Cisco HyperFlex — что за зверь и как готовить?
27 мая 2016
Рубрика: Новости CISCO. Тэги:
Автор: Станислав Черепанов, Сергей Дударь.

cisco_27_05_2016

Совсем недавно — вот буквально в марте — Cisco объявила о выходе нового продукта под названием HyperFlex. Первая часть названия решения весьма недвусмысленно указывает на принадлежность продукта к гиперконвергентным системам, а вторая — на гибкость в применении.

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

Итак, окунемся в историю создания центров обработки данных (ЦОД) или датацентров. Три «кита» каждого ЦОДа — это серверная ферма, сеть хранения данных и локальная сеть, объединяющая первые два элемента если не в единое целое, то точно в работоспособное множество.

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

Для большей эффективности работы физических и виртуальных серверов потребовалось обеспечить им в равной степени доступ к данным. Пришлось от просто дисковых массивов на сервере перейти к специализированным системам хранения данных. Причем с наступлением виртуализации серверов и рабочих станций требования к системам хранения увеличились на порядок-два. Это уже не просто ящик с дисками и отдельными блоками питания: теперь к «стораджу» подключено 10… 50… 600 виртуальных машин, и каждая генерирует данные как полноценная рабочая станция.

Начали виртуализировать системы хранения. Теперь в отдельной системе хранения, как устройстве, можно запускать «виртуальные» системы хранения для разделения монстра-хранилища между разными проектами, админами, подразделениями организации и даже разными организациями.

В итоге получили платформу (она же «ландшафт», она же «архитектура») для ЦОД, состоящую из виртуализированных серверов, виртуализированных сетевых устройств и виртуализированных систем хранения, которую стали называть «конвергентной» — объединяющей в себе разные типы оборудования, протоколы связи, операционные среды и способы работы друг с другом, практически идеальную для последующего запуска приложений. В принципе, для приложений все это и делается. Приложение — это то, что видит пользователь. Приложение дает возможность что-то обрабатывать, анализировать, выдавать какой-то результат обработки от картинки до кассового чека или регистрации автомобиля.

Дальше — больше. Выяснилось, что только у немногих вендоров хватает сил и средств разрабатывать решения для всех трех составляющих ЦОДа. Поэтому остальные начали кооперироваться, чтобы не терять долю рынка. Cisco, например, по состоянию на конец 2013 года удерживала долю рынка конвергентных систем в 50%. Неплохо для вендора, который сервера-то начал выпускать всего за 4 года до этого.

Ну и следующий этап, который предстает во всей своей красе прямо вот в настоящий момент, — это гиперконвергентные системы.

Казалось бы, куда уже дальше виртуализировать и конвергировать? Оказалось, это еще не предел. Ведь аппаратные виртуализированные системы хранения на сегодняшний день не что иное, как комплект «железок»: контроллеры (по сути, менее мощные, но серверы) и подключенные к ним дисковые полки. Контроллеры группируют диски в логические тома, «разбрасывают» данные каждого физического или виртуального сервера по этим томам и дискам ради получения скорости, надежности и т.д. Т.е., основные задачи внутри хранилища выполняет все та же, хоть и специфическая, операционная система. Но мы-то знаем, что раз есть ОС, то ее можно «упаковать» в виртуальную машину и потому запустить ее прямо на нашем основном сервере, где есть мощный процессор от того же Intel, которому совсем нетрудно будет обеспечить пару ядер для еще одной виртуальной машины со специфическими задачами — управлением данными. Систему хранения также можно «подселить» на тот же сервер в виде еще одной служебной VM, обеспечивающей не просто все функции современной системы хранения — группировку дисков в RAID, дедупликацию, сжатие, репликацию и т.д., а еще и позволяющую такой «сторадж» организовать на группе серверов. А в одно целое они будут объединены локальной сетью.

Раньше такая мысль была бы с негодованием отвергнута: скорость передачи данных в Ethernet-сетях еле-еле добиралась до 100 Мб в секунду, а в выделенных системах хранения обмен данными шел на скоростях 8/16 Гб/с (SAS), или 6/12 Гб/с (FiberChannel). Сейчас Ethernet со скоростью 10 Гб/c — практически стандарт для корпоративной сети и все чаще используются скорости 40 и 100 Гб/с. «Ну и чего ж тебе надо?», — как говорил Иван Грозный в одном знаменитом фильме.

В целом, как мы видим, гиперконвергентная система (ГКС) — уже не просто сервер, а мини-ЦОД, в котором все ресурсы (не только для ОС и приложений, но и для виртуальной сети и системы хранения), распределяются между приложениями, пользователями с большой степенью гибкости.

И в этом классе систем Cisco оказалась в первых рядах.

Итак, Cisco HyperFlex

Как мы уже говорили, ЦОД состоит из трех больших подсис­тем: вычислений, коммутации и хранения. У Cisco HyperFlex есть: 1) сервер(а) UCS C220 или UCS C240 (минимум 3 сервера-ноды для начала); 2) пара коммутаторов на основе виртуализированного «конвергентного» коммутатора Nexus — Fabric Interconnect 6200. Это замечательное коммутационное решение, потому что оно, во-первых, универсальное — поддерживает любой протокол IP/FC/FCoE/iSCS; во-вторых, на нем «живет» система управления Cisco UCS Manager (с бесплатной лицензией, что всегда приятно); 3) системы хранения, диски которых расположены в тех же самых серверах. Система хранения виртуальная с практически полным арсеналом плюшек и фишек современного стораджа, но управляется посредством среды VMware vSphere, которую пользователь сознательно выбрал для запуска своих виртуальных машин. Еще одна приятная мелочь: если у вас есть специалист по VMware даже начального уровня — уже достаточно. Вторая приятность — гипервизор VMware vSphere ESXi 6.0 уже предустановлен на всех нодах HyperFlex

