Дмитрий Хороших, менеджер по развитию бизнеса, Cisco
Последние несколько лет развитие рынка ИТ-систем характеризуется широким применением типовых инфраструктурных блоков. С момента первого появления в 2008 г. совместного решения компаний Cisco и NetApp под названием FlexPod использование конвергентных систем для многих заказчиков стало стандартом и позволило им значительно сократить свои временные и финансовые затраты на проектирование и разворачивание ИТ-систем.
Быстрота развертывания и простота обслуживания
Благодаря стандартизации архитектуры типовых инфраструктурных блоков стало возможным разворачивать системы в течение нескольких дней с момента поставки оборудования. Эксплуатация также значительно упростилась: ведь если архитектура всех систем стандартная, то проще разрабатывать и соблюдать регламенты, а следовательно, у заказчика происходит меньше аварий, сокращается время непродуктивного простоя системы.
Предложенный Cisco подход оказался настолько удобным, что разработкой подобных решений занялись и другие компании. Сегодня, спустя восемь лет, подобные решения имеет в своем портфеле каждый уважающий себя производитель ИТ-«железа» для ЦОД. Только в портфеле компании Cisco сегодня присутствует около десятка конвергентных решений – как универсальных, так и оптимизированных под какой-то конкретный тип приложений.
Автоматизация и открытость
Еще одним важным фактором, определившим распространение типовых решений, стала автоматизация. Поскольку такой инфраструктурой легче управлять, то многие операции упрощаются и могут быть описаны в виде универсальных сценариев.
Предлагаемый Cisco продукт для управления ЦОД UCS Director работает со всеми типовыми дизайнами, имеющимися в портфолио нашей компании. И неважно, из каких компонентов построены отдельные «кубики». Если эти компоненты поддерживаются платформой автоматизации, то администратор не должен изучать интерфейсы управления каждой системы СХД, серверной платформы или платформы виртуализации. Подавляющее большинство операций можно выполнять через единый универсальный интерфейс.
Открытость UCS Director также сыграла свою роль. Сегодня существует международное сообщество разработчиков как сценариев автоматизации ЦОД, так и интеграционных модулей для поддержки стороннего «железа». Причем часть таких модулей написана и поддерживается самими производителями, например, интеграция с дисковыми массивами IBM в рамках совместного конвергентного дизайна VersaStack поддерживается самой компанией IBM. Это, в частности, гарантирует, что такая поддержка не пропадет с выходом новой версии прошивки массива.
Переход к гиперконвергенции
Новый подход от Cisco обеспечивает серьезные преимущества для организаций в современном ускоряющемся мире, где выход на рынок на два-три месяца раньше конкурентов позволяет захватить большую его часть и может определить успех компании на несколько лет вперед. А повышение операционных затрат на 5–10% способно «убить» и продукт, и компанию за считанные месяцы. Именно потому множество компаний принялись искать дальнейшие пути улучшения конвергентных платформ. Ведь, по сути, конвергентная платформа строится хоть и по единой архитектуре, но все-таки из разных компонентов.
Вычислительные мощности современных серверов за последние пять-шесть лет возросли на порядок. Далеко вперед шагнули алгоритмы работы с данными. Заметно упали в цене твердотельные накопители, что позволило удешевить процедуру кэширования данных. В результате этого наблюдается широкое развитие следующего поколения интегрированных систем, которые получили название гиперконвергентных.
Приставка «гипер» должна, по идее, показать переход на следующий уровень интеграции: вместо разнотипных компонентов мы теперь используем однотипные и даже, скорее, одинаковые серверы на базе стандартного чипсета x86 с большим количеством внутренних дисков. Все данные хранятся на тех же серверах, на которых они и обрабатываются, а сами серверы соединены стандартной сетью Ethernet. Все операции по работе с данными, сетью и т. д. выполняются за счет программного обеспечения.
Преимущества гиперконвергентных решений
Такой подход к системе несет в себе огромное количество преимуществ по сравнению с традиционным.
Во-первых, расширение системы проводится одинаковыми стандартными блоками, содержащими память, процессоры и дисковое пространство. Расширение мощностей занимает минуты и может быть выполнено стажером или оператором remote hands в удаленном дата-центре.
Во-вторых, ведущие игроки этого рынка предпочитают не создавать для управления такой платформой собственные мудреные интерфейсы, а интегрироваться с консолью управления среды виртуализации. Это решение значительно упрощает жизнь администратору платформы: больше не требуется взаимодействия нескольких людей, чтобы выполнить простейшие, в сущности, действия. В крупной компании даже создание виртуальной машины может занимать пару недель (!). Часто созданием диска и настроек SAN-сети занимается один отдел, подключением к сети – другой, а созданием собственно VM – третий. Да, они сидят в одном здании, но на разных этажах и часто общаются друг с другом посредством служебных записок. Это может быть хорошо для поддержки статичных систем, но становится совершенно неприемлемым, если возникает необходимость в быстром запуске новых продуктов.
В гиперконвергентной платформе все инструменты для управления средой виртуализации сосредоточены в одном месте, а значит, управлять системой может один человек. Именно поэтому гиперконвергентные продукты все чаще выбирают компании, которые хотят сократить капитальные и операционные затраты на эксплуатацию ИТ.
Преимущества гиперконвергентных платформ очевидны, и уже сегодня понятно, что они способны за короткое время кардинальным образом изменить подход к построению ИТ-систем и весь рынок в целом.
Области применения
Возникает вполне резонный вопрос: все ли ИТ-задачи можно переносить на такие платформы и получать преимущества от их использования?
Как показывает практика, этот вопрос пока не имеет однозначного ответа. Чтобы понять, почему это так, желательно немного глубже погрузиться в детали работы гиперконвергентной платформы.
Мы уже знаем, что данные в этих платформах хранятся на внутренних дисках серверов. Отказоустойчивость хранения данных достигается за счет разбиения на блоки небольшого размера с хранением нескольких копий каждого блока. Для предотвращения потери данных при отказе одного из серверов блоки равномерно распределяются по серверам в одном кластере (его еще называют кластером данных).
Такой подход приводит к гораздо большему расходу дискового пространства, чем при использовании традиционных механизмов RAID, но, поскольку стандартные диски значительно дешевле специализированных, в итоге все равно получается хороший выигрыш по цене.
Еще одна особенность специализированных дисков в дисковых массивах – высокая скорость их работы. И вот тут кроется основная слабость гиперконвергентных платформ на вращающихся дисках – относительно низкая скорость работы с единичными высоконагруженными базами данных большого объема. Сильным местом таких систем является беспрецедентно высокая скорость работы с множественными нагрузками малого объема.
Именно поэтому свои первые успехи компании, производившие такие решения, сделали в сегменте платформ для VDI. Идеальный случай: множество дисков небольшого объема, к которым получает доступ такое же множество виртуальных машин. Внутри дисков имеется множество повторяющихся данных – ОС, системное ПО, а значит, здесь можно получить огромный выигрыш от применения алгоритмов дедупликации и компрессии.
Одновременная загрузка сотен виртуальных машин способна вывести из нормального режима работы систему, основанную на традиционной СХД, – для этого даже существует термин «Boot storm». Но для гиперконвергентной платформы именно такой режим работы и есть самый оптимальный.
Вслед за VDI-платформами новый класс систем хорошо зарекомендовал себя в средах разработки и тестирования, особенно если в них применяется гибкий (Agile) подход к процессу разработки ПО. Такой подход предполагает частое, до нескольких раз в день, разворачивание виртуальных сред для тестирования новых функциональных возможностей приложений – и гибкость гиперконвергентных систем здесь очень кстати.
А как же инфраструктурные приложения, составляющие основу большинства ИТ-систем? Сегодня можно с уверенностью сказать, что за два года, прошедшие с момента появления нового подхода, прогресс шагнул далеко вперед и практически все традиционные приложения уже могут работать на гиперконвергентных платформах. За одним единственным исключением: следует избегать переноса на системы с вращающимися дисками больших баз данных. Здесь ключевое слово – «больших».
Что же нам считать большой базой? По данным последних тестов, проведенных нашей компанией, это базы размером более 2–3 ТБ. Виртуальные машины с меньшим размером на гиперконвергентных платформах работают прекрасно. Если же вы хотите получить преимущества нового подхода, но ваша нагрузка превышает этот размер, то единственный выход будет заключаться в использовании платформ с твердотельными накопителями. Благодаря прогрессу последних лет SSD-диски стали стоить значительно дешевле, и цена системы с их использованием вырастает всего на 30–40% относительно сходной конфигурации на вращающихся дисках. Такие системы уже доступны в продаже и активно тестируются заказчиками.
HyperFlex как эффективный способ развития корпоративной платформы виртуализации
Если суммировать в кратком обзоре особенности подхода компании Cisco к построению гиперконвергентных решений, то необходимо отметить следующее.
Аппаратной базой для нашего решения HyperFlex является фабрика UCS – собственная серверная платформа Cisco, доказавшая свою надежность и заслужившая доверие многих пользователей. Линейка решений включает как производительные системы All Flash, целиком построенные на базе SSD-дисков, так и гибридные системы, использующие более дешевые шпиндельные диски для снижения стоимости.
В зависимости от необходимого размера дисковой подсистемы используются либо серверы C220, вмещающие шесть продуктивных дисков, либо C240 (24 диска). Серверы объединяются в кластеры размером от трех до восьми штук, в рамках кластера осуществляется резервирование данных за счет многократного хранения.
Ядром системы является Fabric Interconnect – осуществляет функции коммутации сетевого трафика и автоматизации управления серверами. К одной паре FI может быть подключено до восьми кластеров с данными. Такая организация системы позволяет полностью автоматизировать первоначальную настройку и дальнейшее управление кластером HyperFlex. Всю работу по настройке системы берет на себя сервисная виртуальная машина. Вы просто вводите нужные параметры работы: коэффициент резервирования, сетевые настройки, реквизиты доступа к vCenter – и уже через 30–40 минут получаете полностью готовую систему, интегрированную с платформой виртуализации.
Система также поддерживает расширение кластеров за счет добавления дополнительных вычислительных ресурсов, работу с графическими ускорителями, подключение традиционных SAN-ресурсов и, что важно, может управляться с помощью UCS Director. Таким образом, HyperFlex не является «вещью в себе» – это новый эффективный способ развития корпоративной платформы виртуализации.
