Replikacja serwerów i danych

Replikacja to ciągłe albo częste kopiowanie stanu maszyny albo wolumenu na drugi serwer. Cel jest prosty: gdy padnie węzeł A, węzeł B ma w miarę świeży obraz i da się na nim uruchomić pracę bez składania systemu od zera. Na stronie o serwerach dla firm ten mechanizm pojawia się przy wysokiej dostępności, a nie przy archiwum dokumentów.

Replika nie zastępuje kopii z historią. To, co skasujesz na produkcji, po chwili znika też na replice. Ransomware, który zaszyfruje dysk, zaszyfruje albo uszkodzi także strumień replikacji, jeśli nie ma osobnego repozytorium z retencją. Dlatego obok replikacji stoi Veeam Backup albo inny program z punktami przywracania wstecz, a nie sama „druga kopia w czasie rzeczywistym”.

Opóźnienie replikacji (RPO repliki) bywa minutowe albo godzinne. Im krótsze, tym większe wymagania na łącze i na dysk docelowy. Firma z łączeniem 50 Mb/s między lokalizacjami nie utrzyma synchronicznej replikacji bazy o ciągłym zapisie bez kolejek. Asynchroniczna replikacja z opóźnieniem kilku minut jest wtedy uczciwszym opisem niż obietnica „zero utraty danych” na słabym łączu.

Częsty błąd to nazwanie replikacji backupem w umowie i w rozmowie z klientem. Drugi błąd to replika w tej samej szafie, w tym samym switchu i na tym samym UPS: przeżywa awarię dysku, nie przeżywa pożaru ani awarii zasilania całej szafy. Trzeci błąd to brak testu przełączenia. Replikacja, której nikt nie przełączał przez rok, w dniu awarii odkrywa brak sterownika, brak licencji albo inny adres IP, którego aplikacje nie znają.

Replikację dobieramy do systemów, przy których minuta przestoju boli bardziej niż cena drugiego węzła: produkcja, terminal, kontroler domeny. Katalog ze skanami sprzed pięciu lat dostaje zwykłą kopię nocną. Mieszanie obu potrzeb w jednym „wszystko się replikuje” droży łącze i nie skraca odtwarzania archiwum.

Przy wdrożeniu spisujemy: co jest źródłem, co jest celem, jakie jest maksymalne opóźnienie i kto ma prawo przełączyć ruch. Bez tej listy w nocy ktoś „dla pewności” przełącza produkcję na replikę, która jest o dwie godziny do tyłu, i nadpisuje nowsze dane. Procedura powinna mówić też, czy po przełączeniu stara produkcja wraca jako nowa replika, czy najpierw idzie diagnostyka. Sam fakt, że bajty płyną, nie oznacza gotowości do pracy użytkowników. Gotowość widać dopiero wtedy, gdy księgowa albo magazynier zaloguje się i wystawi dokument na węźle zapasowym bez ręcznego przepisywania adresów.

Replikacja między lokalizacjami wymaga też uczciwego opisu łącza: stała przepustowość, opóźnienie, co się dzieje, gdy łącze padnie na trzy godziny. W tym oknie produkcja działa, a cel przestaje doganiać. Po powrocie łącza idzie doganianie (catch-up), które potrafi zająć łącze na resztę dnia. Warto mieć alert na lag replikacji powyżej ustalonego progu, nie tylko na „job failed”. Próg bierze się z RPO, które firma spisała. Jeśli nikt nie chce spisać RPO, nie ma sensu obiecywać replikacji „prawie na żywo”. Lepiej powiedzieć: opóźnienie do X minut przy zdrowym łączu, a przy awarii łącza decyzja o przełączeniu jest ręczna i ma właściciela. Taki opis przeżywa rozmowę z zarządem i audyt bez wstydliwych dopowiedzeń.