Я читал об OpenStack и о том, как мы можем воссоздать облако в стиле EC2 / S3 для нашей внутренней разработки, и мне трудно найти информацию о том, как облачный контроллер OpenStack обеспечивает избыточность служб управления облаком.
Я знаю, что могу настроить несколько узлов Swift и Nova, но ни один документ / статья / howto / wiki не содержат информации о:
а) что произойдет, если узел облачного контроллера умрет; и б) как настроить резервные облачные контроллеры.
Мне кажется, что, хотя он является масштабируемым, в OpenStack встроена большая точка отказа.
Может ли кто-нибудь с большим опытом работы с OpenStack пролить свет на то, как все это работает в отношении высокой доступности?
Для OpenStack есть несколько вариантов конфигурации высокой доступности. Двумя потенциальными единственными точками отказа являются следующие службы, которые традиционно работают только на одном узле («облачном контроллере»):
Я считаю, что для nova-api вы можете просто запустить несколько экземпляров на разных физических узлах, поскольку состояние сохраняется во внешней базе данных.
Для настройки сетевой службы для работы в режиме высокой доступности необходимо использовать --multi_host параметр конфигурации в вашем файле конфигурации nova. См. Документацию OpenStack на Существующие варианты высокой доступности для сети
Я не играл с OpenStack, но если облачный контроллер действительно является единственной точкой отказа: один из способов предотвратить проблемы с ним - выделить для этого два сервера и настроить Heartbeat v2 (или Corosync / Pacemaker, как его сейчас называют ) между ними в активно-пассивном режиме.
Таким образом, если основной сервер умирает по какой-либо причине, другой поднимает свою рабочую нагрузку за (милли) секунды.
"... Еще лучше: узел контроллера теперь содержит только компоненты платформы, которые не являются внутренними службами OpenStack (MySQL и RabbitMQ - стандартные демоны Linux). Таким образом, администратор облака может позволить себе передать их администрирование внешнему объекту, Database Team. , выделенный кластер RabbitMQ. Таким образом, центральный узел контроллера исчезает, и мы получаем кучу узлов вычислений / API, которые можно масштабировать почти линейно ».