Привет, Хабр! Меня зовут Сергей Алексанков, я технический директор Space. В этой статье расскажу о нашем опыте внедрения файловой системы GFS2 в платформу виртуализации SpaceVM.
Облачные среды, отказоустойчивые кластеры и платформы виртуализации требуют от хранилищ не только надежности, но и поддержки одновременного доступа. В этих условиях традиционные файловые системы (EXT4, NTFS, XFS и др.) оказываются недостаточными — они не рассчитаны на работу с общими блочными устройствами между несколькими узлами. Одним из решений может стать кластерная файловая система, и одной из самых зрелых в этом классе является GFS2 (Global File System 2).
Современные ИТ-инфраструктуры часто строятся вокруг виртуализации и облаков, где несколько серверов одновременно обращаются к одним и тем же данным. В таких системах ключевым становится не просто объем или скорость хранилища, а способ доступа к данным — общий или локальный, файловый или блочный. От того, как именно организовано взаимодействие с хранилищем, зависит архитектура всего решения: от производительности виртуальных машин до отказоустойчивости кластера.
Локальные хранилища привычны для одиночных серверов: диск или массив принадлежит конкретному узлу, который управляет им напрямую. Общие (shared) хранилища, напротив, предоставляют единое пространство данных для нескольких серверов. Именно они лежат в основе высокодоступных кластеров и виртуализационных платформ, где важно, чтобы виртуальные машины могли мигрировать между узлами без потери доступа к своим дискам.
Но общий доступ — это не только вопрос архитектуры, но и способа взаимодействия с данными. Файловые протоколы (NFS, SMB и др.) дают возможность работать с файлами на уровне операционной системы, но вносят дополнительные задержки и ограничения. Блочные протоколы (iSCSI, Fibre Channel) предоставляют более низкоуровневый доступ — сервер видит удаленное устройство как локальный диск. Однако при этом возникает другая проблема: как синхронизировать работу нескольких узлов с одним и тем же блочным устройством, не разрушив файловую систему?
Ответ на этот вызов дают кластерные файловые системы, специально разработанные для совместного блочного доступа. Одна из самых зрелых и функциональных среди них — GFS2 (Global File System 2). В нашем опыте ее интеграция в собственный продукт - платформу виртуализации SpaceVM - позволила приблизиться к созданию устойчивой, масштабируемой и по-настоящему отказоустойчивой среды.
SpaceVM — собственная разработка компании, платформа виртуализации на базе гипервизора KVM. Своего рода аналог vSphere от VMware, адаптированный под отечественные реалии и высокую степень автоматизации, это программный комплекс для управления вычислительными кластерами, автоматизации развертывания виртуальных машин и балансировки ресурсов между узлами. В его основе — идея унифицированного управления инфраструктурой: от гипервизора до сетевых и дисковых подсистем, с акцентом на прозрачность процессов и возможность интеграции с существующими ИТ-ландшафтами.
С использованием GFS2 достигается эффект, сопоставимый по удобству и стабильности с использованием VMFS в продуктах VMware — с открытым исходным кодом и возможностью глубокой адаптации под нужды отечественных заказчиков.
В архитектуре платформы стояла задача обеспечить общий доступ к блочному хранилищу между узлами кластера — без потери целостности данных и с возможностью одновременной работы виртуальных машин. При этом многие заказчики ожидали получить функциональность, сопоставимую с VMFS, используемой в продуктах VMware. Эти два требования сошлись в одной точке: для реализации такой модели доступа мы выбрали GFS2 — кластерную файловую систему, по принципам работы близкую к VMFS, но основанную на открытом коде и допускающую глубокую адаптацию под особенности отечественной инфраструктуры.
GFS2: преимущества архитектуры и механизма блокировок
GFS2 — это POSIX-совместимая кластерная файловая система, разработанная для работы �� общими блочными устройствами, подключенными по Fibre Channel или iSCSI. Ее ключевая особенность — координация доступа к метаданным и содержимому файлов при помощи распределенного менеджера блокировок DLM (Distributed Lock Manager).
Это позволяет гарантировать целостность данных даже при одновременном доступе с нескольких узлов. В отличие от NFS или SMB, где блокировки файлов координируются через сеть, GFS2 использует механизм локальных блокировок. Это принципиальное отличие: при сетевых файловых системах каждая операция блокировки требует удаленного вызова — будь то RPC-запрос или SMB-пакет — и ожидания ответа от сервера. Такие сетевые транзакции неизбежно добавляют задержку, особенно при высокой нагрузке или нестабильных сетевых условиях.
В GFS2 же блокировки реализованы на уровне узлов кластера с использованием локальных ресурсов ОС и специализированных сервисов. Это значит, что большинство операций синхронизации выполняется без сетевых вызовов, напрямую внутри ядра или через быстрые механизмы обмена между узлами. Благодаря этому GFS2 обеспечивает более предсказуемое время отклика и лучшую масштабируемость при росте количества клиентов, чем файловые протоколы NFS или SMB.
По сравнению с прямым пробросом блочных устройств в виртуальные машины, GFS2 предлагает более безопасный и управляемый способ совместного доступа к данным, не жертвуя скоростью и устойчивостью файловой системы.
GFS2 демонстрирует сбалансированный и технологически обоснованный подход к организации доступа к общим данным, выгодно отличаясь как от сетевых решений вроде NFS или SMB, так и от схем прямого подключения блочных устройств без кластеризации.
В сетевых файловых системах вся работа с данными происходит через удаленный сервер — каждая операция чтения, записи или блокировки требует сетевого запроса и подтверждения. Это упрощает администрирование, но создает точку отказа и ограничивает масштабирование: при росте нагрузки сервер становится узким местом, а задержки на уровне сети напрямую влияют на производительность.
В противоположность этому, при прямом пробросе блочного устройства (или подход называемый SharedLVM) в несколько узлов вся логика управления данными перекладывается на хосты. Такой подход обеспечивает высокую скорость, но лишен механизмов согласования и защиты целостности: две машины могут записать разные данные в один и тот же блок, разрушив файловую систему.
GFS2 решает обе проблемы одновременно. Она обеспечивает одновременный блочный доступ к устройству, но при этом использует встроенные кластерные механизмы — журналирование, распределенный менеджер блокировок (DLM) и систему метаданных, общую для всех узлов. За счет этого данные остаются согласованными, а операции синхронизации происходят быстрее, чем в сетевых файловых системах, поскольку выполняются на уровне ядра и не требуют посредничества сервера. Таким образом, GFS2 сочетает надежность и консистентность сетевых решений с низкими задержками и эффективностью блочного доступа.
Второе важное преимущество — масштабируемость. Архитектура GFS2 допускает одновременный доступ к файловой системе с большого числа узлов, не требуя специальных клиентских или серверных реализаций. Это делает ее пригодной для использования как в компактных конфигурациях с 2–3 серверами, так и в полноценных кластерах с десятками узлов.
При этом поддержка iSCSI и Fibre Channel дает гибкость в выборе СХД и не требует полной перестройки инфраструктуры.
Третье — отказоустойчивость. В отличие от решений, где потеря одного узла может повлечь за собой повреждение данных или зависание всей файловой системы, GFS2 умеет корректно обрабатывать сбои.
Механизмы fencing и quorum позволяют изолировать некорректно работающий узел, предотвращая split-brain и обеспечивая консистентность хранилища. Это особенно важно в условиях непрерывной работы платформ виртуализации, где потеря доступности даже части пула данных может повлечь каскадный отказ сервисов.
Наконец, GFS2 упрощает администрирование за счет единого пространства имен и поддержки различных форматов данных. Это позволяет централизованно управлять пулами хранения и использовать привычные средства резервного копирования, миграции и диагностики. Для конечного пользователя это выражается в предсказуемом поведении системы и возможности разворачивать кластерные решения без глубокого погружения в особенности конкретных СХД или драйверов.
На фоне альтернатив — GlusterFS, CEPH, Lustre — GFS2 занимает уникальное положение: это именно кластерная файловая система, работающая поверх одного общего устройства хранения, а не распределенная система с репликацией. Что делает ее особенно актуальной для сценариев, где важна экономия места, контроль над изоляцией данных и высокая предсказуемость поведения I/O.
Для чего мы используем GFS2 в SpaceVM
Одной из ключевых архитектурных задач в SpaceVM стало обеспечение полноценного доступа к общему хранилищу с возможностью запуска и миграции виртуальных машин на любых узлах кластера. Без использования внешней кластерной файловой системы это невозможно реализовать корректно.
В виртуализированной инфраструктуре, где диски ВМ хранятся на сетевых LUN, только кластерная файловая система обеспечивает безопасный параллельный доступ с нескольких узлов, защиту от повреждения данных и поддержание высокой доступности. Именно в этом контексте в архитектуру SpaceVM была интегрирована GFS2 как штатный компонент хранилищ виртуальных машин.
Благодаря GFS2, платформа получает следующие возможности, критически важные для промышленного использования:
Хранение образов ВМ в виде файлов (формата qcow2) на общем устройстве, доступном всем серверам одновременно;
Реализация высокой доступности (HA) за счет возможности мгновенного запуска виртуальной машины на любом из узлов без предварительной миграции её диска;
Поддержка динамического перераспределения ресурсов (DRS), включая live migration, без необходимости вручную управлять блочными устройствами;
Использование моментальных снимков, клонов и тонких дисков, с одновременной защитой от потерь данных при overcommit-сценариях — благодаря механизмам блокировок GFS2;
Выполнение требований безопасности, предъявляемых заказчиками: например, возможность использовать атрибуты безопасности на уровне файлового слоя, чего невозможно достичь при прямом пробросе блочных устройств в ВМ.
GFS2 в SpaceVM — не просто еще один способ монтировать хранилище, а полноценный архитектурный уровень, обеспечивающий устойчивость, управляемость и безопасность всей платформы.
Однако простая интеграция GFS2 в SpaceVM оказалась невозможной. Нужно было добиться не только корректной работы файловой системы, но и органичной интеграции в архитектуру SpaceVM, где свои требования к кластерному транспорту, управлению ограждением узлов и мониторингу.
Архитектура и технические сложности
Файловая система GFS2 не существует в изоляции — она требует работы в составе кластера и взаимодействует с рядом системных компонентов, формирующих так называемый кластерный транспорт. В этой архитектуре важны не только сама файловая система, но и сопутствующий ИТ-ландшафт, обеспечивающий согласованность операций, отказоустойчивость и синхронизацию между узлами.
В первую очередь, GFS2 включает в себя менеджер DLM, который отвечает за координацию доступа к метаданным и содержимому файлов. Чтобы избежать ситуаций типа split-brain и гарантировать консистентность, применяется механизм ограждения (fencing), реализуемый через SBD (Storage-Based Death), чаще всего с использованием аппаратного watchdog-интерфейса IPMI.
Файловая система GFS2 не работает автономно — она является частью кластерной инфраструктуры и требует взаимодействия с рядом системных сервисов, которые обеспечивают согласованность доступа и защиту данных. В отличие от обычных файловых систем, где единственный узел управляет диском, в кластере одновременно несколько машин читают и записывают данные на одно и то же блочное устройство. Это создает типичные распределенные проблемы — от гонок за блокировки до рассинхронизации метаданных при сбоях узлов.
Чтобы избежать подобных ситуаций, GFS2 использует DLM. Он координирует доступ к метаданным и содержимому файлов, гарантируя, что ни один узел не изменит данные, пока другой с ними работает. Механизм блокировок распределенный, но выполняется внутри кластера, без участия центрального сервера, что снижает задержки и устраняет единую точку отказа.
Однако даже с DLM остаются риски, связанные с частичными сбоями — например, когда узел теряет связь с сетью, но продолжает считать себя активным. Чтобы предотвратить разрушение данных в таких сценариях, применяется механизм fencing — изоляции или «отключения» проблемного узла. В GFS2 это реализуется через SBD (Storage-Based Death), который хранит управляющие метки на общем хранилище и при необходимости инициирует аппаратный перезапуск узла через интерфейс IPMI или watchdog. Таким образом, система сохраняет консистентность даже в условиях сетевых сбоев и частичных отказов, что критически важно для кластерной файловой системы.
Кластерный транспорт GFS2 опирается на стек Corosync — это системный уровень, обеспечивающий коммуникацию между узлами и согласование их состояний. Важной частью надежной работы всей системы является синхронизация времени на всех узлах, обеспечиваемая через NTP: даже небольшие расхождения могут привести к рассогласованию в блокировках или ложным срабатываниям watchdog-механизма.
Кроме того, для подключения LUN в инфраструктуре используются утилиты multipath-tools (в случае Fibre Channel) и open-iscsi (для iSCSI). Они обеспечивают корректное определение, маршрутизацию и управление путями к блочным устройствам, поверх которых и разворачивается файловая система GFS2.
GFS2 — целостная кластерная подсистема, в которой управление доступом, синхронизацией, диагностикой и восстановлением после сбоев вынесено на уровень кластера.
К системе/кластеру предъявляется ряд требований: строгое время синхронизации между узлами, устойчивость к потере сетевого трафика и возможность автоматического fencing'а при ошибках. Любые отклонения ведут к перезагрузкам узлов или развалу кластера.
Трудности при развертывании GFS2: от теории к полевым реалиям
Хотя GFS2 — зрелая и мощная технология, ее внедрение в реальной инфраструктуре связано с рядом инженерных сложностей. Эти проблемы не всегда очевидны на этапе проектирования, но проявляются в момент масштабирования, нагрузки или интеграции в существующую платформу. Наш опыт развертывания GFS2 в составе SpaceVM показал: надежная работа кластерной файловой системы требует учета множества низкоуровневых факторов.
Один из критических аспектов — синхронизация времени между узлами. GFS2 использует DLM и SBD, которые чувствительны даже к незначительным расхождениям во времени. Практика показала: если разница между узлами превышает 60 секунд, возможны некорректные решения по кворуму или ошибочные fencing-сценарии. Поэтому требуется жесткая настройка NTP-инфраструктуры с контролем точности синхронизации вплоть до миллисекунд.
Следующая проблема — сетевые коллизии. При использовании iSCSI поверх общей инфраструктуры наблюдались случаи, когда трафик от виртуальных машин перекрывал каналы кластерного транспорта. Это приводило к задержкам, потере пакетов и, как следствие, рассинхронизации между узлами, развалу кворума и перезагрузкам. Особенно остро это проявлялось при объединении сетевых интерфейсов по LACP: реализация агрегации каналов у разных производителей оборудования иногда конфликтовала с работой iSCSI, вызывая нестабильные и трудноотлавливаемые ошибки. Мы отказались от LACP в пользу Active-Backup-режима, обеспечив тем самым предсказуемую работу с минимальной зависимостью от поведения сетевого оборудования.
Отдельного внимания требует механизм ограждения через аппаратный watchdog. В нашем случае это IPMI-интерфейс, который должен реагировать на команды от SBD каждые 5 секунд. Однако в ряде инсталляций IPMI не успевал обработать запросы вовремя — из-за параллельных обращений от других сервисов или под нагрузкой. Это приводило к ложным fencing-сценариям: узел перезагружался без реальной причины. Решение — настройка возможности изменения таймаута watchdog’а и тщательное тестирование поведения IPMI на каждом типе оборудования.
Также важно отметить трудности, возникающие при блокировке монтирования LUN. В случае некорректного завершения работы или проблем с доступом к СХД, файловая система могла зависать в состоянии ожидания, блокируя операции на уровне ядра. Требовались либо перезагрузка узла, либо использование низкоуровневых утилит для разблокировки ресурса.
Подобные случаи невозможно игнорировать в продуктивной системе, и мы встроили в SpaceVM механизмы предиктивной диагностики, позволяющие заранее идентифицировать потенциальные блокировки по косвенным признакам.
Интеграция GFS2 в платформу виртуализации
Интеграция GFS2 в платформу виртуализации SpaceVM потребовала глубокого осмысления архитектуры кластерного транспорта и адаптации логики GFS2 под централизованную модель управления. В отличие от классического использования GFS2 в кластерах с ручной настройкой, здесь требовалось встроить файловую систему в оркестратор, который сам управляет вычислительными узлами, хранилищами и службами мониторинга через API и веб-интерфейс.
Одна из ключевых проблем заключалась в несовместимости базовой логики GFS2 с концепцией SpaceVM. GFS2 ставит во главу угла сохранность данных: при любых ошибках, нарушениях кворума или сбоях с доступом к хранилищу система инициирует ограждение узла, то есть его принудительную перезагрузку. Напротив, SpaceVM ориентирован на непрерывную доступность ВМ и динамическую работу с узлами — даже при частичных деградациях инфраструктуры.
В результате потребовалось реализовать механизм точной настройки поведения GFS2 через интерфейс платформы, чтобы у администр��тора была возможность балансировать между отказоустойчивостью хранения и живучестью вычислительного пула.
Также было необходимо централизовать управление кластерным транспортом. В классическом варианте администратор вручную настраивает corosync, DLM, SBD, конфигурирует кольца, задает пороги кворума и поведение watchdog. В SpaceVM же вся эта конфигурация задается через API и визуальный мастер (wizard) создания GFS2-пула. Он позволяет в одном окне:
выбрать диски,
указать тип монтирования,
настроить кластерный транспорт и fencing,
развернуть файловую систему.
Эта автоматизация особенно важна, поскольку GFS2 имеет высокий порог входа в плане требований к администратору. Ручная настройка — сложна и не масштабируется. Внедрение через интерфейс SpaceVM снимает барьер для широкого использования технологии.
Мы внедрили централизованную валидацию настроек, автоматическое создание кластерного транспорта, подключение или отключение ограждений узлов, а также поддержку резервных сетей на базе протокола SCTP — они выбираются из UI и позволяют без прерывания работы переключаться между каналами связи.
На уровне гипервизора также произошла серьезная интеграция. Контроллер SpaceVM передает вычислительным узлам команды через GRPC, синхронизируя настройки кластера, хранилищ и дисков. Все компоненты — от планировщика задач и очередей до сервисов синхронизации — взаимодействуют через собственную распределенную архитектуру. В этом окружении GFS2 стала частью общей системы: она управляется не вручную, а автоматически, через механизмы модулей Puppet, SSH-контроллеров и специализированных микросервисов.
Особое внимание мы уделили типам монтирования и поведению ограждений. В GFS2 предусмотрены два основных сценария fencing’а:
При потере кворума кластерного транспорта (split-brain).
При ошибках записи или потере связи с блочным хранилищем.
Мы реализовали возможность включать или отключать каждый из этих типов независимо, а также контролировать режим монтирования LUN (например, errors=panic или debug). В результате администратор получает не «чёрный ящик», а управляемую систему, где последствия сбоев можно смоделировать и задать заранее.
Также были предприняты меры по валидации некорректных состояний:
перед созданием нового транспорта проверяются конфигурации всех оставшихся узлов;
при попытке монтирования система автоматически выявляет заблокированные LUN и предотвращает зависание задачи;
по умолчанию отключена устаревшая опция создания дисков с полным выделением пространства (full), вместо неё используется falloc — это снижает нагрузку на GFS2 и исключает ошибки при записи.
Таким образом, мы не просто подключили GFS2 как файловую систему — мы встроили её в архитектуру платформы виртуализации, превратив в управляемый, безопасный и масштабируемый компонент. Получилась не просто интеграция, а полноценная унификация двух миров: надёжного хранения и гибкой оркестрации вычислений.
Оптимизация производительности
Однако даже после корректной настройки GFS2 может демонстрировать нестабильную производительность. В процессе внедрения мы протестировали и включили ряд оптимизаций:
BFQ-алгоритм планирования ввода-вывода, сглаживающий пики нагрузки между ВМ;
Обязательное использование virtio и hyper-v оптимизаций для улучшения взаимодействия между хостом и гостевыми ОС;
Отказ от метода выделения диска full в пользу falloc — это устраняет ошибки записи и уменьшает нагрузку на подсистему хранения.
Итоги: GFS2 — зрелое решение с инженерной спецификой
GFS2 — мощный инструмент, который требует глубокого понимания. Его сила — в контроле над данными, гибкости и отказоустойчивости. Чтобы получить все преимущества его использования нужно глубокое понимание принципов его работы, особенно если разворачивать его «сбоку», не связывая с платформой.
Сложность GFS2 — это не недостаток, а плата за мощь. Осознавая это, разработчики SpaceVM провели кропотливую работу по ее комплексной интеграции в свою платформу.
В результате, то, что в изоляции воспринималось как слабость (чувствительность к среде, сложность настройки), было устранено. Пользователь получает всю силу GFS2 — контроль, гибкость, отказоустойчивость — через доступный интерфейс, автоматизацию и диагностику SpaceVM.
Мы добились того, чего ждали от VMFS в отечественном исполнении: общего хранилища, совместимого с кластерами, виртуальными машинами и требованиями безопасности. А главное — доказали, что даже сложные opensource-компоненты могут органично встраиваться в коммерческие платформы, если подойти к этому как инженеры.