Kliknij tutaj, aby zainstalować program Silverlight

Polska

Zmień

|

Wszystkie witryny firmy Microsoft

Strona główna TechNet

|

Jak zacząć?

|

Subskrypcja TechNet Plus

|

Newsletter TechNet

|

RSS TechNet

|

Blogi TechNet

|

Kontakt

Produkty i technologie

Baza wiedzy TechNet

Szkolenia i certyfikacje

Wirtualne Laboratoria

TechNet Quiz

Centrum Bezpieczeństwa

Do pobrania

Wdrażanie
oprogramowania

Aktualizacje

Konferencje i seminaria

Społeczność

Poznaj TechNet

TechNet FAQ

Pomoc techniczna

TechNet na świecie
(j.ang.)

Biblioteka TechNet (j.ang.)

Baza wiedzy TechNet

>

Artykuły ekspertów

SQL Server na klastrze Windows Server, cz

ęść

1

Opublikowano: 17 sierpnia 2009
Autor:

Marcin Goł

i

Grzegorz Tworek

Zawartość strony

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:

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:

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. Klaster jest 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

Przeczytaj także:

•

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

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...

•

Database Engine – silnika bazy danych,

•

Analysis Services – serwera analitycznego,

•

Reporting Services – serwera raportowego,

•

Integration Services – narzędzi ETL.

•

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).

Szukaj w witrynach Microsoft.com

Prześlij kwerend

Page 1 of 7

SQL Server na klastrze Windows Server, część 1 - Artykuły ekspertów - Baza Wiedzy...

2009-08-31

http://www.microsoft.com/poland/technet/article/art0184.mspx

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:

1. Zarządzać już istniejącym klastrem,

2. Zbadać, czy ze wskazanych komputerów można utworzyć klaster,

3. 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

Page 2 of 7

SQL Server na klastrze Windows Server, część 1 - Artykuły ekspertów - Baza Wiedzy...

2009-08-31

http://www.microsoft.com/poland/technet/article/art0184.mspx

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 ?

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:

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:

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

•

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).

Rysunek 2: Instalacja stand-alone.

Rysunek 3: SQL Server na klastrze.

Page 3 of 7

SQL Server na klastrze Windows Server, część 1 - Artykuły ekspertów - Baza Wiedzy...

2009-08-31

http://www.microsoft.com/poland/technet/article/art0184.mspx

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:

Do początku strony

Ale czy on naprawdę pomaga?

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

•

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ść.

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ą:

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:

•

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

Page 4 of 7

SQL Server na klastrze Windows Server, część 1 - Artykuły ekspertów - Baza Wiedzy...

2009-08-31

http://www.microsoft.com/poland/technet/article/art0184.mspx

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 ?

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]

Rysunek 5. Liczbą wątków roboczych w 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ć):

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

•

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;

•

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

•

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)

Page 5 of 7

SQL Server na klastrze Windows Server, część 1 - Artykuły ekspertów - Baza Wiedzy...

2009-08-31

http://www.microsoft.com/poland/technet/article/art0184.mspx

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:

Wady:

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:

Zasada działania MS DTC:

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

•

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;

•

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

•

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.

Rysunek 6: MS DTC w akcji.

•

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

Page 6 of 7

SQL Server na klastrze Windows Server, część 1 - Artykuły ekspertów - Baza Wiedzy...

2009-08-31

http://www.microsoft.com/poland/technet/article/art0184.mspx

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

Wersja do wydruku

Wyślij informacje

Dodaj do ulubionych

Jak oceniłbyś użyteczność tych informacji?

1

2

3

4

5

Zły

n

m

l

k

j

n

m

l

k

j

n

m

l

k

j

n

m

l

k

j

n

m

l

k

j

Znakomity

Powiedz, dlaczego oceniłeś te informacje właśnie tak .(opcjonalne)

5

5

6

6

Prześlij

Zmień Swój Profil

©2009 Microsoft Corporation. Wszelkie prawa zastrzeżone.

Kontakt z nami

|

Zasady użytkowania witryny microsoft.com

|

Znaki towarowe

|

Ochrona prywatności

Page 7 of 7

SQL Server na klastrze Windows Server, część 1 - Artykuły ekspertów - Baza Wiedzy...

2009-08-31

http://www.microsoft.com/poland/technet/article/art0184.mspx