HA systeemid

Klastriks nimetatakse infotehnoloogias gruppi omavahel ühendatud arvuteid mis töötavad ühtse kogumina. Klastrite ehitamise eesmärk on tavaliselt jõudluse ja tõrkekindluse kasvatamine.

Laias perspektiivis võib klastri jagada kolmeks põhiliseks komponendiks.

Serverid
Serverite vaheline võrk
Serveritel asuv tarkvara

Töökindlus klastri puhul on tähtis et kui süsteemi mingis komponendis tekib tõrge siis ülejäänud süsteem on suuteline ilma riknenud komponendita edasi toimima. Selle saavutamiseks dubleeritakse klastri komponente selleks et vähendada ohtu et mõni klastri sõlm tervikuna toimimast lakkaks. Lisaks on vajalik et kasutusel oleks spetsiaal tarkvara mis oskaks klastri komponenti tõrke korral enda andmevoo ümber seadistada nii et välditaks riknenud osa.

Klastri tüübid

Active/active - Klaster mille puhul kõik kasutuses olevad noded on aktiivsed. Juhul kui üks nodedest seiskub siis jaotatakse koormus ülejäänud nodede vahel ära.
Active/passive - Klaster mille puhul üks node on aktiivne ja teine node on ooteseisus. Juhul kui aktiivne node ära sureb käivitatakse teenus ooteseisus olevas nodes ning töö jätkub. Antud lahenduse puhul on probleemiks see, et üldiselt on süsteemi töös mõnda aega tõrge kuna süsteem peab aru saama et primaarne node on maas ja teise node käivitamine võtab aega.
N+1 - Lisab süsteemi ühe lisa node mis käivitatakse alles siis kui üks nodedest on surnud. Seda nimetust kasutatakse üldiselt klastrites kus on palju nodesi jooksmas. Kahe nodega klastri puhul on see sama mis active/passive.
N+M - Sama mis eelmine kuid lisa nodesi on rohkem. Sellist lahendust kasutatakse siis kui on vaja kõrgemat tõrkekindlust, miinuseks on kindlasti suurem kulu kuna serverite arv mida sellise süsteemi hoidmiseks on vaja on tunduvalt suurem.
N-to-1 - Juhul kui failover toimub siis tagavara node tuuakse kasutusse ainult seni kuni primaarne node on tagasi online. Kui see hetk tuleb siis viiakse kõik teenused primaarse node peale tagasi ning failover node läheb jälle ooteseisu.
N-to-N - Kombinatsioon active/active ja N+M klastrist. Selle klastri puhul jagatakse failind node peal olevad teenused aktiivsete nodede vahel ära ning seega kaob vajadus standby nodede hoidmise järele.

Kõrgkäideldavuse mõõtmine

Süsteemi käideldavust mõõdetakse selle järgi millal teenused on saadavad. Juhul kui süsteem on töös kuid teenused mida süsteem peaks pakkuma ei toimi on tegemist downtimega.

Availability %	Downtime per year	Downtime per month*	Downtime per week
90% ("one nine")	36.5 days	72 hours	16.8 hours
95%	18.25 days	36 hours	8.4 hours
97%	10.96 days	21.6 hours	5.04 hours
98%	7.30 days	14.4 hours	3.36 hours
99% ("two nines")	3.65 days	7.20 hours	1.68 hours
99.5%	1.83 days	3.60 hours	50.4 minutes
99.8%	17.52 hours	86.23 minutes	20.16 minutes
99.9% ("three nines")	8.76 hours	43.8 minutes	10.1 minutes
99.95%	4.38 hours	21.56 minutes	5.04 minutes
99.99% ("four nines")	52.56 minutes	4.32 minutes	1.01 minutes
99.999% ("five nines")	5.26 minutes	25.9 seconds	6.05 seconds
99.9999% ("six nines")	31.5 seconds	2.59 seconds	0.605 seconds
99.99999% ("seven nines")	3.15 seconds	0.259 seconds	0.0605 seconds

Antud tabelist on näha et 99% uptime ja 99.99% uptime vahe on väga suur ning siin on iga komakoht väga tähtis.

Kõrgkäideldavuse rakendamine

Selleks et süsteemi muuta kõrgkäideldavaks tuleks kirja panna kõik süsteemi komponendid mis võivad süsteemi käideldavust mõjutada. Komponente mille riknemise puhul süsteem ei ole enam käideldav kutsutakse SPOF-ideks(Single Point Of Failure). Selleks võivad olla andmesalvestus meedia, võrgu ühendused, serveriruumi lokatsioon jms. Juhul kui süsteem on kaardistatud tuleks otsustada millised komponendid on kriitilised ning vajavad klasterdamist. Klasterdamise plaani koostamisel on tähtis leida kesktee äripoole soovide ja soetusmaksumuse vahel. See osutub üldiselt kõige keerukamaks kuna tihti on raske põhjendada suurt väljaminekut mida klaster lahendus esialgu kindlasti on. Teine kriitiline komponent on süsteemide käideldavuse nõuete kokku leppimine. Tüüpiliselt on äripoole nõudmised ja eeldused süsteemidele reaalsusest erinevad ning nende täitmine tunduvalt keerukam kui reaalselt vaja oleks. Seetõttu ongi mõistlik süsteemi analüüsida ja kokku leppida kas ikka kõik süsteemid on kriitilised või on mõne süsteemi puhul ka katkestused lubatud.