Rakennamme SQL-klusterin. Mutta miten?

Ennen suunnittelua

Alkuun viralliset Microsoftin suositukset failover-klusteria (MSCS) rakennettaessa:

Jos ylläolevia ohjeita ei noudateta, MS toteaa kylmästi että kyseessä on ns. unsupported configuration. Tuen saaminen virityksille voi olla mielenkiintoinen harjoitustyö.

Klusterointi käytännössä

Kyllä, klusterin voi asentaa virtuaalikoneillekin, vaikka niitä paljon HCL:ssä ole. Microsoft tukee noin periaatteessa jopa MS Virtual Serveriin kahden noodin klusterin asennusta, sillä Virtual Serverissä on mahdollista jakaa yksi levy useamman virtuaalikoneen kesken (jolloin quorum ja muut jaetut resurssilevyt ovat mahdollisia). Yli kahden noodin klusterit eivät ole Virtual Serverissä tuettuja.

VMware? Toki. Kunhan käytetty VMware tukee jaettuja levyjä. Käytännössä ESX tai VMware Infrastructure, GSX/VMware Server on hieman rajoittuneempi.

Jaettu SCSI vai SAN? Käytännössä nykyään kuitukortit ja SAN-levy, jaetun väylän SCSI alkaa olla eilispäivää. Jos taitoa on hyppysissä ja iSCSI taipuu, on jaetut levyresurssit mahdollista toteuttaa myös sen avulla.

Apua, en halua asentaa kolmatta ja neljättä konetta AD:ta varten? Käytännössä AD:n _voi_ tunkea klusterin noodille. Tätä ei kuitenkaan suositella, ja yhdellä DC:llä homma on hieman turhaa harjoitusta - jos juuri se noodi, jossa AD pyörii, menee alas, kilahtaa koko klusteri kuitenkin kun AD:sta ei ole saatavilla tarvittavia palveluja. Että se siitä vikasietoisuudesta sitten. Testiympäristössä tälläinen konfiguraatio on sallittua toimintaa, tuotannossa ei.

Yleiskuva kahden koneen SQL-klusterista

Mitä tarvitaan ennen pystytystä?

Jokaiselle laitteelle IP-numeroita kasa.

Hieman rautalankaa: Virtuaalisia IP:eitä ei konfiguroida koneiden verkkokorteille, vaan ne asennuksen eri aikana kerrotaan erilaisille asennusvelhoille, jotka huolehtivat siitä että IP:t tulevat virtuaalisesti varatuiksi missä milloinkin. Verkkokorttien asetuksiin syötetään vain ja ainoastaan palveluverkon IP-numerot, Heartbeat-verkon IP:t ja mahdollisen varmistusverkon IP:t.

Jaettuja levyjä.

Klusteriasennuksen marssijärjestys

Klusterit asennetaan oikeassa järjestyksessä. Alussa klusterissa on vain ja ainoastaan yksi kone. Klusterin muut noodit pidetään sammutettuina tai peräti täysin asentamattomina.

Käyttäjätunnus, jolla setuppeja ajetaan, täytyy olla kaikkien klusterin noodien Local Admin. Käytännössä noodeille siis kirjaudutaan joko Domain Admin-tunnuksella (jolla on automaattisesti em. oikeus), tai luodaan toimialueelle käyttäjätunnus joka käydään erikseen lisäämässä jokaisen noodin paikalliseen Administrators-ryhmään. Noin käytännössä Domain Administrator on vallan hyvä, erillistä tunnusta ei kannata hienostelun takia luoda.

Klusteripalvelu tarvitsee oman käyttäjätunnuksensa toimialueella (tyyliin DOMAIN\CLUSTERUSER) Tämä on siis tunnus, jota MSCS-service käyttää. Tunnus on luotava etukäteen, ja se lisätään kaikkien noodien Local Admin -ryhmiin. Tämä ei ole sama asia kuin se tunnus, jolla klusteroituja SQL-palveluja ajetaan. Tämä ei myöskään ole se tunnus, jolla asennusta ajetaan - kyseessä on pelkkä service-tunnus. Kun klusterointivelhoa ajetaan, velho kysyy tämän tunnuksen nimen ja salasanan.

Verkkokorttien nimissä (Network Places / Properties - Rename) ei saa olla välilyöntejä nimen perässä.

Jokaisella noodilla täytyy olla olemassa - ja ajossa - seuraavat palvelut:

Varsinkin viimeisen puuttuminen aiheuttaa hassunhauskoja ongelmia sitten varsinaisen SQL-asennuksen aikana.  

Klusterin ryhmien nimissä EI saa käyttää erikoismerkkejä. A-Z ja 0-9 ovat sallittuja. Ei yli 14 merkin mittaisia nimiä. Kaikki nimet (klusterin nimi, virtuaalipalvelujen nimet ja niin edelleen) KAPITAALIKIRJAIMIN.

