Ważnym i trudnym tematem przy tworzeniu architektur webowych jest zarządzanie danymi i systemami plików. Podział zasobów pomiędzy poszczególne węzły klastra może być realizowany na różne sposoby, w zależności od charakteru i sposobu realizacji aplikacji. Zazwyczaj wystarcza proste rozwiązanie, w którym publikacja nowych danych następuje na każdy z hostów, np. przy pomocy rsync'a. Takie rozwiązanie wystarczające jest do dynamicznych stron, które nie potrzebują dostępu do zmiennych (wprowadzanych przez użytkowników serwisu) informacji. Zmiany wprowadzane przez edytorów strony są okresowo zatwierdzane przez administratorów, np. za pomocą wspomnianego rsync'a.
Gwarantuje to synchronizację plików w obrębie strony na każdym z węzłów, a tym samym umożliwia prostą synchronizację środowisk testowych/developerskich z produkcją. Zazwyczaj przy takich rozwiązaniach wystarcza współdzielona baza danych, ewentualnie z replikacją master-slave. Rzadziej wymagane są replikacje typu multi-master, które pozwalają na zapis danych na dowolnym z węzłów bazodanowych z gwarancją spójności danych. Open sourcowe narzędzia dają już możliwość realizowania w swoisty sposób replikacji multi-master. Mowa tu o baza MySQL w wersji 5, gdzie można zastosować np. dwa serwery bazodanowe i na każdym z nich ustawić odwołania do drugiej bazy zarówno w trybie master jak i slave. Pozwala to na symulacje działania pełnego trybu multi-master i umożliwia łatwe współdzielenie danych pomiędzy webhostami.
Inną metodą pozwalającą na rozłożenie obciążenia transakcyjnych systemów bazodanowych jest zastosowanie kaskadowej replikacji, co dodatkowo umożliwia synchronizację z systemami klienta. Taka replikacja ma swój początek na serwerze po stronie klienta i jest synchronizowana przez VPN z serwerem MSSQL po stronie K2, skąd następuje dalsza replikacja typu master-slave na kilka serwerów bazodanowych. Końcowe serwery służą jako replikatory tylko-do-odczytu dla silników wyszukiwarek i generowania treści w serwisie klienta. Jeśli tylko architektura systemu webowego na to pozwala, to zastosowanie takiego rozwiązania daje bardzo dobre efekty skalowalności oraz wydajności per node.
Już trzy przeciętne maszyny bazodanowe wystarczą aby serwować skomplikowane zapytania do serwisu z oglądalnością szczytową nawet 1200 requestów/s.
Rozproszenie na poziomie aplikacji jest wygodnym sposobem równoważenia obciążenia, jednak niektóre projekty wymagają wykorzystania nisko poziomowych, bardzo wydajnych rozwiązań – mowa tu o możliwości współdzielenia zasobów dyskowych. Przykładem może tu być serwis moblog.pl gdzie przechowywane są binarne dane (obrazki z MMS) oraz dane tekstowe. Dodatkowo ruch na serwisie jest na tyle duży, że każda oszczędność w efekcie skali przekłada się znacznie na szybkość działania serwisu. W tym wypadku zdecydowaliśmy się użyć współdzielonego systemu plików. Koncepcja sieciowego systemu plików NFS nie wchodziła jednak w grę, z uwagi na wspomnianą przy okazji bazy danych wydajność. Mimo że NFS od swojej pierwszych wersji dokonał olbrzymich postępów na polu wydajności, nadal jednak opiera się o warstwę sieci i musi być utrzymywany w ścisłych ramach protokołu IP. Taki narzut w przypadku moblog.pl również był nie do przyjęcia. Zdecydowano więc o wykorzystaniu GFS2.
GFS (GFS2) to bardzo zaawansowany i rozwijany od wielu lat system plików, który pozwala na jednoczesny dostęp do zasobów dyskowych przez grupę hostów. Odczyt i zapis realizowany może być jednocześnie a transmisja nie jest realizowana tak jak w przypadku np. NFS'a poprzez siec IP a bezpośrednio przez kontroler FC/SCSI. Takie rozwiązanie powoduje znaczne przyspieszenie operacji wykonywanych na dyskach, gdzie przy dużym I/O oraz dużych ilościach danych sieć TCP nie sprawdza się zupełnie. Niestety GFS2 wymaga do odpowiedniego sprzętu, przede wszystkim musimy posiadać odpowiednią macierz, którą będzie można współdzielić między serwerami. Musi być ona na tyle wydajna, aby podołać ogromnej liczbie operacji I/O realizowanej z wielu węzłów. W K2 wykorzystujemy do takich zadań wysoko wydajne macierze HP Enerprise Virtual Array (EVA) osiągającym wydajności rzędu 140 tysięcy operacji I/O na sekundę, dla porównania pojedynczy dysk SCSI/FC osiąga ok. 150 IOPS). W przytaczanym przykładzie mamy zbudowaną sieć GFS,%20Replikacja.aspx">SAN/FC, gdzie na wzór sieci Ethernet będziemy potrzebować odpowiedniego switcha oraz odpowiednich kontrolerów FC w serwerach. Bardzo ważnym elementem w architekturze GFS'a jest brak centralnego serwera metadanych.
Możliwy jest więc scenariusz gdzie GFS2 zostanie uruchomiony na tylko 2 serwerach, bez żadnych dodatkowych mechanizmów. Oczywiście podłączenie wyłącznie dwóch serwerów niesie pewne ryzyko – jest nim brak możliwości tzw. głosowania o stanie maszyn. Inaczej mówiąc, w przypadku awarii jednego serwera drugi z nich nie będzie wiedział czy to on jest w stanie awarii czy tez jego kolega. W przypadku co najmniej 3 maszyn, poprzez mechanizm głosowania GFS2 jest w stanie samodzielnie ocenić, który z węzłów jest uszkodzony i doprowadzić do fizycznego wyłączenia serwera. Tutaj docieramy do kolejnego istotnego mechanizmu, mianowicie klaster oparty o GFS2 musi posiadać metody/urządzenia pozwalające na automatyczne wyłączenie członka klastra.
Może to być urządzenie w rodzaju NPS lub też odpowiednie oprogramowania pozwalające wyłączyć maszynę wirtualną lub oprogramowane chassis bladów pozwalające na fizyczne wyłączanie blada. Operacja taka jest konieczne ze względu na pewność, że w momencie zwolnienia locków zarezerwowanych przez uszkodzony serwer, nie powróci on nagle do życia i zapisu używając locków, które wedle swojej wiedzy nadal posiada.
Ogólnie rzecz biorąc, GFS2 jest doskonałym rozwiązaniem do budowy klastrowanych filesystemów, jednak koszt jego wdrożenia może być znaczny. W obecnej chwili pojawiło się również wsparcie dla iSCSI i jako tańsza alternatywa dla sieci SAN może być rozsądnym rozwiązaniem przy niewielkich instalacjach.