Hibrid felhők névfeloldása AWS-ben

Aki csak most ismerkedik a publikus felhővel, annak hasznára válhat, ha megjegyezzük, hogy hibrid felhőről akkor beszélünk, amikor a céges munkaterhelés egy része (még) a privát felhőben, a saját, vagy saját használatú bérelt adatközpontban fut, de a feladatok egy részét már valamelyik publikusfelhő-szolgáltatóra bíztuk. A két hálózat között akár VPN-nel, akár közvetlen módon – lényegében bérelt vonalasnak tekinthető – kapcsolatot alakítottunk ki.

A Route 53 Resolver alapvető működése

A Route 53 az AWS menedzselt DNS-szolgáltatása, amelyikkel névfeloldást tudunk biztosítani akár a felhőben, akár a földön futó szolgáltatásainknak, számítógépeinknek. Lényegében egy teljesen menedzselt névszervert kapunk, ahova csak a zónákat és a bennük lévő kiszolgálandó rekordokat kell fölvennünk.

Bár a név alapján mást gondolhatnánk, Route 53 Resolvernek mindössze annyi köze van „a” Route 53‑hoz, hogy ez a szolgáltatás is névfeloldással kapcsolatos. Sokáig nem is volt a Route 53 része, sőt neve sem volt. Ekkoriban nevezték +2 vagy .2 DNS-nek is, mégpedig azért, mert a VPC-kben lévő alhálózatoknak mindig a 3. címén kap helyet egy DNS-szerver. Például a 192.168.1.0/24 CIDR esetén a 192.168.1.2 címen hallgatózik DNS-szolgáltatás.

Erre a DNS-szerverre hiba volna önálló hosztként gondolni, valójában az EC2-példányok hypervisorában fut. Így történhet, hogy az EC2-példányok belsejéből a 169.254.169.253-as IP-címen is meg tudjuk szólítani, viszont az EC2-példányokon kívülről sehogy sem. Azaz ha az on-prem hálózatunkat VPN-nel vagy Direct Connect-tel összekötjük a VPC-vel, és a VPC-ben futó EC2-példányopk IP-címét ettől a „pluszkettes” DNS-szervertől szeretnénk megtudakolni, hoppon maradunk. A +2 szerver a kérésekre adott válaszokat gyorsítótárazza, és minthogy ugyanazon a fizikai gépen fut, mint az őt kérdező EC2-példány, ez a gyorsítótárazás igen hatékony.

De kitől kapja a +2 DNS a válaszokat?

Az első ábránkon az AZ-k határát jelző szaggatott vonalakkal kettészelten rajzolt Route 53 Resolver-től. Azért rajzoltuk kettészelve ezt a szolgáltatást, mert szigorúan nem egy AZ-kez kötődik, de minden AZ-ben redundánsan jelen van. Ha tőle kérdezünk, megmarad a hálózatunk AZ-izolációja, egy AZ bukása nem rántja magával a DNS-szolgáltatásunkat.

A Resolver maga három helyen tehet fel kérdéseket. Ha van privát Hosted Zone definiálva a Route 53-ban, és összekapcsoltuk (associate) az aktuális VPC-vel, és a zónára vonatkozik a kérés, akkor itt érdeklődik először. Ha felveszünk egy „.” (pont) zónát, akkor minden kérdés ide fut be. Ilyenkor az itt megadott rekordokat kiszolgálja a Route 53, a világ egyéb részeiről pedig nem fog tudni a VPC-nk.

Ha a kérés a VPC-ben lévő gépekre irányul, akkor maga a VPC adja meg a választ. Ha bármi egyébre, akkor a Resolver a publikus DNS-szervereknél érdeklődik.

Látjuk hát, hogy miként működik a névfeloldás a VPC-n belül. Lássuk, miként illeszkedik a képbe a hibrid felhők névfeloldása!

Névfeloldás hibrid felhőkben saját megoldásokkal

Ha van néhány privát zónánk a Route 53-ban, akkor szeretnénk a benne felvett címeket on-prem is feloldani. Felmerül hát az igény a resolverek közötti DNS-forwardingra, ami ugye conditional forwarding lesz: ha az on-prem hálózatunkból induló kérésben ebbe és ebbe a tartományba tartozó címről van szó, akkor azt a kérést a Route 53-mal szeretnénk feloldatni, és megfordítva. Kézenfekvőnek tűnik a megoldás: továbbítsuk a földi adatközpontból kéréseket a VPC-ben már meglévő DNS‑szerverhez.

