Magas rendelkezésre állás és rugalmasság Microsoft Foundry projektekhez és Agens Szolgáltatásokhoz

Fontos

A cikkben megjelölt (előzetes verziójú) elemek jelenleg nyilvános előzetes verzióban érhetők el. Ez az előzetes verzió szolgáltatásszint-szerződés nélkül érhető el, és éles számítási feladatokhoz nem javasoljuk. Előfordulhat, hogy bizonyos funkciók nem támogatottak, vagy korlátozott képességekkel rendelkeznek. További információ: Supplemental Terms of Use for Microsoft Azure Previews.

Tervezze meg előre az üzletmenet folytonosságát, és készüljön fel a vészhelyreállításra Microsoft Foundry.

Microsoft arra törekszik, hogy Azure szolgáltatások mindig elérhetők legyenek. Előfordulhat azonban, hogy nem tervezett szolgáltatáskimaradások lépnek fel. Ez a cikk bemutatja a többrégiós üzemelő példányok konfigurálását, az infrastruktúra erőforrásainak megerősítését, a modell üzembe helyezésének rugalmasságának tervezését, valamint a feladatátvételi eljárások előkészítését a Foundry-projektekhez és az Ügynökszolgáltatásokhoz.

Fontos

Maga az Öntöde nem biztosít automatikus feladatátvételt vagy vészhelyreállítást.

Előfeltételek

  • Egy Azure előfizetés. Ha nem rendelkezik ilyen fiókkal, hozzon létre egy ingyenes fiókot.
  • Egy Microsoft Foundry-fiók és -projekt. További információ: Microsoft Foundry rövid útmutató.
  • Az Azure CLI telepítve van. Az ebben a cikkben ismertetett zároláskezelési, Cosmos DB-visszaállítási és ellenőrzési lépésekhez szükséges.
  • Azure Cosmos DB folyamatos biztonsági mentés (7 napos vagy 30 napos szint) engedélyezve az adatbázist üzemeltető enterprise_memory Cosmos DB-fiókon, mielőtt bármilyen incidens történne. Az időponthoz kötött visszaállítás csak akkor érhető el, ha előre nem konfigurálta ezt a funkciót.
  • Megfelelő RBAC-szerepkörök:
    • Közreműködő az erőforráscsoportban az erőforrások üzembe helyezéséhez és konfigurálásához.
    • Az erőforráscsoport vagy az egyes erőforrások tulajdonosa az erőforrás-zárolások létrehozásához és kezeléséhez. A Közreműködő szerepkör nem tartalmazza a következőt Microsoft.Authorization/locks/write: .
    • Felhasználói hozzáférés-rendszergazda az RBAC-szerepkörök felügyelt identitásokhoz való hozzárendeléséhez.
    • Cosmos DB-operátor Azure Cosmos DB konfigurációhoz.
    • Search szolgáltatás közreműködője Azure AI Keresés konfigurációhoz.
    • Storage fiók közreműködője Azure Storage konfigurációhoz.

Fontos

Microsoft és Ön közösen működtetik a Foundry Agent Szolgáltatást. Microsoft futtatja az irányítósíkot és a szolgáltatás-gazdaplatformot. Az állapotalapú függőségek (Azure Cosmos DB, Azure AI Keresés, Azure Storage) tartóssága a Standard ügynök üzembe helyezési mód használatakor öné. Alapszintű módban Microsoft kezeli ezeket az adatösszetevőket, és a helyreállítási lehetőségek korlátozottak. Ez a megosztott felelősségi modell azt jelenti, hogy a HA/DR-tervnek minden ügyfél által felügyelt összetevőre külön-külön kell kiterjednie.

A Foundry Azure szolgáltatásainak azonosítása

A Foundry egy Azure natív szolgáltatás, amelynek kevesebb implicit függősége van, mint a korábbi munkaterület-modellnek. Az öntödei projektek számítási feladatok mintái alapján csatolhatnak erőforrásokat, például lekérést, vezénylést, monitorozást és integrációt. A csatolt erőforrásokat nem kötelezőként kezelni, kivéve, ha a számítási feladathoz szükség van rájuk.

A szolgáltatáskategóriák a következők:

  • Platform-infrastruktúra (Microsoft által felügyelt): Az Microsoft regionálisan működő vezérlősíkok és projekt metaadat-szolgáltatásösszetevők.
  • Opcionális számítási feladatok és integrációs erőforrások (ügyfél által felügyelt): Azure Storage, Azure Key Vault, Azure Container Registry (ACR), Application Insights, Azure Logic Apps, Azure Functions, Azure AI Keresés, Azure Cosmos DB, Azure Event Grid, SharePoint, Microsoft Purview (explicit kapcsolódás) és egyéb kapcsolódási célok.
  • Connections: Külső Azure vagy SaaS-szolgáltatásokra hivatkozó konfigurációs objektumok. Ön birtokolja a magas rendelkezésre állású konfigurációt.

Ezek közül az opcionális erőforrások közül egyik sem, például a Key Vault, a Storage, az ACR és az Application Insights, maga az Foundry-erőforrásmodell kemény függőségei, bár a megoldáshoz szükség lehet rájuk. Tervezzen számítási feladatonként, és ne feltételezzen rögzített kötelező készletet.

Erőforrás típusa Példaszolgáltatások Felügyeli: Megjegyzések a rendelkezésre állásról
Platforminfrastruktúra Öntödei vezérlősík, projekt metaadatai Microsoft Regionális; nincs ügyfélművelet a zónakonfigurációhoz.
Állapottárolók (Standard agent mód) Azure Cosmos DB, Azure AI Keresés, Azure Storage Ön Redundancia, biztonsági mentés, replikáció konfigurálása.
Biztonság és titkos kódok Azure Key Vault Ön Automatikus zónaredundancia, ha támogatott; konfigurálja az RBAC-t és a kiürítési védelmet.
Megfigyelő Application Insights Ön Fontolja meg a többrégiós példányokat vagy a feladatátvételi stratégiát.
Kép- és összetevőregisztrációs adatbázis Azure Container Registry Ön Szükség szerint használja a georeplikációs műveleteket.
Integráció és munkafolyamat Logic Apps, Funkciók, Esemény Rács Ön A régió és a DR stratégia igazítása az ügynökfüggőségekkel.
Megfelelőség és adatleképezés Microsoft Purview (csatlakoztatva) Ön Az elektronikus adatfeltárási forgatókönyvek folytonosságának engedélyezése.
Egyéb tudás- és eszközforrások SharePoint, egyéni API-k Ön Konfigurálás szolgáltatásonként HA.

A cikk további része bemutatja, hogyan teheti az egyes összetevőket magas rendelkezésre állásúvá.

Katasztrófák és adatvesztés megelőzése

A megelőzés az elsődleges védelem a kimaradások ellen. Alkalmazza ezeket a javaslatokat az incidensek valószínűségének csökkentése és a számítási feladatok rugalmasságának megtervezése érdekében. További információ: Rugalmasság tervezése.

Erőforrás törlésének megakadályozása

A legtöbb véletlen törlés megakadályozása érdekében alkalmazzon törlési erőforrás-zárolásokat a kritikus erőforrásokra. A zárolások az erőforrásszintű törlés ellen védenek, az adatsík-műveletek azonban nem. Törlési zárolások alkalmazása ezekre az erőforrásokra.

