Введение

При построении ИТ-инфраструктуры предприятия (Enterprise) наиболее значимыми критериями выбора решения становятся:

• высокая доступность,
• непрерывность предоставляемых ИТ услуг (инфраструктурных сервисов),
• целостность хранимых данных,
• возможности обеспечения эластичности.

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

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

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

Следующие категории ИТ-сервисов рассматриваются для построения:

1. Вычислительные ресурсы
2. Сетевые ресурсы
3. Репликация
4. Система хранения данных
5. Сбор метрик
6. Управление жизненным циклом инфраструктурных сервисов
7. Эксплуатационные (Операционные) расходы

Рассмотрим общие принципы построения 'ОТВ эв3" и его возможности.

Общие принципы построения архитектуры

Для обеспечения высокого уровня автоматизации и автономности работы, на уровне инфраструктуры используется программно-определяемая среда:

• Вычисления (виртуализация вычислений/гипервизор)
• Сеть (изоляция сетевого трафика)
• Хранение (R.A.I.N. - redundant/reliable array of inexpensive/independent nodes)
• Построено на основе СПО (Open Source) - отсутствие зависимости от поставщика (vendor lock)
• Уникальная симметричная архитектура решения (нет единой точки отказа), позволяющая оптимально утилизировать выделенные ресурсы и реализующая Shared-nothing подход
• Детерминированное планирование ресурсов, обеспечивающее реальную эластичность и высокую эффективность использования оборудования
• Изоляции рабочих нагрузок (вычислений, обработки данных, сетевого взаимодействия)
• Высокий уровень отказоустойчивости основных сервисов, входящих в решения за счет избыточности
• Обеспечение возможности как вертикального, так и горизонтального масштабирования приложений, помещенных в облачную среду
• Высокий уровень автоматизации управления виртуальными ресурсами, такими как вычисления, частные сети, блочные устройства, приложения

Базовые функциональные возможности

Виртуальные серверы:

• Создание, перегрузка (в том числе "жёсткая"), выключение и удаление виртуального сервера
• Постановка на и снятие с "паузы" виртуального сервера
• Назначение ранее созданного правила доступа на конкретный виртуальный сервер
• Просмотр журнала создания, загрузки виртуального сервера
• Доступ к консоли виртуального сервера
• Изменение размера виртуального сервера
• Пересоздание виртуального сервера (сброс всех ранее произведённых настроек)
• Назначение и освобождения IP адреса Использование API для управления виртуальными серверами

Сеть:

• Создание и управление частными локальными виртуальными сетями (VxLAN)
• Создание и управление маршрутизаторами
• Управление правилами маршрутизации между локальными виртуальными сетями (Лист контроля доступа)
• Построение туннеля между территориально-распределенными частными сетями (VPN), с использованием протокола IP Sec для защиты трафика данных, передаваемых по межсетевому протоколу IP
• Создание балансировщика нагрузки (LBaaS) для обеспечения горизонтального масштабирования вычислений и обеспечения отказоустойчивости разворачиваемых ИТ сервисов
• Использование API для управления сетями

Список контроля доступа:

• Создание собственных правил доступа к вычислительным ресурсам в облачной инфраструктуре
• Создание групп правил доступа к собственным вычислительным ресурсам в облачной инфраструктуре
• Назначение групп правил доступа к собственным вычислительным ресурсам в облачной инфраструктуре
• Использование API для управления списком контроля доступа

Виртуальные блочные устройства:

• Создание и удаление блочных устройств
• Управление "горячими" подключениями блочных устройств к виртуальным серверам без необходимости их (серверов) перегрузки
• Создание и хранение снимка (Snapshot) блочного устройства
• Создание и хранение резервной копии блочного устройства (в том числе инкрементальное)
• Использование API для управления блочными устройствами

Среда исполнения сценариев управления:

• Исполнение шаблонна оркестровки управления сервисами для создания экземпляров ИТ сервисов
• На уровне шаблона поддерживает описание отношения между ресурсами (например, это блочное устройство подключено к этому виртуальному серверу)
• Содержит функциональность, обеспечивающую высокую доступность экземпляров виртуальных серверов и автоматическое масштабирование виртуальных ресурсов по требованию
• Использование API для управления шаблонами оркестровки управления сервисами

