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


05.09.2022

Łatwiejsza migracja do chmur

Commvault i Oracle rozszerzyły partnerską współpracę i wspólnie oferują rozwiązanie...
01.09.2022

Badanie sieci

QNAP ogłosił wprowadzenie oprogramowania ADRA Network Detection and Response (NDR) dla...
01.09.2022

5G w Polsce

Z badania Kearney 5G Readiness Index 2022 wynika, że Polska jest jednym z najgorzej...
01.09.2022

Zarządzanie działaniami

Fortinet zaprezentował chmurową usługę, która koreluje informacje dotyczące...
01.09.2022

Selektywna rejestracja

Naukowcy z UCLA przedstawili projekt inteligentnej kamery, która pozwala wybrać, jaki...
01.09.2022

Więcej mocy, komputer...

Profesjonalny komputer Dell Precision 7865 Tower z AMD Ryzen Threadripper PRO 5000...
01.09.2022

Rekord prędkości

Firma Aorus zapowiada superszybki dysk, następcę modelu Gen4 7000s SSD, który ma oferować...
01.09.2022

Beprzewodowe drukowanie

Firma Brother wprowadziła do swojego portfolio nowe urządzenie wielofunkcyjne z systemem...
01.09.2022

Obraz dobrze zaprogramowany

Monitor interaktywny Lyra to połączenie Androida 11, szyby antybakteryjnej, wbudowanego...

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\"