cisco_27_05_2016_1

Cisco HyperFlex – состав решения

Что получаем? Полноценный датацентр «из коробки». Минимальная комплектация — три сервера (ноды) серии HX и два интерконнекта Nexus 6200 (к чести вендора надо сказать, что для варианта HyperFlex они продаются с огромными скидками). Купили, развернули, пользуемся — хорошо! Однако, рано или поздно ресурсы кончаются и возникает извечный вопрос №2, то есть «Что делать?». И решить его необходимо до возникновения извечного вопроса №1 «Кто виноват?». Как будем решать с HyperFlex? Алгоритм прост.

1)  Если не хватает вычислительных ресурсов, то докупаем память (и в HX220с и в HX240с по 24 слота, до 768Гб DRAM), либо подключаем шасси UCS5108 и получаем еще 8 блейд-серверов в общем пуле ресурсов.

cisco_27_05_2016_2

Cisco HyperFlex HX220c M4. 1RU

2)  Если не хватает дискового пространства, докупаем еще одну ноду — скорее всего, HX240c (до 24 дисков).

cisco_27_05_2016_3

Cisco HyperFlex HX240c M4. 2RU

3)  Если каким-то виртуальным машинам понадобилось до неприличия много пространства или решили поручить одной VM задачу делать резервные копии на выделенный аппаратный сторадж — нет проблем. Прямо в пару конвергентных коммутаторов UCS Fabric Interconnet, подключаем такую «классическую» систему хранения по 10Гб/с IP-сети (т.е. NFS/CIFS/iSCSI/FCoE) или даже по Fiber Channel — коммутатор «понимает» даже его.

cisco_27_05_2016_4

Cisco HyperFlex с блейд-шасси UCS 5108

Понятно, что рано или поздно все три сценария работать перестанут. И что делать тогда? Все выбрасывать и закупать заново?

Возможно, с другим вендором все так бы и получилось, но не с Cisco. Здесь у нас полное сохранение инвестиций, то есть, если мы решим, что нам необходим не «ЦОД из коробки», а полноценный ЦОД с фальшполом и стойками, то, что у нас уже есть: 1). Ноды серии HX2XXс — они же сервера UCS C-series. Вливаются в UCS-ЦОД как родные. 2). Интерконнекты Nexus 6200 — они же используются в «полноразмерном» ЦОДе. И не забываем про «живущий» на них UCS Manager, который бесплатен и «обслуживает» до 160 серверов. Немаловажное, надо сказать, ценовое подспорье. 3). Дисковое пространство тоже никуда не девается, но становится частью конвергентных решений со сторонними вендорами. Уже немало было написано о том, что у Cisco есть совместные разработки с NetApp, EMC, NimbleStorage, Hitachi и даже IBM. По ним есть тонны литературы, включая руководства по эксплуатации, описывающие даже какие кабели в какие порты нужно вставить и какие команды прописать, чтобы все заработало (а FlexPod и vBlock вообще приходят к заказчику настроенными и готовыми к немедленному использованию).

Еще одно немаловажное преимущество — это так называемый footprint, то есть место, физически занимаемое оборудованием в стойке или в офисе. Действительно, серверная — она не резиновая. И чаще всего — ну исторически так сложилось — под нее отдают помещение, от которого отказался бы даже маленький Гарри Поттер. К тому же, в стойке уже размещены коммутаторы, маршрутизаторы и все остальное необходимое. Соответственно, к моменту «созревания» до ЦОДа места остается, мягко говоря, недостаточно. Расширить серверную — не всегда возможно. Поставить в существующую стойку блейд-шасси — тоже проблемно: придется переставлять устройства, менять разводку кабелей — сложно, нудно и затратно, так как придется останавливать работу всей организации. Но при всей занятости стойки, 5–6 юнитов у нас всегда найдется, пусть даже и не подряд. А сколько юнитов требуется для минимального внедрения HyperFlex? Три ноды HX 220c по 1RU и 2 интерконнекта серии 6200 тоже по 1RU, итого 5RU. 5 юнитов в 42-юнитовой стойке найти можно всегда. Более серьезное внедрение — с нодами HX 240c требует 8 RU. При этом эти юниты не должны располагаться подряд — все равно наш мини-ЦОД будет работать как единое целое, главное — подключить все ноды к фабрик-интерконнекту.

Внедрение HyperFlex всего на 3 сервера дает полноценную 10 Gb/s IP и FC-инфраструктуру. Этот элемент в дальнейшем станет ядром ЦОД, даже если дальнейшее развитие потребует более классических решений — инвестиции сохранятся.

Подводя итог повествованию, Cisco HyperFlex — это весьма и весьма удачный выбор для организации, которая начинает внедрять комплексную IT-инфраструктуру, особенно если при этом внедрение требуется произвести в максимально короткие сроки и небольшим количеством персонала. Который, опять же, желательно еще и не сильно переучивать.

Авторы: Станислав Черепанов, управляющий партнер тренинг-центра TrainPower,  Сергей Дударь, менеджер по развитию бизнеса DC Cisco CIS

Orphus system
Подписывайтесь на канал infoCOM.UZ в Telegram, чтобы первыми узнавать об ИКТ новостях Узбекистана
В Telegram
В WhatsApp
В Одноклассники
ВКонтакте