Terheléselosztási beállítások

A terheléselosztás kifejezés a feldolgozás több számítási erőforrás közötti elosztását jelenti. Terheléselosztással optimalizálhatja az erőforrás-használatot, maximalizálhatja az átviteli sebességet, minimalizálhatja a válaszidőt, és elkerülheti az egyetlen erőforrás túlterhelését. A terheléselosztás a számítási feladatok redundáns számítási erőforrások közötti megosztásával is javíthatja a rendelkezésre állást.

Az Azure különböző terheléselosztási szolgáltatásokat biztosít, amelyekkel több számítási erőforrás között oszthatja el a számítási feladatokat. Ezek a szolgáltatások közé tartozik az Azure API Management, az Azure Application Gateway, az Azure Front Door, az Azure Load Balancer és az Azure Traffic Manager.

Ez a cikk a számítási feladatok igényeinek megfelelő terheléselosztási megoldás meghatározásához szükséges szempontokat ismerteti.

Azure-terheléselosztási szolgáltatások

Az Azure-ban a következő fő terheléselosztási szolgáltatások és szolgáltatások érhetők el terheléselosztási képességekkel:

• Az API Management egy felügyelt szolgáltatás, amely HTTP(S) API-k közzétételére, védelmére, átalakítására, karbantartására és figyelésére használható. Átjárót biztosít az API-k számára, és konfigurálható úgy, hogy terheléselosztást biztosítsunk a csomópontok közötti forgalomnak egy kijelölt elosztott terhelésű háttérkészletben. Három különböző terheléselosztási módszer közül választhat: körkörös, súlyozott és prioritásalapú.

  Fontos

  Az API Management nem hagyományos, általános célú terheléselosztó. Kifejezetten HTTP API-khoz lett tervezve, és terheléselosztási képességei a szélesebb körű API-kezelési funkción belül választhatók. Az API Management a teljesség érdekében szerepel ebben a cikkben, mivel terheléselosztási képességeket biztosít adott API-üzemeltetési topológiákhoz. Elsődleges célja azonban az API Gateway funkciói a terheléselosztás helyett.

• Az Application Gateway egy proxy terheléselosztó. Felügyelt szolgáltatásként biztosítja az alkalmazáskézbesítés-vezérlő funkcióit. Különböző 7. rétegbeli terheléselosztást, útválasztást, TLS-kiszervezést és webalkalmazási tűzfalfunkciót kínál. A terheléselosztó megszüntetéseként 4. rétegbeli terheléselosztást is kínál a TCP- és TLS-protokollokhoz. Az Application Gateway használatával át lehet váltani a forgalmat a nyilvános hálózati területről a régión belüli privát hálózati térben üzemeltetett webkiszolgálókra.

• Az Application Gateway for Containers egy alkalmazásréteg (7. réteg) terheléselosztási és dinamikus forgalomkezelési terméke a Kubernetes-fürtön futó számítási feladatokhoz.

• Az Azure Front Door egy alkalmazáskézbesítési hálózat, amely globális terheléselosztást és helygyorsítást biztosít a webalkalmazások számára. A Layer-7 szintű képességeket nyújtja az alkalmazásnak, mint például a Secure Sockets Layer (SSL) terheléslevételét, az útvonal alapú útválasztást, a gyors feladatátvételt és a gyorsítótárazást, a teljesítmény, valamint a magas rendelkezésre állás javítása érdekében.

• A Load Balancer egy 4. rétegbeli szolgáltatás, amely az összes User Datagram Protocol (UDP) és Tcp protokoll bejövő és kimenő forgalmát kezeli. Nagy teljesítményre és rendkívül alacsony késésre tervezték. Másodpercenként több millió kérés kezelésére készült, miközben biztosítja, hogy a megoldás magas rendelkezésre állású legyen. A Load Balancer zónaredundáns, amely magas rendelkezésre állást biztosít a rendelkezésre állási zónák között. Támogatja a regionális üzembehelyezési topológiát és a régiók közötti topológiát is.

• A Traffic Manager egy DNS-alapú forgalom terheléselosztó, amely lehetővé teszi a forgalom optimális elosztását a globális Azure-régiók szolgáltatásai között, miközben magas rendelkezésre állást és válaszkészséget biztosít. Mivel a Traffic Manager egy DNS-alapú terheléselosztási szolgáltatás, a terheléselosztás csak a tartomány szintjén történik. Ezért nem tud olyan gyorsan feladatátvételt végrehajtani, mint az Azure Front Door. A DNS-gyorsítótárazás és a DNS élettartamának (TTL) értékeit figyelmen kívül hagyó rendszerek gyakran okozzák ezt a késést.

