#gfs2

2025-11-13

GFS2 — файловая система для новой виртуализации: наш опыт интеграции в SpaceVM

Рассказываем о своем опыте ее внедрения в нашу платформу виртуализации SpaceVM. Современные ИТ-инфраструктуры часто строятся вокруг виртуализации и облаков, где несколько серверов одновременно обращаются к одним и тем же данным. В таких системах ключевым становится не просто объем или скорость хранилища, а способ доступа к данным — общий или локальный, файловый или блочный. От того, как именно организовано взаимодействие с хранилищем, зависит архитектура всего решения: от производительности виртуальных машин до отказоустойчивости кластера. Локальные хранилища привычны для одиночных серверов: диск или массив принадлежит конкретному узлу, который управляет им напрямую. Общие (shared) хранилища, напротив, предоставляют единое пространство данных для нескольких серверов. Именно они лежат в основе высокодоступных кластеров и виртуализационных платформ, где важно, чтобы виртуальные машины могли мигрировать между узлами без потери доступа к своим дискам. Но общий доступ — это не только вопрос архитектуры, но и способа взаимодействия с данными. Файловые протоколы (NFS, SMB и др.) дают возможность работать с файлами на уровне операционной системы, но вносят дополнительные задержки и ограничения. Блочные протоколы (iSCSI, Fibre Channel) предоставляют более низкоуровневый доступ — сервер видит удаленное устройство как локальный диск. Однако при этом возникает другая проблема: как синхронизировать работу нескольких узлов с одним и тем же блочным устройством, не разрушив файловую систему? Ответ на этот вызов дают кластерные файловые системы, специально разработанные для совместного блочного доступа. Одна из самых зрелых и функциональных среди них — GFS2 (Global File System 2). В нашем опыте ее интеграция в собственный продукт - платформу виртуализации SpaceVM - позволила приблизиться к созданию устойчивой, масштабируемой и по-настоящему отказоустойчивой среды.

habr.com/ru/companies/spacevm/

#gfs2 #gfs #виртуализация #виртуализация_серверов #хранилища #хранение_данных #инфраструктура #vmware_vsphere #vmfs

Andy Priceandyprice
2025-07-29

Just a handful of changes this merge window. Expect more from me as I ramp up my (upstream) kernel work.

lore.kernel.org/gfs2/175374607

Andy Priceandyprice
2024-07-18
Andy Priceandyprice
2024-05-15
Andy Priceandyprice
2023-11-08
Andy Priceandyprice
2023-09-06
Andy Priceandyprice
2023-07-10

Missed it last week as I was on leave but the changes for the 6.5 merge window have been merged. They include an overhaul of the freeze/thaw mechanism to fix deadlocks that can occur when e.g. several cluster nodes try to freeze the fs at the same time.

lore.kernel.org/all/2023070412

2022-01-06
For a new e-mail cluster that will eventually consist of a number of #IMAP servers, I need some shared storage that all servers can read from and write to at the same time. I have some experience with #DRBD, but I was told that DRBD isn't going to be the solution for what I want.

It will start small, with only several hundreds of mailboxes, but it should be able to scale up to many thousands or even hundreds of thousands in the distant future. What I want is a variable number of #Dovecot servers with an HA Director in front of them, so that I can upgrade and reboot individual nodes without users noticing.

#NFS would -on paper- be ideal, but when working with lots and lots of small files it gets very slow. #ZFS is pretty cool, but that wasn't designed as a cluster filesystem and I'm not sure if it can be made to do that reliably. I find #GlusterFS and #GFS2 in many articles, but I don't have any experience with those. I have a bit of experience with #Ceph, just enough to know that I don't want that.

What do you guys think, what is the system I should go for? And, or course, why? Did I overlook systems that are worthwhile?

Bon, la pile #GFS2/#Pacemaker/#Corosync est trop sensible pour moi.

Ça part en vrille trop souvent sans comprendre ce qu’il se passe et le cluster ne récupère rien, tous les #pacemaker par terre ⮕ obligé de rebooter les 3 hyperviseurs #OpenNebula.

À vot’bon ❤ m’sieurs ’dames, pour un p’tit cluster #Ceph pour @EOLE

eole.ac-dijon.fr/presentations

Dr. Roy Schestowitz (罗伊)schestowitz@gnusocial.de
2018-01-22

Client Info

Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst