Egyrégiós adat-kezdőzóna-kapcsolat

Az adatkezelési célzóna, az adat-kezdőzónák és az azon belüli összes szolgáltatás ugyanabban a régióban van beállítva egy régióban egy régióban. Minden célzóna ugyanabban a kapcsolati központ-előfizetésben található. Ez az előfizetés megosztott hálózati erőforrásokat üzemeltet, amelyek tartalmazhatnak hálózati virtuális berendezést (például Azure-tűzfalat), ExpressRoute-átjárót, virtuális magánhálózati (VPN-) átjárót, központi virtuális hálózatot vagy virtuális WAN-központot (vWAN hub).

1. ábra: Egyrégiós Csatlakozás tivitás.

Az Azure Networking Services jelenlegi képességei alapján javasoljuk, hogy egy hálós hálózati architektúrát használjon. A virtuális hálózatok közötti társviszony-létesítést a következők között kell beállítania:

• A Csatlakozás ivity Hub és adatkezelés Zóna
• A Csatlakozás ivity Hub és az egyes adat-célzónák
• A adatkezelés zóna és az egyes adat-kezdőzónák
• Minden egyes adat-kezdőzóna

Ez a cikk a felhőalapú elemzésekhez figyelembe vett hálózati architektúra-beállítások előnyeit és hátrányait ismerteti.

A cikk első szakasza egy egyrégiós mintára összpontosít, ahol a adatkezelés zóna és az összes adat-célzóna ugyanabban a régióban található.

A rendszer az egyes tervezési mintákat a következő feltételek alapján értékeli ki:

• Költség
• Felhasználói hozzáférés kezelése
• Szolgáltatásmenedzsment
• Sávszélesség
• Késés

Az egyes tervezési lehetőségeket az alábbi adatközi célzóna-használati esettel fogjuk elemezni:

Feljegyzés

A B adat-célzónában üzemeltetett B virtuális gép (VM B) betölt egy adatkészletet az A adat-kezdőzónában üzemeltetett A tárfiókból. Ezután a B virtuális gép feldolgozza az adathalmazt, és tárolja azt a B tárfiókban, amely a B adat-kezdőzónában található.

Fontos

Ez a cikk és a hálózatkezelés szakasz egyéb cikkei az adatokat megosztó üzleti egységeket ismertetik. Előfordulhat azonban, hogy nem ez a kezdeti stratégia, és először alapszinten kell kezdenie.

Tervezheti meg a hálózatkezelést, hogy végül megvalósíthassa az ajánlott beállítást az adat-kezdőzónák között. Győződjön meg arról, hogy az adatkezelési célzónák közvetlenül csatlakoznak a szabályozási célzónákhoz.

Hálós hálózati architektúra (ajánlott)

Javasoljuk, hogy a felhőalapú elemzések bevezetésekor használjon hálózati hálós architektúrát. A bérlőn belül beállított meglévő küllős hálózattervezés mellett két dolgot kell tennie a hálózati hálós architektúra implementálásához:

• Virtuális hálózatok közötti társviszonyok hozzáadása az összes adat-kezdőzóna virtuális hálózata között.
• Virtuális hálózatok párosítása az adatkezelési célzóna és az összes adat-célzóna között.

