Co to jest klastrowanie serwerów? Architektura, typy i implementacja w rzeczywistych warunkach

Klastrowanie serwerów to praktyka łączenia wielu fizycznych lub wirtualnych serwerów — zwanych węzłami — tak aby działały jako jeden, zunifikowany system. Ta architektura umożliwia dystrybucję obciążenia, automatyczne przełączanie awaryjne i skalowanie poziome, zapewniając dostępność aplikacji nawet w przypadku awarii poszczególnych komponentów sprzętowych lub programowych. W prawidłowo skonfigurowanym klastrze żaden pojedynczy węzeł nie stanowi punktu awarii, co jest fundamentalną zasadą odróżniającą infrastrukturę klastrową od wdrożeń na pojedynczych serwerach.

W przypadku każdego obciążenia, gdzie przestój bezpośrednio przekłada się na utratę przychodów, narażenie na sankcje regulacyjne lub ryzyko uszkodzenia danych, klastrowanie serwerów nie jest opcją — jest podstawowym wymogiem architektonicznym.

Jak działa klastrowanie serwerów na poziomie architektury

W swojej istocie klaster zbudowany jest na trzech współzależnych warstwach: węzłach obliczeniowych, współdzielonym lub replikowanym magazynie danych oraz oprogramowaniu do zarządzania klastrem. Warstwy te muszą być projektowane i dostrajane razem; błędna konfiguracja którejkolwiek z nich podważa gwarancje, które pozostałe starają się zapewnić.

Węzły

Każdy węzeł to pełnoprawny serwer — fizyczny lub wirtualny — zdolny do samodzielnego uruchamiania docelowego obciążenia. Węzły komunikują się przez dedykowane prywatne łącze wewnętrzne (zazwyczaj oddzielna karta NIC lub para połączonych kart) używane wyłącznie do sygnałów heartbeat i wewnętrznego ruchu klastra. Ta sieć jest odrębna od sieci publicznej obsługującej żądania użytkowników końcowych.

Heartbeat to puls klastra. Węzły wymieniają sygnały w konfigurowalnych odstępach czasu (zazwyczaj co 1–2 sekundy). Jeśli węzeł pominie określoną liczbę kolejnych heartbeatów, menedżer klastra uznaje go za martwy i inicjuje przełączenie awaryjne. Krytycznym przypadkiem brzegowym jest tutaj scenariusz split-brain: gdy sama sieć heartbeat zawiedzie, oba węzły mogą uznać, że drugi nie działa, i jednocześnie próbować przejąć kontrolę nad współdzielonymi zasobami, powodując uszkodzenie danych. Zapobieganie split-brain wymaga mechanizmu kworum — zasobu rozstrzygającego, takiego jak dedykowany dysk kworum, serwer świadek lub oparta na chmurze usługa arbitrażu.

Współdzielony i replikowany magazyn danych

Architektura magazynu danych różni się znacznie w zależności od typu klastra:

• Klastry ze współdzielonym dyskiem używają urządzenia SAN (Storage Area Network) lub NAS (Network-Attached Storage), które wszystkie węzły montują jednocześnie. Menedżer klastra używa rezerwacji SCSI lub rozproszonych menedżerów blokad (DLM), aby zapobiec równoczesnym zapisom, które mogłyby uszkodzić dane.
• Klastry bez współdzielonego zasobu replikują dane między węzłami na poziomie blokowym lub aplikacyjnym (np. DRBD dla Linux, SQL Server Always On Availability Groups). Każdy węzeł posiada własny lokalny magazyn danych; replikacja utrzymuje ich synchronizację.
• Architektury hybrydowe łączą oba podejścia, używając współdzielonego magazynu dla danych podstawowych i replikacji do odtwarzania po awarii w geograficznie oddzielnej lokalizacji.

Oprogramowanie do zarządzania klastrem

Menedżer klastra odpowiada za orkiestrację zasobów, monitorowanie stanu i automatyczne przełączanie awaryjne. Powszechnie stosowane rozwiązania to:

• Pacemaker + Corosync — de facto standard na Linux (RHEL, CentOS, Ubuntu)
• Windows Server Failover Clustering (WSFC) — natywne dla środowisk Windows Server
• Kubernetes — natywne klastrowanie kontenerów z harmonogramowaniem podów, samoleczeniem i aktualizacjami kroczącymi
• VMware vSphere HA / vSAN — klastrowanie na poziomie hiperwizora dla zwirtualizowanych obciążeń