Megjegyzés:

Az klaszterezési technológiák, például az Azure Container Apps vagy az Azure Kubernetes Service (AKS), szerkezeteket tartalmaznak a terhelés elosztására. Ezek az elemek többnyire a saját klaszterhatárukon belül működnek. Készenlét és állapottesztek alapján irányítják a forgalmat az elérhető alkalmazáspéldányokra. Ez a cikk nem foglalkozik az összes terheléselosztási lehetőséggel.

Szolgáltatáskategóriák

Az Azure terheléselosztási szolgáltatásai két dimenzió szerint kategorizálhatók: globális és regionális és HTTP(S) és nem HTTP(S) mentén.

Globális és regionális

• Globális: Ezek a terheléselosztási szolgáltatások elosztják a forgalmat a regionális háttérrendszerek, felhők vagy hibrid helyszíni szolgáltatások között. Egyetlen vezérlősíkot biztosítanak, amely globálisan átirányítja a felhasználói forgalmat a rendelkezésre álló háttérrendszerekhez. Ezek a szolgáltatások reagálnak a szolgáltatás megbízhatóságának vagy teljesítményének változásaira a rendelkezésre állás és a teljesítmény maximalizálása érdekében. Ezeket olyan rendszereknek tekintheti, amelyek terheléselosztást okoznak az alkalmazásbélyegek, a végpontok vagy a különböző régiókban vagy földrajzi helyeken üzemeltetett skálázási egységek között.

• Regionális: Ezek a terheléselosztási szolgáltatások virtuális hálózatokon belüli forgalmat osztanak el virtuális gépeken (virtuális gépeken) vagy zóna- és zónaredundáns szolgáltatásvégpontokon egy régión belül. Ezeket olyan rendszereknek tekintheti, amelyek a virtuális hálózat egy régiójában lévő virtuális gépek, tárolók vagy fürtök közötti terheléselosztást teszik lehetővé.

HTTP(S) és nem HTTP(S)

• HTTP(K): Ezek a terheléselosztási szolgáltatások a 7. rétegbeli terheléselosztók, amelyek csak HTTP(S) forgalmat fogadnak el. Webalkalmazásokhoz vagy más HTTP-végpontokhoz vannak tervezve. A funkciók közé tartozik az SSL-kiszervezés, a webalkalmazási tűzfal, az elérési útalapú terheléselosztás és a munkamenet-affinitás.

• Nem HTTP(s): Ezek a terheléselosztási szolgáltatások közé tartoznak a 4. rétegbeli TCP- és UDP-szolgáltatások, illetve a DNS-alapú terheléselosztási szolgáltatások.

Az alábbi táblázat az Azure terheléselosztási szolgáltatásait foglalja össze.

Szolgáltatás	Globális vagy regionális	Ajánlott forgalom
API Management	Regionális vagy globális	CSAK HTTP(S) API-k
Application Gateway	Regionális	HTTP(S), TCP, &TLS
Alkalmazási Átjáró Konténerekhez	Regionális	HTTP(S)
Azure Front Door	Globális	HTTP(S)
Load Balancer	Regionális vagy globális	Non-HTTP(S)
Forgalomkezelő	Globális	Non-HTTP(S)

Megjegyzés:

A Traffic Manager és a Load Balancer bármilyen típusú forgalmat eloszthat, beleértve a HTTP(s)t is. Ezek a szolgáltatások azonban nem biztosítanak 7. rétegbeli képességeket. A Load Balancerrel ellentétben a Traffic Manager nem kezeli közvetlenül a forgalmat. A Traffic Manager DNS használatával irányítja az ügyfeleket a megfelelő végpontokra.

Válasszon egy terheléselosztási megoldást a forgatókönyvhöz

Terheléselosztási megoldás kiválasztásakor vegye figyelembe a következő tényezőket:

• Forgalom típusa: Határozza meg, hogy ez egy webes HTTP(S) alkalmazás, és hogy nyilvános vagy privát alkalmazásról van-e szó.

• Globális és regionális: Tisztázza, hogy egy virtuális hálózaton belül kell-e virtuális gépeket vagy tárolókat terheléselosztani, a terheléselosztási egységeket vagy a régiók közötti üzembe helyezéseket, vagy mindkettőt.

• Elérhetőség: Tekintse át a szolgáltatásiszint-szerződést (SLA).

• Költség: Figyelembe kell vennie magát a szolgáltatást, valamint az adott szolgáltatásra épülő megoldás kezelésének üzemeltetési költségeit. További információkért lásd az Azure díjszabását.

