Megosztás a következőn keresztül:

Architekturális megközelítések a hálózatkezeléshez több-bérlős megoldásokban

  • Cikk

Az Azure-ban üzembe helyezett összes megoldáshoz valamilyen hálózatkezelésre van szükség. A megoldástervtől és a számítási feladattól függően az Azure hálózati szolgáltatásaival való interakció módja eltérő lehet. Ebben a cikkben megfontolandó szempontokat és útmutatást nyújtunk az Azure-beli több-bérlős megoldások hálózatkezelési szempontjaihoz. Az alacsonyabb szintű hálózatkezelési összetevőkről, például a virtuális hálózatokról a magasabb szintű és az alkalmazásszintű megközelítéseken keresztül információkat is tartalmazunk.

Feljegyzés

Maga az Azure több-bérlős környezet, és az Azure hálózati összetevőit több-bérlős használatra tervezték. Bár a saját megoldás megtervezéséhez nem szükséges tisztában lenni a részletekkel, többet is megtudhat arról, hogy az Azure hogyan elkülöníti a virtuális hálózati forgalmat más ügyfelek forgalmától.

Főbb szempontok és követelmények

Infrastruktúra- és platformszolgáltatások

A hálózatkezelési összetevőkkel kapcsolatos aggodalmak a használt szolgáltatások kategóriájától függően eltérőek lesznek.

Infrastruktúra-szolgáltatások

Amikor olyan infrastruktúra-szolgáltatásokat használ, mint a virtuális gépek vagy az Azure Kubernetes Service, meg kell fontolnia és meg kell terveznie a virtuális hálózatokat vagy virtuális hálózatokat, amelyek támogatják a szolgáltatások kapcsolatát. Figyelembe kell vennie a többi biztonsági és elkülönítési réteget is, amelyeket be kell építenie a tervezésbe. Ne támaszkodjon kizárólag a hálózati réteg vezérlőire.

Platformszolgáltatások

Ha az Azure platformszolgáltatásait, például az App Service-t, az Azure Cosmos DB-t vagy az Azure SQL Database-t használja, akkor a használt architektúra határozza meg a szükséges hálózati szolgáltatásokat.

Ha el kell különítenie a platformszolgáltatásokat az internettől, virtuális hálózatot kell használnia. A használt szolgáltatásoktól függően előfordulhat, hogy privát végpontokkal vagy virtuális hálózattal integrált erőforrásokkal, például az Application Gatewayrel dolgozik. Azonban dönthet úgy is, hogy a platformszolgáltatásait elérhetővé teszi a nyilvános IP-címükön keresztül, és a szolgáltatások saját védelmét, például tűzfalakat és identitásvezérlőket használ. Ilyen esetekben előfordulhat, hogy nincs szüksége virtuális hálózatra.

A virtuális hálózatok platformszolgáltatásokhoz való használatának eldöntése számos követelményen alapul, beleértve a következő tényezőket:

  • Megfelelőségi követelmények: Előfordulhat, hogy meg kell felelnie egy adott megfelelőségi szabványnak. Egyes szabványok megkövetelik, hogy az Azure-környezet meghatározott módon legyen konfigurálva.
  • A bérlők követelményei: Még ha a saját szervezete sem rendelkezik a hálózati réteg elkülönítésére vagy vezérlőire vonatkozó konkrét követelményekkel, előfordulhat, hogy a bérlők. Győződjön meg arról, hogy tisztában van azzal, hogy a bérlők hogyan férhetnek hozzá a megoldáshoz, és hogy rendelkeznek-e a hálózat kialakításával kapcsolatos feltételezésekkel.
  • Összetettség: Összetettebb lehet a virtuális hálózatok megértése és működése. Győződjön meg arról, hogy a csapat tisztában van az érintett alapelvekkel, vagy valószínűleg nem biztonságos környezetet fog üzembe helyezni.

Győződjön meg arról, hogy tisztában van a magánhálózat-használat következményeivel.

Alhálózatok méretezése

