Любая система имеет право называться облачной при выполнении пяти основных условий: самообслуживание по требованию; универсальный доступ по сети вне зависимости от используемого терминального устройства; объединение ресурсов для динамического перераспределения мощностей между потребителями в условиях постоянного изменения спроса на мощности; эластичность сервисов без дополнительных издержек на взаимодействие с поставщиком, как правило, в автоматическом режиме; учет потребления. Однако все это важно для публичного облака, а для частного облака, предназначенного для малого, среднего бизнеса или государственного учреждения, приведенные требования избыточны. Сегодня такие предприятия обладают собственным парком серверов, недорогим телекоммуникационным оборудованием и либо имеют свой ИТ-отдел, занимающийся обслуживанием инфраструктуры, либо отдают трудоемкое обслуживание на аутсорсинг, а в штате держат нескольких специалистов поддержки.

Традиционно роли физических серверов распределяются таким образом, чтобы одна машина выполняла одну задачу либо несколько родственных, что обеспечивает максимальную надежность системы в целом. Например, первичный домен-контроллер в среде Windows, скорее всего, будет выполнять функции сервера DHCP, сервера приложений, но вряд ли на нем будет развернут еще и Microsoft Exchange или файловый сервер. В результате оказывается, что ИТ-отделу может не хватить физического оборудования, хотя реально имеющиеся машины большую часть времени простаивают.

Такая ситуация свидетельствует о том, что пора задуматься о виртуализации: переход в виртуальное пространство позволит оптимизировать загрузку оборудования, а значит, сэкономить на инвестициях в оборудование и на стоимости владения ИТ-инфраструктурой в целом. Однако и виртуализация имеет ограничения и хороша до тех пор, пока речь идет о двух-трех физических серверах и о виртуальных машинах, потребление ресурсов которыми меняется незначительно. Гипервизор предоставляет урезанные возможности по обслуживанию виртуальных машин и собственной среды управления. Безусловно, имеются внешние системы управления гипервизорами. Например, для ESXi компанией VMware выпускается бесплатная версия vSphere, однако возможности таких продуктов также минимальны. Аналогичная ситуация и у KVM, для которого предлагаются развитые пользовательские интерфейсы, по своим возможностям не выходящие за рамки базовых функций.

При этом гипервизор решает конкретную задачу по управлению виртуальной машиной, и в его задачу не входит работа с сетями, хранилищами данных и т. п. В случае, когда возникает необходимость централизованного управления всеми ИТ-ресурсами, особенно централизованного перераспределения ресурсов и управления физическим оборудованием и сетями, требуется переходить от виртуализации к облакам.

Согласно статистике (например, www.rightscale.com/lp/2015-state-of-the-cloud-report), большинство компаний среднего бизнеса в США идут по пути создания собственного частного облака с возможностью перевода его в гибридное. Выбор в пользу частного облака очевиден: компания имеет опыт администрирования собственных вычислительных ресурсов, в ее штате работают специалисты соответствующего профиля и квалификации и уже имеется оборудование, которое надо просто эффективно использовать. Но возникает вопрос: строить облако на базе коммерческого или открытого решения?

Коммерческие разработки обычно имеют хорошую поддержку, а эксперименты по развертыванию систем с открытым исходным кодом могут дорого обойтись компании и сравнимы со стоимостью поддержки, например, решений VMware. Тем не менее облачные решения на базе ПО с открытым кодом сегодня вполне достигли уровня зрелости, требуемого для их успешного применения в качестве инфраструктуры частного облака. Вместе с тем фактический выбор открытых облачных систем невелик и по сути ограничивается системами OpenNebula, CloudStack от Apache Foundation и OpenStack [1].

Вариаций на тему OpenStack сегодня множество: коммерческие версии — HP Helion, Red Hat и SUSE Linux; условно бесплатная версия OpenStack от Ubuntu (Canonical), которая может быть настроена покомпонентно, но необходимо учитывать, что входящий в состав рекомендованной сборки Canonical Landscape — это платное ПО, представляющее собой систему управления инфраструктурой облака; openSUSE, которую разработчики не рекомендуют использовать в качестве боевого решения, предлагая SUSE Linux Enterprise Server, работающую устойчивее своего аналога от сообщества Open Source. В лучшей позиции находится компания Mirantis, имеющая в России как собственный офис, так и партнеров, которые предлагают сборку облачной ОС, в англоязычных материалах называемую Rock Solid.

Типовая рекомендованная инсталляция сборки Mirantis OpenStack (MOS) представлена на рис. 1. Ограничение данной конфигурации состоит в том, что весь внутренний и внешний трафик идет через кластер контроллеров облака, а это может приводить к появлению «бутылочного горла», снижающего производительность облака в целом. Вместе с тем компания одной из первых интегрировала в сборку OpenStack систему хранения данных Ceph, что значительно облегчило администраторам частного облака задачу резервного копирования и обеспечения надежности хранения актуальных данных при одновременном решении проблемы миграции виртуальных машин. Без Ceph блочная миграция могла приводить к сбоям или к полному нарушению функционирования виртуальной машины.

 

Рис. 1. Типовая инсталляция сборки MOS с кластеризованным контроллером стека
Рис. 1. Типовая инсталляция сборки MOS с кластеризованным контроллером стека

 

