Привет, Хабр! Меня зовут Даниил Киселёв, я специалист по техническому сопровождению Space. В этой статье я на практическом примере покажу, как в SpaceVM собрать программно-определяемое кластерное хранилище. Рассмотрим типовую конфигурацию, учитывая, что в реальном продакшене параметры и архитектурные решения могут отличаться.

Бизнес ожидает от СХД простых характеристик — чтобы данные были доступны всегда, а сбои и обслуживание не останавливали работу виртуальных машин и сервисов. Именно поэтому программно-определяемые хранилища становятся распространенным инструментом. На примере SpaceVM разбираем, как за считанные минуты собрать отказоустойчивое кластерное SDS, которое решает сразу несколько ключевых задач: снижает стоимость владения и обеспечивает стабильную работу в реальных условиях эксплуатации.

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

Они не только дешевле в принципе – экономия становится еще заметнее, если приходится иметь дело с неструктурированными данными. Есть и другие преимущества: можно абстрагироваться от аппаратной платформы и успешно побороть пресловутый vendor-lock. (это особенно важно в России), компании куда проще обеспечить независимость от вендорских санкций.

Рассказываем о своем опыте ее внедрения в нашу платформу виртуализации SpaceVM.

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

Локальные хранилища привычны для одиночных серверов: диск или массив принадлежит конкретному узлу, который управляет им напрямую. Общие (shared) хранилища, напротив, предоставляют единое пространство данных для нескольких серверов. Именно они лежат в основе высокодоступных кластеров и виртуализационных платформ, где важно, чтобы виртуальные машины могли мигрировать между узлами без потери доступа к своим дискам.

Но общий доступ — это не только вопрос архитектуры, но и способа взаимодействия с данными. Файловые протоколы (NFS, SMB и др.) дают возможность работать с файлами на уровне операционной системы, но вносят дополнительные задержки и ограничения. Блочные протоколы (iSCSI, Fibre Channel) предоставляют более низкоуровневый доступ — сервер видит удаленное устройство как локальный диск. Однако при этом возникает другая проблема: как синхронизировать работу нескольких узлов с одним и тем же блочным устройством, не разрушив файловую систему?

Ответ на этот вызов дают кластерные файловые системы, специально разработанные для совместного блочного доступа. Одна из самых зрелых и функциональных среди них — GFS2 (Global File System 2). В нашем опыте ее интеграция в собственный продукт - платформу виртуализации SpaceVM - позволила приблизиться к созданию устойчивой, масштабируемой и по-настоящему отказоустойчивой среды.