Akármilyen kézenfekvő, tudjuk, hogy ez azért nem lesz járható út, mert a VPC-kben automatikusan létrejövő DNS‑szerver csak az EC2-k számára létezik. Csak a fizikai gép hypervisorában látható, csak annak a hypervisornak a gépei tudnak szólni hozzá. A probléma visszafelé is fennáll: ha a felhőbéli gépeknek kell földi címeket feloldani, jó volna, ha a +2 resolvernek elmondhatnánk, hogy a földi tartományba tartozó címeket érintő kéréseket továbbítsa a földi DNS-szervereinkhez.

Erre bő két évvel ezelőttig nem volt lehetőség. A szokásos megoldás az volt – és sok-sok régebben kiépített alhálózat mind a mai napig így üzemel –, hogy egy-egy EC2 került az alhálózatba, rajta DNS-szerver alkalmazással. Ezek ugye EC2-k, azaz tudnak beszélni a +2 resolverrel. Az on-prem resolverre felvettük azokat a továbbítási szabályokat, amelyek a felhős privát zónákhoz tartozó kéréseket a DNS-szervert futtató EC2-k felé továbbították. Az EC2-n futó DNS-szerverre, ami például lehetett egy hétköznapi BIND is, felvettük azokat a továbbítási szabályokat, amik a földi tartomány neveit érintő kéréseket a földi DNS-szerverhez továbbították. Az utolsó lépés pedig az volt, hogy a VPC DHCP-beállításait úgy módosítsuk, hogy DNS-szerverként a BIND-et futtató EC2-t kapják az induló gépek.

A rendszer működött, de ez a DNS-szervert futtató gép természetesen egyszerre volt szűk keresztmetszet és az egész architektúra gyenge pontja, egy igazi nagykönyves SPOF, Single Point of Failure. A helyzeten csak némileg javított, ha minden AZ megfelelő alhálózatába került egy-egy DNS-szerver szerepű EC2‑példány, és mindet elhelyeztük a VPC-k DHCP-szervereivel megadott DNS-szerverek listájában.

Színre lép a Route 53 Resolver Endpoints szolgáltatás

A Resolver Endpoints az előző részben vázolt helyzet hibatűrő és skálázható megoldását célozza. Amikor az addig névtelen resolver szolgáltatás kiegészült a resolver végpontokkal, megkapta a mai nevét: Route 53 Resolver. Végpontból kétféle van: inbound, ami a VPC-be érkező DNS-lekérdezéseket fogadja, és outbound, ami a VPC‑ből kiinduló lekérdezéseket továbbítja az on-prem DNS-szerverhez.

Az Inbound végpont

Az inbound forgalomnak a +2 resolverrel kellene beszélnie, ami ugye nem megy – ezt már tudjuk. Azonban a Resolver Endpoints üzembe állításakor olyan ENI-k kerülnek a VPC-be, amik már elérhetők on-prem oldalról is, a VPC-hez vezető Direct Connect vagy VPN-kapcsolaton keresztül. Figyeljünk a szóhasználatra: egy végpont több ENI-t jelenthet. Egyetlen ENI 10.000 lekérdezést fogadhat minden másodpercben. A pontos kvótákról lásd az AWS-dokumentációt. Egy Route 53 Resolver végpont minden ENI-je után egynyolcad dollárt fizetünk óránként.

Ahogy azt már megszokhattuk, ha magas rendelkezésre állásra van szükség, több AZ-be telepítjük az alkalmazásunkat. Ilyenkor ne feledjünk minden AZ-ben Resolver Endpoint ENI-t elhelyezni. És bár van lehetőség arra, hogy az összes on-prem hosztunk közvetlenül forduljon a névfeloldó végpont ENI-jéhez, ez – alighanem sejtjük – nem optimális, sem adminisztratív szempontból, sem a helyi gyorsítótárazás hiányából eredő lassulások miatt. Már csak ezért is érdemes on-prem oldalra egy dedikált forwardoló DNS-szervert telepítenünk.

Az ENI-k védhetők Security group-okkal, és, minthogy VPC-ben vannak, vonatkozik rájuk a VPC, illetve az alhálózat Network Access Control List-je is. Állítsuk be ezeket igényeinknek megfelelően!

Ahogy az előbb hivatkozott weboldal is javasolja, érdemes a másodpercenkénti terhelésre CloudWatch-riasztást állítani. Nem utolsósorban azért állunk mi is ki e mellett az ötlet mellett, mert a Resolver Endpoint üzembe állításnak megvan az a veszélye, hogy nem lesz többé bajunk a névfeloldással. Ez baj? Hát, abban az értelemben, hogy egy-két év (hét?) alatt elfelejtjük, hogy egyáltalán a világon van, olyan természetes a működése, igen. És amikor már réges-rég azt sem tudjuk, hogy van ilyenünk beállítva, egyszer csak elkezd ez-az nem működni, mert kinőttük az említett limitet. Jobb, ha erről időben kapunk értesítést.

Kitérnénk még néhány, a bejövő végpontokkal kapcsolatos jó gyakorlatra:

Mi az a küszöbérték, amit átlépve értesítést akarunk kapni? Az AWS nem győzi hangsúlyozni, hogy nem az a kérdés, hogy lesz-e meghibásodás, csak az, hogy mikor. Ez részint jó üzlet nekik – több erőforrást üzemeltetünk, mint amennyire szigorúan véve szükségünk van –, részint meg igazuk van. Úgyhogy ha van két AZ-nk egy-egy ENI-vel, amik egyenként folyamatosan 5001 kérést kapnak másodpercenként, akkor az egyik ENI kiesésével probléma támad, és a másik nem tudja elvinni a terhelést. Ezt vegyük figyelembe a riasztási határ megállapításakor.

Használjuk-e az inbound endpointot az EC2-példányinkról is? Ne, inkább maradjunk a +2 resolvernél, mert

• nem teszünk vele még egy alkatrészt a láncba, ami ugye meghibásodhat,
• nem számítanak bele a végpont kvótájában az ide érkező kérések,
• megmarad az AZ-k önálló működése, az AZ-izoláció,
• nem fizetünk az AZ-k közötti forgalomért,
• ez ugye mégiscsak ott van a hypervisoron, ami gyorsaságot jelent.

Kell-e több VPC-hez több végpont is? Általában nem, ha a VPC-ink között peering kapcsolat van vagy Transit Gateway-t üzemeltetünk, mert:

• megtehetjük, hogy a hub-VPC kapja meg az összes privát Hosted Zone-t,
• így elég egy Direct Connect vagy VPN, és elég egy Resolver végpont is,
• az EC-példányok nevei pedig feloldódnak a VPC-k határain túl is.

Az Outbound végpont

Ahogy már említettük, az Route 53 Resolver Outbound endpoint a VPC‑ből kiinduló lekérdezéseket továbbítja az on-prem DNS-szerverhez. Lényegében olyan forrás-ENI-ket hozunk létre, amelyek az on-prem végre érkező kérések kiindulópontjai. Ugye észrevettük, hogy ezúttal is több ENI-ről lehet szó? Az egyes ENI-k terhelési határa ugyanaz a 10.000 kérdés másodpercenként, amit a bejövő végpontoknál már láttunk. Egy végpontot több VPC is használhat, de erről még ejtünk szót.

A kimenő végpontokkal kapcsolatos jó gyakorlatokról szólva elmondjuk, hogy

• szokás szerint érdemes a végpontot két AZ-ben kialakítani;
• bánjunk takarékosan a forwardinggal – csak azt forwardoljuk, amit mindenképp szükséges, hogy minél egyszerűbb és rövidebb legyen minél több csomag útja;
• az előbb megismert okok miatt érdemes riasztást állítani a csomagok számára, hogy ne akkor kelljen debuggolni és kapkodni, amikor már fellépett a baj.

A kimenő végpont és a névfeloldási szabályok

A végpont elhelyezésével még csak kapcsolati szinten kezeltük a névfeloldás problémáját, lévén a Resolvernek nem mondtuk meg, hogy használja is ezt a kapcsolatot. Így aztán továbbra is minden bejövő kérés a Resolver „mögött” álló három lehetőség valamelyikéhez irányul (lásd az ábra jobb oldalát).

A névfeloldási szabályok mondják meg, hogy a DNS-kérésre az egyes esetekben hol keresse a Resolver a választ. Resolver Rule-ból kétféle van: FORWARD és SYSTEM. Míg az utóbbival arra utasítjuk a Route 53 Resolvert, hogy a „hagyományos” lehetőségei alapján próbálja megválaszolni a DNS-kérést, a FORWARD-dal azt mondjuk meg, hogy melyik – általában on-prem – szerverhez továbbítsa a kérést.

Ha van egy központi VPC-nk, amelyik a névfeloldásért (is) felel, akkor ott helyezünk el végpontot, és beállítjuk, hogy a szabályok a többi VPC-re is érvényesek legyenek. Látjuk tehát, hogy nem szükséges sok végpontot üzemeltetnünk. Az AWS is arra számít, hogy ezt az eljárást követjük, amikor régiónként négy végpontot engedélyez – bár ez úgynevezett soft kvóta, azaz ha kérjük, akkor engednek többet. A végpontot nem kell megosztanunk a többi VPC-vel, esetleg más AWS‑accounttal, elegendő, ha a szabályokat megosztjuk. A szabályok megosztása maga után vonja a végpont megosztottá válását is.

Ha átfedő szabályokat alakítunk ki, akkor – ahogy arra talán számítunk is – a legspecifikusabb szabály nyer. Ha van külön DNS-szerver a telephely.ceg.hu és a ceg.hu számára, akkor a gep1.telephely.ceg.hu címet az első, míg a webszerver.ceg.hu címet a második szabály alapján igyekszik feloldani a Route 53 Resolver.