• Funkciók és korlátok: Azonosítsa az egyes szolgáltatások által támogatott képességeket és a vonatkozó szolgáltatási korlátokat.

Az alábbi folyamatábra segítségével kiválaszthatja az alkalmazás terheléselosztási megoldását. A folyamatábra végigvezeti a javaslatok elérésére vonatkozó legfontosabb döntési kritériumokon.

Jótanács

Az Azure Copilot segítségével végigvezetheti a döntésen, hasonlóan az itt ismertetett folyamatábrahoz. További információ: Az Azure Load Balancer használata a Microsoft Azure Copilot használatával.

Minden alkalmazás egyedi követelményekkel rendelkezik, nem egyszerű döntési fákban rögzítve. A folyamatábra vagy a Copilot-javaslat kiindulási pontként való kezelése. Ezután végezzen részletesebb értékelést.

A képen egy elágaztatott folyamatábra látható, amelyben minden elérési út terheléselosztási vagy alkalmazáskézbesítési megoldáshoz vezet. Az első elérési út a webalkalmazásnál (HTTP/HTTPS) kezdődik, majd a "nem" feliratú nyílon keresztül az internetre nyitott alkalmazáshoz vezet, végül a Load Balancerhez. A második útvonal a webalkalmazásban (HTTP/HTTPS) kezdődik, az Igen nyíl mentén haladva az internetre irányuló alkalmazáshoz vezet, majd a Nem nyílon keresztül a globális, több régióban üzembe helyezett alkalmazáshoz, végül az Application Gatewayhez ér. A harmadik út a webalkalmazásnál (HTTP/HTTPS) kezdődik, utána az Internetre néző alkalmazáshoz megy az Igen gomb segítségével, majd a globális, több régióban üzembe helyezett állapothoz az Igen gomb segítségével, utána az "Szüksége van teljesítménynövelésre?" kérdésnél az Igen gomb segítségével, és végül az Azure Front Door-on végződik. A negyedik út a webalkalmazásban (HTTP/HTTPS) kezdődik, az internetre irányuló alkalmazáshoz az 'Igen', globális/több régióban történő üzembe helyezés esetén az 'Igen', majd a teljesítménygyorsítás szükségessége esetén 'Nem', végül az SSL-tehermentesítés vagy alkalmazásréteg-feldolgozás kérésenkénti szükségessége esetén 'Igen' és az út az Azure Front Door és Application Gateway-nél ér véget. Az ötös út a webalkalmazásnál (HTTP/HTTPS) kezdődik, igen kapcsolat esetén az internetre irányuló alkalmazáshoz folytatódik, majd igen választás esetén a globális/több régióban üzembe helyezetthez vezet. Ha nem szükséges teljesítménygyorsítás, akkor továbblép a kérdésre, hogy szükség van-e SSL offloadra vagy alkalmazásréteg feldolgozásra kérésenként, amely esetén igen válasz után az Azure Front Door és API Management lesz az API-k kizárólagos hosztolására. A hatos út a webalkalmazásnál (HTTP/HTTPS) kezdődik, az internet-elérésű alkalmazáshoz "igen" válasszal folytatódik, majd a "globális/több régióban üzembe helyezett" lehetőséghez "igen" válasszal, utána a "Szüksége van teljesítménygyorsításra?" kérdéshez "nem" válasszal, majd a "Szüksége van SSL offload-ra vagy alkalmazásréteg-feldolgozásra kérésenként?" kérdéshez "nem" válasszal, aztán a tárhely típusához, végül a Paas esetén az Azure Front Door-ral zárul, IaaS virtuális gépek esetén az Azure Front Door és Load Balancer-ral, vagy AKS esetén az Azure Front Door és Application Gateway bejövő forgalom-vezérlővel. Minden elérési út egy vagy több Azure-szolgáltatással (Load Balancer, Application Gateway, Azure Front Door vagy API Management) fejeződik be, amelyet az alkalmazás hatóköre, a globális elérés, a teljesítményigények, az SSL-követelmények és az üzemeltetési környezet alapján választ ki.

Ha a számítási feladat több, terheléselosztást igénylő szolgáltatást is tartalmaz, egyenként értékelje ki az egyes szolgáltatásokat. A hatékony beállítás gyakran több típusú terheléselosztási megoldást használ. Ezeket a megoldásokat a számítási feladat architektúrájának különböző pontjain is beépítheti egyedi funkciók vagy szerepkörök kiszolgálásához.

Meghatározások

