Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Azure OpenAI Service
Öntödei eszközök
Azure App Service
Azure Key Vault
Azure Monitor
Microsoft Foundry
Ez a cikk egy olyan sorozat része, amely a Baseline Microsoft Foundry-csevegés referenciaarchitektúrájára épül. Tekintse át az alaparchitektúrát, hogy azonosíthassa a szükséges módosításokat, mielőtt üzembe helyezi azt egy Azure számítási feladatokhoz készült leszállózóna-előfizetésben.
Ez a cikk egy olyan generatív AI-számítási feladatarchitektúrát ismertet, amely üzembe helyezi az alapkonfigurációs csevegőalkalmazást, de olyan erőforrásokat használ, amelyek nem tartoznak a számítási feladatok csapatának hatókörébe. A platformcsapatok központilag kezelik az erőforrásokat, és több számítási feladatokat végző csapat használja őket. A megosztott erőforrások közé tartoznak a hálózatkezelési erőforrások a helyek közötti kapcsolatokhoz, az identitáshozzáférési felügyeleti rendszerekhez és a szabályzatokhoz. Ez az útmutató segítséget nyújt a Azure célzónákat használó szervezeteknek a konzisztens irányítás és a költséghatékonyság fenntartásában.
Az Foundry erőforrásokat és projekteket használ az AI-fejlesztés és -üzembe helyezés rendszerezéséhez. A célzóna-implementációk például egy Foundry-erőforrást használhatnak központosított erőforrásként egy üzleti csoport szintjén, és a projekteket delegált erőforrásként az adott üzleti csoport minden számítási feladatához. Az erőforrás-szervezési tényezők és a költségfelosztási korlátozások miatt nem javasoljuk ezt a topológiát, és ez a cikk nem nyújt útmutatást. Ez az architektúra ehelyett a számítási feladatot az Foundry-erőforrás tulajdonosaként kezeli, ami az ajánlott megközelítés.
Számítási feladat tulajdonosaként megosztott erőforrás-kezelést delegál a platformcsapatok számára, hogy a számítási feladatok fejlesztésére összpontosíthasson. Ez a cikk bemutatja a számítási feladatok csapatának perspektíváját, és javaslatokat ad a platformcsapat számára.
Fontos
Mi az Azure célzóna?
Azure célzónák két fő területre osztják a szervezet felhőbeli lábnyomát:
Minden munkaterheléshez egyetlen munkaterhelési leszálló zóna tartozik, amely tartalmazza az összes környezetét, például a fejlesztési, a tesztelési és az éles környezetet. Minden környezet egy vagy több Azure előfizetésből áll. A munkaterhelési landing zone a szervezet megosztott platformerőforrásaihoz csatlakozik. Ez a kapcsolat hozzáférést biztosít a kezdőzónának a számítási feladatot támogató infrastruktúrához, például hálózatkezeléshez, identitáshozzáférés-kezeléshez, szabályzatokhoz és figyeléshez.
A platform kezdőzónája különböző előfizetések gyűjteménye, amelyeket több platformcsapat is kezelhet. Minden előfizetés egy adott funkcióval rendelkezik. A kapcsolati előfizetések például központosított tartománynévrendszert (DNS)-feloldást, helyek közötti kapcsolatot és hálózati virtuális berendezéseket (NVA-kat) biztosítanak a platformcsapatok számára.
Az architektúra implementálásához ismerje meg a Azure célzónák, a design alapelveit és design területeit.
Cikktartalom-elrendezés
| Architecture | Tervezési döntések | Jól kiépítésű keretrendszer megközelítése |
|---|---|---|
| ▪ Architektúradiagram ▪ Számítási feladatok erőforrásai ▪ Összevont erőforrások |
▪ Előfizetés beállítása ▪ Hálózati ▪ Adatelemzői hozzáférés ▪ Erőforrások figyelése ▪ Szervezeti irányítás ▪ Változáskezelés |
▪ Megbízhatóság ▪ Biztonság ▪ Költségoptimalizálás ▪ Működési kiválóság ▪ Teljesítményhatékonyság |
Architecture
Töltse le az architektúra Visio fájlját.
Components
Minden Azure célzóna-architektúra elkülöníti a tulajdonjogot a platformcsapat és a számítási feladatokkal foglalkozó csapat között. Ezt a szétválasztást előfizetés-demokratizálásnak nevezzük. Az alkalmazástervezőknek, adattudósoknak és DevOps-csapatoknak világosan meg kell érteniük ezt a részleget annak meghatározásához, hogy mi tartozik közvetlen befolyásuk vagy irányításuk alá, és mi nem.
A legtöbb munkaterhelési fogadózóna-implementációhoz hasonlóan a munkaterhelést kezelő csapat elsősorban a munkaterhelési összetevők konfigurációját, üzembe helyezését és felügyeletét kezeli, beleértve az architektúrában található AI-szolgáltatásokat is.
Munkaterhelési csapat tulajdonában lévő erőforrások
A következő erőforrások többnyire változatlanok maradnak az alaparchitektúra alapján.
A Foundry-erőforrás és annak projektjei egy MI-alkalmazásplatform részét képezik. Ezen a platformon a számítási feladat AI-fejlesztői és adattudósai kiértékelik és üzembe helyezik az AI-modelleket. Emellett a platformmal tesztelik és üzemeltetik az ügynököket. Minden projekt egy végpontot tesz elérhetővé, amelyet az ügyfelek a csapat ügynökeivel és modelljeivel való interakcióhoz használnak. Ebben az architektúrában az Foundry-erőforrás lehetővé teszi, hogy a számítási feladatokat ellátó csapat szolgáltatásként (MaaS) üzemeltetjen modelleket, implementálja a tartalombiztonságot, és olyan ügynököket hozzon létre, amelyek számítási feladatspecifikus kapcsolatokat használnak az eszközökhöz.
Ha a szervezet AI-kiválósági központja korlátozza az AI-modellek üzembe helyezéséhez való hozzáférést, előfordulhat, hogy a számítási feladatokat kezelő csapat nem üzemeltet modelleket a saját Foundry-erőforrásában. Ehelyett előfordulhat, hogy központosított AI-erőforrásokat , például AI-központot kell használniuk. Ebben a forgatókönyvben az összes modellhasználat általában egy AI-átjárón halad át, amelyet az AI-platform csapata biztosít.
Ebben a cikkben feltételezzük, hogy ebben a forgatókönyvben a generatív AI-modellek a munkaterhek által birtokolt és üzemeltetett erőforrások. Ha nem, a modellgazda vagy az AI-átjáró számítási feladatok függőségévé válik. A platformcsapatnak megbízható hálózati kapcsolatot kell fenntartania az ön virtuális hálózatától a saját virtuális hálózatukig, vagy létre kell hozni egy privát végpontot.
Az Agent Service egy natív felhőbeli futtatókörnyezet, amely lehetővé teszi az intelligens ügynökök biztonságos és autonóm működését. Ebben az architektúrában az Agent Service biztosítja a csevegések vezénylési rétegét. Az alaparchitektúrával összhangban üzemelteti és kezeli a felhasználói kéréseket feldolgozó parancssori ügynököt . A cikkben ismertetett landing zóna hálózati és irányítási kialakítása egyaránt érvényes akkor is, ha promptügynököt, illetve konténeresített üzemeltetett ügynököt helyez üzembe.
Ebben az architektúrában használja a standard ügynökbeállítást . Csatlakoztassa az ügynököt egy dedikált alhálózathoz a küllős virtuális hálózatban, és irányozza át a kimenő forgalmat a kapcsolati előfizetésen keresztül. Az alaparchitektúra leírása szerint egy egybérlős adatproxy fut ebben a dedikált alhálózatban, és az ügynök kimenő forgalmát kezdeményezi.
A számítási feladatokért felelős csapat dedikált Azure erőforrásokat biztosít az ügynökállapothoz, a csevegési előzményekhez és a fájltároláshoz. Ezek az erőforrások Azure Cosmos DB NoSQL, Azure Storage és Azure AI Keresés. Az Agent Service példány kizárólag az alábbi erőforrásokat és azok adatait kezeli. A számítási feladat más alkalmazásösszetevői vagy a szervezet más számítási feladatai nem használhatják őket.
Ha privát MCP-kiszolgálókat üzemeltet, a számítási feladatokat üzemeltető csapat telepíti és üzemelteti az MCP-kiszolgálókat és azok gazdakörnyezetét. A platform csapata elegendő küllős címteret foglal le a dedikált MCP-alhálózat számára, és támogatja a központosított DNS- és tűzfalkövetelményeket. Nyilvános MCP-kiszolgálók esetén a számítási feladatokkal foglalkozó csapat biztosítja a platformcsapatnak a jóváhagyott végponti teljes tartományneveket, amelyeket az ügynökforgalomnak a központi tűzfalon keresztül kell elérnie.
Azure App Service lehetővé teszi a fejlesztők számára, hogy webes és mobilalkalmazásokat építsenek, és api-alkalmazásokkal automatizálják az üzleti folyamatokat. Ebben az architektúrában a webalkalmazást üzemeltetik, amely tartalmazza a csevegő felhasználói felületet (UI), és több példányával biztosítja a felhasználói komponenst, zónákon keresztüli elérhetőséget nyújtva a rendelkezésre állás érdekében.
Egy Azure Storage-fiók ZIP-fájl formájában tárolja a webalkalmazás kódját, amely az App Service-hez csatolódik.
Az AI Search egy skálázható keresési infrastruktúra, amely heterogén tartalmakat indexel, és lehetővé teszi az adatok API-k, alkalmazások és AI-ügynökök használatával történő lekérését. Ebben az architektúrában az AI Search által üzemeltetett Foundry IQ a számítási feladatok tudástáraként szolgál a kiterjesztett generációs lekérési mintához. Ez a minta kinyer egy megfelelő lekérdezést egy parancssorból, lekérdezi az AI Search szolgáltatást, és az eredményeket egy generatív AI-alapmodell alapadataiként használja.
Azure Application Gateway egy webes forgalom terheléselosztó és alkalmazáskézbesítési vezérlő. Ebben az architektúrában fordított proxyként működik, amely átirányítja a felhasználói kéréseket az App Service-ben üzemeltetett csevegőfelületre. Egy Azure webalkalmazás tűzfalát üzemelteti, amely segít megvédeni az előtérbeli alkalmazást a potenciálisan rosszindulatú forgalomtól.
Azure Key Vault a titkos kulcsok, kulcsok és tanúsítványok biztonságos tárolására és elérésére szolgáló felhőszolgáltatás. Ebben az architektúrában az Application Gateway Transport Layer Security (TLS) tanúsítványát tárolja.
Azure Monitor, Azure Monitor Naplók és Application Insights gyűjti, tárolja és vizualizálja a megfigyelhetőségi adatokat. Ebben az architektúrában lehetővé teszik a monitorozást, a diagnosztikát és a működési elemzéseket az összes számítási feladat összetevőjére vonatkozóan.
Azure Policy számítási feladatspecifikus szabályzatokat alkalmaz a vezérlők nagy léptékű szabályozásához, biztonságossá tételéhez és alkalmazásához. Ebben az architektúrában szabályozási és megfelelőségi szabályokat kényszerít ki a számítási feladatokért felelős csapat által kezelt erőforrásokra.
A számítási feladatokért felelős csapat a következő erőforrásokat is fenntartja:
A küllős virtuális hálózati alhálózatok és a hálózati biztonsági csoportok (NSG-k) fenntartják a szegmentálást és az alhálózatok közötti forgalom szabályozását. Ebben az architektúrában hálózati határokat és biztonságot kényszerítenek ki a számítási feladatok összetevői között.
A privát végpontok biztonságos kapcsolatot biztosítanak a szolgáltatásként nyújtott platform (PaaS) megoldásokkal. Ebben az architektúrában biztosítják, hogy a bizalmas szolgáltatások csak a magánhálózaton belül legyenek elérhetők, ami csökkenti a nyilvános internetnek való kitettséget. A további függőségek, például a másik csapat tulajdonában lévő állapottárolók privát végpontként is elérhetők a számítási feladat számára, elkerülve az átmenő útválasztást a kapcsolati előfizetésen keresztül.
Platformcsapat tulajdonában lévő erőforrások
A platformcsapat a következő központosított erőforrások tulajdonosa és fenntartója. Ez az architektúra feltételezi, hogy ezek az erőforrások előre ki vannak építve, és függőségként kezeli őket.
Azure Firewall felügyelt, felhőalapú hálózati biztonsági szolgáltatás. Ebben az architektúrában az Azure Firewall a központi hálózatban irányítja, ellenőrzi és korlátozza a számítási feladatból származó kimenő forgalmat, beleértve az ügynök forgalmát is. A munkaterhelések kimenő forgalma az internetre, a telephelyek közötti célállomásokra vagy más munkaterhelési landing zone-okba kerül.
Változás az alapkonfigurációtól: Az alaparchitektúrában a számítási feladatokért felelős csapaté ez az összetevő. Ebben az architektúrában a platformcsapat kezeli azt a kapcsolati előfizetés alatt.
Azure Bastion egy felügyelt PaaS-szolgáltatás, amellyel privát IP-címmel csatlakozhat a virtuális gépekhez. Ebben az architektúrában a központi hálózaton Azure Bastion biztonságos üzemeltetési hozzáférést biztosít a számítási feladatok összetevőihez, és lehetővé teszi az Foundry-összetevőkhöz való hozzáférést. Biztosítja, hogy a rendszergazdák és a támogatási munkatársak biztonságosan csatlakozzanak a virtuális gépekhez anélkül, hogy RDP-/SSH-portokat a nyilvános internethez adnák ki.
Változás az alapkonfigurációtól: Az alaparchitektúrában a számítási feladatokért felelős csapaté ez az összetevő.
A küllős virtuális hálózat az, ahol a számítási feladat üzembe van helyezve.
Változás az alapkonfigurációtól: Az alaparchitektúrában a számítási feladatokért felelős csapaté ez a hálózat.
A felhasználó által definiált útvonalak (UDR-ek) a központi hálózat tűzfalára való bújtatást kényszerítik ki.
Változás a kiindulási állapottól: Az alaparchitektúrában a munkaterhelésért felelős csapat irányítja ezt az útválasztást.
Azure Policy-alapú szabályozási korlátozások és
DeployIfNotExists(DINE) szabályzatok vonatkoznak a számítási feladatok előfizetésére. Ezeket a szabályzatokat közvetlenül a platformcsapat által kezelt felügyeleti csoport szintjén vagy a munka előfizetésére alkalmazhatja.Változás az alapkonfigurációtól: Ezek a szabályzatok újak ebben az architektúrában. A platformcsapat olyan szabályzatokat alkalmaz, amelyek korlátozzák a számítási feladatot. Egyes szabályzatok duplikálhatják a meglévő számítási feladatokra vonatkozó korlátozásokat, vagy új korlátozásokat vezetnek be.
Azure privát DNS-zónák tárolják a privát végpontokhoz tartozó rekordokat, hogy a munkaterhelési összetevők biztonságosan lekérdezhessék a számítási feladatban használt PaaS-szolgáltatások FQDN-jét (teljes minősített tartománynevét). További információ: Azure Private Link és DNS-integráció nagy méretekben.
Változás az alapkonfigurációtól: Az alaparchitektúrában a számítási feladatokért felelős csapaté ez a hálózat. Ebben az architektúrában a platformcsapat kezeli ezt az összetevőt a kapcsolati előfizetés alatt.
A DNS-feloldási szolgáltatás támogatja a küllős virtuális hálózatokat és a helyszíni munkaállomásokat. Ez a szolgáltatás általában Azure Firewall használ DNS-proxyként vagy Azure DNS privát feloldóként. Ebben az architektúrában a szolgáltatás feloldja a hálózati ágból érkező összes DNS-kérés privát végponti DNS-rekordjait. Az Ügynökszolgáltatás megoldási követelményeinek engedélyezéséhez a platformcsapatnak DNS Private Resolvert és csatolt szabálykészleteket kell használnia, vagy gondoskodnia kell arról, hogy a virtuális hálózat DNS-ét a központi megoldáshoz konfigurálja.
Azure DDoS Protection segít megvédeni a nyilvános IP-címeket az elosztott támadásoktól. Ebben az architektúrában a DDoS Protection segít megvédeni az Application Gatewayhez társított nyilvános IP-címet.
Változás az alapkonfigurációtól: Az alaparchitektúra során a számítási feladatok csapata megvásárolja a DDoS Protectiont.
Fontos
Azure célzónák a platform kezdőzóna-előfizetéseinek részeként biztosítják az előző erőforrások egy részét. A terhelési előfizetés más erőforrásokat is biztosít. Ezen erőforrások nagy része a kapcsolati előfizetésben található, amely magában foglalja a Azure ExpressRoute, a Azure VPN Gateway és a DNS Private Resolvert is. Ezek az erőforrások helyszíni hozzáférést és névfeloldásokat biztosítanak. Ezeknek az erőforrásoknak a kezelése nem tartozik a jelen cikk hatókörébe.
Előfizetés beállítása
A számítási feladatokkal foglalkozó csapatnak tájékoztatnia kell a platformcsapatot az architektúra implementálásához szükséges konkrét kezdőzóna-követelményekről. A platformcsapatnak pedig közölnie kell a követelményeit a számítási feladatokkal foglalkozó csapattal.
A számítási feladatokkal foglalkozó csapatnak például részletes információkat kell megadnia a szükséges hálózati területről. A platform csapata ezeket az információkat használja a szükséges erőforrások lefoglalásához. A számítási feladatokkal foglalkozó csapat határozza meg a követelményeket, és a platformcsapat hozzárendeli a megfelelő IP-címeket a virtuális hálózaton belül.
A platformcsapat hozzárendel egy felügyeleti csoportot a számítási feladat üzleti kritikussága és műszaki igényei alapján. Ha például a számítási feladat elérhető az interneten, például ebben az architektúrában, a platformcsapat kiválaszt egy megfelelő felügyeleti csoportot. A szabályozás kialakításához a platformcsapat felügyeleti csoportokat is konfigurál és implementál. A számítási feladatokat a számítási feladat csapatának a szabályozás korlátain belül kell megterveznie és működtetnie. A felügyeleti csoportok jellemző különbségeiről további információt a A Azure célzóna architektúrájának megbontása című témakörben talál.
A platformcsapat beállítja az előfizetést ehhez az architektúrához. Az alábbi szakaszok útmutatást nyújtanak az előfizetés kezdeti beállításához.
Terhelési követelmények és teljesítés
A számítási feladatokért felelős csapatnak és a platformcsapatnak együtt kell működnie olyan részletekben, mint a felügyeleti csoport hozzárendelése, Azure Policy szabályozása és a hálózatkezelés beállítása. Készítsen egy ellenőrzőlistát a követelményekről a platformcsapattal való megbeszélések és tárgyalások indítására. Példaként az alábbi ellenőrzőlista szolgál.
| Tervezési szempont | Az architektúra számítási feladatainak követelményei | |
|---|---|---|
| ☐ | Küllős virtuális hálózatok száma és mérete: A platformcsapat létrehozza és konfigurálja a virtuális hálózatot, majd összekapcsolja a regionális központtal, hogy azt küllőként jelölje ki. Azt is biztosítaniuk kell, hogy a hálózat képes legyen alkalmazkodni a számítási feladatok jövőbeli növekedéséhez. Ezeknek a feladatoknak a hatékony elvégzéséhez ismerniük kell a szükséges küllők számát. | Az összes erőforrás üzembe helyezése egyetlen, dedikált küllős virtuális hálózaton. Igényeljen legalább /21 egybefüggő címteret az alapvető számítási feladathoz és egy privát MCP-kiszolgáló gazdagéphez. Több címterület kérése, ha egymás mellett történő üzembe helyezésre van szükség. A következő tényezők határozzák meg a legtöbb IP-címigényt: - Az Application Gateway követelményei az alhálózat méretére (rögzített méret). - Privát végpontok egyetlen IP-címmel a PaaS-szolgáltatásokhoz (rögzített méret). - A build agentek alhálózatának mérete (fix méret). - Az Agent Service egy /24 előtagon belüli alhálózatot igényel az ügynök kimenő forgalmát kezelő adatproxy elhelyezéséhez. - A Azure Container Apps üzemeltetett privát MCP-kiszolgálók dedikált alhálózatot igényelnek. Ez az architektúra egy, a Microsoft.App/environments számára delegált /24 előtagot foglal le. |
| ☐ | Virtuális hálózati címelőtagok: A platformcsapat általában a meglévő konvenciók alapján rendel IP-címeket, elkerüli a társhálózatokkal való átfedést, valamint az IP-címkezelési (IPAM) rendszeren belüli rendelkezésre állást. | Az ügynökintegrációs alhálózatnak érvényes magáncímelőtagot kell használnia. Az Agent Service támogatja azokat az alhálózatokat, amelyek az 10.0.0.0/8, 172.16.0.0/12 vagy 192.168.0.0/16 használják. Kérje meg a platformcsapatot, hogy biztosítson egy csomópontot, amely érvényes címelőtaggal ellátott az ügynök alhálózatának. |
| ☐ | Üzembe helyezési régió: A platformcsapatnak a számítási feladatok erőforrásaival azonos régióban kell üzembe helyeznie egy központot. | A számítási feladathoz kiválasztott régió és a mögöttes számítási erőforrások régióinak kommunikálása. Győződjön meg arról, hogy a régiók támogatják a rendelkezésre állási zónákat. Azure OpenAI a Foundry Models-ben korlátozott a regionális elérhetősége. |
| ☐ | Adatszuverenitás: A platformcsapatnak be kell tartania a számítási feladathoz szükséges összes adattárolási követelményt. | Ha a számítási feladat szigorú adattárolást igényel, győződjön meg arról, hogy a platformcsapat nem duplikálja Azure Diagnostics naplókat, és nem küld adatokat a Purview-nak olyan régióban, amelyet a követelmények nem engedélyezettek. |
| ☐ | A forgalom típusa, mennyisége és mintázata: A platformcsapatnak meg kell határoznia a számítási feladat megosztott erőforrásainak bejövő és kimenő követelményeit. | Adja meg az alábbi tényezőket: – Hogyan kell a felhasználóknak felhasználniuk ezt a munkaterhelést. – Hogyan használja fel ez a számítási feladat a környező erőforrásokat. - A konfigurált átviteli protokoll. - A forgalmi minta, valamint a várható csúcsidő és csúcsidőn kívüli idő. Kommunikáljon, ha nagy számú egyidejű internetkapcsolatra (csevegésre) számít, és amikor a számítási feladat minimális hálózati forgalmat (háttérzajt) hoz létre. |
| ☐ | Tűzfalkonfiguráció: A platformcsapatnak szabályokat kell beállítania a jogszerű kimenő forgalom engedélyezéséhez. | Osszon meg részleteket a spoke-hálózatból származó kimenő forgalomról, beleértve az ügynök és a privát MCP-kiszolgáló forgalmát is. Build ügynök és jump box gépek rendszeres operációs rendszer javítást igényelnek. Előfordulhat, hogy az ügynököknek internetes földelési forrásokkal, nyilvános MCP-kiszolgálókkal, eszközökkel vagy más, a számítási feladaton kívül üzemeltetett ügynökökkel kell kommunikálniuk. |
| ☐ | Speciális szerepkörökből érkező bejövő forgalom: A platformcsapatnak hálózati hozzáférést kell biztosítania a megadott szerepkörökhöz a számítási feladathoz, és megfelelő szegmentálást kell megvalósítania. | A platformcsapattal együttműködve állapítsa meg a következő szerepkörök engedélyezett hozzáférésének legjobb módját: - Adattudósok és fejlesztők, amelyek a vállalati hálózati kapcsolatok munkaállomásairól érik el az Foundry portált – A számítási réteghez erőforrás-kezelésű ugróboxon keresztül hozzáférő operátorok |
| ☐ |
Nyilvános internet-hozzáférés a számítási feladathoz: A platform csapata ezeket az információkat használja a kockázatértékeléshez, amely számos döntést hoz: - A számítási feladat elhelyezése egy megfelelő védőkorlátokkal rendelkező felügyeleti csoportban - Elosztott szolgáltatásmegtagadási (DDoS) védelem a számítási feladatokat ellátó csapat által jelentett nyilvános IP-címhez - TLS-tanúsítványok beszerzése és kezelése |
Tájékoztassa a platformcsapatot a bejövő forgalom profiljáról: – Az Application Gateway nyilvános IP-címére irányuló internetes forgalom - A TLS-tanúsítványok beszerzéséhez tartozó nyilvános IP-címhez társított teljes tartománynevek (FQDN-ek) |
| ☐ | Private végponthasználat: A platformcsapatnak be kell állítania Azure privát DNS-zónákat a privát végpontokhoz, és gondoskodnia kell arról, hogy a központi hálózat tűzfala megfelelően hajtsa végre a DNS-feloldást. | Tájékoztassa a platformcsapatot a privát végpontokat használó összes erőforrásról, beleértve a következő erőforrásokat: - AI-keresés - Azure Cosmos DB a NoSQL-hez - Kulcs tároló -Öntöde - Tárfiókok Ismerje meg, hogy a központ hogyan kezeli a DNS-feloldást, és határozza meg a számítási feladatokat ellátó csapat feladatait a privát DNS-zónarekordok, a DNS Private Resolver-szabályok összekapcsolása vagy a virtuális hálózat DNS-beállításainak kezeléséhez. |
| ☐ |
Központosított AI-erőforrások: A platformcsapatnak tisztában kell lennie a modellek és a platformok várható használatával. Ezeket az információkat arra használják, hogy hálózatot alakítsanak ki a szervezeten belüli központosított AI-erőforrásokkal. Minden szervezet saját AI-bevezetési és szabályozási terveket határoz meg, és a számítási feladatokat végző csapatnak ezeken a korlátozásokon belül kell működnie. |
Tájékoztassa a platformcsapatot a használni kívánt AI- és gépi tanulási erőforrásokról. Ez az architektúra a Foundry-modellekben üzemeltetett Öntödei, Ügynökszolgáltatás- és generatív alapmodelleket használja. Világosan megismerheti, hogy mely központosított AI-szolgáltatásokat kell használnia, és hogy ezek a függőségek milyen hatással vannak a számítási feladatra. |
Fontos
A platformcsapatnak olyan előfizetés-feldolgozási folyamatot kell követnie, amely strukturált kérdéseket használ a számítási feladatokért felelős csapat információinak gyűjtésére. Ezek a kérdések szervezetenként eltérőek lehetnek, de a cél az előfizetések hatékony implementálásához szükséges adatok összegyűjtése. További információkért lásd az előfizetési automatát.
Compute
A vezénylési réteg és a csevegési felhasználói felület változatlan marad, mint az alaparchitektúra.
hálózat
Az alaparchitektúra a számítási feladatot egyetlen virtuális hálózaton helyezi üzembe.
Változás az alapkonfigurációtól: Ez az architektúra két virtuális hálózatra osztja a számítási feladatot. Az egyik hálózat számítási feladat összetevőit üzemelteti. A másik hálózat kezeli az internetkapcsolatot és a hibrid kapcsolatot. A platformcsapat határozza meg, hogy a számítási feladat virtuális hálózata hogyan integrálható a szervezet nagyobb hálózati architektúrájával, amely általában egy küllős topológiát követ.
Töltse le az architektúra Visio fájlját.
Központi virtuális hálózat: Ez a virtuális hálózat regionális központként szolgál, amely olyan központosított és gyakran megosztott szolgáltatásokat tartalmaz, amelyek ugyanazon a régióban kommunikálnak a számítási feladatok erőforrásaival. A központ a kapcsolati előfizetésben található. A platformcsapat a hálózat erőforrásainak tulajdonosa.
Küllős virtuális hálózat: Ebben az architektúrában az alaparchitektúra egyetlen virtuális hálózata lényegében küllős virtuális hálózattá válik. A platformcsapat ezt a küllős hálózatot a központi hálózathoz társítja. Ők birtokolják és kezelik a spoke-hálózatot, beleértve a peeringet és a DNS-konfigurációt. A számítási feladatokért felelős csapat birtokolja a hálózat erőforrásait, beleértve az alhálózatait is. Ez a hálózat számos számítási feladatot tartalmazó erőforrást tartalmaz.
A felügyelet és a tulajdonjog ezen felosztása miatt a számítási feladat csapatának egyértelműen közölnie kell a számítási feladat követelményeit a platformcsapattal.
Fontos
A platformcsapat számára: Ne hozzon létre közvetlen összeköttetést egy küllős hálózat és egy másik küllős hálózat között, kivéve, ha a számítási feladathoz kifejezetten szükség van rá. Ez a gyakorlat védi a számítási feladat szegmentálási céljait. A csapatnak elő kell segítenie az összes tranzitív virtuális hálózati kapcsolatot. Ha azonban a munkaterhelési landing zone csapatai közvetlenül, saját kezelésű privát végpontok használatával összekapcsolják a hálózataikat, az Ön csapata nem kezeli ezeket a kapcsolatokat.
Ismerje meg, hogy a külső csapatok mely számítási feladatokat kezelik. Ismerje meg például a csevegőügynökök közötti hálózati kapcsolatot, valamint egy másik csapat által kezelt, földi környezetvektor-adatbázist.
Virtuális hálózati alhálózatok
A küllős virtuális hálózaton alhálózatokat hozhat létre és oszthat ki a számítási feladatokra vonatkozó követelmények alapján. Szegmentálás biztosításához alkalmazzon olyan vezérlőket, amelyek korlátozzák az alhálózatokra irányuló és kimenő forgalmat. Ez az architektúra nem ad hozzá alhálózatokat az alaparchitektúra alhálózatainál túl. A landing zone hálózati architektúrája már nem igényli a AzureFirewallSubnet vagy AzureBastionSubnet alhálózatokat, mert ezeket a képességeket a platformcsapat valószínűleg a platform-előfizetésekben üzemelteti.
A számítási feladatok Azure célzónában való üzembe helyezésekor továbbra is helyi hálózati vezérlőket kell implementálnia. A szervezet további hálózati korlátozásokat írhat elő az adatszivárgás elleni védelem és a központi biztonsági üzemeltetési központ és az informatikai hálózati csapat láthatóságának biztosítása érdekében.
Bejövő forgalom
A bejövő forgalom ugyanaz marad, mint az alaparchitektúra.
A számítási feladatba való nyilvános internetes bejövő forgalomhoz kapcsolódó erőforrásokat kezelheti. Ebben az architektúrában például az Application Gateway és a nyilvános IP-címe a külső hálózaton található, nem pedig a központi hálózaton. Egyes szervezetek központi szegélyhálózat (más néven DMZ, demilitarizált zóna és szűrt alhálózat) használatával helyeznek el bejövő erőforrásokat egy csatlakozási előfizetésben. Az adott topológiával való integráció a jelen cikk hatókörén kívül esik.
A bejövő forgalom vizsgálatának alternatív megközelítése
Ez az architektúra nem használja a Azure Firewall a bejövő forgalom vizsgálatára, de néha a cégirányítás megköveteli. Ezekben az esetekben a platformcsapat támogatja az implementációt, hogy a számítási feladatokat végző csapatok további behatolásészlelési és megelőzési réteget biztosítsanak. Ez a réteg segít blokkolni a nem kívánt bejövő forgalmat. A topológia támogatásához ez az architektúra több UDR-konfigurációt igényel. További információért lásd a Teljes felügyelet hálózatot webalkalmazásokhoz az Azure Firewall és az Application Gateway használatával.
DNS-konfiguráció
Az alaparchitektúra minden összetevője közvetlenül a DNS-feloldáshoz használja a Azure DNS.
Változás az alapkonfigurációtól: Ebben az architektúrában általában egy vagy több DNS-kiszolgáló kezeli a DNS-feloldásokat. A virtuális hálózat létrehozásakor a virtuális hálózat DNS-tulajdonságait már ennek megfelelően kell beállítani. A számítási feladatokat ellátó csapatnak nem kell ismernie a DNS-szolgáltatás implementálási részleteit.
Ez az architektúra az alábbi módokon konfigurálja a számítási feladatok összetevőit a DNS-sel.
| Összetevő | DNS-konfiguráció |
|---|---|
| Application Gateway | Virtuális hálózattól örökölt |
| App Service (csevegőfelület) | Virtuális hálózattól örökölt |
| AI-keresés | Ez nem bírálható felül, az Azure DNS-t használja. |
| Öntöde | Ez nem bírálható felül, az Azure DNS-t használja. |
| Ügynökszolgáltatás | Ez nem bírálható felül, az Azure DNS-t használja. |
| Privát MCP-kiszolgálók | Virtuális hálózattól örökölt |
| Azure Cosmos DB | Ez nem bírálható felül, az Azure DNS-t használja. |
| ugródoboz | Virtuális hálózattól örökölt |
| Ügynökök létrehozása | Virtuális hálózattól örökölt |
Ez az architektúra nem konfigurálja a DNS-beállításokat olyan összetevőkhöz, amelyek nem kezdeményeznek kimenő kommunikációt. Ezek az összetevők nem igényelnek DNS-feloldást.
Az architektúra számos összetevője a központ DNS-kiszolgálóin üzemeltetett DNS-rekordokra támaszkodik a számítási feladat privát végpontjainak feloldásához. További információ: Azure privát DNS-zónák.
Ha a központi DNS-feloldás nem lehetséges, ezek az összetevők a következő korlátozásokkal szembesülnek:
A platformcsapat nem tud DNS-kéréseket naplózni, ami megsértheti a szervezeti biztonsági csapat követelményeit.
A Private Link által közzétett szolgáltatások feloldása a landing zone-ban vagy más számítási feladatok landing zone-jaiban lehetetlen lehet.
Javasoljuk, hogy ismerje meg, hogyan kezeli a platformcsapat a DNS-t. További információ: Private Link és DNS-integráció nagy méretekben. Ha olyan összetevőket ad hozzá, amelyek közvetlenül az Azure DNS-től függenek, komplexitást vihet be a platform által biztosított DNS-topológiába. Az összetevők újratervezésével vagy a kivételek egyeztetésével minimalizálható az összetettség.
Kimenő forgalom
Az alaparchitektúrában minden kimenő forgalom az internetre az Azure Firewallon keresztül halad.
Eltérés az alapértéktől: Ebben az architektúrában a platform egy olyan UDR-t biztosít, amely az általa üzemeltetett Azure Firewall példányra mutat. Alkalmazza ezt az UDR-t az alaparchitektúra ugyanazon alhálózataira.
A spoke virtuális hálózatot elhagyó összes forgalom, beleértve az adatproxy által indított ügynök kimenő forgalmát is, az ügökintegrációs alhálózatból a peeringgel kapcsolt hubhálózaton keresztül, egy kimenő tűzfalon át halad.
Töltse le az architektúra Visio fájlját.
A Key Vault, a Foundry és más szolgáltatások privát végpontjaival folytatott kelet-nyugati ügyfélkommunikáció ugyanaz marad, mint a baseline architektúra. Az előző diagram nem tartalmazza ezt az elérési utat.
Internetes forgalom átirányítása a tűzfalra
A küllős hálózat összes alhálózata tartalmaz egy útvonalat, amely az összes internetkapcsolattal rendelkező forgalmat vagy 0.0.0.0/0 forgalmat a központ Azure Firewall-példányára irányítja.
| Összetevő | Az internetes forgalom központon keresztüli kényszerítésére szolgáló mechanizmus |
|---|---|
| Application Gateway | Nincs. A szolgáltatásból származó, internetes forgalom nem irányítható át a platformcsapat tűzfalán keresztül. |
| App Service (csevegőfelület) | A regionális virtuális hálózati integráció és a vnetRouteAllEnabled beállítás engedélyezve van. |
| AI-keresés | Nincs. A szolgáltatásból származó forgalom nem kényszeríthető tűzfalon keresztül. Ez az architektúra nem használ készségeket. |
| Ügynökszolgáltatás | A snet-agentsEgress alhálózatra alkalmazott UDR. |
| Privát MCP-kiszolgálók | Az snet-mcpServers alhálózatra alkalmazott UDR. |
| Ugródobozok | A snet-jumpBoxes alhálózatra alkalmazott UDR. |
| Ügynökök létrehozása | A snet-agents alhálózatára alkalmazott UDR. |
Ez az architektúra nem konfigurálja a kimenő kommunikációt nem kezdeményező összetevők kényszerített bújtatását.
Azon összetevők vagy szolgáltatások esetében, amelyek nem irányíthatják a kimenő forgalmat a központon keresztül, a számítási feladatokkal kapcsolatos csapatnak igazodnia kell a szervezeti követelményekhez. A követelmények teljesítéséhez használjon kompenzáló vezérlőket, tervezzen újra a számítási feladatokat, hogy kizárja a nem támogatott funkciókat, vagy formális kivételeket kérjen. Ön a felelős az adatkiszivárgás és a visszaélések mérsékléséért.
Alkalmazza a platform által biztosított internetes útvonalat az összes alhálózatra, még akkor is, ha nem számít arra, hogy az alhálózat kimenő forgalommal rendelkezik. Ez a megközelítés biztosítja, hogy az alhálózat váratlan telepítései rutinszerű kimenet szűrésén átessenek. Az olyan alhálózatok esetében, amelyek privát végpontokat tartalmaznak, engedélyezze a hálózati irányelveket a teljes útválasztás és az NSG-vezérlés támogatására.
Ez az útvonalkonfiguráció biztosítja, hogy az App Service, az Foundry és projektjei, valamint a számítási feladat virtuális hálózatából származó egyéb szolgáltatások kimenő kapcsolatait a rendszer megvizsgálja és szabályozza.
privát DNS-zónák Azure
A kelet-nyugati forgalomhoz privát végpontokat használó számítási feladatokhoz DNS-zónarekordok szükségesek a konfigurált DNS-szolgáltatóban. A Private Link támogatásához ez az architektúra számos DNS-zónarekordra támaszkodik olyan szolgáltatások esetében, mint a Key Vault, a Foundry és a Azure Storage.
Változás az alapkonfigurációtól: Az alaparchitektúra esetében a számítási feladatok csapata közvetlenül felügyeli a privát DNS-zónákat. Ebben az architektúrában a platformcsapat általában privát DNS-zónákat tart fenn. A számítási feladatokkal foglalkozó csapatnak világosan meg kell értenie a platformcsapat követelményeit és elvárásait a privát DNS-zónarekordok kezelésével kapcsolatban. A platformcsapat a privát DNS-zónarekordok helyett más technológiát is használhat.
Ebben az architektúrában a platformcsapatnak dns-t kell beállítania a következő Foundry FQDN API-végpontokhoz:
privatelink.services.ai.azure.comprivatelink.openai.azure.comprivatelink.cognitiveservices.azure.com
A platformcsapatnak a következő teljes tartománynevekhez is be kell állítania a DNS-t, amelyek az Agent Service szolgáltatásbeli függőségei:
privatelink.search.windows.netprivatelink.blob.core.windows.netprivatelink.documents.azure.com
Fontos
A DNS feloldásának helyesen kell működnie a küllő virtuális hálózaton belül, mielőtt üzembe helyezi az Agent szolgáltatás képességgazda kiszolgálóját, illetve az Agent szolgáltatás működése során. Az Agent Szolgáltatás funkció nem használja a függőleges virtuális hálózat DNS-konfigurációját. Ezért javasoljuk, hogy a platformcsapat konfiguráljon egy szabálykészletet a munkaterhelés privát DNS-zónáihoz a DNS Private Resolverben, és kapcsolja ezeket a szabályokat a munkaterhelési landing zone küllőjéhez.
Mielőtt üzembe helyezi a Foundryt és annak ügynöki funkcióját, meg kell várnia, amíg az Ügynökszolgáltatás függőségei teljes mértékben feloldhatók a küllős hálózaton belül a privát végpontjaik irányába. Ez a követelmény különösen fontos, ha a DINE-szabályzatok kezelik a DNS privát zónáinak frissítéseit. Ha megkísérli üzembe helyezni az Ügynökszolgáltatás képességet, mielőtt a privát DNS-rekordok feloldhatók az alhálózaton belülről, az üzembe helyezés meghiúsul.
A platformcsapatnak a privát DNS-zónákat is üzemeltetnie kell az architektúrában található egyéb számítási feladatok függőségeihez:
privatelink.vaultcore.azure.netprivatelink.azurewebsites.net
Adatelemző és ügynök fejlesztői hozzáférése
Az alaparchitektúrához hasonlóan ez az architektúra letiltja az Foundry portálhoz és más böngészőalapú szolgáltatásokhoz való nyilvános bejövő hozzáférést. Az alaparchitektúra üzembe helyez egy jump boxot, amely egy forrás IP-címet biztosít a böngészőnek a virtuális hálózatról, amelyet a különböző számítási feladatok szerepkörei használnak.
Amikor a számítási feladat egy Azure célzónához csatlakozik, a csapat további hozzáférési lehetőségeket kap. A platformcsapattal együttműködve ellenőrizze, hogy magánjellegű hozzáférést kaphat-e a különböző böngészőalapú Foundry-portálokhoz a virtuális gép (VM) kezelése és szabályozása nélkül. Ez a hozzáférés egy meglévő ExpressRoute- vagy VPN Gateway-kapcsolat tranzitív útválasztásán keresztül lehetséges.
A natív munkaállomás-alapú hozzáférés helyszíni útválasztást és DNS-feloldást igényel, amelyet a platform csapata nyújthat. Vegye fel ezt a követelményt az előfizetési értékesítési kérelembe.
Ezen portálokhoz natív munkaállomás-alapú hozzáférés biztosítása javítja a hatékonyságot, és leegyszerűsíti a karbantartást a virtuális gépek ugrómezőinek kezeléséhez képest.
A jump box szerepe
Az architektúrában szereplő jump box az üzemeltetési támogatásra nyújt megoldást, nem a futásidőre, illetve nem az AI- és gépi tanulás fejlesztésére. A jump box elháríthatja a DNS- és hálózati útválasztási problémákat, mivel belső hálózati hozzáférést biztosít az egyébként külsőleg elérhetetlen összetevőkhöz.
Az alaparchitektúrában az Azure Bastion hozzáfér a jump boxhoz, amelyet ön kezel.
Ebben az architektúrában a Azure Bastion a kapcsolati előfizetésben a platformcsapat által kezelt megosztott regionális erőforrásként van üzembe helyezve. Ebben az architektúrában a használati eset bemutatásához az Azure Bastion a kapcsolati előfizetésben található, és azt a csapat nem telepíti.
A jump boxként szolgáló virtuális gépnek meg kell felelnie a virtuális gépekre vonatkozó szervezeti követelményeknek. Ezek a követelmények tartalmazhatnak olyan elemeket, mint a vállalati identitások a Microsoft Entra ID-ben, meghatározott alaprendszerképek és javítási rendszerek.
Erőforrások figyelése
A Azure célzónaplatform megosztott megfigyelhetőségi erőforrásokat biztosít a felügyeleti előfizetés részeként. Javasoljuk azonban, hogy saját monitorozási erőforrásokat építsen ki a számítási feladat tulajdonjogi feladatainak megkönnyítése érdekében. Ez a megközelítés igazodik az alaparchitektúrához.
A következő monitorozási erőforrásokat kell üzembe helyezned:
Az Application Insights a csapat alkalmazásteljesítmény-kezelési (APM) szolgáltatásaként szolgál. Ezt a szolgáltatást a csevegés felhasználói felületén, az Ügynökszolgáltatásban és a modellekben konfigurálhatja.
Az Azure Monitor Naplók munkaterület központi gyűjtőpontként szolgál a számítási feladat tulajdonában lévő Azure erőforrások összes naplója és metrikája számára.
Az alaparchitektúrához hasonlóan minden erőforrásnak el kell küldenie Azure diagnosztikai naplókat a csapat által kiosztott Azure Monitor Naplók munkaterületre. Ez a konfiguráció az infrastruktúra részét képezi az erőforrások kódként (IaC) történő üzembe helyezésének. Előfordulhat, hogy naplókat is el kell küldenie egy központi Azure Monitor Naplók munkaterületre. Azure célzónákban ez a munkaterület általában a felügyeleti előfizetésben található.
A platformért felelős csapat több olyan folyamattal rendelkezhet, amelyek hatással vannak a munkaterhelési landing zone-ban lévő erőforrásokra. Például DINE-szabályzatokkal konfigurálhatják a diagnosztikát, és naplókat küldhetnek a központosított felügyeleti előfizetéseknek. Emellett Azure Monitor alapszintű riasztásokat is alkalmazhatnak a szabályzaton keresztül. Győződjön meg arról, hogy a megvalósítás nem blokkolja ezeket a további naplózási és riasztási folyamatokat.
Azure Policy
Az alaparchitektúra általános szabályzatokat javasol a számítási feladatok szabályozásához. Ha ezt az architektúrát egy workload landing zone-ban helyezi üzembe, nem kell további szabályzatokat hozzáadnia vagy eltávolítania. A szabályozás kikényszerítése és a számítási feladat biztonságának növelése érdekében továbbra is alkalmazza a szabályzatokat az előfizetésre, az erőforráscsoportokra vagy az erőforrásokra.
A munkaterhelés landing zone-jának előfizetése várhatóan már a munkaterhelés üzembe helyezése előtt rendelkezik meglévő szabályzatokkal. Egyes szabályzatok az szervezeti irányítást úgy segítik, hogy ellenőriznek vagy letiltanak bizonyos konfigurációkat a telepítések során.
Az alábbi példaszabályzatok a számítási feladatok üzembe helyezésének összetettségéhez vezethetnek:
Policy:Secrets [in Key Vault] a megadott maximális érvényességi idővel kell rendelkeznie.
Complication: A Foundry titkok tárolására képes egy csatlakoztatott Key Vaultban, amely a tudással és eszközkapcsolatokkal kapcsolatos. Ezek a titkos kódok nem rendelkeznek a szolgáltatás által megadott lejárati dátummal. Az alaparchitektúra nem használja ezeket a típusú kapcsolatokat, de az architektúrát kiterjesztheti a támogatásukra.
Szabályzat:Az AI Search-szolgáltatásoknak ügyfél által felügyelt kulcsokkal kell titkosítaniuk az inaktív adatokat.
Komplikáció: Ez az architektúra nem igényel ügyfél által felügyelt kulcsokat. Az architektúrát azonban kiterjesztheti a támogatásukra.
Házirend:Az öntödei modelleket nem lehet előnézetben megtekinteni.
Komplikáció: A fejlesztés során használhat egy előzetes modellt, amely várhatóan általánosan elérhető lesz, mire engedélyezi az ügynökképességet az éles számítási feladatban.
A platformcsapatok DINE-szabályzatokat alkalmazhatnak az egy munkaterhelési landing zone-előfizetésbe történő automatikus üzembe helyezések kezelésére. Az IaC-sablonokba előzetesen beépítheti és tesztelheti a platform által kezdeményezett korlátozásokat és módosításokat. Ha a platformcsapat olyan Azure szabályzatokat használ, amelyek ütköznek az alkalmazás követelményeivel, egyeztethet egy megoldást.
Változások kezelése az idő függvényében
Ebben az architektúrában a platform által biztosított szolgáltatások és műveletek külső függőségekként szolgálnak. A platformcsapat továbbra is alkalmazza a módosításokat, a kezdőzónákat, és alkalmazza a költségvezérlőket. Előfordulhat, hogy a platformcsapat nem rangsorolja az egyes számítási feladatokat. A függőségek módosítása, például a tűzfal módosítása több számítási feladatot is érinthet.
Az összes külső függőség kezeléséhez hatékonyan és időben kell kommunikálnia a platformcsapatokkal. Fontos, hogy a módosításokat előzetesen tesztelje, hogy ne legyenek negatív hatással a számítási feladatokra.
A számítási feladatot érintő platformmódosítások
Ebben az architektúrában a platformcsapat a következő erőforrásokat kezeli. Ezeknek az erőforrásoknak a módosítása hatással lehet a számítási feladat megbízhatóságára, biztonságára, műveleteire és teljesítménycéljaira. Értékelje ki ezeket a módosításokat, mielőtt a platformcsapat implementálná őket, hogy megállapítsa, hogyan befolyásolják a számítási feladatokat.
Azure szabályzatok: A Azure házirendek módosításai hatással lehetnek a számítási feladatok erőforrásaira és függőségeire. Ezek a módosítások közé tartozhatnak a közvetlen szabályzatfrissítések vagy a kezdőzóna új felügyeleticsoport-hierarchiába való áthelyezése. Előfordulhat, hogy ezek a módosítások észrevétlenek maradnak, amíg új üzembe helyezés nem történik, ezért alaposan tesztelnie kell őket.
Example: A szabályzatok már nem teszik lehetővé az ügyfél által felügyelt kulcstitkosítást igénylő Azure Cosmos DB példányok üzembe helyezését, és az architektúra Microsoft felügyelt kulcstitkosítást használ.
Tűzfalszabályok: A tűzfalszabályok módosítása hatással lehet a számítási feladat virtuális hálózatára vagy az összes forgalomra széles körben alkalmazandó szabályokra. Ezek a módosítások blokkolhatják a forgalmat, és akár csendes folyamathibákat is okozhatnak. Ezek a lehetséges problémák mind a kimenő tűzfalra, mind az Azure Virtual Network Manager alkalmazott NSG-szabályokra vonatkoznak.
Példa: A Bing API-k felé irányuló blokkolt forgalom sikertelen ügynökeszköz-hívásokat eredményez az internetes földelési adatokhoz.
Útválasztás a központi hálózaton: A hubon az útválasztás tranzitív jellegének változásai hatással lehetnek a számítási feladatok működésére, ha egy számítási feladat más virtuális hálózatokhoz való útválasztástól függ.
Példa: Az útválasztási változás megakadályozza, hogy az Foundry-ügynökök hozzáférjenek egy másik csapat által üzemeltetett vektortárolóhoz, vagy megakadályozzák, hogy az adatelemzési csapatok hozzáférjenek az Foundry portálhoz a munkaállomásaikról.
Azure Bastion gazdagép: Az Azure Bastion gazdagép rendelkezésre állásának vagy konfigurációjának módosításai.
Példa: A konfiguráció módosítása megakadályozza a jump boxok és a build ügynök virtuális gépek elérését.
A platformot érintő számítási feladatok változásai
Az alábbi példák a számítási feladatok azon módosításait ismertetik, amelyeket közölnie kell a platformcsapattal. A platformcsapatnak az új módosítások érvénybe lépése előtt ellenőriznie kell a platformszolgáltatás megbízhatósági, biztonsági, üzemeltetési és teljesítménycéljait.
Hálózati kimenő forgalom: Monitorozza a hálózati kimenő forgalom jelentős növekedését, hogy a számítási feladat ne váljon zajos szomszédjává a hálózati eszközökön. Ez a probléma hatással lehet más számítási feladatok teljesítmény- vagy megbízhatósági céljaira. Ez az architektúra többnyire önálló, és nem valószínű, hogy jelentős változást tapasztal a kimenő forgalmi mintákban.
Nyilvános hozzáférés: A számítási feladatok összetevőinek nyilvános hozzáférésének módosítása további tesztelést igényelhet. Előfordulhat, hogy a platformcsapat áthelyezi a számítási feladatot egy másik felügyeleti csoportba.
Példa: Ebben az architektúrában, ha eltávolítja a nyilvános IP-címet az Application Gatewayből, és csak belsővé teszi az alkalmazást, a számítási feladat internetes kitettsége megváltozik. Egy másik példa a böngészőalapú AI-portálok internetes kitettsége, amit nem ajánlunk.
Üzleti kritikussági minősítés: A számítási feladat szolgáltatásiszint-szerződéseinek (SLA-k) módosítása új együttműködési megközelítést igényelhet a platform és a számítási feladatokat végző csapatok között.
Példa: A megnövekedett bevezetés és a sikeresség miatt a számítási feladat kritikusan áttérhet az alacsonyról a magas üzleti szintre.
Adatszuverenitás: Az adatszuverenitási követelmények módosítása esetén előfordulhat, hogy a platformcsapatnak módosítania kell a naplógyűjtési tervét, támogatnia kell az Ön munkaterhelésének Purview-integrációját, vagy támogatnia kell a szervezet biztonsági információ- és eseménykezelési (SIEM) megoldását.
Példa: Előfordulhat, hogy a számítási feladat megköveteli, hogy az ügynökszál összes adata földrajzi határokon belül maradjon. Ha a Foundry purview-hoz vagy SIEM-hez csatlakozik, gondoskodnia kell arról, hogy a felhasználók adatai ne replikálódjanak olyan régióba, amely megsérti a jogszabályi követelményeket.
Vállalati architektúra csapata
Egyes szervezetek nagyvállalati architektúra-csapattal rendelkeznek, amelyek befolyásolhatják a számítási feladat és az architektúra kialakítását. Ez a csapat ismeri a vállalat AI bevezetésének stratégiáját, valamint a A számítási feladatok Azure tervezésére vonatkozó alapelveit és ajánlásait. Működjön együtt ezzel a csapattal annak érdekében, hogy ez a csevegési számítási feladat megfeleljen a forgatókönyv-specifikus célkitűzéseknek, és összhangban legyen a szervezeti stratégiával és javaslatokkal.
Megfontolások
Ezek a szempontok implementálják a Azure Well-Architected-keretrendszer alappilléreit, amelyek a számítási feladatok minőségének javítása érdekében használható vezérelvek. További információ: Well-Architected Framework.
Reliability
A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információkért tekintse meg a Megbízhatósági terv felülvizsgálati ellenőrzőlistát.
Ez az architektúra fenntartja az alaparchitektúra megbízhatósági garanciáit. Nem vezet be új megbízhatósági szempontokat az alapvető számítási feladatok összetevőihez.
Kritikus függőségek
A számítási feladat által a platformon és a munkaterhelés célzónájában végrehajtott összes funkciót függőségként kezelje. Az egyes függőségekhez kapcsolattartási módszereket és eszkalációs útvonalakat tartalmazó incidenskezelési tervek karbantartása. Vegye fel ezeket a függőségeket a számítási feladat hibamódjának elemzésébe (FMA).
Vegye figyelembe a következő számítási feladatok függőségeit és példaforgatókönyveit:
Kimenő tűzfal: A központi kimenő tűzfal a számítási feladathoz nem kapcsolódó változásokon megy keresztül. Több számítási feladat is osztozik a tűzfalon.
DNS-feloldás: Ez az architektúra a platformcsapat által a legtöbb erőforráshoz biztosított DNS-t használja, Azure DNS és csatolt DNS-feloldó szabálykészletekkel kombinálva az Agent Service-hez. Ennek eredményeképpen a számítási feladat a privát végpontok DNS-rekordjainak időbeni frissítésétől és a DNS-szolgáltatások rendelkezésre állásától függ.
DINE-szabályzatok: Azure privát DNS-zónák DINE-szabályzatai vagy bármely más platform által biztosított függőség best-effort alapon működnek, és nem tartalmaznak SLA-t. Az architektúra privát végpontjaihoz tartozó DNS-konfiguráció késleltetése például megakadályozhatja, hogy a csevegés felhasználói felülete forgalomra kész legyen, vagy letiltsa az ügynökök számára az Ügynökszolgáltatás-lekérdezések végrehajtását.
Felügyeleti csoport szabályzatai: A környezetek konzisztens szabályzatai támogatják a megbízhatóságot. Győződjön meg arról, hogy az üzem előtti környezetek megfelelnek az éles környezeteknek, hogy pontos tesztelést biztosítsanak, és megakadályozzák a környezetspecifikus eltéréseket, amelyek blokkolhatják az üzembe helyezést vagy a skálázást. További információ: Alkalmazás-fejlesztési környezetek kezelése Azure célzónákban.
Számos ilyen szempont létezhet Azure landing zones nélkül. Együtt kell működnie a platformcsapatokkal ezeknek a problémáknak a megoldása érdekében, és gondoskodnia kell arról, hogy megfeleljen az összes követelménynek. További információ: Függőségek azonosítása.
Biztonság
A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információkért lásd a Biztonsági terv felülvizsgálati ellenőrzőlistát.
Bejövő forgalom vezérlése
Ha el szeretné különíteni a munkaterhelést a szervezet más munkaterhelési küllőitől, alkalmazza az NSG-ket az alhálózatokon, és használja ki a nem tranzitív jelleget és a vezérlőket a regionális elosztó központban. Olyan átfogó NSG-k létrehozása, amelyek csak az alkalmazás és az infrastruktúra bejövő hálózati követelményeit teszik lehetővé. Ne kizárólag a központi hálózat nem tranzitív jellegére támaszkodik a biztonság érdekében.
A platformcsapat Azure biztonsági szabályzatokat implementál. Egy szabályzat például biztosíthatja, hogy az Application Gateway megtagadási módra állított webalkalmazási tűzfallal rendelkezzen, amely korlátozza az előfizetés számára elérhető nyilvános IP-címek számát. Az említett szabályzatok mellett telepítsen további, munkaterhelés-központú szabályzatokat, amelyek megerősítik a bejövő forgalom biztonsági helyzetét.
Az alábbi táblázat példákat mutat be az architektúra bejövő vezérlőire.
| Forrás | Cél | Munkaterhelés vezérlése | A platform vezérlése |
|---|---|---|---|
| internet | Alkalmazásforgalmi folyamatok | Az összes terhelési kérelmet irányítani kell egy NSG-n, egy webalkalmazás tűzfalon és útválasztási szabályok alkalmazásával, mielőtt lehetővé tenné, hogy a nyilvános forgalmat privátra alakítsa át a csevegési felhasználói felület számára. | None |
| internet | Foundry Portal-hozzáférés és adatsík-hozzáférés REST API-val | Az összes hozzáférés megtagadása szolgáltatásszintű konfigurációval. | None |
| internet | Adatsík-hozzáférés az összes szolgáltatáshoz az Application Gateway kivételével | Minden hozzáférés megtagadása NSG-szabályokon és szolgáltatásszintű konfiguráción keresztül. | None |
| Azure Bastion | Ugródoboz és építési ügynök hozzáférés | Alkalmazzon egy NSG-t a jump box alhálózatra, amely blokkolja a távelérési portok felé történő összes forgalmat, kivéve, ha a forrás a platform által kijelölt Azure Bastion alhálózat. | None |
| Telephelyek közötti | Foundry Portal-hozzáférés és adatsík-hozzáférés REST API-val | Minden hozzáférés megtagadása. Ha nem használja a jump boxot, csak az adatelemzők számára engedélyezett alhálózatokban lévő munkaállomásokról engedélyezze a hozzáférést. | Nem tranzitív útválasztás kényszerítése vagy Azure Firewall használata egy Azure Virtual WAN biztonságos központban |
| Egyéb küllők | None | NSG-szabályokkal letiltva. | Nem tranzitív útválasztás kényszerítése vagy Azure Firewall használata egy Virtual WAN biztonságos központban |
Kimenő forgalom szabályozása
Alkalmazza azokat az NSG-szabályokat, amelyek a megoldás szükséges kimenő kapcsolati követelményeit fejezik ki, és minden mást elutasítanak. Ne csak a központi hálózati vezérlőkre hagyatkozz. Munkafolyamat-kezelőként a forráshoz lehető legközelebb kell leállítania a nem kívánt kimenő forgalmat.
A munkaterhelés alhálózatai a virtuális hálózaton belül ön tulajdonában vannak, de a platformcsapat valószínűleg olyan tűzfalszabályokat hozott létre, amelyek kifejezetten az ön által rögzített követelményeket képviselik az előfizetési eljárás részeként. Győződjön meg arról, hogy az alhálózatok és az erőforrás-elhelyezés változásai az architektúra teljes élettartama alatt kompatibilisek maradnak az eredeti kéréssel. A hálózati csapattal együttműködve biztosíthatja a minimális hozzáférésű kimenő forgalom vezérlésének folytonosságát.
Az alábbi táblázat példákat mutat be az architektúra kimenő vezérlőire.
| Végpont | Cél | Munkaterhelés vezérlése | A platform vezérlése |
|---|---|---|---|
| Nyilvános internetes források | Előfordulhat, hogy az ügynök internetes keresést igényel egy Azure OpenAI-kérés létrehozásához | NSG-k alkalmazása az ügynökintegrációs alhálózatra | Tűzfalalkalmazási szabályok alkalmazása külső tudástárakra és eszközökre |
| Nyilvános MCP-kiszolgálók | Az ügynök nyilvános végpontokon keresztül hívja meg a jóváhagyott eszközöket | NSG-k és UDR alkalmazása az ügynökintegrációs alhálózaton | Tűzfalalkalmazási szabályok alkalmazása jóváhagyott MCP-kiszolgáló teljes tartományneveihez |
| Privát MCP-kiszolgálók | Az ügynök privát kapcsolaton keresztül hívja meg a számítási feladat által birtokolt eszközöket | Engedélyezze a 443-as és 31443-as kimenő TCP-portokat az ügynökintegrációs alhálózatból, valamint az ezeknek megfelelő bejövő forgalmat az MCP alhálózaton | None |
| Öntvényműhely adat sík | A csevegési felhasználói felület kommunikál a csevegőügynökkel | TCP/443 engedélyezése az App Service integrációs alhálózatáról az Foundry privát végpont alhálózatára | None |
| Azure Cosmos DB | A memóriaadatbázis elérése az Agent Service-ből | TCP engedélyezése minden porton a Azure Cosmos DB privát végpont alhálózatán | None |
A számítási feladat virtuális hálózatát elhagyó forgalom esetében ez az architektúra a számítási feladatok szintjén az NSG-ken keresztül, a platform szintjén pedig egy központi hálózati tűzfalon keresztül alkalmazza a vezérlőket. Az NSG-k kezdeti, széles körű hálózati forgalmi szabályokat biztosítanak. A platform központjában a tűzfal pontosabb szabályokat alkalmaz a nagyobb biztonság érdekében.
Ez az architektúra nem igényel kelet-nyugati forgalmat a belső összetevők, például az Agent Service és a függő AI Search-példány között a központi hálózaton keresztüli átirányításhoz.
DDoS elleni védelem
Határozza meg, hogy ki alkalmazza a megoldás nyilvános IP-címeit lefedő DDoS Protection-csomagot. Előfordulhat, hogy a platformcsapat IP-címvédelmi csomagokat használ, vagy Azure Policy használ a virtuális hálózatvédelmi csomagok kényszerítéséhez. Ez az architektúra DDoS Protection-lefedettséget igényel, mivel nyilvános IP-címmel rendelkezik az internetről való bejövő forgalomhoz. További információ: Javaslatok a hálózatkezeléshez és a kapcsolathoz.
Identitás- és hozzáférés-kezelés
Hacsak a platformcsapat irányítási automatizálása nem igényel további vezérlőket, ez az architektúra nem vezet be új engedélyezési követelményeket a platformcsapat bevonása miatt. Azure szerepköralapú hozzáférés-vezérlésnek (Azure RBAC) továbbra is teljesítenie kell a minimális jogosultság elvét, amely korlátozott hozzáférést biztosít csak azoknak a személyeknek, akiknek szükségük van rá, és csak szükség esetén. További információért lásd: Ajánlások az identitás- és hozzáférés-kezeléshez.
Tanúsítványok és titkosítás
A csapat általában beszerezi a TLS-tanúsítványt az Application Gateway nyilvános IP-címéhez. A platform csapatával együttműködve megtudhatja, hogyan kell a tanúsítványbeszerzési és felügyeleti folyamatoknak igazodniuk a szervezeti elvárásokhoz.
Az architektúra összes adattárolási szolgáltatása támogatja Microsoft felügyelt vagy ügyfél által felügyelt titkosítási kulcsokat. Használjon ügyfél által felügyelt titkosítási kulcsokat, ha a számítási feladatok tervezése vagy szervezete nagyobb ellenőrzést igényel. Azure célzónák maguk nem határoznak meg egy adott módszert.
Felhőhöz készült Microsoft Defender
A Microsoft Defender for Cloud bázisvonal-architektúrában ismertetett konfigurációt használja. Ha az előfizetési értékesítési folyamat nem engedélyezi automatikusan ezeket a Defender-terveket, győződjön meg arról, hogy ezt a felelősséget a munkacsoportként Önök vállalják.
Microsoft Purview
A Foundry telepítésekor várhatóan a Microsoft Purview natív integrációját kell használnia. Az üzembe helyezés során győződjön meg arról, hogy engedélyezi a Microsoft Purview Adatbiztonságot a Microsoft Öntödei vezérlősíkon. Lásd A Microsoft Purview használata a Microsoft Foundry adatbiztonságának és megfelelőségének kezelésére.
Költségoptimalizálás
A költségoptimalizálás a szükségtelen kiadások csökkentésére és a működési hatékonyság javítására összpontosít. További információt a Költségoptimalizálás tervezési felülvizsgálati ellenőrzőlistájában talál.
Az alaparchitektúra összes költségoptimalizálási stratégiája az architektúra számítási feladatainak erőforrásaira vonatkozik. Ezt a preconfigured becslést használja a Azure díjkalkulátorban a számítási feladatok erőforrásainak költségeinek megértéséhez. Módosítsa az értékeket a használati mintáknak és a regionális díjszabásnak megfelelően.
Ez az architektúra nagy mértékben kihasználja Azure célzóna platform-erőforrások előnyeit. Például az olyan erőforrások, mint a Azure Firewall és a DDoS Protection váltása a számítási feladatokról a platformerőforrásokra. Még akkor is költséghatékonyabb a hozzáadott biztonság és a helyek közötti kapcsolat, ha ezeket az erőforrásokat díjvisszatérítési modellben használja. Használja ki a platformcsapat egyéb központosított ajánlatait, hogy ezeket az előnyöket a számítási feladatra is kiterjessze anélkül, hogy veszélyeztetné a szolgáltatási szintű célkitűzést, a helyreállítási idő célkitűzését vagy a helyreállítási pont célkitűzését.
Note
Az előre konfigurált díjszabási becslés nem tartalmazza a megosztott platform infrastruktúráját, például Azure Firewall, Azure Bastion, DDoS Protection vagy központi hálózati erőforrásokat. A platformcsapat kezeli ezeket az erőforrásokat a platform-előfizetésekben, és a költségek meg vannak osztva a számítási feladatok között.
Fontos
Ne próbálja meg optimalizálni a költségeket az Foundry-függőségek platformerőforrásként való összevonásával. Ezeknek a szolgáltatásoknak továbbra is számítási feladatok erőforrásainak kell maradniuk.
Működési kiválóság
Az Operational Excellence azokat az üzemeltetési folyamatokat fedi le, amelyek üzembe helyeznek egy alkalmazást, és éles környezetben működtetik. További információ: Az operatív kiválóság tervezési felülvizsgálati ellenőrzőlistája.
Továbbra is ön a felelős az alaparchitektúra minden működési kiválósági szempontjaért. Ezek a feladatok közé tartozik a monitorozás, a GenAIOps, a minőségbiztosítás és a biztonságos üzembe helyezési eljárások.
Több fogadó adatainak korrelálása
A számítási feladat Azure Monitor Naplók munkaterülete tárolja a számítási feladat naplóit és metrikáit, valamint annak infrastruktúra-összetevőit. A központi Azure Monitor-naplók munkaterülete azonban gyakran tárol naplókat és metrikákat központosított szolgáltatásokból, például Azure Firewall, DNS Private Resolver és Azure Bastion. Az adatok több fogadóból való korrelációja összetett feladat lehet.
A korrelált adatok segítenek az incidensek elhárításában. Az architektúra triage runbookjának foglalkoznia kell ezzel a helyzetekkel, és tartalmaznia kell a szervezeti kapcsolattartási adatokat, ha a probléma túlmutat a számítási feladatok erőforrásain. A számítási feladatok rendszergazdáinak segítségre lehet szükségük a platformgazdáktól a vállalati hálózatkezelés, a biztonság vagy más platformszolgáltatások naplóbejegyzéseinek korrelálásához.
Fontos
A platformcsapat számára: Ha lehetséges, adjon Azure RBAC engedélyeket a releváns platformerőforrások naplótárolóinak lekérdezésére és olvasására. Engedélyezze a tűzfalnaplókat a hálózati és alkalmazásszabály-értékelésekhez és a DNS-proxyhoz. Az alkalmazáscsapatok ezeket az információkat felhasználhatják a feladatok hibaelhárítására. További információ: Javaslatok a figyeléshez és a fenyegetésészleléshez.
Ügynökök létrehozása
Az architektúra számos szolgáltatása privát végpontokat használ. Az alaparchitektúrához hasonlóan ehhez a kialakításhoz buildügynökökre is szükség lehet. Csapata biztonságosan és megbízhatóan telepíti a build ügynököket. A platformcsapat nem vesz részt ebben a folyamatban.
Győződjön meg arról, hogy a build ügynök kezelése megfelel a szervezeti szabványoknak. Ezek a szabványok magukban foglalhatják a platform által jóváhagyott operációsrendszer-rendszerképek használatát, a javítási ütemezéseket, a megfelelőségi jelentéskészítést és a felhasználói hitelesítési módszereket.
Teljesítményhatékonyság
A teljesítményhatékonyság arra utal, hogy a terhelés képes hatékonyan skálázni a felhasználói igények teljesítésére. További információt a Teljesítményhatékonyság tervezési felülvizsgálati ellenőrzőlistájában talál.
Az alaparchitektúra teljesítményhatékonysági szempontjai is érvényesek erre az architektúrára. A csapat megtartja az irányítást az alkalmazásfolyamatokban lévő erőforrások felett, nem pedig a platformcsapat felett. Skálázza a csevegés felhasználói felületének gazdagépét, nyelvi modelljeit és egyéb összetevőit a számítási feladatok és a költségkorlátok alapján. Az architektúra végső megvalósításától függően vegye figyelembe a következő tényezőket, amikor teljesítménycélok alapján méri a teljesítményt:
- Kimeneti forgalom és helyek közötti késleltetés
- A költségelszigetelés szabályozásának termékváltozat-korlátozásai
Közreműködők
Microsoft fenntartja ezt a cikket. A következő közreműködők írták ezt a cikket.
Fő szerzők:
- Bilal Amjad | Microsoft Cloud megoldástervező
- Freddy Ayala | Microsoft Cloud megoldástervező
- Chad Kittel | Vezető szoftvermérnök – Azure minták és Gyakorlatok
Következő lépés
Megtudhatja, hogyan dolgozhat együtt a technikai részleteken a platformcsapattal.