F5 - Priority Group Activation

28.12.2023 | Tag F5

Spolu se základními balancovacími technikami F5 umožňuje nastavení záložních nodů v poolu, které odbavování provozu převezmou až v případě výpadku primárních nodů.

Teorie

Na první pohled nemusí být zřejmé, k čemu je tato funkce dobrá. Nicméně nedávno jsem měla zajímavý požadavek na nastavení balancingu na F5. Šlo o interní stránky hostované na dvou serverech, ty však nebyly rovnocenné. Jeden server byl read-write, tedy byla na něm dostupná administrace, a druhý byl read-only, kdy se na něm daly informace pouze zobrazit. Požadavek byl, aby stránky vždy obsluhoval read-write nod a teprve pokud by přestal odpovídat, aby provoz odbavoval read-only nod. Přesně pro tento případ se hodí priority group activation. (Další příklad třeba můžou být nody umístěné v různých datacentrech, kdy chceme, aby primárně obsluhovaly nody z konkrétního datacentra a další byly jen jako záloha při výpadku).

Jak to tedy teoreticky funguje.. Jednotlivým členům poolu/nodům se zadá jejich priority skupina. Čím vyšší hodnota, tím větší prioritu nod má a tím spíš odbavuje. Obráceně to znamená, že nod s hodnotou priority group 0 bude aktivní pouze v případě, kdy nody s vyšší hodnotou nebudou dostupné, nebo nebudou splňovat potřebný počet pro odbavování. Pokud mají dva nody stejnou hodnotu, jsou ve stejné skupině a odbavují společně, proto také název priority group. Priority skupin může být mnoho, reálného limitu se asi nedá v běžném provozu dosáhnout.

Teď má každý člen poolu nastavenou svou priority skupinu. Dál se v rámci poolu určí, kolik aktivních nodů musí ve skupině pro odbavování být, přičemž minimum je 1. Běžně budou odbavovat nody s vyšší priority skupinou, ale jakmile jejich počet klesne pod nastavené minimum, přidá se další skupina nodů s nižší prioritou. Takto se v případě potřeby budou přidávat další a další skupiny. Jakmile se nody s vyšší prioritou zase oživí, provoz se bude rozdělovat opět jen mezi ně. To je nastavení Priority Group Activation, které v defaultu bývá při vytváření poolu vypnuté. Zda je člen aktivní nebo ne klasicky určuje jeho stav podle přiřazeného health monitoru, případně se členové dají administrativně aktivovat/deaktivovat.

Ještě doplním, že balancovací metoda poolu se i s použitím priority group dá normálně konfigurovat, nastavení balancingu bude platit na všechny nody ze skupin, které zrovna odbavují. Toliko teorie, dále příklad, který snad bude pochopitelnější.

Příklad

Ačkoli reálný požadavek, ze kterého článek vychází, počítal s jedním aktivním a jedním backup serverem, tento příklad uděláme zajímavější. Budeme mít 4 web servery, kdy dva budou primárně odbavovat – budou mít priority skupinu 20, v našem poolu nejvyšší. Třetí a čtvrtý nod budou backup pro případ, že primární nody selžou. Tj. pokud počet aktivních nodů klesne pod dva, přidá se další skupina. Zkusíme scénář 1, kdy třetí a čtvrtý nod budou mít prioritu 10, a scénář 2, kdy třetí nod bude mít prioritu 10 a čtvrtý nod bude mít prioritu 5.

Na F5 vytvoříme úplně jednoduchý http virtual server. A protože mám omezené zdroje, reálné servery ve skutečnosti zastoupí jeden virtuální Debian s Nginxem a 4 síťovkami. Na každé síťovce bude vlastní IP adresa a na ní jednoduchá webová stránka, která pouze řekne, na kterém interface zrovna jsme.

Konfigurace

Napřed potřebujeme reálné servery, ale tím se nebudeme zatěžovat, proto jen ukážu, co je na každé IP adrese vystaveno a že Nginx nám poslouchá na 4 rozhraních. Pro F5 jde o 4 unikátní IP adresy, bude je tedy brát jako klasické samostatné nody.

