Vo firmách i štátnych inštitúciách sa informačné technológie podieľajú už takmer na všetkých procesoch. Zložitosť komunikačných systémov rastie, infraštruktúra sa musí meniť stále rýchlejšie, a predovšetkým prispôsobovať aktuálnym potrebám. Riešením sú softvérovo definované dátové centrá (SD DC). Konkrétne sa dnes zameriame na komunikačné toky v dátových centrách.
ČO JE SDx A AKO DO TOHOTO KONCEPTU ZAPADÁ SD DC
Pozrime sa najprv na princíp SDx. Ak chceme niečo v tradičných dátových centrách konfigurovať, musíme každý komunikačný prvok nastavovať samostatne, zariadenie po zariadení tak, aby sme dosiahli požadované funkcionality celku. U SDx všetko vykonávame z jedného centrálneho bodu – orchestrátora. Do neho zadáme pravidlá, ktoré má daná sieť spĺňať. A centrálne riadený orchestrátor jednotlivé prvky nakonfiguruje.
Takto môžeme pristupovať napríklad k routingu a cez SD WAN orchestrátor konfigurovať, spravovať a optimalizovať prenosové trasy i medzi kontinentami. Alebo môžeme SDA orchestrátor využiť na optimalizáciu a nastavovanie užívateľských prístupov, v LAN sieťach, pokojne aj vo viac geografických lokalitách.
V prípade dátových centier nám orchestátor umožní automatizačnú konfiguráciu jednotlivých komunikačných prvkov v prostredí, ktoré môže zahŕňať jednu, ale i viac lokalít (distribučný DC). Prípadne časť dátového centra môže byť v cloude/cloudoch rôznych poskytovateľov.
U SDx je tiež podstatné, že máme oddelenú trasu pre konfiguráciu a pre dáta. V staršom legacy svete toto neexistovalo. Jednoducho povedané, v SDx svete sú prvýkrát konfiguračné vrstvy (control plane) konfiguračné trasy oddelené od tých dátových (dáta plane) prenosových. Ďalšia podstatná vec je, že sa to všetko deje z jedného miesta. Tým pádom je nám jedno, koľko zariadení v danej sieti máme – či päť alebo päťdesiat.
Úvod do legacy DC sveta
Predstavte si, že budujeme dátové centrum a chceme postaviť jednoduchú webovú aplikáciu, ktorá má nejaké logické vrstvy. Prvá vrstva aplikácie bude frontend, ku ktorému sa pripájajú ľudia z internetu. Samotné spracovávanie zabezpečuje vo väčšine prípadov druhá vrstva – backend. Tá spracováva požiadavky z frontendu a využíva vstupy z databázovej vrstvy. Takto si môžeme reálne nejakú aplikáciu predstaviť – je zložená z frontendu, backendu a databázy.
Na každú z týchto vrstiev sú kladené trochu iné požiadavky. Pri databáze sú vyžadované iné nároky z oblasti zabezpečenia, pretože do nej majú prístup len dôveryhodné systémy. Naopak frontend je otvorený do internetu. Tam musíme bezpečnostný prístup riešiť úplne inak. Aby sme v tradičnom datacentre ochránili obsah – dáta, potrebujeme zabezpečiť, aby komunikácia, ktorá na frontend prichádza, bola za sieťovým a aplikačným firewallom, a za nejakým balancerom. Máme tak tri hardvérové sieťové prvky, ktoré musíme postaviť do cesty. V štandardnom svete potrebujeme už dopredu poznať ako nastaviť príslušné VLAN, adresáciu IP adries, aby packet mohol cez tieto tri prvky prechádzať. Tým dokážeme zakázať, aby klient z internetu tieto tri prvky obišiel a rovno sa dostal na frontendový server. Môže to byť totiž potencionálny útočník, ktorý na frontendovom serveri urobí veľkú škodu.
Rozdiel medzi legacy a SDx svetom
Teraz sa dostávame k tomu podstatnému, čo legacy svet odlišuje od SDx. V SD svete, jednoducho povedané, nepotrebujeme konfigurovať jednotlivé prvky. Ukážme si to na príklade ostrovov v oceáne. Každý ostrov je súčasťou aplikácie. Máme ostrov frontend a ostrov database, napríklad z roku 2019. V súčasnosti sa rozhodneme aplikáciu aktualizovať a pribudne ďalší ostrov – backend. Aj na ňom je potreba všetko zabezpečiť – firewall, loadbalancer atď. Obrazne povedané musíme zrušiť staré plavebné trasy a vybudovať nové. Ako na to? Z jedného miesta z orchestrátora nastavím, aby sa lodička neplavila cestou internet-frontend, následne frontend-databázy. Ale trasu frontend-databázy zruším a cez orchestrátor lodičke poviem, že do databázy nebude plávať priamo, ale najprv zamieri na ostrov backend. A z neho sa vybuduje ďalšie trasa na databázu. V prípade veľkého množstva návštevníkov nám orchestrátor dokáže meniť veľkosť lodičky, aby dokázala priviesť všetkých návštevníkov (dynamické pridávanie zdrojov – server – kontajnerov). Možno sa zdá, že je to jednoduchý proces, ale ak sa dostaneme na úroveň reálne konfigurácie sieťových prvkov, tak je to veľký zásah do života daného datacentra.
Vo svete SD si danú cestu budujeme softvérovo. Len orchestrátoru zadáme príkaz, že chceme cesty takto pozmeniť a orchestátor plošne vykoná rekonfiguráciu po jednotlivých prvkoch. Administrátor pritom vôbec nemusel fyzicky do datacentra prísť, nič ručne konfigurovať, vykonávať zmeny v kabeláži, či meniť VLAN alebo IP adresovanie, smerovanie (routing) v sieti atď. Pri SD sa aj na komunikačné trasy pozeráme z pohľadu aplikácie. S tým súvisí otázka geografického umiestnenia dátových centier.
Vzdialené dátové centrá spolu komunikujú efektívnejšie
Uveďme si príklad – zákazník si vybuduje datacentrum a má ho na jednom mieste. Ak tam má kritické informácie, môže prísť povodeň či iná živelná pohroma a vznikne problém. Príde o svoje jediné datacentrum a všetky informácie. V takom prípade radšej zákazníci vykonajú to, že si vybudujú dve či viac datacentier, ktoré sú geograficky oddelené. Vzdialenosť tu nehrá rolu. Je jedno, či sú od seba 10 či 50 kilometrov.
Uveďme si príklad, v jednom datacentre nám beží aplikácia. Dôjde k živelnej pohrome a datacentrum „zhasne”. V takomto prípade potrebujeme v reálnom čase prepnúť na službu v druhom datacentre. „Zapnúť” ju nie je taký problém. Otázka je, čo urobiť s dátami? Pri klasických dátových centrách sa medzi databázami budujú samostatné dátové trasy. DB tak fungujú obrazne v jednej sieti a môžu sa synchrónne replikovať. V SD svete toto vieme zabezpečiť bez toho, aby tam musel byť fyzický prepoj. Nepotrebujeme priame prepojenie medzi dvojicou dátových centier. Môžeme využiť akýkoľvek transport, ktorý máme k dispozícii. Môže to byť internet, MPLS atď. Nad tým dokážeme dátové centrá prepojiť takým spôsobom, ako boli umiestnené v jednej sieti. Ak pôjdeme od tohto konceptu trochu ďalej, prečo by to to druhé dátové centrum nemohlo byť cloud? Tým sme chceli povedať, že softvérovo definované dátové centrum a spôsob, akým sa konfiguruje prostredníctvom orchestrátora, dokáže zabezpečiť aj prepojenie geograficky vzdialených dátových centier. A to všetko jednoducho cez bežnú IP sieť.
Aká je budúcnosť?
Vlastné dátové centrá boli predtým neefektívnymi monštrami, ktorá vyžadovali prácu množstva odborníkov. Boli navyše veľmi nákladné, takže si ich mohli dovoliť len korporácie, štátne inštitúcie či armáda. To sa postupom rokov menilo. Nástup virtualizácie serverov niekedy na prelome tisícročia bol zásadný a dátové centrá si mohli dovoliť aj menšie subjekty. V nasledujúcich desiatkach rokov nebude výnimkou, aby jeden IT špecialista spravoval pokojne tisíce serverov naraz. Na to si však budeme musieť ešte chvíľu počkať.
Softvérovo definované dátové centrum (SD DC), tiež niekedy nazývané ako virtuálne dátové centrum (VDC) je marketingový pojem, ktorý rozširuje virtualizačné koncepty, ako je abstrakcia, združovania a automatizácia, na všetky zdroje a služby dátového centra za účelom dosiahnutia IT ako služby (ITaaS) . V softvérovo definovanom dátovom centre sú všetky prvky infraštruktúry (siete, úložisko, CPU a zabezpečenia) virtualizované a dodávané ako služba.