Ha virtuális hálózatot kell üzembe helyeznie, fontos, hogy gondosan mérlegelje a teljes virtuális hálózat és a virtuális hálózaton belüli alhálózatok méretezési és címterét.

Győződjön meg arról, hogy tisztában van azzal, hogyan fogja üzembe helyezni az Azure-erőforrásokat a virtuális hálózatokon, és hogy az egyes erőforrások hány IP-címet használnak fel. Ha bérlőspecifikus számítási csomópontokat, adatbázis-kiszolgálókat vagy egyéb erőforrásokat helyez üzembe, győződjön meg arról, hogy olyan alhálózatokat hoz létre, amelyek elég nagyok a bérlő várható növekedéséhez és az erőforrások horizontális automatikus méretezéséhez.

Hasonlóképpen, ha felügyelt szolgáltatásokkal dolgozik, fontos tisztában lenni az IP-címek használatának módjával. Ha például az Azure Kubernetes Service-t az Azure Container Networking Interface (CNI) használatával használja, az alhálózatból felhasznált IP-címek száma olyan tényezőkön alapul, mint a csomópontok száma, a horizontális skálázás és a használt szolgáltatástelepítési folyamat. Ha a Azure-alkalmazás Service-t és az Azure Functionst VNet-integrációval használja, a felhasznált IP-címek száma a csomagpéldányok számán alapul.

Az alhálózatok tervezésekor tekintse át az alhálózatok szegmentálási útmutatóját .

Nyilvános vagy privát hozzáférés

Fontolja meg, hogy a bérlők az interneten vagy magánhálózati IP-címeken keresztül férnek-e hozzá a szolgáltatásokhoz.

Az internetalapú (nyilvános) hozzáféréshez használhat tűzfalszabályokat, IP-címek engedélyezését és letiltását, megosztott titkos kulcsokat és kulcsokat, valamint identitásalapú vezérlőket a szolgáltatás biztonságossá tételéhez.

Ha privát IP-címek használatával kell engedélyeznie a szolgáltatáshoz való kapcsolódást, fontolja meg az Azure Private Link Service vagy a bérlők közötti virtuális hálózatok közötti társviszony-létesítést. Néhány korlátozott forgatókönyv esetén megfontolhatja az Azure ExpressRoute vagy az Azure VPN Gateway használatát is a megoldáshoz való privát hozzáférés engedélyezéséhez. Ezt a módszert csak akkor javasoljuk, ha kevés bérlővel rendelkezik, és minden bérlőhöz külön virtuális hálózatokat helyez üzembe.

Hozzáférés a bérlők végpontjaihoz

Fontolja meg, hogy adatokat kell-e küldenie a bérlői hálózatok végpontjaira, akár az Azure-on belül, akár azon kívül. Például meg kell hívnia egy ügyfél által biztosított webhookot, vagy valós idejű üzeneteket kell küldenie egy bérlőnek?

Ha adatokat kell küldenie a bérlők végpontjaira, vegye figyelembe az alábbi gyakori módszereket:

  • Kezdeményezhet kapcsolatokat a megoldásból a bérlők végpontjaihoz az interneten keresztül. Fontolja meg, hogy a kapcsolatoknak statikus IP-címről kell-e származnia. A használt Azure-szolgáltatásoktól függően előfordulhat, hogy NAT-átjárót, tűzfalat vagy terheléselosztót kell üzembe helyeznie.
  • Ügynök üzembe helyezése az Azure által üzemeltetett szolgáltatások és az ügyfelek hálózatai közötti kapcsolat engedélyezéséhez, függetlenül attól, hogy hol találhatók.
  • Az egyirányú üzenetkezeléshez érdemes lehet olyan szolgáltatást használni, mint az Azure Event Grid, eseménytartományokkal vagy anélkül.

Megfontolandó megközelítések és minták

