Евгений Лагунцов, инженер-консультант по серверным продуктам, Cisco
Cisco HyperFlex представляет собой гиперконвергентное решение, которое позволяет построить комплексную ИТ-инфраструктуру, включающую вычислительные ресурсы, подсистему хранения данных и сетевую среду, просто, быстро и экономически эффективно.
HyperFlex – это программно-аппаратный комплекс, состоящий из следующих компонентов:
• фабрика Cisco UCS Fabric Interconnect серий 6200 или 6300, обеспечивающая внутреннюю коммутацию комплекса, сетевое взаимодействие с внешним миром – сетями LAN и, возможно, SAN, а также интегрированное управление серверной платформой на основе политик и шаблонов;
• гиперконвергентные узлы, оснащенные вычислительными мощностями (процессоры, память) и локальными дисковыми ресурсами;
• системное ПО – платформа виртуализации и платформа построения распределенной подсистемы хранения данных HX data platform;
• опционально могут быть добавлены вычислительные узлы, не оснащенные локальными дисковыми ресурсами, которые являются составной частью комплекса и используют распределенную подсистему хранения данных, построенную на базе дисков гиперконвергентных узлов.
Аппаратная платформа
В качестве аппаратной платформы для HyperFlex используется серверная система Cisco UCS (Unified Computing System), которая обеспечила компании Cisco успешный выход на рынок серверов и положение одного из лидеров на рынке блейд-платформ. Использование UCS Fabric Interconnect позволяет комплексу HyperFlex обладать традиционными преимуществами UCS – интегрированной коммутацией и интегрированным управлением. Универсальная среда передачи и универсальный ввод-вывод обеспечивают возможность довести до конкретного сервера в конкретный момент времени нужное количество интерфейсов нужного типа с нужными характеристиками.
Управление серверными ресурсами и сетевой инфраструктурой уровня доступа реализуется на основе политик, шаблонов, что позволяет разворачивать, конфигурировать и масштабировать инфраструктуру, в буквальном смысле слова не обращая внимания на количество управляемых серверов.
Вычислительные и дисковые ресурсы комплекса HyperFlex располагаются на гиперконвергентных узлах, которых в настоящее время существует четыре модели.
Модель HX220 HX240 HXAF220 HXAF240
Форм-фактор 1RU 2RU 1RU 2RU
Тип Гибридный (Flash + HDD) Гибридный (Flash + HDD) All-Flash All-Flash
Диски под данные 6×1,2 TB HDD 10k До 23×1,2 TB HDD 10k 6×960GB SSD или 6×3,8 TB SSD До 10×960GB SSD или 10×3,8 TB SSD
Кэш 480GB SSD 1.6TB SSD 800GB SSD 800GB SSD
Процессоры 2×Xeon E5-2600v4 2×Xeon E5-2600v4 2×Xeon E5-2600v4 2×Xeon E5-2600v4
Память 24 слота DIMM, до 1,5 ТБ 24 слота DIMM, до 1,5 ТБ 24 слота DIMM, до 1,5 ТБ 24 слота DIMM, до 1,5 ТБ
Ввод-вывод VIC1227 (2×10G) VIC1227 (2×10G) VIC1227 (2×10G) VIC1227 (2×x0G)
На сегодняшний день в одном кластере HyperFlex может быть от трех до восьми гибридных узлов или от трех до 16 узлов All-Flash. Если нужно больше вычислительных ресурсов, размер кластера может быть увеличен вдвое за счет использования бездисковых вычислительных узлов. На одной фабрике (паре FI) можно построить единый комплекс из восьми кластеров, суммарным размером до 160 серверов, с единым управлением из одного vCenter.
На каждом гиперконвергентном узле установлены гипервизор VMware ESXi и сервисная виртуальная машина, реализующая функции подсистемы хранения данных. Диски, установленные в серверный узел, подключены к HBA, который в монопольном режиме выделен сервисной виртуальной машине: таким образом, сервисная VM полностью контролирует дисковую подсистему. В гипервизор интегрирован дополнительный модуль Iovisor, который обеспечивает взаимодействие гипервизора со всеми сервисными виртуальными машинами для доступа к данным.
Одной из ключевых особенностей HyperFlex является страйпинг – равномерное распределение всех данных между всеми узлами в рамках одного кластера. Это позволяет избежать бутылочных горлышек на уровне дисковых подсистем конкретных узлов и задействовать для каждой виртуальной машины на любом узле все доступные дисковые и кэш-ресурсы, распределенные по всему кластеру.
Защита данных реализуется за счет хранения каждого блока данных по выбору пользователя либо в двух, либо в трех копиях – на двух или трех разных узлах. Это позволяет обеспечить доступность данных при аппаратных проблемах с дисками и/или узлами в целом.
При изменении количества узлов в кластере система автоматически перераспределяет данные между всеми узлами так, чтобы, с одной стороны, гарантировать равномерность распределения, а с другой – обеспечить заданный уровень отказоустойчивости: хранение каждого блока в двух или трех копиях на разных узлах.
Хранение данных реализуется при помощи специализированной файловой системы на основе логов – LogFS, что позволяет в числе прочего обеспечить возможность эффективного применения механизмов дедупликации и компрессии. Дедупликация и компрессия всегда включены: они не приводят к сколько-либо заметному снижению производительности и выполняются на этапе сброса данных из кэша на диски долговременного хранения.
Возможности интеграции
Как было отмечено, на базе одной пары Fabric Interconnect можно объединять до восьми кластеров HypeFlex. Кроме того, в эту же систему можно подключать серверы UCS, решающие другие задачи, оснащенные другими операционными системами, гипервизорами и т. д.
Такая конфигурация системы является штатной, полностью поддерживается и позволяет строить компактные вычислительные комплексы, лишь частично использующие гиперконвергенцию. Еще одним плюсом является возможность подключения к сетям хранения данных SAN – это делает систему HyperFlex невероятно гибкой, поскольку те задачи, для которых не подходит гиперконвергентная платформа (например, крупные СУБД), продолжают работать на традиционной СХД. Такая архитектура также существенно упрощает процесс миграции.
Отдельно следует сказать, что HyperFlex как платформа является одним из типовых дизайнов Cisco (Cisco validated design – CVD) для построения вычислительной инфраструктуры ЦОД, поэтому полностью поддерживается UCS Director – инструментом автоматизации ЦОД от компании Cisco.
Производительность и методы ее измерения
HyperFlex, как и другие гиперконвергентные решения, – это система, реализующая, в частности, задачи по хранению данных, причем выполняющая это относительно новым способом. Поскольку данные и их доступность – важнейший актив современных предприятий, при рассмотрении возможности использования гиперконвергентных решений практически всегда возникает вопрос: способно ли такое решение обеспечивать достаточную стабильность, устойчивость и производительность при работе с данными? Для ответа на него зачастую организуют тестирования, в рамках которых рекомендуется обращать внимание на следующие моменты.
• Проверять систему следует на нагрузках, по возможности максимально приближенных к «боевым», т. е. к тем задачам, которые в конечном счете система должна будет решать в реальной жизни. В случае применения синтетических тестов, например, таких как iometer или vdbench, нужно попытаться подобрать показательный ряд тестов с различными параметрами размера блоков, соотношения чтения/записи, случайного/последовательного доступа – соответствующими основным задачам, которые будут решаться на этой системе. Гнаться за большими красивыми цифрами на тестах с параметрами, которые не имеют никакого отношения к реальной будущей нагрузке, на наш взгляд, бессмысленно.
• Тесты имеет смысл проводить с рабочими размерами данных достаточно большого объема (как минимум 1,5–2 терабайта), чтобы гарантировать, что система при выполнении теста действительно работает с дисками, а не просто пишет и читает данные из кэша.
• Тесты следует запускать на длительный период времени – как минимум на 12 часов (рекомендуется 24 часа). Это позволит проверить, насколько стабильно работает система под длительной пиковой нагрузкой, как изменяется со временем ее производительность.
• Рекомендуется использовать различные варианты размещения виртуальных машин, генерирующих нагрузку, – не только их равномерное распределение по кластеру, но и, например, локализацию большого числа тестовых машин на одном физическом узле. Это позволит проверить, насколько узким местом является один узел и насколько эффективно кластер может обслуживать нагруженные узлы.
• Рекомендуется учитывать не только интегральные показатели производительности системы, но и распределение полученных результатов по разным тестовым машинам. Наиболее предпочтительным здесь является вариант, когда все виртуальные машины будут показывать сравнимые результаты, нежели иметь для ряда машин хорошие показатели производительности, а для некоторых – неудовлетворительные.
• Рекомендуется проводить тестирование на кластере в конфигурации дополнительных сервисов, приближенной к реалистичной. В частности, для гиперконвергентных решений из-за не очень бережливого подхода к защите данных (хранение нескольких копий) актуальными являются вопросы дедупликации и компрессии данных. Поскольку эти функции, скорее всего, будут применяться в реальной жизни, замеры производительности лучше проводить с включенными функциями дедупликации и компрессии.
• Полезным тестом является эмуляция отказа одного из компонентов системы в процессе нагрузочного тестирования производительности. Например, во время длительного теста имеет смысл извлечь из одного из узлов один диск и проанализировать, насколько просела производительность, как система отработала отказ, восстановила ли она уровень защищенности и производительности через некоторое время, сколько времени на это ушло.
Практика реальных внедрений
Как показывает практика реальных внедрений, результаты тестирований у заказчиков, а также отчеты о тестировании, опубликованные независимыми агентствами (один из таких отчетов о тестировании, проведенном лабораторией ESG Lab, на русском языке доступен по адресу http://cs.co/esglab-hx-test), система Cisco HyperFlex может обеспечить хорошую, стабильную и ровную производительность, а также отказоустойчивость при работающих функциях по оптимизации дискового пространства, прежде всего благодаря своим архитектурным отличительным особенностям: специализированной файловой системе на основе логов и равномерному распределению всех данных по всем узлам в рамках кластера. Это позволяет обеспечивать эффективность механизмов оптимизации, отсутствие бутылочного горлышка и максимальное задействование всех доступных ресурсов для решения задач, поставленных перед гиперконвергентной платформой.
