Привет, Хабр! В этой статье расскажем о гиперконвергенции и как ее можно реализовать разными путями в облаке. А также просто разберемся, чем она отличается от виртуализации с контейнерами. Для начала дадим определение гиперконвергенции, далее поговорим про OpenStack и VMware и затем перейдем к деталям реализации.
Навигация по тексту:
Немного про OpenStack и VMware
- VMware: просто, но дорого
- OpenStack: гибкость за счет сложностиРеализация гиперконвергентной инфраструктуры на базе OpenStack
- All-in-One
- Logical Volume Manager
- С SDS вроде Ceph
Что такое гиперконвергенция
Давайте разберемся с основными понятиями, потому что порой даже опытные разработчики путают эти технологии между собой.
Виртуализация — это технология, позволяющая запускать несколько виртуальных машин на одном физическом сервере. Каждая виртуальная машина получает свою долю физических ресурсов процессора и памяти, но при этом хранение данных и сетевая инфраструктура обычно остаются отдельными компонентами. Представьте многоэтажный дом, где у каждого своя квартира, но коммунальные службы общие и управляются независимо. В этой модели вы можете гибко распределять вычислительные ресурсы, но управление хранилищами данных и сетью требует отдельных инструментов и подходов.
Контейнеризация — это технология, фокусирующаяся на изоляции приложений и их зависимостей внутри неких сущностей (контейнеров), которые используют общее ядро операционной системы. Контейнеры «легче» виртуальных машин и быстрее разворачиваются, но имеют меньшую изоляцию. Это похоже на то, как жители многоэтажки живут каждый в своей комнате, но пользуются единственной кухней и ванной, — у каждого свое личное пространство, но базовая инфраструктура общая. Такой подход особенно эффективен для микросервисной архитектуры и быстрого масштабирования отдельных компонентов приложения.
Гиперконвергенция — это архитектурный подход, при котором вычислительные процессы, хранение данных и сетевые функции объединяются в единую программно-определяемую систему — иначе говоря, систему, позволяющую осуществить виртуализацию всех критически значимых аспектов, в том числе вычислительные ресурсы, сети и системы хранения данных. Представьте собственный дом, где все системы интегрированы и работают слаженно под вашим контролем. Вы можете гибко управлять всеми ресурсами через единый интерфейс, а масштабирование происходит простым добавлением новых узлов в систему. В отличие от виртуализации, где каждый компонент управляется отдельно, или контейнеризации, где упор сделан на изоляцию приложений от ядра ОС, гиперконвергенция создает полностью интегрированную инфраструктуру, где все компоненты работают как единое целое под централизованным управлением.
Чем может быть полезна гиперконвергенция
Гиперконвергентная инфраструктура (HCI) наиболее востребована в тех средах разработки, для которых требуется гибкое управление ресурсами. Она позволяет быстро создавать изолированные тестовые окружения, упрощает построение CI/CD пайплайнов благодаря программно-определяемой инфраструктуре и отлично подходит для микросервисной архитектуры, где важно независимое масштабирование компонентов. При работе с системами HCI обеспечивает единую консистентную среду для разработки и тестирования, что особенно ценно при постепенной миграции между облаками или при работе с чувствительными данными. А в высоконагруженных системах интегрированное управление всеми ресурсами позволяет оптимально распределять нагрузку и быстро масштабировать отдельные компоненты при необходимости.
Однако даже у кажущейся идеально подходящей на первый взгляд гиперконвергенции есть подводные камни:
Это принципиально новый подход к построению архитектуры: придется многому научиться и, возможно, полностью пересмотреть привычные методы работы.
HCI требует широких компетенций во всех аспектах инфраструктуры: аппаратного комплекса, программного обеспечения, сетей, систем хранения данных и прочего.
Гиперконвергенция, как подход к построению инфраструктуры, может быть реализована разными способами. При выборе конкретного решения стоит рассмотреть различные технологические платформы. Если говорить об open source решениях, то помимо OpenStack существуют и другие варианты, такие как OpenNebula или Proxmox. Эти платформы предлагают готовую реализацию гиперконвергентной инфраструктуры и, хотя они менее гибкие и не настолько кастомизируемые как OpenStack, они значительно проще в освоении и развертывании. Open source подход не только обеспечивает экономию на лицензиях, но и дает свободу от привязки к конкретному вендору, что особенно важно для проектов, где не требуется глубокая настройка под специфические нужды.
Немного про OpenStack и VMware
Как мы знаем, OpenStack — это платформа с открытым исходным кодом для создания облачных инфраструктур, позволяющая управлять большими пулами вычислительных ресурсов, хранилищ и сетей. VMware vSAN — программно-определяемое хранилище данных, интегрированное с гипервизором ESXi. В отличие от OpenStack, в котором нет готовой «из коробки» поддержки гиперконвергенции, VMware представляет коммерческое решение для создания гиперконвергентной инфраструктуры, где все достаточно просто: покупаете готовое решение, устанавливаете, настраиваете — и вперед.
VMware: просто, но дорого
Развертывание гиперконвергентной инфраструктуры на базе VMware vSAN можно сравнить с процессом сборки конструктора по заранее подготовленной инструкции. Это готовое решение, где все компоненты уже интегрированы и оптимизированы для беспрепятственного взаимодействия. VMware предлагает интуитивно понятные инструменты для настройки, мониторинга и управления. Однако за это удобство приходится платить.
Лицензирование продуктов VMware — удовольствие не из дешевых и осуществляется по числу физических процессоров (CPU). Тарифы формируются исходя из стоимости подписки (per CPU или per Instance), и для крупных проектов это может стать существенной статьей расходов. Например, одни затраты на стандартные vSphere могут достигнуть нескольких тысяч долларов, а если добавить vSAN, HCI Kit и другие компоненты, то сумма значительно возрастет. Особенно это становится критичным в условиях, когда речь идет о гиперконвергентных инфраструктурах, где плотность вычислительных мощностей и использование многопоточности играют ключевую роль.
Проблема еще более усложняется в современных реалиях. После ухода VMware с российского рынка возникли сложности с получением официальной поддержки и своевременных обновлений. Поэтому риски безопасности делают это решение еще менее привлекательным.
OpenStack: гибкость за счет сложности
OpenStack предлагает совершенно иной подход к построению гиперконвергентной инфраструктуры. Это решение ближе к философии open source, где всё находится в руках разработчика, и свобода выбора практически безгранична. Но, как и в любом инструменте с высокой степенью гибкости, за свободу приходится платить сложностью.
Преимущество OpenStack — открытая (разрешительная) лицензия. Вы можете использовать стек бесплатно, а поддержку обеспечивает мировое сообщество и коммерческие компании, такие как Red Hat. Например, облачная платформа Рег.ру построена на технологии OpenStack, и для нас как провайдера это означает, что мы можем предоставлять решения без привязки к лицензионным ограничениям. Мы сами обеспечиваем поддержку и развитие инфраструктуры. К тому же, в текущих условиях OpenStack стал решением, с использованием которого возможно получить государственную сертификацию в России, благодаря чему мы в том числе смогли пройти аттестацию и войти в реестр российского ПО.
Санкции и нынешние ограничения подтолкнули многих к поиску альтернатив. И OpenStack, благодаря своей открытости и гибкости, на фоне других решений с лицензиями стал очевидным выбором для многих.
Реализация гиперконвергентной инфраструктуры на базе OpenStack
All-in-One
Прежде чем углубиться в сложные конфигурации, стоит рассмотреть самый простой вариант развертывания гиперконвергентной инфраструктуры на базе OpenStack: All-in-One. Это базовый способ развернуть облако, который часто становится отправной точкой для знакомства с данной технологией. В конфигурации All-in-One все сервисы OpenStack сосредоточены на одной ноде. Здесь нет разделения на control- и compute-plane: БД, брокер сообщений, вычислительные ресурсы (Nova-*), сетевые сервисы (Neutron-*) и управляющие компоненты (API, планировщики) запущены на одном физическом сервере. Каждая нода одновременно выполняет функции и контроллера, и вычислительного узла.
Такой подход особенно привлекателен для небольших проектов с крайне ограниченными ресурсами, когда в распоряжении, допустим, всего три физических сервера. All-in-One также отлично подходит для тестовых сред, сред разработки и обучения. Это самый дешевый способ создания отказоустойчивой инфраструктуры на OpenStack, что делает его идеальным для проведения экспериментов и быстрого тестирования концепций.
Однако у All-in-One есть свои ограничения. Производительность такой конфигурации ограничена ресурсами одного сервера, а масштабирование сопряжено со значительными трудностями. Отсутствие какого-либо физического разделения ресурсов может привести к проблемам при высоких нагрузках. Поэтому All-in-One не рекомендуется использовать для production-окружений, особенно если предполагается рост нагрузки или расширение инфраструктуры.
All-in-One можно рассматривать как отличную стартовую площадку для понимания принципов работы OpenStack и гиперконвергенции. Однако по мере роста потребностей и ресурсов рекомендуется переходить к более сложным и функциональным конфигурациям, которые рассмотрим далее. Эти конфигурации лучше подходят для реальных production-задач и обеспечивают большую гибкость и производительность.
Logical Volume Manager
Подход с использованием LVM (Logical Volume Manager) предлагает гибкость и экономичность, однако подразумевает определенные компромиссы в плане отказоустойчивости и масштабируемости. В основе работы LVM лежит управление блочными устройствами на уровне операционной системы, что позволяет гибко выделять и перераспределять дисковое пространство. В OpenStack за интеграцию с дисковой подсистемой отвечает компонент Cinder, обеспечивая доступ к хранилищам для виртуальных машин. В процессе развертывания гиперконвергентной инфраструктуры с использованием LVM нет необходимости настраивать сложные распределенные системы хранения или обеспечивать взаимодействие между множеством узлов. Это решение идеально для случаев, когда нужно быстро запустить инфраструктуру с минимальной сложностью.
Главное преимущество LVM заключается в простоте и скорости развертывания. Для запуска гиперконвергентной системы с LVM не требуется сложных настроек: базовая конфигурация может быть выполнена за короткое время, а управление томами осуществляется через стандартные инструменты. Это делает решение привлекательным выбором в условиях, где распределенное хранилище вроде Ceph кажется избыточным.
Однако стоит понимать, что у такого подхода есть ограничения. Прежде всего, LVM не предлагает встроенной отказоустойчивости. Если физический сервер выйдет из строя, можно потерять все данные с дисков. Использование LVM также ограничено в плане масштабируемости. Кроме того, LVM, как правило, работает в рамках одного узла или ограниченного кластера, и при увеличении объемов данных его эффективность начинает снижаться. Это означает, что в сценариях с интенсивными нагрузками на хранилище или большими объемами данных LVM быстро исчерпает свои возможности. Здесь придется либо переходить на более сложные решения, либо рассматривать кардинальные изменения в архитектуре.
Тем не менее, для задач, где требуется быстрое развертывание и управление дисковыми ресурсами, LVM может стать отличным выбором. Он позволяет гибко управлять томами, создавать снапшоты и легко изменять размеры дисков, что полезно в динамичных средах.
С SDS вроде Ceph
Ceph тесно интегрирован с OpenStack, что позволяет организовать высокомасштабируемое и отказоустойчивое хранилище для виртуальных машин. Интеграция Ceph с OpenStack реализуется через несколько ключевых компонентов. Сервисы OpenStack напрямую взаимодействуют с Ceph: Nova использует его для хранения образов виртуальных машин, Cinder подключается для создания блочных устройств, а Glance хранит в нем шаблоны образов. Также Ceph обеспечивает автоматическую репликацию данных между узлами кластера, что делает его особенно эффективным для крупных инфраструктур, где требуется не только надежное хранение, но и возможность горизонтального масштабирования.
Однако настройка связки OpenStack с Ceph — это нечто сродни сборке сложной архитектуры из отдельных элементов без полной инструкции. Да, есть множество руководств и рекомендаций, но каждый сценарий использования требует индивидуального подхода. Это не готовое решение, которое можно просто установить и запустить. Подробнее о Ceph и том, как реализована данная технология в облаке, мы рассказывали в нашей предыдущей статье.
Заключение
Таким образом, для реализации гиперконвергентной среды на базе OpenStack существует несколько популярных подходов, каждый из которых имеет свои плюсы и минусы. Что касается гипервизоров, OpenStack по умолчанию использует KVM, но поддерживает и другие, включая ESXi. Это дает гибкость в выборе и позволяет использовать существующую инфраструктуру. Настройка управления памятью требует глубокого понимания ядра Linux и работы с Huge Pages, Zram, Zswap и другими технологиями, так как в отличие от VMware, где есть механизмы сжатия и высвобождения оперативной памяти (ballooning), в OpenStack таких функций «из коробки» нет.
В то же время, подготовка гиперконвергентной инфраструктуры средствами VMware (vSAN) — это больше вопрос следования пошаговой инструкции. Сам процесс установки значительно проще, чем у OpenStack, и требует меньше времени на начальное развертывание. Большая часть работы автоматизирована, и конфигурация всех компонентов, включая хранилище и сети, может быть выполнена через графический интерфейс VMware vCenter.
Выходит, что разница между OpenStack и VMware с точки зрения установки и порога входа для разработчиков заключается в глубине контроля и сложности настройки. OpenStack требует большего погружения в детали системного программирования, конфигурации сети и контейнеризации, что делает его более гибким, но и более сложным в установке и управлении. VMware, напротив, обеспечивает быстрый и интуитивно понятный процесс установки, но за это удобство приходится платить как в финансовом плане (лицензии и поддержка), так и в плане ограничений гибкости.
Так или иначе, выбор будет зависеть от множества факторов: бюджета, требований к функциональности, необходимости в поддержке и многого другого. На одной чаше весов будут большие затраты на поиск и оплату компетентных специалистов, которые настроят гиперконвергенцию так, как вам угодно. А на другой — простота использования с меньшими требованиями к квалификации, но раздутыми ценами на лицензии и нулевой свободой к изменению исходников под себя. Мы же для себя выбор сделали в пользу OpenStack, и сегодня наши пользователи могут оценить преимущества этой технологии на облачной платформе Рег.ру.