Ebben a szakaszban ismertetjük a több-bérlős megoldásokban megfontolható legfontosabb hálózatkezelési megközelítéseket. Először az alapvető hálózati összetevők alacsonyabb szintű megközelítéseit ismertetjük, majd követjük azokat a megközelítéseket, amelyeket a HTTP-vel és más alkalmazásrétegekkel kapcsolatos problémák esetén is figyelembe vehet.

Bérlőspecifikus virtuális hálózatok a szolgáltató által kiválasztott IP-címekkel

Bizonyos esetekben dedikált, virtuális hálózatokhoz csatlakoztatott erőforrásokat kell futtatnia az Azure-ban egy bérlő nevében. Előfordulhat például, hogy minden bérlőhöz futtat egy virtuális gépet, vagy privát végpontokat kell használnia a bérlőspecifikus adatbázisok eléréséhez.

Fontolja meg egy virtuális hálózat üzembe helyezését minden bérlőhöz egy ön által szabályozható IP-címtér használatával. Ez a megközelítés lehetővé teszi, hogy a virtuális hálózatokat a saját céljaira társviszonyba hozza, például ha egy küllős topológiát kell létrehoznia a forgalom és a kimenő forgalom központi szabályozásához.

A szolgáltató által kiválasztott IP-címek azonban nem megfelelőek, ha a bérlőknek közvetlenül kell csatlakozniuk a létrehozott virtuális hálózathoz, például virtuális hálózatok közötti társviszony-létesítéssel. Valószínű, hogy a kiválasztott címtér nem kompatibilis a saját címterükkel.

Bérlőspecifikus virtuális hálózatok bérlő által kiválasztott IP-címekkel

Ha a bérlőknek a saját virtuális hálózataikat kell társviszonyba helyezniük a nevükben felügyelt virtuális hálózattal, érdemes lehet bérlőspecifikus virtuális hálózatokat üzembe helyezni egy olyan IP-címtérrel, amelyet a bérlő választ ki. Ez a rendszer lehetővé teszi minden bérlő számára, hogy a rendszer virtuális hálózatában lévő IP-címtartományok ne fedjék át a saját virtuális hálózataikat. A nem átfedésben lévő IP-címtartományok használatával biztosíthatják, hogy hálózataik kompatibilisek legyenek a társviszony-létesítéshez.

Ez a megközelítés azonban azt jelenti, hogy nem valószínű, hogy a bérlők virtuális hálózatait egymással társviszonyba helyezheti, vagy bevezethet egy küllős topológiát, mert valószínűleg átfedésben vannak a különböző bérlők virtuális hálózatai között az IP-címtartományok.

Küllős topológia

A küllős virtuális hálózatok topológiája lehetővé teszi, hogy több küllős virtuális hálózattal társviszonyt létesítsen egy központosított központi virtuális hálózattal. Központilag szabályozhatja a virtuális hálózatok forgalmát és kimenő forgalmát, és szabályozhatja, hogy az egyes küllők virtuális hálózatában lévő erőforrások képesek-e kommunikálni egymással. Minden küllős virtuális hálózat hozzáférhet a megosztott összetevőkhöz is, például az Azure Firewallhoz, és használhat olyan szolgáltatásokat, mint az Azure DDoS Protection.

Ha küllős topológiát használ, győződjön meg arról, hogy a korlátokat, például a társhálózatok maximális számát tervezi, és győződjön meg arról, hogy nem használ átfedésben lévő címtereket az egyes bérlők virtuális hálózataihoz.

A küllős topológia akkor lehet hasznos, ha bérlőspecifikus virtuális hálózatokat helyez üzembe a kiválasztott IP-címekkel. Minden bérlő virtuális hálózata küllővé válik, és megoszthatja a közös erőforrásokat a központi virtuális hálózaton. A küllős topológiát akkor is használhatja, ha megosztott erőforrásokat skáláz több virtuális hálózaton skálázás céljából, vagy ha az Üzembehelyezési bélyegek mintát használja.

Tipp.