Każde rozwiązanie udostępnia różne prymitywy do definiowania zasobów, ograniczeń i polityk przełączania awaryjnego. Zasób w Pacemaker, na przykład, to dowolna usługa zarządzana przez klaster — adres IP, punkt montowania systemu plików, demon bazy danych — a ograniczenia definiują reguły kolejności i kolokacji dla tych zasobów.

Główne korzyści z klastrowania serwerów

Wysoka dostępność i automatyczne przełączanie awaryjne

Głównym motorem większości wdrożeń klastrowych jest wysoka dostępność (HA). Gdy węzeł zawiedzie, menedżer klastra wykrywa awarię poprzez brakujące heartbeaty, a następnie przenosi dotknięte zasoby do działającego węzła — proces ten nazywany jest przełączaniem awaryjnym. Nowoczesne oprogramowanie klastrowe może zakończyć ten proces w czasie poniżej 30 sekund dla większości obciążeń, choć odtwarzanie na poziomie bazy danych (odtwarzanie po awarii, odtwarzanie dziennika) dodaje dodatkowy czas zależny od obciążenia.

Recovery Time Objective (RTO) i Recovery Point Objective (RPO) to dwa wskaźniki definiujące jakość HA:

• RTO — jak długo usługa jest niedostępna podczas przełączania awaryjnego
• RPO — ile danych może zostać utraconych (mierzonych w czasie), jeśli węzeł podstawowy zawiedzie przed zakończeniem replikacji

Replikacja synchroniczna osiąga RPO = 0, ale wprowadza opóźnienie zapisu, ponieważ węzeł podstawowy musi czekać na potwierdzenie każdego zapisu przez replikę. Replikacja asynchroniczna zmniejsza opóźnienie, ale akceptuje niezerowe RPO. Wybór między nimi jest decyzją biznesową, a nie czysto techniczną.

Równoważenie obciążenia i skalowanie poziome

Klastry równoważące obciążenie rozdzielają przychodzące żądania między węzły przy użyciu algorytmów takich jak round-robin, najmniej połączeń, hash IP lub ważona dystrybucja. Sam load balancer — czy to sprzętowy (F5, Citrix ADC) czy programowy (HAProxy, NGINX, LVS) — znajduje się przed klastrem i musi być redundantny, aby nie stać się pojedynczym punktem awarii.

Skalowanie poziome w klastrze oznacza dodawanie węzłów zamiast modernizacji sprzętu poszczególnych serwerów (skalowanie pionowe). Ma to istotne znaczenie ekonomiczne: węzły na sprzęcie klasy commodity są tańsze na jednostkę mocy obliczeniowej niż wysokiej klasy serwery monolityczne, a klaster abstrahuje bazowy sprzęt od aplikacji.

Tolerancja błędów i redundancja

Tolerancja błędów wykracza poza redundancję węzłów. Projekt klastra klasy produkcyjnej uwzględnia:

• Podwójne zasilacze w każdym węźle podłączone do oddzielnych PDU i UPS
• Redundantne ścieżki sieciowe (łączenie kart NIC lub trunking LACP do oddzielnych przełączników)
• Multipath I/O (MPIO) dla połączeń z magazynem danych, eliminujące awarie pojedynczej karty HBA lub kabla
• Geograficzna dystrybucja między strefami dostępności lub centrami danych w celu ochrony przed awariami na poziomie lokalizacji

Ignorowanie którejkolwiek z tych warstw tworzy ukryte pojedyncze punkty awarii, których oprogramowanie klastrowe nie jest w stanie skompensować.

Uproszczona konserwacja krocząca

Jedną z operacyjnie niedocenianych korzyści jest konserwacja bez przestojów. Węzeł może zostać płynnie opróżniony — jego zasoby przeniesione do węzłów partnerskich — załatany, uruchomiony ponownie i przywrócony do klastra bez żadnej przerwy w świadczeniu usług. Nazywa się to planowanym przełączeniem awaryjnym lub migracją na żywo w środowiskach zwirtualizowanych. Przekształca to łatanie systemu operacyjnego i wymianę sprzętu z zaplanowanych okien konserwacyjnych w rutynowe, niezakłócające operacje.

