PL Tekst

Testy odporności infrastruktury

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.


Tekst PL

EN Tekst

Infrastructure resilience tests

In order to verify the real operational resilience of the infrastructure, simulations of failures of various combinations of nodes were performed, along with analysis of service behavior during system degradation.

Single server failure

Loss of any single node does not cause noticeable service interruption for end users. Redundant layers automatically take over the load, and the system continues operating in a degraded mode.
In some cases (e.g. MooseFS master failover), automatic failover requires a few minutes to fully stabilize.
This architecture allows maintenance, updates, and hardware replacement without significant impact on system availability.

Two server failure

Most services remain available. Availability of redundant services depends on the combination of failed nodes.
Potentially affected components include:
redundant mail servers,
HA OPNsense pair,
selected application replicas.
Other infrastructure components continue operating with reduced redundancy.

Three server failure

Services using triple replication or quorum mechanisms may lose availability if all nodes of a given service group fail.
This applies to, among others:
MooseFS,
SeaweedFS,
PostgreSQL clusters,
MySQL replication mechanisms requiring quorum.
The architecture was designed so that degradation is gradual and predictable.

Large-scale multi-node failure

In case of simultaneous loss of four or more servers, service availability degrades further, however selected infrastructure components may still operate in a limited mode.
The goal of the design was not to achieve full resilience against every possible failure, but to build an infrastructure providing predictable system behavior, controlled service degradation, and long-term stable operation.

Main switch failure

Disconnects the entire internal network. Currently, the planned improvement is the purchase of a second managed switch and a change of network configuration from LAGG/LACP mode to LAGG/failover using the second switch.

Power supply failure

Critical server-room components providing Internet access are protected by a dual power path with Schottky diodes — one from the main power supply and one from the backup supply.

UPS and power grid failure

Failure of any single UPS has no impact on server room operation.
Failure of two UPS units — if grid power remains available — still has no impact.
Only failure of all three power sources shuts down the server room.

Recovery time

Each server has a local backup copy on a second disk in the same enclosure — restoration time is effectively only the time needed to copy data back to a replacement disk. The key factor is the physical repair time (e.g. disk replacement).
Thanks to service redundancy, failure of a single server does not interrupt most services.

Recovery time (RTO)

Each server has a local backup copy on a second disk in the same enclosure.
System restoration after disk failure is essentially a data copy operation — typically taking a few to several minutes.
Local backups are primarily used for fast operational recovery, while full backup archives remain isolated from the production environment.
The key factor is the physical hardware repair time (e.g. disk replacement). Thanks to service redundancy, a single server failure does not interrupt most services.

Off-site time

Backups are located in the same physical room, therefore only the time needed to copy data to a staging disk and then to the final disk is relevant — approx. 30 minutes.

Local backups

Each server has a local backup copy on a second disk in the same enclosure. Restoration time after disk failure is typically a few to several minutes.

Off-site backups

Currently, there are no off-site backups (all backups are stored in the same physical location). This is a deliberate trade-off based on project priorities.
Full backup execution to a staging disk and final storage takes around 30 minutes.

Monitoring

A Prometheus + Grafana stack is available but currently not used. Classical tools (Munin, Monitorix, Ganglia, MRTG) provide clearer and more practical insights for this environment.


Tekst EN