Ha a megoldás több földrajzi régióban fut, általában ajánlott külön központokat és központi erőforrásokat üzembe helyezni minden régióban. Bár ez a gyakorlat magasabb erőforrásköltséggel jár, elkerüli, hogy a forgalom szükségtelenül haladjon át több Azure-régión, ami növelheti a kérések késését, és globális társviszony-létesítési díjakat vonhat maga után.

Statikus IP-címek

Fontolja meg, hogy a bérlőknek szükségük van-e a szolgáltatásra, hogy statikus nyilvános IP-címeket használjanak a bejövő forgalomhoz, a kimenő forgalomhoz vagy mindkettőhöz. A különböző Azure-szolgáltatások különböző módokon teszik lehetővé a statikus IP-címeket.

Ha virtuális gépekkel és más infrastruktúra-összetevőkkel dolgozik, érdemes lehet terheléselosztót vagy tűzfalat használni a bejövő és kimenő statikus IP-címekhez is. Fontolja meg a NAT Gateway használatát a kimenő forgalom IP-címének szabályozásához. A NAT Gateway több-bérlős megoldásban való használatáról további információt az Azure NAT Gateway több-bérlős megoldásokkal kapcsolatos szempontjaiban talál.

Amikor platformszolgáltatásokkal dolgozik, a használt szolgáltatás határozza meg, hogy szabályozható-e és hogyan az IP-címek. Előfordulhat, hogy az erőforrást meghatározott módon kell konfigurálnia, például az erőforrás virtuális hálózatban való üzembe helyezésével, illetve NAT-átjáró vagy tűzfal használatával. Vagy kérheti a szolgáltatás által a kimenő forgalomhoz használt IP-címek aktuális készletét. Az App Service például egy API-t és egy webes felületet biztosít az alkalmazás aktuális kimenő IP-címeinek lekéréséhez.

Ügynökök

Ha engedélyeznie kell a bérlők számára a megoldás által kezdeményezett üzenetek fogadását, vagy ha hozzá kell férnie a bérlők saját hálózataiban található adatokhoz, fontolja meg egy ügynök (más néven helyszíni átjáró) biztosítását, amelyet üzembe helyezhetnek a hálózaton belül. Ez a megközelítés akkor működik, ha a bérlői hálózatok az Azure-ban, egy másik felhőszolgáltatóban vagy a helyszínen találhatók.

Az ügynök kimenő kapcsolatot kezdeményez egy ön által megadott és felügyelt végponttal, és vagy életben tartja a hosszú ideig futó kapcsolatokat, vagy időnként lekérdezi azokat. Fontolja meg az Azure Relay használatát az ügynök és a szolgáltatás közötti kapcsolatok létrehozásához és kezeléséhez. Amikor az ügynök létrehozza a kapcsolatot, hitelesíti a kapcsolatot, és tartalmaz néhány információt a bérlőazonosítóról, hogy a szolgáltatás leképezhesse a kapcsolatot a megfelelő bérlőhöz.

Az ügynökök általában leegyszerűsítik a bérlők biztonsági konfigurációját. A bejövő portok megnyitása összetett és kockázatos lehet, különösen helyszíni környezetben. Az ügynökök nem igénylik, hogy a bérlők vállalják ezt a kockázatot.

Példák olyan Microsoft-szolgáltatások, amelyek ügynököket biztosítanak a bérlői hálózatokhoz való kapcsolódáshoz:

Az Azure Private Link szolgáltatás privát kapcsolatot biztosít a bérlő Azure-környezetéből a megoldáshoz. A bérlők saját virtuális hálózattal is használhatják a Private Link szolgáltatást a szolgáltatás helyszíni környezetből való eléréséhez. Az Azure biztonságosan irányítja a forgalmat a szolgáltatáshoz privát IP-címek használatával.

További információ a Private Linkről és a több-bérlősségről: Több-bérlős és Azure Private Link.

Tartománynevek, altartományok és TLS

Ha több-bérlős megoldásban használ tartományneveket és átviteli rétegbeli biztonságot (TLS), számos szempontot figyelembe kell vennie. Tekintse át a több-bérlős és a tartománynevekre vonatkozó szempontokat.