Typy klastrów serwerowych

Klastry wysokiej dostępności

Klastry HA są najczęstszym wdrożeniem w przedsiębiorstwach. Dwuwęzłowy klaster HA aktywny-pasywny uruchamia obciążenie na węźle podstawowym, podczas gdy węzeł pomocniczy pozostaje w trybie gotowości, stale synchronizowany. Wariant aktywny-aktywny uruchamia obciążenie na wszystkich węzłach jednocześnie, co zwiększa przepustowość, ale wymaga, aby aplikacja obsługiwała równoczesny dostęp z wielu węzłów — nie wszystkie bazy danych ani starsze aplikacje to umożliwiają.

Klastry równoważące obciążenie

Klastry te są z natury aktywne-aktywne. Load balancer rozdziela sesje między pulę serwerów aplikacyjnych. Trwałość sesji (sticky sessions) jest powszechnym wymogiem dla aplikacji stanowych: load balancer musi kierować żądania danego klienta do tego samego węzła backendowego przez całą sesję. Tworzy to niejawną zależność, która komplikuje usuwanie węzłów i przełączanie awaryjne, dlatego bezstanowy projekt aplikacji jest zdecydowanie preferowany w nowoczesnych architekturach.

Klastry przełączania awaryjnego

Klastry przełączania awaryjnego priorytetyzują szybkość odtwarzania i integralność danych ponad surową wydajność. Są standardową architekturą dla wdrożeń SQL Server, Oracle RAC i SAP HANA. Kluczowym wyzwaniem inżynieryjnym jest zapewnienie, że cel przełączenia awaryjnego posiada spójną, aktualną kopię wszystkich danych w momencie awarii — dlatego replikacja synchroniczna i projekt kworum są niezbędne w tych środowiskach.

Klastry magazynowania

Rozproszone systemy magazynowania, takie jak Ceph, GlusterFS i MinIO, tworzą własną warstwę klastrową, niezależną od klastra obliczeniowego powyżej. Ceph, na przykład, używa algorytmu CRUSH do dystrybucji danych między OSD (Object Storage Daemons) bez centralnego wąskiego gardła metadanych. Klastry magazynowania zapewniają backend woluminów trwałych dla obciążeń Kubernetes i współdzieloną warstwę magazynowania dla klastrów obliczeniowych HA.

Klastry obliczeniowe i HPC

Klastry obliczeniowe wysokiej wydajności używają harmonogramistów zadań (SLURM, PBS, LSF) do przydzielania węzłów do zadań obliczeniowych. Węzły są połączone przez InfiniBand lub szybki Ethernet w celu obsługi niskoopóźnieniowej, wysokoprzepustowej komunikacji MPI (Message Passing Interface), której wymagają równoległe obciążenia naukowe. W przypadku obciążeń akcelerowanych przez GPU — trenowanie głębokiego uczenia, dynamika molekularna, obliczeniowa dynamika płynów — infrastruktura GPU Hosting z połączeniami NVLink lub NVSwitch jest odpowiednią architekturą.

Praktyczne aspekty implementacji

Projekt sieci

Sieć klastra to nie jest jedna sieć. Prawidłowo zaprojektowany klaster posiada co najmniej trzy oddzielne segmenty sieciowe:

1. Sieć publiczna — ruch skierowany do klientów
2. Prywatne łącze wewnętrzne klastra — heartbeat i wewnętrzna komunikacja klastra
3. Sieć magazynowania — ruch iSCSI, NFS lub Fibre Channel do backendowego magazynu współdzielonego

Łączenie tych sieci na jednej karcie NIC lub sieci VLAN wprowadza rywalizację i tworzy scenariusze, w których nasycenie I/O magazynu zakłóca sygnały heartbeat, wywołując fałszywe przełączenia awaryjne.

Fencing i STONITH

STONITH (Shoot The Other Node In The Head) to mechanizm, za pomocą którego klaster przymusowo wyłącza lub resetuje węzeł, który uznaje za uszkodzony. Bez fencingu węzeł, który stał się nieresponsywny, ale nie jest w pełni martwy, może kontynuować zapis do współdzielonego magazynu, podczas gdy klaster już przełączył się awaryjnie — co jest gwarantowaną ścieżką do uszkodzenia danych. Implementacje STONITH obejmują sterowanie zasilaniem przez IPMI/iDRAC, przełączanie PDU i wymuszone wyłączenie zasilania na poziomie hiperwizora. Żaden klaster HA bez działającej konfiguracji fencingu nie jest w rzeczywistości klastrem HA.