A példánkban az A tárfiókból betöltött adatok a két adat-kezdőzóna virtuális hálózata között beállított virtuális hálózatok közötti társviszony-létesítési kapcsolatot (2) váltják át. A B virtuális gép ((3) és (4) betölti és feldolgozzák, majd a helyi privát végponton (5) keresztül küldik el a B tárfiókban való tároláshoz.

Ebben a forgatókönyvben az adatok nem adják át a Csatlakozás ivity Hubot. Az adatplatformon belül marad, amely egy adatkezelési célzónából és egy vagy több adat-célzónából áll.

2. ábra: Hálós hálózati architektúra.

Felhasználói hozzáférés-kezelés a meshed hálózati architektúrában

A hálós hálózati architektúra kialakításához az adatalkalmazási csapatoknak csak két dologra van szükségük ahhoz, hogy új szolgáltatásokat hozzanak létre (beleértve a privát végpontokat is):

• Hozzáférés írása a dedikált erőforráscsoporthoz az adat-célzónában
• Csatlakozás a kijelölt alhálózathoz való hozzáféréshez

Ebben a kialakításban az adatalkalmazás-csapatok maguk is üzembe helyezhetnek privát végpontokat. Mindaddig, amíg rendelkeznek a szükséges hozzáférési jogosultságokkal a privát végpontok adott küllős alhálózathoz való csatlakoztatásához, a csapatoknak nincs szükségük támogatásra a szükséges kapcsolat beállításakor.

Összefoglaló:

Szolgáltatáskezelés a hálós hálózati architektúrában

A hálós hálózati architektúra kialakításában egyetlen hálózati virtuális berendezés sem működik egyetlen meghibásodási vagy szabályozási pontként. A Csatlakozás ivity Hubon keresztül küldött adathalmazok hiánya csökkenti a központi Azure-platform csapatának terhelését, feltéve, hogy nem kell vertikálisan felskáláznia a virtuális berendezést.

Ez azt jelenti, hogy a központi Azure-platform csapata már nem tudja megvizsgálni és naplózni az adat-kezdőzónák között küldött összes forgalmat. A felhőalapú elemzés azonban több előfizetésre kiterjedő koherens platform, amely lehetővé teszi a skálázást, és leküzdi a platformszintű korlátozásokat, így ez nem jelent hátrányt.

Az egyetlen előfizetésen belül üzemeltetett összes erőforrás esetében a központi Azure-platform csapata már nem vizsgálja meg a központi Csatlakozás ivity Hub összes adatát. A hálózati naplókat továbbra is rögzítheti a hálózati biztonsági csoport folyamatnaplóinak használatával. A szolgáltatásspecifikus diagnosztikai Gépház használatával összesítheti és tárolhatja az egyéb alkalmazás- és szolgáltatásszint-naplókat.

Ezeket a naplókat nagy méretekben rögzítheti az Azure Policy-definíciók használatával a diagnosztikai beállításokhoz.

Ez a kialakítás lehetővé teszi, hogy natív Azure DNS-megoldást hozzon létre saját DNS Zónák alapján. A DNS A-rekord életciklusát az Azure Policy-definíciókon keresztül automatizálhatja privát DNS-csoportok esetében.

Összefoglaló:

Hálós hálózati architektúra költsége

Feljegyzés

Ha egy privát végpontot társhálózaton keresztül ér el, a rendszer csak magát a privát végpontot számítja fel, a virtuális hálózatok közötti társviszony-létesítésért nem. A hivatalos nyilatkozatot a gyakori kérdések között olvashatja el: Hogyan működik a számlázás a privát végpontok társhálózatról való elérésekor?

Ebben a hálózati kialakításban csak a következőért kell fizetnie:

• privát végpontok (óránként)
• a privát végpontokon keresztül küldött bejövő és kimenő forgalom a nyers adatkészlet betöltéséhez (1) és a feldolgozott adatkészlet tárolásához (6)

A virtuális hálózatok közötti társviszony-létesítést nem számítjuk fel (2), ezért ez a lehetőség minimális költséggel jár.

Összefoglaló:

Sávszélesség és késés a hálós hálózati architektúrában

Ez a kialakítás nem rendelkezik ismert sávszélesség- vagy késési korlátozásokkal, mivel a hálózati virtuális berendezések nem korlátozzák az adatközi célzóna-adatcserére vonatkozó átviteli sebességet. A tervezés egyetlen korlátozó tényezője az adatközpontok fizikai korlátja (száloptikai kábelek sebessége).

Összefoglaló:

Hálós hálózati architektúra összefoglalása

Ha felhőalapú elemzést szeretne alkalmazni, javasoljuk, hogy a hálós hálózat kialakítását használja. A hálós hálózatok minimális költséggel biztosítják a maximális sávszélességet és az alacsony késést, de nem veszélyeztetik a felhasználók hozzáférésének kezelését vagy a DNS-réteget.

Ha az adatplatformon belül más hálózati házirendeket kell kikényszerítenie, használja a hálózati biztonsági csoportokat a központi hálózati virtuális berendezések helyett.

Hagyományos küllős architektúra (nem ajánlott)

A küllős hálózati architektúra kialakítása a legnyilvánvalóbb megoldás, amelyet sok vállalat elfogadott. Ebben a hálózati tranzitivitás a Csatlakozás ivity Hubban lesz beállítva, hogy a B virtuális gépről hozzáférjen az A tárfiók adataihoz. Az adatok két virtuális társhálózati társviszonyt ((2) és (5)) és egy hálózati virtuális berendezést a Csatlakozás ivity Hubon ((3) és (4)) üzemeltetnek. Ezután a virtuális gép betölti az adatokat (6), és visszatárja a B tárfiókba (8).

3. ábra: Küllős architektúra.

Felhasználói hozzáférés-kezelés hagyományos központ- és küllős architektúrában

A hagyományos központ- és küllős kialakításban az adatalkalmazási csapatoknak csak két dologra van szükségük ahhoz, hogy új szolgáltatásokat tudjanak létrehozni (beleértve a privát végpontokat is):

• Hozzáférés írása az erőforráscsoporthoz az adat-kezdőzónában
• Csatlakozás a kijelölt alhálózathoz való hozzáféréshez

Ebben a kialakításban az adatalkalmazás-csapatok maguk is üzembe helyezhetnek privát végpontokat. Mindaddig, amíg rendelkeznek a szükséges hozzáférési jogosultságokkal a privát végpontok adott küllős alhálózathoz való csatlakoztatásához, a csapatoknak nincs szükségük támogatásra a szükséges kapcsolat beállításakor.

Összefoglaló:

Szolgáltatáskezelés a hagyományos központ- és küllős architektúrában

Ez a hálózattervezés jól ismert és összhangban van a legtöbb szervezet meglévő hálózatbeállításával. Ez megkönnyíti a tervezés magyarázatát és implementálását. Központosított, natív Azure-beli DNS-megoldást is használhat saját DNS Zónákkal, hogy teljes tartománynév-feloldási megoldást biztosítson az Azure-bérlőn belül. A saját DNS Zónák használatával automatizálhatja a DNS A-rekord életciklusát az Azure-szabályzatok használatával.

Ennek a kialakításnak egy másik előnye, hogy a forgalmat egy központi hálózati virtuális berendezésen keresztül irányítják, így az egyik küllőből a másikba küldött hálózati forgalom naplózható és vizsgálható.

Ennek a kialakításnak az egyik hátránya, hogy a központi Azure Platform-csapatnak manuálisan kell kezelnie az útvonaltáblákat. Ez szükséges a küllők közötti tranzitivitás biztosításához, amely lehetővé teszi az adategységek több adat-célzóna közötti megosztását. Az útvonalkezelés idővel összetetté és hibalehetőséggé válhat, és elölről kell megfontolni.

Ennek a hálózati beállításnak egy másik hátránya a központi hálózati virtuális berendezés beállítása. A hálózati virtuális berendezés egyetlen meghibásodási pontként működik, és meghibásodás esetén komoly állásidőt okozhat az adatplatformon belül. Az adathalmazok adatplatformon belüli méretének növekedésével és az adatközi célzóna-használati esetek számának növekedésével a rendszer nagyobb forgalmat küld a központi hálózati virtuális berendezésen keresztül.

Idővel ez gigabájt vagy akár terabájtnyi adatküldést eredményezhet a központi példányon keresztül. Mivel a meglévő hálózati virtuális berendezések sávszélessége gyakran csak egy- vagy kétjegyű gigabájtos átviteli sebességre korlátozódik, a központi hálózati virtuális berendezés szűk keresztmetszetté válhat, amely kritikusan korlátozza az adat-kezdőzónák közötti forgalmat, és korlátozza az adategységek megoszthatóságát.

A probléma elkerülésének egyetlen módja, ha a központi hálózati virtuális berendezést több példányra skálázza fel, ami jelentős költségekkel jár erre a kialakításra nézve.

Összefoglaló:

Hagyományos küllős architektúra költsége

Feljegyzés

Ha egy privát végpontot társhálózaton keresztül ér el, a rendszer csak magát a privát végpontot számítja fel, a virtuális hálózatok közötti társviszony-létesítésért nem. A hivatalos nyilatkozatot a gyakori kérdések között olvashatja el: Hogyan működik a számlázás a privát végpontok társhálózatról való elérésekor?

Ebben a hálózatban óránként kell fizetnie a tárfiókok privát végpontjaiért. A privát végpontokon keresztül küldött bejövő és kimenő forgalomért is díjat kell fizetnie egy nyers adatkészlet (1) betöltéséhez és a feldolgozott adatkészlet tárolásához (8).

Az ügyfél egy virtuális hálózatok közötti társviszony-létesítés bejövő és kimenő forgalmáért (5) számít fel díjat. Ahogy korábban említettük, az első virtuális hálózatok közötti társviszony-létesítés nem számít fel díjat (2).

Ha ezt a hálózati kialakítást ((3) és (4)) használja, akkor a központi hálózati virtuális berendezés költsége magas lesz. Vagy további licenceket kell vásárolnia, és igény szerint fel kell skáláznia a központi hálózati virtuális berendezést, vagy gigabájtonként kell fizetnie a gigabájtonkénti díjat, ahogy azt az Azure Firewall végzi.

Összefoglaló:

Sávszélesség és késés a hagyományos küllős architektúrában

Ez a hálózati kialakítás komoly sávszélesség-korlátozásokkal rendelkezik. A központi hálózati virtuális berendezés a platform növekedésével kritikus szűk keresztmetszetté válik, ami korlátozza az adatközi kezdőzónák használati eseteit és az adathalmazok megosztását. Emellett valószínűleg több adathalmazpéldányt is létrehoz az idő múlásával.

Ez a kialakítás a késést is jelentősen befolyásolja, ami a valós idejű elemzési forgatókönyvekben különösen kritikussá válik.

Összefoglaló:

A hagyományos központ- és küllős architektúra összefoglalása

Ez a küllős hálózat kialakítása hozzáférés-kezeléssel és szolgáltatásfelügyeleti előnyökkel rendelkezik, de a szolgáltatáskezelés kritikus korlátozásai, a sávszélesség és a késés miatt nem javasoljuk ezt a hálózati kialakítást adatközi célzóna-használati esetekhez.

Privát végpont-vetítési architektúra (nem ajánlott)

Egy másik tervezési lehetőség a privát végpontok kivetítése minden egyes kezdőzónára. Ebben a tervben minden egyes kezdőzónában létrejön egy A tárfiók privát végpontja. Ez egy első privát végponthoz vezet az A adat-kezdőzónában a Vnethez az A adat-kezdőzónában, egy második privát végponthoz, amely a B adat-kezdőzónában csatlakozik a virtuális hálózathoz stb.

Ugyanez vonatkozik a B tárfiókra és az adat-kezdőzónákon belüli egyéb szolgáltatásokra is. Ha az adat-kezdőzónák számát n-ként határozzuk meg, akkor legalább az összes tárfiókhoz és az adat-kezdőzónákon belüli egyéb szolgáltatásokhoz n privát végpontok tartoznak. Ez a privát végpontok számának exponenciális növekedéséhez vezet.

4. ábra: Privát végpont-vetítési architektúra.

Mivel egy adott szolgáltatás (például az A tárfiók) összes privát végpontja ugyanazzal a teljes tartománynévvel (példáulstorageaccounta.privatelink.blob.core.windows.net) rendelkezik, ez a megoldás olyan kihívásokat hoz létre a DNS-rétegben, amelyek nem oldhatók meg saját DNS Zónák használatával. Ehelyett olyan egyéni DNS-megoldásra van szüksége, amely képes a DNS-nevek feloldására a kérelmező származása/IP-címe alapján. Ez lehetővé teszi, hogy a VMA kapcsolódjon az A adat-célzónában lévő virtuális hálózathoz csatlakoztatott privát végpontokhoz, és hogy a B virtuális gép csatlakozzon a B adat-célzónában lévő virtuális hálózathoz csatlakoztatott privát végpontokhoz. Ezt Windows Server-alapú beállítással teheti meg, míg a DNS A-rekordok életciklusát a tevékenységnapló és az Azure Functions kombinációjával automatizálhatja.

Ebben a beállításban az A tárfiókban lévő nyers adatkészletet a B virtuális gépbe töltheti be, ha a helyi privát végponton (1) keresztül éri el az adathalmazt. Miután betöltötte és feldolgozta az adathalmazt ((2) és (3)), a B tárfiókban tárolhatja a helyi privát végpont (4) közvetlen elérésével. Ebben az esetben az adatok nem lépnek át virtuális hálózatok közötti társviszonyokon.

Felhasználói hozzáférés-kezelés privát végpontvetítési architektúrában

Ez a kialakítás a felhasználói hozzáférés-kezeléshez hasonló megközelítést alkalmaz, mint a hálós hálózati architektúra. Ebben a kialakításban azonban más adat-célzónák hozzáférési jogosultságait is megkövetelheti, hogy ne csak egy kijelölt adat-célzónán és virtuális hálózaton belül hozzon létre privát végpontokat, hanem más adat-célzónákban és azok megfelelő virtuális hálózataiban is.

Emiatt az adatalkalmazási csapatoknak három dologra van szükségük, nem kettőre, hogy maguk is új szolgáltatásokat tudjanak létrehozni:

• erőforráscsoporthoz való hozzáférés írása egy kijelölt adat-célzónában
• csatlakozás a kijelölt alhálózathoz
• hozzáférés egy erőforráscsoporthoz és alhálózathoz az összes többi adat-kezdőzónán belül a megfelelő helyi privát végpontok létrehozásához

Ez a hálózati kialakítás növeli a hozzáférés-kezelési réteg összetettségét, mivel az adatalkalmazási csapatoknak minden egyes adat-kezdőzónához engedélyre van szükségük. A kialakítás zavaró is lehet, és idővel inkonzisztens RBAC-t eredményezhet.

Ha az adat-kezdőzóna-csapatok és az adatalkalmazás-csapatok nem kapják meg a szükséges hozzáférési jogosultságokat, a hagyományos központ- és küllős architektúrában ismertetett problémák (nem ajánlottak).

Összefoglaló:

Szolgáltatáskezelés a privát végpontvetítési architektúrában

Bár a hálós hálózati architektúra kialakításához hasonlóan ez a hálózati kialakítás sem a hálózati virtuális berendezés egyetlen meghibásodási pontként vagy átviteli sebesség szabályozásaként működik. Emellett csökkenti a központi Azure-platform csapatának felügyeleti többletterhelését azáltal, hogy nem küld adathalmazokat a Csatlakozás ivity Hubon keresztül, mert nincs szükség a virtuális berendezés vertikális felskálázására. Ez azt jelenti, hogy a központi Azure-platform csapata már nem tudja megvizsgálni és naplózni az adat-kezdőzónák között küldött összes forgalmat. A felhőalapú elemzés azonban több előfizetésre kiterjedő koherens platform, amely lehetővé teszi a skálázást, és leküzdi a platformszintű korlátozásokat, így ez nem jelent hátrányt.

Egyetlen előfizetésen belül üzemeltetett összes erőforrás esetén a forgalom nem lesz vizsgálva a központi Csatlakozás ivity Hubban. A hálózati naplókat továbbra is rögzítheti a hálózati biztonsági csoport folyamatnaplóival, és a szolgáltatásspecifikus diagnosztikai Gépház használatával összesítheti és tárolhatja az egyéb alkalmazás- és szolgáltatásszintű naplókat. Ezeket a naplókat nagy méretekben rögzítheti az Azure-szabályzatok használatával. Másrészt az adatplatform által igényelt hálózati címtér nő a szükséges privát végpontok exponenciális növekedése miatt, ami nem optimális.

A hálózati architektúrával kapcsolatos fő aggodalmak a korábban említett DNS-kihívások. Nem használhat natív Azure-megoldást saját DNS Zónák formájában, ezért ehhez az architektúrához olyan külső megoldásra van szükség, amely képes a teljes tartománynevek feloldására a kérelmező származása/IP-címe alapján. Emellett eszközöket és munkafolyamatokat kell fejlesztenie és karbantartania az A-rekordok saját DNS automatizálásához, ami jelentősen növeli a felügyeleti többletterhelést a javasolt Azure Policy-alapú megoldáshoz képest.

Elosztott DNS-infrastruktúrát hozhat létre saját DNS zónák használatával, de ez DNS-szigeteket hoz létre, ami végső soron problémákat okoz, amikor megpróbál hozzáférni a bérlőn belüli más kezdőzónákban üzemeltetett privát kapcsolati szolgáltatásokhoz. Ezért ez a kialakítás nem járható út.

Összefoglaló:

Privát végpont-vetítési architektúra költsége

Feljegyzés

Ha egy privát végpontot társhálózaton keresztül ér el, akkor csak a privát végpontért kell fizetnie, a virtuális hálózatok közötti társviszony-létesítésért nem. A hivatalos nyilatkozatot a gyakori kérdések között olvashatja el: Hogyan működik a számlázás a privát végpontok társhálózatról való elérésekor?

Ebben a hálózati kialakításban csak a privát végpontokért (óránként) és a magánvégpontokon keresztül küldött bejövő és kimenő forgalomért kell fizetnie a nyers adathalmazok (1) betöltéséhez és a feldolgozott adatkészletek tárolásához (4). Az adatplatform privát végpontjainak számának exponenciális növekedése miatt azonban további költségekre kell számítani. Mivel óránkénti díjat számítunk fel, a többletköltség nagyban függ attól, hogy hány privát végpont jön létre.

Összefoglaló:

Sávszélesség és késés a privát végpontvetítési architektúrában

Ez a kialakítás nem rendelkezik ismert sávszélesség- és késési korlátozásokkal, mivel nincs olyan hálózati virtuális berendezése, amely korlátozza az adatközi célzóna-adatcsere átviteli sebességét. A tervezés egyetlen korlátozó tényezője az adatközpontok fizikai korlátja (száloptikai kábelek sebessége).

Összefoglaló:

Privát végpont-vetítési architektúra összefoglalása

A privát végpontok exponenciális növekedése ebben a hálózati architektúrában azt eredményezheti, hogy nem tudja, hogy mely privát végpontokat használja a rendszer, milyen célra. A hozzáférés-kezelési problémák és a DNS-réteg összetettségi problémái is korlátozottak. Ezen problémák miatt nem javasoljuk ezt a hálózati kialakítást adatközi célzóna-használati esetekhez.

Privát végpontok Csatlakozás ivity Hub architektúrában (nem ajánlott)

Egy másik hálózati lehetőség, ha privát végpontokat üzemeltet a Csatlakozás ivity Hubon, és csatlakoztatja őket a központi virtuális hálózathoz. Ebben a megoldásban egyetlen privát végpontot üzemeltet a vállalati virtuális hálózaton lévő összes szolgáltatáshoz. A legtöbb vállalatnál meglévő küllős hálózati architektúra, valamint az a tény, hogy a Csatlakozás ivity Hub üzemelteti a privát végpontokat ebben a megoldásban, nincs szükség tranzitivitásra. A Csatlakozás ivity Hub és az adat-kezdőzónák közötti virtuális hálózatok közötti társviszony lehetővé teszi a közvetlen hozzáférést.

Az adatok egyetlen virtuális hálózat közötti társviszonyt létesítenek a Csatlakozás ivity Hub és az adat-célzóna között, hogy betöltse a B virtuális gép A tárfiókjában tárolt adathalmazt. Az adatkészlet betöltése és feldolgozása ((3) és (4)) után ugyanazt a virtuális társhálózatot másodszor (5) is bejárja, mielőtt végül a B tárfiókban tárolva lenne a központi virtuális hálózathoz csatlakoztatott privát végponton keresztül (6).

5. ábra: Privát végpontok az Csatlakozás ivity Hub architektúrájában.

Felhasználói hozzáférés-kezelés a Csatlakozás ivity Hub architektúrájában

Ebben a hálózati kialakításban az adat-kezdőzóna-csapatoknak és az adatalkalmazási csapatoknak két dologra van szükségük ahhoz, hogy privát végpontokat csatlakoztathassanak a központi virtuális hálózathoz:

• engedélyek írása egy erőforráscsoporthoz a Csatlakozás ivity Hub-előfizetésben
• csatlakozási engedélyek a központi virtuális hálózathoz

A Csatlakozás ivity Hub a szervezet Azure platformcsapatának van kijelölve, és a szervezet szükséges és megosztott hálózati infrastruktúrájának üzemeltetésére van dedikáltan (beleértve a tűzfalakat, átjárókat és hálózatkezelési eszközöket). Ez a hálózati beállítás inkonzisztenssé teszi ezt a kialakítást, mivel nem követi a nagyvállalati szintű kezdőzóna alapvető alapelveinek hozzáférés-kezelési alapelveit. Ezért a legtöbb Azure-platformcsapat nem fogja jóváhagyni ezt a tervezési lehetőséget.

Összefoglaló:

Szolgáltatáskezelés a Csatlakozás ivity Hub architektúrájában

Bár a hálós hálózati architektúra kialakításához hasonlóan ez a kialakítás nem rendelkezik hálózati virtuális berendezéssel, amely egyetlen meghibásodási pontként vagy szabályozási átviteli sebességként működik. Emellett csökkenti a központi Azure-platform csapatának felügyeleti többletterhelését azáltal, hogy nem küld adathalmazokat a Csatlakozás ivity Hubon keresztül, mert nincs szükség a virtuális berendezés vertikális felskálázására. Ez azt jelenti, hogy a központi Azure-platform csapata már nem tudja megvizsgálni és naplózni az adat-kezdőzónák között küldött összes forgalmat. A felhőalapú elemzés azonban több előfizetésre kiterjedő koherens platform, amely lehetővé teszi a skálázást, és leküzdi a platformszintű korlátozásokat, így ez nem jelent hátrányt.

Egyetlen előfizetésen belül üzemeltetett összes erőforrás esetén a forgalom nem lesz vizsgálva a központi Csatlakozás ivity Hubban. A hálózati naplókat továbbra is rögzítheti a hálózati biztonsági csoport folyamatnaplóival, és a szolgáltatásspecifikus diagnosztikai Gépház használatával összesítheti és tárolhatja az egyéb alkalmazás- és szolgáltatásszintű naplókat. Ezeket a naplókat nagy méretekben rögzítheti az Azure-szabályzatok használatával.

Ez a kialakítás lehetővé teszi, hogy natív Azure DNS-megoldást hozzon létre saját DNS Zónák alapján, és lehetővé teszi a DNS A-rekord életciklusának automatizálását az Azure Policies használatával.

Összefoglaló:

Csatlakozás ivity Hub architektúraköltsége

Feljegyzés

Ha egy privát végpontot társhálózaton keresztül ér el, a rendszer csak magát a privát végpontot számítja fel, a virtuális hálózatok közötti társviszony-létesítésért nem. A hivatalos nyilatkozatot a gyakori kérdések között olvashatja el: Hogyan működik a számlázás a privát végpontok társhálózatról való elérésekor?

Ebben a hálózati kialakításban csak a privát végpontokért (óránként) és a magánvégpontokon keresztül küldött bejövő és kimenő forgalomért kell fizetnie egy nyers adatkészlet (1) betöltéséhez és a feldolgozott adatkészlet tárolásához (6).

Összefoglaló:

Sávszélesség és késés a Csatlakozás ivity Hub architektúrájában

Ez a kialakítás nem rendelkezik ismert sávszélesség- és késési korlátozásokkal, mivel nincs olyan hálózati virtuális berendezése, amely korlátozza az adatközi célzóna-adatcsere átviteli sebességét. A tervezés egyetlen korlátozó tényezője az adatközpontok fizikai korlátja (száloptikai kábelek sebessége).

Összefoglaló:

Privát végpontok a Csatlakozás ivity Hub architektúrájában – összefoglalás

Bár ez a hálózati architektúra több előnnyel is rendelkezik, a korábban említett hozzáférés-kezelési inkonzisztenciák alparvá teszik. Ezért nem javasoljuk ezt a tervezési megközelítést.

Egyrégiós adatok kezdőzónájának kapcsolati következtetése

Az összes áttekintett hálózati architektúra-lehetőség és azok előnyei és hátrányai közül a hálós hálózati architektúra az egyértelmű győztes. Óriási előnyökkel jár az átviteli sebesség, valamint a költségek és a felügyelet szempontjából, ezért javasoljuk, hogy használja a felhőalapú elemzések üzembe helyezésekor. A küllős virtuális hálózatok közötti társviszony-létesítés korábban nem volt gyakori, és ez problémákat eredményezett az adathalmazok tartományok és üzleti egységek közötti megosztásával kapcsolatban.

A felhőalapú elemzéseket több előfizetésre kiterjedő koherens megoldásként tekintheti meg. Egyetlen előfizetés-beállítás esetén a hálózati forgalom egyenlő a hálós hálózati architektúra folyamatával. Egyetlen előfizetés-beállításon belül a felhasználók valószínűleg elérik a platform előfizetési szintű korlátait és kvótáit, amelyeket a felhőalapú elemzések célja elkerülni.

Következő lépések

• Régiók közötti adat-célzóna Csatlakozás ivity