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.
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.
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.
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