Ostatnio opisywałem w ramach słownika pojęć czym jest wysoka dostępność. Dzisiaj chciałbym przedstawić przykładowe rozwiązanie jakim jest database mirroring.

Na wstępie zaznaczam, że rozwiązań wysokiej dostępności tzw. HA (z ang. High Availability) jest kilka różnią się oczywiście kosztami jakie trzeba ponieść oraz poziomem skomplikowania co przekłada się często na to jak szybko system będzie dostępny po stwierdzeniu awarii.

Zasada wykorzystania odbicia lustrzanego bazy jest przenoszenie w miarę na bieżąco danych do drugiej lokalizacji (drugiej instancji SQL Server). Celowo piszę instancji bo fizycznie można zestawić proces klonowania bazy pomiędzy dwiema instancjami na tym samym serwerze czy też precyzyjniej pisząc w ramach tego samego systemu Windows.

W przypadku Database Mirroringu dostępne są dwa modele pracy:

• bez wykorzystania serwera „świadka” (tzw. witness)

• z wykorzystaniem serwera „świadka” (tzw. witness)

Źródło: https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/media/dbm-3-way-session-intro-ov.gif?view=sql-server-2017

W praktyce nie ma to większego sensu i aby faktycznie wykorzystywać to jako mechanizm wysokiej dostępności powinno być to zestawione do przynajmniej drugiej maszyny wirtualnej.

Ważne jest to, że mechanizm ten jest transparentny dla aplikacji czyli można go wykorzystać na poziomie serwera baz danych bez ingerencji w aplikację i można go bez problemu zastosować do aplikacji WAPRO ERP.

W przypadku modelu bez świadka w przypadku wykrycia awarii to administrator przełącza serwer zapasowy aby pełnił rolę serwera głównego. W przypadku wykorzystania serwera świadka to właśnie ten serwer monitoruje dostępność serwera podstawowego i w przypadku wykrycia awarii informuje serwer zapasowy, że to on powinien przejąc kontrolę w działaniu.

Dodatkowo jeśli aplikacja jest odpowiednio zaprogramowana to można w niej wskazać tzw. failover partner i aplikacja sama spróbuje się połączyć do serwera zapasowego jeśli podstawowy serwer nie będzie odpowiadał po awarii.

Co potrzeba do tego mechanizmu?

• SQL Server w edycji standard  lub wyższej dla serwerów podstawowych i zapasowych
• Serwer świadka może być na instancji Express
• Przynajmniej 2 maszych wirtualnych aby faktycznie występowało zjawisko redundancji systemu a w praktyce najlepiej dwa serwery fizyczne jeśli chcemy zapewnić redundancję sprzętową

Zalety:

• Stosunkowa łatwa konfiguracja
• transparentność dla aplikacji
• licencjonowanie SQL Server dopuszcza konfigurację mirroringu na jednej licencji (na jeden serwer) pod warunkiem, że po wystąpieniu awarii w ciągu 30 dni pierwotny serwer wróci do działania i będzie pełnił nadal rolę serwera głównego
• możliwość automatycznego przełączania aplikacji (nie dotyczy tu WAPRO ERP)
• niski koszt wdrożenia

Wady:

• konfiguracja per baza danych, w przypadku bardzo dużej ilości baz danych np. w biurze rachunkowym lepszym rozwiązaniem może być klaster SQL