Введение

Что делать, если объёмы данных растут, а бюджет не резиновый? Многим организациям кажется, что надёжное хранение больших данных возможно только на дорогих специализированных системах хранения (SAN). Но эпоха, когда хранение данных без SAN означало идти на компромисс в надёжности, осталась позади. Представьте, что вы можете собрать отказоустойчивое хранилище из обычных серверов – словно конструктор LEGO, где каждый элемент добавляет прочности и объёма. Звучит фантастично? Программно-определяемое хранилище (Software-Defined Storage, SDS) превращает эту фантастику в реальность, позволяя построить надёжный кластер хранения на стандартном железе и забыть про точку отказа.

SDS – это подход, при котором всё «волшебство» надёжности и управления данными выполняет программное обеспечение, а не дорогое специализированное оборудование. Проще говоря, мы берём несколько обычных серверов с дисками, устанавливаем на них специальное ПО – и получаем единое отказоустойчивое хранилище с автоматической репликацией данных и масштабируемостью. В этой статье мы разберёмся, как работает такой SDS кластер, обсудим популярные open-source решения вроде Ceph и GlusterFS, узнаем, в чём секрет его отказоустойчивости и масштабируемости, какие требования предъявляются к сети и дискам, а главное – посмотрим реальные сценарии применения. Вы увидите, что построить современное хранилище данных можно даже на арендованных серверах – без многомиллионных затрат на SAN.

Ceph: масштабируемое объектное хранилище

Одним из самых известных решений в мире SDS является Ceph. Это открытая (open-source) платформа, которая позволяет объединить десятки и сотни серверов в единый пул хранения. Ceph изначально разработан как масштабируемое объектное хранилище (object storage), но поддерживает и блочные устройства (RBD) для виртуальных машин, и файловую систему (CephFS). Проект развивается сообществом при поддержке крупных игроков рынка: так, компания Red Hat инвестирует в развитие Ceph и выпускает его коммерческую версию для предприятий.

Главная сила Ceph – масштабируемость и отказоустойчивость по умолчанию. Данные в кластере Ceph разбиваются на объекты и автоматически распределяются по серверам с помощью алгоритма CRUSH (он как шеф-повар, который раздаёт «куски» данных на хранение по определённому рецепту). Этот алгоритм позволяет обойтись без центрального узла учёта данных: нет единой таблицы размещения, вместо неё – математическая формула, вычисляющая, где лежит объект. Что это даёт? Во-первых, нет единой точки отказа – даже если один сервер выйдет из строя, кластер знает, как восстановить утраченные копии данных на других узлах. Во-вторых, можно добавлять новые серверы (узлы) и диски, и Ceph автоматически включит их в работу, перераспределив часть объектов – кластер растёт без простоя и миграций. Хотите хранить петабайты данных так же, как это делают крупнейшие облачные провайдеры? Ceph справится с этой задачей.

Ceph часто выбирают для облачных инфраструктур и виртуализации. Не случайно практически все вендоры OpenStack-систем сходятся во мнении, что Ceph – оптимальная платформа хранения образов виртуальных машин и данных приложений в частных облаках. Иными словами, Ceph зарекомендовал себя как надёжное хранилище для виртуализации. Если у вас есть кластер гипервизоров (KVM, Proxmox, OpenStack) – интеграция с Ceph позволит хранить диски VM в распределённом хранилище: ни один сервер не является для них «single point of failure». Вдобавок Ceph поддерживает моментальные снимки (snapshots) и тонкое выделение объёма (thin provisioning), что удобно для резервного копирования и быстрого клонирования VM. Недаром Ceph называют одним из королей open-source кластеров хранения данных – он даёт максимум гибкости и надёжности, хотя требует тщательной настройки и мощной сети.

GlusterFS: распределённое файловое хранилище

Другой яркий представитель мира SDS – GlusterFS. Если Ceph похож на швейцарский нож (умеет всё, но сначала надо разобраться с множеством функций), то GlusterFS – это надёжный топор: простое решение для распределённого файлового хранилища, которое можно развернуть без долгих настроек. GlusterFS изначально создан для scale-out файлового хранения: он предоставляет единый виртуальный том, объединяющий диски разных серверов, и этот том можно смонтировать по стандартным протоколам (NFS, CIFS через Samba, или собственным клиентом FUSE) как одну большую сетевую папку. Внутри же GlusterFS управляет хранением просто: файлы нарезаются на куски и хранятся на нескольких серверах по принципу хеширующего распределения. Каждый сервер в Gluster выполняет роль хранилища (brick), а совокупность brick’ов образует единый объем.