• A webalkalmazás (HTTP/HTTPS) olyan alkalmazásra utal, amely az alábbi képességek legalább egyikét igényli:

  • Útválasztási döntést hoz a 7. rétegbeli adatokhoz, például egy URL-címhez
  • Lehetővé teszi a kommunikációs hasznos teher, például a HTTP-kérelem törzsének ellenőrzését.
  • Kezeli a Transport Layer Security (TLS) funkcióit

• A nem HTTP(S) alkalmazás olyan alkalmazásra utal, amely 4. rétegbeli (TCP- vagy UDP-protokollok) vagy Transport Layer Security (TLS-protokoll) támogatást igényel. Az Azure Load Balancer és az Azure Application Gateway egyaránt képes kezelni az ilyen forgalmat. A funkciók és a viselkedésük azonban eltér az összehasonlítási cikkben leírtak szerint.

• Az internetkapcsolattal rendelkező alkalmazás olyan alkalmazásra utal, amely nyilvánosan elérhető az internetről. Ajánlott eljárásként az alkalmazástulajdonosok korlátozó hozzáférési szabályzatokat alkalmaznak, vagy olyan ajánlatok beállításával védik az alkalmazást, mint a webalkalmazási tűzfal és az elosztott szolgáltatásmegtagadás elleni védelem.

• A globális vagy több régióban üzembe helyezett terheléselosztónak egyetlen, magas rendelkezésre állású vezérlősíkmal kell rendelkeznie, amely a forgalmat a globálisan elosztott alkalmazás nyilvános végpontjaira irányítja. Ez a konfiguráció támogatja az aktív-aktív vagy az aktív-passzív topológiákat a régiók között.

  Megjegyzés:

  Egy regionális szolgáltatás, például az Application Gateway használatával terheléselosztást végezhet a több régióra kiterjedő háttérrendszerek között, és egyetlen vezérlősíkon vezérelheti az útválasztást. A szolgáltatás régióközi privát kapcsolattal, globális virtuális hálózati társviszony-létesítéssel vagy más régiókban található szolgáltatások nyilvános IP-címével működik.

  Nem ez a forgatókönyv a döntés elsődleges pontja.

  Ha egy regionális erőforrást használ útválasztóként a globálisan elosztott háttérrendszerekhez, regionális hibapontot vezet be. Emellett további késéssel jár, mivel a forgalom az egyik régión keresztül van kényszerítve, mielőtt egy másikba lép, majd újra visszatér.

• A szolgáltatásként nyújtott platform (PaaS) egy felügyelt üzemeltetési környezetet biztosít, ahol anélkül helyezheti üzembe az alkalmazást, hogy vm-eket vagy hálózati erőforrásokat kellene kezelnie. Ebben az esetben a PaaS olyan szolgáltatásokra vonatkozik, amelyek integrált terheléselosztást biztosítanak egy régión belül. További információ: Számítási szolgáltatás kiválasztása a méretezhetőség érdekében.

• Az AKS lehetővé teszi a tárolóalapú alkalmazások üzembe helyezését és kezelését. Az AKS kiszolgáló nélküli Kubernetes-t, integrált folyamatos integrációt és folyamatos teljesítést (CI/CD) biztosít, valamint nagyvállalati szintű biztonságot és irányítást. Ezeket az AKS-számítási feladatokat AKS-háttérrendszernek nevezzük. További információ: AKS architektúraterv.

• A szolgáltatásként nyújtott infrastruktúra (IaaS) egy olyan számítási lehetőség, amellyel a szükséges virtuális gépeket, valamint a kapcsolódó hálózati és tárolási összetevőket építheti ki. Az IaaS-alkalmazások belső terheléselosztást igényelnek egy virtuális hálózaton belül a Load Balancer használatával.

• Az alkalmazásréteg-feldolgozás egy virtuális hálózaton belüli speciális útválasztásra utal. Ilyenek például az útvonalalapú útválasztás virtuális gépek vagy virtuálisgép-méretezési csoportok között. További információ: Application Gateway üzembe helyezése az Azure Front Door mögött.

• Csak az API-k utal arra az igényre, hogy a nem webalkalmazások HTTP(S) API-jainak terheléselosztására van szükség. Ebben az esetben, ha a számítási feladat már használja az API Managementet az átjáróképességeihez, megfontolhatja az opcionális terheléselosztási funkcióját, hogy a forgalmat olyan API-háttérrendszerekre irányítsa, amelyek még nem kiegyensúlyozottak egy másik mechanizmussal. Ha a számítási feladat nem használja az API Managementet, ne használja kizárólag terheléselosztásra.

