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

ęść

Opublikowano: 17 sierpnia 2009
Autor:

Marcin Goł

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

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

Zły

Znakomity

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

Prześlij

Zmień Swój Profil

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