Klastrowanie na poziomie aplikacji a klastrowanie na poziomie infrastruktury

Krytyczne rozróżnienie, które jest często pomijane: klastrowanie infrastruktury (Pacemaker, WSFC) zapewnia przełączanie awaryjne na poziomie węzła, ale aplikacja musi być również zaprojektowana tak, aby tolerować nagłe restarty. Bazy danych wymagają odtwarzania po awarii; serwery aplikacyjne mogą potrzebować ponownego nawiązania połączeń z backendami; pamięci podręczne mogą być zimne po przełączeniu awaryjnym. Klastrowanie na poziomie aplikacji — takie jak grupy replikacji baz danych, klastry Elasticsearch lub klastry brokerów Kafka — obsługuje spójność danych i dostępność na warstwie danych, niezależnie od infrastruktury poniżej. Środowiska produkcyjne zazwyczaj łączą oba podejścia: infrastrukturalne HA dla warstwy obliczeniowej i replikację na poziomie aplikacji dla warstwy danych.

Opóźnienie między węzłami

W przypadku replikacji synchronicznej opóźnienie między węzłami bezpośrednio wpływa na wydajność zapisu. Synchroniczne zatwierdzenie wymaga pełnego obiegu do repliki przed potwierdzeniem zapisu klientowi. Przy opóźnieniu między węzłami wynoszącym 1ms, teoretyczna maksymalna przepustowość synchronicznego zapisu wynosi 1 000 operacji na sekundę na wątek — niezależnie od tego, jak szybki jest lokalny dysk. Dlatego geograficznie rozproszone klastry synchroniczne są niepraktyczne powyżej ~100km między lokalizacjami, i dlatego replikacja asynchroniczna jest używana do odtwarzania po awarii między regionami.

Kiedy klastrowanie serwerów jest właściwym wyborem

Klastrowanie serwerów jest odpowiednie, gdy koszt przestoju lub utraty danych przekracza koszt infrastruktury klastrowej. Konkretne wskaźniki:

• Aplikacja posiada SLA wymagające dostępności na poziomie 99,9% lub wyższym (mniej niż 8,7 godziny przestoju rocznie)
• Obciążenie nie może być przerywane w celu łatania, wymiany sprzętu lub zmian pojemności
• Wzorce ruchu są nieprzewidywalne lub skokowe, wymagające elastycznego skalowania poziomego
• Wymogi regulacyjne nakazują redundancję danych i możliwość audytu (PCI-DSS, HIPAA, SOC 2)
• Aplikacja przetwarza transakcje finansowe, dokumentację medyczną lub komunikację w czasie rzeczywistym, gdzie utrata danych ma konsekwencje prawne

W przypadku mniejszych obciążeń, które nie spełniają tych kryteriów, dobrze skonfigurowane środowisko VPS Hosting z automatycznymi kopiami zapasowymi i monitoringiem może zapewnić wystarczającą odporność za ułamek kosztów.

Wyzwania i typowe tryby awarii

Koszty i narzut infrastrukturalny

Minimalny wykonalny klaster HA wymaga co najmniej dwóch węzłów, współdzielonego lub replikowanego magazynu danych, redundantnej sieci i licencji oprogramowania do zarządzania klastrem (tam gdzie ma to zastosowanie). W przypadku wdrożeń lokalnych oznacza to zazwyczaj mnożnik kosztów od 3x do 5x w porównaniu z wdrożeniem na pojedynczym serwerze. Klastrowanie oparte na chmurze z wykorzystaniem usług zarządzanych (AWS RDS Multi-AZ, Azure SQL Managed Instance) przenosi ten koszt na model wydatków operacyjnych, ale wprowadza uzależnienie od dostawcy.

Złożoność konfiguracji i wiedza operacyjna

Błędna konfiguracja klastra jest jedną z głównych przyczyn nieplanowanych przestojów w środowiskach korporacyjnych. Typowe błędy to:

