Huawei FusionCube — когда гиперконвергентная система выгоднее серверов и СХД
Как устроена гиперконвергентная система, чем она отличается от связки серверов и системы хранения и в каких сценариях выгоднее классической схемы.
Гиперконвергентная система объединяет вычислительные узлы, хранилище и программный слой виртуализации в одном изделии. Вместо раздельной закупки серверов, системы хранения и сети хранения данных заказчик получает готовое шасси с преднастроенным программным обеспечением. Huawei поставляет такие решения под маркой FusionCube — они лежат в разделе конвергентных систем.
Разберём, чем гиперконвергентная система отличается от классической связки «серверы плюс система хранения», в каких сценариях она выгоднее и что проверить до заказа.
Как устроена гиперконвергентная система
В классической схеме вычисления и хранение разнесены: серверы подключаются к системе хранения через отдельную сеть хранения данных. Каждый элемент закупается, настраивается и обслуживается отдельно, а между ними стоят коммутаторы сети хранения со своими лицензиями и правилами зонирования.
В гиперконвергентной системе диски установлены в самих вычислительных узлах, а распределённое программное хранилище собирает их в единый пул с репликацией между узлами. Отдельная сеть хранения данных не нужна — узлы обмениваются данными по обычной сети передачи данных. Отказ диска или целого узла не приводит к потере данных: копии блоков лежат на других узлах.
- Узлы. Вычислительные модули с процессорами, памятью и локальными дисками. В линейку входят как готовые шасси, так и серверы FusionCube для наращивания.
- Распределённое хранилище. Программный слой, объединяющий локальные диски узлов в общий пул с заданным уровнем избыточности.
- Гипервизор. Среда виртуализации, поставляемая вместе с системой либо устанавливаемая заказчиком.
- Управление. Единая консоль для узлов, хранилища и виртуальных машин вместо трёх независимых интерфейсов.
- Шасси и обвязка. Готовые исполнения в стойке — FusionCube 1000 Cabinet, комплектующие берутся из раздела комплектующих FusionCube.
Сравнение с классической схемой
| Параметр | Серверы и система хранения | Гиперконвергентная система |
|---|---|---|
| Состав поставки | серверы, массив, коммутаторы сети хранения, лицензии по отдельности | узлы с преднастроенным программным обеспечением |
| Сеть хранения данных | отдельная, с адаптерами и коммутаторами | не требуется, обмен по сети передачи данных |
| Срок ввода в работу | недели на монтаж, настройку и согласование совместимости | дни, конфигурация задана производителем |
| Масштабирование | раздельно по вычислениям и по ёмкости | добавлением узла целиком |
| Гибкость соотношения ресурсов | высокая, любой перекос закрывается точечно | ограниченная, вычисления и ёмкость растут вместе |
| Обслуживание | три подсистемы, три компетенции | единая консоль и единая точка поддержки |
| Полезная ёмкость | определяется уровнем массива | ниже сырой на величину репликации между узлами |
Когда выгоднее гиперконвергентная система
- Виртуализация общего назначения. Инфраструктура из десятков виртуальных машин с типовым профилем нагрузки: серверы приложений, службы каталога, файловые и почтовые службы.
- Филиалы и удалённые площадки. На площадке нет выделенного администратора хранилищ, а инфраструктура должна работать автономно. Единая консоль и отсутствие сети хранения данных упрощают эксплуатацию.
- Инфраструктура виртуальных рабочих мест. Профиль нагрузки предсказуем, число рабочих мест растёт линейно, и добавление узла закрывает и вычисления, и ёмкость.
- Сжатые сроки запуска. Конфигурация проверена производителем, совместимость компонентов не требует отдельного согласования.
- Ограниченный штат. Одна точка поддержки вместо разбирательств, на чьей стороне проблема — сервера, массива или сети хранения.
Когда классическая схема остаётся предпочтительной
- Резкий перекос в требованиях. Если нужно много ёмкости при малых вычислениях либо наоборот, добавление узлов приводит к оплате незадействованных ресурсов. В такой ситуации отдельная система хранения экономичнее.
- Существующая инфраструктура хранения. Если массив уже закуплен и не выработал ресурс, к нему проще добавить стоечные серверы.
- Базы данных с высокими требованиями к задержке. Часть нагрузок чувствительна к характеру распределённого хранилища и требует проверки на пилоте.
- Высокая плотность вычислений. Там, где на первом месте число узлов в стойке, применяются блейд-серверы с общим шасси.
Что проверить до заказа
- Минимальное число узлов. Распределённое хранилище требует определённого минимума узлов для обеспечения избыточности. Систему из двух узлов собрать не получится.
- Полезная ёмкость. Считается не по сумме дисков, а с учётом репликации и служебного резерва. Разница с сырой ёмкостью существенная, и её нужно закладывать в расчёт заранее.
- Сеть между узлами. Обмен репликами идёт по сети передачи данных, поэтому требуется отдельный сегмент нужной пропускной способности на коммутаторах.
- Лицензирование. Гипервизор, распределённое хранилище и средства резервного копирования лицензируются отдельно, и модель лицензирования проверяется до подписания спецификации.
- Резервное копирование. Репликация между узлами защищает от отказа оборудования, но не заменяет резервную копию: логическое повреждение данных реплицируется вместе с данными.
- Питание и охлаждение. Плотное шасси даёт заметную нагрузку на стойку, что учитывается при расчёте источников бесперебойного питания.
Наращивание системы
Расширение выполняется добавлением узла: пул хранилища увеличивается, нагрузка перераспределяется автоматически. Отдельно можно наращивать память и диски внутри узлов из раздела комплектующих для серверов, если упор идёт в один вид ресурса.
При планировании расширения учитывают, что узлы в кластере должны быть сопоставимы по конфигурации. Добавление узла с существенно иными характеристиками приводит к неравномерному распределению нагрузки и снижению общей производительности пула.
Частые вопросы
Сколько узлов нужно минимально? Зависит от выбранного уровня избыточности распределённого хранилища. Точное число фиксируется на этапе проектирования конфигурации.
Можно ли использовать свой гипервизор? Линейка поддерживает несколько вариантов среды виртуализации; допустимый набор проверяется по конкретной модели и версии программного обеспечения.
Что происходит при отказе целого узла? Виртуальные машины перезапускаются на оставшихся узлах, данные доступны из реплик. Пул переходит в состояние с пониженной избыточностью до замены узла.
Нужны ли коммутаторы сети хранения данных? Нет, отдельная сеть хранения не требуется. Нужен выделенный сегмент сети передачи данных под обмен между узлами.
Подойдёт ли решение для филиала? Да, это один из основных сценариев: компактная конфигурация, единая консоль и отсутствие требований к отдельному администратору хранилищ.
Что мы поставляем
В каталоге — конвергентные системы Huawei, серверы всех линеек, системы хранения, коммутаторы и комплектующие. Считаем полезную ёмкость с учётом избыточности, проверяем требования к сети между узлами и подбираем конфигурацию под профиль нагрузки.
Пришлите профиль нагрузки, требуемую ёмкость и число виртуальных машин на sale@huawei.net.ru — сравним гиперконвергентную и классическую схему на ваших цифрах и посчитаем поставку.