GlusterFS ценят за удобство: стартовать кластер можно с двух узлов (например, для зеркального хранения – когда каждый файл дублируется на обоих серверах), а затем масштабировать до десятков узлов по мере роста данных. Никаких центральных метаданных-серверов нет – информация о том, где лежит файл, распределена между узлами. За счёт этого GlusterFS, как и Ceph, не имеет единой точки отказа и продолжает работать даже при выходе из строя части оборудования. При этом отказоустойчивость легко регулируется: можно задать, сколько копий данных хранить (2, 3 или больше), либо использовать режим разбиения данных с избыточностью (аналог RAID5/6, называемый Disperse/Erasure Coding). GlusterFS отлично подходит для сценариев, где требуется общее файловое пространство для множества клиентов. Например, медиакомпания может хранить видеоролики на SDS кластере из GlusterFS, и монтажёры будут работать с единым каталогом, не задумываясь, на каком сервере лежит каждый файл – данные реплицируются автоматически. А для отделов, привыкших к сетевым шарам Windows, Gluster предлагает совместимость с SMB – пользователи увидят привычную папку, за которой скрывается целый кластер.

По производительности GlusterFS при правильной настройке способен выдавать впечатляющие результаты, особенно на быстрых сетях. Есть примеры компаний, которые хранят сотни терабайт неструктурированных данных на GlusterFS-кластере и получают и высокую скорость доступа, и удобство масштабирования. Конечно, у GlusterFS несколько более узкая специализация по сравнению с Ceph: он ориентирован преимущественно на файловый доступ и относительно «умеренные» масштабы, тогда как Ceph блестяще чувствует себя в гипермасштабных установках и в роли объектного хранилища. Зато порог входа у GlusterFS ниже – с ним может справиться и небольшой IT-отдел без глубоких знаний в storage-системах.

Отказоустойчивость: данные под надёжной защитой

SDS кластер ценится прежде всего за отказоустойчивость. В традиционной схеме хранения один сервер или стоечный массив хранит данные – и если с ним что-то случится, мы рискуем потерять информацию или остановить сервисы. А что делает SDS? Он распространяет данные по нескольким узлам и поддерживает заданное число копий. Представьте семейный фотоархив, который вы сохранили на трёх разных жёстких дисках: шанс одновременного выхода из строя всех трёх крайне мал – значит, ваши снимки в безопасности. Так и кластер SDS обычно хранит 2–3 копии каждого блока данных на разных серверах. Если вдруг один сервер «падает» (а это неизбежно случается рано или поздно), система автоматически берёт данные из уцелевших копий и начинает восстанавливать недостающую копию на оставшихся рабочих узлах. Пользователи при этом ничего не замечают – разве что скорость доступа может немного снизиться на время восстановительного процесса.

Важно отметить: настоящая отказоустойчивость требует не только репликации, но и устранения единой точки отказа во всех элементах системы. SDS-подход подразумевает, что отказ одного компонента не приводит к остановке всего хранилища. Поэтому грамотное развертывание включает минимум 3 узла (чтобы выдержать выход из строя одного и всё равно иметь 2 копии данных; либо выдержать потерю даже двух узлов при схеме с тремя копиями). Кроме того, контролирующие сервисы кластера (например, мониторы Ceph или менеджеры GlusterFS) тоже разворачиваются в нескольких экземплярах для высокой доступности. В итоге мы получаем хранилище без единого «болевого» центра: выйдет из строя диск – данные прочитаются с другого; откажет целый сервер – его роль возьмут на себя соседи по кластеру.

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

Масштабируемость: рост без границ

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

Такой подход означает, что вы можете начать с малого (например, кластер из трёх машин) и постепенно наращивать его, без длительных простоев и миграций данных на новые устройства. В мире традиционных SAN вы часто упираетесь в ограничение контроллера или шасси: условно, есть место под 24 диска – заполнили, дальше только покупка новой полки (и ещё не факт, что она совместима с вашим контроллером). В SDS подобных «стен» просто нет. Ваше масштабируемое хранилище может состоять из десятков и сотен узлов, и если изначально хватало трёх, а через год понадобилось десять – вы просто добавляете новые серверы, интегрируя их в кластер. Смена оборудования тоже упрощается: можно плавно вывести старые узлы из эксплуатации, заменяя их новыми, без остановки доступа к данным.