• Fencing nieskonfigurowany lub nieprzetestowany — klaster nie może bezpiecznie odtworzyć się po awariach węzłów
• Kworum błędnie skonfigurowane — scenariusze split-brain uszkadzają współdzielone dane
• Zależności zasobów zdefiniowane nieprawidłowo — usługi uruchamiają się w złej kolejności po przełączeniu awaryjnym, powodując kaskadowe awarie
• Sieć heartbeat na tym samym interfejsie co ruch produkcyjny — skoki magazynu lub ruchu wywołują fałszywe przełączenia awaryjne

Bieżące zarządzanie klastrem wymaga inżynierów rozumiejących zarówno oprogramowanie klastrowe, jak i chronione przez nie aplikacje. Jest to odrębny zestaw umiejętności od ogólnej administracji systemami.

Wąskie gardła magazynowania

Współdzielony magazyn danych jest częstym wąskim gardłem wydajności w klastrach HA. Wszystkie węzły rywalizują o przepustowość I/O do tego samego backendowego magazynu. Źle zaprojektowane klastry magazynowania stają się czynnikiem ograniczającym dla całego systemu. Rozwiązania obejmują warstwowanie magazynu (NVMe dla gorących danych, dyski obrotowe dla zimnych), buforowanie odczytu na węzłach i rozproszone architektury magazynowania, które eliminują pojedynczy kontroler magazynu.

W przypadku obciążeń wymagających maksymalnej wydajności I/O i pełnej kontroli sprzętu, Serwery dedykowane z lokalnym magazynem NVMe i sprzętowym RAID zapewniają solidną podstawę do budowania węzłów klastra zoptymalizowanych pod kątem magazynowania.

Architektura klastra dla środowisk hostingu WWW

Klastry skierowane do sieci mają specyficzny wzorzec architektury wart szczegółowego omówienia:

[Client Requests]
        |
[Load Balancer Layer] (HAProxy / NGINX / cloud LB — active-active pair)
        |
[Application Server Layer] (Node 1, Node 2, Node N — stateless)
        |
[Database Layer] (Primary + Replica — HA cluster with automatic failover)
        |
[Shared Storage / Object Storage] (Ceph, NFS, S3-compatible)

Każda warstwa jest niezależnie skalowalna i redundantna. Serwery aplikacyjne są bezstanowe — stan sesji jest przechowywany we współdzielonym klastrze Redis lub Memcached, a nie na lokalnym węźle. Ten projekt oznacza, że dowolny węzeł aplikacyjny może zostać usunięty lub dodany bez wpływu na aktywne sesje.

Dla zespołów zarządzających infrastrukturą WWW na dużą skalę, środowiska VPS z cPanel zapewniają zarządzaną płaszczyznę sterowania, która upraszcza zadania zbliżone do klastrowych, takie jak zarządzanie DNS, provisioning SSL i konfiguracja wielu domen. Dla zespołów preferujących szczegółową kontrolę nad stosem klastrowym, Panele sterowania VPS oferują szereg opcji dostosowanych do różnych modeli operacyjnych.

Terminacja SSL w klastrowym środowisku WWW zasługuje na szczególną uwagę: load balancer zazwyczaj obsługuje terminację TLS, deszyfrując ruch przed jego dystrybucją do węzłów backendowych przez sieć wewnętrzną. Wymaga to, aby Certyfikaty SSL były provisionowane i odnawiane na warstwie load balancera, a nie na poszczególnych węzłach aplikacyjnych — jest to częsta błędna konfiguracja powodująca błędy certyfikatów po przełączeniu awaryjnym węzła.

Macierz decyzyjna techniczna

Użyj tej macierzy, aby określić odpowiednią architekturę klastra dla danego obciążenia:

Praktyczna lista kontrolna kluczowych wniosków

Przed wdrożeniem klastra serwerowego zweryfikuj każdy z poniższych punktów:

