Евгений Потапов (Сумма Айти)

OpenStack изнутри

Евгений Потапов

Евгений Потапов

10 лет опыта веб-разработки

5 лет опыта использования облачных технологий

генеральный директор компании «Сумма АйТи»

Стартовали в 2008 году в Иркутске

Поддержка высоконагруженных веб-сайтов

140 миллионов посетителей в сутки

1000+ серверов на поддержке

40 специалистов

внутренние задачи

внутренние задачитестирование failover-планов(быстро переключились на резервную архитектуру)

развертывание бэкапов(накатили свежий бэкап и убедились что он работает)

тестирование новых версий ПО(выкатили новую версию и убедились что она не падает)

тестирование новых решений(mongo db is web scale)

разработка внутренних проектов(доработки мониторинга, машины для девелоперов и тд)

удобно и просто(не залезая в консоль можно сделать виртуалку, использовать и удалить)

о парке хост-машин думать не надо(не нужно думать о том что на хост-машине может полететь рейд-массив)

что используем за то и платим(платим только за то, что используем)

+

на самом деленужно следить за AWS постоянно

закончил таск – выключи инстанс(AWS – дорогая штука при оплате за месяц)

работа на паузе – останови инстанс(не дай бог что-то было в ephemeral)

надо что-то запустить – дважды подумай(может не стоит запускать эту фигню на две недели на m1.xlarge?)

-

а может ? о нем много говорят(большое комьюнити, будет нормальная поддержка)

навсегда забыть об остановках инстансов ради экономии при этом также удобно как AWS(пусть себе работает до тех пор пока не потребуются ресурсы)

вообще в целом - дешевле(на hetzner Xeon E5-1650 64GB RAM стоит 99 евро)

да и просто интересно(тренды нужно знать)

Не специализируемся на OpenStack

Личный опыт (+опыт друзей и коллег)

Доклад на стыке системного администрирования и менеджмента, но есть хардкор

OpenStack - структура

http://www.openstack.org/software/

“The diagram below, illustrates the most common architecture of an OpenStack-based cloud”

http://www.solinea.com/blog/openstack-grizzly-architecture-revisited

OpenStack - структураNova – контроллер виртуализацииNeutron (Quantum) – управление сетевой инфраструктуройCinder – управление дисковой инфраструктуройGlance – управление образамиKeystone – служба идентификацииHorizon – Dashboard

OpenStack - структура

http://ilearnstack.com/tag/openstack/

OpenStack NovaNova – контроллер виртуализации

Службы Nova:API – интерфейс к NovaAMPQ – служба очередейCompute – взаимодействие с гипервизоромConductor – интерфейс взаимодействия с БД для ComputeScheduler – выбор узла для выполнения запроса из очереди

OpenStack Nova

OpenStack Nova1. Запрос на создание инстанса приходит в Nova API 2. Nova API записывает в очередь запрос к Nova Scheduler о том, что надо выполнить такой запрос3. Nova Scheduler получает запрос из очереди, выбирает узел на котором надо выполнить запрос.4. Nova Scheduler шлет запрос в очередь для Nova Compute о том, что надо запустить инстанс

OpenStack Nova

OpenStack Nova5. Nova Compute получает из очереди запрос о том что надо получить инстанс.6. …но Nova Compute не знает о том, какие у инстанса параметры – так как с параметрами в базе общается Nova Conductor7. Nova Compute отправляет запрос в очередь к Nova Conductor о том что надо получить параметры инстанса

OpenStack Nova

OpenStack Nova8. Nova Conductor делает запрос в БД о свойствах инстанса и отдает в очередь ответ с информацией о свойствах запускаемого инстанса9.Nova Compute запускает инстанс с заданными свойствами.

OpenStack Nova

OpenStack NovaБД – MySQLОчередь – QIPD или RabbitMQ7 демонов

те или иные ошибки возникают регулярно

OpenStack Nova«Race condition возникает в момент запуска и одновременного с этим удаления инстанса, если на инстансы назначена одна и та же security group»https://bugs.launchpad.net/nova/+bug/1202449

OpenStack Nova«Невозможно запустить инстанс, если существуют несколько security group с одним и тем же именем (например, в других проектах), и эта security group назначена на этот инстанс»https://bugs.launchpad.net/nova/+bug/1203413

OpenStack Nova«Инстансы в состоянии suspend нельзя вывести из этого состояния после перезагрузки host-машины»

- “My lessons learned are: NEVER PUT YOUR INSTANCE IN SUSPEND STATE!!!”

https://bugs.launchpad.net/nova/+bug/1052696

https://twitter.com/lusis/status/436697765679468544

Neutron«Neutron это система для управления сетями и IP адресами».«Neutron позволяет вам быть уверенным в том, что сеть – не будет узким местом или лимитирующим фактором в вашей облачной среде»

http://en.wikipedia.org/wiki/OpenStack

Neutron

http://openstack.redhat.com/Networking_in_too_much_detail

Neutron1. Виртуальная машина получает информацию об IP-адресе своего интерфейса по DHCP (об этом позже)

[itsumma@cloud ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0DEVICE=eth0BOOTPROTO=dhcpONBOOT=yes

пусть, назначен адрес 10.0.0.12

Neutron2. Сетевой интерфейс виртуальной машины соединяется с TAP-устройством хост-машины

Neutron3. На TAP-девайс, связанный с данной виртуальной машиной, навешаны iptables чейны, в которых прописаны правила назначенной на машину секьюрити-группы

Neutron4. TAP-девайс соединен с интерфейсом br-int, реализованном через Open vSwitch.

«Open vSwitch – программный многоуровневый коммутатор с открытым исходным кодом, предназначенный для работы в гипервизорах и на компьютерах с виртуальными машинами»

http://openvswitch.org/

Neutron5. Интерфейс br-int соединяется с интерфейсом br-ext, который уже доступен хост-машине, но это не все

Neutron6. DHCP на виртуальные машины раздается через приложение dnsmasq, работающее внутри network namespace – службы linux, которая позволяет запустить собственный сетевой стэк для группы процессов

Neutron[root@openstack itsumma]# ip netns exec qrouter-89f090d0-aa1e-4189-bfd8-b8381de2cc97 iptables -t nat -S-A neutron-l3-agent-OUTPUT -d x.x.x.126/32 -j DNAT --to-destination 10.0.0.16-A neutron-l3-agent-OUTPUT -d x.x.x.123/32 -j DNAT --to-destination 10.0.0.18-A neutron-l3-agent-OUTPUT -d x.x.x.245/32 -j DNAT --to-destination 10.0.0.13-A neutron-l3-agent-OUTPUT -d x.x.x.124/32 -j DNAT --to-destination 10.0.0.19-A neutron-l3-agent-OUTPUT -d x.x.x.244/32 -j DNAT --to-destination 10.0.0.9-A neutron-l3-agent-OUTPUT -d x.x.x.125/32 -j DNAT --to-destination 10.0.0.20-A neutron-l3-agent-OUTPUT -d x.x.x.122/32 -j DNAT --to-destination 10.0.0.17

Хватит безумия, выводы На развертывание системы с нуля уходит от двух недель до двух месяцевНа хостинге должна быть возможность просто сделать OS Reload – это обязательно потребуется в первое время, несколько разЦелесообразность экономии при использовании одной машины неочевидна – у нас ушло полтора месяца работы одного человекаДля небольших деплойментов – лучше подождать пару лет

Евгений Потапов

http://[email protected]://twitter.com/eapotapov

OpenStack изнутри