Компания
272,03
рейтинг
19 августа 2013 в 15:07

Разное → FastVPS: Как мы меняли платформы виртуализации

Павел Одинцов, технический директор компании FastVPS Eesti OU

Мы занимаемся услугами по аренде виртуальных (VPS) и выделенных серверов уже почти 7 лет и поддерживаем сейчас более 170 тысяч сайтов наших клиентов. За это время мы успели пару раз сменить платформу виртуализации, попробовав и Xen, и OpenVZ, и Parallels Cloud Server, и в итоге остановились на PCS. Зачем мы меняли платформы, по каким параметрам их сравнивали, что нас в них радовало, а чем, прямо скажем, мы были недовольны – под катом.
image

Почти 6 лет назад мы одними из первых на рынке стали предлагать услуги аренды виртуальных серверов, и в качестве первичной VPS-платформы выбрали гипервизор Xen на базе Debian Etch 4.0, так как у нас уже был опыт работы с данным дистрибутивом, а ядро с поддержкой Xen имелось в официальном репозитории.

Шли годы, появлялись новые клиенты, и пропорционально росли вопросы к надежности и уровню изоляции платформы Xen. На нашем оборудовании в то время с неприятной регулярностью случались отказы (были серьезные проблемы с драйверами сетевых карт), что сильно мешало предоставлять качественную услугу нашим клиентам.

Помучавшись с год, мы попробовали перенести нескольких клиентов, которые особенно жаловались на падения Xen, на сервер с OpenVZ (почему не KVM? Очень просто — тогда он был на очень сыром уровне и не был рекомендован к промышленному использованию). Нашей радости не было предела. OpenVZ, основанный на превосходно протестированном ядре RHEL 5, показал себя с лучшей стороны — пропали проблемы с железом и повысилась скорость работы виртуальных серверов на том же оборудовании при аналогичной с Xen плотности размещения клиентов. О чем еще только может мечтать хостинг-провайдер?

Но мы продолжали расти, и для новых мощных тарифов нам потребовалась более быстрая и комплексная платформа, на роль которой OpenVZ уже не подходил по причине недостаточно высокой скорости работы при условиях очень больших ресурсов аппаратного сервера (особенно в случае NUMA-архитектур). В частности, в случае выделения 4-8 физических ядер на один виртуальный сервер на NUMA-архитектурах OpenVZ неоптимально распределяет виртуальные ядра по физическим NUMA-нодам, что выливается в серьезный провал производительности. Также был недостаточно высоким уровень изоляции ввода/вывода, что приводило к задержкам в работе файловой системы внутри VPS. Устав от этих проблем, мы снова начали искать решение для виртуализации/контейнеризации.

Искали недолго: пообщались с Parallels, и они быстро уверили нас в том, что в их Parallels Cloud Server решены все эти проблемы, а также имеется еще огромное количество функций, которые были бы полезны и нам, и нашим пользователям.

Сначала пару слов о ядре системы — как 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 конкретных серверов.
Как боремся: Нам пришлось управлять созданием/саспендом/удалением VPS напрямую через pva agent ноды, а также добавлять все ноды в pva management node для реализации функций уровня всей инсталляции (миграции в первую очередь). В Parallels нам уже пообещали реализовать эту функцию в одном из ближайших релизов, подождем и посмотрим, что получится.

2. Нет возможности сменить OS без удаления VPS и создания его заново. Это крайне проблемная особенность, в корне конфликтующая с сущностью услуги предоставления VPS. Клиенты очень часто меняют операционки с одной на другую, и отсутствие подобной функции в Power Panel серьезно повышает нагрузку на нашу поддержку.
Как боремся: Сейчас для смены ОС клиенту требуется написать в нашу поддержку, она, в свою очередь, инициирует удаление контейнера на сервере, корректирует ОС и устанавливает контейнер повторно. В общем, далеко не удобный вариант, и времени это занимает около 15-20 минут.
Ребята из Parallels обещали нам сделать возможность оставлять ID при пересоздании контейнера, что решит большую часть проблем с совместимостью (но не все).

3. Отсутствие поддержки шейпинга входящего трафика и крайне нестабильная работа текущего cbq-шейпера исходящего трафика. Это сводит на нет возможность максимально плотного размещения маломощных контейнеров на ноде — мелкий клиент может выгрузить гигабитный канал. Шейпер для нас, безусловно, мега-критичный, так как это ограничивает нас в возможностях создания новых тарифных планов.
Как боремся: В качестве временного решения используется наш собственный скрипт на базе шейпера tc/htb, который в принципе работает приемлемо, но управлять им в обход API PCS довольно затруднительно. Поэтому шейпер от Parallels хотелось бы получить в числе первых и как можно скорее.

