Richtlijnen voor het aanpassen van de grootte

  • Artikel

Overzicht van richtlijnen voor het aanpassen van de grootte

Bij het plannen van de implementatie van Azure Arc-gegevensservices moet u de juiste hoeveelheid plannen:

  • Compute
  • Geheugen
  • Storage

Deze resources zijn vereist voor:

  • De gegevenscontroller
  • Beheerde SQL-exemplaren
  • PostgreSQL-servers

Omdat gegevensservices met Azure Arc in Kubernetes worden geïmplementeerd, hebt u de flexibiliteit om in de loop van de tijd meer capaciteit toe te voegen aan uw Kubernetes-cluster door rekenknooppunten of opslag. In deze handleiding worden de minimale vereisten uitgelegd en worden de grootten voor enkele algemene vereisten aanbevolen.

Algemene vereisten voor het aanpassen van de grootte

Notitie

Als u niet bekend bent met de concepten in dit artikel, kunt u meer lezen over Kubernetes-resourcebeheer en kubernetes-grootte-notatie.

Kerngetallen moeten een geheel getal groter dan of gelijk aan één getal zijn.

Wanneer u implementeert met Azure CLI (az), gebruikt u een macht van twee getallen om de geheugenwaarden in te stellen. Gebruik met name de achtervoegsels:

  • Ki
  • Mi
  • Gi

Limietwaarden moeten altijd groter zijn dan de aanvraagwaarde, indien opgegeven.

Limietwaarden voor kernen zijn de factureerbare metrische gegevens op SQL Managed Instance- en PostgreSQL-servers.

Minimale implementatievereisten

Een minimale grootte voor de implementatie van gegevensservices met Azure Arc kan worden beschouwd als de Azure Arc-gegevenscontroller plus één met SQL beheerd exemplaar plus één PostgreSQL-server. Voor deze configuratie hebt u ten minste 16 GB RAM en 4 kernen van de beschikbare capaciteit in uw Kubernetes-cluster nodig. U moet ervoor zorgen dat u een minimale Kubernetes-knooppuntgrootte hebt van 8 GB RAM en 4 kernen en een som van de totale capaciteit van 16 GB RAM die beschikbaar is voor al uw Kubernetes-knooppunten. U kunt bijvoorbeeld 1 knooppunt hebben met 32 GB RAM-geheugen en 4 kernen of u kunt 2 knooppunten hebben met elk 16 GB RAM en 4 kernen.

Zie het artikel over opslagconfiguratie voor meer informatie over de grootte van opslag.

Details van de grootte van de gegevenscontroller

De gegevenscontroller is een verzameling pods die zijn geïmplementeerd in uw Kubernetes-cluster om een API, de controllerservice, de bootstrapper en de bewakingsdatabases en dashboards te bieden. In deze tabel worden de standaardwaarden voor geheugen- en CPU-aanvragen en -limieten beschreven.

Podnaam CPU-aanvraag Geheugenaanvraag CPU-limiet Geheugenlimiet
bootstrapper 100m 100Mi 200m 200Mi
control 400m 2Gi 1800m 2Gi
controldb 200m 4Gi 800m 6Gi
logsdb 200m 1600Mi 2 1600Mi
logsui 100m 500Mi 2 2Gi
metricsdb 200m 800Mi 400m 2Gi
metricsdc 100m 200Mi 200m 300Mi
metricsui 20m 200Mi 500m 200Mi

metricsdc is een daemonset, dat wordt gemaakt op elk van de Kubernetes-knooppunten in uw cluster. De getallen in de tabel zijn per knooppunt. Als u het implementatieprofielbestand instelt allowNodeMetricsCollection = false voordat u de gegevenscontroller maakt, wordt dit daemonset niet gemaakt.

U kunt de standaardinstellingen voor de controldb pods in uw YAML-bestand voor de gegevenscontroller overschrijven. Voorbeeld:

  resources:
    controller:
      limits:
        cpu: "1000m"
        memory: "3Gi"
      requests:
        cpu: "800m"
        memory: "2Gi"
    controllerDb:
      limits:
        cpu: "800m"
        memory: "8Gi"
      requests:
        cpu: "200m"
        memory: "4Gi"

