Bunkier w serwerowni - Axxana Phoenix System RP

Jednym ze sposobów zabezpieczania danych na macierzy jest ich replikacja do analogicznego urządzenia w lokalizacji zdalnej. Macierz źródłowa używana jest jako maszyna produkcyjna, a wszystkie zmiany przesyłane są do lokalizacji zapasowej. Dzięki temu uszkodzenie/zniszczenie macierzy, a nawet katastrofa (ogień,powódź, zawalenie się budynku) całego centrum komputerowego nie doprowadzi do utracenia przez nas danych.


Replikacja w skrócie:

Replikację można podzielić, z grubsza ,na dwa typy:

Synchroniczna - zapewnia, że w każdej chwili  na macierzy zdalnej, jest dokładny obraz danych produkcyjnych.  Każdy zapis/zmiana przez serwer podpięty do macierzy jest wysyłany do zdalnej lokalizacji i dopiero po przyjściu jego potwierdzenia zapisu, host jest informowany o udanej zmianie.
Zaletą tej replikacji jest zerowa wartość RPO czyli, w przypadku awarii, nasza kopia jest identyczna jak dane na uszkodzonej maszynie. Wady to, przede wszystkim, zwiększony czas oczekiwania i ograniczona odległość na którą można stosować to rozwiązanie (ok 100km).

Asynchroniczna - Potwierdzenie zapisu wraca do hosta od razu po jego wykonaniu na macierz źródłowej. Wszyskie bloki danych które się zmieniły są zapisywane w odrębnym miejscu i cyklicznie wysyłane "w paczce" na drugą macierz. Długość tego cyklu wysyłania danych określa nam jakie RPO uzyskujemy, Np: wysyłając zmiany co 15 minut, w najgorszym przypadku po awarii mamy możliwość pracownia na danych sprzed kwadransu. To jest oczywiście wada tej replikacji, w porównaniu do synchornicznej. Zalety to mniejsze wymagania co do parametrów łącza, szybsze działanie i brak ograniczeń związanych z maksymalną odległością między dwoma serwerowniami.


Axxana Phoenix System RP

Jak widać obydwa typy replikacji mają swoje wady i zalety.
Pytanie , czy istnieje rozwiązanie łączące te drugie i eliminujące pierwsze.
Oczywiście nie, ale istnieje dość dobry zastępnik, który marketingowo nazywany jest "Replikacją synchroniczną po asynchronicznej infrastrukturze"
Produkt posiadający te rozwiązanie to Axxana Phoenix System RP.
Zasada działania niczym nie różni się od zwykłej macierzy z włączoną asynchroniczną replikacją ( wykorzystywany jest Recovery Point od EMC) - zmienione dane są zapisywane i cyklicznie wysyłane do lokalizacji zdalnej. Cały trik polega jednak na miejscu, gdzie te zmiany,są przechowywane przed wysłaniem. Jest to EDR (Enterprise Data Recording) black box.


EDR black box

Pojemnik, w którym znajdują się nie wysłane jeszcze lokalizacji zdalnej dane, jest oparty na technologi używanej do budowy "czarnych skrzynek" w samolotach. Oznacza to, że może wytrzymać ogień o temperaturze ponad 1000 stopni, zalanie wodą, uderzenia, wstrząsy oraz najróżniejsze siłowe próby zniszczenia/uszkodzenia, a także ochronić przed tymi czynnikami swoją zawartość.
Zabezpieczenia te gwarantują, że nawet w przypadku np: zawalenia budynku z serwerownią, dane nie przesłane do lokalizacji zapasowej są bezpieczne. Problematyczne może być wysłanie paczki zmian po takiej katastrofie do drugiej macierzy ale i na to jest rozwiązanie: Phoenix System potrafi w przypadku zniszczenia infrastruktury sieciowej, komunikować się i zainicjować transfer za pomocą sieci komórkowej. Nadajnik oczywiście także jest zabezpieczony i znajduje się wewnątrz EDRa.

