W celu zweryfikowania rzeczywistej odporności operacyjnej
infrastruktury przeprowadzono symulacje awarii różnych
kombinacji węzłów oraz analizę zachowania usług podczas
degradacji systemu.
Awaria
pojedynczego serwera
Utrata dowolnego pojedynczego węzła nie powoduje zauważalnych przerw w
działaniu usług dla użytkowników końcowych. Warstwy
redundantne automatycznie przejmują obciążenie, a system kontynuuje
pracę w trybie zdegradowanym. W
niektórych
przypadkach (np. przełączenie MooseFS master) automatyczny failover
wymaga kilku minut na pełną stabilizację. Taka
architektura
umożliwia wykonywanie aktualizacji, prac serwisowych oraz wymiany
sprzętu bez istotnego wpływu na działanie infrastruktury.
Awaria dwóch serwerów
Większość usług
pozostaje dostępna. Dostępność usług redundantnych zależy od kombinacji
uszkodzonych węzłów.
Potencjalnie niedostępne mogą
stać się m.in.:
redundantne serwery pocztowe, para
HA OPNsense, wybrane repliki usług
aplikacyjnych.
Pozostałe elementy infrastruktury kontynuują pracę z ograniczoną
redundancją.
Awaria
trzech serwerów
Usługi wykorzystujące potrójną replikację lub mechanizmy
quorum mogą utracić dostępność, jeśli awaria obejmie wszystkie węzły
danej grupy usługowej. Dotyczy
to m.in.: MooseFS,
SeaweedFS, klastrów PostgreSQL,
mechanizmów replikacji MySQL wymagających quorum.
Architektura została zaprojektowana w taki sposób, aby
degradacja następowała stopniowo i przewidywalnie.
Rozległa awaria wielowęzłowa
Przy
jednoczesnej utracie
czterech lub większej liczby serwerów dostępność usług ulega
dalszej degradacji, jednak wybrane komponenty infrastruktury mogą nadal
działać w ograniczonym zakresie. Celem
projektu nie było
osiągnięcie pełnej odporności na każdą możliwą awarię, lecz budowa
infrastruktury zapewniającej przewidywalne zachowanie systemu,
kontrolowaną degradację usług oraz możliwość długoterminowej, stabilnej
eksploatacji.
Awaria
głównego switcha
"Rozpina" całą wewnętrzna sieć. Aktualnie planowany jest zakup drugiego
switcha zarządzalnego i zmianę konfiguracji sieci z trybu LAGG/LACP na
LAGG/failover z wykorzystaniem drugiego switcha.
Awaria zasilaczy
Elementy krytyczne serwerowni, zapewniające
dostęp do Internetu są chronione podwójnym obwodem z diodami
Schottky-ego - jeden z zasilacza głównego, drugim z
rezerwowego.
Awaria
UPS i sieci
energetycznej
Awaria
dowolnego, jednego UPS pozostaje bez
wpływu na pracę serwerowni. Awaria
dwóch UPS - o
ile zasilanie z sieci energetycznej działa - pozostaje bez wpływu na
pracę serwerowni. Dopiero
awaria wszystkich trzech
źródeł zasilania wyłącza serwerownię.
Czas przywrócenia do pracy
Serwery
posiadają
indywidualną kopie zapasową na drugim dysku w tej samej obudowie - czas
jej przywrócenia to w praktyce tylko czas jej przegrania na
uszkodzony dysk systemowy. Kluczowy jest czas usuwania awarii w
rozumieniu przywróceniu sprawności samego komputera do
działania (np. wymiana dysku).
Czas
Recovery (RTO)
Każdy serwer ma lokalną kopię zapasową na drugim dysku zamontowanym w
tej samej obudowie.
Przywrócenie systemu po awarii
dysku sprowadza się w praktyce do przegrania backupu —
zajmuje to zwykle kilka–kilkanaście minut. Lokalne
kopie służą przede wszystkim do szybkiego recovery operacyjnego,
natomiast pełne archiwum backupowe pozostaje odseparowane od środowiska
produkcyjnego.
Kluczowym czynnikiem jest fizyczny czas
naprawy sprzętu (np. wymiana dysku). Dzięki redundancji usług awaria
pojedynczego serwera nie powoduje przerw w dostępności większości
serwisów.
Czas
czas off-site
Kopie znajdują sie w tm samym pomieszczeniu, jest to więc liczy się
tylko czas
przegrania danych na dysk pośredni + ostateczne dogranie na dysk
docelowy - ok.
30 min.
Lokalne
backupy
Każdy serwer posiada lokalną kopię zapasową na drugim dysku w tej samej
obudowie. Czas przywrócenia systemu po awarii dysku to w
praktyce przegranie backupu na nowy dysk — zajmuje to
zazwyczaj kilka do kilkunastu minut.
Backupy
off-site
Obecnie nie posiadam kopii zapasowych poza lokalizacją (wszystkie
backupy znajdują się w tym samym pomieszczeniu). Jest to świadomy
kompromis wynikający z priorytetów projektu. Czas
wykonania pełnego backupu na dysk pośredni i finalne zapisanie wynosi
około 30 minut.
Monitoring
Posiadam działający
stack Prometheus + Grafana, jednak aktualnie go nie używam. Klasyczne
narzędzia (Munin, Monitorix, Ganglia, MRTG) dają mi bardziej czytelne i
przydatne w moim przypadku informacje.