Павел Одинцов, технический директор компании FastVPS Eesti OU
Мы занимаемся услугами по аренде виртуальных () и выделенных серверов уже почти 7 лет и поддерживаем сейчас более 170 тысяч сайтов наших клиентов. За это время мы успели пару раз сменить платформу виртуализации, попробовав и Xen, и OpenVZ, и Parallels Cloud Server, и в итоге остановились на PCS. Зачем мы меняли платформы, по каким параметрам их сравнивали, что нас в них радовало, а чем, прямо скажем, мы были недовольны – под катом.
Почти 6 лет назад мы одними из первых на рынке стали предлагать услуги аренды виртуальных серверов, и в качестве первичной VPS-платформы выбрали гипервизор Xen на базе Debian Etch 4.0, так как у нас уже был опыт работы с данным дистрибутивом, а ядро с поддержкой Xen имелось в официальном репозитории.
Шли годы, появлялись новые клиенты, и пропорционально росли вопросы к надежности и уровню изоляции платформы Xen. На нашем оборудовании в то время с неприятной регулярностью случались отказы (были серьезные проблемы с драйверами сетевых карт), что сильно мешало предоставлять качественную услугу нашим клиентам.
Помучавшись с год, мы попробовали перенести нескольких клиентов, которые особенно жаловались на падения Xen, на сервер с OpenVZ (почему не KVM? Очень просто — тогда он был на очень сыром уровне и не был рекомендован к промышленному использованию). Нашей радости не было предела. OpenVZ, основанный на превосходно протестированном ядре RHEL 5, показал себя с лучшей стороны — пропали проблемы с железом и повысилась скорость работы виртуальных серверов на том же оборудовании при аналогичной с Xen плотности размещения клиентов. О чем еще только может мечтать ?
Но мы продолжали расти, и для новых мощных тарифов нам потребовалась более быстрая и комплексная платформа, на роль которой OpenVZ уже не подходил по причине недостаточно высокой скорости работы при условиях очень больших ресурсов аппаратного сервера (особенно в случае NUMA-архитектур). В частности, в случае выделения 4-8 физических ядер на один виртуальный сервер на NUMA-архитектурах OpenVZ неоптимально распределяет виртуальные ядра по физическим NUMA-нодам, что выливается в серьезный провал производительности. Также был недостаточно высоким уровень изоляции ввода/вывода, что приводило к задержкам в работе файловой системы внутри . Устав от этих проблем, мы снова начали искать решение для виртуализации/контейнеризации.
Искали недолго: пообщались с Parallels, и они быстро уверили нас в том, что в их Parallels Cloud Server (старое название Virtuozzo) решены все эти проблемы, а также имеется еще огромное количество функций, которые были бы полезны и нам, и нашим пользователям.
Сначала пару слов о ядре системы — как PCS, так и OpenVZ используют ядро на базе RHEL 2.6.32, но различий между ними много. Ключевое же для нас отличие PCS от OpenVZ — в более высокой плотности размещения виртуальных серверов и их более качественной изоляции друг от друга.
Что хорошего есть в PCS по сравнению с OpenVZ
Раньше бывало, что один из контейнеров забивал журнал файловой системы, и из-за плохой изоляции файловых систем контейнеров это катастрофически влияло на производительность всех остальных контейнеров. В PCS (а также в свежих версиях OpenVZ) эта проблема решена файловой системой ploop. Суть её в том, что вместо одной файловой системы для всех контейнеров у каждого контейнера своя отдельная ФС. Это позволяет полностью избежать проблем, когда вся файловая система с данными контейнеров зависит от действий одного-единственного пользователя.
Второе улучшение мы получили за счет более эффективного использования памяти. Раньше платформа кешировала в ОЗУ все экземпляры идентичных файлов в разных контейнерах, например, десятки различных копий библиотек curl или libc кешировались отдельно для каждого контейнера. Это сильно забивало память. С PCS нам удалось высвободить около 15% ОЗУ с помощью механизма pfcache, который хитро кеширует файловый ввод/вывод и не загружает каждый раз новый экземпляр библиотеки, а вместо этого ставит ссылку на уже загруженную «соседом» область памяти. Это, конечно же, работает только в случае идентичности версий библиотек.
Ещё одна проблема, которую нам удалось побороть, — это плохая изоляция ввода-вывода между контейнерами. В OpenVZ мы часто сталкивались с тем, что из-за низкого уровня изоляции ввода-вывода в случаях, когда, например, один из контейнеров забивал очередь I/O работой с миллионами файлов, во всех остальных контейнерах на той же ноде ввод-вывод нещадно тормозил. В PCS это решено с помощью подсистемы ядра cgroups (в Parallels утверждают, что их специалисты принимали непосредственное участие в ее разработке), которая изолирует файловый ввод/вывод между контейнерами. Cgroups плюс собственная файловая система для каждого контейнера даёт идеальную (ну, почти) изоляцию виртуальных окружений. Как вы уже, наверное, поняли, журнал ФС теперь не один общий на все контейнеры, а отдельный для каждого контейнера.
Четвертая проблема была связана с тем, что пользователи много и часто обращались в поддержку с вопросами о том, как запустить сломавшийся по тем или иным причинам контейнер, а также с проблемами, когда контейнеру не хватало памяти или жесткого диска. В PCS мы вывели функции восстановления, доступ по VNC и утилиты для контроля состояния виртуальной машины непосредственно пользователям, так что они теперь сами могут делать то, чем раньше напрягали поддержку. В итоге у нас количество обращений по этим вопросам снизилось примерно на треть.
Ну и из «мелочей»:
Панель Power Panel нас порадовала, но не сказать, что поразила – ничего супер-инновационного, зато имеется полный комплект довольно удобных графических и консольных утилит для решения любых проблем без привлечения нашей поддержки. Новички, которые сталкивались с виртуализацией в первый раз, почти не обращались в поддержку при установке и управлении виртуальными машинами.
Система резервного копирования работает быстро, создает минимальную нагрузку на дисковую систему (за счет поддержки ploop снапшотов), а также имеет поддержку инкрементальных бэкапов (что, в свою очередь, очень сильно экономит нам дисковое пространство).
Чего в PCS нет, и как это пришлось решать нам самим
Теперь о том, на какие грабли мы наступили во время развертывания Parallel Cloud Server и какие мы придумывали способы, чтобы с ними справиться.
1. У панели централизованного управления (PVA MN) отсутствует API, и все операции нужно выполнять через веб-интерфейс или через API конкретных серверов.
Как боремся: Нам пришлось управлять созданием/саспендом/удалением напрямую через pva agent ноды, а также добавлять все ноды в pva management node для реализации функций уровня всей инсталляции (миграции в первую очередь). В Parallels нам уже пообещали реализовать эту функцию в одном из ближайших релизов, подождем и посмотрим, что получится.
2. Нет возможности сменить OS без удаления и создания его заново. Это крайне проблемная особенность, в корне конфликтующая с сущностью услуги предоставления . Клиенты очень часто меняют операционки с одной на другую, и отсутствие подобной функции в Power Panel серьезно повышает нагрузку на нашу поддержку.
Как боремся: Сейчас для смены ОС клиенту требуется написать в нашу поддержку, она, в свою очередь, инициирует удаление контейнера на сервере, корректирует ОС и устанавливает контейнер повторно. В общем, далеко не удобный вариант, и времени это занимает около 15-20 минут.
Ребята из Parallels обещали нам сделать возможность оставлять ID при пересоздании контейнера, что решит большую часть проблем с совместимостью (но не все).
3. Отсутствие поддержки шейпинга входящего трафика и крайне нестабильная работа текущего cbq-шейпера исходящего трафика. Это сводит на нет возможность максимально плотного размещения маломощных контейнеров на ноде — мелкий клиент может выгрузить гигабитный канал. Шейпер для нас, безусловно, мега-критичный, так как это ограничивает нас в возможностях создания новых тарифных планов.
Как боремся: В качестве временного решения используется наш собственный скрипт на базе шейпера tc/htb, который в принципе работает приемлемо, но управлять им в обход API PCS довольно затруднительно. Поэтому шейпер от Parallels хотелось бы получить в числе первых и как можно скорее.
Наш скрипт для тех, кому это необходимо
4. Отсутствие курсов/русскоязычной документации — тут в первую очередь проблема с документацией для клиентов и сотрудников нашей поддержки.
Как боремся: Ну, у нас администраторы бывалые, разумеется, проблем с английским и навыками установки и настройки не возникало. А вот клиентам пришлось помогать, соответственно, есть лишняя нагрузка на поддержку.
5. Очень сложная система сборки шаблонов на базе вручную настроенного контейнера. Часто нужно настроить контейнер вручную и потом на его базе создавать остальные. Сейчас это можно сделать двумя способами: либо через шаблоны EZ Template, но в этом случае нельзя заложить в контейнер сложные сценарии. Если нужен какой-то сложный контейнер, приходится клонировать его вручную, а это реализовано неудобно и работает только в пределах одного сервера.
Как боремся: Сейчас реализуем через существующий совершенно не интуитивный механизм. Хотелось бы иметь возможность создавать библиотеку образов типовых контейнеров.
6. Набор шаблонов приложений для Linux OS сейчас очень скуден и не покрывает даже базовых потребностей пользователей. Из-за этого у нас много запросов клиентов на установку дополнительного ПО (например, memcached, redis, openvpn).
Как боремся: Запросы решаются вручную силами технической поддержки.
7. Отсутствуют примеры работы с API Агента на нескольких языках программирования. В идеале вообще хотелось бы готовую библиотеку-обвязки.
8. Нет возможности лицензирования не только на уровне отдельного сервера, но и сразу для всего кластера серверов.
Как боремся по пунктам 7-8: Тут понятно, пока работаем с тем, что есть.
9. Хотелось бы больше внимания к ускорению локальных дисковых хранилищ (например, за счет SSD-кэширования). Мы планируем решить эту проблему за счет внедрения стораджевого решения, возможно, даже Parallels Cloud Storage.
Как боремся: В данный момент используются довольно дорогие, но локальные хранилища на базе RAID 10.
Все эти вопросы и пожелания мы уже передали в Parallels.
Немного о том, как шел процесс внедрения PCS
Мы использовали решения от Dell, основа для работы наших серверов — PowerEDGE 720 на базе Intel Xeon в двухпроцессорной конфигурации с дисковой подсистемой на базе SAS жестких дисков.
Мы решили отдельно остановиться на обеспечении отказоустойчивости аппаратных ферм и поэтому выделили этот этап. Начали мы с пункта, который доставлял нам множество проблем в прошлом – памяти. Ошибки памяти при условиях очень большого объема ОЗУ на сервере (64Gb +) – очень частое явление, и поэтому мы выбрали конфигурацию с контролем четности. В дисковой подсистеме использовали проверенное годами решение на базе RAID-10 с кэшированием чтений и записи (конечно же, с BBU). Оптимизация сетевой подсистемы заключается в установке двух отдельных сетевых контроллеров и подключении их к разным свитчам посредством технологии агрегации каналов, чтобы избежать даунтайма в случае отказа одного из свитчей или сетевых карт.
Когда была готова аппаратная платформа, приступили к развертыванию PCS на нашем оборудовании. Ребята из Parallels специально для тестов дали нам большое количество триал лицензий и обеспечили тесное взаимодействие с техническими специалистами, что очень сильно упростило работы по внедрению. Сама процедура установки мало отличается от интерактивной установки CentOS 6 и прошла без каких-либо сложностей (разумеется, имеется возможность установки через PXE, которой мы пользуемся для развертывания новых серверов).
Сама система PCS — это множество компонентов, которые можно поставить на один сервер или распределить на несколько серверов. Основной компонент здесь — Parallels Agent (устанавливается непосредственно на аппаратную часть сервера и представляет собой API для управления виртуальными контейнерами, но не имеет графического интерфейса). Для визуального управления используется отдельный компонент (ставится как контейнер) — Parallels Management Node (PVA MN), который требуется поставить лишь один раз, и уже после этого он может управлять любым количеством серверов c Parallels Agent (PA). То есть можно разместить ноду управления на одном сервере с клиентскими контейнерами, а можно вынести ее на отдельный сервер. Мы крупные хостеры, нам удобнее и надёжнее было поставить PA и PVA MN на разные сервера, а небольшие компании могут ставить оба компонента на один сервер.
В данный момент PCS уже почти 4 месяца находится в промышленной эксплуатации, и мы, несмотря на замечания, им довольны, так как работает главное:
— Плотность контейнеров получилась больше, чем на OpenVZ и других платформах
— Доступность контейнеров выше за счет лучшей изоляции ФС и ввода-вывода
— Экономим ОЗУ и дисковое пространство
— Ежедневное инкрементальное копирование – данные клиентов в безопасности, дискового пространства тратится меньше
— Мы тратим меньше времени на обслуживание серверов, так как PCS почти не требует присмотра за ним
— Сократилось количество обращений в поддержку
— Мы можем создавать новые и новые тарифы с большим объемом памяти, диска и процессорных мощностей
— Клиенты довольны. :-)
Если у вас есть вопросы – пишите в комментариях.
Автор: holymay
