Vägledning för storleksändring

Översikt över storleksvägledning

När du planerar för distributionen av Azure Arc-datatjänster planerar du rätt mängd:

• Compute
• Minne
• Storage

Dessa resurser krävs för:

• Datakontrollanten
• SQL-hanterade instanser
• PostgreSQL-servrar

Eftersom Azure Arc-aktiverade datatjänster distribueras på Kubernetes har du flexibiliteten att lägga till mer kapacitet i Kubernetes-klustret över tid efter beräkningsnoder eller lagring. Den här guiden beskriver minimikrav och rekommenderar storlekar för vissa vanliga krav.

Allmänna storlekskrav

Kommentar

Om du inte är bekant med begreppen i den här artikeln kan du läsa mer om Kubernetes-resursstyrning och Kubernetes storleks notation.

Kärnor måste vara ett heltalsvärde som är större än eller lika med ett.

När du distribuerar med Azure CLI (az) använder du en kraft på två tal för att ange minnesvärdena. Mer specifikt använder du suffixen:

• Ki
• Mi
• Gi

Gränsvärdena måste alltid vara större än värdet för begäran, om det anges.

Gränsvärden för kärnor är det fakturerbara måttet på SQL-hanterad instans och PostgreSQL-servrar.

Minimikrav för distribution

En azure Arc-aktiverad distribution av azure arc-aktiverade datatjänster kan anses vara Azure Arc-datakontrollanten plus en SQL-hanterad instans plus en PostgreSQL-server. För den här konfigurationen behöver du minst 16 GB RAM-minne och 4 kärnor med tillgänglig kapacitet i Kubernetes-klustret. Du bör se till att du har en kubernetes-nodstorlek på minst 8 GB RAM-minne och 4 kärnor och en total kapacitet på 16 GB RAM som är tillgänglig för alla dina Kubernetes-noder. Du kan till exempel ha 1 nod på 32 GB RAM-minne och 4 kärnor eller så kan du ha 2 noder med 16 GB RAM-minne och 4 kärnor vardera.

Mer information om lagringsstorlek finns i artikeln om lagringskonfiguration .

Storleksinformation för datakontrollant

Datakontrollanten är en samling poddar som distribueras till ditt Kubernetes-kluster för att tillhandahålla ett API, kontrollanttjänsten, bootstrappern och övervakningsdatabaserna och instrumentpanelerna. Den här tabellen beskriver standardvärdena för minnes- och CPU-begäranden och gränser.

Poddnamn	CPU-begäran	Minnesbegäran	CPU-gräns	Minnesgräns
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 är en daemonset, som skapas på var och en av Kubernetes-noderna i klustret. Talen i tabellen är per nod. Om du anger allowNodeMetricsCollection = false i distributionsprofilfilen innan du skapar datakontrollanten skapas inte detta daemonset .

Du kan åsidosätta standardinställningarna för controldb och kontrollera poddar i YAML-filen för datakontrollanten. Exempel:

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

Mer information om lagringsstorlek finns i artikeln om lagringskonfiguration .

Storleksinformation för SQL-hanterad instans

Varje SQL-hanterad instans måste ha följande minsta resursbegäranden och begränsningar:

Tjänstenivå	Generell användning	Affärskritisk
CPU-begäran	Minimum: 1 Max: 24 Standard: 2	Minimum: 3 Maximalt: obegränsat Standard: 4
CPU-gräns	Minimum: 1 Max: 24 Standard: 2	Minimum: 3 Maximalt: obegränsat Standard: 4
Minnesbegäran	Minimum: 2Gi Maximal: 128Gi Standard: 4Gi	Minimum: 2Gi Maximalt: obegränsat Standard: 4Gi
Minnesgräns	Minimum: 2Gi Maximal: 128Gi Standard: 4Gi	Minimum: 2Gi Maximalt: obegränsat Standard: 4Gi

Varje SQL-hanterad instanspodd som skapas har tre containrar:

Containerns namn	CPU-begäran	Minnesbegäran	CPU-begränsning	Minnesbegränsning	Kommentar
fluentbit	100m	100Mi	Har inte angetts	Har inte angetts	Containerresursbegäranden fluentbit är utöver de begäranden som angetts för den SQL-hanterade instansen.
arc-sqlmi	Användaren har angetts eller inte angetts.	Användaren har angetts eller inte angetts.	Användaren har angetts eller inte angetts.	Användaren har angetts eller inte angetts.
collectd	Har inte angetts	Har inte angetts	Har inte angetts	Har inte angetts

Standardvolymstorleken för alla beständiga volymer är 5Gi.

Storleksinformation för PostgreSQL-server

Varje PostgreSQL-servernod måste ha följande minsta resursbegäranden:

• Minne: 256Mi
• Kärnor: 1

Varje PostgreSQL-serverpodd som skapas har tre containrar:

Containerns namn	CPU-begäran	Minnesbegäran	CPU-begränsning	Minnesbegränsning	Kommentar
fluentbit	100m	100Mi	Har inte angetts	Har inte angetts	Containerresursbegäranden fluentbit är utöver de begäranden som angetts för PostgreSQL-servern.
postgres	Användaren har angetts eller inte angetts.	Användaren har angetts eller 256Mi (standard).	Användaren har angetts eller inte angetts.	Användaren har angetts eller inte angetts.
arc-postgresql-agent	Har inte angetts	Har inte angetts	Har inte angetts	Har inte angetts

Kumulativ storleksändring

Den totala storleken på en miljö som krävs för Azure Arc-aktiverade datatjänster är främst en funktion av antalet och storleken på databasinstanserna. Den totala storleken kan vara svår att förutsäga i förväg med vetskapen om att antalet instanser kan öka och minska och mängden resurser som krävs för varje databasinstans kan ändras.

Baslinjestorleken för en viss Azure Arc-aktiverad datatjänstmiljö är storleken på datakontrollanten, som kräver 4 kärnor och 16 GB RAM-minne. Därifrån lägger du till den kumulativa summan av kärnor och minne som krävs för databasinstanserna. SQL Managed Instance kräver en podd för varje instans. PostgreSQL-servern skapar en podd för varje server.

Förutom de kärnor och minne som du begär för varje databasinstans bör du lägga till 250m kärnor och 250Mi RAM-minne för agentcontainrarna.

Exempel på storleksberäkning

Krav:

• "SQL1": 1 SQL-hanterad instans med 16 GB RAM-minne, 4 kärnor
• "SQL2": 1 SQL-hanterad instans med 256 GB RAM-minne, 16 kärnor
• "Postgres1": 1 PostgreSQL-server på 12 GB RAM-minne, 4 kärnor

Storleksberäkningar:

• Storleken på "SQL1" är: 1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). För agenter per podd använder du 16.25 Gi RAM-minne och 4,25 kärnor.

• Storleken på "SQL2" är: 1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores]). För agenterna per podd använder du 256.25 Gi RAM-minne och 16,25 kärnor.

• Den totala storleken på SQL 1 och SQL 2 är:

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

• Storleken på "Postgres1" är: 1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). För agenter per podd använder 12.25 Gi DU RAM-minne och 4.25 kärnor.

• Den totala kapacitet som krävs:

  • För databasinstanserna:
    • 272,5 GB RAM-minne
    • 20,5 kärnor
  • För SQL:
    • 12,25 GB RAM-minne
    • 4,25 kärnor
  • För PostgreSQL-server
    • 284,75 GB RAM-minne
    • 24,75 kärnor

• Den totala kapacitet som krävs för databasinstanserna plus datakontrollanten är:

  • För databasinstansen
    • 284,75 GB RAM-minne
    • 24,75 kärnor
  • För datakontrollanten
    • 16 GB RAM-minne
    • 4 kärnor
  • Sammanlagt:
    • 300,75 GB RAM-minne
    • 28,75 kärnor.

Mer information om lagringsstorlek finns i artikeln om lagringskonfiguration .

Övriga beaktanden

Tänk på att en viss begäran om databasinstansstorlek för kärnor eller RAM-minne inte får överskrida den tillgängliga kapaciteten för Kubernetes-noderna i klustret. Om den största Kubernetes-noden du har i ditt Kubernetes-kluster till exempel är 256 GB RAM-minne och 24 kärnor kan du inte skapa en databasinstans med en begäran om 512 GB RAM-minne och 48 kärnor.

Underhålla minst 25 % av den tillgängliga kapaciteten över Kubernetes-noderna. Med den här kapaciteten kan Kubernetes:

• Schemalägga poddar som ska skapas effektivt
• Aktivera elastisk skalning
• Stöder löpande uppgraderingar av Kubernetes-noderna
• Underlättar långsiktig tillväxt på efterfrågan

I dina storleksberäkningar lägger du till resurskraven för Kubernetes-systempoddar och andra arbetsbelastningar, som kan vara att dela kapacitet med Azure Arc-aktiverade datatjänster i samma Kubernetes-kluster.

För att upprätthålla hög tillgänglighet under planerat underhåll och katastrofkontinuitet planerar du att minst en av Kubernetes-noderna i klustret ska vara otillgänglig vid en viss tidpunkt. Kubernetes försöker schemalägga om poddarna som kördes på en viss nod som togs ned för underhåll eller på grund av ett fel. Om det inte finns någon tillgänglig kapacitet på de återstående noderna schemaläggs inte poddarna om för att skapas förrän det finns tillgänglig kapacitet igen. Var extra försiktig med stora databasinstanser. Om det till exempel bara finns en Kubernetes-nod som är tillräckligt stor för att uppfylla resurskraven för en stor databasinstans och noden misslyckas, schemalägger Kubernetes inte den databasinstanspodden på en annan Kubernetes-nod.

Tänk på de maximala gränserna för en Kubernetes-klusterstorlek .

Kubernetes-administratören kan ha konfigurerat resurskvoter för ditt namnområde/projekt. Tänk på dessa kvoter när du planerar databasinstansstorlekarna.