Zie het artikel over opslagconfiguratie voor meer informatie over de grootte van opslag.

Details van de grootte van een beheerd SQL-exemplaar

Elk beheerd SQL-exemplaar moet de volgende minimale resourceaanvragen en -limieten hebben:

Servicelaag Algemeen gebruik Bedrijfskritiek
CPU-aanvraag Minimum: 1
Maximum: 24
Standaardwaarde: 2		 Minimaal: 3
Maximum: onbeperkt
Standaard: 4
CPU-limiet Minimum: 1
Maximum: 24
Standaardwaarde: 2		 Minimaal: 3
Maximum: onbeperkt
Standaard: 4
Geheugenaanvraag Minimum: 2Gi
Maximale: 128Gi
Standaardwaarde: 4Gi		 Minimum: 2Gi
Maximum: onbeperkt
Standaardwaarde: 4Gi
Geheugenlimiet Minimum: 2Gi
Maximale: 128Gi
Standaardwaarde: 4Gi		 Minimum: 2Gi
Maximum: onbeperkt
Standaardwaarde: 4Gi

Elke sql Managed Instance-pod die wordt gemaakt, heeft drie containers:

Containernaam CPU-aanvraag Geheugenaanvraag CPU-limiet Geheugenlimiet Aantekeningen
fluentbit 100m 100Mi Niet opgegeven Niet opgegeven De fluentbit containerresourceaanvragen zijn naast de aanvragen die zijn opgegeven voor het beheerde SQL-exemplaar.
arc-sqlmi Gebruiker opgegeven of niet opgegeven. Gebruiker opgegeven of niet opgegeven. Gebruiker opgegeven of niet opgegeven. Gebruiker opgegeven of niet opgegeven.
collectd Niet opgegeven Niet opgegeven Niet opgegeven Niet opgegeven

De standaardvolumegrootte voor alle permanente volumes is 5Gi.

Details van grootte van PostgreSQL-server

Elk PostgreSQL-serverknooppunt moet de volgende minimale resourceaanvragen hebben:

  • Geheugen: 256Mi
  • Kernen: 1

Elke PostgreSQL-serverpod die wordt gemaakt, heeft drie containers:

Containernaam CPU-aanvraag Geheugenaanvraag CPU-limiet Geheugenlimiet Aantekeningen
fluentbit 100m 100Mi Niet opgegeven Niet opgegeven De fluentbit containerresourceaanvragen zijn naast de aanvragen die zijn opgegeven voor de PostgreSQL-server.
postgres Gebruiker opgegeven of niet opgegeven. Gebruiker opgegeven of 256Mi (standaard). Gebruiker opgegeven of niet opgegeven. Gebruiker opgegeven of niet opgegeven.
arc-postgresql-agent Niet opgegeven Niet opgegeven Niet opgegeven Niet opgegeven

Cumulatieve grootte

De totale grootte van een omgeving die is vereist voor gegevensservices met Azure Arc is voornamelijk een functie van het aantal en de grootte van de database-exemplaren. De totale grootte kan moeilijk te voorspellen zijn om te voorspellen dat het aantal exemplaren kan toenemen en verkleinen en de hoeveelheid resources die vereist zijn voor elk database-exemplaar kan veranderen.

De basislijngrootte voor een bepaalde omgeving met Gegevensservices met Azure Arc is de grootte van de gegevenscontroller, waarvoor 4 kernen en 16 GB RAM nodig zijn. Voeg hier het cumulatieve totaal van kernen en geheugen toe die nodig zijn voor de database-exemplaren. Sql Managed Instance vereist één pod voor elk exemplaar. PostgreSQL-server maakt één pod voor elke server.

Naast de kernen en het geheugen die u voor elk database-exemplaar aanvraagt, moet u kernen en 250Mi RAM toevoegen 250m voor de agentcontainers.

Voorbeeldberekening van grootte

