Azure od A do… základní síťování

Minule jsme vytvářeli naše první virtuální servery v Azure a dnes se podíváme na další veledůležitou část – sítě. Jedná se o téma poměrně bohaté, takže se nám nejspíš opět nevejde do jednoho článku, ale pojďme se do toho vrhnout a dnes si společně probere základy.

Cloud Services

S Cloud Services jsme se již setkali posledně. Sice jen okrajově, ale setkali. Když jsme vytvářeli naši VM, částí konfigurace bylo rozhodnutí o vytvoření nové Cloud Service, nebo využití stávající. Následovala specifikace DNS jména.

Tehdy pro nás bylo důležité jen to veřejné DNS jméno. Dnes se dostaneme k tomu zbytku.

Cloud Service nás nemine při každém vytváření VM. Najdete ji v menu Management portálu a je možné ji vytvořit i z přes tlačítko New. O co s tedy vlastně jedná? Cloud Service je v podstatě logickým kontejnerem pro naše virtuální servery.

Do jedné Cloud Service můžeme dát jeden a více virtuálních serverů nebo Web a Worker rolí, pokud využíváme PaaS. Rozdíl PaaS a IaaS jsem stručně představil v prvním dílu. Protože zde probíráme spíše infrastrukturní část, budeme se nadále věnovat více virtuálním serverům (IaaS). Ať už do Cloud Service umístíme VM nebo Web a Worker Role, vždy se bude jednat o virtuální server. Lišit se bude jen naše úroveň správy a šablony pro úvodní konfiguraci. Cloud Service takový virtuální server vždy ukrývá za veřejným DNS (a tedy i veřejnou IP - VIP). Server dostane i interní IP (DIP) a komunikace z veřejné sítě prochází na tu interní přes Azure firewally. V podstatě si to můžeme představit jako NAT. Tato topologie je zachována ve všech Cloud Services.

K definici portů pro prostup firewallem slouží VM Endpoint.

Endpoints

I na Endpointy jsme narazili během vytváření VM. By-default jsou vždy vytvářeny dva – pro Remote Desktop a Remote Powershell. Přidat samozřejmě můžete i vlastní a nejen při vytváření VM. Stačí kliknout na vybraný virtuál a přejít do záložky Endpoints

Přidání Endpointu je jednoduchou záležitostí. V dolní liště stačí kliknout na New a projít jednoduchým wizardem.

Nyní zvolíme Stand-Alone Enpoint. O těch loadbalancovaných si něco povíme níže. Pokračujeme na další krok a tam už nás čeká to nejdůležitější – tedy zvolení jména, protokolu a portu. Při kliknutí na jméno se rozbalí drop-down nejznámějších šablon. Lze tak snadno nastavit prostup pro často využívané protokoly jako HTTP, FTP, POP3, SMTP atd. Pokud vaše zamýšlená konfigurace není v šabloně, nic vám nebrání specifikovat vlastní jméno i port.

Pak už jen stačí vše potvrdit a za chvilku je Endpoint vytvořen.

Již existující Endpointy je možné překonfigurovat v podobném duchu jako poslední krok wizardu vytváření.

Ještě zde máme jednu zajímavou možnost konfigurace a to je specifikace Access Controll Listu. Přeci jen je komunikace na daném portu povolená z kteréhokoliv konce světa a to nemusí být zrovna žádoucí konfigurace. Specifikací veřejných subnetů lze definovat White List i Black List adres. Na RDP tak můžete přistupovat pouze z lokality vaší firmy a komunikaci na http jste schopni limitovat, když zrovna nečekáte návštěvníky z Číny. Podobných scénářů vás určitě napadne plno a ACL je naplní.

Lokální IP a Loadbalancing

O trochu výše jsem zmínil, že virtuální server má svou interní IP. V rámci jedné Cloud Service můžete mít více virtuálních serverů a tyto servery na sebe „uvidí“. Konfigurace to určitě není ideální, protože na jiné servery, v jiné Cloud Service se již nedopingáte. V Cloud Service je opravdu jen základní a automaticky definovaná síť. Nemůžete dále spravovat nebo určovat vlastní rozsahy atd. K tomu všemu a k mnohému dalšímu slouží Virtual Networks (VNETs), které si blíže představíme příště. K čemu nám je tedy takováto blízkost VM v jedné Cloud Service? K Loadbalancingu.

V momentě přidání dvou a více VM do jedné Cloud Service, jste schopni definovat takzvaný Load-Balanced Set.

Celé schéma bude vypadat takto:

Tak bude zajištěno, že už náš Endpoint nebude směřovat pouze na jednu instanci v Cloud Service, ale bude docházet k loadbalancingu na všechny instance, přidané do tohoto setu. Principiálně se jedná o Round Robin, ale je zde i rozpoznání mrtvých uzlů. Pokud nepošle server na příslušném serveru odpověď ve vámi stanoveném intervalu, nebude na něj další komunikace směrována.

Na obrázku výše definujeme, že pokud se nám minimálně dvakrát nevrátí odpověď, považujeme server za nepoužitelný pro směřování komunikace.

Scénář si můžeme snadno ověřit stopnutím site v IIS. Nejdříve na jednom a pak na druhém serveru. Případně můžete aktualizovat stránku a sledovat náhodné přepínání.

Tolik k základnímu loadbalancingu a základnímu síťování. Příště si sítě více přizpůsobíme a podíváme se právě na VNETs a další záležitosti spojené s vysokou dostupností.

Matouš Rokos, MVP
Mainstream Technologies