Átjáró-útválasztási és átjáró-kiszervezési minták

Az átjáró útválasztási mintája és az átjáró kiszervezési mintája magában foglalja egy 7. rétegbeli fordított proxy vagy átjáró üzembe helyezését. Az átjárók hasznosak a több-bérlős alkalmazások alapvető szolgáltatásainak biztosításához, beleértve a következő képességeket:

  • Útválasztási kérések bérlőspecifikus háttérrendszerekhez vagy üzembehelyezési bélyegekhez.
  • Bérlőspecifikus tartománynevek és TLS-tanúsítványok kezelése.
  • Biztonsági fenyegetésekre vonatkozó kérések vizsgálata webalkalmazási tűzfal (WAF) használatával.
  • A válaszok gyorsítótárazása a teljesítmény javítása érdekében.

Az Azure számos olyan szolgáltatást biztosít, amely ezen célok némelyikének vagy mindegyikének elérésére használható, beleértve az Azure Front Doort, a Azure-alkalmazás Gatewayt és az Azure API Managementet. Saját egyéni megoldást is üzembe helyezhet olyan szoftverekkel, mint az NGINX vagy a HAProxy.

Ha egy átjáró üzembe helyezését tervezi a megoldáshoz, ajánlott először egy teljes prototípust készíteni, amely tartalmazza az összes szükséges funkciót, és ellenőrizni, hogy az alkalmazás összetevői továbbra is a várt módon működnek-e. Azt is tudnia kell, hogy az átjáró-összetevő hogyan fog méretezni a forgalom és a bérlő növekedésének támogatása érdekében.

Statikus tartalom üzemeltetési minta

A statikus tartalom-üzemeltetési minta magában foglalja a webes tartalom szolgáltatását egy natív felhőbeli tárolási szolgáltatásból, valamint egy tartalomkézbesítési hálózat (CDN) használatával a tartalom gyorsítótárazásához.

Használhatja az Azure Front Doort vagy egy másik CDN-t a megoldás statikus összetevőihez, például egyoldalas JavaScript-alkalmazásokhoz, valamint statikus tartalmakhoz, például képfájlokhoz és dokumentumokhoz.

A megoldás kialakításától függően előfordulhat, hogy bérlőspecifikus fájlokat vagy adatokat is gyorsítótárazhat egy CDN-en belül, például JSON-formátumú API-válaszokat. Ez a gyakorlat segíthet a megoldás teljesítményének és méretezhetőségének javításában, de fontos megfontolni, hogy a bérlőspecifikus adatok megfelelően elkülönítettek-e ahhoz, hogy ne szivárogjanak ki adatok a bérlők között. Gondolja át, hogyan szeretné kiüríteni a bérlőspecifikus tartalmakat a gyorsítótárból, például az adatok frissítésekor vagy egy új alkalmazásverzió üzembe helyezésekor. A bérlőazonosító URL-elérési útba való beiktatásával szabályozhatja, hogy töröl-e egy adott fájlt, az adott bérlőhöz kapcsolódó összes fájlt, vagy az összes bérlő összes fájlja.

Antipatterns kerülni

Nem sikerült megtervezni a virtuális hálózatok közötti kapcsolatot

Az erőforrások virtuális hálózatokon való üzembe helyezésével nagy mértékben szabályozhatja, hogy a forgalom hogyan halad át a megoldás összetevőin. A virtuális hálózatok integrációja azonban további összetettségi, költség- és egyéb tényezőket is bevezet, amelyeket figyelembe kell vennie. Ez a hatás különösen igaz a szolgáltatásként nyújtott platform (PaaS) összetevőire.

Fontos a hálózati stratégia tesztelése és megtervezése, hogy az éles környezetben történő implementálás előtt feltárhassa a problémákat.

Nem tervez korlátokat