• Kworum jest skonfigurowane z nieparzystą liczbą głosów lub dedykowanym rozstrzygaczem — nigdy nie wdrażaj klastra dwuwęzłowego bez świadka kworum
• Fencing (STONITH) jest przetestowany poprzez fizyczne odłączenie kabla sieciowego i potwierdzenie, że klaster prawidłowo izoluje węzeł i kończy przełączanie awaryjne
• Sieci heartbeat i produkcyjna są na oddzielnych fizycznych interfejsach — nigdy ich nie łącz
• Multipath magazynu (MPIO) jest skonfigurowany z co najmniej dwiema niezależnymi ścieżkami do współdzielonego magazynu
• Opóźnienie replikacji jest monitorowane z progami alertów zdefiniowanymi przed przekroczeniem RPO
• Przełączanie awaryjne zostało przetestowane pod obciążeniem — klaster, który nigdy nie był testowany, nie jest klastrem, jest teorią
• Zachowanie aplikacji po przełączeniu awaryjnym jest zweryfikowane — potwierdź, że aplikacja łączy się ponownie z nowym węzłem podstawowym, czyści nieaktualne połączenia i prawidłowo obsługuje ruch
• Zdarzenia klastra są rejestrowane na centralnym, zewnętrznym serwerze logów — nie w lokalnym magazynie węzła, który może być niedostępny podczas awarii, którą próbujesz zdiagnozować
• Certyfikaty SSL są provisionowane na warstwie load balancera, a nie na poszczególnych węzłach backendowych
• Planowanie pojemności uwzględnia dostępność N-1 węzłów — klaster musi obsługiwać pełne obciążenie produkcyjne przy jednym węźle wyłączonym

Często zadawane pytania

Jaka jest minimalna liczba węzłów wymagana dla klastra serwerowego?

Technicznie dwa węzły są wystarczające dla klastra HA aktywny-pasywny. Jednak klaster dwuwęzłowy wymaga świadka kworum (trzeciego zasobu rozstrzygającego), aby zapobiec split-brain. W przypadku klastrów aktywnych-aktywnych równoważących obciążenie, trzy węzły to praktyczne minimum, aby zachować redundancję przy usunięciu jednego węzła w celu konserwacji.

Czym jest split-brain w klastrze serwerowym i dlaczego jest niebezpieczny?

Split-brain występuje, gdy wewnętrzna sieć komunikacyjna klastra zawodzi, powodując utratę kontaktu między węzłami. Każdy węzeł dochodzi do wniosku, że drugi zawiódł i próbuje jednocześnie przejąć kontrolę nad współdzielonymi zasobami. Jeśli oba węzły zapisują do tego samego współdzielonego magazynu jednocześnie bez koordynacji, wynikiem jest uszkodzenie danych. Mechanizmy kworum i fencing STONITH to dwie obrony przed split-brain.

Czym klastrowanie serwerów różni się od wirtualizacji serwerów?

Wirtualizacja dzieli jeden fizyczny serwer na wiele izolowanych maszyn wirtualnych. Klastrowanie łączy wiele serwerów, aby działały jako jeden system. Oba podejścia są komplementarne: zwirtualizowane serwery (VM) są często używane jako węzły klastra, a platformy hiperwizorów, takie jak VMware vSphere, zawierają własne funkcje klastrowania HA działające na poziomie VM, a nie systemu operacyjnego lub aplikacji.

Czy klastrowanie serwerów może wyeliminować wszystkie przestoje?

Nie. Klastrowanie drastycznie redukuje nieplanowane przestoje poprzez automatyzację przełączania awaryjnego, ale ich nie eliminuje. Samo przełączanie awaryjne zajmuje czas (od sekund do minut w zależności od obciążenia i konfiguracji klastra). Ponadto błędy w oprogramowaniu klastrowym, jednoczesne awarie wielu węzłów i scenariusze partycji sieciowej mogą powodować przestoje, którym klastrowanie nie może zapobiec. Celem jest spełnienie zdefiniowanego SLA dostępności, a nie osiągnięcie absolutnego zerowego przestoju.

Jaka jest różnica między klastrem HA a konfiguracją odtwarzania po awarii (DR)?

Klaster HA zapewnia automatyczne, niemal natychmiastowe przełączanie awaryjne w obrębie tej samej lokalizacji lub strefy dostępności, zazwyczaj z RPO = 0 i RTO mierzonym w sekundach do minut. Konfiguracja DR replikuje dane do geograficznie oddzielnej lokalizacji i wymaga ręcznej lub półautomatycznej interwencji w celu aktywacji, z RTO mierzonym w minutach do godzin i niezerowym RPO ze względu na replikację asynchroniczną. Środowiska produkcyjne wymagające zarówno lokalnej odporności, jak i geograficznej redundancji wdrażają klastrowanie HA w obrębie lokalizacji i replikację DR między lokalizacjami.