Сервис сбора ключевых показателей производительности (сервис телеметрии) виртуальных ресурсов (в разрезе проектов) и оборудования:

• Загрузка ЦПУ.
• Использование RAM.
• Загрузка сетевых интерфейсов.
• Значение температуры (опрос оборудования по протоколам SNMP или IPMI).
• Опрос иных компонентов через Restful API
• Опрос иных компонентов через разработанные агенты
• Использование API для управления данными и отображения их в графической консоли

Планирование ёмкости систем хранения и масштабируемость

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

Разворачиваемое решение обеспечивает как вертикальное, так и горизонтальное масштабирование:

• Вертикальное масштабирование вычислений ограничено максимальными объемами памяти и ЦПУ гипервизора.
• Горизонтальное масштабирование вычислений обеспечивается в рамках одной зоны доступности, а также нескольких зон доступности.
• Горизонтальное масштабирование системы хранения операционных (горячих) данных обеспечивается в рамках зоны доступности. При этом обеспечивается обезличенное хранение 3-х независимых копий данных.
• Горизонтальное масштабирование системы хранения резервных данных обеспечивается как в рамках одной зоны доступности, так и нескольких зон доступности. При этом обеспечивается распределенное хранение не менее 3 копий данных, причем в каждой из зон доступности хранится не менее одной копии данных.

Для повышения эффективности хранения, а также повышения производительности ввода/вывода, используется компрессия данных.

Архитектура: Компонентная диаграмма Пример развертывания в 2-х ЦОДах

Слой гипервизоров (вычислительные узлы)

В каждой из зон доступности (локации) выполняется группировка (агрегация) вычислительных узлов. При необходимости добавления дополнительных вычислительных мощностей, стандартизированные вычислительные узлы автоматически присоединяются в развернутой инфраструктуре "ОТВ эв3" и тем самым обеспечивается горизонтальное масштабирование. Как правило, предлагается иметь одну и более группу (агрегацию) вычислительных узлов. При этом все вычислительные узлы отдельно взятой группы имеют одинаковую, типовую конфигурацию: схожий тип процессора, объем памяти. Слой программно-определяемых сетей В каждой из зон доступности разворачивается программно-определяемая сеть. Отказоустойчивость обеспечивается за счет избыточности маршрутизаторов и DHCP служб. Функциональные возможности этого слоя позволяют пользователям настраивать и определять сетевые подключения, а также управлением инфраструктурой виртуальных сетей, включая сети, коммутаторы, подсети и маршрутизаторы для устройств, управляемых службой, отвечающей за виртуализацию вычислений. Также используются расширенные сужбы, такие как VPN, LBaaS, ACL.

Слой программно-определяемых систем хранения данных

В каждой из зон доступности разворачивается программно-определяемая система хранения данных. Она имеет полностью симметричную архитектуру, где все узлы хранения равны между собой. Добавление или удаление любого узла хранение не ведет к каким-либо изменениями в конфигурации. Для определения места, где данные будут сохранены (узел хранения, дисковый носитель) используется алгоритм консистентного хеширования. Это повышает автономность работы системы хранения данных и минимизирует потребность в администрировании. Каждое виртуальное блочное устройство представляет собой совокупность объектов, хранящихся на основе ключ-значения. При этом каждый упомянутый объект имеет размер 4МБ. Хранимый объект не может быть модифицирован (доступен лишь в режиме только для чтения / read only), любое изменение данных происходит путем записи нового объекта (copy-on-write). Сервис хранения данных оптимизирован для OLTP нагрузки и обеспечивает: хранение не менее 3 копий виртуальных блочных устройств, распознавание ошибок ввода / вывода, автоматическую балансировку нагрузки и хранимых данных. Доступ к виртуальным блочным устройствам возможен только с уровня гипервизора. Создаваемое пользователем виртуальное блочное устройство может быть подключено к одному из виртуальных серверов, созданных в решении "ОТВ эв3".