Na straně F5 začneme konfigurací samotného poolu, protože ho pro virtuální server stejně budeme potřebovat. Pool vytvoříme přes levé menu a položku Local Traffic - Pools - Pool List a tlačítko Create v pravém rohu, nebo plusko v menu. Je vcelku jedno, co si zvolíme za monitoring a balancovací metodu, podstatná je pro nás položka Priority Group Activation. Zde z defaultu přepneme na Less than.. a zadáme minimální počet aktivních nodů. V našem případě chceme minimálně dva aktivní nody, proto hodnota 2.

Během přidávání členů do poolu zadáme jejich adresy (volitelně jméno), port 80, na kterém Nginx poslouchá, a hlavně vyplníme položku Priority. Na konci budou mít dva členové prioritu 20, ty budou primárně odbavovat. Pak podle scénáře budou dva zbývající členové s prioritou 10 a alternativně jeden s prioritou 10 a druhý s prioritou 5. Touto malou změnou se nám změní i výsledné chování poolu. Nastavení priority vidíme u každého člena vypsané vpravo a samozřejmě ji můžeme pod každým členem dle potřeby měnit.

Nakonec uděláme úplně obyčejný virtual server na portu 80 bez certifikátu a dalších profilů, pouze přivazbíme vytvořený pool. V reálu samozřejmě může být konfigurace VIP jakkoliv komplexní, nyní však potřebujeme jen vystavit nějakou službu.

Tím je konfigurace hotová. Výsledná služba bude při balancování vypadat nějak takto.

Testovat toto prostředí jde různými způsoby. Buďto se na straně webserveru zablokuje některá ze síťovek, nebo se na straně F5 nod administrativně vypne, což je vidět na mých screenshotech. Bohužel, testovat funkci balancingu s jedním klientským strojem jde velmi těžko, nedokážu tedy pořádně ukázat, co se po vypnutí nodu dva bude dít, ale mohu zkusit celý proces popsat.

• Na startu máme všechny 4 nody v poolu živé. Protože je nastavena Priority Group Activation, od začátku budou obsluhovat pouze dva nody ve skupině s nejvyšší prioritou 20 a zbylé čekají.

• Pokud jakýmkoliv způsobem jeden z nodů s prioritou 20 odstavíme, poruší se podmínka minimálně 2 aktivních nodů a do balancování se přidá skupina s prioritou 10. V případě prvního scénáře to jsou oba dva zbývající nody, v případě druhého jeden.

• V případě druhého scénáře máme ještě pořád v zásobě jeden nod s prioritou 5. Pokud by se odstavil další aktivní nod, došlo by i na tento poslední a začal by odbavovat také.

• Nakonec, pokud se nody s prioritou 20 vrátí do hry, budou opět odbavovat pouze ty. Zbylé nody dokončí spojení, která na nich jsou, a přejdou opět do standby režimu.

Chování poolu se dá monitorovat pomocí jeho statistik, kde je hezky vidět, které nody jsou aktivní a které čekají. Začíná se s vynulovanou statistikou a po chvilce provozu uvidíme, jak na tom jednotliví členové jsou z pohledu spojení a přenesených dat. Statistiku si můžeme podle potřeby vyresetovat.

Zde je vidět statistika pro scénář 2, kdy odbavuje jeden server s prioritou 20, druhý server se stejnou prioritou je vypnutý, třetí s prioritou 10 také odbavuje a čtvrtý s prioritou 5 čeká.

Pokud bychom se vrátili k příkladu zmíněném na začátku, konfigurace poolu by byla následovně: Activation Priority Group by mělo hodnotu Less than 1. Read-write nod by měl hodnotu 10 a read-only může mít hodnotu 0. Dokud je RW nod živý, bude odbavovat pouze on. Jakmile přestane fungovat, začne odbavovat RO nod.