Гиперконвергенция и СХД: горизонты применения

Традиционный подход к развертыванию ИТ-инфраструктуры предполагает сборку ИТ-систем из компонентов разных вендоров с дальнейшей настройкой их взаимодействия. Любая классическая ИТ-архитектура – это нелинейная система с множеством соединений между СХД, серверной частью и сетью. В рамках же гиперконвергентного подхода создается интегрированный комплекс по принципу «все в одном». Каждый узел кластера (сервер) содержит в одном корпусе систему виртуализации, сетевые компоненты и СХД.

Настройка или апгрейд классической ИТ-системы требуют проверки совместимости каждого компонента с остальными составляющими на уровне «железа» и ПО. Гиперконвергентные системы (ГКС) предоставляют готовую ИТ-среду «из коробки» для быстрого запуска приложений и развертывания баз данных. Настраивать взаимодействие между базовыми инфраструктурными компонентами в ГКС не нужно. При таком подходе уменьшается возможность отказа связки «железо + ПО». ГКС также проще эксплуатировать, масштабировать и модернизировать. 

Гиперконвергентные решения могут служить основой для создания корпоративных ИТ-систем с нуля, а также встраиваться в существующий цифровой ландшафт предприятия в качестве вспомогательного элемента. Например, при необходимости масштабирования системы для работы с «горячими» данными использовать ГКС может оказаться дешевле, чем закупать дополнительные диски нужного объема для СХД. 

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

Компаниям, проводящим цифровизацию, нет смысла наращивать свои компетенции, скажем, в СХД, целесообразнее сосредоточиться на проблемах основного бизнеса. ГКС в таком случае является оптимальным решением для экономии времени и фокусирования компетенций на ключевых рабочих задачах. 

Первоочередная проблема, которую нужно решить, – выработать базовый подход к ИТ в целом и системам хранения данных в частности. Мы акцентируем внимание на СХД в данном контексте по причине постоянно растущей роли данных практически в любой сфере деятельности. 

Расширенное использование цифровых инструментов в работе компаний, госструктур и частных лиц приводит к лавинообразному росту объемов данных, возникающих при их взаимодействии в онлайне и офлайне. Собранную информацию нужно не просто обрабатывать и хранить, но и делать это в соответствии с отраслевыми особенностями, требованиями регуляторов, а самое главное – экономически эффективно.

«Водораздел» между классическими и гиперконвергентными решениями в СХД проходит по следующим основным пунктам:

Пройдясь по этой шпаргалке, можно понять, что подойдет для решения поставленной задачи – ГКС или классическая ИТ-архитектура.

Далее следует в два этапа провести планирование. Первый этап – это выработка требований к ИТ-решению, т.е. их сбор и анализ. Второй – непосредственно сайзинг и конфигурирование самого решения.

Первый этап существенно важнее второго. Требования бизнеса к ИТ-решению – та отправная точка, которая определяет развитие всего проекта. В зависимости от того, сколько времени ИТ-система может быть недоступна без причинения критического ущерба бизнесу, от необходимого режима работы, от сроков хранения бэкапов выбирают тип и конфигурацию решения. 

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

Все зафиксированные бизнес- и технические требования надо проверить. Частая ошибка на этом этапе – после начала построения решения проводить его тестирование прямо по ходу работ. Тестировать надо до финального выбора подхода к проекту. То есть сформулировали требования – и сразу же проверили их выполнение на определенном типе решения в рамках пилотного проекта.

Тестирование можно провести на ресурсах пилотной зоны внутри организации или в облачной среде. Также с просьбой организовать пилотную зону можно обратиться к интегратору или к производителю оборудования. Любой подход поможет проверить требования и на базе полученной информации разработать профиль нагрузки и определить вычислительные мощности системы. 

Только после этого переходят к сайзингу, который начинается не с расчета конкретных показателей, а с выбора технологического подхода – ГКС или классическая СХД. 

Если с традиционными СХД сталкивались многие, то особенности гиперконвергентных систем необходимо описать подробнее. 

Распределенное хранилище в таком продукте позволяет объединять локальные диски серверов в пул для дальнейшего представления системе виртуализации. ГКС поддерживают дедупликацию, репликацию, снэпшоты и клоны, технологию стирающего кода (erasure coding), а также предоставление ресурсов хранения для внешних систем. Современные ГКС также позволяют использовать различные протоколы доступа к хранилищу (iSCSI, NFS, SMB) и допускают развертывание в нескольких ЦОДах с формированием так называемого метрокластера (metro cluster).

Как правило, минимальное количество нод – три. Три узла необходимы для надежной работы и обеспечения отказоустойчивости. Если выйдет из строя одна нода, а две другие продолжат нормально функционировать, то с данными в ГКС СХД все будет в порядке. Выбывшую ноду можно будет спокойно заменить, не останавливая работу системы. 

Если выбывают две ноды, важно иметь три копии данных. Но в этом случае запускается режим maintenance mode, когда потери придется восстанавливать вручную.

Что касается метрокластера, то ГКС могут поддерживать распределение как на уровне ЦОДов, так и ниже – вплоть до уровня стоек. Соответственно, можно распределять их по зонам, или создавая классический метрокластер, или формируя отдельные отказоустойчивые блоки. Самое главное здесь – наличие хорошей сети. В традиционных СХД ситуация в принципе аналогичная, но в ГКС этому аспекту уделяется больше внимания.

Применимость традиционного и ГКС-подхода к практическим задачам можно представить следующим образом. 

Стандартные инфраструктурные сервисы – служба каталогов, небольшие почтовые серверы, СЭД, файловые серверы, средних размеров СУБД, любые распределенные вычисления, облачные системы – хорошо ложатся на формат ГКС с точки зрения общей производительности и специфических задач СХД. А вот масштабные enterprise-системы разворачивать на ГКС смысла не имеет. 

Гиперконвергентный подход прекрасно подходит для ИТ-задач филиальных сетей, когда нужно организовать стандартную отказоустойчивую инфраструктуру в каждом региональном подразделении. При этом строить в каждом филиале инфраструктуру из СХД, коммутаторов, серверов и гипервизора – долго, сложно и неудобно. Поэтому ГКС как формат «все в одном» позволяет оперативно «поднять» все необходимые ИТ-ресурсы. Далее их также просто синхронизировать и реплицировать данные из всех филиалов. 

Благодаря своей динамичности ГКС хорошо решает и задачи тестовых сред: если компании нужно что-то создавать, тестировать и масштабировать, проверять совместимость с legacy-системами, то тестирование лучше проводить в ИТ-средах на базе ГКС.

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!

<< Предыдущая статья   Вернуться к содержанию   Следующая статья >>