Az alábbi táblázat az egyes erőforrások védelmét és korlátozásait ismerteti:

Erőforrás Biztosított védelem Korlátozások
Foundry-fiók Megakadályozza a fiók, projekt, modell, kapcsolat és ügynökfunkció hosztok törlését. Nem védi az egyes ügynököket és szálakat.
Azure Cosmos DB fiók Megakadályozza a fiók, enterprise_memory adatbázis és tárolók törlését. Nem védi a tárolókon belüli adatokat.
Azure AI Keresés szolgáltatás Megakadályozza a keresési szolgáltatáspéldány törlését. Nem védi az indexeket és az adatokat az indexekben.
Azure Storage fiók Megakadályozza a fiók- és blobtárolók törlését. Nem védi az egyes blobokat. A tulajdonosi szerepkörrel rendelkező felhasználók a tároló törlése előtt eltávolíthatják a zárolást.

A mélységi rugalmasság érdekében egyesítse az erőforrás-zárolásokat a Azure Policy denyAction effektussal az erőforrás-szolgáltató törlési kérelmeinek letiltásához. Ez a rétegzett megközelítés minden erőforrás helyreállítási képességeitől függetlenül erősíti a védelmet.

A következő Azure CLI parancs törlési zárolást alkalmaz egy Foundry-fiókra:

az lock create \
  --name "FoundryAccountLock" \
  --lock-type CanNotDelete \
  --resource-group "<your-resource-group>" \
  --resource-name "<your-foundry-account>" \
  --resource-type "Microsoft.CognitiveServices/accounts"

A zárolás alkalmazásának ellenőrzése:

az lock list \
  --resource-group "<your-resource-group>" \
  --resource "<your-foundry-account>" \
  --resource-type "Microsoft.CognitiveServices/accounts" \
  --output table

A várt kimenet az erőforrások zárolási nevét és típusát jeleníti meg.

Hivatkozás:az lock create

Minimális jogosultsági hozzáférés implementálása

Azure szerepköralapú hozzáférés-vezérlés (RBAC) használatával korlátozhatja a vezérléshez és az adatsíkokhoz való hozzáférést. Csak a szükséges engedélyeket adja meg, és rendszeresen ellenőrizze őket.

Éles környezetben ne adjon állandó törlési engedélyeket ezekhez az erőforrásokhoz egyetlen egyszerű felhasználónak sem. Az állapottárolókhoz való adatsík-hozzáféréshez csak a projekt felügyelt identitásának kell állandó írási engedélyekkel rendelkeznie.

