В середине 2014 года мы в приняли решение о необходимости переноса услуг публичного сервиса аренды виртуальных машин (далее сервис ) с платформы OpenQRM, которая была выбрана на тот момент без должного анализа потребностей клиентов и не отвечала требованиям как к управляемости так и к философии поведения (надо сказать, что разработчики OpenQRM вообще странно подошли к разработке, создав продукт из кучи bash-скриптов, кода на PHP и кучи костылей). В общем, наши пользователи были несчастливы, сервис был так себе и приносил скорее убытки, чем прибыль. Необходимо отметить, что наша дочерняя компания, которая как раз оказывает операторские услуги — небольшая региональная компания и мы не рассматривали создание большого сервиса в тот момент, а основной задачей виделось переход на стабильный и надежный продукт, который бы отвечал следующим требованиям:
- простота в развертывании и настройке для нужд сервиса ;
- готовность к использованию и достаточно широкая база пользователей;
- простота в диагностике ошибок;
- удобный пользовательский интерфейс;
- API для управления виртуальными машинами.
Размер инфраструктуры не планировался большим — на тот момент мы рассчитывали использовать 512 — 1024 ГБ RAM, 128 — 256 ядер Xeon E5-2670, 10 — 20 ТБ хранилища, 200+ виртуальных машин. Сервис предполагал предоставление виртуальных машин с непосредственным присвоением публичных IPv4, о поддержке IPv6 речь не шла. В качестве технологии виртуализации мы ориентировались на KVM. Хранилище — классическое NFSv3.
Мы провели сравнительный анализ (читайте — попробовали развернуть по мануалам) несколько продуктов — Apache CloudStack, OpenStack, Eucalyptus и выбрали Apache CloudStack (далее ACS) для предоставления услуг. Мы не рассматривали для использования системы без API. Сейчас уже достаточно сложно ретроспективно восстановить процесс выбора, могу лишь заметить, что функционирующую инфраструктуру с использованием ACS мы получили за 1-2 дня. На тот момент это был ACS версии 4.3, который мы до сих пор и используем в данном облаке (обновление до текущих версий не имеет смысла, поскольку инфраструктура стабильна, адекватно реагирует на добавление и замену различных ее частей и позволяет обеспечивать потребности пользователей). В момент написания статьи к выпуску планируется ACS 4.10, данный релиз включает не так много изменений, которые предоставляют новую функциональность. Тут необходимо сделать небольшое отступление — ACS предоставляет большое количество различных сервисов, конечным выбором которых получается то или иное облако — можно с балансировкой нагрузки или без, с использованием NAT или прямым назначением IP, с внешними шлюзами безопасности или без поддержки безопасности и т.п. В общем, может оказаться, что в рамках одних топологий развертывания, гипервизоров, хранилищ, сетевых топологий почти нет изменений между релизами 4.3 и 4.10, в то время как в рамках других топологий этих изменений может быть существенное количество.
Мы используем самый простой вариант развертывания — публичное облако с общим адресным пространством без специальных сетевых услуг (это называется ACS с базовыми зонами (basic zones) без групп безопасности (security groups)). В рамках данной модели развертывания что-то новое изобрести достаточно сложно, поэтому в рамках ACS 4.10 мы ждем только поддержку IPv6.
Дело в том, что ACS часто используется для предоставления комплексных виртуальных услуг и развивается в данном направлении быстрее (это так называемые продвинутые зоны (advanced zones)), поэтому для продвинутых зон поддержка IPv6 существует достаточно давно, а для базовых зон появляется только сейчас. В том случае, если облако будет использоваться для предоставления услуг крупным клиентам в B2B или просто как приватное облако для внедрения в организации, то необходимо смотреть какие возможности требуются и, возможно, что с релиза 4.3 до 4.10 произошли какие-то существенные изменения в наборе возможностей. Мы в настоящий момент не видим в рамках нашего бизнеса предоставлять региональным клиентам такие услуги (точнее, они не готовы их покупать или мы не умеем их продавать), поэтому ACS с базовыми зонами — наше все.
Итак, как происходила в течение трех лет эксплуатация нашей инфраструктуры, и с какими сложностями мы столкнулись. Вполне вероятно, что если следовать замечаниям, которые здесь описаны, то эксплуатация облака может быть практически безболезненной. Итак, что мы обнаружили в ACS за 3 года описано далее.
Доступность
Итак, начнем с аптайма — у нас есть серверы с аптаймом более 1 года, никаких нестабильных моментов из-за которых ACS уходит “в пике” за три года не обнаружено. Подавляющее количество поломок системы происходило из-за проблем с электроснабжением. За время эксплуатации компенсацию за нарушение SLA 99.9% мы производили 1 раз.
Виртуальный маршрутизатор
Самый плохой, сложный, непрозрачный компонент ACS — виртуальный маршрутизатор. Роль его заключается в предоставлении услуг DHCP, прямой и обратной зоны DNS, маршрутизации, балансировке, статическом NAT, поддержки паролей и ssh-ключей шаблонов VM (cloud-init), пользовательских данных. В нашем облаке он используется только для DHCP, прямой и обратной зоны DNS, поддержки паролей и ssh-ключей шаблонов VM (cloud-init), пользовательских данных. Данный компонент может быть отказоустойчивым, но в рамках нашего развертывания это не имеет большого смысла, поскольку ACS автоматически поднимает его при аварии и на функциональность это не влияет.
Если бы мы использовали продвинутые зоны с нетривиальными сетевыми функциями, то виртуальный маршрутизатор выполнял бы критическую роль. В общем, с виртуальным маршрутизатором в ACS 4.3 есть ряд проблем, часть из которых дожила до 4.9 и в 4.10 наконец-то должны быть внесены изменения, которые их решат. Первая проблема, которую мы обнаружили — проблема c DHCP сервером в Debian — он не выдает DHCP информацию из-за бага, который описан (например, здесь). Далее, у нас были проблемы с ротацией логов, из-за чего происходило переполнение файловой системы виртуального маршрутизатора и он переставал работать. В итоге, мы внесли в саму виртуальную машину существенное количество изменений, поправили скрипты, возможно сломали совместимость с другими функциями, но добились чтобы он работал как надо. В настоящее время мы выполняем перезагрузку данного компонента один раз в 1-2 месяца, поскольку облако находится на финальном этапе жизненного цикла, когда внесение изменений не имеет практического смысла. Стоит отметить, что для больших инфраструктур с десятками тысяч VM с виртуальным маршрутизатором имеются другие проблемы, например, описанная здесь. Я еще не проводил анализ того решена ли данная проблема в 4.10, но энтузиазм коммитеров на ее решение вроде высокий (в форке Cosmic она точно уже решена). Стоит отметить, что вместо виртуального маршрутизатора на базе Debian Linux можно использовать Juniper SRX, Citrix NetScaler. В настоящее время есть инициатива реализации виртуального маршрутизатора с использованием VyOS (думаю, что она не будет реализована, поскольку за ней не стоит серьезного игрока, которому это решение необходимо).
Сценарий задания правил iptables, ebtables на хосте виртуализации
При запуске виртуальной машины агент ACS, размещенный на хосте, выполняет конфигурирование правил iptables и ebtables, с помощью которых производится ограничение сетевых возможностей виртуальных машин (изменение MAC, присвоение чужих IP, нелегальные DHCP серверы). По непонятным причинам в ACS 4.3 данный сценарий не работал корректно — правила терялись, к машинам переставал идти трафик. Стоит отметить, что в текущем тестовом облаке ACS 4.9.2 эта проблема решена и не доставляет неудобств. В общем, мы переписали python-сценарий и добились его корректной работы. Касательно данной проблемы, есть подозрение, что в силу экспериментального режима развертывания мы “сломали” ACS, и из-за этого наблюдалось такое поведение, возможно, что при осознанном конфигурировании проблема бы не проявила себя.
Несколько первичных хранилищ NFS для одного кластера
Это просто эвристическое правило, которого мы стали придерживаться в итоге. Не используйте несколько хранилищ для одного кластера (кластер это иерархическая сущность ACS, которая объединяет несколько хостов виртуализации и хранилища и представляет собой способ выделения доменов отказа). В общем, пока мы использовали несколько хранилищ в рамках кластера, то стабильность нашего облака была ниже чем после объединения всех хранилищ в одно). В настоящий момент для всего облака мы используем большой сервер с программным RAID6 на SSD дисках Samsung Pro 850 и регулярным резервным копированием.
Интерфейс самообслуживания пользователя ACS
Интерфейс ACS достаточно консервативный и ориентирован на администраторов, а пользователя, который не использовал ранее комплексные инструменты администрирования VM, он однозначно пугает и требуется существенная работа по описанию его функций и способов выполнения различных задач. В этом смысле, интерфейсы, которые предоставляют AWS, DO и другие ведущие провайдеры сервисов , предоставляют пользователю лучший UX. Как итог, время от времени, служба поддержки вынуждена объяснять пользователю каким образом выполнить ту или иную нетривиальную операцию достаточно продолжительное время по телефону (например, как создать шаблон из выполняющейся VM).
Вместо заключения
Необходимо заметить, что в текущий момент это все проблемы, которые мы после трех лет эксплуатации можем идентифицировать как важные и оказавшие существенное влияние на качество сервиса. Конечно, были и другие, менее существенные проблемы, инциденты и ситуации, которые требовали вмешательства администраторов для их устранения.
В настоящее время мы планируем развертывание нового облака на 288 ядер Xeon E5-2670, 1536 GB RAM и 40 TB хранилища SSD с использованием ACS 4.10 (Basic Zones, Security Groups). Для того, чтобы предоставлять нашим пользователя более качественный сервис мы так же инициировали создание альтернативного интерфейса именно для такого развертывания, который создается как открытый продукт CloudStack-UI и учитывает тот опыт, который мы приобрели в результате эксплуатации текущего облака.
Автор: ivankudryavtsev
