Ve firmách i státních institucích se informační technologie podílejí už téměř na veškerých procesech. Složitost komunikačních systémů roste, infrastruktura se musí měnit stále rychleji, a především přizpůsobovat aktuálním potřebám. Řešením jsou softwarově definovaná datová centra (SD DC). Konkrétně se dnes zaměříme na komunikační toky v datových centrech.
Podívejme se nejprve na princip SDx jako takového. Pokud chceme něco v tradičních datových centrech konfigurovat, musíme každý komunikační prvek nastavovat samostatně, zařízení po zařízení tak abychom dosáhli požadované funkcionality celku. U SDx vše provádíme z jednoho centrálního bodu – orchestrátoru. Do něj zadáme pravidla, která má daná síť splnit. A centrálně řízený orchestrátor jednotlivé prvky nakonfiguruje.
Takto můžeme přistupovat například k routing a přes SD WAN orchestrátor konfigurovat, spravovat a optimalizovat přenosové trasy i mezi kontitenty. Anebo můžeme SDA orchestrátor využít k optimalizaci a nastavování oživatelských přístupů, v LAN sítích, klidně i ve vice geografických lokalitách.
V případě datových center nám orchestrátor umožní automatizační konfiguraci jednotlivých komunikačních prvků v prostředí, které může zahrnovat jednu, ale I vice lokalit (distribuční DC). Případně část datového centra může být v cloudu/cloudech různých poskytovatelů.
U SDx je také podstatné, že máme oddělenou trasu pro konfiguraci a pro data. Ve starším legacy světě toto neexistovalo. Jednoduše řečeno, v SDx světě jsou poprvé konfigurační vrstvy (control plane)konfigurační trasy oddělené od těch datových (data plane) přenosových. Další podstatná věc je, že se to vše děje z jednoho místa. Tím pádem je nám jedno, kolik zařízení v dané síti máme – zda pět nebo padesát.
Představte si, že budujeme datové centrum a chceme postavit jednoduchou webovou aplikaci, která má nějaké logické vrstvy. První vrstva aplikace bude frontend, ke kterému se připojují lidé z internetu. Samoté zpracovávání zařizuje ve většině případů druhá vrstva – backend. Ta zpracovává požadavky z frontendu a využívá vstupy z databázové vrstvy. Takto si můžeme reálně nějakou aplikaci představit – je složená s frontendu, beckendu a databáze.
Na každou z těchto vrstev jsou kladené trochu jiné požadavky. U databáze jsou vyžadovány jiné nároky z oblasti zabezpečení, protože do ní mají přístup jen důvěryhodné systémy. Naopak frontend je otevřený do internetu. Tam musíme bezpečnostní přístup řešit úplně jinak.
Aby byl v tradičním datacentru obsah ochráněn, je nutné data zabezpečit, aby komunikace, která na frontend přichází, byla za síťovým firewallom, za aplikačním firewallom a za nějakým balancerem. Do cesty je tak nutné postavit tři hardwarové síťové prvky. Ve standardním světě se nastavují příslušné síťové prvky, a IP adresy tak, aby pakety mohly přes tyto tři prvky procházet. Tím lze zakázat, aby uživatel přes internet tyto tři prvky obešel a rovnou se dostal na
frontendový server.
Nyní se dostáváme k tomu zásadnímu, co legacy svět odlišuje od SDx. V SD světě jednoduše řečeno nepotřebujeme konfigurovat jednotlivé prvky. Ukažme si to na příkladu ostrovů v oceánu. Každý ostrov je častí aplikace. Máme ostrov frontend a ostrov database, například z roku 2019. V současnosti se rozhodneme aplikaci aktualizovat a přibude další ostrov – backend. I na něm je potřeba vše zabezpečit – firewall, loadbalancer atd. Musíme obrazně zrušiť staré plavební trasy a vybudovat nové. Jak na to? Z jednoho místa z orchestrátoru zařídím, aby lodička neplula cestou internet-frontend, následně frontend-databáze. Ale trasu frontend-databáze zruším a přes orchestrátor lodičce povím, že do databáze nebude plout přímo, ale nejprve zamíří na ostrov backend. A z něj se vybuduje další trasa na databázi. V případě velkého množství návštěvníků nám orchestrátor dokáže měnit velikost lodičky, aby dokázala přivést všechny návstěvníky (dynamické přídávání zdrojů – server – kontejnerů). Možná se zdá, že je to jednoduchý process, ale pokud se dostaneme na úroveň reálné konfigurace síťových prvků tak je to velký zásah do života daného datacentra.
Ve světě SD si danou cestu budujeme softwarově. Jen orchestrátoru zadáme příkaz, že chceme cesty takto pozměnit a orchestátor plošně provede rekonfiguraci po jednotlivých prvcích. Administrátor přitom vůbec nemusel fyzicky do datacentra docházet, nic růčně konfigurovat, provádět změny v kabeláži, či měnit VLAN nebo IP adresaci, směřování (routing) v síti atd. U SD se I na komunikační trasy díváme z pohledu aplikace. S tím souvisí otázka geografického umístění datových center.
Uveďme si příklad – zákazník si vybuduje datacentrum a má ho na jednom místě. Pokud tam má kritické informace, může přijít povodeň či jiná živelná pohroma a je problém. Přijde o své jediné datacentrum a o sto procent všechny informace. V takovém případě zákazníci provedou to, že si vybudují dvě či vice datacenter, která jsou geograficky oddělená. Vzdálenost zde nehraje roli. Je jedno, zda jsou od sebe 10 či 50 kilometrů.
Uveďme si příklad, v jednom datacentru nám běží aplikace. Dojde k živelné pohromě a datacentrum „zhasne”. V takovém případě potřebujeme v reálném čase prepnout na službu v druhém datacentru. Není problem ji tam „zapnout”. Otázka je, co udělat s daty?
U klasických datových center se mezi databázemi budují samostatné datové trasy. DB tak fungují obrazně v jedné síti a mohou se synchroně replikovat. V SD světě toto umíme zabezpečit bez toho, aby tam musel být fyzický přepoj. Nepotřebujeme přímé propojení mezi dvojicí datových center. Můžeme využít jakýkoliv transport, který máme k dispozici. Může to být internet, MPLS atd. Nad tím dokážeme datová centra propojit takovým způsobem, jako byla umístěná v jedné síti. Pokud půjdeme od tohoto konceptu trochu dale, proč by to to druhé datové centrum nemohlo být cloud? Tím jsme chtěli říct, že softwarově definované datové centrum a způsob, jakým se konfiguruje prostřednictvím orchestrátoru, dokáže zabezpečit i propojení geograficky vzdálených datových center. A to vše jednoduše přes běžnou IP síť.
Vlastní datová centra byla dříve neefektivními monstry, která vyžadovala práci řady odborníků. Byla navíc velmi nákladná, takže si je mohli dovolit jen korporace, státní instituce či armáda. To se postupem let měnilo. Nástup virtualizace serverů někdy na přelomu tisíciletí byl přelomový a datová centra si mohly dovolit i menší subjekty. V následujících desítkách let nebude výjimkou, aby jeden IT specialista obstarával klidně tisíce serverů najednou. Na to si ale budeme muset ještě chvíli počkat.
Softwarově definované datové centrum (SD DC), také někdy nazývané jako virtuální datové centrum (VDC) je marketingový pojem, který rozšiřuje virtualizační koncepty, jako je abstrakce, sdružování a automatizace, na všechny zdroje a služby datového centra za účelem dosažení IT jako služby (ITaaS). V softwarově definovaném datovém centru jsou všechny prvky infrastruktury (sítě, úložiště, CPU a zabezpečení) virtualizovány a dodávány jako služba.
We are in the process of finalizing. If you want to be redirected to our old version of web site, please click here.
