ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/capacity-planning-dr-configurations.md
Kjell Tore Guttormsen 3a73eeafdc refactor(ms-ai-architect): R13 del 1 — nøytraliser Cosmo-personaen i ref-korpusets headinger, etter å ha rettet en gate som var målt usann to ganger
Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:

1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
   produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
   substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
   `Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
   tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
   kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
   formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
   132 bokføres til R13b/R14.

Tre korreksjoner av premisser som sto i ordren og STATE:
  «ca 320 produkt»   -> 451 (case-sensitivt nett manglet 327 lowercase
                        TOC-ankre + 99 identifikatorer; sann nevner 1 638)
  «169 headinger»    -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
                        internt inkonsistent med sin egen topp-variant (204)
  «417 matcher ingen
   populasjon»       -> 417 er cosmo-headinger utenfor kodefences; briefens
                        nevner var reell hele tiden

Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.

TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.

Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.

Verifisering (alle 7 kriterier fra ordren):
  G1 persona på heading-linjer   401 -> 0
  G2 døde fragmentlenker         1 -> 1 (pre-eksisterende, unntatt)
  G3 produkt-forekomster         451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
  de 3 kun-produkt-filene        byte-identiske
  nettet validert begge veier    injisert persona feller G1; genitiv feller G1;
                                 produkt-heading og de 3 filene passerer
  hele diffen                    802 heading-linjer + 654 TOC-linjer, ANNET = 0
  linjeantall                    728 lagt til = 728 slettet
  suite                          1120/1120 (1097 + 23 nye)
  validate-plugin                250 PASS / 0 FAIL
  stikkprøve                     10 filer, alle 5 skills, inkl. de 3 mest
                                 produkt-tunge (26/20/19) — kun heading+TOC

Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 22:12:28 +02:00

14 KiB
Raw Blame History

Capacity Planning for DR Configurations

Last updated: 2026-02 Status: GA Category: Business Continuity & Disaster Recovery Type: reference Source: https://learn.microsoft.com/azure/well-architected/design-guides/disaster-recovery


Innhold

Introduksjon

Kapasitetsplanlegging for Disaster Recovery-konfigurasjoner handler om å dimensjonere reserveressurser riktig slik at AI-systemer kan gjenopprettes innenfor definerte RTO- og RPO-mål. For AI-arbeidsbelastninger er dette spesielt utfordrende fordi ressurskravene er høye (GPU-compute, store indekser, høy throughput) og kostnadene eskalerer raskt ved full duplisering.

Azure tilbyr flere strategier for å balansere kapasitet, kostnad og gjenopprettingstid: fra alltid-aktive active-active konfigurasjoner til minimalt provisionerte warm/cold standby-oppsett med auto-scaling. Valget avhenger av kritikalitetstier og budsjett.

Norske offentlige organisasjoner må gjøre en avveining mellom tilgjengelighetskrav (NSMs grunnprinsipper) og kostnadseffektivitet (krav om forsvarlig bruk av offentlige midler). Kapasitetsplanlegging bør dokumenteres som del av organisasjonens BCDR-plan og revideres minst årlig.

Dimensjonering av DR-miljø for toppbelastning

AI-komponent dimensjoneringsmatrise

AI-komponent Primær region DR (Active-Active) DR (Warm Standby) DR (Cold Standby)
Azure OpenAI 120K TPM 120K TPM 60K TPM + autoscale 0 (redeploy)
AI Search (replikaer) 3 3 2 0 (rebuild)
AI Search (partisjoner) 4 4 4 0 (rebuild)
App Service P3v3 x 3 P3v3 x 3 P2v3 x 1 0 (deploy)
Cosmos DB (RU/s) 10,000 10,000 4,000 (autoscale) 0 (restore)

Beregning av DR-kapasitetsbehov

# Kapasitetsberegningsmodell for AI DR-miljø
def calculate_dr_capacity(primary_config, dr_strategy, peak_multiplier=1.2):
    """
    Beregn nødvendig DR-kapasitet basert på primær konfigurasjon.

    Args:
        primary_config: Dict med primær region ressurser
        dr_strategy: 'active-active', 'warm-standby', 'cold-standby'
        peak_multiplier: Faktor for toppbelastning (default 1.2x)
    """
    dr_config = {}

    if dr_strategy == "active-active":
        # Full kapasitet i begge regioner
        for resource, capacity in primary_config.items():
            dr_config[resource] = capacity * peak_multiplier

    elif dr_strategy == "warm-standby":
        # Redusert kapasitet, skaleres opp ved failover
        scaling_factors = {
            "openai_tpm": 0.5,        # 50% av primær
            "search_replicas": 0.67,    # 2 av 3 replikaer
            "search_partitions": 1.0,   # Full (kan ikke skalere raskt)
            "app_service_instances": 0.33,  # 1 av 3 instanser
            "cosmos_ru": 0.4,          # 40% med autoscale til 100%
        }
        for resource, capacity in primary_config.items():
            factor = scaling_factors.get(resource, 0.5)
            dr_config[resource] = int(capacity * factor)

    elif dr_strategy == "cold-standby":
        # Ingen kjørende ressurser, kun IaC-maler
        for resource, capacity in primary_config.items():
            dr_config[resource] = 0
        dr_config["iac_templates"] = True
        dr_config["estimated_deploy_time_minutes"] = 30

    return dr_config

# Eksempel
primary = {
    "openai_tpm": 120000,
    "search_replicas": 3,
    "search_partitions": 4,
    "app_service_instances": 3,
    "cosmos_ru": 10000
}

warm = calculate_dr_capacity(primary, "warm-standby")
print(f"Warm standby config: {warm}")
# Output: {'openai_tpm': 60000, 'search_replicas': 2, ...}

Surge capacity og burst-håndtering

Azure OpenAI Token Rate Limiting

Azure OpenAI har regionalt baserte kvoter. Ved failover til sekundær region kan eksisterende kvoter være utilstrekkelige.

# Sjekk nåværende kvote i sekundær region
az cognitiveservices account list-usage \
  --name "aoai-secondary-swedencentral" \
  --resource-group "rg-ai-dr" \
  --output table

# Pre-provisioner kapasitet med Provisioned Throughput Units (PTU)
az cognitiveservices account deployment create \
  --name "aoai-secondary-swedencentral" \
  --resource-group "rg-ai-dr" \
  --deployment-name "gpt-4o-ptu" \
  --model-name "gpt-4o" \
  --model-version "2024-08-06" \
  --model-format "OpenAI" \
  --sku-capacity 50 \
  --sku-name "ProvisionedManaged"

Auto-scaling for App Service

# Konfigurer autoscale i DR-region
az monitor autoscale create \
  --resource-group "rg-ai-dr" \
  --name "autoscale-ai-app-dr" \
  --resource "/subscriptions/{sub}/resourceGroups/rg-ai-dr/providers/Microsoft.Web/serverFarms/asp-ai-dr" \
  --min-count 1 \
  --max-count 5 \
  --count 1

# Scale-up regel basert på CPU
az monitor autoscale rule create \
  --resource-group "rg-ai-dr" \
  --autoscale-name "autoscale-ai-app-dr" \
  --condition "Percentage CPU > 70 avg 5m" \
  --scale out 2

# Scale-down regel
az monitor autoscale rule create \
  --resource-group "rg-ai-dr" \
  --autoscale-name "autoscale-ai-app-dr" \
  --condition "Percentage CPU < 30 avg 10m" \
  --scale in 1

Cosmos DB Autoscale

# Konfigurer autoscale for Cosmos DB i DR-region
# Baseline: 4000 RU/s, maks: 10000 RU/s
az cosmosdb sql container throughput migrate \
  --account-name "cosmos-ai-dr" \
  --resource-group "rg-ai-dr" \
  --database-name "chatbot-state" \
  --name "conversations" \
  --throughput-type "autoscale"

az cosmosdb sql container throughput update \
  --account-name "cosmos-ai-dr" \
  --resource-group "rg-ai-dr" \
  --database-name "chatbot-state" \
  --name "conversations" \
  --max-throughput 10000

Kostnadsoptimalisering for standby-ressurser

Kostnadsprofiler per DR-strategi

Strategi Kostnad vs. primær RTO Best for
Active-Active (full) 100% ~0 Tier 0: Mission Critical
Active-Active (optimized autoscale) 5070% Sekunder Tier 0/1
Warm Standby (partial) 2540% 515 min Tier 1: Business Critical
Cold Standby (IaC only) 510% 3060 min Tier 2: Business Operational
Backup & Restore 25% TimerDager Tier 3: Administrative

Spesifikke kostnadsbesparelser

## Kostnadsbesparelser for Warm Standby

1. **Azure OpenAI**: Bruk pay-per-token (ikke PTU) i DR-region
   - Besparelse: 6080% vs. PTU
   - Tradeoff: Ingen garantert kapasitet ved failover

2. **AI Search**: 2 replikaer i stedet for 3 i DR
   - Besparelse: ~33% på search-kostnaden
   - Tradeoff: kun read-only (query) SLA i stedet for full read-write (query + indeksering) SLA — begge er 99,9 % (det finnes ingen 99,99 %-tier)

3. **App Service**: P2v3 i stedet for P3v3, med autoscale
   - Besparelse: ~50% på compute
   - Tradeoff: 12 min skaleringstid ved failover

4. **Cosmos DB**: Autoscale med lav baseline
   - Besparelse: 4060% ved lavt normalbruk
   - Tradeoff: Opptil 10s oppskaleringsforsinkelse

Azure Cost Management for DR

# Tag alle DR-ressurser for kostnadssporing
az tag create --name "Environment" --value "DR"

# Sett budsjett-alert for DR-ressursgruppe
az consumption budget create \
  --budget-name "dr-monthly-budget" \
  --amount 50000 \
  --category "Cost" \
  --time-grain "Monthly" \
  --time-period '{"Start": "2026-01-01", "End": "2026-12-31"}' \
  --resource-groups "rg-ai-dr" \
  --notifications '{
    "Warning80": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 80,
      "contactEmails": ["platform-team@org.no"]
    },
    "Critical100": {
      "enabled": true,
      "operator": "GreaterThan",
      "threshold": 100,
      "contactEmails": ["platform-team@org.no", "management@org.no"]
    }
  }'

Skaleringsregler og auto-scaling

DR Activation Scaling Pipeline

# Azure DevOps Pipeline: DR Activation Scale-Up
trigger: none  # Manuelt eller via alert webhook

parameters:
  - name: activationType
    type: string
    values:
      - failover
      - failover-drill
      - scale-test

stages:
  - stage: ScaleUpDR
    displayName: 'Scale Up DR Environment'
    jobs:
      - job: ScaleSearchService
        steps:
          - task: AzureCLI@2
            displayName: 'Scale AI Search to 3 replicas'
            inputs:
              azureSubscription: 'dr-service-connection'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                az search service update \
                  --name "search-secondary-swedencentral" \
                  --resource-group "rg-ai-dr" \
                  --replica-count 3

      - job: ScaleAppService
        steps:
          - task: AzureCLI@2
            displayName: 'Scale App Service to P3v3'
            inputs:
              azureSubscription: 'dr-service-connection'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                az appservice plan update \
                  --name "asp-ai-dr" \
                  --resource-group "rg-ai-dr" \
                  --sku P3v3

      - job: VerifyCapacity
        dependsOn:
          - ScaleSearchService
          - ScaleAppService
        steps:
          - task: AzureCLI@2
            displayName: 'Verify DR capacity'
            inputs:
              azureSubscription: 'dr-service-connection'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                echo "=== Search Service ==="
                az search service show \
                  --name "search-secondary-swedencentral" \
                  --resource-group "rg-ai-dr" \
                  --query "{replicas:replicaCount, partitions:partitionCount, status:status}"

                echo "=== App Service Plan ==="
                az appservice plan show \
                  --name "asp-ai-dr" \
                  --resource-group "rg-ai-dr" \
                  --query "{sku:sku.name, workers:numberOfWorkers}"

Kapasitetsreservasjonsstrategier

Azure Reserved Instances for DR

Ressurstype Reservasjonsanbefaling Besparelse Merknad
App Service P2v3 1-år RI for baseline ~35% For warm standby baseline
Cosmos DB (autoscale) Ingen RI N/A Autoscale er per-bruk
Azure OpenAI PTU RI kun for primær ~30% DR bruker pay-per-token
AI Search Standard RI for begge regioner ~35% Partisjoner kjører alltid
Storage (GZRS) Reservert kapasitet ~25% For store datasett

Capacity Reservation Groups

# Opprett kapasitetsreservasjon for VM-baserte workloads i DR-region
az capacity reservation group create \
  --name "crg-ai-dr-swedencentral" \
  --resource-group "rg-ai-dr" \
  --location "swedencentral" \
  --zones 1 2 3

# Reserver spesifikk VM-størrelse
az capacity reservation create \
  --capacity-reservation-group "crg-ai-dr-swedencentral" \
  --resource-group "rg-ai-dr" \
  --name "cr-gpu-nc24ads" \
  --location "swedencentral" \
  --sku "Standard_NC24ads_A100_v4" \
  --capacity 2 \
  --zone 1

Referanser

For arkitekten

  • Bruk denne referansen når kunden trenger hjelp med å dimensjonere og kostnadsoptimalisere sine DR-miljøer for AI-workloads.
  • Warm standby med autoscale er den mest kostnadseffektive strategien for Tier 1 (Business Critical) AI-systemer — typisk 2540% av full dupliseringskostnad.
  • Påminn om at Azure OpenAI-kvoter er regionsspesifikke — kunden MÅ pre-allokere kapasitet i DR-regionen, ellers risikerer de at failover feiler pga. kvotebegrensninger.
  • For AI Search: Partisjoner kan ikke skaleres ned uten å gjenopprette tjenesten, så dimensjonér partisjoner identisk i begge regioner.
  • Anbefal Azure Cost Management med tags og budsjetter for å overvåke DR-kostnader separat fra produksjonskostnader.