Dla zainteresowanych polecam następujący film na serwisie YouTube na którym naocznie można przekonać się jakie "tortury" jest w stanie wytrzymać "black box" ( w menu: palenie, dziurawienie, przygniatanie, potrząsanie i inne):

Reasumując:


Rozwiązanie jest ciekawe i dość "efektowne" (przynajmniej przy oglądaniu "testów"). Oczywiście nie zastąpi prawdziwej replikacji synchronicznej i w niektórych przypadkach może być dość problematyczne (wysyłanie dużej ilości danych poprzez sieć komórkową) ale w przypadku gdy odległość między naszymi centrami komputerowymi jest znacznie większa niż 100km może być dobrym zastępnikiem rozwiązania gwarantującego zerową utratę danych (RPO=0) przy awarii/katastrofie.

Do poczytania:

Opis EDRa
Axxana Phoenix System RP
THE PHOENIX SYSTEM RP

ISM - Replikacja zdalna

Replikacja zdalna jest to tworzenie repliki w innej lokacji. Druga lokacja (macierz) na którą wykonuje się replikacje może być kilka metrów od macierzy źródła lub znajdować się na innym kontynencie.

Replikowanie zdalne zabezpiecza dane przed ich utratą spowodowaną przez lokalną katastrofę ( powódz, pożar, zamieszki itd...)

Wyróżnia się dwa podstawowe typy replikacji: Synchroniczną i Asynchroniczną. Dane pomiędzy lokacjami mogą być przesyłane na kilka sposobów, poprzez: Sieć IP, Sieć SAN, za pomocą Dense Wave Division Multiplexing (DWDM) lub Synchronous Optical Network (SONET)

Replikacja Synchroniczna:

W replikacji synchronicznej każdy zapis wykonany przez hosta zostaje przesłany z macierzy źródła, na macierz cel, następnie cel potwierdza zapis danych i dopiero po tym macierz źródłowa wysyła do hosta potwierdzenie wykonania operacji. Takie działanie powoduje, że przez cały czas, na obydwu macierzach są te same dane, dodatkowo zachowywana jest kolejność zapisów. RPO jest zerowe , RTO wynosi tyle ile potrzeba do uruchomienia aplikacji po stronie celu.

Replikacja synchroniczna ma wysokie wymagania, jeżeli chodzi o przepustowość łącza, pomiędzy dwoma lokalizacjami. Musi być ono w stanie obsłużyć maksymalne obciążenia generowane przez I/O

Ten rodzaj replikacji zwykle nie jest możliwy na odległości większe niż 100-200km

Replikacja Asynchroniczna:

W tej replikacji po wysłaniu żądania zapisu przez hosta, dane zostają zapisane na macierzy źródle i od razu host otrzymuje potwierdzenie. Źródło buforuje nowe dane i periodycznie wysyła do drugiej lokacji. RPO jest niezerowe i zależne od częstości wysyłania danych do macierzy celu. Zużycie łącza jest dużo niższe i zwykle przepustowość może być mniejsza niż typowe obciążenie I/O generowane przez hosta. Na macierzy źródle należy utrzymywać bufory na dane przygotowywane do wysłania. Ten rodzaj synchronizacji może być implementowany na długich dystansach.

Rodzaje replikacji zdalnej:

Ze względu na poziom na jakim działa replikacja zdalna, podobnie jak w przypadku replikacji lokalnej możemy wyróżnić dwa jej typy:

• Host Based Replication
• Logical Volume Manager (LVM) based
• Log Shipping
• Storage Array based
• Support both synchronous and asynchronous mode
• Disk Buffered - Consistent PITs

Host Based Replication: LVM Based