Компонентная диаграмма

Пояснение:

Используемый Instance HA Service позволяет обеспечить высокую доступность унаследованных приложений, работающих на виртуальной машине. В случае сбоя экземпляра виртуальной машины (instance), или даже целого вычислительного узла обеспечивается восстановление работы этого экземпляра виртуальной машины или экземпляров виртуальных машин вышедшего из строя физического узла на исправном и доступном узле. Существенным требованием для корректной работы данного сценария является наличие shared системы хранения. Это может быть как хранилище доступное в рамках одного центра обработки данных, так и гео-распределенная система хранения, имеющаяся в распоряжении у предприятия.

Текущее решение, максимально использует базовые возможности API Openstack, что позволяет существенно снизить риски реализации подобного решения и избавиться от зависимости от конкретного поставщика подобных решений.

Слой средств управления виртуальными ресурсами и сбора метрик

На этом уровне выделяются следующие логические подслои управления:

• Аутентификация и авторизация пользователей, позволяющий разделить права пользователей с точки зрения управления виртуальными ресурсами
• Шаблоны виртуальных серверов
• Виртуальные серверы
• Сети, в том числе VPN, и балансировка нагрузки
• Списки контроля доступа
• Виртуальные блочные устройства, в том числе их резервное копирование
• Сценарии хореографии виртуальных ресурсов
• Сбор метрик производительности, в том числе используется при хореографии виртуальных ресурсов и мониторинге
• Средства управления виртуальными ресурсами и сбора метрик представляют собой единую точку доступа и управления ресурсами, вне зависимости от количества cформированных зон доступности.

Слой гео-распределённой программно-определяемой СХД

Обеспечивает распределенное хранение резервных копий данных и представляет собой облачную систему хранения данных. СХД горизонтально масштабируется, позволяя использовать гетерогенное оборудование (оборудование от разных поставщиков, имеющее различия в конфигурациях). Виртуализация хранения отделяет и абстрагирует пул хранения от его физической реализации, что позволяет достичь эластичности (увеличивать или уменьшать по мере необходимости), что позволяет снизить логистические риски, связанные с доставкой партии оборудования, в случае необходимости увеличения емкости хранилища. Многопользовательский режим в совокупности с аутентификацией и авторизацией пользователей слоя управления виртуальными ресурсами позволяет разделить права доступа к резервным копиям, что способствует снижению операционных рисков в ходе эксплуатации всего решения.

СХД хранит 3 копии данных на разных дисках, обеспечивая максимально удаленное нахождение каждой из копий по отношению друг к другу с точки зрения объявленных зон доступностей, физических серверов и дисков.

Сетевой взаимодействие, логический уровень

Для развертывания облачной инфраструктуры "ОТВ эв3" выделяют 3 уровня абстракции: сеть управления, используемая для коммуникации служебных ИТ сервисов и сетевого трафика между виртуальными машинами; внутренняя частная сеть, объединяющая зоны доступности и позволяющая привилегированным пользователям организации работать с развернутыми сервисами; публичная сеть интернет. Сеть управления находится за NAT по отношению к частной сети организации и публичной сети интернет. В рамках "ОТВ эв3" у администраторов решения есть возможность создавать сетевую топологию любой сложности (создавать нужные уровни абстракции, формировать DMZ, управлять правилами доступа, назначать IP адреса виртуальным серверам из выделенного пула адресов публичной и частной / внутренних подсетей и т.п.).

Пояснение:

Производительность рассматривалась критическим фактором при проектировании облачной инфраструктуры. Основное внимание уделено системе хранения данных, являющейся, чаще всего, наиболее узким местом. При использовании NL SAS дисков со скоростью 7500 оборотов в секунду и полосой пропускания сети 20Гб/сек, решение "ОТВ эв3" обеспечивает производительность ввода вывода не хуже 22-25 тысяч IOPS для блока размером 4Кб на уровне виртуального сервера. Суммарная производительность системы хранения гиперконвергентной инфраструктуры, состоящей из пяти узлов - не хуже 110 тысяч IOPS для блока размером 4Кб.