Автор: Дмитрий Новаковский
Сейчас отличное время для того, чтобы быть компанией-участницей инициативы OpenStack – вы получаете большую часть данных для маркетинга и управления продукцией, просто разговаривая каждый день с клиентами и партнерами. Как бы то ни было, конкуренция в данной сфере довольно высока, поэтому и для сообщества, и для отдельных вендоров важно грамотно создать задел функциональных возможностей и расставить их приоритеты, при этом четко осознавая, кто и чего хочет. Я выступлю в роли «капитана очевидность», но все же скажу, что потребности Предприятия весьма отличаются от потребностей сервис-провайдера, органа власти или какого-нибудь IT-подразделения, работающего в масштабе World Wide Web.
В данном посте (и в нескольких предстоящих) я поделюсь своими мыслями относительно функциональных возможностей – фактически «строительных блоков» – которые все еще отсутствуют в OpenStack, но необходимы для того, чтобы платформа успешно использовалась на уровне Предприятия. Кроме того, вы узнаете, ведется ли в настоящее время работа над устранением данного пробела и, если да, то какие решения существуют.
Высокая доступность (High Availability, или HA): для Предприятия это, пожалуй, две самые важные буквы в контексте виртуализации/облака. В двух словах, ее наличие означает, что, в случае если по какой-либо причине произойдет сбой в работе виртуальной машины (VM), например, из-за отказа операционной системы, выхода из строя всего узла гипервизора и т.п., то центр обработки данных/платформа управления облаком «вернет ее к жизни» в кратчайшее время. Это может быть сделано посредством быстрого перезапуска на том же хосте гипервизора или экстренного переноса (эвакуации) на другой хост гипервизора. «Экстремальным» режимом для VIP виртуальных машин является «Отказоустойчивость», или функционирование двух VM на разных гипервизорах с зеркалированием состояния CPU/памяти таким образом, чтобы всегда оставалась хотя бы одна сохранившая работоспособность VM, к которой можно было бы обратиться в случае катастрофы.
Исторически успех vSphere на уровне Предприятия в основном строился на восприятии существующих приложений как относящихся к классу «pets». Такие приложения активно разрабатывались в течение многих лет, они работают на «голом железе» и поддерживаются в рабочем состоянии специальными командами. Приложения такого типа, как правило, не готовы к работе на облаке. Им практически не присуща встроенная интеллектуальная обработка отказов, но они успешно используются для удовлетворения потребностей бизнеса и бюджет на их разработку спланирован на много лет вперед.
Помимо консолидации на меньшем количестве физических серверов, vSphere повышает «качество жизни» данных приложений, помогая им восстанавливаться после сбоев, при этом не требуя от них какого-либо «учета работы средств виртуализации/облачных сервисов». Чтобы иметь успех, платформа OpenStack должна уметь выполнять ту же функцию.
Хорошие новости заключаются в том, что «кусочки», необходимые для поддержки высокой степени доступности уже имеются, так что для построения общей «доступности-как-услуги» для OpenStack требуется меньше усилий, чем можно было бы ожидать.
В OpenStack поддержано несколько совместно используемых+распределенных серверных систем хранения данных, которые подходят для осуществления динамической миграции/экстренного переноса (у нас в Mirantis любимой системой является Ceph), а в Nova даже реализована команда «nova evacuate», которая приводит к вызову ряда API для экстренного переноса VM на другой хост гипервизора.
Чего не хватает, так это компонента управления+мониторинга (и, конечно, красивого пользовательского интерфейса и мощного PR ). Какой-то процесс все же должен тщательно следить за работой VM с поддержкой высокой доступности на различных уровнях (доступность гипервизора, работоспособность nova-compute, ответ на пинг VM и т.д.), и после принятия решения «все, она умерла» запускать экстренный перенос через Nova. Кроме того, безусловно, такая система должна гарантировать успех выполняемого экстренного переноса.
Плохие новости заключаются в том, что сообщество OpenStack было (и в некоторой степени до сих пор остается) непоследовательным в определении вектора развития OpenStack в контексте обеспечения доступности приложений. К счастью, последний Саммит в Атланте укрепил мнение относительно необходимости «Завоевания Предприятий» и, сохраняя уважение к изначальным принципам OpenStack, предполагающим «применение методологии DevOps/готовность к использованию облака», многие открыто высказывающиеся члены сообщества поддерживают идею «создания сервиса, который бы использовал API-функции Nova для мониторинга других сервисов или всех VM и автоматически выполнял определенные действия, такие как запуск другого экземпляра с последнего снапшота тома, создание дополнительных экземпляров и т.п.».
Самым неприятным (или, возможно, просто неудачным) моментом является то, что пока сообщество не выработало последовательной позиции, некоторые потенциальные клиенты, которые рассматривают возможность внедрения OpenStack, могли получить неправильный месседж и думают: «OpenStack никогда не будет заботиться об обеспечении высокой доступности, выходящей за рамки собственной инфраструктуры контроллеров». Интересно, есть ли у нас еще время, чтобы вернуть доверие этих людей.
А теперь наступает момент истины: кто будет писать код, и когда он превратится в полезную функциональность?
Кто-то может утверждать, что возможным решением является настройка систем Nagios или Zabbix, выполняющих интенсивный опрос виртуальных машин класса «pet», и скриптов, запускающих экстренный перенос. Это может сработать в какой-нибудь странной среде типа «сделай сам», но, я думаю, что в контексте управления это слишком громоздко для уровня предприятия. Не стоит забывать о том, что IT зачастую до сих пор является местом возникновения затрат на предприятии, поэтому нам нужно облегчить работу сотрудникам IT, а не наоборот. Далее, можно также рассмотреть возможность использования Heat в качестве «машины состояний», а Ceilometer в качестве аварийного администратора, но, по крайней мере, на данный момент нет каких-либо подходящих историй успеха, о которых можно было бы говорить.
Реальный компромисс в данном случае – начать внедрять OpenStack с одновременным использованием гипервизоров KVM и vSphere (при условии наличия у предприятия определенных лицензий vSphere). OpenStack может быть полезной для самообслуживания/коллективной аренды/оркестровки и хостинга приложений, готовых к работе с облаком на базе KVM, а vSphere будет делать то, что она делает лучше всего, – выполнять роль ведущего узла для приложений класса «pet» и заботиться о том, чтобы они оставались довольны виртуализацией «наподобие голого железа».
К счастью, компания VMWare вложила немало средств в разработку драйвера vCenter для Nova, и, как разъяснил Kenneth Hui в серии своих отличных постов, функциональные возможности типа HA, DRS и vMotion функциональны, даже работая под OpenStack. Вы даже можете с легкостью воспользоваться преимуществами такой настройки – см. наши последние посты на тему того, как использовать Mirantis OpenStack для построения своего первого комплекса OpenStack+vSphere,.
Какие еще функциональные возможности, на ваш взгляд, нужны OpenStack для того, чтобы добиться успеха на уровне Предприятия?
PS: Не забывайте о том, что поддержка высокой степени доступности включена в vSphere, начиная с выхода Essentials Plus Kit, второго наименее дорогостоящего предложения VMWare после ESXi-only Essentials Kit, но для его использования вам также потребуется лицензия на vCenter.
Оригинал статьи на английском языке.
Сейчас отличное время для того, чтобы быть компанией-участницей инициативы OpenStack – вы получаете большую часть данных для маркетинга и управления продукцией, просто разговаривая каждый день с клиентами и партнерами. Как бы то ни было, конкуренция в данной сфере довольно высока, поэтому и для сообщества, и для отдельных вендоров важно грамотно создать задел функциональных возможностей и расставить их приоритеты, при этом четко осознавая, кто и чего хочет. Я выступлю в роли «капитана очевидность», но все же скажу, что потребности Предприятия весьма отличаются от потребностей сервис-провайдера, органа власти или какого-нибудь IT-подразделения, работающего в масштабе World Wide Web.
В данном посте (и в нескольких предстоящих) я поделюсь своими мыслями относительно функциональных возможностей – фактически «строительных блоков» – которые все еще отсутствуют в OpenStack, но необходимы для того, чтобы платформа успешно использовалась на уровне Предприятия. Кроме того, вы узнаете, ведется ли в настоящее время работа над устранением данного пробела и, если да, то какие решения существуют.
Недостающий структурный элемент №1: высокая доступность/отказоустойчивость на уровне Предприятия
Высокая доступность (High Availability, или HA): для Предприятия это, пожалуй, две самые важные буквы в контексте виртуализации/облака. В двух словах, ее наличие означает, что, в случае если по какой-либо причине произойдет сбой в работе виртуальной машины (VM), например, из-за отказа операционной системы, выхода из строя всего узла гипервизора и т.п., то центр обработки данных/платформа управления облаком «вернет ее к жизни» в кратчайшее время. Это может быть сделано посредством быстрого перезапуска на том же хосте гипервизора или экстренного переноса (эвакуации) на другой хост гипервизора. «Экстремальным» режимом для VIP виртуальных машин является «Отказоустойчивость», или функционирование двух VM на разных гипервизорах с зеркалированием состояния CPU/памяти таким образом, чтобы всегда оставалась хотя бы одна сохранившая работоспособность VM, к которой можно было бы обратиться в случае катастрофы.
Почему Предприятию необходима поддержка высокой степени доступности?
Исторически успех vSphere на уровне Предприятия в основном строился на восприятии существующих приложений как относящихся к классу «pets». Такие приложения активно разрабатывались в течение многих лет, они работают на «голом железе» и поддерживаются в рабочем состоянии специальными командами. Приложения такого типа, как правило, не готовы к работе на облаке. Им практически не присуща встроенная интеллектуальная обработка отказов, но они успешно используются для удовлетворения потребностей бизнеса и бюджет на их разработку спланирован на много лет вперед.
Помимо консолидации на меньшем количестве физических серверов, vSphere повышает «качество жизни» данных приложений, помогая им восстанавливаться после сбоев, при этом не требуя от них какого-либо «учета работы средств виртуализации/облачных сервисов». Чтобы иметь успех, платформа OpenStack должна уметь выполнять ту же функцию.
Как обстоят дела с обеспечением высокой степени доступности в OpenStack?
Хорошие новости заключаются в том, что «кусочки», необходимые для поддержки высокой степени доступности уже имеются, так что для построения общей «доступности-как-услуги» для OpenStack требуется меньше усилий, чем можно было бы ожидать.
В OpenStack поддержано несколько совместно используемых+распределенных серверных систем хранения данных, которые подходят для осуществления динамической миграции/экстренного переноса (у нас в Mirantis любимой системой является Ceph), а в Nova даже реализована команда «nova evacuate», которая приводит к вызову ряда API для экстренного переноса VM на другой хост гипервизора.
Чего не хватает, так это компонента управления+мониторинга (и, конечно, красивого пользовательского интерфейса и мощного PR ). Какой-то процесс все же должен тщательно следить за работой VM с поддержкой высокой доступности на различных уровнях (доступность гипервизора, работоспособность nova-compute, ответ на пинг VM и т.д.), и после принятия решения «все, она умерла» запускать экстренный перенос через Nova. Кроме того, безусловно, такая система должна гарантировать успех выполняемого экстренного переноса.
Плохие новости заключаются в том, что сообщество OpenStack было (и в некоторой степени до сих пор остается) непоследовательным в определении вектора развития OpenStack в контексте обеспечения доступности приложений. К счастью, последний Саммит в Атланте укрепил мнение относительно необходимости «Завоевания Предприятий» и, сохраняя уважение к изначальным принципам OpenStack, предполагающим «применение методологии DevOps/готовность к использованию облака», многие открыто высказывающиеся члены сообщества поддерживают идею «создания сервиса, который бы использовал API-функции Nova для мониторинга других сервисов или всех VM и автоматически выполнял определенные действия, такие как запуск другого экземпляра с последнего снапшота тома, создание дополнительных экземпляров и т.п.».
Самым неприятным (или, возможно, просто неудачным) моментом является то, что пока сообщество не выработало последовательной позиции, некоторые потенциальные клиенты, которые рассматривают возможность внедрения OpenStack, могли получить неправильный месседж и думают: «OpenStack никогда не будет заботиться об обеспечении высокой доступности, выходящей за рамки собственной инфраструктуры контроллеров». Интересно, есть ли у нас еще время, чтобы вернуть доверие этих людей.
А теперь наступает момент истины: кто будет писать код, и когда он превратится в полезную функциональность?
Временное решение
Кто-то может утверждать, что возможным решением является настройка систем Nagios или Zabbix, выполняющих интенсивный опрос виртуальных машин класса «pet», и скриптов, запускающих экстренный перенос. Это может сработать в какой-нибудь странной среде типа «сделай сам», но, я думаю, что в контексте управления это слишком громоздко для уровня предприятия. Не стоит забывать о том, что IT зачастую до сих пор является местом возникновения затрат на предприятии, поэтому нам нужно облегчить работу сотрудникам IT, а не наоборот. Далее, можно также рассмотреть возможность использования Heat в качестве «машины состояний», а Ceilometer в качестве аварийного администратора, но, по крайней мере, на данный момент нет каких-либо подходящих историй успеха, о которых можно было бы говорить.
Реальный компромисс в данном случае – начать внедрять OpenStack с одновременным использованием гипервизоров KVM и vSphere (при условии наличия у предприятия определенных лицензий vSphere). OpenStack может быть полезной для самообслуживания/коллективной аренды/оркестровки и хостинга приложений, готовых к работе с облаком на базе KVM, а vSphere будет делать то, что она делает лучше всего, – выполнять роль ведущего узла для приложений класса «pet» и заботиться о том, чтобы они оставались довольны виртуализацией «наподобие голого железа».
К счастью, компания VMWare вложила немало средств в разработку драйвера vCenter для Nova, и, как разъяснил Kenneth Hui в серии своих отличных постов, функциональные возможности типа HA, DRS и vMotion функциональны, даже работая под OpenStack. Вы даже можете с легкостью воспользоваться преимуществами такой настройки – см. наши последние посты на тему того, как использовать Mirantis OpenStack для построения своего первого комплекса OpenStack+vSphere,.
Какие еще функциональные возможности, на ваш взгляд, нужны OpenStack для того, чтобы добиться успеха на уровне Предприятия?
PS: Не забывайте о том, что поддержка высокой степени доступности включена в vSphere, начиная с выхода Essentials Plus Kit, второго наименее дорогостоящего предложения VMWare после ESXi-only Essentials Kit, но для его использования вам также потребуется лицензия на vCenter.
Оригинал статьи на английском языке.