Az adatokat az Agent Service REST API-kkal is megsemmisítheti. Az olyan beépített AI-szerepkörök, mint a Foundry User , törölhetik a működési adatokat ezen API-k vagy a Foundry portál használatával. Az API-k balesetei vagy visszaélései helyreállítási igényeket teremthetnek. Ezekhez az adatsík-műveletekhez nincs beépített AI-szerepkör. További információ: Microsoft Foundry REST API-referencia. Hozzon létre custom szerepköröket a Microsoft.CognitiveServices/*/write adatműveletek hozzáférésének korlátozásához.

Fontos

Az Foundry RBAC-szerepköröket nemrég átnevezték. Foundry user, Foundry Owner, Foundry-fióktulajdonos és Foundry Project Manager korábban Azure AI-felhasználónak, Azure AI-tulajdonosnak, Azure AI-fióktulajdonosnak és Azure AI-Project-kezelőnek hívták. Előfordulhat, hogy egyes helyeken továbbra is a korábbi elnevezések jelennek meg, amíg az átnevezés fokozatosan bevezetésre kerül. A szerepkör-azonosítók és az alapvető jogosultságok az átnevezés ellenére változatlanok maradnak.

Az egységes felelősség elvének megvalósítása

A Azure Cosmos DB fiókját, Azure AI Keresés szolgáltatását és Azure Storage fiókját kizárólag a számítási feladat AI-ügynökszolgáltatásának szentelheti. Az erőforrások más Foundry-fiókokkal vagy számítási feladat-összetevőkkel való megosztása nagyobb engedélyfelületek és nagyobb sugárterhelés révén növeli a kockázatot. Az egyik számítási feladathoz nem kapcsolódó műveleteknek soha nem szabad eltávolítaniuk vagy megrongálniuk egy másik számítási feladat ügynök állapotát. Ez az elkülönítés lehetővé teszi, hogy számítási feladatonkénti helyreállítási döntéseket hozzon anélkül, hogy minden vagy semmi megközelítést kellene alkalmaznia.

Zónaredundáns konfigurációk használata

Használjon zónaredundáns konfigurációkat Azure Cosmos DB fiókjához, Azure AI Keresés szolgáltatásához és Azure Storage fiókjához. Ez a beállítás védelmet nyújt a régión belüli zónahibák ellen. A zónaredundáns konfigurációk nem védenek a teljes regionális kimaradások, emberi vagy automatizálási hibák ellen. Az Ügynökszolgáltatás Microsoft üzemeltetett összetevői zónaredundánsak.

Erőforrások konfigurálása a helyreállítás támogatására

Konfigurálja ezeket az erőforrásokat incidens előtt. Az útmutató helyreállítási lépései feltételezik, hogy a következő beállításokat alkalmazta.

Erőforrás Ajánlott konfigurációk Célja
Foundry-fiók Hozzon létre egy explicit kapcsolódást a Microsoft Purview-hez. Támogatja az adat folytonosságát olyan megfelelőségi forgatókönyvek esetében, mint az adatfeltárási kérések a száladatok elvesztése után.
Foundry-projekt Felhasználó által hozzárendelt felügyelt identitást használjon, ne rendszer által hozzárendelt felügyelt identitást. Támogatja az ügynökfüggőségekhez való hozzáférés visszaállítását a szerepkör-hozzárendelések újbóli alkalmazásának nélkül.
Öntöde Ügynöki Szolgáltatás Használja a Standard ügynök üzembe helyezési módját. Több helyreállítási képességet biztosít, mint az alapszintű mód, amely szinte semmilyen helyreállítási lehetőséggel nem rendelkezik az erőforrás-veszteséghez.
Azure Cosmos DB Folyamatos biztonsági mentés engedélyezése időponthoz kötött visszaállítással. Válassza ki a 7 napos vagy 30 napos megőrzési szintet a helyreállítási követelmények alapján. Az adatbázis, a enterprise_memory tárolók vagy a teljes fiók véletlen törléséből való helyreállítás.
Azure Cosmos DB Használjon egyedi, szervezetspecifikus nevet (például contoso-agents-cosmosdb). Az időponthoz kötött visszaállítás során a Cosmos DB létrehoz egy új fiókot az eredeti névvel. Ha ez a név már foglalt, a visszaállítás sikertelen.
Azure Cosmos DB Engedélyezze az olvasási replikációt a kijelölt feladatátvételi régióban, és engedélyezze a Szolgáltatás által kezelt feladatátvételt. Lehetővé teszi a Cosmos DB szolgáltatás számára, hogy az írási régiót az elsődleges régióról a másodlagos régióra váltsa egy hosszan tartó regionális kimaradás során.
Azure AI Keresés Használjon egyedi, szervezetspecifikus nevet (például contoso-agents-search). A helyreállítás során létrejön egy új szolgáltatás az eredeti névvel. Ha ez a név már foglalt, a visszaállítás sikertelen.
Azure Storage fiók Geozónára redundáns tárolás (GZRS) használata. A munkaterhelés helyreállítási régiója lehet a Storage-fiók másodlagos régiója, de nem szükséges. Lehetővé teszi az ügyfél által felügyelt feladatátvétel indítását az előre meghatározott régióba.

Hivatkozások:

A Cosmos DB konfigurálása az Azure CLI használatával

Ezekkel a Azure CLI parancsokkal konfigurálhatja az ajánlott Cosmos DB-beállításokat az incidens bekövetkezése előtt.

Folyamatos biztonsági mentés engedélyezése időponthoz kötött visszaállítással:

az cosmosdb update \
  --name <account-name> \
  --resource-group <resource-group> \
  --backup-policy-type Continuous \
  --continuous-tier Continuous7Days

Referencia:az cosmosdb update

Az olvasási replikáció engedélyezése egy feladatátvételi régióhoz, valamint a szolgáltatás által felügyelt feladatátvétel engedélyezése:

az cosmosdb update \
  --name <account-name> \
  --resource-group <resource-group> \
  --locations regionName=<primary-region> failoverPriority=0 isZoneRedundant=true \
              regionName=<secondary-region> failoverPriority=1 isZoneRedundant=true \
  --enable-automatic-failover true

Referencia:az cosmosdb update

Üzembe helyezési módok és helyreállítási következmények

A A szabványos üzembehelyezési módban az ügynök állapotát a saját Azure Cosmos DB, Azure AI Keresés és Azure Storage fiókjaiban tárolja. Ez a topológia növeli az incidens kockázatát (például közvetlen adattörlést), de szabályozhatja a helyreállítási eljárásokat. Az alapszintű mód szinte semmilyen helyreállítási képességet nem biztosít az emberi vagy automatizálási alapú erőforrás-veszteséghez.

Tipp

Az Ügynökszolgáltatás nem rendelkezik rendelkezésre állási vagy állapotmegőrzési szolgáltatásiszint-szerződéssel (SLA). A standard mód kicsomagozza az SLA-kat és az adatok tartóssági garanciáit a mögöttes tárolási összetevőkre.

Felhasználó által hozzárendelt felügyelt identitások használata

Ha egy összetevő felügyelt identitással fér hozzá egy függőséghez, adja meg az identitásnak a szükséges szerepkör-hozzárendeléseket. A rendszer által hozzárendelt felügyelt identitással a hibás erőforrás újbóli létrehozása új fő azonosítót hoz létre. Ezután újra kell alkalmaznia az összes szerepkör-hozzárendelést minden függőségnél, és törölnie kell az árva hozzárendeléseket. Egyes függőségek más csapatok tulajdonában lehetnek, ami koordinációt és késést okoz a helyreállítás során.

A felhasználó által hozzárendelt felügyelt identitások elkerülik ezt az erőfeszítést. A hibás erőforrás visszaállítása után próbálkozzon újra a meglévő, felhasználó által hozzárendelt felügyelt identitással. A meglévő szerepkör-hozzárendelések érvényesek maradnak.

Fontos

Ne kezeljen egyetlen felhasználó által hozzárendelt felügyelt identitást univerzális identitásként több nem kapcsolódó felhasználás esetén.

Hozzárendelhet például egy dedikált, felhasználó által hozzárendelt felügyelt identitást projektenként. Még ha két projekt is azonos szerepkör-hozzárendeléssel rendelkezik, ezt a helyzetet ideiglenesnek kell tekinteni. A jövőbeli eltérések szükségtelen engedélyeket adhatnak egy projekthez, ha azonos identitáson osztoznak, megsértve a legkisebb jogosultság elvét. A különálló identitások lehetővé teszik, hogy a függőségi naplók projektenként különbséget tesznek a tevékenységek között.

Megismételhető üzembehelyezési technikák használata

Definiálja az infrastruktúra fiók- és projekt-, képességgazda- és függőségeit kódként (IaC), például Bicep vagy Terraformként. Egyes helyreállítási lépésekhez az erőforrások ismételt üzembe helyezésére van szükség pontosan úgy, ahogy voltak. Az IaC-t az igazság forrásaként kezelve gyorsan reprodukálhatja a konfigurációkat és a szerepkör-hozzárendeléseket. Moduláris IaC-t hozhat létre, hogy egymástól függetlenül üzembe helyezhesse az egyes projekteket.

Az ügynököket újratelepíthetővé tenni. A rövid élettartamú ügynökök esetében a meglévő alkalmazáskód általában elegendő. Hosszú élettartamú ügynökök esetén tárolja a JSON-definíciókat és a tudás- vagy eszközkötéseket a forráskezelésben, és automatizálja az üzembe helyezést az Foundry API-khoz irányuló folyamathívásokkal. Az új ügynökazonosítók ügyfélkonfigurációjának automatikus frissítése. Ez a folyamat rehidratálja az ügynökdefiníciókat, a tudásfájlokat és az eszközkapcsolatokat.

Kerülje a közvetlenül az Foundry portálon vagy Azure portálon végrehajtott nem követett módosításokat. A nem nyomon követett gyártási módosítások lassabbá teszik a helyreállítást és növelik a hibák esélyét.

Ha továbbra is a rendszer által hozzárendelt identitásokat választja (ellentétben a felhasználó által hozzárendelt felügyelt identitások használatára vonatkozó javaslattal), az IaC-t úgy tervezheti meg, hogy a projekt főazonosítójára hivatkozó szerepkör-hozzárendeléseket ne mutációval hozza létre. A szerepkör-hozzárendelések fő azonosítója változatlan, és nem frissíthető új értékre. guid() Olyan kifejezést használjon, amely az egyszerű azonosítót tartalmazza, így egy újragenerált identitás eltérő szerepkör-hozzárendelési nevet eredményez.

Az alábbi Bicep kódrészlet a Cosmos DB minimális sablonját jeleníti meg folyamatos biztonsági mentéssel és erőforrás-zárolással. A sablon bővítése az Azure AI Keresés, Azure Storage (GZRS), valamint a kezelt identitáshoz tartozó szerepkör-hozzárendelések alkalmazásával.

param location string = resourceGroup().location
param cosmosDbName string
param failoverRegion string

resource cosmosDb 'Microsoft.DocumentDB/databaseAccounts@2026-03-15' = {
  name: cosmosDbName
  location: location
  properties: {
    databaseAccountOfferType: 'Standard'
    consistencyPolicy: {
      defaultConsistencyLevel: 'Session'
    }
    locations: [
      { locationName: location, failoverPriority: 0, isZoneRedundant: true }
      { locationName: failoverRegion, failoverPriority: 1, isZoneRedundant: true }
    ]
    enableAutomaticFailover: true
    backupPolicy: {
      type: 'Continuous'
      continuousModeProperties: { tier: 'Continuous7Days' }
    }
  }
}

resource lock 'Microsoft.Authorization/locks@2020-05-01' = {
  name: '${cosmosDbName}-lock'
  scope: cosmosDb
  properties: {
    level: 'CanNotDelete'
    notes: 'Protect Cosmos DB from accidental deletion.'
  }
}

A Azure AI Keresés elsődleges adattárként való kezelésének minimalizálása

Azure AI Keresés a máshol tárolt mérvadó tartalmak származtatott, lekérdezésoptimalizált vetületének tárolására szolgál. Ne hagyatkozz rá a tudáseszközök egyetlen helyeként. A helyreállítás során újra kell létrehoznia azokat az ügynököket, amelyek a fájlon alapuló ismeretekre hivatkoznak az éles vagy a helyreállítási környezetben.

A beszélgetési szálakon belül csatolt felhasználó által feltöltött fájlok általában nem állíthatók helyre, mert nincsenek regisztrálva vagy megmaradva a témakörnyezeten kívül. Állítsa be az elvárásokat arra vonatkozóan, hogy ezek a mellékletek átmenetiek, és katasztrófa esetén elvesznek.

Ügynökadatok biztonsági mentése és visszaállítása

Fontos

Az ebben a szakaszban ismertetett eljárásokhoz standard ügynök üzembe helyezési mód szükséges. Alapszintű módban Microsoft kezeli az állapottárolókat, és ezek a helyreállítási lehetőségek nem érhetők el.

A beszélgetési szálak előzményeinek tartóssága az alapul szolgáló Standard módú állapottárolóktól függ: Cosmos DB enterprise_memory adatbázis, Azure AI Keresés indexek és storage-blobok a mellékletekhez. Nincs beépített egykattintásos exportálási vagy importálási funkció a teljes beszélgetési előzményekhez.

Ügynökdefiníciók biztonsági mentése

Az ügynök JSON-definícióinak és tudásforrás-hivatkozásának tárolása a forrásvezérlőben. Az Foundry REST API-val rendszeresen exportálhat ügynökkonfigurációkat:

  1. Az Ügynökök API meghívásával listázhatja az ügynököket az ügynökazonosítók, nevek, eszközkötések és tudásbázis-konfigurációk lekéréséhez.
  2. Mentse az ügynökdefiníciót JSON-fájlként a verziókövetési rendszerben.
  3. Az egyes ügynökdefiníciók mellett eszközkötéseket, tudásfájl-hivatkozásokat és kapcsolatkonfigurációkat is tartalmazhat.
  4. Ezt a folyamatot a CI/CD-folyamatokban rendszeres ütemezés szerint (például naponta vagy minden üzembe helyezés után) automatizálhatja.

Az alábbi Python kódrészlet a Azure AI-projektek ügyfélkódtárát használja az összes ügynök listázásához és az egyes definíciók JSON-fájlként való mentéséhez:

import json
import os
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

with AIProjectClient(
    endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential()
) as client:
    agents = client.agents.list_agents()
    for agent in agents:
        with open(f"{agent.id}.json", "w") as f:
            json.dump(agent.model_dump(), f, indent=2)
        print(f"Saved agent: {agent.name} ({agent.id})")

Hivatkozás:AIProjectClient.agents.list_agents()

Tipp

Az ügynökkonfigurációkat a REST API használatával is exportálhatja. A REST API teljes hozzáférést biztosít az ügynökerőforrásokhoz az automatizáláshoz bármilyen nyelven vagy CI/CD-folyamatban.

Visszaállítás a Cosmos DB időponthoz kötött biztonsági mentéséből

Ha véletlenül törli az adatbázist vagy annak enterprise_memory tárolóit:

  1. Nyissa meg a Azure portált, és nyissa meg Cosmos DB-fiókját.
  2. Válassza az Időponthoz kötött visszaállítás lehetőséget, és válasszon egy visszaállítási időbélyeget a törlés előtt.
  3. Adjon meg egy új célfióknevet a visszaállított adatokhoz.
  4. A visszaállítás befejezése után frissítse az Foundry Agent Service-kapcsolatot, hogy a visszaállított Cosmos DB-fiókra mutasson. Az Foundry portálon nyissa meg a projektet, válassza aCsatlakoztatott erőforrások>, keresse meg a Cosmos DB-kapcsolatot, és frissítse a végpontot az új visszaállított fióknévre.
  5. Az ügynök működésének ellenőrzéséhez futtasson egy tesztbeszélgetést a visszaállított környezetben.

A visszaállítást a Azure CLI is elindíthatja:

az cosmosdb restore \
  --account-name <source-account-name> \
  --target-database-account-name <restored-account-name> \
  --restore-timestamp "2026-01-15T10:00:00Z" \
  --location <region> \
  --resource-group <resource-group>

Megjegyzés

A visszaállított fiók mindig ugyanabban az előfizetésben és erőforráscsoportban jön létre, mint a forrásfiók. Ha a forrás erőforráscsoportot törölték, a parancs futtatása előtt hozza létre újra ugyanazzal a névvel. A --location paraméter a visszaállított fiók írási régióját állítja be, nem a célerőforráscsoport helyét. A visszaállítás után frissítenie kell az Agent Service kapcsolati sztringjét, valamint újra kell alkalmaznia a szerepkör-hozzárendeléseket, ha rendszer által hozzárendelt felügyelt identitásokat használ. A felhasználó által hozzárendelt felügyelt identitások csökkentik ezt a többletterhelést.

Megfelelőségi adatok megőrzése

Csatlakozzon a Microsoft Purview-hez, hogy megőrizze a származási és besorolási metaadatokat, még akkor is, ha a működési folyamat adatai elvesznek. Ez a kapcsolat biztosítja, hogy az adatfeltárási és naplózási képességek túléljék a katasztrófákat.

Azure AI Keresés indexek újraépítése

Ha a Azure AI Keresés szolgáltatás elveszett vagy sérült, építse újra az indexeket a mérvadó adatforrásokból:

  1. Hozzon létre egy új Azure AI Keresés szolgáltatást a helyreállítási régióban, vagy használja a többrégiós üzemelő példányban kiépített másodlagos szolgáltatást.
  2. Hozza létre újra az indexdefiníciókat az IaC-sablonokból vagy a forrásvezérelt sémafájlokból.
  3. Az indexek újratöltéséhez futtassa az adatbetöltési folyamatot az eredeti adatforrásokon (például Azure Blob Storage, Azure SQL Database vagy Cosmos DB-n).
  4. Frissítse az ügynök tudásbázis-hivatkozásait, hogy az új keresési szolgáltatásvégpontra mutasson.
  5. Ellenőrizze az index teljességét reprezentatív keresési lekérdezések futtatásával és az eredmények ismert alapkonfigurációkkal való összehasonlításával.

Többrégiós üzembe helyezés megtervezése

A többrégiós telepítés az Azure két régiójában történő Foundry erőforrások és más infrastruktúra létrehozására támaszkodik. Ha regionális kimaradás történik, váltson a másik régióra. Amikor megtervezi az erőforrások üzembe helyezésének helyét, fontolja meg a következő szempontokat:

  • Regionális rendelkezésre állás: Ha lehetséges, használjon egy régiót ugyanabban a földrajzi területen, nem feltétlenül a legközelebbit. A Foundry regionális elérhetőségének ellenőrzéséhez tekintse meg Azure termékek régiónként.

  • Azure párosított régiók: A párosított régiók koordinálják a platformfrissítéseket, és szükség esetén rangsorolják a helyreállítási erőfeszítéseket. Azonban nem minden régió van párosítva. További információ: Azure párosított régiók.

  • Szolgáltatás rendelkezésre állása: Döntse el, hogy a megoldás erőforrásaihoz forró/meleg, meleg/meleg vagy meleg/hideg szolgáltatást használ-e.

    • Aktív-aktív: Mindkét régió egyszerre aktív, és bármelyik régió azonnal használatra kész.
    • Forró/meleg: A fő régió aktív. A másodlagos régió kritikus erőforrásokkal (például üzembe helyezett modellekkel) rendelkezik, amelyek készen állnak az indításra. Nem kritikus erőforrások manuális üzembe helyezése a másodlagos régióban.
    • Hideg/meleg: Az elsődleges régió aktív. A másodlagos régióban telepítve van a Foundry és más erőforrások, valamint a szükséges adatok. Erőforrások, például modellek, modelltelepítések és folyamatok manuális üzembe helyezése.

Az alábbi táblázat az egyes stratégiák hozzávetőleges helyreállítási céljait mutatja be. A tényleges értékek az üzembe helyezés méretétől, a használatban lévő szolgáltatásoktól és az adatreplikációs konfigurációtól függenek.

Stratégia Hozzávetőleges RTO Hozzávetőleges RPO Relatív költség Legjobb
Nagy forgalmú / gyakran hozzáfért Jegyzőkönyv Közel nulla A legmagasabb: teljes duplikált erőforrások futnak mindkét régióban Nulla leállási idővel járó követelményekkel rendelkező éles üzem munkaterhelések
Forró/meleg 30 perc és 2 óra között Percről órára, a replikáció késésétől függően Mérsékelt: kritikus erőforrások futnak, mások készenléti állapotban Üzletileg kritikus fontosságú számítási feladatok, amelyek képesek elviselni a rövid megszakításokat
Meleg/hideg 2–8 óra Órák a biztonsági mentés gyakoriságától függően Legalacsonyabb: kiépített, de nem aktív erőforrások Fejlesztési, előkészítési vagy költségérzékeny számítási feladatok rugalmas helyreállítási célokkal

Tipp

Az üzleti követelményektől függően előfordulhat, hogy az Foundry-szolgáltatásokat másként kezeli.

Az Öntöde más szolgáltatásokra alapoz. Egyes szolgáltatások más régiókba replikálódnak. Más szolgáltatásokat manuálisan kell létrehoznia több régióban. Az alábbi táblázat felsorolja a replikációért felelős szolgáltatásokat, valamint a konfiguráció áttekintését:

Azure szolgáltatás Georeplikált Konfiguráció
Öntödei projektek Ön Projektek létrehozása a kijelölt régiókban.
Key Vault Microsoft Használja ugyanazt az Azure Key Vault példányt együtt a Foundry-projekttel és az erőforrásokkal mindkét régióban. Azure Key Vault automatikusan áttér egy másodlagos régióba. További információ: Azure Key Vault rendelkezésre állás és redundancia.
Tárolófiók Ön Az öntödei projektek nem támogatják az alapértelmezett tárhelyfiók feladatátvételét georedundáns tárhely (GRS), geo-zónaredundáns tárhely (GZRS), olvasási hozzáférésű georedundáns tárhely (RA-GRS) vagy olvasási hozzáférésű geo-zónaredundáns tárhely (RA-GZRS) használatával. Konfiguráljon egy tárfiókot az igényeinek megfelelően, és használja a projekthez. Minden későbbi projekt a projekt tárfiókját használja. További információ: Azure Storage redundancia.
Azure Container Registry Ön Engedélyezze a földrajzi replikációt a Azure Container Registry példányon a párosított régióba. Használja ugyanazt a példányt mindkét projekthez. További információért lásd az Geo-replikáció az Azure Container Registryben.
Application Insights Ön Hozzon létre Application Insightst a projekthez mindkét régióban. Az adatmegőrzési időtartam és a részletek módosításához tekintse meg az Application Insights adatgyűjtési, adatmegőrzési és tárolási adatait.

Ezeket a fejlesztési eljárásokat használva gyors helyreállítást és újraindítást engedélyezhet a másodlagos régióban:

  1. Használjon Azure Resource Manager sablonokat. A sablonok kódként szolgálnak infrastruktúraként, és lehetővé teszik a szolgáltatások gyors üzembe helyezését mindkét régióban.
  2. A két régió közötti eltérés elkerülése érdekében frissítse a folyamatos integrációs és üzembehelyezési folyamatokat a két régióban való üzembe helyezéshez.
  3. Szerepkör-hozzárendelések létrehozása mindkét régió felhasználói számára.
  4. Hozzon létre hálózati erőforrásokat, például Azure virtuális hálózatokat és privát végpontokat mindkét régióhoz. Győződjön meg arról, hogy a felhasználók mindkét hálózati környezethez hozzáférhetnek. Konfigurálja például a VPN-t és a DNS-t mindkét virtuális hálózathoz.

Tervezés magas rendelkezésre álláshoz

Rendelkezésre állási zónák konfigurálása

Egyes Azure szolgáltatások támogatják a rendelkezésre állási zónákat. A rendelkezésre állási zónákat támogató régiókban, ha egyetlen zóna meghibásodik, a zónaredundanciára konfigurált szolgáltatások továbbra is működnek. A nem zónaredundáns szolgáltatások fennakadásokat tapasztalhatnak. Az Ügynökszolgáltatás Microsoft üzemeltetett összetevői zónaredundánsak. Ellenőrizze, hogy az ügyfél által felügyelt függőségek (Cosmos DB, AI Search, Storage) zónaredundancia esetén is konfigurálva vannak-e.

További információ a Rendelkezésre állási zóna szolgáltatás támogatásáról.

Kritikus összetevők üzembe helyezése több régióban

Döntse el, hogy milyen szintű üzletmenet-folytonosságra van szüksége. A szint eltérhet a megoldás összetevőitől. Használhat például forró/forró konfigurációt az éles folyamatokhoz vagy a modellek üzembe helyezéséhez, a fejlesztéshez pedig meleg/hideg konfigurációt.

A Foundry egy regionális szolgáltatás, amely a szolgáltatás oldalán és az előfizetésében lévő tárfiókban tárolja az adatokat. Regionális katasztrófa esetén a szolgáltatásadatok nem állíthatók helyre. A szolgáltatás által az előfizetés tárfiókjában tárolt adatokat helyreállíthatja, ha engedélyezve van a tárterület-redundancia. A szolgáltatásoldali adatok többnyire metaadatok, például címkék, eszköznevek és leírások. A tárfiókban lévő adatok általában nem metaadatok, például feltöltött adatok.

Az üzletmenet-folytonossághoz nélkülözhetetlen kapcsolatok esetén:

  1. Hozzon létre két különálló erőforrást két különböző régióban (például két AI Services-erőforrásban).
  2. Hozzon létre két projektkapcsolatot, egyet minden regionális erőforráshoz.
  3. Ellenőrizze, hogy mindkét kapcsolat aktív és elérhető-e az alkalmazásból.
  4. Helyezzen üzembe erőforrásokat minden üzleti szempontból kritikus projekthez mindkét régióban.

Tároló elkülönítése nagy adathalmazokhoz

Ha adatokat csatlakoztat az AI-alkalmazás testreszabásához, adatkészleteket használhat Azure AI-ben és Azure AI-n kívül. Az adathalmaz kötete nagy lehet, ezért tartsa ezeket az adatokat egy külön tárfiókban a robbanási sugár korlátozása és a replikáció egyszerűsítése érdekében.

  1. Hozzon létre egy dedikált tárfiókot a nagy adathalmazokhoz, a projekt elsődleges tárolójától elkülönítve.
  2. Értékelje ki az adatreplikációs stratégiát (LRS, GRS, GZRS), amely a legjobban megfelel a helyreállítási követelményeknek.
  3. A Foundry portálon hozzon létre kapcsolatot az adat-tárolási fiókkal. Ha több Foundry-példánya van különböző régiókban, ugyanarra a tárfiókra mutathat. A kapcsolatok régiók között működnek.

Korai kimaradások észlelésének figyelése

Konfigurálja a monitorozást és a riasztást, hogy a csapat észlelje a regionális romlást, mielőtt az hatással lenne az éles számítási feladatokra:

  1. Engedélyezze az összes Azure szolgáltatásra vonatkozó Azure Service Health riasztásokat a Foundry munkaterhelésében. A Service Health előzetes értesítést küld a tervezett karbantartásról, és korai figyelmeztetést ad a nem tervezett kimaradásokról.
  2. Konfigurálja az erőforrás állapotriasztásokat a Cosmos DB, Azure OpenAI és Storage fiókokhoz az egyes erőforráshibák észlelésére.
  3. Az Application Insights rendelkezésre állási tesztjeinek beállítása az ügynökvégpontok folyamatos mintavételéhez több földrajzi helyről.
  4. Olyan riasztási műveletcsoportokat definiálhat, amelyek e-mailben, SMS-ben vagy az incidenskezelő rendszeren keresztül értesítik az operatív csapatot, hogy a feladatátvételi döntések gyorsan végrehajthatók legyenek.

Modell üzembe helyezési rugalmasságának konfigurálása

Azure OpenAI-modellek üzembe helyezései a legtöbb Foundry-számítási feladat kritikus fontosságú összetevői. Tervezheti meg az üzembehelyezési topológiát a rugalmasság érdekében, hogy egy regionális kimaradás vagy kapacitáskorlátozás ne vegye offline állapotba az alkalmazást. Ez a szakasz a standard és kiépített üzembehelyezési stratégiákat, az API-átjáró mintákat és az őket összekapcsoló támogató infrastruktúrát ismerteti.

Standard telepítések konfigurálása

A standard üzemelő példányok a rugalmasság legegyszerűbb útját kínálják, mivel az adatzóna és a globális standard lehetőségek automatikusan elosztják a kéréseket több régió között.

Megjegyzés

Ha az adattárolási követelmények lehetővé teszik, inkább a Globális Standard telepítéstípusokat részesítse előnyben. Az adatzónák üzembe helyezései (USA/EU) a következő legjobb megoldás az olyan szervezetek számára, amelyek földrajzi határokon belüli adatfeldolgozást igényelnek.

A Standard telepítéseknél a következő megközelítést alkalmazza:

  1. Alapértelmezett adatzóna-telepítések (usa-beli vagy uniós beállítások).
  2. Két Azure OpenAI-erőforrás üzembe helyezése ugyanabban a Azure-előfizetésben. Helyezze az egyik erőforrást az előnyben részesített régióba, a másikat a másodlagos (feladatátvételi) régióba. Azure OpenAI az előfizetés plusz régió szintjén foglalja le a kvótát, így mindkét erőforrás a kvóta befolyásolása nélkül oszthat meg előfizetéseket.
  3. Hozzon létre egy üzembe helyezést minden olyan modellhez, amelyet az elsődleges régióban kíván használni, és duplikálja ezeket a modelltelepítéseket a másodlagos régióban. Foglalja le a teljes rendelkezésre álló kvótát minden standard telepítésben. A teljes kiosztás nagyobb átviteli sebességet biztosít, mint a kvóta több üzembe helyezésre való felosztása.
  4. Válassza ki az üzembehelyezési régiót a hálózati topológia alapján. Az Azure OpenAI-erőforrást bármely támogatott régióban üzembe helyezheti, majd létrehozhat egy privát végpontot az adott erőforráshoz az alkalmazáshoz közelebbi régióban.
    • Miután a forgalom belép a Azure OpenAI-határra, a szolgáltatás optimalizálja az útválasztást és a feldolgozást az adatzónában elérhető számítási feladatok között.
    • Az Adatzóna-útválasztás hatékonyabb és egyszerűbb, mint a saját kezűleg irányított terheléselosztás több regionális üzembe helyezés között.
  5. Ha egy regionális kimaradás miatt az elsődleges üzembe helyezés elérhetetlenné válik, a forgalmat átirányíthatja a passzív régióban lévő másodlagos üzembe helyezéshez ugyanabban az előfizetésben.
    • Mivel mind az elsődleges, mind a másodlagos zónatelepítés, a zóna minden elérhető régiójában ugyanabból a zónakapacitás-készletből merítenek. A másodlagos üzembe helyezés védelmet nyújt az elsődleges Azure OpenAI-végpont elérhetetlenségével szemben.
    • Használjon Generatív AI átjárót, amely támogatja a terheléselosztást és a kapcsolat-megszakító mintázatot (például Azure API Management) az Azure OpenAI végpontok előtt, hogy minimálisra csökkentse a regionális kimaradás miatti fennakadást.
    • Ha egy adott előfizetés kvótája kimerült, helyezzen üzembe egy új előfizetést ugyanúgy, és helyezze a végpontját a Generative AI-átjáró mögé.

Kiépített telepítések konfigurálása

A kiépített átviteli egység (PTU) üzemelő példányai dedikált kapacitást biztosítanak a késésre érzékeny vagy kritikus fontosságú számítási feladatokhoz. Nagyvállalati PTU-készlet kombinálása választható munkaterhelés-specifikus üzembe helyezésekkel a maximális rugalmasság és ellenálló képesség érdekében.

Vállalati PTU-készlet létrehozása

  1. Provisionelt telepítések esetén hozzon létre egyetlen Data Zone PTU telepítést, amely vállalati PTU-készletként szolgál. A Azure API Management használatával kezelheti a több alkalmazásból érkező forgalmat, és beállíthatja az átviteli sebesség korlátait, a naplózást, a prioritást és a feladatátvételi logikát.
    • A vállalati PTU-készletet "privát Standard üzemelő példányként" tekintheti, amely védelmet nyújt a zajos-szomszéd probléma ellen. Ha a standard telepítések iránti igény magas, a szervezet számára garantált, kizárólagos hozzáférés biztosított egy olyan kapacitáskészlethez, amelyet csak Ön használhat.
    • Ezzel a megközelítéssel szabályozhatja, hogy mely alkalmazások tapasztalnak nagyobb késést, így prioritást adhat a kritikus fontosságú alkalmazások felé történő forgalomnak.
    • A kiépített telepítések késési SLA-kkal vannak támogatva, amelyek előnyösebbé teszik őket, mint a standard telepítések a késésre érzékeny számítási feladatok esetében.
    • A vállalati PTU-üzemeltetések magasabb kihasználtsági arányt is elérnek, mivel a forgalom egyenletesen eloszlik az alkalmazás munkaterhelései között, míg az egyes munkaterhelések általában több kivételes terhelési csúcsot eredményeznek.
  2. Helyezze az elsődleges vállalati PTU-telepítést egy másik régióba, mint az elsődleges Standard Zone telepítést. Regionális kimaradás esetén nem veszíti el egyszerre a PTU és a Standard Zóna üzembe helyezéséhez való hozzáférést.

Számítási feladatokra dedikált PTU-üzemelő példányok

Egyes számítási feladatokhoz szükség lehet saját, dedikált üzembe helyezésre. Ha igen, kövesse az alábbi irányelveket:

  1. Hozzon létre egy dedikált PTU-üzembe helyezést az adott alkalmazáshoz.
  2. Helyezze a számítási feladat PTU-készletét a vállalati PTU-készletétől eltérő régióba a regionális hibák elleni védelem érdekében. Tegyük fel például a számítási feladat PTU-készletét az A régióban, a vállalati PTU-készletet pedig a B régióban.
  3. Konfigurálja a feladatátvételi láncot, hogy a számítási feladatra dedikált üzembe helyezés először a vállalati PTU-készletre, majd a Standard üzembe helyezésre omljon át. Ha a számítási feladat PTU-üzemelő példányának kihasználtsága meghaladja a 100%, a PTU-végpontok továbbra is kiszolgálják a kéréseket, így magasabb késésű SLA marad fenn az adott alkalmazáshoz.

Ábra bemutatja a feladatterhelésre dedikált PTU-tól a vállalati PTU-készlethez a Standard üzembe helyezésig tartó feladatátvételi láncot.

A forgalom az alkalmazástól a feladat számára dedikált PTU telepítéshez áramlik. Ha az üzembe helyezés telített (a kihasználtság meghaladja a 100%-ot), a forgalom a vállalati PTU-készletbe irányul át. Ha a vállalati készlet nem érhető el, a forgalom átesik a Standard üzembe helyezésig.

Ez az architektúra lehetővé teszi a standard üzembe helyezések összeillesztését a profilozott központi telepítésekkel, így egyensúlyt teremthet a teljesítmény és a reziliencia között. Használja a PTU-t az alapvető erőforrásigények fedezésére a számítási feladatok során, és a standard üzembe helyezéseket a forgalmi csúcsok kezelésére.

Diagram, amely bemutatja, hogyan növekednek az előre konfigurált és standard telepítések az alap és a kiugró forgalom kezelésére.

A PTU kezeli a számítási feladatok alapkonfigurációs igényét, míg a standard üzemelő példányok a kiosztott kapacitáson túli forgalomnövekedést is elnyelik.

Generatív AI-átjáró beállítása

A Generatív AI-átjáró egy fordított proxy, amely általában Azure API Management, amely a Azure OpenAI-végpontok előtt helyezkedik el, és a következőket biztosítja:

  • Terheléselosztás több Azure OpenAI-végponton.
  • Kapcsolatcsoport-megszakító minta a nem megfelelő végpontok automatikus észleléséhez és irányításához.
  • Sebességkorlátozás és szabályozás a háttérrendszernek a forgalom megugrásával szembeni védelméhez.
  • Központosított naplózás és megfigyelhetőség az összes modellvégponton.
  • Prioritásos útválasztás , hogy a kritikus fontosságú alkalmazások a versengés során először kapacitást szerezzenek.

A kiforrott Azure lábnyommal és hibrid kapcsolattal rendelkező szervezeteknek magánhálózaton keresztül kell használniuk a szolgáltatást. A hibrid kapcsolattal nem rendelkező szervezetek vagy más felhőbeli alkalmazásokkal, például GCP-vel vagy AWS-sel rendelkező szervezetek a szolgáltatást a Microsoft nyilvános gerinchálózaton keresztül használhatják.

A modellvégpontok infrastruktúrájának támogatása

A Azure OpenAI üzembehelyezési architektúráját támogató infrastruktúrát figyelembe kell venni a rugalmassági kialakításban. Az egyes összetevők attól függenek, hogy az alkalmazások Azure OpenAI-t használnak-e az interneten vagy magánhálózaton keresztül.

Felhasználás a Microsoft nyilvános gerinchálózaton keresztül

A szolgáltatást a Microsoft nyilvános gerinchálózaton keresztül használó szervezeteknek a következő tervezési elemeket kell figyelembe venniük:

  1. A Generatív AI-átjáró üzembe helyezése olyan módon, amely biztosítja a rendelkezésre állást egy Azure regionális kimaradás során. Ha Azure API Management használ, helyezzen üzembe külön APIM-példányokat több régióban, vagy használja a multi-region gateway szolgáltatást.
  2. Egy nyilvános globális kiszolgáló terheléselosztóját használva több Generatív AI-átjárópéldány között oszthatja el a forgalmat aktív/aktív vagy aktív/passzív módon. Azure Front Door betöltheti ezt a szerepkört.

Diagram, amely a többes feladatátvételi architektúrát mutatja be az Azure Front Door által több API Management-példány között történő terheléselosztással.

Azure Front Door több régióban osztja el a hálózati forgalmat az API Management példányai között. Minden APIM-példány átirányítja a kéréseket Azure régióban lévő OpenAI-végpontokra, és automatikus feladatátvételt biztosít, amikor egy régió elérhetetlenné válik.

Fogyasztás privát hálózaton keresztül

A szolgáltatást magánhálózaton keresztül használó szervezeteknek a következő tervezési elemeket kell figyelembe venniük:

  1. Hibrid kapcsolat üzembe helyezése, hogy védelmet nyújtson egy Azure régió meghibásodása ellen. A hibrid kapcsolat összetevői közé tartozik a helyszíni hálózati infrastruktúra és a Microsoft ExpressRoute vagy VPN.
  2. A Generatív AI-átjáró üzembe helyezése a regionális kimaradások során történő rendelkezésre álláshoz. Ha Azure API Management használ, helyezzen üzembe külön APIM-példányokat több régióban, vagy használja a multi-region gateway szolgáltatást.
  3. Helyezzen üzembe Azure Private Link privát végpontokat minden Azure OpenAI-példányhoz minden Azure régióban. Az Azure saját DNS esetében használjon split-brain DNS-megközelítést, ha az összes alkalmazásforgalom a Generative AI Gateway-n halad át. Ez a megközelítés további védelmet nyújt a regionális hibák ellen. Ha az átjárón kívül közvetlen hozzáférésre van szükség, frissítse saját DNS rekordokat manuálisan egy Azure régió elvesztése során.
  4. A Generative AI Gateway-példányok közötti forgalom aktív/aktív vagy aktív/passzív módon történő elosztásához használjon privát globális kiszolgálói terheléselosztót. Azure nem biztosít natív globális kiszolgálói terheléselosztót a privát DNS-feloldást igénylő számítási feladatokhoz. Globális kiszolgálói terheléselosztó helyett a szervezetek a Generatív AI-átjáró végpontjának DNS-rekord-összevonásával érhetnek el aktív/passzív mintát.

Átállás kezdeményezése

Váltás a feladatátvételi projektre

Ha az elsődleges projekt nem érhető el, váltson a másodlagos projektre:

  1. Azonosítsa a másodlagos projekt végpontját és kapcsolati adatait az IaC-konfigurációból vagy az üzembe helyezés dokumentációjából.

  2. Frissítse az alkalmazáskonfigurációt, hogy a másodlagos projektre mutasson. Használjon környezeti változókat vagy központosított konfigurációt (például Azure App Configuration) a nem rögzített projekthivatkozások helyett, hogy a régiók közötti váltás csak konfigurációmódosítást igényel:

    • Frissítse az Foundry-projekt végpontjának URL-címét a másodlagos régióra.
    • Ha a Generative AI-átjárót használja, ellenőrizze, hogy a megszakító már átirányította-e a forgalmat a másodlagos Azure OpenAI-végpontokra.
    • Ha nincsenek megosztva régiók között, frissítse a közvetlen szolgáltatáskapcsolatokat (Cosmos DB, AI Search, Storage).
    # Example: switch to secondary region endpoints
export FOUNDRY_ENDPOINT="https://<secondary-project>.cognitiveservices.azure.com"
export AZURE_OPENAI_ENDPOINT="https://<secondary-aoai>.openai.azure.com"

  3. Ellenőrizze a kapcsolatot egy tesztkérelem futtatásával a másodlagos projektvégponton.

  4. Küldje újra a folyamatban lévő feladatokat, mert a szolgáltatáskimaradás során futó feladatok nem váltanak automatikusan a másodlagos projektre.

Az Foundry nem szinkronizálja vagy helyreállítja az összetevőket vagy a metaadatokat a projektek között. Ha úgy konfigurálja az elsődleges és a másodlagos projekteket, hogy a társított erőforrásokat engedélyezve legyen a georeplikálás, bizonyos objektumok elérhetők a feladatátvételi projektben. Például mindkét projekt ugyanazokat a Docker-lemezképeket, konfigurált adattárakat és Azure Key Vault erőforrásokat használja.

Feladatátvételi készültség ellenőrzése

Rendszeresen ellenőrizze, hogy a másodlagos környezet képes-e kezelni az éles számítási feladatokat. Hajtsa végre ezeket az ellenőrzési lépéseket rendszeres ütemezés szerint (például negyedévente):

  1. Győződjön meg arról, hogy a másodlagos régió Foundry-projektje, az üzembe helyezett modellek és kapcsolatok aktuálisak, és megfelelnek az elsődleges régió konfigurációjának.
  2. A másodlagos projektben egy reprezentatív ügynök vagy folyamatfeladat futtatása a végpontok közötti funkciók ellenőrzéséhez, beleértve a Azure Cosmos DB, Azure AI Keresés és Azure Storage elérését.
  3. Ellenőrizze, hogy a felügyelt identitások, felhasználók és szolgáltatásnevek összes RBAC-szerepkör-hozzárendelése a másodlagos régióban van-e érvényben.
  4. Tesztelje a DNS-feloldási és hálózati kapcsolatokat, beleértve a privát végpontokat és a VPN-útvonalakat az ügyfélkörnyezetektől a másodlagos régióig.
  5. Dokumentálja a hiányosságokat, és frissítse az IaC-sablonokat vagy az üzembe helyezési folyamatokat, hogy a következő felülvizsgálati ciklus előtt bezárja őket.

Törölt erőforrások helyreállítása

Ha töröl egy projektet és annak erőforrásait, egyes erőforrások támogatják a helyreállítható törlést, és helyreállíthatók. A projektek nem támogatják a helyreállítható törlést, ezért a törlés után nem állíthatók helyre. Az alábbi táblázat azt mutatja be, hogy mely szolgáltatások támogatják a helyreállítható törlést.

Szolgáltatás Lágy törlés engedélyezve
Foundry-projekt Nem
Azure Storage Lásd : Törölt tárfiók helyreállítása
Azure Key Vault Igen

Más Foundry-erőforrások (fiókok, projektek) törlése vagy tisztítása utáni helyreállításához lásd: Törölt Foundry-erőforrások helyreállítása vagy tisztítása.

Gyakori problémák elhárítása

Kérdés Lehetséges ok Felbontás
Az erőforrás-zárolás nem akadályozza meg a törlést Helytelen hatókörben alkalmazott zárolás Ellenőrizze, hogy a zárolás közvetlenül az erőforrásra van-e alkalmazva, nem csak az erőforráscsoportra. A megerősítéshez használja az lock list --resource-group <rg> .
RBAC-engedély megtagadva a Cosmos DB konfigurálásakor Hiányzó szerepkör-hozzárendelés Győződjön meg arról, hogy Cosmos DB-operátor vagy közreműködői szerepkör van a Cosmos DB-fiókban.
Áthidalási projekt nem fér hozzá a megosztott erőforrásokhoz A felügyelt identitás eltérés Ha rendszer által hozzárendelt identitást használ, alkalmazza újra a szerepkör-hozzárendeléseket. Érdemes lehet a felhasználó által hozzárendelt felügyelt identitásra váltani.
A Cosmos DB időpillanat szerinti visszaállítása meghiúsul A folyamatos biztonsági mentés nincs engedélyezve Incidens bekövetkezése előtt engedélyezze a folyamatos biztonsági mentést. Ez a beállítás visszamenőlegesen nem alkalmazható.
A Cosmos DB visszaállítása elnevezési ütközéssel meghiúsul Már használatban lévő fióknév A fiók első létrehozásakor használjon egyedi, szervezetspecifikus nevet. Ütközés esetén állítsa vissza a fióknevet egy másikra, és frissítse az Agent Service kapcsolatokat.
A másodlagos üzembe helyezés kvótahibákat ad vissza A kvóta nincs lefoglalva a feladatátvételi régióban Ellenőrizze, hogy teljes kvótát osztott-e ki az elsődleges és a másodlagos Azure OpenAI-üzemelő példányokhoz. Ellenőrizze a kvótát a az cognitiveservices account list-usage --name <account-name> --resource-group <resource-group> használatával.
A DNS-feloldás a régió feladatátvétele után meghiúsul saját DNS rekordok nem frissülnek Ha a Private Linket Generatív AI-átjáró nélkül használja, manuálisan frissítse a saját DNS-rekordokat úgy, hogy a másodlagos régió privát végpontjaira mutassanak.
Az ügynök nem tud csatlakozni a Cosmos DB feladatátvétele után A kapcsolati sztring a régi végpontra mutat Frissítse az Ügynökszolgáltatás-kapcsolatot, hogy hivatkozzon az új Cosmos DB-fiókvégpontra. Ellenőrzés tesztbeszélgetéssel.
Az APIM-átjáró 503-at ad vissza a regionális kimaradás során A megszakító nincs konfigurálva Konfigurálja a megszakító mintát a Generative AI Gateway-ben, hogy automatikusan kerülhesse a nem megfelelő állapotú háttérrendszereket.

Kapcsolódó tartalom

  • Last updated on