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


20.12.2018

Większa moc

QNAP Mustang-200
20.12.2018

Nowa era Wi-Fi

NETGEAR Nighthawk AX8
20.12.2018

Szybkie skanowanie

Brother ADS-1700W i ADS-1200
06.12.2018

Niższe moce

UPS Eaton 9SX
03.12.2018

Monitory dla MŚP

AOC E1
29.11.2018

Wykrycie szkodliwego...

Sophos Intercept X Advanced
27.11.2018

Automatyzacja zabezpieczeń

Red Hat Ansible Automation
23.11.2018

Nieograniczona skalowalność

SUSE Enterprise Storage 5.5
20.11.2018

Dwa procesory Threadripper

AMD Ryzen Threadripper 2970WX i 2920X

Wysoka dostępność serwerów SQL. Klastry niezawodności infrastruktury

Data publikacji: 29-10-2018 Autor: Marcin Szeliga
RYS. 1. OGÓLNY SCHEMAT BUDOWY...

Celem artykułu jest przedstawienie technologii wysokiej dostępności serwera SQL Server, które pozwalają spełnić wymagania użytkowników dotyczące zapewnienia ciągłości pracy systemów bazodanowych.

 

Wymagania użytkowników w zakresie dostępności baz danych są coraz bardziej rygorystyczne. Po pierwsze, oczekują oni, że w przypadku ewentualnej awarii systemu nie utracą żadnych danych bądź jedynie ich ściśle określoną ilość – ten wymóg pozwala spełnić wdrożenie odpowiedniej strategii tworzenia i odtwarzania kopii zapasowych, czyli rozwiązań klasy DR (Disaster Recovery). Jednak usunięcie awarii i odtworzenie bazy danych może zająć dużo czasu. Dlatego spełnienie drugiego oczekiwania użytkowników, a mianowicie zapewnienia ciągłej dostępności systemów bazodanowych, nawet w wypadku uszkodzenia ich poszczególnych elementów czy nagłego wzrostu obciążenia, wymaga zastosowania odpowiedniej technologii ciągłej dostępności (High Availability – HA).

> Ciągła dostępność

Zagwarantowanie ciągłej pracy systemu bazodanowego jest jednym z najważniejszych zadań jego administratora. Polega ono na zapobieganiu niedostępności usługi w wyniku awarii sprzętu lub oprogramowania, błędów użytkowników, katastrof naturalnych itp. poprzez ochronę zasobów (takich jak dysk czy baza danych), za pomocą odpowiednich technologii HA.

Niedostępność usługi może być wcześniej zaplanowana, na przykład spowodowana koniecznością przeprowadzenia prac modernizacyjnych, instalacji poprawek lub wymianą sprzętu, albo niezaplanowana, będąca skutkiem wystąpienia błędu uniemożliwiającego pracę użytkowników w sposób przez nich odczuwalny. Oba rodzaje niedostępności powinny być uwzględnione w uzgodnionej z użytkownikami systemu umowie SLA.

W najprostszym przypadku umowa SLA powinna określać czas dopuszczalnej niedostępności usługi obliczony według wzoru Dostępność = MTBF / (MTBF + MTTR), gdzie MTBF oznacza średni czas pomiędzy awariami, a MTTR to średni czas potrzebny do usunięcia awarii. Tak obliczoną dostępność z reguły przedstawia się za pomocą liczby dziewiątek (tabela).

Jak widać, nawet zapewnienie dostępności na poziomie trzech dziewiątek (99,9%) oznacza ograniczenie czasu planowanych i nieplanowanych niedostępności poniżej 9 godzin w skali roku. Tylko niepoprawny optymista może uważać, że jest to wykonalne bez zastosowania dodatkowych rozwiązań HA.

> Rozwiązania zapewniania ciągłej dostępności serwera SQL Server

Od wersji 2012 SQL Server oferuje dwie technologie ciągłej dostępności, o podobnej nazwie, ale różniące się zasadą działania:

 

  • AlwaysOn Failover Clustering Instances (FCI), czyli klastry niezawodności infrastruktury,
  • AlwaysOn Availability Groups (AG), czyli grupy wysoko dostępnych baz danych.


Zanim przedstawimy będącą tematem tego artykułu technologię FCI, powinniśmy zauważyć, że ciągła dostępność baz danych zależy też od właściwej konfiguracji serwera i odpowiedniego wykorzystania jego funkcjonalności.

I tak zmiana niektórych opcji konfiguracyjnych serwera SQL Server, np. włączenie możliwości wykonywania zewnętrznych skryptów, wymaga restartu usługi. Dlatego w pierwszej kolejności należy właściwie skonfigurować serwer, którego ciągłą dostępność mamy zapewnić.

Ponadto poszczególne edycje serwera SQL Server różnią się funkcjonalnością – edycja Enterprise nie tylko zawiera funkcje związane z wydajnością i skalowalnością, ale również pozwalające poprawić ciągłą dostępność. Należą do nich:

 

  • przebudowa indeksów online – przebudowa dużych indeksów może trwać od kilkudziesięciu minut do kilku godzin. Jeżeli na ten czas niezbędna do działania systemu tabela zostanie zablokowana, z perspektywy użytkownika usługa będzie niedostępna;
  • migawki baz danych (snapshot) – możliwość błyskawicznego utworzenia kopii bazy danych potrafi znacząco skrócić czas niedostępności bazy analitycznej lub odzyskiwania utraconych w wyniku awarii danych (migawki baz danych dostępne są wyłącznie do odczytu);
  • możliwość częściowego udostępniania użytkownikom odtwarzanej z kopii zapasowej bazy (online recovery) – jest prostym sposobem na skrócenie czasu niedostępności bazy po awarii;
  • dodawanie procesorów online oraz rozbudowa pamięci online – okazują się niezastąpione, gdy trzeba rozbudować serwer, a nie możemy pozwolić sobie na przerwę w działaniu świadczonych przez niego usług.


[...]

Pracownik naukowy Wyższej Szkoły Bankowej w Poznaniu Wydział Zamiejscowy w Chorzowie, jest autorem książek poświęconych analizie danych i posiada tytuł Microsoft Most Valuable Professional w kategorii Artificial Intelligence.

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 © 2013 Presscom / Miesięcznik "IT Professional"