Масштабируемость SDS ценна не только объёмом, но и производительностью. Ведь добавляя узел, вы увеличиваете не только терабайты, но и суммарную пропускную способность и количество операций ввода-вывода. Каждый новый сервер приносит свои ресурсы – CPU для обработки запросов, сетевую карту для передачи данных, диски для операций ввода-вывода. Таким образом, производительность растёт пропорционально размеру кластера. Это особенно актуально для задач, оперирующих большими данными, и тех же резервных копий: по мере роста нагрузок вы масштабируете инфраструктуру постепенно, избегая ситуаций, когда одно хранилище стало «узким местом» всей системы.

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

Требования к сети и оборудованию

Развернуть SDS кластер на обычных серверах – идея отличная, но есть нюанс: от качества «обычного» железа во многом зависит успех. Программно-определяемое хранилище отвязывает нас от дорогих проприетарных аппаратов, но не отменяет законов физики. Главный из них – узким местом станет самая медленная часть системы. Чаще всего это сеть.

Сеть – кровеносная система любого SDS-кластера. Узлы постоянно обмениваются данными: реплицируют блоки, синхронизируют состояние. Если соединить их старым добрым Gigabit Ethernet, кластер, конечно, будет работать – но скорость доступа к данным может разочаровать. Для серьёзных внедрений рекомендуется как минимум 10-гигабитная сеть между серверами, а в идеале – 25 Гбит/с и выше, особенно если планируется использование SSD-хранилищ. Имейте в виду: когда несколько клиентов одновременно читают и пишут данные, трафик распределяется по узлам, и суммарная нагрузка на сеть может быть очень высокой. Выделенная сеть для хранилища – хорошая практика: отделите трафик между узлами от пользовательского, чтобы они не мешали друг другу. Кроме пропускной способности, важна задержка: низкие latency ускоряют протоколы репликации и случайные операции. Здесь помогут качественные сетевые карты (с поддержкой RDMA/RoCE, если позволяет бюджет) и быстрые коммутаторы. И не забывайте о резервировании: как минимум два линка от каждого сервера к разным свичам, чтобы отказ одного сетевого устройства не “уронил” весь кластер.

Диски и серверы – второй фундамент. SDS прекрасно работает на коммодити-оборудовании, но это не значит, что годятся любые списанные машины. Практика показывает, что чрезмерная экономия на железе может выйти боком: лучше сразу заложить серверы с запасом по CPU и RAM (службы кластера тоже потребляют ресурсы, особенно Ceph – он любит оперативную память для кэширования). Диски стоит выбирать надёжные, серверной серии – ведь они будут непрерывно нагружены. Для ускорения можно комбинировать SSD и HDD: например, в Ceph журналы (WAL/DB) выносить на NVMe-SSD, а сами данные хранить на ёмких HDD; либо использовать SSD-пулы для горячих данных и SATA-диски для холодных архивов. GlusterFS также позволяет применять SSD как кэш. Главное – следить за балансом: не имеет смысла ставить ультрабыстрые NVMe, если сеть между узлами узкая, или наоборот, вкладываться в 100-гигабитный Ethernet, храня всё на медленных 5400 RPM HDD. Планируйте конфигурацию сбалансировано под свои задачи.

Подытожим основные рекомендации по инфраструктуре SDS-кластера:

• Выделенная скоростная сеть. Желательно 10 GbE и выше, отдельная от пользовательской, с резервированием (две коммутационные линии на каждый узел).
• Достаточно узлов для надёжности. Минимум три сервера, чтобы кластер пережил выход из строя одного. Для больших установок продумывайте зоны отказа (failure domains) – распределяйте данные по разным стойкам или узлам.
• Баланс производительности дисков и сети. Используйте быстрые SSD там, где нужны высокие IOPS (метаданные, журналы), HDD – для объёма. Убедитесь, что сеть справится с трафиком от этих дисков.
• Аппаратный резерв. Иметь наготове запасные диски и узлы либо чёткий план замены. SDS сам восстановит данные при сбое, но лучше заменить проблемное железо до полного отказа – так восстановление пройдёт быстрее и менее заметно.

Помните, что SDS не требует элитного «золотого» железа, но и чудес не совершает: производительность и надёжность вашего кластера будут ровно такими, насколько хорошо спроектирована и реализована его инфраструктура.

Сценарии использования SDS

Итак, мы обсудили, как устроено программно-определяемое хранилище и из чего «варится» надёжный кластер. Пора ответить на главный вопрос: где это применять? Рассмотрим несколько реальных сценариев, в которых SDS раскрывает свои сильные стороны:

1. Хранилище для виртуализации и облаков. Как уже упоминалось, SDS-кластеры отлично подходят для хранения дисков виртуальных машин, контейнеров и вообще всего, что нужно гибко и надёжно хранить в инфраструктуре виртуализации. Представьте частное облако, где десятки гипервизоров запускают сотни VM. Вместо того чтобы каждая физическая машина имела своё локальное хранилище или подключалась к единственному дорогому SAN, вы поднимаете единое распределённое файловое хранилище на базе Ceph или GlusterFS. Все гипервизоры читают и пишут образы VM в этот кластер – и если один узел хранилища выходит из строя, данные не теряются, виртуалки продолжают работу (их можно перезапустить на других гипервизорах). Такой подход повысил отказоустойчивость множества облачных сервисов. Недаром хранение данных без SAN постепенно становится нормой в современных дата-центрах – и SDS здесь играет ключевую роль.
2. Резервные копии и архивы. В любой организации есть бэкапы – от баз данных до почтовых ящиков – и объём этих резервных копий только растёт. SDS-кластер прекрасно справляется с ролью большого “бака” для резервных копий и архивных данных. Во-первых, благодаря дешевизне масштабирования: вместо покупки специализированного устройства для backup можно рассмотреть такой шаг, как аренда серверов для хранения данных – при необходимости вы просто берёте в аренду дополнительный сервер и добавляете его в кластер. Это значительно дешевле, чем приобретать ещё один проприетарный storage: практика показывает, что использование стандартных x86-серверов и дисков снижает первоначальные затраты на систему хранения на 30–50%. Во-вторых, репликация в SDS обеспечивает спокойствие: копии данных не пропадут из-за сбоя одного из узлов. Дополнительно можно настроить гео-репликацию – например, синхронизировать резервное хранилище с другим офисом или облачной площадкой. Тогда даже в случае серьёзного ЧП (например, пожар в дата-центре) у вас останется актуальная копия данных.
3. Распределённое файловое хранилище для компании. Многие организации сталкивались с ситуацией, когда на файловом сервере заканчивается место, и приходится судорожно чистить “файлопомойку” или докупать новое NAS-устройство. SDS решает эту проблему элегантно. Вы можете развернуть отказоустойчивый кластер хранения для отдела или всей компании, где пользователи будут складывать документы, изображения, проекты – и по мере роста объёмов просто расширять его. Плюс – исчезает единая точка отказа: сотрудники продолжают иметь доступ к общим файлам даже если один из серверов кластера выйдет из строя. GlusterFS в роли такого офисного решения уже успешно используется на практике. А для распределённых команд SDS даёт возможность объединить файловое пространство между филиалами: скажем, часть кластера стоит в Европе, часть – в Америке, и данные дублируются между ними (для пользователей это прозрачно, они просто быстрее получают доступ к ближайшему узлу). В эпоху удалённой работы и глобальных команд такой подход к хранению данных становится всё более востребованным.

Конечно, это лишь часть возможных сценариев. Open-source кластер хранения на обычных серверах универсален: его можно адаптировать под задачи видеонаблюдения (писать поток с камер сразу на несколько узлов, чтобы не потерять запись), под нужды больших данных (где важно параллельно обрабатывать информацию прямо там, где она хранится), под веб-хостинг (раздавать статичные файлы сайтов из отказоустойчивого хранилища) и многое другое. SDS – это про гибкость, и вы сами решаете, как использовать этот инструмент.

Вывод: своё хранилище без лишних затрат

Эра, когда за надёжность данных отвечала исключительно дорогая «железная» коробка от именитого вендора, уходит в прошлое. Программно-определяемое хранилище демонстрирует, что можно добиться той же (а порой и большей) гибкости, отказоустойчивости и эффективности, опираясь на силу софта и сообщества, а не на стоимость оборудования. Мы рассмотрели, как Ceph и GlusterFS позволяют собрать мощный кластер из обычных машин, как такой SDS кластер переживает сбои и растёт вместе с вашими потребностями, и где он особенно полезен.

Самое приятное – начать можно с малого, буквально с нескольких серверов. Оцените свои задачи: нужны быстрые диски или много места? Какой уровень отказоустойчивости вам необходим? Подберите open-source решение под эти критерии и протестируйте его в деле. Благодаря гибкости SDS вы ничем не рискуете: не понравится одно – переключитесь на другое, не устроит производительность – масштабируйте кластер или оптимизируйте конфигурацию. Никакого vendor lock-in и многолетних лизингов – только вы и ваши задачи.

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

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