Kun AD on pystyssä, tunnukset on luotu, ja se kone josta on tarkoitus tehdä klusterin ensimmäinen noodi on asennettu - ja se on liitetty toimialueeseen member serverinä - voidaan lähteä itse klusterin pystytykseen. Jaetut levyt (minimissään klusterin Quorum-levy) liimataan kiinni ensimmäiseen koneeseen, levy partitioidaan ja formatoidaan, ja cluadmin.exe:llä konfiguroidaan uusi klusteri.

Klusterointivelhoke kyselee paljon asioita, ja tarkistaa verkkokorttien konfiguraatiot ja jaetut levyt. Jos kaikki oli hyvin, lopputuloksena on yhden noodin klusteri.

Kun yhden noodin klusteri on toimiva, tuodaan muut koneet yksi kerrallaan osaksi klusteria, käytännössä:

SAN-levyjen käytössä jaettuina levyinä on potentiaalinen ongelma: lue lisää alta. Jos klusteri käyttää jaettua SCSI-levyä, ongelmaa ei yleensä ole.

Kun noodia lisätään olemassaolevaan klusteriin, asennusvelho saattaa ystävällisesti kilahtaa ja ja antaa erheilmoituksen:

Checking that all nodes have access to the quorum resource
Status: 0x800713de
The quorum disk could not be located by the cluster service.

Monimutkaisissa SAN-ympäristöissä noodit saattavat nähdä jaettujen levyjen LUNit ja TID:t eri tavalla. Asennusvelho yrittää selvittää mikä levy kuuluu potentiaalisesti mihinkin klusteriin, ja jos identifikaatio menee takamukselleen, velho tuomitsee noodin klusteriin kelpaamattomaksi. Ei hätää, asiaan on kiertokeino:

To work around this issue, click Advanced when you are prompted for the nodes to add to the cluster, and then click Advanced (minimum) configuration.
The Advanced option excludes the detection that is described earlier in this article from the Analyze process, and permits the cluster installation to continue.
However, if there are disk-configuration issues, the cluster may experience issues with bringing the disks online or with disk failover.

Kun toinen noodi on onnistuneesti tuotu klusteriin, kannattaa testata failoverin onnistuminen. Cluadmin.exe:stä voidaan resurssiryhmiä hyppyyttää noodilta toiselle. Testaa että Cluster Group (joka yleensä sisältää Cluster Admin IP- ja Name -resurssin sekä Quorum-levyn) loikkaa noodilta toiselle ja tulee kauniisti online-tilaan.

Mikäli päästään näin pitkälle, on kaikki jo perin mukavasti, onnea toimivan klusterin johdosta.

Ennen SQL-serverin kanssa pulaamista

Ennen kuin yhtään SQL-instanssia asennetaan, täytyy MSDTC klusteroida (sikäli kun se halutaan/joudutaan klusteroimaan). MSTDC lisätään omaan klusteriryhmäänsä (cluadmin.exe:n näyttämä "group"), sille annetaan oma virtuaalinen IP ja oma pieni jaettu levypartitio. Aiheesta on KB-artikkeleita:

How to configure Microsoft Distributed Transaction Coordinator on a Windows 2003 cluster
How to enable network DTC access in Windows Server 2003

Edellämainitut paperit kannattaa lukea hyvin tarkkaan, sillä hommassa on koukku - kun MSDTC:n klusteriresurssi on rakennettu, sitä EI SAA PÄÄSTÄÄ online-tilaan ennen kuin network DTC access on asennettu. Mikäli yrität tuoda MSDTC:n onlineksi suoraan rersurssimäärittelyjen jälkeen, homma hajoaa käsiin. Ensin siis luodaan resurssit paperien mukaan, ja heti sen jälkeen asennetaan DTC network access. Kone bootataan, ja tämän jälkeen klusteroitu DTC nousee onlineksi itsestään, mutta ongelmaa ei ole - network access asennettiin juuri. Pääsyoikeuksien konfiguroiminen dtc-palveluun em. ohjeiden mukaan ei sitten enää ole ongelma.

Testaa klusterin toiminta (failover) ennen kuin yrität asentaa SQL Serveriä.

Lisää jokaisen noodin unc-nimi ja IP-numero jokaisen noodin LMHOSTS-tiedostoon. DNS ei ole aina täydellinen eikä NetBIOS-nimenselvitys aina ihan pelitä. Helppo ja halpa kiertokonsti, ynnä varmistaa asennuksen onnistumisen.

Luo SQL Serverin ajotunnusten vaatimat ryhmät etukäteen toimialueelle. Käytännössä tarvitaan kolme ryhmää, alla nimiehdotukset:

Ryhmiä ei tarvitse sen kummemmin konfiguroida, kunhan ovat olemassa.

Luo asennettaville SQL-instansseille toimialueen käyttäjätunnukset (ajotunnukset) ennen asennusta. Jokaiselle instanssille oma tunnuksensa. Käytännössä lisätään siis toimialueelle normaali user-tunnus tyyliin DOMAIN\SQLUSER1. Tunnus lisätään klusterin kaikkien noodien paikalliseen Administrators -ryhmään.

SQL-palvelun ajotunnuksen salasanassa ei saa olla lainausmerkkejä.

Kaikkien noodien tulee päästä käsiksi asennustiedostoihin ilman käyttäjätunnusta. Helpommin tämä tulee suoritettua niin, että SQL Serverin asennustiedostot (DVD:n tai CD:eiden sisältö) kopioidaan ennen asennuksen aloittamista paikalliselle kiintolevylle. Asennusohjelma huolehtii itse tarvittavista tiedostokopioinneista muille noodeille asennuksen aikana.

SQL-serverin asennuksen aikana

Jos katkaiset asennuksen kesken syystä tai toisesta (esim. huomaat tehneesi konfiguraatiovirheen), poista käsin kaikki asennetut osat ennen uutta yritystä. Käytännössä Add/Remove Programs auki, kaikki SQL-niminen pois, kaikki XML-niminen pois. Jollet tätä tee, kaatuvat seuraavat asennusyritykset mitä hämärimmillä tavoilla. Trust me, kokemusta on.

Jos tarkoitus on - MS:n ohjeiden vastaisesti - tehdä active-active -klusteri (jossa molemmat noodit ajavat normaalitilanteessa kumpikin omaa instanssiaan SQL-palvelimesta, siis kaksi erillistä virtuaalista palvelua), täytyy vähintään toinen instanssi tehdä nimetyksi (named instance). Yhdessä klusterissa voi olla vain yksi default instance.

Suositus on, että useamman instanssin asennuksessa kaikki instanssit tehdään nimettyinä.

Kuten edelläkin tuli mainittua, jos asennetaan mitä hyvänsä muita SQL:n palveluita kuin pelkkä kantapalvelu (vaikkapa notification services, workstation components, integration services ja niin edelleen), täytyy MSDTC ajaa klusteroituna palveluna.

Kaikkien noodien tulee olla identtisesti konfiguroituja. Kaikkien noodien politiikkojen (GPO:t ja domain/machine policyt) tulee olla samanlaisia.

Varsinainen SQL:n asennus suoritetaan siltä noodilta käsin, josta tulee aluksi klusterin aktiivinen instanssi kyseiselle palvelulle. Asennuksen aikana täytyy varmistua siitä, ettei muilla noodeilla ole kukaan kirjautuneena - ei niin konsolilla, kuin RDP:nkään kautta. Asennus kilahtaa mikäli jossain noodissa on jokin tunnus kirjautuneena.

Virtuaalisen SQL-palvelun nimi KAPITAALIKIRJAIMIN, ja alle 14 merkkiä. Ei erikoismerkkejä instanssien nimissä eikä virtuaalipalvelujen nimissä (http://support.microsoft.com/kb/285100)

Kaikkien instanssiin liittyvien jaettujen levyjen tulee olla klusterissa "online"-tilassa asennuksen aikana. Kaikilla jaetuilla levyillä tulee olla asematunnus (tai mount point). Levyjen pitää olla osa instanssia varten luotua resource grouppia.

Disabloi NetBIOS kaikilta muilta verkkokorteilta paitsi niiltä joilta klusteroitua palvelua tarjotaan ulospäin.

Asennuksen jälkeen

Virtuaalisen palvelun nimeä voi muuttaa. Instanssin nimeä ei.

Service Packin asentaminen tapahtuu kullekkin instanssille erikseen - tosin jaetut komponentit usean instanssin klusterissa päivittyvät ensimmäisellä ajokerralla kaikki. Jälkimmäisillä ajokerroilla päivittyy vain kunkin noodin Database Services -osio.

Uteleminen klusteroidulta SQL-palvelimelta:

select SERVERPROPERTY('IsClustered') as _1_Means_Clustered RPROPERTY('ComputerNamePhysicalNetBIOS') as CurrentNode
, SERVERPROPERTY('Edition') as Edition
, SERVERPROPERTY('MachineName') as VirtualName
, SERVERPROPERTY('InstanceName') as InstanceName
, SERVERPROPERTY('ServerName') as Virtual_and_InstanceNames
, SERVERPROPERTY('ProductVersion') as Version
, SERVERPROPERTY('ProductLevel') as VersionNameWithoutHotfixes
select * from sys.dm_io_cluster_shared_drives
select * select * from sys.dm_os_cluster_nodes