Odbywa się na poziomie LVMowych volume grup (więcej o LVMie jest w poprzednim wpisie). LVM, na hoście źródle, wysyła poprzez sieć IP wszyskie zapisy, do swojej volume grupy, LVM na źródle zapisuje te zmiany do volume grupy docelowej. Ten typ replikacji może działać zarówno w sposób synchroniczny jak i asynchroniczny, dane są wtedy wpierw zapisywane do log file na źródle i dopiero potem wysyłane do celu. Log file jest także wykorzystywany, jako tymczasowe miejsce przechownia zmian w przypadku utraty połączenia. Ten rodzaj replikacji pozwala utrzymywać kopię danych bez potrzeby używania sieci SAN.

Zalety:

• Różne poziomy RAID mogą być zdefiniowane na celu i źródle

Wady:

• Długie problemy z połączeniem siecowym, powodują powstawanie wielkich log filów.
• Negatywny wpływ na wydajność hosta

Host Based Replication: Log Shipping

Jest to rodzaj replikacji na poziomie hosta, wykorzystywany przez bazy danych. Transakcje wykonywane na źródle są zapisywane do logu, który następnie jest periodycznie wysyłany na źródło. Źródło zapisuje loga a następnie wprowadza zawarte w nim operacje do swojej bazy. RPO jest zależne od wielkości loga i częstotliwości jego wysyłania. Zaletami tego typu replikacji jest małe zużycie CPU oraz małe wymagania dotyczące przepustowości łącza.


Storage Array Based Remote Replication

W tym rodzaju replikacji podobnie jak w przypadku lokalnym (poprzedni wpis) wszystkie operacje odbywają się i są zarządzane przez macierz - powoduje to zwolnienie zasobów CPU. Do połączenia między macierzami można wykorzystać łącze dedykowane lub współdzielone.
Replikacja Storage Based może występować w wersji synchronicznej (potwierdzenie zapisu do hosta zostaje wysłane dopiero po otrzymaniu potwierdzenia o zapisaniu zmiany na macierzy celu ) lub asynchronicznej ( potwierdzenie zapisu zostaje wysłane do hosta natychmiast, a dane ze źródła na cel są wysyłane co pewien ustalony okres czasu). W replikacji asynchronicznej stosowane są różne metody zapewnienia spójności danych , niektórzy producenci dołączają do każdego żądania znacznik czasowy, tak żeby na macierzy celowej zachować kolejność z zapisów. Innym sposobem jest zapisywanie na bufor cache przez zadany okres czasu, a następnie zablokowanie bufora w stanie spójnym i przesłanie go na drugą stronę.


Storage Array Based - Disk Buffered Replication

Jest to połączenie lokalnej i zdalnej replikacji na poziomie macierzy. Najpierw spójna kopia PIT (snapshot) jest tworzona lokalnie na macierzy źródle. Następnie ta replika jest przesyłana na macierz docelową. RPO jest zależne od częstości


Replikacja na trzy lokacje.

W replikacji synchronicznej źródło i cel nie mogą być oddalone od siebie bardziej niż około 200km. Powoduje to, że taka konfiguracja jest wrażliwa na katastrofy o lokalnym zasięgu. Rozwiązaniem jest stosowanie replikacji asynchronicznej i lokacji odległych o setki czy tysiące kilometrów. W takich konfiguracjach jednak RPO jest niezerowe i często nie akceptowalne.
Rozwiązaniem jest replikacja na trzy lokacje (Three site replication).
Replikacja tego rodzaju może odbywać się na dwa sposoby:

• Cascade/Multi-hop
• Triangle/Multi-target

Cascade/Multi-hop:

SOURCE----------->BUNKER---------->TARGET

W tym rodzaju replikacji przepływ danych jest następujący: Ze źródła (SOURCE) dane są synchronicznie replikowane na BUNKER a z niego asynchronicznie lub metodą Disk Buffered na TARGET

Triangle/Multi-target:

W rozwiązaniu cascade/multi-hop mamy większą niezawodność, niż przy dwóch lokacjach, ale zagrożenie nie jest wyeliminowane całkowice. Utrata BUNKER powoduje, że aplikacje działają na produkcji, ale brak jakiejkolwiek replikacji na TARGET. Wady te eliminuje rozwiązanie Triangle/Multi-target, gdzie każda lokalizacja jest połączona z dwoma pozostałymi.