• A tartalomkézbesítési hálózat (CDN) olyan szolgáltatás, amely felgyorsítja a weblapok betöltési idejét a földrajzilag elosztott kiszolgálói hálózaton keresztül. A CDN lehetővé teszi a teljesítmény gyorsítását vagy az optimalizált belépési pontot a gyorsított ügyfélbeléptetés érdekében a célhálózatba. Az Azure Front Door támogatja a tartalomkézbesítési hálózatokat és az Anycast forgalomgyorsítását is. Mindkét funkció előnyeit az Application Gateway használatával vagy anélkül is élvezheti az architektúrában.

• Az átengedő terheléselosztó olyan terheléselosztó, amelyben az ügyfél közvetlenül létesít kapcsolatot egy háttérkiszolgálóval, amelyet a terheléselosztó terjesztési algoritmusa választ ki.

• A terheléselosztó megszüntetésekor az ügyfél kapcsolatot létesít a terheléselosztóval (proxyval), és a rendszer külön kapcsolatot kezdeményez a terheléselosztóról a háttérkiszolgálóra.

Egyéb szempontok

Minden terheléselosztási szolgáltatás rendelkezik képességtámogatással vagy megvalósítási részletekkel is, amelyeket érdemes figyelembe vennie. Íme néhány példa, amelyek relevánsak lehetnek a terheléselosztási forgatókönyvhöz:

• WebSockets-támogatás
• Kiszolgáló által küldött események támogatása
• HTTP/2-támogatás (a háttércsomópontok fogadása és folytatása)
• Ragadós munkamenet támogatása
• Háttércsomópont állapotmonitorozási mechanizmusa
• A hibás csomópontok észlelése és az útválasztási logikából való eltávolítás közötti késedelem ügyfélélményére gyakorolt hatása.

A terheléselosztó kiszervezési képességei

Az Azure néhány terheléselosztási lehetősége lehetővé teszi a képességek kiszervezését a háttércsomópontoktól a terheléselosztóig. Ezek a beállítások a Gateway Offloading felhőtervezési mintát valósítják meg. Az Application Gateway például ki tudja kapcsolni a TLS-t, így a számítási feladat nyilvánosan elérhető tanúsítványát a háttércsomópontok helyett egy helyen kezeli a rendszer. Az API Management konfigurálható arra, hogy elvégezzen néhány alapvető hitelesítési feladatot, mint például a JSON web tokenek (JWT) hozzáférési jogcímeinek érvényesítését. A keresztirányú problémák kiszervezése segíthet csökkenteni a logika összetettségét a háttérrendszerben, és javíthatja a teljesítményüket.

Példák

Az alábbi táblázat a megoldásban használt terheléselosztási szolgáltatások alapján különböző cikkeket sorol fel.

Szolgáltatások	Cikk	Leírás
Load Balancer	Virtuális gépek terheléselosztása rendelkezésre állási zónák között	A virtuális gépek terheléselosztása a rendelkezésre állási zónák között, így megvédheti alkalmazásait és adatait egy teljes adatközpont valószínűtlen meghibásodása vagy elvesztése ellen. A zónaredundancia esetén egy vagy több rendelkezésre állási zóna meghiúsulhat, és az adatútvonal addig marad fenn, amíg a régió egy zónája kifogástalan állapotban marad.
Forgalomkezelő	Többfunkciós webalkalmazás magas rendelkezésre álláshoz és vészhelyreállításhoz	A magas rendelkezésre álláshoz és vészhelyreállításhoz készült rugalmas, többtényezős alkalmazások üzembe helyezése. Ha az elsődleges régió elérhetetlenné válik, a Traffic Manager átvált a másodlagos régióra.
"Application Gateway" és API-kezelés	API Management kezdőzóna architektúrája	Az Application Gateway használatával ki lehet kapcsolni a webalkalmazási tűzfalat és a TLS-t. Az API Management használatával terheléselosztást alkalmazhat az API-háttérrendszerek között.
Forgalommenedzser és Alkalmazásátjáró	Többrégiós terheléselosztás a Traffic Managerrel és az Application Gatewayrel	Megtudhatja, hogyan szolgálhatja ki a webes számítási feladatokat, és hogyan helyezhet üzembe rugalmas több-nagyobb alkalmazásokat több Azure-régióban a magas rendelkezésre állás és a robusztus vészhelyreállítási infrastruktúra érdekében.

Következő lépések

• Nyilvános terheléselosztó létrehozása virtuális gépek terheléselosztásához
• Webes forgalom irányítása az Application Gateway használatával
• A Traffic Manager konfigurálása globális DNS-alapú terheléselosztáshoz
• Az Azure Front Door konfigurálása magas rendelkezésre állású globális webalkalmazáshoz