Az Azure számos olyan korlátozást kényszerít ki, amelyek hatással vannak a hálózati erőforrásokra. Ezek a korlátok közé tartoznak az Azure-erőforráskorlátok , valamint az alapvető protokoll- és platformkorlátok. Ha például nagy léptékű több-bérlős megoldást hoz létre platformszolgáltatásokra, például Azure-alkalmazás Service-ra és Azure Functionsre, előfordulhat, hogy figyelembe kell vennie a TCP-kapcsolatok és az SNAT-portok számát. Amikor virtuális gépekkel és terheléselosztókkal dolgozik, figyelembe kell vennie a kimenő szabályokra és az SNAT-portokra vonatkozó korlátozásokat is.

Kis alhálózatok

Fontos figyelembe venni az egyes alhálózatok méretét, hogy lehetővé tegye az üzembe helyezett erőforrások vagy erőforrások példányainak számát, különösen a méretezés során. Amikor szolgáltatásként (PaaS) működő platformerőforrásokkal dolgozik, győződjön meg arról, hogy az erőforrás konfigurációja és skálázása hogyan befolyásolja az alhálózatban szükséges IP-címek számát.

Nem megfelelő hálózati szegmentálás

Ha a megoldás virtuális hálózatokat igényel, fontolja meg a hálózati szegmentálás konfigurálását a bejövő és kimenő (észak-déli) forgalom és a megoldáson belüli (kelet-nyugati) folyamatok szabályozásához. Döntse el, hogy a bérlőknek saját virtuális hálózatokkal kell rendelkezniük, vagy megosztott erőforrásokat fog-e üzembe helyezni megosztott virtuális hálózatokon. A megközelítés módosítása nehéz lehet, ezért győződjön meg arról, hogy figyelembe veszi az összes követelményt, majd válasszon egy olyan megközelítést, amely a jövőbeli növekedési célokhoz fog működni.

Csak hálózati rétegbeli biztonsági vezérlőkre támaszkodva

A modern megoldásokban fontos, hogy a hálózati réteg biztonságát más biztonsági vezérlőkkel kombinálja, és ne csak tűzfalakra vagy hálózati szegmentálásra támaszkodjon. Ezt néha zéró megbízhatóságú hálózatkezelésnek is nevezik. Identitásalapú vezérlőkkel ellenőrizheti az ügyfelet, a hívót vagy a felhasználót a megoldás minden rétegében. Fontolja meg olyan szolgáltatások használatát, amelyek lehetővé teszik további védelmi rétegek hozzáadását. Az elérhető lehetőségek a használt Azure-szolgáltatásoktól függenek. Az AKS-ben fontolja meg egy szolgáltatásháló használatát a kölcsönös TLS-hitelesítéshez, valamint a hálózati házirendeket a kelet-nyugati forgalom szabályozásához. Az App Service-ben fontolja meg a beépített támogatás használatát a hitelesítéshez, az engedélyezéshez és a hozzáférés korlátozásához.

Gazdagépfejlécek újraírása tesztelés nélkül

Az átjáró kiszervezési mintájának használatakor érdemes lehet újraírni a Host HTTP-kérések fejlécét. Ez a gyakorlat leegyszerűsítheti a háttérbeli webalkalmazás-szolgáltatás konfigurálását azáltal, hogy az egyéni tartományt és a TLS-felügyeletet az átjáróra iktatja.

A Host fejléc újraírása azonban problémákat okozhat egyes háttérszolgáltatások esetében. Ha az alkalmazás HTTP-átirányításokat vagy cookie-kat használ, a gazdagépnevek eltérése megszakíthatja az alkalmazás működését. Ez a probléma különösen akkor fordulhat elő, ha olyan háttérszolgáltatásokat használ, amelyek maguk is több-bérlősek, például Azure-alkalmazás Service, Azure Functions és Azure Spring Apps. További információkért tekintse meg a gazdagépnév megőrzésének ajánlott eljárásait.

Győződjön meg arról, hogy az alkalmazás viselkedését a használni kívánt átjárókonfigurációval teszteli.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

  • John Downs | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke

Egyéb közreműködők:

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések