Azure od A do… – možnosti Load Balancingu v IaaS v2


Léto je za námi a klid článků je u konce! V minulém dílu  jsme si představili Infrastructrure as a Service v2, tedy vylepšené provozování virtuálních serverů, storage, sítí a všeho, co s virtuální infrastrukturu souvisí. Dnes se ve volném pokračování podíváme na možnosti balancování, protože i ty jsou ve v2 inovovány. Balancing je navíc nabízen jako služba, což je velká výhoda oproti světu tradičních balancerů z on-premise prostředí. Za balancer v Azure navíc nejsou účtovány žádné poplatky.

Balancing – jak to bylo a jak je to teď

IaaS v1 (nebo také Classic) vám z hlediska balancerů nedal moc na výběr. Ať už jedna, nebo více VM vždy dostala balancer v rámci cloud service. K VM procházela komunikace přes endpoints (v podstatě NAT) na povolených portech a na výběr byli buď balancované, nebo nebalancované endpointy. Více jsem se tomu věnoval v článku o základních možnostech sítí  (článek pro vás může být stále aktuální, protože IaaS v1 i v2 jsou k dispozici bok po boku a je možné využívat obě).

Jak jsme si říkali minule, v IaaS v2 jsou veškeré komponenty nezávislé a je možné je vytvořit, až když je potřebujeme a navázat referenci. V2 virtuály se tak zbavují závislosti na Cloud Service, veřejných IP atd.

rokos1

Obrázek 1 - Srovnání architektury IaaS v1 a v2

Jednou z těch nezávislých komponent je i Load Balancer a tak se dále podíváme, jak se s ním nyní pracuje a vše si vysvětlíme na nákresu.

Front end IP

Balancer pracuje na stejném principu a stejných konfiguracích, ať je externí, nebo interní. Jediným rozdílem je veřejná, nebo interní adresa (nebo více adres) na vstupu. Pokud budete používat externí balancing, je třeba jej referencí svázat s veřejnou IP (VIP). Pro interní balancing se hodí rezervace DIP (interní IP) a stejné možnosti balancingu jsou pak k dispozici z vnitřní sítě)

NAT rules

V těchto pravidlech lze definovat prostup na konkrétní virtuál za balancerem a komunikace po příslušném portu pak vždy bude směřována na konkrétní jeden server – tedy bez balancingu. To se nám hodí např. pro povolení vzdálené plochy (RDP), kdy chceme přesně na konkrétní virtuál.

LB Rules

LB rules definuje pravidlo balancingu. Stanovíte tedy port pro balancování a balancer vás nasměruje na některý z odpovídajících serverů v Back end poolu. Jestli server odpovídá, nebo ne posoudí Probe. Pro LB rule lze nastavit příchozí a cílový port a set virtuálů v Availability setu. Nově je nastavit Session Persistence, pokud je třeba, aby během jedné session nebyl uživatel náhodně směrován na různé servery, ale držel se toho, na kterém relace začala. Session Persistence lze svázat se zdrojovou IP klienta, nebo s IP a protokolem.

rokos2

Probe

Probe posuzuje, jestli je server schopen přijmout komunikaci z pravidla výše. Díky tomu nebude nikdy komunikace směřována na nefunkční servery, které neodpovídají. Je možné nastavit port, na kterém budou odpovědi serveru sledovány a dále interval testování komunikace v sekundách a počet neúspěšných pokusů o navázání komunikace v daném intervalu, po jehož dosažení přestane být na server směřována komunikace. Probe lze svázat s jedním a více pravidly.

Back end IP Pool

V posledním kroku definujeme Availability Set a virtuální servery v něm, na které bude komunikace směřována. Za jedním balancerem může být více poolů, pracujících s více pravidly.

rokos3

Obrázek 2 - Blade konfigurace balanceru

Závěr

Stávající možnosti balancingu byly vyzdvihnuty do IaaS v2 a přibylo několik novinek, jako Session Persistence, nebo svobodné nastavení Probe a vice pravidly pro balancované i konkrétní směřování komunikace. Balancer se zbavil závislosti na Cloud Service a je tak lépe využitelný pro Azure projekty. Za tyto možnosti se navíc nic nepřiplácí a balancer je k dispozici zdarma.

- Matouš Rokos, MVP
Mainstream Technologies

Comments (0)

Skip to main content