Таким образом, сборка OpenStack стала вполне работоспособным продуктом, что позволило компании «ТМ Оператор Групп» выполнить проект для сайта Newsru.com, серверы которого для обеспечения отказоустойчивости размещались в трех независимых ЦОД. При переходе от виртуализации к облакам в Newsru.com возник вопрос об управлении инфраструктурой частного облака, и выбор сборки Mirantis OpenStack 6.х казался логичным — процедура развертывания продукта состоит только из одной операции установки контроллера инфраструктуры стека Fuel и занимает 20–30 минут. Сам по себе Fuel сильно упрощает работу с оборудованием, позволяя обнаружить сервер и ввести его в инфраструктуру стека в соответствии с описанными в настройках облака ролями. В проекте Newsru.com была оптимизирована загрузка серверного оборудования и консолидированы вычислительные мощности, что, в свою очередь, позволило не заменять, а просто выводить из эксплуатации машины, срок службы которых подходит к концу. Экономия оказалась довольно существенной, даже на энергопотреблении.

Однако в ряде случаев развертывание частного облака заканчивается неудачей. MOS — довольно капризный продукт, и следует не более чем на 30–40% отклоняться от указанных в документации рекомендованных параметров, одновременно строго следя за совместимостью оборудования. (У компании имеется платная служба поддержки, способная помочь развернуть работоспособное частное облако.)

Вместе с тем решить задачу объединения трех географически разнесенных ЦОД средствами OpenStack в проекте Newsru.com не удалось, несмотря на то что в документации приводится множество красивых схем, объясняющих, как обеспечить географическую распределенность (в терминах OpenStack — Multi-region mode). Отсутствие каналов связи с пропускной способностью не менее 10 Гбит/с стало еще одним препятствием на пути создания географически распределенного облака — при времени выполнения команды rping в 130 мс надеяться на устойчивую работу географически разнесенной инфраструктуры не приходится, особенно в контексте системы аутентификации Keystone и хранилища Ceph, на котором задержки будут просто катастрофическими. В результате для проекта Newsru.com географическая распределенность была реализована программно средствами отказоустойчивого кластера на основе СУБД MariaDB/Galera.

Как бы то ни было, опыт проекта Newsru.com продемонстрировал, что стек технологий OpenStack можно применять для промышленных высоконагруженных систем и решения задачи оптимизации загрузки оборудования. Кроме того, OpenStack действительно позволяет обеспечить отказоустойчивость, однако у этой облачной операционной системы имеются ограничения и ряд требующих локализации проблем, возникающих в процессе эксплуатации: высокая загрузка процессора контроллера при работе Open vSwitch, программного коммутатора, предназначенного для работы в гипервизорах и с виртуальными машинами; сложность обновления базовой операционной системы и компонентов стека при использовании готовых сборок; высокая сетевая нагрузка при выходе из строя одного из серверов и т. п.

В результате, в расчете на промышленные проекты на основе OpenStack, было решено создать собственную сборку, оптимизированную под конкретное аппаратное обеспечение компании «ДЕПО Компьютерс». Эта разработка должна была решать проблемы с надежностью, допускать тиражирование и позволять без высоких затрат развертывать частное облако для конкретного заказчика. Ясно, что конфигурация облака должна допускать масштабирование и уже при минимальной комплектации решать бизнес-задачи заказчика.

Первое, от чего было решено отказаться, — это контроллер оборудования облака (аналог Fuel). Вместо него был сформирован набор скриптов, позволяющий инсталлировать сервер и ввести его в уже существующую ИТ-инфраструктуру с назначением ему определенной роли (рис. 2). Сами роли отличаются от принятого в MOS — в новой версии OpenStack Liberty функции контроллера менее выражены и фиксированы лишь функции веб-интерфейса управления инфраструктурой Horizon и ряда вспомогательных сервисов. OpenStack Neutron, отвечающий за сетевые ресурсы облака, был оптимизирован за счет применения схемы Providers Network, позволяющей использовать физическое коммуникационное оборудование вместо виртуальных маршрутизаторов, а оставшийся его функционал был распределен по всем машинам, входящим в инфраструктуру. Другим изменением, позволившим снизить потребление ресурсов, стал отказ от Open vSwitch.

Рис. 2. Логическая схема частного облака Depo Opencloud TМ
Рис. 2. Логическая схема частного облака Depo Opencloud TМ

 

Одновременно с оптимизацией использования ресурсов были разработаны и протестированы вспомогательные программные сервисы, отвечающие за обновление ПО, быстрое развертывание виртуальных машин с заданным набором программного обеспечения, резервное копирование данных, виртуальных машин и конфигурации облака.

В декабре 2015 года в ГБОУ «Лицей № 1533 (информационных технологий)» было развернуто частное облако [2] на платформе Depo Opencloud TМ в конфигурации из трех серверов, которые заменили устаревающую стойку и обеспечили условия для одновременной работы нескольких тысяч пользователей.

***

Проекты для Newsru.com и Лицея № 1533 показали, что на базе OpenStack можно строить бюджетное частное облако для компаний малого и среднего бизнеса, однако широкому распространению такого решения препятствуют недоверие пользователей и дефицит квалифицированных кадров. В этой связи выходом может быть типовое тиражируемое решение на основе, например, Depo OpenCloud TM, не требующее больших ресурсов на развертывание и эксплуатацию частного облака.

Литература

  1. Дмитрий Волков, Лев Левин. Секреты успеха OpenStack // Открытые системы.СУБД. — 2015. — № 2. — С. 14–17. URL: http://www.osp.ru/os/2015/02/13046272 (дата обращения: 18.03.2016).
  2. Дмитрий Волков. Облако для образования // Computerworld Россия. — 2016. — № 1. — С. 24. URL: http://www.osp.ru/cw/2016/01/13048275 (дата обращения: 18.03.2016).

Владимир Сигунов (vsigunov@tmoperatorgroup.ru) — технический директор, «ТМ Оператор Групп» (Москва).