Новости

19.05.2016

Cisco Hyper Flex - что за зверь и как его готовить?


Cisco Hyper Flex - что за зверь и как его готовить?

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

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

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

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

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

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

Начали виртуализировать системы хранения. Они стали более сложными и функциональными. Дошло до того, что теперь в отдельной системе хранения, как устройстве, можно запускать “виртуальные” системы хранения для разделения монстра-хранилища между разными проектами, админами, подразделениями организации и даже разными организациями.

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

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

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

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

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

Ан нет! Вспомним какие сейчас скорости обеспечивает “локальная сеть”? 10..40..100Гбит/с – ну и где тут FiberChannel 8/16Гбит/с или шина SAS 6/12Gb/s ? В итоге функционал такого на 100% виртуального стораджа  - адекватный, даже есть возможность (не у всех) размазывать данные приложение между разными дисками – SAS/SATA/SSD – т.е. тиринг. Скоростные показатели, даже при включенной дедубликации данных, адекватные. Ну а что вы хотели? Ведь теперь мы не ограничены 2мя, ну пусть 4мя контроллерами в системе хранения. Каждый физический сервер в неком ландшафте или платформе - он же и контроллер своего кусочка стораджа и дисковая полка. Теперь мы в составе стоимости покупаемых 3..4..5..8 серверов получаем еще и 2…3..5..8 контроллеров для своего стораджа!

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

Очень надеюсь, что описанное более-менее понятно и заодно сняло психологический барьер типа «настоящий сторадж лучше». Про виртуальные коммутаторы «без тела» уже не говорим – любители и пользователи виртуальных сред давно с ними живут.

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

Итак, Cisco HyperFlex.

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

Как мы уже говорили, ЦОД состоит из трех четырех больших подсистем: вычислений, коммутации и, хранения и управления. У Cisco HyperFlex есть:

1) сервер(а) UCS C-220 или UCS C-240, если не хватает вычислительной мощности, то можно ее расширить шасси с 8 блейд-серверами (минимум 3 сервера-ноды для начала)

2) пара фабрик-коммутаторов на основе виртуализированного «конвергентного» коммутатора Nexus – Fabric Interconnect интерконнектов Nexus 62xx0000. Это замечательное коммутационное решение, потому что оно во-первых универсальное – поддерживает любой протокол IP/FC/FCoE/iSCS; во-вторых на них нем "живет" система управления Cisco UCS Manager , то есть система управления всем что можно сделать с современными серверами и их сетевой частью (с бесплатной лицензией, что всегда приятно);

3) ___ отсеков для жестких дисков на системы хранения, диски которых находятся в п.1 –расположены в тех же самых серверах. HX220-c  и ____ на HX240c. Система хранения виртуализированна с практически полным арсеналом плюшек и фишек современного стораджа, но и управляется не мудреной отдельной системой управления да еще с доп лицензией, а  посредством той же самой среды VMware vSphere, которую пользователь сознательно выбрал для запуска своих виртуальных машин. Еще одна приятная мелочь: .

Да, лицензия на vCenter бесплатная.

4) Управляется вся эта система - уже оговорился чуть ранее - посредством VMware vSphere. То есть, если у вас есть специалист по VMware даже начального уровня - уже достаточно чтобы он же и стораджем управлял. Вторая приятность – гипервизор VMware vSphere ESXi 6.0 уже предустановлен на всех нодах HyperFlex .

Что получаем? Полноценный дата-центр "из коробки". Минимальная комплектация - три сервера (ноды) серии HX и два интерконнекта Nexus 6200 (к чести вендора надо сказать, что для варианта HyperFlex они продаются с огромными скидками).

Купили, развернули, пользуемся - хорошо. ! Природа современного IT такова, однако, что рано или поздно ресурсы кончаются и возникает извечный вопрос №2, то есть "Что делать?". И решить его необходимо до возникновения извечного вопроса №1 "Кто виноват?". Как будем решать с HyperFlex?

Алгоритм прост.

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


Cisco HyperFlex HX220c M4. 1RU

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

Cisco HyperFlex HX240c M4. 2RU

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

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


Фишка коммутационной пары входящий в решение HyperFlex  - UCS FI  - как раз в конвергенции – поддержке всех протоколов. Эти же коммутаторы и обеспечивают нашу группу серверов сетью 10Гбит, организуя скоростные каналы общения между узлами, достаточные и для работы виртуальных серверов и для нашего виртуального стораджа и подключенного физического. 1,8Терабита в секунду каждый из 2х коммутаторов хватит?

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

Возможно, с другим вендором все так бы и получилось, но не с Cisco. Здесь у нас полное сохранение инвестиций, то есть если мы решим, что нам необходим не "ЦОД из коробки", а полноценный ЦОД с фальшполом и стойками, то что у нас уже есть,

1) Ноды серии HX2XXс - они же сервера UCS -C-series. Вливаются в UCS-ЦОД как родные.

2) Интерконнекты Nexus 6200 - они же используются в "полноразмерном" ЦОДе./ И не забываем про "живущий" на них UCS Manager, который бесплатен и "обслуживает" до 160 серверов. Немаловажное, надо сказать, ценовое подспорье,

3) Дисковое пространство тоже никуда не девается, но становится частью конвергентных решений со сторонними вендорами. Уже немало было написано о том, что у Cisco есть совместные разработки с NetApp, EMC, NimbleStorage, Hitachi  и даже IBM. По ним есть тонны литературы, включая руководства по эксплуатации описывающие даже какие кабели в какие порты нужно вставить и какие команды прописать, чтобы все заработало (а FlexPod  и vBlock вообще приходят к заказчику настроенными и готовыми к немедленному использованию).

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

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


Возврат к списку