Tipični problemi datacentara

Pojava personalnih računara je izazvala pravu revoluciju, ne samo u obradi podataka, nego i u svakodnevnom životu. Njihova modularna priroda, mogućnost da se u potpunosti izabere konfiguracija i količina ugrađenih resursa, omogućila je da svako može nabaviti računar skladu sa zahtjevanom namjenom, performansama, prenosivošću i cijenom. Tehnologija i performanse su napredovale, cijena je padala, i danas gotovo da nema doma koji nema makar jedan računar – desktop, laptop, u novije vrijeme tablet ili moćan mobilni telefon, koje takođe možemo smatrati za računare specifičnog načina upotrebe. Opštoj kompjuterizaciji društva je doprinio i gotovo paralelan razvoj Interneta i raznih mrežnih usluga zasnovanih na njemu. Postalo je moguće raditi od kuće, uz djeljenje podataka u svakom trenutku, sa svakog uređaja, preko mreže na koju smo maltene svi povezani, često i 24 sata dnevno. Sve je to uzrokovalo raširenost x86 tehnologija i aplikacija, koje se u ogromnoj većini produkcija danas koriste.

Ispostavilo se da decentralizacija kompjuterskih resursa i veliki broj kompjutera (prije svega servera) koji izvršavaju operacije, koliko god revolucionarna bila, počinje da uzima svoj danak.

Kompanije sve više moraju da prilagode svoje poslovanje, i sve više i više rade na unapređenju svojih datacentara. Datacentar je, tipično, lokacija sa svom pratećom infrastrukturom – prostor, serveri, mrežna oprema, itd. – na kojoj se vrte i obrađuju kompanijski podaci. Potrebno je obezbjediti dovoljno kompjuterskih resursa za opsluživanje sve većeg broja korisnika i sve veće količine podataka. Pružanje usluga 24 sati dnevno, 7 dana u nedjelji su postale uobičajene za razne pružaoce usluga koji žele iskoristiti potencijal Interneta; server koji izvršava uslužni servis mora biti dostupan i van kompanijskog radnog vremena kao i tokom noći, zbog mogućnosti pristupa korisnika koji žive i rade u drugim vremenskim zonama. Ispostavilo se da decentralizacija kompjuterskih resursa i veliki broj kompjutera (prije svega servera) koji izvršavaju operacije, koliko god revolucionarna bila, počinje da uzima svoj danak. Tipični izazovi decentralizovanih sistema  postali su često nepremostiv problem:

Razasutost podataka. Podaci su razbacani po serverima. Brojne servere (i radne stanice) je postalo sve teže pojedinačno bekapovati. Nadalje, u slučaju pada servera njegovi podaci ostaju „zarobljeni“ i nedostupni sve do oporavka servera. Zato je bolje uvesti neki centralni bekap sistem ili uređaj na koji se svi ključni serveri bekapuju u regularnim intervalima. Tako, u slučaju pada servera, imamo bar dostupne njegove podatke. Ostaje problem sporog oporavka servisa, jer je prije svega vraćanje podataka iz bekapa relativno sporo, i moramo imati spreman server na koji ćemo restaurirati podatke i na njemu pokrenuti čitavo to vrijeme nedostupan servis. Mnoge se kompanije zato odlučuju da nabave neki storage sistem – centralnu lokaciju na kojoj drže aktivne, produkcione podatke, a ne (samo) zbog bekapa. Bekap je i naravno dalje obavezan – prije svega, šta da radimo u slučaju otkaza storage sistema, na kome su maltene svi naši podaci „na gomili?“ U svakom slučaju, današnji storage sistemi omogućavaju paralelan, brz pristup (istim) podacima od strane više servera, što uvećava dostupnost servisa koji se vrti na serverima; naime, u slučaju otkaza nekog servera drugi može automatski preuzeti posao jer su mu podaci dostupni, i maltene nema primjetnog zaustavljanja servisa – tzv. klaster mod (cluster). Namjerno pominjemo storage sistem, jer ćemo kasnije vidjeti da je njegovo postojanje maltene obavezno za ostvarivanje punog potencijala virtuelizacije.

Prisutan je veliki broj slabo opterećenih servera, čije resurse ne možemo dostaviti nekim drugim servisima koji rade sporo, zatvoreni na svojim serverima ograničenih resursa.

Neravnomjerna upotreba i razasutost dostupnih kompjuterskih resursa. Potreba za velikim brojem servera dovela je do pojave, istovremeno, maltene neopterećenih i preopterećenih servera. Naime, veliki broj servera je, razumljivo, potreban zbog porasta broja korisnika, veće količine podataka koja se obrađuje, a kako bi se odziv sistema održao na razumnom nivou. Međutim, potreban je i zbog redundanse servisa, kako bi u slučaju pada jednog servera servis bio dostupan preko drugog; kao i zbog preporučene podjele „jedan server – jedan servis“ jer u slučaju pada jednog servisa ili bug-a u njemu postoji mogućnost da padne čitav server, pa samim tim i svi preostali njegovi servisi. Povrh svega, mnogi veoma važni servisi ne zahtjevaju previše resursa. Dakle, prisutan je veliki broj slabo opterećenih servera, čije resurse ne možemo dostaviti nekim drugim servisima koji rade sporo, zatvoreni na svojim serverima ograničenih resursa. Uzmimo kao primjer domen kontroler. Da se podsjetimo, karakteristika mreže organizovane u obliku domena je da postoji centralno mjesto (server, tj. domen kontroler) na kome se prije svega vrši autentikacija (tj. provjera identiteta korisnika koji se loguje na mrežu, odakle god da se loguje), autorizacija (provjera ima li (autentikovan) korisnik pravo da izvrši akciju koju pokušava izvesti – na mreži, kompjuteru na kome je logovan, na nekom drugom kompjuteru, štampaču, itd.) kao i mnogobrojne dodatne operacije (npr. centralizovano podešavanje svih računara i servera u mreži, definisanje aktivnosti koje korisnik smije ili ne smije izvesti, itd.) Ukratko, domen kontroler je jako važan server; u slučaju njegove nedostupnosti pojaviće se mnogobrojni problemi (nemogućnost logovanja korisnika, pristupa resursima, itd). Zato je potrebno imati makar dva domen kontrolera, i na tim serverima je apsolutno poželjno ne podizati neke druge servise, kako neki problem u njima ne bi doveo problema sa domenskim servisima, samim tim i mrežnim pristupom. S druge strane, domen kontroler najčešće nije hardverski pretjerano zahtjevan, pogotovo u okruženjima sa manjim brojem računara i korisnika; dakle, relativno mnogo neiskorištenih hardverskih resursa. U isto vrijeme, neki drugi server (recimo, neki database server) radi sporo jer nema dovoljno resursa.

Ulaganje u servere sa maksimalnom redundansom može biti ogromno, a, s druge strane, ne garantuje 100% dostupnost servera.

Neplanirano i planirano gašenje servera (unplanned/planned downtime). Potrebno je što više smanjiti mogućnost nedostupnosti servera zbog fizičkog otkaza nekih komponenti. Zato serveri često moraju imati duple komponente, kako zbog boljih performansi zbog paralelnog korištenja, tako i zbog omogućavanja nesmetanog rada u slučaju otkaza jedne od komponenti iz para. Tu se u prvom redu misli na dva napajanja, dvije mrežne kartice, dva Host Bus Adaptera (HBA) za vezu prema (Fibre Channel, FC) storage sistemima, više hard diskova, i slične duplirane komponente koje relativno često otkazuju. Na skupim serverima neke ili sve navedene komponente se mogu zamijeniti čak i dok server radi, dok još skuplji podržavaju i „naživo“ zamjenu procesora i memorije. Ulaganje u servere sa maksimalnom redundansom može biti ogromno, a, s druge strane, ne garantuje 100% dostupnost servera u slučaju otkaza bilo koje komponente, pošto uvijek postoje neka čija neispravnost uzrokuje pad servera – tu se u prvom redu misli na matičnu (sistemsku) ploču, backplane sa izvedenim konekcijama između komponenti, itd. Osim neregularnog gašenja servera (uslijed njegovog otkaza, npr), često se ukazuje potreba i za regularnim gašenjem ili restartom servera, npr. zbog nadogradnje hardvera, drajvera, instalacija patch-eva, itd. I u tom slučaju, kao i u slučaju neregularnog gašenja, servisi na serveru su nedostupni sve dok server ne vratimo „online.“ Treba navesti i problem otkaza starih servera za koje nema rezervnih djelova, a servisi na njima nisu predviđeni da rade na novim serverima i operativnim sistemima.

Uvođenje novih servisa, proširenje kapaciteta postojećih servisa, podrška starim (legacy) servisima. Čak i kad ne uzimamo u obzir često veliki vremenski period potreban za nabavku novog servera i obezbjeđivanje potrebne infrastrukture, potrebno ga je instalirati, pravilno konfigurisati, testirati, i, konačno, pustiti u produkciju. Takođe, problem mogu praviti stare (legacy) aplikacije i operativni sistemi, koje često neće raditi na novom hardveru, tako da ostaje često dugotrajan proces migracije poslovnih aplikacija na nove hardverske i softverske platforme.

Infrastrukturni problemi. Često se zapostavlja činjenica da svaki server zahtjeva svoj dio infrastrukture: prije svega prostor, napajanje, hlađenje, mrežne konekcije, administraciju, fizičko obezbjeđivanje. Potrebno je unaprijed provjeriti da li postojeći kapaciteti zadovoljavaju neminovan porast infrastrukturnih zahtjeva, od naizgled banalnih tipa ima li dovoljno mjesta u serverskom ormaru za server, dovoljno utičnica, kablova, itd. pa sve do teško rješivih problema nedovoljnog kapaciteta postojeće infrastukture koja ne dozvoljava novim serverima da se odazivaju dovoljno brzo na poslovne zahtjeve, i, paradoksalno, dobijemo usporenje čitavog sistema.

U daljnjem tekstu ćemo vidjeti osnovne principe na kojima je zasnovana virtuelizacija, i kako ona, ako potpuno ne ukloni, prilično ublažava pomenute i mnoge druge probleme. U svakom slučaju, daje novi ugao gledanja i nove ideje definitivno vrijedne razmatranja.

Osnovna ideja virtuelizacije

Na trenutak se zapitajmo „šta bi bilo kad bi bilo:“ Šta bi bilo kad bi naš server bio fajl? Fajl koji se „otvara,“ „čita,“ „edituje“ na nekom specijalno namijenjenom (fizičkom) serveru? Šta sve možemo da radimo sa fajlovima? Možemo da ih editujemo, snimamo. Možemo da ih kopiramo, čak i sa jednog računara na drugi, nezavisno od hardvera, samo je važno da svaki računar ima instaliranu aplikaciju koja može da otvori i „konzumira“ taj fajl. Kad nam više ne treba, možemo ga obrisati. Zvuči kao naučna fantastika, ali, osnovna ideja na kojoj se zasniva virtuelizacija i iz koje proizlaze sve njene mogućnosti je pretvaranje stvarnog, fizičkog kompjutera u fajl (zapravo, kolekciju fajlova). I sa tom kolekcijom možemo da radimo maltene sve što možemo sa regularnim fajlovima.

                Kako je to moguće? Možda je najbolje dati odgovor na pomenuto pitanje kroz analogiju funkcionisanja neke korisničke aplikacije. Kako npr. radi neka aplikacija za obradu teksta? Startujemo aplikaciju, kreiramo dokument, u njega unosimo tekst, slike, formule, podatke različitog tipa… Sve te operacije se izvršavaju koristeći hardver računara; u prvom redu procesor i memoriju, ali aplikacija može prihvatati unos podataka sa tastature, miša, touch ekrana ili nekih drugih netipičnih uređaja, prikazati dokument na ekranu ili poslati ga na štampu ili nekome e-mail-om, snimiti na hard disk, itd. Po potrebi, možemo otvoriti snimljen dokument, pročitati ga, eventualno izmjeniti, snimiti promjene. Naravno, možemo kreirati više dokumenata različitog sadržaja, čak i različitog tipa podataka (jedan dokument sa tekstom, drugi sa slikama, treći sa tabelama, itd.) a iz nekog razloga, ti dokumenti mogu biti grupisani (npr, pripadaju nekom projektu, razni podaci o nekoj osobi, itd.) Također, možemo raditi sa više dokumenata paralelno.

Analogija između rada sa dokumentima i rada sa virtuelnim mašinama je sljedeća:

  • Virtuelnu mašinu možemo posmatrati kao kolekciju dokumenata različitog tipa, sadržaja i formata podataka
  • Virtuelizacioni softver, odn. hypervisor je „aplikacija za obradu“ virtuelnih mašina
  • Host je fizički server na kome radi (na kome je instaliran) hypervisor
  • Kreiranje virtuelne mašine se svodi na kreiranje pripadajuće grupe fajlova na hostu
  • Startovanje virtuelne mašine se svodi na na nekoliko operacija tipa otvaranje pripadajućih fajlova po predefinisanom redoslijedu, njihovo čitanje, editovanje, učitavanje sadržaja u memoriju, itd.

Osnovna ideja je da, umjesto da koristimo određen broj fizičkih servera (sa instaliranim operativnim sistemima), kroz implementaciju virtualizacije obezbjedimo mogućnost pokretanja više (virtuelnih) servera (svaki sa instaliranim operativnim sistemom) koji se paralelno vrte na jednom hostu i koriste njegove hardverske resurse, ali međusobno potpuno izolovano. Naime, i fizički serveri u realnosti koriste svaki svoj hardver međusobno potpuno izolovano – npr. neispravna memorija jednog servera neće oboriti drugi server, niti server direktnim pristupom svom hardveru može da ometa drugi server dok pristupa svojim lokalnim hardverskim resursima. Za svaku virtuelnu mašinu je potrebno rezervisati određenu količinu hardvera fizičkog servera isključivo za njene potrebe: tj. izdjeliti kompletan hardver servera u potpuno izolovane cjeline (od kojih svaka sadrži određen broj procesora, određenu količinu memorije, prostor na disku, određen broj mrežnih kartica, itd.) a svaka cjelina je vidljiva kao nezavisan računar.

U narednim člancima slijedi detaljnija razrada osnovnih principa na kojima je zasnovana virtuelizacija.

[mc4wp_form id=”736″]