SQL Server na klastrze Windows Server, część 1

Autor: Marcin Goł i Grzegorz Tworek

Opublikowano: 17 sierpnia 2009

Zawartość strony

	Wstęp
	Podstawy budowy SQL Server
	Instalacja klastra
	A po co ten klaster?
	Ale czy on naprawdę pomaga?
	Koszty…
	Zainstalowałem klaster, ale co to jest MSDTC ?
	W następnej części...

Wstęp

Klaster jest efektywnym i ciekawym mechanizmem zapewniania wysokiej dostępności nawet dla bardzo wymagających i skomplikowanych usług. W dużej mierze wynika to ze specyficznej architektury rozwiązania, która powoduje że jest ono przezroczyste dla aplikacji klienckich. Innymi ważnymi argumentami "za" jest automatyczne przełączenie po awarii oraz możliwość tworzenia dużych środowisk gdzie klastrowane jest wiele usług na wielu maszynach. Jednym z najczęstszych powodów korzystania z clustering services jest zapewnienie wysokiej dostępności serwerom baz danych – głównie SQL Server.

 Do początku strony

Podstawy budowy SQL Server

Przed opisem architektury klastra warto przypomnieć kilka informacji o budowie SQL Server.

Platforma przetwarzania danych Microsoft SQL Server składa się z 4 głównych serwerów:

• Database Engine – silnika bazy danych,
• Analysis Services – serwera analitycznego,
• Reporting Services – serwera raportowego,
• Integration Services – narzędzi ETL.

Instalacja każdego z powyższych powoduje powstanie bytu logicznego zwanego instancją, składającego się z wielu różnych elementów, np. w skład instancji silnika bazy danych wchodzą między innymi komponenty:

• binaria,
• systemowe bazy danych (master, tempdb, msdb, model, mssqlsystemresource),
• bazy danych użytkownika,
• system uprawnień,
• SQL Server Agent,
• zasoby umożliwiające komunikację/identyfikację (np. nazwa instancji).

Dzięki takiemu systemowi instalacji SQL Server, możliwe jest przeprowadzenie wielu odrębnych instalacji na pojedynczym systemie operacyjnym, a następnie równoległa praca wielu instancji – przy czym każda z nich może się charakteryzować np. przydzielonymi zasobami sprzętowymi, różną wersją pakietu serwisowego. Takie podejście umożliwia dużą elastyczność, ale niesie za sobą też pewne niedogodności w postaci walki o zasoby sprzętowe – pamięć, procesory, dyski czy też sieć. Warto dodać, że w SQL Server 2008 wprowadzono Resource Governor (RG) mający za zadanie optymalizować wykorzystanie zasobów sprzętowych przydzielonych dla instancji. Głównymi zadaniami stawianymi przed RG jest zapewnienie żeby jeden lub kilka wątków roboczych nie wysyciły zasobów sprzętowych instancji (RG pomaga walczyć ze zjawiskami typu: Pani z księgowości uruchomiła raport i cała firma stoi…); mechanizm RG jest dostępny w edycji Enterprise SQL Server 2008 i późniejszych.

Podsumowując: instancja to logiczne opakowanie na komponenty SQL Server i to na jej poziomie zarządza się zasobami sprzętowymi.

 Do początku strony

Instalacja klastra

Dla jasności, warto przybliżyć kilka ogólnych idei i terminów. Najprostszym terminem jest węzeł. Oznacza on po prostu komputer wchodzący w skład klastra. Klasterjest grupą serwerów, które współdziałają ze sobą w celu utrzymania działania usługi. Oznacza to, że jeżeli usługa zatrzyma się, to klaster spróbuje ją ponownie uruchomić. Może na tym samym komputerze a może na innym. Określenie tego nie jest takie zupełnie proste. Wirtualna nazwa to jedna z usług klastra. Oznacza nazwę sieciową, inną niż nazwa jakiegokolwiek komputera w sieci. Nazwa ta wykorzystywana jest przez klientów w celu podłączenia się do usługi. Skoro nie wiadomo, na którym konkretnie komputerze działa usługa, to musi istnieć jakaś metoda połączenia się... Po to właśnie jest nazwa wirtualna. Klaster wie gdzie jest dana usługa, więc klient korzystający z nazwy wirtualnej, potrzebną usługę łatwo znajdzie. Dysk współdzielony, to zasób dyskowy (często na macierzy), do którego wszystkie węzły klastra mogą się podłączyć. W danej chwili podłączony jest tylko jeden węzeł na raz, ale klaster może odłączyć ten węzeł i podłączyć inny. Quorum(nazwa jest nieścisła, ale taka się przyjęła) jest specjalnym dyskiem, którego klaster używa do zarządzania samym klastrem, w szczególności w sytuacjach awaryjnych. Ostanie opisane tu pojęcie " przeniesienie grupy usług " oznacza, że usługi wchodzące w skład danej grupy zatrzymywane są na jednym serwerze, drugi serwer staje się ich właścicielem, po czym usługi są uruchamiane. Ponieważ usługi klastra mogą być wewnątrz grupy powiązane wieloma zależnościami, proces ten może trwać od kilku sekund do kilku minut, w czasie których usługi nie są w pełni dostępne.

Proces instalacji (tworzenia klastra) wykracza poza ramy niniejszego artykułu, jednak warto go w zarysie przybliżyć. Przede wszystkim, jak wspomniano wcześniej – potrzebny jest sprzęt. Poza tym, należy zainstalować wersję Enterprise systemu operacyjnego Windows Server. Jeżeli na serwerze zainstalowana zostanie rola Failover Clustering, to wśród narzędzi administracyjnych pojawi się konsola zarządzająca klastrami. Przy pomocy tej konsoli można wykonać jedną z trzech operacji:

• Zarządzać już istniejącym klastrem,
• Zbadać, czy ze wskazanych komputerów można utworzyć klaster,
• Utworzyć klaster na wskazanych komputerach.

Druga opcja jest szczególnie przydatna, ponieważ w Windows Server 2008, mechanizm badania został znacząco poprawiony i podaje administratorowi naprawdę użyteczne informacje pozwalające na zbudowanie środowiska zgodnego z regułami sztuki. Mimo, że klaster pozwoli się zbudować na komputerach nie mających dysków współdzielonych, podejście takie nie wydaje się rozsądne dla klastra, na którym pracować będzie SQL Server. Dyski warto podłączyć przed badaniem, ponieważ dzięki temu zostaną nim objęte, co być może oszczędzi wielu kłopotów.

W systemie Windows Server 2008, klastry budować można również na wersji CORE. Z punktu widzenia niniejszego artykułu jest to jednak nieistotne, ponieważ na klastrze takim nie będzie możliwe zainstalowanie serwera SQL. Należy również pamiętać, że bez domeny Active Directory, klaster nie może istnieć i wszystkie węzły muszą być dodane do domeny.

Mimo, że nie jest to formalny wymóg, warto aby serwery użyte do budowy klastra były do siebie jak najbardziej podobne. Mogą mieć inne dyski czy ilość pamięci, ale architektura procesorów, role systemu, zainstalowane poprawki czy aplikacje powinny być wszędzie identyczne. W szczególności, serwery (i systemy) x86 powinny być klastrowane z innymi x86 a x64 – tylko z x64. Podobnie sytuacja wygląda dla platformy IA-64.

Mając już komputery, które przechodzą badanie zgodności z klastrem, należy wybrać opcję tworzenia nowego klastra i wszystko powinno przebiec bez kłopotu. W trakcie tworzenia, kreator proponuje ponowne badanie czy węzły się do klastra nadają. Należy na badanie takie zezwolić. Wiadomo, że przebiegnie poprawnie, a kosztem niewielkiego wydłużenia czasu budowania klastra, administrator zyskuje wsparcie firmy Microsoft. Klastry, które nie zostały zweryfikowane podczas budowania, wsparcia takiego nie mają.

Przeznaczone dla SQL Server dyski podłączone są do jednego z węzłów. Można przed instalacją serwera baz danych "poprawić" im przypisane litery (przy użyciu konsoli zarządzającej klastrem) oraz upewnić, się że quorum znajduje się na właściwym dysku. Quorum wymaga wprawdzie bardzo niewielkiej przestrzeni (1GB to aż nadto) ale dysk, na którym się znajduje w praktyce nie daje się wykorzystać w żadnym innym celu. Dlatego warto dla quorum przeznaczyć dedykowany niewielki dysk współdzielony, zamiast pozwolić mu "zabrać" przestrzeń przeznaczoną na bazy danych.

Niezagospodarowane dyski przydzielone są do jednego z węzłów. Jeżeli z jakiegoś powodu podłączony do nich powinien być inny węzeł – dysk należy przenieść. Niestety klaster nie oferuje możliwości przenoszenia samych dysków. Przenosić można tylko całe grupy. Dlatego, aby przenieść nieprzydzielony dysk, należy utworzyć grupę, dodać do niej dysk i przenieść grupę. Grupę taką można potem skasować a dysk pozostanie podłączony do tego węzła, do którego powinien.

 Do początku strony

A po co ten klaster?

Wraz z postępującym rozwojem firm, bardzo często zdarza się, że koszty przestoju np.: aplikacji klasy ERP ponieważ "padł serwer baz danych" mogą być liczone w setkach tysięcy czy nawet milionach euro – nawet jeśli czas przestoju wynosić będzie kilka godzin (czas instalacji + odtworzenia konfiguracji i baz danych).

Aby łatwiej było ustalać warunki umów typu Service Level Agreement (SLA), wprowadzono miarę dostępności usługi, przy czym dostępność jest opisywana nie tylko przez działanie aplikacji na serwerze, ale np.: uwzględniany jest też średni czas odpowiedzi na zapytanie. Biorąc pod uwagę wszystkie warunki dostępności przyjęło się ją mierzyć w procentach. Poniższa tabela zawiera wartości dla najczęściej spotykanych opcji:

Dostępność %	Niedostępność/rok	Niedostępność/miesiąc	Niedostępność/tydzień
90 %	36,5 doby	3 doby	16,8 godziny
95 %	18,25 doby	1,5 doby	8,4 godziny
98 %	7,3 doby	14,4 godziny	3,36 godziny
99 %	3,65 doby	7,2 godziny	1,68 godziny
99,5 %	1,83 doby	3,6 godziny	50,4 minuty
99,8 %	17,52 godziny	86,23 minuty	20,16 minuty
99,9 %	8,76 godziny	43,2 minuty	10,1 minuty
99,95 %	4,38 godziny	21,56 minuty	5,04 minuty
99,99 %	52,6 minuty	4,32 minuty	1,01 minuty
99,999 %	5,26 minuty	25,9 sekundy	6,05 sekundy
99,9999 %	31,5 sekundy	2,59 sekundy	0,605 sekundy

Rysunek 1 Dostępność a czasy przestoju.

Bardzo często spotyka się określanie dostępności 99,9% jako „trzech dziewiątek”, 99,99% jako "czterech" itd.. Należy zwrócić uwagę że im krótszy możliwy czas przestoju tym mechanizmy odpowiedzialne za wykrywanie i odpowiedź na awarię powinny być zautomatyzowane, a komponenty sprzętowe/programowe redundantne. Oczywiste jest również, że każda kolejna "dziewiątka" bardzo mocno podnosi koszt i złożoność rozwiązania - wiąże się to ze koniecznością wprowadzana kolejnych mechanizmów zabezpieczających. Samo osiągnięcie dostępności na poziomie 99,999% - nie leży tylko w gestii zarządzania redundancją sprzętu ale w dużej mierze odpowiedniej architektury aplikacji.

Co można zwielokrotniać w typowym środowisku ?

• zasilanie (linie zasilające, UPSy, zasilacze w serwerach),
• klimatyzacje/chłodzenie w serwerowni,
• karty zapewniające dostęp do zasobów dyskowych,
• dyski twarde,
• kontrolery I/O,
• karty sieciowe/infrastrukturę sieciową,
• łącza internetowe,
• pamięć operacyjną,
• komponenty programowe (np. serwery aplikacyjne).

Jak widać, powielać można praktycznie wszystko i wraz z rosnącymi wymogami, wprowadza się kolejne redundantne komponenty do systemu.

Jednym ze sposobów skracania czasu przestoju jest utrzymywanie bliźniaczego sprzętu/środowiska. Jednakże wymaga to dużego nakładu administracyjnego a sam proces odtworzenia musi być często testowany. Częściowym obejściem tego problemu jest wdrożenie serwera uruchomionego w oparciu o Clustering Services.

MSSQL zainstalowany stand-alone, przyjmuje postać zestawu usług systemowych, które pracując wykorzystują warstwy niższe (sprzętu i systemu operacyjnego), co przedstawiono na poniższym rysunku:

Rysunek 2: Instalacja stand-alone.

W związku z powyższym dostępność SQL Server zależy nie tylko od zarządzania samym RDBMS ale również (być może głównie) od niezawodności systemu operacyjnego oraz sprzętu. Idea działania klastra polega na uniezależnieniu się aplikacji właśnie od warstw poniżej.

Po instalacji SQL Server na klastrze podział na warstwy wygląda w sposób następujący:

Rysunek 3: SQL Server na klastrze.

Ponieważ instancja SQL Server zainstalowana jest na współdzielonym zasobie dyskowym (np.: iSCSI, SCSI, SAN), a biblioteki wymagane do uruchomienia zostały zainstalowane na wybranych węzłach klastra, uzyskano niezależność silnika bazy danych od serwera, na którym został zainstalowany. Co znaczy że ta sama instancja SQL Server może pracować na jednym albo na drugim węźle klastra! Dodatkowo dzięki clustering services zyskuje się ciekawe mechanizmy administracyjne np.: wykrywanie awarii, automatyczne przełączanie czy przypisywanie poszczególnych usług do konkretnych węzłów (występują tutaj dwa mechanizmy – Preferred owners oraz AntiAffinityClassNames).

Należy pamiętać jednak, że samo wdrożenie klastra nie zapewnia wysokiej dostępności – ważne są jeszcze inne komponenty systemu, procedury utrzymania i aktualizacji oprogramowania.

Warto zwrócić uwagę, że z punktu widzenia aplikacji łączących się do bazy danych po wdrożeniu klastra, nie jest wymagana żadna specjalna/dodatkowa funkcjonalność (np.: wersja biblioteki podłączającej się do serwera) ani dodatkowa konfiguracja (np. wpisanie zapasowych serwerów do konfiguracji) – po prostu jako nazwę serwera bazy danych wskazuje się nazwę jaka została nadana klastrowi – a to on już się zajmuje się podłączeniem użytkowników do właściwego węzła!

Inne cechy charakterystyczne klastra:

• ochronie podlega cała klastrowana usługa – czyli w przypadku SQL Server będzie nią cała instancja (a nie tylko wydzielone bazy jak w innych rozwiązaniach wysokiej dostępności),
• klaster nie chroni przed fizycznym uszkodzeniem plików usługi – klaster chroni przed awarią serwerów/uszkodzeniem systemu operacyjnego,
• klaster nie jest odpowiedzią na niedostępność podczas instalacji uaktualnień dla usługi (do takich celów powinno się korzystać z rozwiązań typu NLB) – nie można wykonać instancji patchy SQL Server na jednym a potem na kolejnych węzłach gdyż instalacja jest jedna i jest przechowywana na współdzielonym zasobie dyskowym,
• przełączenie usługi z węzła X na węzeł Y oznacza jej zatrzymanie, odmontowanie zasobów na węźle X, podmontowanie zasobów oraz uruchomienie na Y – czyli chwilową niedostępność.

 Do początku strony

Ale czy on naprawdę pomaga?

Poniżej krótki opcji sytuacji A co jeśli …

1. Stan wyjściowy: zainstalowany SQL Server na klastrze 2 węzłowym (A i B), w konfiguracji Active-Passive

2. Sytuacja: węzeł A uległ awarii (w momencie awarii był węzłem aktywnym)

   Co się dzieje?

3. Clustering services stwierdzają że węzeł A stał się niedostępny (odbywa się to po przez wzajemne pingowanie się serwerów – tzw. heart beat)

4. Zasoby podmontowane na serwerze A przepinane są na węzeł B

5. Usługa SQL Server zaczyna być uruchamiana na węźle B

   a. Montowane są bazy systemowe

   b. Montowane są bazy danych użytkowników

Powyżej przedstawiono standardowy model wykorzystania klastra dla SQL Server – jeden węzeł przestaje być dostępny, instancja jest przenoszona na drugi węzeł. Co ważne zarówno wykrycie awarii jak i przełączenie wykonują się automatycznie. Dla administratora pozostaje kwestia jak najszybszego przywrócenia uszkodzonego węzła do życia – tak, aby stale zapewniać wysoką dostępność.

 Do początku strony

Koszty…

Niestety – wdrożenie klastra ma też swoje minusy – głównie ujawniają się one bilansie kosztowym projektu. Aby otrzymać poprawnie zbudowany i supportowany klaster SQL Server potrzebne są:

• minimum wersja Enterprise Windows Server
• minimum wersja Standard SQL Server
• serwery (najlepiej identyczne) spełniające HCL opublikowane dla klastrów (w Windows Server 2003) lub złożone z elementów posiadających logo i certyfikację dla Windows (w Windows Server 2008)
• wydajny zasób współdzielony, na którym będą pracowały bazy danych

Uważny czytelnik zwrócił na pewno uwagę, że w takiej konfiguracji część zasobów jest niewykorzystywana – tzn.: np. w przypadku 2 węzłowego klastra, jeden serwer będzie węzłem aktywnym (ang. active) – będzie obsługiwał żądania użytkowników, a drugi będzie pasywny (ang. passive). Zgodnie z tą nomenklaturą dwuwęzłowy klaster z jedną instancją SQL można określić jako: Active-Passive, co oznacza że jest jedna instancja SQL Server i raz pracuje na jednym a raz na drugim węźle. Żeby klaster miał sens maszyny pasywne muszą pozostać włączone i sprawne, więc do ogólnego rachunku projektu należy doliczyć jeszcze koszty utrzymania (administracja, energia elektryczna, chłodzenie, gwarancja itd)…

Jak udowodniono powyżej, klastry mogą znacząco zwiększyć dostępność serwerów baz danych, jednakże są kosztowne. Mając w pamięci możliwości konfiguracyjne - przypisanie hostowanej usługi do wybranych węzłów łatwo znaleźć rozwiązanie w postaci klastra Active-Active, czyli klastra, w którym wszystkie węzły są obciążone. Taką instalację przedstawiono na rysunku poniżej:

Rysunek 4: Klaster Active-Active serwera MS SQL Server.

Oczywiście drugą usługą nie musi być drugi SQL Server – może to być dowolna inna aplikacja, często stosowanym rozwiązaniem jest uruchamianie na jednym węźle klastra silnika relacyjnego, a na drugim serwera analitycznego. Ale co w sytuacji kiedy SQL Server z węzła A musi wystartować na obciążonym węźle B ?

• Stan wyjściowy: zainstalowany SQL Server na klastrze dwuwęzłowym (węzły A i B), w konfiguracji Active- Active, usługi: MSSQL#A, MSSQL#B; MSSQL#B pracuje wykorzystując 100% zasobów pamięci węzła B
• Sytuacja: węzeł A uległ awarii;

Ponieważ MSSQL#A musi zostać uruchomiony na węźle B, proces uruchamiając prosi o przydzielenie zasobów – alokuje początkowo pewną (małą) ilość RAM, pomimo że usługa prosi o więcej pamięci – nie otrzyma jej gdyż MSSQL#B alokuje większość dostępnej pamięci i nie przejawia chęci żeby ją oddać … W związku z tym, należy się liczyć z niemożnością korzystania z baz danych pracujących na instancji MSSQL#A…. . SQL Server będzie pracował ale będzie to robił odpowiednio do zasobów jakimi dysponuje.

Znane są w przyrodzie wypadki, że druga instancja chętnie będzie oddawała pamięć – w praktyce jednak jest to mało realne, a co więcej takie zachowanie przy złej konfiguracji może doprowadzić do wygłodzenia i znaczącego spadku wydajności instancji oddającej pamięć.

Niestety, problemy opisane powyżej są częstym problemem tego typu instalacji – SQL Server bardzo niechętnie oddaje przydzieloną pamięć RAM, i o ile zasoby takie jak procesory czy sieć będą rozdzielane przez systemowe schedulery, o tyle z pamięcią może być problem. Pomocną okazać się może procedura sp_configure – uruchomiona z opcja 'max server memory (MB)', która pozwala określić pamięć dla puli buforów. Niestety – pomimo obecności w nazwie "max server memory" nie oznacza to, że SQL Server nie wykroczy poza wskazaną ilość pamięci niż wskazane w tym parametrze – jest to związane z pozostałymi elementami SQL Server – tzw. MemToLeave.

Jaką wartość należy ustawić zatem jako max server memory ? Można o tym przeczytać tutaj i tutaj. W skrócie algorytm wygląda następująco:

[max server memory] = [RAM] – [system operacyjny] – [wątki robocze SQL Server] – [linked servery itp] – [inne aplikacje]

• system operacyjny powinien dostać ok 2GB
• wątki robocze – każdy wątek w zależności od typu maszyny zabiera różną ilość pamięci (x86 – 0.5MB, x86-64 – 2MB, IA64 – 4MB); liczba wątków jest określana na podstawie tabeli (chyba, że administrator zmodyfikował to przy pomocy sp_configure 'max worker threads'):

Liczba procesorów	32bit	64bit
1-4	256	512
5-8	288	576
9-16	352	704
17-32	480	960

Rysunek 5. Liczbą wątków roboczych w SQL Server.

• inne części MemToLeave – linked servery, xp, com – ok 1GB
• inne aplikacje – w zależności od potrzeb – zwykle nie potrzebują więcej niż 3GB (chyba, że jest to inna instancja SQL Server)

Przykład:

CPU: 8, RAM 32GB, x64 (x86-64, np.: Intel EMT64 czy AMD64), serwer WWW potrzebuje 0,5GB

max server server memory = 32 – 2 – ~1,1 – 1 – 0,5GB=> ~27,5GB

Tak więc, znając powyższy algorytm oraz zapotrzebowanie na pamięć zainstalowanych aplikacji, łatwo określić max server memory i przypisać je odpowiednio klastrowanym instancjom.

Warto przeanalizować te sytuacje ponownie (tym razem dla instancji z ograniczoną pamięcią jaką mogą zaalokować):

• Stan wyjściowy: zainstalowany SQL Server na klastrze dwuwęzłowym (węzły A i B), w konfiguracji Active- Active, usługi: MSSQL#A, MSSQL#B; ustawiono parametry dotyczące pamięci zgodnie z: min server memory 35% RAM, max server memory 45% RAM dla każdej z usług
• Sytuacja: węzeł A uległ awarii;

MSSQL#A jest uruchamiana na węźle B – ponieważ MSSQL#B ma ograniczoną pamięć RAM jaką może wykorzystać usługa #A uruchamiana jest bez problemu; jednakże czas odpowiedzi do użytkowników w dalszym ciągu jest niższy gdyż usługi muszą współdzielić procesory, sieć oraz zasoby systemu.

Generalna zasada dla klastrów dwuwęzłowych: suma pamięci przydzielonej instancjom powinna być niższa niż pamięć zainstalowana w węźle … (i jest to zalecenie firmy Microsoft). W przypadku klastrów o większej liczbie węzłów można próbować rozrzucać instancje na odpowiednie dobrane maszyny przez parametr dzięki wspomnianym wyżej mechanizmom.

Rozważając klaster Active-Active należy uwzględnić zakup większych maszyn niż w rzeczywistości są wymagane (w szczególności warto zakupić więcej pamięci). Należy zwrócić uwagę na fakt, że serwer mający dwukrotnie większą ilość pamięci i procesorów nie jest dwukrotnie szybszy… ale często jest dwukrotnie droższy (przy dużych maszynach różnice w kosztach mogą być trudne do zaakceptowania). Sposobem obejścia problemu kosztów przy dużych maszynach może być zakup 3 serwerów swoimi możliwościami lepiej dopasowanymi do instancji – oraz budowa na nich klastra Active-Active-Passive (maksymalna liczba węzłów dla SQL Server to 16, dla Windows 32).

Kontynuując temat rozwiązań dwuwęzłowych, należy rozważyć kwestię failbacku, czyli powrotu do poprzedniego przydziału usług do węzłów klastra, operacja ta charakteryzuje się:

Zalety:

• dzięki ponownemu rozdziałowi usług pomiędzy węzły klastra polepszy się wydajność usług.

Wady:

• zarówno failover jak i failback oznaczają przerwę w działaniu usługi – co z kolei oznacza chwilową przerwę w dostępie do bazy danych,
• jeśli zostanie przeprowadzony na niestabilną maszynę wówczas mogą wystąpić kolejne przestoje związane z kolejnymi przełączeniami.

W związku z tym należy uważać, że failback powinien być przeprowadzony jak najszybciej po dokładnej weryfikacji serwera z którego usługa wcześniej uciekła. W sytuacji idealnej operacja powinna być nadzorowana przez administratora i przeprowadzona w okresie okna serwisowego (lub chociaż najmniejszej aktywności użytkowników).

 Do początku strony

Zainstalowałem klaster, ale co to jest MSDTC ?

MSDTC – czyli Microsoft Distributed Transaction Coordinator – jest komponentem Windows Server i zapewnia koordynowanie transakcji pomiędzy zdalnymi systemami. Transakcji MSDTC są zgodne z zasadami ACID – są atomowe (wszystko albo nic), spójne – przenoszą dane z jednego do drugiego spójnego stanu, odizolowane – dopóki transakcja nie zostanie potwierdzona jej zmiany nie są widoczne dla innych użytkowników, trwałe – zmiany dokonywane w transakcji są trwałe.

W jaki sposób działa MSDTC? Koordynator swoją pracę opiera na menadżerach transakcji oraz menadżerach zasobów oraz dwufazowym potwierdzaniu, przedstawiono to na rysunku poniżej:

Rysunek 6: MS DTC w akcji.

Zasada działania MS DTC:

• Klient komunikuje się ze menadżerem transakcji i prosi o rozpoczęcie transakcji

• Klient dokonuje zmian

• Klient prosi o zakończenie transakcji

  a. Menadżer transakcji pyta menadżerów zasobów czy są gotowi potwierdzić transakcje

      i. Jeśli wszyscy menadżerowie zasobów potwierdzili, transakcja jest zatwierdzana

      ii. Jeśli choć jeden z menadżerów nie potwierdził transakcji, cała transakcja jest anulowana na wszystkich serwerach uczestniczących w transakcji

Dzięki takim możliwościom, można budować złożone systemy biznesowe, które w jednej transakcji dokonają zmian w wielu systemach (np. zmiana w bazie danych i dodanie wiadomości do kolejki MSMQ), a w razie wystąpienia problemów zmiany nie zostaną zachowane i dane pozostaną spójne.

Ale po co MS DTC w klastrze baz danych? Na wszelki wypadek. Tak to nie był żart, sam SQL Server nie potrzebuje MS DTC i świetnie radzi sobie bez niego, ale jako że instalacja MS DTC to chwila, a może okazać się potrzebne w przyszłości to najlepsze praktyki zalecają instalację MS DTC. Kilka ważnych uwag – w Windows Server 2008, MS DTC ewoluowało i umożliwia uruchomienie więcej niż 1 instancji MS DTC w klastrze.

 Do początku strony

W następnej części...

W drugiej części opisane zostaną kroki jakie należy podjąć aby poprawnie zainstalować SQL Server 2008 na klastrze.

• SQL Server na klastrze Windows Server, część 2

---

Marcin Goł Architekt baz danych, ISCG Aktualnie pracuje w ISCG, gdzie projektuje i optymalizuje bazy danych; w swojej pracy głównie wykorzystuje technologie Microsoft SQL Server. Wcześniej brał udział w wielu wdrożeniach systemów OSS dla sektora telekomunikacyjnego oraz pracował jako administrator środowiska opartego o technologię Microsoft. Lider Polish SQL Server User Group (PLSSUG); aktywny użytkownik portalu WSS.pl, prowadzi blog SQL Server. Specjalizuje się w analizie i rozwiązywaniu problemów wydajnościowych. W styczniu 2009 został nagrodzony tytułem Most Valuable Professional w kategorii SQL, ponadto posiada certyfikaty firmy Microsoft, min.: MCITP: Database Administrator.

---

Grzegorz Tworek (Konsultant ISCG, MVP) Inżynier systemowy, komputerowiec w drugim pokoleniu. Od wielu lat aktywnie promuje idee związane z bezpieczeństwem informatyki, zwłaszcza w powiązaniu z systemami Microsoft. Autor artykułów i książek na temat security, prelegent na rozmaitych konferencjach. Aktywnie uczestniczy w działaniach SEClub. Równie duży zapał do tworzenia jak i do psucia systemów sprawia, że w projektach najchętniej uczestniczy jako audytor. W lipcu 2007 został nagrodzony tytułem Most Valuable Professional w kategorii Enterprise Security. Prowadzi polski blog TechNet.

Do początku strony

---