Richtlijnen voor het aanpassen van de grootte

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 Maximum: 128Gi Standaardwaarde: 4Gi	Minimum: 2Gi Maximum: onbeperkt Standaardwaarde: 4Gi
Geheugenlimiet	Minimum: 2Gi Maximum: 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	Opmerkingen
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	Opmerkingen
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.

Andere 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.