Автор: Дмитрий Новаковский Сейчас прекрасное время для компании OpenStack: вы получаете большую часть данных по маркетингу и управлению продуктами, просто общаясь со своими клиентами и партнерами каждый день.
Как бы то ни было, конкуренция в этой области достаточно высока, поэтому как сообществу, так и отдельным вендорам важно грамотно формировать задел функционала и расставлять его приоритеты, при этом четко понимая, кто чего хочет. Я буду играть роль «Капитана Очевидность», но все равно скажу, что потребности Предприятия сильно отличаются от потребностей поставщика услуг, государственного учреждения или какого-то ИТ-подразделения, действующего в масштабах Всемирной паутины.
.
В этом посте (и в нескольких последующих) я поделюсь своими мыслями о функциональности — по сути, о «строительных блоках», — которые все еще отсутствуют в OpenStack, но необходимы для успешного использования платформы на уровне предприятия.
Кроме того, вы узнаете, ведется ли в настоящее время работа по устранению разрыва, и если да, то какие решения существуют.
Недостающий структурный блок № 1: высокая доступность/отказоустойчивость на уровне предприятия
Высокая доступность (HA).Для предприятия это, пожалуй, две самые важные буквы в контексте виртуализации/облака.
В двух словах, его наличие означает, что если по какой-либо причине виртуальная машина (ВМ) выйдет из строя, например из-за сбоя операционной системы, выхода из строя всего узла гипервизора и т. д., то ее выведет дата-центр/платформа управления облаком.
вернуться к жизни в кратчайшие сроки.
Это можно сделать посредством быстрого перезапуска на том же хосте гипервизора или экстренного переноса (эвакуации) на другой хост гипервизора.
«Экстремальным» режимом для виртуальных машин VIP является «Отказоустойчивость», или функционирование двух ВМ на разных гипервизорах с зеркалированием состояния ЦП/памяти таким образом, чтобы всегда оставалась хотя бы одна ВМ, остающаяся работоспособной, что может доступ к ним в случае стихийного бедствия.
Почему предприятию необходима поддержка высокой доступности?
Исторически успех vSphere на уровне предприятия во многом основывался на восприятии существующих приложений как «домашних животных».Такие приложения активно разрабатываются уже много лет, работают на «голом железе» и обслуживаются специализированными командами.
Эти типы приложений обычно не готовы к облаку.
В них практически нет встроенной интеллектуальной обработки неисправностей, но они успешно используются для удовлетворения потребностей бизнеса, а бюджет на их разработку запланирован на много лет вперед. Помимо консолидации на меньшем количестве физических серверов, vSphere улучшает «качество жизни» этих приложений, помогая им восстанавливаться после сбоев, не требуя от них принятия каких-либо «соображений виртуализации/облачных сервисов».
Чтобы добиться успеха, платформа OpenStack должна иметь возможность выполнять ту же функцию.
Как обстоят дела с высокой доступностью в OpenStack?
Хорошей новостью является то, что элементы, необходимые для поддержки высокой доступности, уже существуют, поэтому построение общей доступности как услуги для OpenStack требует меньше усилий, чем можно было бы ожидать.OpenStack поддерживает несколько общих и распределенных серверных систем хранения, которые подходят для динамической миграции/отработки отказа (Ceph — наш фаворит в Mirantis), а Nova даже включает команду «nova evacuate», которая вызывает ряд API для экстренной передачи виртуальной машины.
на другой хост гипервизора.
Чего не хватает, так это компонента управления+мониторинга (и, конечно же, красивого пользовательского интерфейса и мощного пиара).
Какой-то процесс все равно должен внимательно следить за работой ВМ с поддержкой высокой доступности на разных уровнях (доступность гипервизора, производительность nova-вычислений, реакция на пинг ВМ и т.д.), и после принятия решения «все, она мертва» запускать экстренный перевод через Nova. Кроме того, конечно, такая система должна гарантировать успешность выполнения экстренной передачи.
Плохая новость заключается в том, что сообщество OpenStack было (и в некоторой степени остается) непоследовательным в определении направления OpenStack в контексте доступности приложений.
К счастью, последний саммит в Атланте подтвердил необходимость «завоевать предприятие» и, сохраняя уважение к первоначальным принципам OpenStack «DevOps/готовность к облаку», многие откровенные члены сообщества поддерживают эту идею «создание службы, которая будет использовать функции Nova API для мониторинга других служб или всех виртуальных машин и автоматически выполнять определенные действия, такие как запуск другого экземпляра из последнего снимка тома, создание дополнительных экземпляров и т. д.» Самый неудачный (или, возможно, просто неудачный) аспект заключается в том, что до тех пор, пока сообщество не выработает последовательную позицию, некоторые потенциальные клиенты, рассматривающие возможность внедрения OpenStack, могут получить неправильное сообщение и подумать: «OpenStack никогда не будет заботиться о высокой доступности».
за пределами собственной инфраструктуры контролеров».
Интересно, успеем ли мы еще вернуть доверие этих людей.
Теперь наступает момент истины: кто будет писать код и когда он превратится в полезный функционал?
Временное решение
Можно возразить, что возможным решением является настройка систем Nagios или Zabbix для выполнения интенсивного опроса домашних виртуальных машин и сценариев для запуска экстренной миграции.Это может сработать в какой-нибудь странной среде DIY, но я думаю, что в контексте управления это слишком громоздко для уровня предприятия.
Не забывайте, что ИТ-специалисты зачастую по-прежнему являются центром затрат предприятия, поэтому нам нужно облегчить задачу ИТ-специалистам, а не наоборот. Кроме того, можно было бы также рассмотреть возможность использования Heat в качестве «конечного автомата» и Ceilometer в качестве менеджера по чрезвычайным ситуациям, но, по крайней мере, на данный момент нет подходящих историй успеха, о которых можно было бы говорить.
Настоящий компромисс в этом случае — начать внедрение OpenStack с одновременным использованием гипервизоров KVM и vSphere (при условии наличия у предприятия определенных лицензий vSphere).
OpenStack может быть полезен для самообслуживания/совместной аренды/оркестрации и размещения облачных приложений на базе KVM, а vSphere будет делать то, что умеет лучше всего – выступать в качестве главного узла для домашних приложений и заботиться о том, чтобы они были довольны виртуализация «голого железа».
К счастью, VMWare вложила значительные средства в разработку драйвера vCenter для Nova, и, как объяснялось, Кеннет Хуэй в своей серии превосходных постов , такие функции, как HA, DRS и vMotion, работают даже при работе на OpenStack. Вы даже можете легко воспользоваться этой настройкой — см.
Какие еще функции, по вашему мнению, необходимы OpenStack для успеха на уровне предприятия? PS: Не забывайте, что поддержка высокой доступности была включена в vSphere с момента выпуска Essentials Plus Kit, второго наименее дорогого предложения VMWare после Essentials Kit только для ESXi, но для его использования вам также потребуется лицензия vCenter. Оригинальная статья по-английски .
Теги: #Mirantis #Mirantis #openstack #высокая доступность #виртуальная машина #vsphere #ceph #nova #nagios #zabbix #heat #ceilometer #kvm #vmware #open source
-
Nokia: Квартальные Результаты
19 Oct, 24 -
Форекс – Это Не Гербалайф?
19 Oct, 24 -
Философия Эволюции И Эволюция Интернета
19 Oct, 24