Schemat przepływu danych jest następujący: Ze SOURCE dane są synchronicznie replikowanie na BUNKER oraz asynchronicznie na TARGET. Pomiędzy BUNKER a REMOTE zestawiona jest również replikacja asynchorniczne z dyferencyjną resychronizacją (Asych with Differential Resynch).

Takie rozwiązanie gwarantuje, że po utracie lokacji dane nie dość że są dostępne, to jeszcze mamy rozwiązanie DR (Disaster Recovery) - czyli jesteśmy w stanie przetrwać utratę drugiej lokalizacji.

SAN Based Remote Replication

Ten rodzaj replikacji może odbywać się pomiędzy macierzami różnych producentów. Dane są przesyłane poprzez SAN/WAN. Samą replikacją steruje jedna z macierzy, nazywana "contolling array". Macierz docelowa nosi nazwę "Remote array". W SAN Based Remote Replication możliwe są dwie operacje: push i pull. Push polega na wysłaniu danych z control array do remote array , natomiast pull to przesłanie danych z remote array do control array. Obydwie te czynności nadzoruje i inicjuje control array.

Nośniki zdalnej replikacji

Aby zdalna replikacja mogła mieć miejsce między macierzami biorącymi w niej udział musi istnieć połączenie.

Przykłady takiego połączenia to:

• ESCON i FC dla krótszych odległości
• IP network dla dalekich dystansó
• Sieci optyczne: DWDM i SONET

---

Sekcja nr 3 została oficjalnie skończona, została jeszcze część 4 opisująca zabezpieczanie i zarządzanie zasobami storage. Z racji pewnych zmian zachodzących ostatnio w moim życiu zawodowym wpisy mogą pojawiać się nieco rzadziej, choć będę chciał utrzymać poziom co najmniej jednego nowego na tydzień.

Zobaczymy czy się uda.

ISM - Metody lokalnej replikacji

Metody lokalnej replikacji można podzielić na dwie kategorie:

• Host based
• Storage Array based

Gdy mówimy o lokalnej replikacji typu host based, to odbywa się ona z wykorzystaniem zasobów hosta (CPU) i na poziomie hosta, poprzez pracujący na nim software. W tym przypadku o lokalnej replikacji mówimy jeżeli odbywa się w zakresie jednego datacenter. Przykładami replikacji lokalnej tyou host based są: Logical Volume Manager (LVM) base mirroring i File System Snapshot

Replikacja lokalna typu Storage Array based odbywa się w obrębie jednej macierzy i wykorzystuje jej zasoby do stworzenia kopii danych. Przykładami replikacji tego typu są: Full volume mirroring , Pointer based full volume replication, Pointer based virtual replication

Replikacja host based: LVM Based Mirroring

W tej metodzie za replikację jest odpowiedzialny LVM, który składa się z trzech komponentów:

• Wolumeny fizyczne (physical volumes) - tożsame z dyskami
• Grupy wolumenów (volume groups) - jeden lub większa ilość wolumenów fizycznych
• Logiczny wolumen (logical volumes) - struktura logiczna zbudowana w obrębie jednej grupy

Przy replikacji na poziomie LVMa, każda partycja logiczna (struktura w logicznym wolumenie) jest podmapowana do dwóch partycji fizycznych. Aplikacja pisze do podmapowanej partycji logicznej a sterownik LVMa zapisuje na dwie partycje fizyczne. Ta metoda jest także znana jako LVM mirroring.

Dwie zmirrorowane partycje fizyczne mogą być rozdzielone.

Replikacja host based: File System Snapshot

Snapshot FSa to replika oparta na wskaźnikach do danych. Metoda ta wykorzystuje dwie struktury bitmape i mapę bloków:

• Bitmap : używana jest do śledzenia bloków które ulegają zmianie po stworzeniu snapshota. Początkowo cała wypełniona jest zerami.
• Block map : zawiera wskaźniki do bloków danych które musza byc odczytane ze snapshota

Mechanizm działania snapshota jest następujący: podczas jego tworzenia, powstają także bitmapa i block mapa. Przy zapisywaniu danych stosowany jest mechanizm Copy on First Write (COFW) - oznacza to że przy pierwszej zmianie danego bloku, dane nie są nadpisywane ale przekopiowywane na nowe miejsce. Następnie bit w bitmapie odpowiadającej za ten blok danych zmienia swoją wartość z 0 na 1 , a wskaźnik w block mapie zaczyna wskazywać na miejsce do którego przekopiowano dane. 

Dzięki zastosowaniu tej metody snapshot zajmuje tylko tyle miejsca ile zajmują zmiany wykonane od czasu jego wykonania do chwili obecnej. Wadą tego typu replikacji jest wyższe zużycie CPU ( LVM musi zajmować się śledzeniem zmian).

Replikacja storage based: Full Volume Mirroring

W full volume mirroring-u do LUNa źródłowego jest przypisany (attached) LUN docelowy i między nimi ustalone jest powiązanie typu mirror. Wszyskie dane zostają przegrane z źródła do celu, nowe zmiany także są synchronizowane. LUN źródłowy i docelowy mają dokładnie te same dane.
Jeżeli cel jest w stanie: przypisany (attached) wtedy jest on niedostępny dla hostów.
Taką struktrurę można rozłączyć (detached) w takim przypadku cel staje się PIT (Point in time) repliką LUNa źródła i może zostać podłączony do hostów np w celach testowych lub do zrobienia backupu.
Po rozłączeniu zmiany zarówno na LUNie źródłowym jak i docelowym są śledzone i przy ponownym przypisaniu synchronizowaniu ulegają jedynie zmiany.


Replikacja storage based: Pointer Based Full Volume Replication

Ten typ replikacji tworzy replikę od razu dostępną po włączeniu sesji replikacyjnej ( nie ma potrzeby czekania aż istniejące dane przekopiują się ze źródła do celu ), od razu kopia jest też dostępna do wystawienia dla hostów. Czas aktywowania definiuje PIT kopii.
Pointer based, full volume repliaction może być uruchomiona w dwóch trybach:

• Copy on First Access (CoFA)
• Full Copy

W obydwu przypadkach, podczas aktywowania replikacji tworzona jest bitmapa dla wszystkich danych na źródle. Wskaźniki w tej bitmapie wiążą puste bloki na celu z blokami z danymi na źródle. Następnie w zależności od trybu w jakim działa replikacja dane są kopiowane ze źródła do celu.

Copy on First Access:

W tym trybie dane są kopiowane na źródło zawsze kiedy host próbuje się do nich odnieść po raz pierwszy od stworzenia PIT kopii.
Nieco dokładniejszy opis tego procesu:

• Kiedy do źródła jest wysyłane ( po raz pierwszy) żądanie zapisu - oryginalne dane są kopiowane na cel + nowe dane są zapisywane na źródle. Dane zostają oznaczone (na bitmapie) jako przekopiowane.
• Kiedy do celu wysyłane ( po raz pierwszy) jest żądanie odczytu - oryginalne dane są kopiowane ze źródła na cel. Dane zostają oznaczone (na bitmapie) jako przekopiowane.
• Kiedy do celu jest wysyłane (po raz pierwszy) jest żądanie zapisu - oryginalne dane są kopiowane ze źródła na cel a następnie nadpisywane nowymi danymi. Dane zostają oznaczone (na bitmapie) jako przekopiowane.

Kluczowy tutaj jest fakt oznaczania danych jako przekopiowanych. Po tej zmianie zarówno dane na źródle jak i na celu mogą się zmieniać, co doprowadza do sytuacji, że oryginalna PIT kopia przestaje istnieć.

