Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


26.10.2020

Nowa wersja nVision

Można już pobierać nową wersję nVision
26.10.2020

Monitorowanie infrastruktury

Vertiv Environet Alert
23.10.2020

Telefonia w chmurze

NFON Cloudya
23.10.2020

Nowości w EDR

Bitdefender GravityZone
23.10.2020

Wykrywanie anomalii

Flowmon ADS11
23.10.2020

Mobilny monitor

AOC 16T2
22.10.2020

HP Pavilion

HP zaprezentowało nowe laptopy z linii Pavilion.
22.10.2020

Inteligentny monitoring

WD Purple SC QD101
22.10.2020

Przełącznik 2,5GbE

QNAP QSW-1105-5T

Zapewnianie ciągłej dostępności baz danych

Data publikacji: 29-08-2017 Autor: Marcin Szeliga
RYS. 1. PRZYKŁAD...

Zapewnienie ciągłości działania systemów IT należy do podstawowych zadań gwarantujących powodzenie operacji biznesowych w firmie. W poprzednim artykule zajmowaliśmy się strategią pozwalającą na szybkie odzyskanie baz danych. Teraz zajmiemy się mechanizmami zwiększającymi dostępność systemów bazodanowych i ich odporność na awarie.

W pierwszej części artykułu przedstawione zostały strategie odtwarzania kopii zapasowych pozwalające w prosty sposób zmniejszyć wskaźnik RPO (Recovery Point Objective), czyli ograniczyć ilość utraconych po awarii danych do kilku minut. W tej części przyjrzymy się sposobom minimalizowania drugiego z kluczowych wskaźników umowy SLA (Service Level Agreement), czyli RTO (Recovery Time Objective). Skrócenie mierzonego w ten sposób czasu niedostępności baz danych po wystąpieniu awarii wymaga zastosowania takich technologii jak klastry niezawodności lub zduplikowania chronionych baz danych, na przykład za pomocą technologii AlwaysOn Availability Groups.

> Definicja ciągłej dostępności

Dostępność oznacza możliwość korzystania przez użytkowników z aplikacji. „Możliwość korzystania” określa się w kategoriach utraty danych, spadku wydajności oraz czasu trwania przestojów w pracy systemu. Głównym zadaniem systemów zapewniania ciągłej dostępności jest właśnie ograniczenie do minimum czasu planowanych i nieplanowanych przestojów.

Tak rozumianą dostępność wyraża się wzorem:



Wynik najczęściej przedstawia się w postaci liczby dziewiątek:

 

  • dwie dziewiątki (99%) oznaczają niedostępność aplikacji przez 3 dni i 15 godzin w skali roku;
  • trzy dziewiątki (99,9%) oznaczają niedostępność aplikacji przez 8 godzin i 45 minut w skali roku;
  • cztery dziewiątki (99,99%) oznaczają niedostępność aplikacji przez 52 minuty i 34 sekundy w skali roku;
  • pięć dziewiątek (99,999%) oznacza niedostępność aplikacji przez 5 minut i 15 sekund w skali roku.

 

Ponieważ do czasu niedostępności zalicza się zarówno planowane (związane z pracami administracyjnymi), jak i nieplanowane (będące wynikiem awarii) przestoje, zapewnienie dostępności na poziomie trzech dziewiątek wymaga ograniczenia RTO do mniej niż godziny. A to z kolei wymaga wdrożenia strategii zapewniania ciągłej dostępności baz danych.

> Ciągła dostępność baz danych

Wprowadzone w wersji 2012 serwera SQL Server technologie AlwaysOn pozwalają w prosty i względnie tani sposób zminimalizować czas niedostępności baz danych i jako takie są podstawowym elementem strategii zapewniania ich ciągłej dostępności.

Pod nazwą AlwaysOn kryją się dwie różne technologie:

AlwaysOn Failover Cluster Instances (FCI) – bazuje na usłudze klastrów niezawodności infrastruktury systemu Windows. Taki klaster składa się z dwóch lub więcej węzłów, przy czym jednocześnie aktywnym (czyli takim, na którym działają chronione bazy serwera SQL Server) jest tylko jeden węzeł, na pozostałych węzłach serwer SQL Server jest zatrzymany. Na dodatkowych węzłach mogą być uruchomione inne usługi, w tym instancje serwera SQL Server, w ramach których działają inne bazy danych.

Aktywny węzeł jest aktualnym właścicielem takich zasobów, jak nazwa wirtualnego serwera SQL Server, jego adres IP, dysk Quorum oraz dyski danych. Dodatkowe węzły regularnie łączą się z węzłem aktywnym, sprawdzając jego dostępność – na poziomie systemu operacyjnego odbywa się to poprzez wysyłanie sygnałów „tętna” (Heartbeat), na poziomie serwera SQL Server poprzez wykonywanie procedury diagnostycznej sp_server_diagnostics. Jeżeli aktywny węzeł zostanie uznany za niedostępny, pozostałe węzły klastra (oraz opcjonalnie takie jego zasoby, jak udział sieciowy) głosują większościowo nad przełączeniem serwera SQL Server na węzeł zapasowy. Samą niedostępność serwera SQL Server można zdefiniować, wybierając jeden z pięciu dostępnych poziomów, gdzie poziom 1 oznacza, że serwer bazodanowy nie odpowiada, a poziom 5, że serwer nie odpowiada, czas odpowiedzi jest za długi albo że zgłosił on jeden z błędów, mających bezpośredni wpływ na wykonywanie zapytań.

Jeżeli kworum uzna, że węzeł aktywny jest niedostępny, zdefiniowany węzeł zapasowy zostaje bieżącym właścicielem wspólnych zasobów i uruchamiana na nim jest usługa serwera baz danych.

[...]

Autor od 20 lat zawodowo pracuje z danymi i posiada tytuł Microsoft Most Valuable Professional.

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"