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.