Full Copy Mode:
W tym trybie od razu po stworzeniu PIT kopii (aktywacji sesji replikacyjnej) rozpoczyna się proces kopiowania w tle wszystkich danych ze źródła na cel.

Replikacja storage based: Pointer Based Virtual Replication

W tym rodzaju replikacji po uruchomieniu cel zawiera tylko wskaźniki do danych na źródle. Początkowo wielkość repliki jest równa zero. W tej metodzie replikacji cel jest nazywany virtualną repliką, ponieważ nie jest LUNem czy przestrzenią dyskową ale zbiorem wskaźników.
Pointer Based Virtual Replication używa mechanizmu Copy on First Write ( CoFW)
CoFW działa następująco:

• Kiedy do źródła jest wysyłane ( po raz pierwszy) żądanie zapisu - oryginalne dane są kopiowane do pewnego wcześniej zdefiniowanego obszaru na macierzy (tzw: save location). Wskaźnik na celu jest zmieniany na tą nową lokację. Po wykonaniu tego orginalne dane na źródle są nadpisywane. 
• Kiedy do celu jest wysyłane (po raz pierwszy) jest żądanie zapisu - oryginalne dane są kopiowane ze źródła na save location, a następnie zmianie ulegają wskaźniki w celu. Potem wykonuje się jeszcze jedną kopię danych w save location i dopiero potem nadpisuje je nowymi danymi.

---

Tyle o lokalnej replikacji - pominąłem trochę materiału o szczegółach dotyczących śledzenia zmian i odtwarzania z repliki. Sprawy raczej oczywiste i wynikające już z tego co zostało napisane.

Kolejny wpis będzie o zdalnej replikacji i na tym skończymy trzecią (z czterech) sekcji przygotowujących do egzaminu na EMC Proven Associate.

ISM - Lokalna replikacja i pojęcie spójności danych

Czym jest replikacja:

Replika - dokładna kopia.
Replikacja - proces tworzenia repliki.
Lokalna replikacja - replikowanie danych w obrębie jednej macierzy lub w obrębie jednego data center.


 Wykorzystanie replik:

• Alternatywne źródło backupów - przeważanie backupy robi się z volumenów produkcyjnych, jednak powoduje to dodatkowe obciążenie wydajnościowe dla tych urządzeń. Aby uniknąć spadku wydajności można robić replikę PIT ( point-in-time) i jej używać jako źródła do backupu. Dodatkową zaletą takiego wykorzystania replik jest zmniejszenie okna backupowego.
• Szybsze odtworzenia - wykorzystanie replik pozwala na szybsze odtworzenie danych, w przypadku ich utraty lub awarii.
• Redukcja obciążenia volumenów produkcyjnych - niektóre działania np: raportowanie można wykonywać na replikach zamiast na "głównych" danych. Pozwala to na odciążenie volumenów produkcyjnych.
• Testowanie - repliki można wykorzystywać do różnego rodzaju testów. Najczęstszym przypadkiem są upgrady aplikacji i OSów - najpierw przeprowadza się je na replice i sprawdza czy działanie systemu jest poprawne.
• Migracja danych - lokalne repliki mogą zostać wykorzystane do przeprowadzenia migracji danych nie wpływających na niedostępność systemów produkcyjnych.

Typy replik:

Repliki możemy podzielić na dwa typy z punktu widzenia RPO: 

• PIT (Point-in-time)
• Continuos

Repliki PIT są wykonywane w danej chwili i zawierają dane produkcyjne z pewnego określonego punktu w czasie. RPO jest niezerowe i oczywiście zwiększa się razem z upływem czasu, który minął od stworzenia repliki. Repliki tego typu mogą być wykonywane przed przeprowadzeniem pewnych działań, mogących spowodować korupcję danych ( np wgrywnie patchy). 

Repliki continuos polegają na ciągłym utrzymywaniu dokładnej repliki danych produkcyjnych. Zmiany dokonywane na źródle są od razu sygnalizowane i synchronizowane z repliką. RPO przy tego typu replikcji jest bliskie (lub równe) zero.

Cechy dobrej repliki:

Aby uznać mechanizm replikacyjny i replikę za "dobrą" powinny być spełnione następujące warunki:

• Spójność (Consistency) - podstawowa cecha każdej repliki. Zapewnia, że dane zostały skopiowane w sposób właściwy i pełny oraz, że replika jest spójna z danymi produkcyjnymi
• Odtwarzalność po awarii - musimy być w stanie odtworzyć dane z repliki po ich uszkodzeniu/utracie na produkcji
• Używalność - musimy być w stanie, w razie potrzeby, uruchomić produkcję bezpośrednio na danych zreplikowanych (zachodzi to w przypadku gdy nie tylko utracone/uszkodzone zostały dane źródłowe, ale także sam sprzęt (macierz) źródłowy jest niedostępny)

Spójność danych:

Warunkiem koniecznym do działania i używalności repliki jest aby dane na niej były spójne.
Większość systemów plików i baz danych buforuje dane w pamięci, zanim zapisze je na dyski - aby replika była spójna, należy zadbać, aby wszystkie dane buforowane były zapisane na dyskach, w momencie jej tworzenia. Dla systemów plików spójność z repliką można zapewnić na dwa sposoby. Metoda offline polega na odmontowaniu FSa przed zrobieniem repliki, natomiast sposób onlinowy na wyczyszczeniu bufora hosta (Flush host buffer)  przed replikacją. Podobne dwie metody są możliwe przy pracy z bazami danych: baze można zamknąć przed zrobieniem jej repliki (offline) lub przełączyć na specjalny tryb (hot backup mode), jeżeli zależy nam na replikacji w online.


Spójność systemu plików: Flushing Host Buffer

FS buforuje dane w pamięci RAM hosta, żeby przyśpieszyć działanie aplikacji. Zbuforowane informacje są periodycznie zrzucane na dyski. W systemach UNIXowych zajmuje się tym sync demon, który czyści ram z danych zbuforowanych, co pewien ustalony interwał. Wykonanie repliki, kiedy system jest podmontowany i zbuforowane dane nie są nagrane na dyski, kończy się niespójną kopią. Replika z odmontowanego systemu jest zawsze spójna, gdyż automatycznie przed procesem odmontowanie, zachodzi zrzut wszyskich danych zbuforowanych w pamieci na dysk.


Spójność bazy danych: Dependent Write I/O

Dependent Write jest to żądanie zapisu, które nie będzie wystawione przez aplikację, zanim inny, powiązany z nim zapis nie zostanie zakończony. Przykładem Dependent Write w bazach danych jest zlecenie zapisu do bazy, które jest zależne, od udanego zakończenia zapisu do loga. Dependency Write zapewniają iż baza pozostanie spójna, nawet w przypadku utraty zasilania (power outage).
Dependent Write także musi zostać zachowane, jeżeli chcemy wykonać spójną replikę bazy danych ,w trybie online. W tym przypadku "flush host buffer" z RAMu na dyski, który jest potrzeby aby zachować spójność FSa, także musi być wykonany z zachowaniem "zapisów zależnych", czyli wykonywanych w odpowiedniej kolejności.


Spójność bazy danych: Holding I/O

Kolejną metodą zapewnienia spójności onlinowej repliki jest wstrzymanie I/O do i z bazy, stworzenie repliki, a następnie ponowne uruchomienie I/O. Większość baz posiada umiejętność przetrwanie w stanie spójnym przerwy w dostawie prądu, co w działaniu jest dość podobne do wstrzymania I/O.

---

Muszę przyznać, że całkiem ciekawe te materiały dotyczące replikacji. Może dlatego, że nigdy za bardzo nie zastanawiałem się nad zachowaniem spójności danych na poziomie wyższym niż samej macierzy.
Kolejny wpis ( i chyba jeszcze następny też) będzie dalej poruszał się w obrębie replik.