1.3.1.3.1. Archiwum replikowane

 

 

 

Jak działa archiwum replikowane?

 

Archiwum replikowane ma zastosowanie na serwerach, na których Asmen nie ma kanałów fizycznych dla danych archiwizowanych w danym zasobie, a równocześnie w sieci dostępne jest inne archiwum, z którego można pozyskać dane historyczne. Dla archiwum replikowanego Aspad nie pobiera danych bieżących z Asmena. W zamian stale pozyskuje dane historyczne z innego serwera, na którym archiwizowane są dane z kanałów fizycznych, zapisując je we własnym archiwum. Typowym zastosowaniem są serwery pośredniczące.

Sposób działania nieco się różni dla archiwum standardowego i SQL.

 

Archiwum standardowe

 

Dla archiwum standardowego Aspad po uzupełnieniu danych przy starcie systemu, kontynuuje to uzupełnianie (replikuje dane), cyklicznie sprawdzając nowe dane pojawiające się na drugim serwerze. Nawet dłuższe przerwy w komunikacji są na bieżąco nadrabiane po uzyskaniu łączności, aż do ograniczenia podanego w deklaracji Minimalny okres uzupełniania na zakładce Uzupełnianie w parametrach danego archiwum.

Także na wspomnianej zakładce Uzupełnianie  można określić nazwy serwerów, z których mają być pobierane dane do replikacji.

 

Rys. Klasyczne archiwum - archiwizacja danych z modułu Asmen.

 

 

 

 

 

Rys. Archiwum replikowane - realizacja architektury kolektor-serwer.

 

 

 

 

Archiwum SQL

 

Jeżeli dla danego zasobu nie podano deklaracji synchronizacji archiwum SQL, to archiwum replikowane działa tak samo, jak standardowe.

Jeżeli zadeklarowano opcję Synchronizacja w Architekt > Obszary i komputery > Dane archiwalne > <archiwum> > zakładka Synchronizacja, to dane są tylko synchronizowane na poziomie baz danych SQL, a wyłączone jest zarówno pobieranie danych bieżących z Asmena, jak i uzupełnianie przez Aslinka.

 

 

 

Rys. Synchronizacja na poziomie baz danych SQL.

 

 

Synchronizacja ma tę przewagę nad zwykłym uzupełnianiem, że uwzględnia wszystkie zmiany w archiwum, także dane historyczne dopisywane lub zmieniane z opóźnieniem.

 

 

Deklaracja

 

Deklaracja wygląda dokładnie tak samo, jak archiwum do zapisu:

 

Architekt > Obszary i komputery > Dane archiwalne > <dodana pozycja archiwum> > zakładka Standardowe > opcja Archiwum replikowane

 

 

 

Jakie problemy pozwala wyeliminować archiwum replikowane?

 

Przy zastosowaniu pozostałych dostępnych typów archiwum moduł Aspad pozyskuje dane do archiwizacji na 3 sposoby:

 

1. Dane bieżące lub historyczne pobiera z modułu Asmen.

 

2. Podczas startu uzupełnia brakujące dane z innego serwera za czas wyłączenia Asixa.

 

3. Synchronizuje dane archiwum SQL z innym serwerem, jeżeli podano dla tego archiwum deklarację synchronizacji.

 

 

Na serwerach, gdzie ASMEN nie ma swoich kanałów fizycznych takie rozwiązanie ma kilka wad:

 

1. Archiwizowane dane muszą być dostarczane kanałami sieciowymi Asmena nie rzadziej niż okres archiwizacji. W konsekwencji:

 

a. jeżeli Asmen nie zdąży przekazać danych z takim cyklem, to ma tylko jeden dodatkowy cykl na nadrobienie zaległości; później pojawia się dziura w archiwum;

 

b. jeżeli okres odświeżania Asmena jest krótszy niż Aspada, to dane są dostarczane częściej niż jest to potrzebne.

 

2. Przy chwilowym braku komunikacji z źródłem danych powstaje dziura w archiwum, która nie jest uzupełniana. Wyjątkiem jest archiwum SQL z deklaracją synchronizacji.

 

3. Jeżeli zadeklarowano Archiwum do zapisu oraz zadeklarowano synchronizację, to dane do archiwum SQL dostarczane są podwójnie: pierwszy raz jako dane bieżące Asmena, a drugi jako dane z synchronizacji z drugim archiwum.

 

Archiwum replikowane powstało w celu wyeliminowania powyższych niedogodności.

 

 

 

Gdzie stosować archiwum replikowane?

 

Wybór pomiędzy archiwum replikowanym a zwykłym archiwum do zapisu zależy głównie od 2 czynników: czy na danej stacji Asmen dostarcza dane z kanałów fizycznych, czy też sieciowych oraz jak szybko dane historyczne mają się pojawiać na wykresach w przelicznikach, skryptach, itd.

 

Dane z kanałów fizycznych, czy sieciowych

 

Jeżeli zastosujemy archiwum replikowane, to dane do archiwizacji będą zawsze pobierane z archiwum innego komputera. Będzie tak nawet wtedy, gdy chwilowo ten inny komputer jest wyłączony, co oznacza, że w naszym archiwum znajdą się tylko te dane, które były wcześniej zarchiwizowane w innym i będzie brakowało danych za czas jego wyłączenia. Utracilibyśmy w ten sposób zdolność korzystania z redundantnych kanałów Asmena na naszym komputerze.

 

Wnioski:

1. Archiwum replikowane zwykle nadaje się do zastosowania na serwerach pośredniczących (z uwagą o opóźnieniu dostarczanych danych).

2. Archiwum replikowanego nie należy stosować na redundantnych stacjach operatorskich.

3. Archiwum replikowane może być zastosowane na stacji operatorskiej, na której wszystkie dane tego archiwum pochodzą z kanałów sieciowych i mogą być pobrane z bliźniaczego archiwum komputera, który posiada kanały fizyczne dla tych danych.

 

Opóźnienie danych

 

Dane archiwizowane z dostarczanych danych bieżących (w pozostałych typach archiwum) są dostępne praktycznie natychmiast, czyli mogą być na bieżąco obserwowane na wykresach, czy też użyte w skryptach lub przelicznikach.

 

W przypadku danych replikowanych serwer wysyła dane nie częściej niż raz na dziesięć sekund, a w przypadku archiwum SQL nie częściej niż podano w deklaracji synchronizacji (o ile taką deklarację zastosowano). Dopiero po ich dostarczeniu dane będą dostępne na stacji z archiwum replikowanym.

Dane będą przy tym opatrzone prawidłowymi znacznikami czasu, a jedynie opóźni się ich pojawienie w archiwum.

 

Wnioski:

1. Archiwum replikowane można stosować tam, gdzie nie jest istotne opóźnienie pojawienia się danych historycznych w stosunku do danych bieżących.

2. Nie wolno stosować archiwum replikowanego na stacjach, na których wykres musi nadążać z dokładnością do sekund za danymi bieżącymi.

3. Nie wolno stosować archiwum replikowanego na stacjach, na których skrypty lub przeliczniki nie są odporne na opóźnione pojawienie się danych historycznych.