Дмитрий Хороших, менеджер по развитию бизнеса в области решений для ЦОД, Cisco
Модернизация вычислительной платформы современного ЦОД – сегодня это почти непрерывный процесс. Ушли те времена, когда обновление серверного парка проводилось раз в 3–4 года, сегодня новые приложения внедряются постоянно. Это требует от ИТ-подразделения наличия четкого плана по развитию. О том, как его создать и поддерживать, мы с вами сегодня и поговорим.
Прежде чем приступать к модернизации существующего ЦОД, следует четко определиться с задачами, которые при этом хочется решить. Нередко сотрудники ИТ-подразделения думают только о том, «чтобы все работало». В таком случае чаще всего просто покупаются новые серверы, системы хранения, производится миграция нагрузки, и все остается «как есть» до следующего обновления. Этот процесс только на бумаге выглядит просто, на деле же он затягивается на месяцы, а иногда может растянуться и на пару лет. Все это время команда эксплуатации живет в состоянии непрекращающегося цейнтнота, занимаясь решеним постоянно возникающих проблем и «тушением пожаров». Ни о каком проактивном развитии инфраструктуры при этом, как правило, не может быть и речи. Компания, конечно, получает кое-какие преимущества от того, что оборудование стало быстрее, а хранение дешевле, но эти преимущества сложно назвать значительными.
На этом фоне выгодно выделяются компании, которые в противоположность такому подходу решают, что обновление инфраструктуры ЦОД должно попутно приносить существенное упрощение процессов обслуживания, расширения и ежедневной экплуатации инфраструктуры дата-центра. И сегодня уже существуют технологии, которые позволяют этого достичь. Достаточно лишь архитектурно «разобрать» существующую инфраструктуру на составляющие и «собрать» ее заново, заменив, где возможно, морально устаревшие технологии на современные. Основной вопрос в этом случае: вокруг чего осуществлять такую «сборку»? Традиционно все процессы в ЦОД происходили вокруг приложений – ведь они напрямую связаны с автоматизацией задач бизнеса, фокус на приложения позволял проще подходить к обоснованию бюджетов на модернизацию и эксплуатацию ЦОД. Однако в последние несколько лет становится более ощутимым фокус на данные, которые накапливаются и обрабатываются в компании. Поэтому, если мы планируем архитектуру ЦОД на следующие 5–10 лет, фокус на данные, их типы и характеристики будет сегодня наиболее правильным. Также для однотипных данных можно использовать одинаковые процедуры обеспечения отказоустойчивости, резервного копирования и автоматизации работы – это еще одно преимущество разделения систем в ЦОД по типам данных. Все это вместе дает компании существенную экономию на процессах эксплуатации информационных систем, позволяя высвободить ресурсы для развития.
Данные почти любой современной компании можно отнести к одному из следующих типов.
- Высоконагруженные серверы, невиртуализированные СУБД. Зачастую этих данных не очень много, но они критически влияют на ведение основного бизнеса компании. Простой таких систем или существенное замедление работы часто череваты оттоком клиентов или прямыми финансовыми потерями. Поэтому естественно, что все внимание службы эксплуатации большую часть времени состредоточено на работе именно этих систем. Автоматизация даже небольших, но повторяющихся операций по поддержке этой части инфраструктуры способна значительно упростить жизнь ИТ-департаменту и освободить время для планирования будущего развития.
- Платформа виртуализации, диски виртуальных машин. Последние несколько лет внедрение виртуализации идет массовыми темпами, благодаря чему сегодня эти данные, как правило, занимают наибольший объем в современной компании. Несмотря на то что платформа виртуализации позволяет абстрагировать «железо» от ПО, эксплуатация именно этой части инфраструктуры часто доставляет наибольшую головную боль ИТ подразделению. Основной причиной этого является отсутствие в компании развитых инструментов аналитики и автоматизации управления серверами, СХД, сетями SAN, а также сложные механизмы обеспечения отказоустойчивости. Расширение такого комплекса тоже зачастую представляет собой отдельный проект, отнимающий время и ресурсы. Именно здесь современные гиперконвергентные решения позволяют получить настоящий прорыв и модернизация ЦОД – удобный момент, чтобы эти решения применить. Бизнес-приложения, работающие в виртуализованной среде, также могут быть критичными для бизнеса, и сегодня существуют технологии, позволяющие обеспечить для них нулевое время простоя даже при полном отключении одного из центров обработки данных, если, конечно, у компании есть резервный.
- Вторичные данные. Это самый противоречивый тип данных, ему сложно дать точное опредение. В любой компании найдутся данные, которые не влияют напрямую на бизнес, но которые все равно нужно как-то хранить, обрабатывать, защищать, – файловые хранилища, архивы документов, различные медиаданные. Фотографии с прошлогоднего корпоратива или фото открытия нового завода на первый взгляд выглядят как не самая важная информация. Но где их искать, если через пару лет маркетинг решит выпустить памятный альбом об истории развития компании? Естественным образом возникает вопрос надежного долговременного хранения таких данных, причем желательно с наиболее низкой стоимостью за единицу объема. Сегодня существуют различные системы для управления подобным вторичным документооборотом, одна из которых – Cohesity предлагается закачикам в рамках портфолио компании Cisco. Кстати говоря, эти же решения в последний год предлагается использовать и для хранения резервных копий данных, ведь их тоже желательно хранить отказоустойчивым образом.
- Большие данные. Несмотря на снижение публичного интереса к теме больших данных, все больше компаний начинают их реальное практическое использование. Форма этого использования может быть различной: кто-то только строит системы сбора и накопления таких данных, надеясь приступить к анализу в следующие несколько месяцев; другие компании уже активно наполняют свои «озера данных» (Data Lake) и уже сегодня развивают внутреннюю экспертизу по их анализу. Инфраструктура под такие системы обычно создается независимо от основных ИТ-платформ, развивается довольно хаотично и обслуживается силами команды, занимающейся анализом данных. Однако рано или поздно возникает задача по передаче этого комплекса в эксплуатацию основному ИТ-подразделению, и желательно на этом этапе как-то унифицировать инфраструктуру. Компания Cisco предлагает своим заказчикам для этих целей готовые законченные аппаратно-программные комплексы под Hadoop и другие платформы для работы с большими данными. Причем такой комплекс может быть целиком, включая ПО, поставлен и взят на поддержку Cisco, что облегчает ИТ-подразделению задачу поддержания его работоспособности.
Конечно, разделение данных на указанные категории достаточно условно, более того – сегодня почти любая новая информационная система в ЦОД, как правило, начинается с набора виртуальных машин, т. е. на начальном этапе жизненного цикла относится к категории «платформа виртуализации». Виртуализация стала той средой, которая позволяет легко опробовать новые инструменты, чтобы составить мнение об их полезности для компании. Именно поэтому очень важно, чтобы платформа виртуализации обладала гибкими возможностями по масштабированию и отказоустойчивости, а также гибкостью в построении различных конфигураций.
Одним из ключевых критериев, который может определять отнесение данных к конкретной категории, может быть стоимость их хранения и обработки. К примеру, файловые папки зачастую не требуют высокой скорости доступа, поэтому даже если хранилище документов начиналось на стадии пилотного проекта как набор виртуальных машин Cohesity на платформе виртуализации, то по мере роста будет иметь смысл перенести их на выделенные серверы, чтобы снизить общую стоимость работы с этими данными. Аналогично внутри платформы виртуализации данные могут расслаиваться по различным кластерам, например отдельным системам на вращающихся дисках и All Flash, для оптимизации стоимости хранения и обработки. Это нормальный процесс в жизненном цикле любой ИТ-системы. И если выбранная компанией платформа его поддерживает, это позволит сэкономить в будущем много ресурсов на этапе эксплуатации системы. При этом сама миграция виртуальных машин между кластерами различных уровней может, конечно, производится средствами ПО виртуализации.
После того как мы смогли разделить наши данные на указанные категории: фокусные высоконагруженные СУБД, диски виртуальных машин или контейнеры, файловые хранилища, – следующим шагом становится выбор наиболее подходящего решения для каждой из систем. В этом заказчикам Cisco может помочь документ по дизайну архитектуры центров обработки данных (Datacenter design playbook), доступный по адресу http://cs.co/dc-design-playbook . В нем собрана информация обо всех готовых дизайнах (Cisco Validated Design) для построения отдельных подсистем ЦОД.
Рассмотрим наиболее популярные решения.
Задача поддержки высоконагруженных или невиртуализированных СУБД проработана на сегодняшний день наиболее хорошо. Для этого сегмента приложений уже давно существуют типовые апробированные решения. В частности, у Cisco эти решения выражены типовыми готовыми дизайнами, созданными совместно с производителями различных систем хранения. Flexpod вместе с Netapp, VersaStack c IBM, Flashstack с Pure Storage – вот лишь небольшой список типовых решений. Каждое из них представляет собой готовую оттестированную архитектуру с понятными критериями масштабирования и обширной документацией, описывающей как собирать, инсталлировать и эксплуатаирвать комплекс сам по себе, а также в качестве платформы для различных приложений. Самая подробная информация по этому классу решений содержится в документе Cisco Datacenter Design Playbook, ссылка на который была дана выше.
Платформы виртуализации и хранение образов дисков виртуальных машин. Для этого сегмента в последние 10 лет вышло рекордное количество инновационных решений. Фокус у таких решений самый различный: одни вендоры нацеливают свои решения на виртуализацию всего и вся, пытаясь дать своим заказчикам возможность строить платформу из любого «железа», которое оказалось под рукой. При таком подходе основная характеристика, которой заказчику приходится жертвовать, – это производительность итоговой платформы. Другие идут по пути разработки специализированных аппаратных компонентов, позволяющих достигнуть более высоких скоростей на небольшом количестве прикладных задач. Компания Cisco при разработке своего решения для платформ виртуализации решила сфокусироваться на максимальной производительности итоговоговой системы и оптимизации затрат на ее эксплуатацию, так как именно эти характеристики важны для большинства заказчиков, разворачивающих корпоративные приложения. Поговорим об этом решении подробнее.
Cisco Hyperflex является гиперконвергентной платформой для систем виртуализации. Термин «гиперконвергентная» означает, что для хранения данных используются внутренние диски серверов, а не внешняя СХД. Также автоматически отпадает необходимость во внешней сети хренения данных. Все функции по организации отказоустойчивого хранения данных, обычно выполняемые аппаратно, в случае Hyperflex реализуются программно на тех же серверах. В результате заказчики получают простую, горизонтально масштабируемую платформу виртуализации, которая при этом еще и ориентирована на вычислительную нагрузку довольно высокого уровня. Достаточно сказать, что, по данным открытого опроса среди заказчиков Hyperflex (а их в мире уже более 3,5 тысяч), более 15% опрошенных используют систему для запуска СУБД или других критичных для инфраструктуры приложений. Учитывая, что еще два года назад системы подобного класса ни для каких нагрузок, кроме VDI, не рассматривались в приципе, это очень неплохой показатель. По данным других открытых тестов независимой компании Enterprise Storage Group (в частности, только что вышедшего теста All NVMe конфигурации http://cs.co/hx-nvme-test ), сегодня платформа Hyperflex может быть полноценной заменой традиционного подхода даже для достаточно требовательных приложений.
Об архитектуре Cisco Hyperflex в последнее время было много написано в различных изданиях, поэтому здесь мы остановимся только на наиболее интересных фактах.
- Платформа строится из готовых блоков, выполненных на базе серверов Cisco C-серии. Конфигурация блоков является фиксированной с точки зрения дисковой подсистемы сервера, при этом заказчику предоставляется возможность не устанавливать все диски сразу, а добавлять их на ходу по мере роста системы. По памяти и процессорам заказчик полностью свободен в своем выборе и может ориентироваться на необходимое количество ресурсов.
- Существуют несколько типов блоков, которые отличаются типом жестких дисков (HDD, SSD, NVMe) и их максимальным количеством на 1 сервер (10 или 24). Это позволяет заказчику выбирать скорость и емкость дисковой подсистемы итогового решения из довольно широкого диапазона вариантов.
- Система имеет 4 степени свободы по масштабированию: можно наращивать количество узлов с дисками в кластере либо добавлять бездисковые узлы с процессорами и памятью для специальных задач. Например, в вышедшей в конце апреля версии ПО Hyperflex0 появилась поддержка сервера C480ML в качестве бездискового узла Hyperflex-кластера. Это позволяет использовать гиперфлекс в том числе для работы с задачами машинного обучения. Еще одним вариантом расширения емкости кластера, на этот раз дисковой, является подключение к нему через сеть SAN дискового тома с внешнего дискового массива. Такой подход позволяет добавлять внешние архивные данные без необходимости жертвовать для их обработки внутренним дисковым пространством кластера. Также этот подход позволяет упростить процесс миграции: можно в рамках одной системы применять и конвергентный, и гиперконвергентный подходы. Четвертым вариантом масштабирования является подключение нескольких кластеров с единой паре Fabric Interconnect. Это позволяет накрыть единым зонтиком управления несколько гиперконвергентных систем, а заодно сэкономить на сетевом уровне. Фабрика UCS (та самая пара Fabric Interconnect) в этом случае также выполняет функцию сети уровня доступа.
- В кластере Cisco Hyperflex всегда по умолчанию включены дедупликация и компрессия, независимо от того, используются узлы с вращающимися дисками или All Flash. Эти две функции включены всегда, более того, все тесты производительности Hyperflex всегда публикуются с включенными дедупликацией и компрессией. В общем случае эти две функции сокращают объем данных на дисках примерно в 1,5 раза, т. е. из условных 100 байт, записанных виртуальными машинами, на диск пишутся 45–50. Это позволяет существенно экономить необходимое количество дисковых накопителей в серверах по сравнению с решениями других производителей.
- Hyperflex поддерживает два режима репликации данных между территориально распределенными системами – синхронный и асинхронный. Оба режима требуют для своей работы только наличия L3-связности между двумя системами. Для работы синхронной репликации двум системам необходимо соединение на скорости 10 Гбит/сек и задержка времени прохождения сигнала (RTT – round trip time) не более 5 мс. Для асинхронной репликации и этого не нужно: достаточно только того, чтобы две системы могли обмениваться пакетами на 3-м уровне сети. Настройка механизмов репликации выполняется из единого интерфейса и занимает не более нескольких минут. Только на одной это процедуре заказчики получают значительные преимущества в трудозатратах на экплуатацию Hyperflex по сравнению с традиционной схемой: сервер – Сеть SAN – дисковый массив.
- Hyperflex может интегрироваться с внешними системами резервного копирования, такими как Veeam, Commvault, Cohesity, при этом для увеличения скорости создания резервных копий используется технология мгновенных снимков (Shapshots) на уровне самого гиперфлекса, а не платформы виртуализации. Такой подход позволяет уменьшать длительность окна резервного копирования для отдельно взятых виртуальных машин.
Все эти факты в совокупности с простотой системы и высоким уровнем автоматизации типовых операций приводят к тому, что после перехода на Cisco Hyperflex у ИТ-специалистов заказчика появляется значительно больше времени, которое они могут использовать на развитие инфраструктуры.
Вторичные данные компании
Для хранения таких данных чаще всего используются файловые папки на одном из существующих дисковых массивов либо отдельные NAS-хранилища. В первом случае не очень продуктивно используются дорогостоящие ресурсы СХД, такие как дисковое пространство и ресурсы контроллера. Во втором – заказчик по мере роста инфраструктуры получает несколько разобщенных хранилищ, которые нужно администрировать, а также обеспечивать защиту хранящейся на них информации. Общим минусом обоих подходов является то, что данные никак не отслеживаются, из-за чего со временем возникает множество дубликатов, что также ведет к увиличению расходуемого дискового пространства.
Решить эту проблему также помогает гиперконвергентный подход. С недавнего времени в портфолио компании Cisco существет продукт Cohesity, он предназначен для работы с вторичными данными в масштабах всей компании, при этом обеспечивается полная прозрачность жизненного цикла данных между основным офисом и филиалами, если они есть. В качестве аппартной платформы можно использовать виртуальные машины на базе Hyperflex или отдельные физические серверы. Система позволяет видеть все данные компании в едином интерфейсе, с возможностью настройки репликации данных между различными площадками, если это необходимо. Также есть возможность подключения облачного хранилища, если заказчик хочет настроить резервное копирование данных во внешнее облако.
Все хранимые данные дедуплицируются и сжимаются, что также позволяет экономить дисковое пространство и тем самым снижать совокупную стоимость хранения на единицу объема данных.
Руководство к действию
Разделение данных на три описанные выше группы позволяет выработать план постепенной модернизации инфраструктуры сегодняшнего ЦОД. Проще всего, если данные компании уже как-то упорядочены, но зачастую это не так, потому, перед тем как приступать к планированию, необходимо сделать минимальный аудит инфраструктуры. Фокус на данные позволяет выстроить этот процесс достаточно прозрачно и подойти к нему формализованно, так что многие компании могут выполнить его своими силами. Основная цель подобного аудита – выяснить, какое количество данных каждого типа есть в компании. Это поможет понять, какие преобразования позволят получить максимальный эффект в ближайшей перспективе. Из опыта общения с заказчиками: наиболее острая проблема ИТ-инфраструктур сегодня – построение масштабируемой платформы виртуализации, именно поэтому тема гиперконвергенции сегодня и получает такое распространение. Вторая по значимости проблема – хранение и управление вторичными данными, хотя у многих заказчиков она все чаще выходит на первое место.
Вне зависимости от того, какое направление модернизации инфраструктуры выбрано, имеет смысл посмотреть, какие из существующих частей могут быть использованы для сокращения стоимости модернизации. Так, если заказчик уже имеет серверную инфраструктуру Cisco на основе фабрики UCS, эта же фабрика может быть использована для подключения любых новых серверов. В таком случае сохраняются вложения в фабрику и вся вновь создаваемая инфраструктура находится в единой модели управления. Еще одним очевидным преимуществом подобного подхода является то, что подключения к сетевому ядру ЦОД производятся по единой схеме, агрегированными каналами, а все сетевые настройки этих подключений производятся в тех же сервисных профилях, с помощью которых настраиваются серверы. Это уменьшает количество точек управления и в итоге снижает совокупную стоимость владения серверной платформой.
Если же система пока еще не содержит фабрики UCS, то ее внедрение заложит хороший фундамент для будущего роста и развития серверной инфраструктуры ЦОД.
В рамках этой статьи рассмотрена только часть задач по модернизации инфраструктуры центра обработки данных, ее вычислительных подсистем. В дальнейшем мы рассмотрим те изменения, которые происходят в сетевой инфраструктуре современного ЦОД.