image
Наш скрипт для тех, кому это необходимо

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 жестких дисков.
image

Мы решили отдельно остановиться на обеспечении отказоустойчивости аппаратных ферм и поэтому выделили этот этап. Начали мы с пункта, который доставлял нам множество проблем в прошлом – памяти. Ошибки памяти при условиях очень большого объема ОЗУ на сервере (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
Parallels
рейтинг 272,03

Комментарии (90)

  • +12
    То есть сервера на зене висли, а на openvz проблемы магически прошли? Что-то как-то странно написано. Вообще, миграция с Xen на контейнеры как средство повышения стабильности вызывает острый скепсис, особенно в свете того, что и в PCS, и в OpenVZ злой гость может попортить нервы администратору bind'ами файловой системы немеряно.
    • +5
      Упомянутый Вами баг-фича с mount bind решен уже месяц с лишним назад: wiki.openvz.org/Download/kernel/rhel6-testing/042stab079.4 да и на практике мы ни разу не видели его эксплуатации.
      • +1
        ок, молодцы, закрыли. Мне для того, чтобы его самому найти понадобилось пол-часа на VDS'ке под openvz.

        Повторю вопрос: вы про стабильность openvz по сравнению с xen'ом серьёзно? Не хотите соревнование устроить? Правила простые: по сети на невинные узлы не гадить (то есть specially crafted traffic пожалуйста — он же на соседей — нет), ограничться 30-50 мегабитами максимум.

        Каждый предоставляет соседу контейнер/виртуалку и даёт возможность попытаться попортить жизнь администратору хоста/соседям. Разумеется, хосты в этом случае лабораторные.

        Как вы думаете, у кого больше шансов попортить жизнь соседям — у root'а в openvz или у root'а в xen'е?

        Количество постоянно добавляемых beacon в openvz позволяет легко апроксимировать число «неучтённых» тонких мест в изоляции. Как в этих условиях можно говорить про большую стабильность — не понимаю.
        • +5
          Про стабильность мы абсолютно серьезно Случаев, когда клиент виртуального сервера выводил из строя сервер целиком — единицы за последний год (да и-то это бал лишь небольшая деградация производительности, а не отказ). Не буду отрицать — это случается, но это настолько экзотические стечения обстоятельств, которые довольно сложно воспроизвести в лабораторных условиях, что я не вижу совершенно никаких поводов для беспокойства.

          А по поводу недочетов в системе изоляции — найдите еще и мы с радостью их починим с инженерами Parallels :)

          По поводу тестов — это Вам скорее к Parallels, а не к нам, у них чудесная Test Team, которая как раз отрабатывает ситуации «а давайте замучаем этот контейнер» :)
          • +3
            Я вполне допускаю, что кто-то бегает и латает. Однако, я хочу ещё раз сделать упор на то, что говорить «xen менее стабилен, чем openvz», мягко говоря, не корректно. Изоляция openvz весьма тонкая и на фоне весьма раздражающей, но очень ясной модели разделения ресурсов xen'а не выглядит.
        • +2
          Обратите внимание что речь идет про Xen на Debian Etch. А это должно было быть 2007-2008 год. Тогда у Xen'а действительно были проблемы со стабильностью. И тогда в какой-то момент код Xen'а даже выкинули из ядра… Обратно Xen в ванильное ядро приняли совсем недавно, перед самой сменой нумерации версий Linux на 3.х, если мне не изменяет память.

          Тогда проблемы были с этим…

          В статье много других вещей смущает. Про изоляцию ввода/вывода например. Индивидуальная файловая система для каждого контейнера — хорошая идея. Но проблему с производительностью подсистемы ввода вывода она решить не может…
          Как-то у автора запросто получается сравнивать принципиально разные технологии: контейнеры с гипервизорами.

          Кстати, вопрос: Какой гипервизор используется PCS? Уж не Xen ли случаем?
          • 0
            Так она и не должна решать проблемы с производительностью ввода вывода непосредственно, она решает лишь проблемы, когда много-много мелких изменений коммитятся в журнал от одного контейнера и мешают жить остальным. Разумеется, если дисковая сама по себе медленная — это никто и никак решить не может, только его величество апгрейд :)

            Насколько я знаю, гипервизор используется собственной разработки Parallels, но тут могу нагло врать, так как мы работаем исключительно с контейнерами.
            • 0
              Возможно я туплю. А что означает фраза
              Нет возможности сменить OS без удаления VPS
              на контейнере?
              • 0
                Ага, примерно так и понимать. Чтобы сделать замену ОС в VPS с Debian на CentOS нужно удалить контейнер полностью и создать вновь. Ну очень неприятная фича, всем штатом бесимся, когда делаем! :)
          • 0
            Насколько я знаю (я не спец) там контейнеры, коммерческая версия openvz с приватной панелькой.

            Последний раз когда меня в него пустили, я сделал -300Гб (на 300Гб меньше, чем 0) свободного места. Мне сказали «там криво настроено» и на этом всё слегка заглохло, а дальше было лениво смотреть.
            • 0
              Боюсь, такое было возможно только в vzfs, да, она бесилась временами и сходила с ума (за что скоро станет deprecated). Но в ploop как ни финти — за квоту не вылезти.
            • 0
              Уточню сам себя. PCS — это не только контейнеры (openvz), но и полноценный гипервизор с характеристиками на уровне KVM. И да — из одного интерфейса можно создавать и контейнер и виртуальные машины. Например, легко дружится FreeBSD/Solaris в VM и Linux в контейнере.
              • 0
                Хаха, смешно, когда «характеристики на уровне KVM» достигаются использованием [чуть пиленого?] QEMU/KVM.
                • 0
                  А можно поподробнее и попредметнее? :)
                  • –1
                    Поподробнее и попредметнее будет в вашем сообщении вместо фразы «но и полноценный гипервизор с характеристиками на уровне KVM» написать «но и полноценный гипервизор, основанный на QEMU/KVM».

                    А то получается, что это вроде как гипервизор собственной разработки, который круче, чем горы, яйца и KVM, а на деле это тот же самый QEMU/KVM. Ну, примерно как BolgenOS и Ubuntu.
                    • 0
                      Прочтите уже описание продукта www.parallels.com/products/server/baremetal/sp/whatsnew/ и не несите околесицу про «копипасту qemu/kvm». Это самостоятельный продукт, не имеющий никакого отношения к KVM и Qemu в целом и уже долгое время работающий в продакшене.
                      • –1
                        image

                        А вот что говорят нам факты:
                        [root@server ~]# lscpu
                        Architecture: x86_64
                        CPU op-mode(s): 32-bit, 64-bit
                        Byte Order: Little Endian
                        CPU(s): 1
                        On-line CPU(s) list: 0
                        Thread(s) per core: 1
                        Core(s) per socket: 1
                        Socket(s): 1
                        NUMA node(s): 1
                        Vendor ID: GenuineIntel
                        CPU family: 6
                        Model: 45
                        Stepping: 7
                        CPU MHz: 2299.000
                        BogoMIPS: 4598.00
                        Hypervisor vendor: KVM
                        Virtualization type: full
                        L1d cache: 32K
                        L1i cache: 32K
                        L2 cache: 256K
                        L3 cache: 15360K
                        NUMA node0 CPU(s): 0

                        Я не очень понимаю зачем вы тут дискутируете и портите себе репутацию непрофессиональными комментариями, поскольку этот вопрос (какой тип виртуализации используется) напрямую не затрагивает ваши интересы. Но факт, что используется KVM-виртуализация, что и требовалось доказать.

                        Не вижу в этом ничего плохого, KVM — отличный инструмент, лицензия GPL позволяет делать с ним что угодно, но как то более на мой взгляд правильно что ли было бы упоминать в доках о том, что используется этот тип виртуализации. Ну так, чисто из уважения к комьюнити, и чтобы казусов не было, когда партнер с пеной у рта доказывает что KVM ни причем, а KVM-то — вот он ;)
                        • +1
                          Ничего личного — мы просто стремимся к торжеству истины :) Ведь как мы можем рекомендовать или использовать для пользователей продукт, который не знаем и за который не стоим горой?

                          Ваши доводы может быть и верны, в какой-то мере. Пока эта мера в том, что lscpu — бажен :)

                          Если верить lscpu (к слову, это весьма странная тулза) то да, это, безусловно KVM:
                          sudo lscpu
                          Architecture: x86_64
                          CPU op-mode(s): 64-bit
                          CPU(s): 1
                          Thread(s) per core: 1
                          Core(s) per socket: 1
                          CPU socket(s): 1
                          NUMA node(s): 1
                          Vendor ID: GenuineIntel
                          CPU family: 6
                          Model: 26
                          Stepping: 5
                          CPU MHz: 3074.000
                          Hypervisor vendor: KVM
                          Virtualization type: full
                          L1d cache: 32K
                          L1i cache: 32K
                          L2 cache: 256K
                          L3 cache: 8192K

                          Если же посмотреть на cpuinfo, он не имеет ни малейшего повода для похожести на KVM:
                          cat /proc/cpuinfo
                          processor: 0
                          vendor_id: GenuineIntel
                          cpu family: 6
                          model: 26
                          model name: Intel® Core(TM) i7 CPU 950 @ 3.07GHz
                          stepping: 5
                          cpu MHz: 3074.000
                          cache size: 8192 KB
                          fpu: yes
                          fpu_exception: yes
                          cpuid level: 11
                          wp: yes
                          flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc up arch_perfmon rep_good nonstop_tsc pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt hypervisor lahf_lm ida arat
                          bogomips: 6148.00
                          clflush size: 64
                          cache_alignment: 64
                          address sizes: 36 bits physical, 48 bits virtual
                          power management:

                          Для сравнения KVM выглядит так:
                          cat /proc/cpuinfo
                          processor: 0
                          vendor_id: GenuineIntel
                          cpu family: 6
                          model: 13
                          model name: QEMU Virtual CPU version (cpu64-rhel6)
                          stepping: 3
                          cpu MHz: 3392.292
                          cache size: 4096 KB
                          fpu: yes
                          fpu_exception: yes
                          cpuid level: 4
                          wp: yes
                          flags: fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm up rep_good pni cx16 hypervisor lahf_lm
                          bogomips: 6784.58
                          clflush size: 64
                          cache_alignment: 64
                          address sizes: 36 bits physical, 48 bits virtual
                          power management:

                          А если верить родной утилите от производителя KVM (RedHat), virt-what то это — bare metal (случай, когда скрипт не выводит ничего), то есть вообще физическое железо, как же он не признал KVM-то?

                          Надеюсь, сейчас сомнений в том, что это не KVM? =)

                          Как последний киллер довод приведу то, что этот же самый гипервизор работает на Mac OS () и виртулизирует все, что пожелает душа. KVM такого не умеет.
                          • +1
                            Я слышал, что у Parallels есть наработки для виртуализации ОС и для windows.
                          • 0
                            Первое достигается -model host или -model <одна из предефайненных моделей> в qemu.
          • +2
            Аргумент про этч принимается. 2.6.26 — это было легендарное ядро.
    • +2
      Это было не вчера, а несколько лет назад. И тогда у Xen'а действительно были проблемы с надёжностью.
  • +1
    Спасибо, интересный опыт.
    А OpenVZ контейнеры на разных ФС в LVM сделать нельзя, это не решит проблему с очередью ФС?
    • +2
      В принципе, можно, конечно же. Но это довольно сложно поддерживать, так как придется делать следующее: lvcreate (создаем раздел), mkfs.ext4 (создаем на нем ФС), mount (монтируем). После этого через опцию ve_root у утилиты vzctl можно создать контейнер где душа пожелает.

      В принципе, на первый взгляд это не так сложно, но на практике — надо будет потом менять размер ФС (как в сторону увеличения, так и в сторону уменьшения), выполнять проверки диска и многое другое. Технология ploop делает в своей сути тоже самое (чисто для себя ploop где-то рядом с LVM, но чуточку иной), но красиво и без привлечения сторонних утилит.
      • +1
        Или берем xcp и даже не думаем об этом, все работает из коробки ;)
        • +1
          xcp больше нет, следующая версия для xcp 1.6 -> Xenserver 6.2. Он теперь опенсорсный, кроме нескольких проприентарных компонент, без которых он всё равно работает.

          И если вы надеетесь, что оно «из коробки всё работает и надёжно и под хайлоадом» — разочарую. Его нужно много и тщательно окучивать.
          • 0
            Ну да, это понятно.
        • 0
          Ой далеко там все раньше было из коробки(ну или было но работало неожиданно), и много вы развернули xcp хотя бы на тысячу виртуалок?
          • +1
            В xcp 1.1, было практически все, что необходимо. XCP 1.6 добавили много нового/открыли, и стало все еще лучше. В xcp есть одна беда — это если очень активно использовать снапшоты, могут появиться проблемы. И да, баги есть везде. Да.
            • 0
              А что значит очень активно использовать? Ну скажем ежедневный бекап?
              Желательно бы ещё и инкрементальный.
              • 0
                Если вы читали посты селектела, почему они отказались от снапшотов, там amarao рассказывал, какие есть проблемы. XCP очень плохо следит за зависимостями и связностью снапшотов, и из за этого возникают проблемы. Очень активно, это если постоянно восстаналиваться со снапшота и делать снапшот снапшота, очень часто и очень много. А так там есть cow.
  • +6
    Спасибо за подробный отчет!
  • +1
    Черт, а Амазон-то не знает! Надо бы рассказать. :) Чего-то мне слабо верится, что проблемы с дровами сетевой карточки — это именно проблемы XEN-а. Может, просто производитель заточил дрова под RHEL и всё?

    P.S. Использую XEN с 3-й версии, проблемы были, но всё решаемо.
    • +3
      Разумеется, все решаемо, но в те стародавние времена, к сожалению, у нас не было ресурсов для исправления проблем драйверов.

      Но дабы быть совсем честными — в те времена Amazon услуги такой еще не предоставлял, это было где-то около 2005 года, а Amazon EC2 был тестово запущен лишь в 2006 году.
    • +1
      У амазона вообще не особо то и xen, они же его переписали более чем под себя. От ванильного ксена я думаю они довольно далеко.
  • +1
    Короче, PCS костыль ;) Вы смотрели, например XCP?
    • +1
      Почему костыль? PCS — это примерно тоже самое, что XCP, но не на базе Xen, а на базе OpenVZ ;)
      • +2
        PCS, совсем далеко до XCP, очень далеко. Особенно в свете того, что xenserver будет бесплатным. Посмотрите на список фич xenserver и список того, что предоставляет PCS.
        • 0
          Давайте будем конкретны :) Что умеет XCP и чего не умеет PCS?

          Из ключевых фич PCS:
          Лайв миграция
          Бэкапы/инкрементальные бэкапы
          Централизованное хранилище
          HA

          Что кроме этого умеет XCP, чего ен умеет PCS?
          • +1
            Да хотя бы размещать файлы клиентов на lvm, а не в файле? Все ключивые фичи, которые вы указали, давно есть в xcp и проверено в xenserver. Так же, не знаю, поправили или нет, 1 виртуалка в openvz может полностью загрузить хост ноду.

            Централизованное хранилище, это не заслуга PCS, так как он просто оперирует файлами, так что просто mount nfs://…

            Так же, сама система виртуализации: нормальная vs расширенный чрут.

            Вам openvz видимо нравится вот по этой причине:
            Плотность контейнеров получилась больше, чем на OpenVZ и других платформах
            Экономим ОЗУ и дисковое пространство

            ?

            Если уж оверселить, с той же памятью, можно например взять — www.redhat.com/products/cloud-computing/virtualization/, если я ничего не путаю, в kvm из коробки можно оверселить память. И это на нормальном гипервизоре.

            Можно понять, когда люди используют контейнеры для разработки, такое может быть удобно. Но когда начинают использовать для предоставления массовых услуг, как-то не понятно эта мотивация.

            Много времени прошло с debian 4, и выбирая сейчас, отталкиваться от совсем старого опыта, как-то странно.
            • 0
              «Да хотя бы размещать файлы клиентов на lvm, а не в файле» — прочтите про ploop openvz.org/Ploop, это не совсем «ФС в файле», это полноценный менеджер логических устройств поверх файлов.

              «Централизованное хранилище, это не заслуга PCS, так как он просто оперирует файлами, так что просто mount nfs://…» — я боюсь, что аналоги продукта Parallels Cloud Storage могут предложить разве что Google да Amazon да и-то в весьма ограниченном виде. Попробуйте, это реально круто, ничего общего с NFS и прочими SAN/NAS!

              Ну оверселлить можно и в Xen и в KVM и даже на уровне железа и переносить недобросовестность оператора на технологию — совсем не хорошо :)

              А Debian у нас нету давно на нодах, мы не отталкиваемся :)
              • 0
                Google да Amazon? Да и-то в весьма ограниченном виде? Это могло быть правдой лет 5 назад, но сейчас это полная, некомпетентная и беспросветная херня :) Распределенных отказоустойчивых СХД есть вагон и маленькая тележка. В качестве ликбеза почитайте здесь. Там распределенные СХД перечислены на любой вкус, отказоустойчивые и обыкновенные, свободные и проприетарные, платные и бесплатные, ядерные и юзерспейсные, с поддержкой QEMU/Xen и прочего.
                • +1
                  Даже сильные мира сего при работе с _распределенными_ ФС зачастую либо покупают компании, которые их разрабатывали или перехватывают разработчиков и это не «для красивой строки в разделе о компании», а совершенно оправданная цена — сложность таких ФС зашкаливает и возможность их внедрения без наличия специалистов (я не говорю про людей, которые три раза ставили ее на «тестовой ферме» и прочли две публикации на хабре, а про тех, кто досконально знает, как и в каком случае поведет себя определенная ФС) — процесс крайне чреватый полной потерей данных.

                  Ну и да — прочтите уж тех спецификацию на Parallels Cloud Storage — www.parallels.com/products/pcs/cloud-storage/. Это не пиар, мы его пока не используем, но это реально крутое и очень технологичное решение.
                  • 0
                    Ну зачем переводить вопрос в плоскость стоимости внедрения. Было утверждение, что аналог могут предложить в ограниченном виде только Amazon и Google. Вот это утвеждение ложно. Прямо здесь на хабре есть примеры использования Ceph, GlusterFS, GPFS в том числе от уважаемых компаний. Это если говорить о кластерных СХД, не говоря про shared СХД, среди которых например Нексента и прочие. Как итог задачи миграции / снимки / избыточность уже решаются кучей разных продуктов, причем решаются уже сейчас, вот прямо на практике, в продакшене. В отличие от Parallels Cloud Storage, который непонятно использует ли кто-то вообще в продакшене или нет. Спецификация — это ок, но пока нет реальных деплойментов она, что называется, doesn't make sense. Так что это все таки пиар.

                    Безусловно, у этого продукта есть большое практическое преимущество — врожденная интеграция с контейнерами. Именно о нем и стоит писать, чтобы не получать негатив.
                    • 0
                      Как же не переходить в плоскость внедрения, если мы сейчас обсуждаем комментарии к статье про опыт реального внедрения? :)

                      Безусловно, Вы правы, что есть и иные подходы и иные продукты и множество компаний оказывающих поддержку, но из всего того что я видел — Parallels Storage по нашим тестам мне нравится больше всего.

                      В том и дело, что интеграция с контейнерами там лишь подфича, никто не запрещает создать на сторадже свой видео архив, например, правда, нужно учитывать, что это не Posix файловая система.

                      Обращаю внимание, что при желании на Parallels Storage можно запустить OpenVZ, например, или KVM (тут даже не потребуется правка драйверов).
            • +2
              Так же, не знаю, поправили или нет, 1 виртуалка в openvz может полностью загрузить хост ноду.


              В OpenVZ довольно грамотный CPU scheduler. При этом, если CPU limits не выставлены и больше никто ничего не делает, то почему бы и не полностью загрузить хост? Если хотите организовать вариант «собака на сене» (пусть лучше CPU будет простаивать, но виртуалке не давать больше N%) — пожалуйста, используйте CPU limits. В противном случае есть cpu units, когда у каждого контейнера (и у хоста) есть свой вес, и шедалер раздаёт всем кванты пропорционально их весам. Можно, конечно, использовать и units, и limits, плюс к тому vcpu (ограничение по кол-ву процессорных ядер) и cpu affinity (привязка конкретных контейнеров к конкретным ядрам). Мне кажется, это практически все варианты покрывает. Или вы что-то другое имели в виду?

              • 0
                Я говорю про веса, они вообще не работали на последней версии openvz 1 год назад. Имеем 40 виртуальных машин, все с разными весами, контейнер с самым маленьким приоритетом может загрузить весь cpu на хост ноде, когда он нужен остальным.
                • 0
                  Веса абсолютно точно работают как миниум 3+ года. Что в ядрах 2.6.18, что в ядрах 2.6.32. Без этого никто бы не выпустил коммерческий продукт :)
                • 0
                  Впервые про такое слышу. Если не трудно, ткните меня носом в багзиллу.
            • +1
              «Централизованное хранилище» — не совсем корректный термин. Имеется в виду не NFS или там какой-нибудь SAN/NAS, а кластерная распределённая файловая система Parallels Cloud Storage, которая входит в состав Parallels Cloud Server. Её смысл вкратце такой — дисковое пространство всех нод сливается в один кластер, на котором и лежат контейнеры. Там, конечно, есть и избыточность, подобная RAID-ам, и локальность данных, и (что особенно важно) высокая скорость. Можно посмотреть доклад Кирилла Коротаева на YAC2012 — video.yandex.ru/users/ya-events/view/813/user-tag/yac%202012/
          • 0
            Так же, хочу извиниться, что влез в обсуждения, с такими комментариями, все же это не правильно.
          • 0
            Сколько из перечисленных фич уже работают у вас в продакшене? Вот чтобы прямо сейчас можно было прийти и воспользоваться.
            Централизованное хранилище (Parallels Cloud Storage), живая миграция уже в строю?
            • 0
              Это все в строю уже по меньшей мере год. Вообще все и лайв миграция и клауд сторадж. А в последнем релизе месяц назад и поддержка HA приехала :)
              • 0
                А здесь вы пишете что еще не используете. Таки да или нет?
                habrahabr.ru/company/parallels/blog/190524/#comment_6627942
                • 0
                  Хранилище мы не используем в продакшене, но у нас есть крупная тест-инсталляция с ним, которую мы уже почти месяц очень тщательно изучаем в разных ситуациях. Лайв миграция есть и с Parallels Storage и без него (ну и, к слову, она есть даже в openvz и очень даже неплохая), она работает в обоих случаях и уже используется нами (да — для клиентов, да — в продакшене).
  • 0
    А VMWare как вариант рассматривался?
    • +2
      Да, разумеется рассматривали, но вышло очень дорого в расчете на 1 виртуальный сервер :(
  • +1
    Зря не используете в шейпере хэш-таблицы для фильтров.
    • +1
      А можно поподробнее? Можно в ЛС.
      • +4
        Там ничего особенного в целом. Но выигрыш в производительности может быть колоссальным. Грубо говоря, потребление процессора перестает зависеть от числа фильтров.
        Первоисточник тут lartc.org/howto/lartc.adv-filter.hashing.html
        • 0
          Спасибо, не слышал про такой вариант. Но как быть, когда у нас идут сплошняком IP из блоков 159.253.X.X и 5.9.X.X? Тут уже не похешируешь по последнему октету :(
          • +4
            В принципе ничто не мешает и по двум последним октетам хэшировать.
            В «hashing» фильтре hashkey mask 0x0000ffff at 12 link 2:
            и потом в «рядовых» фильтрах например ht 2:c22: для x.x.12.34.
            Или как в примере в той статье. Там 4 /24 сети описываются.
            • 0
              Круто, спасибо, создал тикет на доработку шейпера :) Если сделаем — обязательно выложим как дополнительную опцию
  • 0
    В OpenVZ, насколько я понимаю, есть проблема при создании бэкапа со стороны пользователя. Я так и не разобрался, как его можно сделать. Хотелось бы что-то простое, типа
    dd if=/dev/sda1 of=/backup.img
    А в вашей системе виртуализации с этим как?
    • 0
      Проблемы в целом никакой нету, что в OpenVZ, что в PCS (что в ploop, что в vzfs). Конкретно у нас бэкап делается ежесуточно и доступен в панели управления.
    • +1
      «Со стороны пользователя» — это значит «внутри контейнера»? Если так, то при использовании OpenVZ на ploop dd if=/dev/sda1 of=/backup.img изнутри контейнера вы сделать сможете (только девайс будет называться /dev/ploopNNNp1), но проблема в том, что /backup.img будет лежать на том же девайсе.

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

      По поводу бекапа на openvz в целом. Если не использовать ploop (файловая система в файле), то с точки зрения хоста контейнер — это просто каталог (какой-нибудь /vz/private/12345), его и надо бекапить. Если использовать ploop, то можно сделать очень изящные инкрементальные бекапы на блочном уровне с использованием ploop snapshots. Кое-что на эту тему тут openvz.org/Ploop
      • 0
        Спасибо. К сожалению у меня это именно каталог:
        /vz/private/3377 on / type simfs (rw,relatime,usrquota,grpquota)
        Просто меня настолько удивила разница между VirtualBox'ом и VPS на основе OpenVZ(отсутствие /dev/sd* /dev/hd*),
        что очень захотелось услышать, что в PCS — виртуальный жесткий диск выглядит именно как виртуальный жесткий диск)
        • 0
          На ploop это дело выглядит примерно вот так:
          cat /proc/mounts /dev/ploop38074p1 / ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group 0 0

          Но если быть полностью честным — это полноценная ФС лишь на уровне аппаратной ноды, из контейнера подкрутить настройки ext4 или, например, сделать рисайз (хотя бы в меньшую сторону) не выйдет.

          Тоже самое касается бэкапа.

          k001, а реально ли из контейнера получить доступ на чтение блочного имаджа или это на грани фантастики?
          • 0
            а реально ли из контейнера получить доступ на чтение блочного имаджа или это на грани фантастики?


            Да, как обычно, надо лишь дать доступ к девайсу:

            # vzctl set 1011 --devnodes ploop53835p1:rw --save
            Setting devices
            CT configuration saved to /etc/vz/conf/1011.conf
            
            # vzctl enter 1011
            entered into CT 1011
            
            # file /dev/ploop53835p1
            /dev/ploop53835p1: block special
            
            # dd if=/dev/ploop53835p1 of=/file bs=1M count=10
            10+0 records in
            10+0 records out
            10485760 bytes (10 MB) copied, 0.105055 s, 99.8 MB/s
            
            # file /file
            /file: Linux rev 1.0 ext4 filesystem data, UUID=9b82bff8-c625-4c63-b550-9efe561cf3e9 (needs journal recovery) (extents) (large files) (huge files)
            
            • 0
              Круто, спасибо :)
        • 0
          К сожалению у меня это именно каталог:


          Почему «к сожалению»? Каталог, в нём файлы, берите и делайте бекап, хоть таром, хоть рсинком.

          Чтобы создать ploop контейнер:

          # yum install ploop
          # vzctl create 12345 --layout ploop
          


          Чтобы всегда по умолчанию создавались ploop контейнеры, нужно прописать VE_LAYOUT=ploop в /etc/vz/vz.conf
          • 0
            Я клиент, а не провайдер)

            Спасибо за rsync — совсем про него забыл
  • 0
    А кто-нибудь IB внутрь виртуалок пробрасывать научился? Вроде Xen-то умеет, но у меня стойкое подозрение что он всю карту в монопольное использование отхватывает, а мне интересно разделение ресурса.
    • +1
      InfiniBand? Ох, мы не сталкивались, но могу спросить ребят из Parallels, нужно?
    • 0
      SR-IOV. Большинство convergent сетевых карт умеет (то есть IB в комплекте). Только оно не мигрябельно между хостами.
  • 0
    Я ваш клиент, но почему-то не ощутил изменений.
    В частности VNC найти не смог.
    И да. У вас на сайте до сих пор старая информация по используемой технологии.
    • 0
      VNC работать должен 100%, уточните номер услуги/тикета? Все решим обязательно.

      Про технологию вся информация имеется прямо в самом заголовке: fastvps.ru/fast-private-servers/

      А по поводу изменений — даже бэкапы не заметили в Power Panel? :)
      • 0
        Я вас не правильно понял. У меня тариф ovz. Я подумал ovz заменил полностью на PCS.
        • 0
          Только FPS пока что :( Если хотите попробовать — прошу в ЛС, можем дать совершенно чудесную скидку на FPS-1 :)
  • –1
    опять реклама
    • +8
      Пусть и реклама (это ведь корпоративный блог), но информация подана интересно и познавательно с технической стороны.
    • +6
      да, вся бы реклама была столь подробна и информативна ;)
  • 0
    А как себя ведет ploop когда пользователь меняет тариф (в частности, когда уменьшается доступное дисковое пространство)? И что происходит если у пользователя на момент уменьшения тарифа на диске было больше данных чем разрешено по новому тарифу?
    • 0
      О, а давайте замутим краткий мануал хав-ту по ploop?

      • Чем вообще так крут ploop? Это быстрая миграция даже в случае миллионов файлов в контейнере! Это поддержка снапшотов и как следствие консистентного бэкапа. Возможность ресайза в любую сторону (уменьшение/увеличение).
      • Сколько будет занимать диск моего контейнера, если я ему выделю 100 гб, но поставлю лишь чистую ОС? Занимать он будет около 600 мегабайт — вес чистой операцонной системы. Что будет если я скачаю 100 гб и удалю их сразу же? Образ контейнера будет занимать 100 гб, но посредством запуска утидиты vzctl compact (без остановки контейнера!) можно очень быстро привести размер образа к размеру файловой системы, что просто killer фича!
      • Где хранятся все данные контейнера — в файле, в папке /vz/$CTID/private/
      • Это raw (сырое) устройство, которое можно смонтировать через loop? Нет — используется собственный формат хранения и нужна поддержка в ядре
      • Используется ли какая-либо специфическая файловая система или используется что-то свое? Используется проверенный временем ext4.
      • Как осуществляется изменения размера файловой системы? Стандартными утилитами resize2fs
      • Как осуществляется создание файловой системы? Стандартной утилитой mkfs.ext4
      • На какой файловой системе могут размещаться образы виртульных машин? Гарантированно поддерживаются ext4 и Parallels Storage, по поводу остальных — нужно уточнять
      • Что будет, если файловая система ext4 внутри контейнера попросит fsck? ploop проверить его автоматически и исправит все возможные проблемы
      • 0
        А вот еще добавочка:
        • Что будет, если попытаться уменьшить размер жесткого диска контейнера до размера, который меньше общего количества данных внутри контейнера? Да ошибка будет и все, ничего не сотрется, ничего не потеряется :)
      • 0
        На какой файловой системе могут размещаться образы виртуальных машин? Гарантированно поддерживаются ext4 и Parallels Storage,


        плюс ещё nfs3 (и nfs4 — в тестировании)
        • 0
          А nfs4 уже в контексте новой ветки ядра 3.X.X?
          • 0
            Так, я попутал поддержку NFSv4 внутри контейнера и для ploop. Ploop, если мне опять не изменяет память, работает поверх nfs — 3 или 4.

            NFSv4 для контейнера уже есть, но выключена по дефолту, потому что недотестирована. From openvz.org/Download/kernel/rhel6-testing/042stab078.7/changes:
            [nfs] NFSv4 support inside a CT has been added/corrected/enhanced, plus online migration of such CTs is supported now (PSBM-17798, PSBM-17795)
            NOTE: NFSv4 inside CT is currently disabled by default, can be enabled via nfs4_ct_enable sysctl on the HN.

            • 0
              Ого, круто) будем тестировать! Спасибо)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное