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

Autor: Marcin Goł i Grzegorz Tworek

Opublikowano: 24 sierpnia 2009

Zawartość strony

	Instalacja SQL Server 2008 na klastrze
	Podsumowanie

Instalacja SQL Server 2008 na klastrze

Stan wyjściowy jest znany: istnieje klaster, ma dysk quorum oraz dysk przeznaczony dla serwera baz danych. Płyta instalacyjna SQL Server jest już w napędzie (lub została zamapowana w środowisku wirtualnym) i można zgodzić się na autorun.

Pierwszy komunikat pozbawia złudzeń na szybką instalację. Nie ma .NET Framework 3.5 – nie będzie SQL.

Rysunek 7: Komunikat instalatora.

Nie pojawia się ani słowo, że na płycie SQL2008 jest jego wersja instalacyjna, ale w takich sytuacjach nie warto się poddawać. Oczywiście można pobrać .NET Framework 3.5 z Internetu, jednak wcześniej warto zajrzeć do katalogu x64\redist\DotNetFrameworks, gdzie znajduje się już plik dotNetFx3Setup.exe.

Warto zwrócić uwagę, że próba samodzielnej instalacji z podkatalogu dla jednej z trzech wspieranych architektur (x86, x64 oraz IA64) nie powiedzie się i wyświetlony zostanie mało jednoznaczny komunikat o niepowodzeniu. Należy użyć pliku dotNetFx3Setup.exe i nie próbować utrudniać sobie pracy.

Instalacja trwa kilka minut, przez większość czasu wyświetlając informację "Download complete. You can now disconnect from the Internet." mimo, że oprogramowanie jest instalowane z płyty DVD.

W końcu, po udanej instalacji należy zrestartować serwer.

Ponowne uruchomienie instalatora SQL Server 2008 wyświetla znowu komunikat o potrzebie .NET Framework, ale tym razem można wybrać pomiędzy OK a Cancel i dzięki temu przejść krok dalej.

Rysunek 8: Komunikat instalatora.

Następna prośba instalatora może dotyczyć poprawki KB942288. Brzmi to niepozornie, jednak jest o tyle ciekawe, że to nowy Windows Installer a dokładniej jego wersja 4.5 Jeżeli nie jest jeszcze zainstalowany, to po instalacji niestety niezbędny jest kolejny restart.

W końcu, uruchamia się instalator i na zakładce Installation pojawiają się upragnione opcje.

Rysunek 9: Możliwe tryby instalacji.

Instalacja stand-alone jest oczywiście możliwa również na węźle klastra, ale mało interesująca i nie warto z niej korzystać. Dwie kolejne pozycje to właśnie te, o które od początku chodziło. Istnieje jeszcze kilka ciekawych możliwości, ale o nich pojawi się parę zdań w dalszej części artykułu. Nowy klaster, nowy SQL – jedynym słusznym wyborem jest w takiej sytuacji "New SQL Server failover cluster installation".

Wyraźnie widać, że w stosunku do SQL Server 2005 znacząco zmieniła się koncepcja instalacji. Dostępne wcześniej proste instalowanie z jednego hosta, zastąpione zostało podejściem "najpierw zrób klaster a później dodaj węzły". Poprzednia wersja była bardziej przyjazna dla użytkownika, ale to tylko pozory. Praktyka wielokrotnie pokazywała, że uproszczone GUI oznaczało mocno skomplikowane mechanizmy pod spodem. Z GUI nie dało się zrobić nic mądrego a silnik w środku działał tak jak mógł w danych realiach. Kto nie spróbował przepchnąć między węzłami w WAN całego programu instalacyjnego, ten niełatwo zrozumie, dlaczego pozornie przyjemny interfejs doprowadzał czasem do rwania włosów z głowy. W SQL Server 2008 zostało to zmienione i teraz na każdym serwerze trzeba mieć program instalacyjny i na każdym wykonać kilka działań.

Niezależnie od tego, że proces instalacji rozbito na kilka kroków, cała aplikacja jest w pełni świadoma klastra i zachowuje się poprawnie.

Kreator instalacji, podobnie jak w starszych wersjach SQL wykonuje wiele sprawdzeń wyświetlając ich wynik ze statusem Passed (wszystko gra), Warning (coś nie tak ale da się zainstalować) i Error (błąd tak poważny, że instalacja jest niemożliwa). Dopiero po gruntownym sprawdzeniu wymagań, pojawia się upragnione okno z opcjami instalacji.

Rysunek 10: Wybór komponentów SQL Server.

Database Engine zwykle jest w środowisku niezbędne. Pozostałe komponenty powinny być dostosowane do potrzeb, ale zazwyczaj rozsądne jest, żeby gdzieś istniała co najmniej jedna instalacja podstawowych narzędzi zarządzających (Management Tools – Basic, i od razu mała uwaga - SQL Profiler oraz Database Engine Tuning Advisor – znajdują się w instalacji „Complete” narzędzi do zarządzania).

Kolejne pytanie rozbudowanego kreatora dotyczy konfiguracji wirtualnej nazwy oraz instancji.

Rysunek 11: Wybór nazwy serwera oraz nazwy instancji.

Jak wyjaśniono we wcześniejszej części artykułu, nazwa instancji pozwala na uruchomienie kilku serwerów SQL na jednym komputerze. Najlepiej przyjąć, że na klastrze nie instaluje się nienazwanych instancji i opcja "Default Instance" nigdy nie powinna pozostać zaznaczona. Warto również zwrócić uwagę, aby nazwy instancji nie duplikowały się w systemie bez świadomej potrzeby. Wirtualna nazwa serwera to ta nazwa, pod którą klienci będą szukać swojego serwera SQL a klaster zadba o to, żeby połączony z taką nazwą klient trafił ze swoim zapytaniem na ten węzeł, który w danej chwili faktycznie zajmuje się usługą. Jak widać, instalator wyświetla informacje o już istniejących na danym komputerze serwerach SQL. W wielu przypadkach może to być bardzo pomocne.

W kolejnych krokach kreatora należy skonfigurować:

• dysk na binaria,
• grupę zasobów,
• dysk na dane,
• podsieć, z której ma korzystać serwer (ważna uwaga poniżej),
• grupy dla serwera (database engine oraz agent) przy czym nie ma obowiązku tworzenia nowej grupy,
• konta usług (dedykowane konto w AD dla usług SQL nie jest takim złym pomysłem)
• collation (bliżej nie wiadomo dlaczego dostępne na dodatkowej zakładce kreatora)
• sposób autentykacji, hasło SA i konta należące do SQL Servers Administrators
• katalogi na dane (w dodatkowej zakładce)
• użycie FILESTREAM (również na zakładce)
• raportowanie błędów i użycia do Microsoft

Po krótkim podsumowaniu można w końcu kliknąć "Install".

Kreator domyślnie przyjmuje, że wirtualny adres IP pozyskany będzie z serwera DHCP. Jest to nowa (cenna!) funkcjonalność Windows Server 2008, jednak nie zawsze adresowane z DHCP serwery są mile widziane i nie zawsze (zwłaszcza w środowiskach laboratoryjnych) DHCP w sieci istnieje. Oznacza to w praktyce, że w momencie pytania o konfigurację sieci, należy zachować czujność i odznaczyć zupełnie niepozorny checkbox. Ekran konfiguracyjny jest szczególnie mylący przez fakt, że podobny ekran podczas tworzenia klastra ma w tym miejscu checkbox służący do zaznaczania czy dana sieć ma być przez klaster używana czy też nie. Jeżeli ktoś przegapi właściwy moment a w sieci DHCP nie istnieje instalacja się nie powiedzie. Co gorsze, utworzona zostanie grupa zasobów, w niej nazwa, adres i serwer SQL, ale całość nie będzie działać. Mimo, że można poprawić właściwości adresu, to jednak taki klaster nie będzie możliwy do rozszerzenia o kolejne węzły. Instalator oczywiście poinformuje o błędzie, jednak nie wyjaśni, na czym ów błąd dokładnie polega. Żeby już zupełnie zamieszać, instalator nie posprząta po sobie i cały proces instalacji należy samodzielnie cofnąć do punktu wyjścia tak na źle zainstalowanym węźle jak i na całym klastrze.

Jeżeli wszystko działa poprawnie, instalator wyświetli informację o powodzeniu instalacji a w klastrze pojawia się nowa grupa SQL Server zawierająca adres, nazwę, dysk, serwer SQL oraz agenta SQL.

Rysunek 12: Działająca grupa w klastrze.

Ciekawe efekty przynosi sprawdzenie potencjalnych właścicieli zasobów (possibile owners). Dysk, który zazwyczaj istnieje w klastrze wcześniej, może zostać przejęty przez wszystkie węzły. Adres sieciowy oraz nazwa również, choć nie jest to domyślnie zaznaczone. W przypadku serwera i agenta SQL, na liście pojawiają się tylko te węzły, na których istnieją już binaria SQL, czyli początkowo tylko jeden. Jest to zgodne z opisaną wyżej nową polityką instalacji, jednak oznacza w praktyce, że cały proces instalacji stworzył jednowęzłowy klaster SQL. Wbrew pozorom, może to być często użyteczne, jednak nie zapewnia redundancji i w większości przypadków administratorom zależy na tym, żeby węzłów było więcej. W tym celu, należy uruchomić program instalacyjny SQL i skorzystać z drugiej opcji instalacji: "Add node to a SQL Server failover cluster". Oczywiście, operację tą należy wykonać na tym węźle, który ma być dołączony do klastra. Warto przy tym pamiętać, że serwer już działa i może obsługiwać aplikacje podczas dodawania kolejnych węzłów, jednak zdrowy rozsądek podpowiada, że jeżeli to możliwe, należy jeszcze poczekać z oddaniem serwera do użytku. Podczas instalacji dodatkowych węzłów, praca już istniejącej instancji SQL nie jest ani na chwilę przerywana, co może w wielu sytuacjach być bardzo ważne.

Jak nietrudno się domyślić, instalacja na drugim węźle zacząć się musi od .NET Framework 3.5, restartu, Installera 4.5 i kolejnego restartu. Później, z zakładki "Install" wybrać można wspomnianą powyżej opcję dodania węzła do już istniejącego klastra SQL i po sprawdzeniu zgodności z wymaganiami, cały proces przebiega stosunkowo sprawnie. Warto zaznaczyć, że wszystkie istotne ustawienia zostały skonfigurowane podczas tworzenia pierwszego węzła i w zasadzie jedyna decyzja administratora polega na określeniu, do którego klastra SQL (a w zasadzie instancji w klastrze) należy dodać instalowany właśnie węzeł.

Rysunek 13: Wybór serwera, do którego dodawany jest nowy węzeł.

Następnie należy podać hasła do używanych w SQL kont serwisowych oraz określić parametry raportowania do Microsoft o użyciu i ewentualnych błędach serwera. Po szybkim sprawdzeniu parametrów węzła, wyświetlane jest podsumowanie i można w końcu kliknąć "Install".

Całość kończy się przyjemnym ekranem informującym o powodzeniu instalacji.

Rysunek 14: Komunikat o powodzeniu insalacji.

W efekcie, do już istniejących zasobów instancji SQL, dodawany jest drugi węzeł jako "Possible owner". Grupa daje się przenosić a serwer działa bez zarzutu. W analogiczny sposób dodawać można kolejne węzły. Należy przy tym pamiętać, że SQL w wersji Standard pozwala na tworzenie dwuwęzłowego klastra podczas, gdy wersja Enterprise ograniczona do 16 węzłów.

 Do początku strony

Podsumowanie

Podsumowując stwierdzić należy, że klaster to bardzo użyteczne rozwiązanie. Sprawia on, ze usługa (w przypadku niniejszego artykułu, usługa związana z SQL Server) jest stale utrzymywana w działaniu. Jeżeli przestanie działać – klaster ją uruchomi ponownie, być może na innym komputerze, jednak w taki sposób, że klienci nie zauważą żadnej zmiany. W efekcie, czas przestoju usługi jest stosunkowo niewielki, co bywa bardzo cenne.

Oznacza to w praktyce, że administrator myślący poważnie o czasie dostępności swoich systemów, musi wziąć pod uwagę rozwiązanie bazujące na klastrze. Być może wymagania klastra (zwłaszcza współdzielone dyski i wersje Enterprise) okażą się w konkretnej sytuacji zbyt wysokie, niemniej jednak, właściwe podejście powinno wyglądać tak, że bazy danych mają pracować w klastrze, a być może istnieją przesłanki (najczęściej wynikające z budżetu), dla których z klastra w danej sytuacji należy zrezygnować. Zbudowanie klastra SQL jest naprawdę proste a korzyści zauważy każdy użytkownik aplikacji korzystającej z baz danych.

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