Vereisten:

  • 'SQL1': 1 met SQL beheerd exemplaar met 16 GB RAM, 4 kernen
  • 'SQL2': 1 met SQL beheerd exemplaar met 256 GB RAM, 16 kernen
  • "Postgres1": 1 PostgreSQL-server met 12 GB RAM, 4 kernen

Grootteberekeningen:

  • De grootte van 'SQL1' is: 1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Voor de agents per pod worden RAM-geheugen en 4,25 kernen gebruikt 16.25 Gi .

  • De grootte van 'SQL2' is: 1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores]). Voor de agents per pod worden RAM-geheugen en 16,25 kernen gebruikt 256.25 Gi .

  • De totale grootte van SQL 1 en SQL 2 is:

    • (16.25 GB + 256.25 Gi) = 272.5-GB RAM
    • (4.25 cores + 16.25 cores) = 20.5 cores

  • De grootte van 'Postgres1' is: 1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Voor de agents per pod worden RAM-geheugen en 4.25 kernen gebruikt12.25 Gi.

  • De totale capaciteit die nodig is:

    • Voor de database-exemplaren:
      • 272,5 GB RAM
      • 20,5 kernen
    • Voor SQL:
      • 12,25 GB RAM
      • 4,25 kernen
    • Voor PostgreSQL-server
      • 284,75 GB RAM
      • 24,75 kernen

  • De totale capaciteit die nodig is voor de database-exemplaren plus de gegevenscontroller is:

    • Voor het database-exemplaar
      • 284,75 GB RAM
      • 24,75 kernen
    • Voor de gegevenscontroller
      • 16 GB RAM
      • 4 kernen
    • In totaal:
      • 300,75 GB RAM
      • 28,75 kernen.

Zie het artikel over opslagconfiguratie voor meer informatie over de grootte van opslag.

Overige overwegingen

Houd er rekening mee dat een aanvraag voor de grootte van een database-exemplaar voor kernen of RAM de beschikbare capaciteit van de Kubernetes-knooppunten in het cluster niet kan overschrijden. Als het grootste Kubernetes-knooppunt in uw Kubernetes-cluster bijvoorbeeld 256 GB RAM en 24 kernen is, kunt u geen database-exemplaar maken met een aanvraag van 512 GB RAM en 48 kernen.

Behoud ten minste 25% van de beschikbare capaciteit op de Kubernetes-knooppunten. Met deze capaciteit kan Kubernetes:

  • Efficiënt pods plannen die moeten worden gemaakt
  • Elastisch schalen inschakelen
  • Ondersteunt rolling upgrades van de Kubernetes-knooppunten
  • Faciliteert groei op langere termijn op aanvraag

Voeg in uw berekeningen voor de grootte de resourcevereisten van de Kubernetes-systeempods en eventuele andere workloads toe, die mogelijk capaciteit delen met gegevensservices met Azure Arc in hetzelfde Kubernetes-cluster.

Als u hoge beschikbaarheid wilt behouden tijdens gepland onderhoud en de continuïteit van noodgevallen, moet u op elk gewenst moment plannen dat ten minste één van de Kubernetes-knooppunten in uw cluster niet beschikbaar is. Kubernetes probeert de pods die werden uitgevoerd op een bepaald knooppunt, opnieuw te plannen voor onderhoud of vanwege een fout. Als er geen capaciteit beschikbaar is op de resterende knooppunten, worden deze pods pas opnieuw gepland voor het maken als er weer capaciteit beschikbaar is. Wees extra voorzichtig met grote database-exemplaren. Als er bijvoorbeeld slechts één Kubernetes-knooppunt groot genoeg is om te voldoen aan de resourcevereisten van een groot database-exemplaar en dat knooppunt mislukt, plant Kubernetes die database-exemplaarpod niet op een ander Kubernetes-knooppunt.

Houd rekening met de maximumlimieten voor een Kubernetes-clustergrootte .

Uw Kubernetes-beheerder heeft mogelijk resourcequota ingesteld voor uw naamruimte/project. Houd rekening met deze quota bij het plannen van de grootte van uw database-exemplaren.