Usredotočimo se više na neke veće arhitektonske principe upravljanja klasterima nego na bilo koje pojedinačno tehnološko rješenje.
Neke stvarne implementacije vidimo kasnije u knjizi - a o tome kako ovo funkcionira na Amazonovom AWS-u možete saznati puno u mojoj knjizi Manning o Nauči Amazon Web Services u mjesecu ručka. Ali zasad, provjerimo da li nam je ugodno s osnovama.
Pokretanje poslužiteljskih operacija korištenjem klastera bilo fizičkih ili virtualnih računala podrazumijeva poboljšanje pouzdanosti i izvedbe iznad onoga što biste mogli očekivati od jednog, moćnog poslužitelja. Pouzdanost dodajete izbjegavanjem da cijelu svoju infrastrukturu objesite na jednu točku kvara (tj. Na jedan poslužitelj). A performanse možete povećati sposobnošću da vrlo brzo dodate računalnu snagu i kapacitet povećavanjem i smanjivanjem.
To bi se moglo dogoditi inteligentnim širenjem vašeg radnog opterećenja u razna zemljopisna okruženja i okruženja potražnje (uravnoteženje opterećenja)
rezervni poslužitelji koji se mogu brzo koristiti u slučaju da radni čvor zakaže (preusmjeravanje), optimizirajući način na koji je razmješten vaš podatkovni nivo ili omogućujući toleranciju kvarova kroz labavo povezane arhitekture.
Doći ćemo do svega toga. Prvo, ipak, evo nekoliko osnovnih definicija:
Čvor : Pojedinačni stroj (bilo fizički ili virtualni) koji samostalno izvodi operacije poslužitelja na vlastitom operacijskom sustavu. Budući da bilo koji pojedinačni čvor može zakazati, ispunjavanje ciljeva dostupnosti zahtijeva da više čvorova djeluje kao dio klastera.
Klaster : Dva ili više čvorova poslužitelja koji rade u međusobnoj koordinaciji kako bi izvršavali pojedinačne zadatke kao dio veće usluge, gdje međusobna svijest omogućuje jednom ili više čvorova da nadoknade gubitak drugog.
Neuspjeh poslužitelja : nesposobnost čvora poslužitelja da adekvatno odgovori na zahtjeve klijenta. To je moglo biti zbog potpunog pada, problema s povezivanjem ili zato što je preplavljena velikom potražnjom.
Otkazivanje : Način na koji klaster pokušava prilagoditi potrebe klijenata osirotelih neuspjehom jednog čvora poslužitelja pokretanjem ili preusmjeravanjem drugih čvorova kako bi se popunila praznina u usluzi.
Failback : Vraćanje odgovornosti na čvor poslužitelja dok se oporavlja od kvara.
Replikacija : Stvaranje kopija kritičnih spremišta podataka kako bi se omogućio pouzdan sinkroni pristup s više čvorova poslužitelja ili klijenata i kako bi se osiguralo da će preživjeti katastrofe. Replikacija se također koristi za omogućavanje pouzdanog uravnoteženja opterećenja.
Višak : Pribavljanje više identičnih fizičkih ili virtualnih čvorova poslužitelja od kojih bilo koji može usvojiti osirotele klijente drugog koji ne uspije.
Podijeljeni mozak : Stanje pogreške u kojem se mrežna komunikacija između čvorova ili zajedničke pohrane nekako pokvarila i više pojedinačnih čvorova, svaki vjerujući da je jedini čvor još uvijek aktivan, nastavlja pristupati i ažurirati zajednički izvor podataka. Iako ovo ne utječe na dizajn zajedničkog ničega, može dovesti do pogrešaka klijenta i oštećenja podataka unutar zajedničkih klastera.
Ograđivanje : Da bi se spriječilo razdvajanje mozga, demon stonithd može se konfigurirati da automatski isključi neispravni čvor ili nametne virtualnu ogradu između njega i resursa podataka ostatka klastera. Sve dok postoji šansa da čvor i dalje može biti aktivan, ali se ne koordinira pravilno s ostatkom klastera, ostat će iza ograde. Stonith je kratica za "Pucaj u drugi čvor u glavi". Stvarno.
Kvorum : Možete konfigurirati ograđivanje (ili prisilno gašenje) koje će se nametnuti čvorovima koji nisu ispali međusobno ili s nekim zajedničkim resursima. Kvorum se često definira kao više od polovice svih čvorova na ukupnom klasteru. Korištenjem tako definiranih konfiguracija izbjegavate imati dva potklastera čvorova, od kojih svaki vjeruje da drugi ne radi ispravno, pokušavajući izbaciti drugi.
Oporavak od katastrofe : Vaša se infrastruktura teško može smatrati visoko dostupnom ako nemate automatizirani sustav sigurnosnih kopija, zajedno s integriranim i testiranim planom oporavka od katastrofe. Vaš će plan morati uzeti u obzir preraspodjelu svakog od poslužitelja u vašem klasteru.
Aktivni / pasivni klaster
Ideja iza preusmjeravanja usluge je da bi nagli gubitak bilo kojeg čvora u klasteru usluga brzo nadoknadio drugi čvor koji bi zauzeo njegovo mjesto. Da bi to uspjelo, IP adresa se automatski premješta u čvor u stanju pripravnosti u slučaju otkazivanja. Alternativno, mrežni alati za usmjeravanje poput uravnoteživača opterećenja mogu se koristiti za preusmjeravanje prometa s neuspjelih čvorova. Točan način na koji se failover događa ovisi o načinu na koji ste konfigurirali svoje čvorove.
U početku će biti konfiguriran samo jedan čvor koji služi klijentima i nastavit će to činiti sam dok nekako ne uspije. Odgovornost za postojeće i nove klijente tada će se prebaciti (tj., „Failover“) na pasivni - ili rezervni - čvor koji se do sada pasivno držao u rezervi. Primjenjujući model na više poslužitelja ili komponente poslužiteljske sobe (poput napajanja), n + 1 redundantnost pruža taman dovoljno resursa za trenutnu potražnju i još jednu jedinicu za pokrivanje kvara.
Aktivni / aktivni klaster
Klaster koji koristi aktivni / aktivni dizajn imat će dva ili više identično konfiguriranih čvorova koji neovisno opslužuju klijente.
Ako jedan čvor zakaže, njegovi će se klijenti automatski povezati s drugim čvorom i, koliko dopuštaju resursi, dobiti puni pristup resursima.
Jednom kada se prvi čvor oporavi ili zamijeni, klijenti će se ponovno podijeliti između oba čvora poslužitelja.
Primarna prednost pokretanja aktivnih / aktivnih klastera leži u sposobnosti učinkovitog uravnoteženja radnog opterećenja između čvorova i čak mreža. Uravnoteživač opterećenja - koji usmjerava sve zahtjeve klijenata na dostupne poslužitelje - konfiguriran je za nadgledanje aktivnosti čvorova i mreže i korištenje nekog unaprijed određenog algoritma za usmjeravanje prometa na one čvorove koji su u stanju to najbolje riješiti. Politike usmjeravanja mogu slijediti kružni obrazac, gdje se zahtjevi klijenta jednostavno izmjenjuju između dostupnih čvorova ili unaprijed zadanom težinom gdje neki čvor preferira neki omjer.
Imati pasivni čvor koji djeluje kao stand-by zamjena za svog partnera u aktivnoj / pasivnoj konfiguraciji klastera pruža značajnu ugrađenu redundanciju. Ako vaš rad apsolutno zahtijeva neprekinutu uslugu i neprimjetne prijelaze u slučaju otkaza, tada bi vam neka varijacija aktivne / pasivne arhitekture trebala biti cilj.
Klasteri Dijeljeno-ništa i Dijeljeno-diskovi
Jedno od vodećih načela distribuiranog računanja je izbjegavanje da se vaš rad oslanja na bilo koju točku kvara. To jest, svaki bi resurs trebao biti ili aktivno repliciran (suvišan) ili neovisno zamjenjiv (failover), i ne bi trebao postojati niti jedan element čiji bi neuspjeh mogao srušiti cijelu vašu uslugu.
Sada zamislite da imate nekoliko desetaka čvorova koji se svi oslanjaju na jedan poslužitelj baze podataka za svoju funkciju. Iako neuspjeh bilo kojeg broja čvorova neće utjecati na daljnje zdravlje tih čvorova koji ostanu, ako baza podataka propadne, cijeli klaster bi postao beskoristan. Čvorovi u klasteru s dijeljenim ničim, međutim, (obično) će održavati vlastite baze podataka, tako da - pod pretpostavkom da su ispravno sinkronizirani i konfigurirani za trajnu sigurnost transakcija - nikakav vanjski kvar neće utjecati na njih.
To će imati značajniji utjecaj na klaster uravnoteženog opterećenja, jer svaki čvor uravnotežen opterećenja ima stalnu i kritičnu potrebu za istodobnim pristupom podacima. Međutim, pasivni čvor na jednostavnom sustavu preusmjeravanja mogao bi preživjeti neko vrijeme bez pristupa.
Iako bi takva postavka mogla usporiti način na koji klaster odgovara na neke zahtjeve - dijelom i zbog straha od kvarova s podijeljenim mozgom, moglo bi biti potrebno periodično ograđivanje stonithom - kompromis može biti opravdan za kritično raspoređivanje u misijama gdje je pouzdanost primarna briga.
Dostupnost
Prilikom dizajniranja klastera, trebat ćete imati prilično dobar osjećaj koliko tolerantni možete biti neuspješni. Ili, drugim riječima, s obzirom na potrebe ljudi ili strojeva koji konzumiraju vaše usluge, koliko dugo može trajati prekid usluge prije nego što se rulja prolije kroz vaša prednja vrata vilicama i plamenim bakljama. Važno je to znati jer će količina viška koju ugradite u svoj dizajn imati ogroman utjecaj na prekide s kojima ćete se na kraju suočiti.
Očito je da će se sustav koji gradite za uslugu koja se može isključiti tijekom vikenda, a da to nitko ne primijeti, uvelike razlikovati od web mjesta e-trgovine čiji kupci očekuju pristup 24 sata dnevno. U najmanju ruku, trebali biste općenito težiti prosjeku dostupnosti od najmanje 99% - a neke operacije zahtijevaju znatno veće rezultate u stvarnom svijetu. Vrijeme porasta od 99% značilo bi gubitak kraći od ukupno četiri dana svake godine.
Postoji relativno jednostavna formula pomoću koje možete izgraditi korisnu procjenu dostupnosti (A). Ideja je podijeliti srednje vrijeme prije kvara s prosječnim vremenom prije kvara plus srednje vrijeme za popravak.
A = MTBF / (MTBF + MTTR)
Što se vrijednost A približi vrijednosti 1, vaš će klaster biti dostupniji. Da biste dobili realnu vrijednost za MTBF, vjerojatno ćete trebati potrošiti vrijeme izlažući stvarni sustav ozbiljnoj kazni i pažljivo ga promatrajući zbog softverskih, hardverskih i mrežnih kvarova. Pretpostavljam da biste mogli pogledati i objavljene metrike životnog ciklusa dobavljača hardvera ili velikih potrošača poput Backblazea kako biste dobili ideju koliko dugo može trajati teško korišteni hardver.
MTTR će biti proizvod vremena koje je potrebno vašem klasteru da zamijeni funkcionalnost poslužiteljskog čvora koji nije uspio (postupak koji je sličan, iako nije identičan oporavku od katastrofe - koji se fokusira na brzu zamjenu neuspjelog hardvera i povezivanja). U idealnom slučaju to bi bila vrijednost što bliža nuli sekundi.
Problem je u tome što je u stvarnom svijetu obično previše nepoznatih varijabli da bi ova formula bila uistinu točna, jer će čvorovi koji rade s različitim softverskim konfiguracijama i izgrađeni s hardverom različitih profila i dobi imati širok raspon očekivanog životnog vijeka. Ipak, to može biti dobar alat koji će vam pomoći da prepoznate dizajn klastera koji je najbolji za vaš projekt.
Pomoću tih podataka možete lako generirati procjenu ukupnog zastoja vaše usluge tijekom cijele godine.
S tim u vezi, ako svoje resurse postavljate na neovisnog dobavljača platforme poput VMWare ili Amazon Web Services, ugovor je o razini usluge (SLA) davatelja usluge. Amazonov EC2, na primjer, jamči da će njihovi računski primjerci i uređaji za pohranu podataka u blokovima isporučivati mjesečni postotak neprekidnog rada od najmanje 99,95% - što je manje od pet sati zastoja godišnje. AWS će izdavati kredite mjesecima u kojima su promašili ciljeve - iako nedovoljno dovoljni da nadoknade ukupne poslovne troškove vašeg zastoja. Pomoću tih podataka možete organizirati razinu tehnološkog viška koja odgovara vašim jedinstvenim potrebama.
Naravno, kao pružatelj usluga vlastitim kupcima, možda ćete trebati objaviti vlastiti SLA na temelju procjena MTBF-a i MTTR-a.
Rukovanje sesijom
Za bilo koji odnos poslužitelja i klijenta, podatke generirane HTTP sesijama s podacima potrebno je spremiti na način koji će ih učiniti dostupnima za buduće interakcije. Klaster arhitekture mogu unijeti ozbiljnu složenost u ove odnose, jer se određeni poslužitelj s kojim klijent ili korisnik komunicira može mijenjati između jednog i sljedećeg koraka.
Radi ilustracije, zamislite da ste prijavljeni na Amazon.com, pregledavate njihove knjige o LPIC treningu i povremeno dodajete neki predmet u košaricu (nadamo se, još primjeraka ove knjige). Dok ste spremni za unos podataka o plaćanju i odjavu, poslužitelj koji ste koristili za pregledavanje možda više uopće neće postojati. Kako će vaš trenutni poslužitelj znati koje ste knjige odlučili kupiti?
Ne znam točno kako Amazon to rješava, ali problem se često rješava pomoću alata za replikaciju podataka, poput memcached rada na
vanjski čvor (ili čvorovi). Cilj je pružiti stalan pristup pouzdanom i dosljednom izvoru podataka bilo kojem čvoru koji bi mu mogao zatrebati.
Ovaj je članak preuzet iz knjige „ Naučite sebe Linux virtualizacija i velika dostupnost: pripremite se za ispit za ovjeru LPIC-3 304 “. Pogledajte moje ostale knjige o administraciji AWS-a i Linuxa , uključujući Linux u akciji i Linux u pokretu - hibridni tečaj koji se sastoji od više od dva sata videozapisa i oko 40% teksta Linuxa u akciji.