A pontosabb specifitást követő második alapelv, hogy a FORWARD-szabályok prioritása nagyobb, mint a SYSTEM-szabályoké. Hiába hoznánk létre egy „.” zónát a privát Hosted Zones részen, a FORWARD-szabályok már korábban „elviszik” a kérést az on-prem-szervereinkhez.

Ha esetleg valamilyen céges előírás miatt a „.” zónára irányuló kéréseket is elforwardoljuk az on-prem DNS-szerverekhez, akkor jó ha tudjuk, hogy ezzel viszont nem bíráljuk felül a VPC DNS-t és a privát Hosted Zones részen rögzített címek felé induló kéréseket. Van ugyanis néhány automatikusan definiált SYSTEM-szabály, amelyek a „.” zónán túl tartalmazzák

• a régió.compute.internal,
• a régió.compute.amazonaws.com,
• a VPC-ben használt tartomány reverse zónái,
• és a VPC CIDR alatt lévő lévő minden /24-es tartomány felé irányuló kérések szabályát.

Ezek a szabályok természetesen felülbírálhatók, de ha nem bíráljuk felül, akkor specifikusabbak mint a „.”, és nyernek – tehát a fenti címekre vonatkozó kéréseket az AWS saját szerverei oldják fel. Ha a FORWARD feloldási szabályok közé felvesszük ezeket a zónákat is, akkor a specifitás azonos, de a FORWARD-lánc nagyobb prioritása miatt már az ott megadott szerverekhez fot be a kérés.

A fenti szabályok nem bírálják felül a FORWARD-szabályoknál megadott „.”-t egyéb esetekben, hiszen a specifitás azonos, de ezek SYSTEM-szabályok, azaz alacsonyabb prioritásúak. Így, ha a felhőben a thesmart.academy címet szeretnénk feloldani, akkor már nem a publikus DNS-szolgáltatótól kérdez a Route 53 Resolver, hanem az on-prem DNS‑szervertől.

Az egyszeri AWS-üzemeltető arra tippelhet, hogy akkor nyilván VPC-peering kapcsolaton vagy Transit Gateway-en át vezet a csomagok útja, de téved. A csomagok VPC-n belül eljutnak a Route 53 Resolverig, az meg tudja, hogy merre van a kimenő végpontja, és arrafelé indítja a továbbított lekérdezést. Sem VPC-peeringre, sem Transit Gateway-re nincs tehát szükség a névfeloldás vázolt módon történő üzemeltetéséhez – de természetesen, ha más okból szükség van valamelyikükre, a meglétük nem okoz gondot.

Aki Microsoft Active Directory-t – akár az AWS menedzselt AD-jét, akár saját üzemeltetésűt, akár az AWS-féle Simple AD-t – üzemeltet az AWS felhőjében, annak különösen jól jöhet a névfeloldó végpontok használata. A probléma ugyebár abban rejlik, hogy az MS AD szereti, ha a tartományának neveit ő maga oldhatja fel. A végpontok megjelenésééig a bevett gyakorlat a saját üzemeltetésű névszerverekére hasonlított, azaz elhelyeztük a VPC DHCP-jében névszerverként az Active Directory szerverének címét, és onnantól minden kérés ezen az EC2-példányon át történt. A névfeloldó szabályok használatával viszont megtehetjük, hogy csak az AD-tartományba eső címekre vonatkozó kéréseket továbbítjuk az AD-szerverekhez. Vegyük észre, hogy az Outbound végpontot ez esetben olyan lekérdezéshez használjuk, ami végső soron nem hagyja el az AWS hálóját, és vegyük észre azt is, hogy így lehet módunk egy AD-szerverrel több, egyébként hálózati kapcsolattal össze nem kötött VPC-t is ellátni. A módszernek az az előnye is megvan, hogy a jó öreg +2 gyorsítótárazza a lekérdezések eredményét.

Elég sok mindent áttekintettünk. Röviden:

• láttuk, miként működik a +2 resolver egy olyan VPC-ben, ahol semmit nem alakítottunk az alapértelmezett beállításokon, és láttuk, hogy egyedül a +2 resolver miért kevés, ha hibrid felhőt üzemeltetünk;
• láttuk, hogy miként oldható meg a hibrid felhős névfeloldás saját eszközökkel, de azt is, hogy mik a saját eszközös megoldás buktatói, és végül
• láttuk, hogy miként segít a helyzeten a névfeloldó végpontok használata.

Elméletileg mostanra nagyon okosak vagyunk, itt az idő, hogy mindezt a gyakorlatban is kamatoztassuk. Sok sikert mindenkinek a Route 53 Resolver használatához!