크기 조정 지침
크기 조정 지침 개요
Azure Arc 데이터 서비스 배포를 계획할 때 다음의 정확한 양을 계획합니다.
- 컴퓨팅
- 메모리
- 스토리지
이러한 리소스는 다음과 같은 경우에 필요합니다.
- 데이터 컨트롤러
- SQL 관리되는 인스턴스
- PostgreSQL 서버
Azure Arc 지원 데이터 서비스는 Kubernetes에 배포되므로 시간이 지남에 따라 컴퓨팅 노드 또는 스토리지를 통해 Kubernetes 클러스터에 더 많은 용량을 유연하게 추가할 수 있습니다. 이 가이드에서는 최소 요구 사항을 설명하고 일부 일반적인 요구 사항에 대한 권장 크기를 설명합니다.
일반 크기 조정 요구 사항
참고 항목
이 문서의 개념이 익숙하지 않으실 경우 Kubernetes 리소스 거버넌스 및 Kubernetes 크기 표기법에 관해 자세히 알아볼 수 있습니다.
코어 수는 1보다 크거나 같은 정수 값이어야 합니다.
Azure CLI(az)를 사용하여 배포하는 경우 숫자 2의 거듭제곱을 사용하여 메모리 값을 설정합니다. 특히 다음 접미사를 사용합니다.
KiMiGi
제한 값은 지정된 경우 항상 요청 값보다 커야 합니다.
코어에 대한 제한 값은 SQL Managed Instance 및 PostgreSQL 서버에서 청구 가능한 메트릭입니다.
최소 배포 요구 사항
최소 크기의 Azure Arc 지원 데이터 서비스 배포는 Azure Arc 데이터 컨트롤러와 하나의 SQL Managed Instance 및 하나의 PostgreSQL 서버로 간주될 수 있습니다. 해당 구성에서는 Kubernetes 클러스터에서 사용 가능한 16GB RAM 및 코어 4개 이상의 용량이 필요합니다. 최소한 Kubernetes 노드 크기가 8GB RAM 및 코어 4개이고, 모든 Kubernetes 노드에서 총 16GB RAM을 사용할 수 있어야 합니다. 예를 들어 32GB RAM, 4 코어에서는 노드 하나를 갖게 되거나 각각 16GB RAM, 4 코어인 노드 두 개를 갖게 됩니다.
스토리지 크기 조정에 관한 자세한 내용은 스토리지 구성 문서를 참조하세요.
데이터 컨트롤러 크기 조정 세부 정보
데이터 컨트롤러는 API, 컨트롤러 서비스, 부트스트래퍼, 모니터링 데이터베이스, 대시보드를 제공하기 위해 Kubernetes 클러스터에 배포되는 Pod의 컬렉션입니다. 다음 표에서는 메모리, CPU 요청, 한도의 기본값을 설명합니다.
| Pod 이름 | CPU 요청 | 메모리 요청 | CPU 제한 | 메모리 제한 |
|---|---|---|---|---|
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는 클러스터의 각 Kubernetes 노드에 만들어지는 daemonset입니다. 표의 숫자는 노드당입니다. 데이터 컨트롤러를 만들기 전에 배포 프로필 파일에 allowNodeMetricsCollection = false를 설정하면 이 daemonset가 만들어지지 않습니다.
데이터 컨트롤러 YAML 파일에서 controldb 및 Control Pod에 대한 기본 설정을 재정의할 수 있습니다. 예시:
resources:
controller:
limits:
cpu: "1000m"
memory: "3Gi"
requests:
cpu: "800m"
memory: "2Gi"
controllerDb:
limits:
cpu: "800m"
memory: "8Gi"
requests:
cpu: "200m"
memory: "4Gi"
스토리지 크기 조정에 관한 자세한 내용은 스토리지 구성 문서를 참조하세요.
SQL 관리형 인스턴스 크기 조정 정보
각 SQL Managed Instance에는 다음과 같은 최소 리소스 요청 및 제한이 있어야 합니다.
| 서비스 계층 | 범용 | 중요 비즈니스용 |
|---|---|---|
| CPU 요청 | 최소: 1 최대: 24 기본값: 2 |
최소: 3 최대: 무제한 기본값: 4 |
| CPU 제한 | 최소: 1 최대: 24 기본값: 2 |
최소: 3 최대: 무제한 기본값: 4 |
| 메모리 요청 | 최솟값: 2Gi최댓값: 128Gi기본값: 4Gi |
최솟값: 2Gi최대: 무제한 기본값: 4Gi |
| 메모리 제한 | 최솟값: 2Gi최댓값: 128Gi기본값: 4Gi |
최솟값: 2Gi최대: 무제한 기본값: 4Gi |
생성된 각 SQL 관리형 인스턴스 Pod에는 세 개의 컨테이너가 있습니다.
| 컨테이너 이름 | CPU 요청 | 메모리 요청 | CPU 제한 | 메모리 제한 | 주의 |
|---|---|---|---|---|---|
fluentbit |
100m |
100Mi |
지정되지 않음 | 지정되지 않음 | fluentbit 컨테이너 리소스 요청은 SQL Managed Instance에 대해 지정된 요청에 추가로 적용됩니다. |
arc-sqlmi |
사용자가 지정되었거나 지정되지 않았습니다. | 사용자가 지정되었거나 지정되지 않았습니다. | 사용자가 지정되었거나 지정되지 않았습니다. | 사용자가 지정되었거나 지정되지 않았습니다. | |
collectd |
지정되지 않음 | 지정되지 않음 | 지정되지 않음 | 지정되지 않음 |
모든 영구 볼륨의 기본 볼륨 크기는 5Gi입니다.
PostgreSQL 서버 크기 조정 세부 정보
각 PostgreSQL 서버 노드에는 다음과 같은 최소 리소스 요청이 있어야 합니다.
- 메모리:
256Mi - 코어: 1
만들어진 각 PostgreSQL 서버 Pod에는 3개의 컨테이너가 있습니다.
| 컨테이너 이름 | CPU 요청 | 메모리 요청 | CPU 제한 | 메모리 제한 | 주의 |
|---|---|---|---|---|---|
fluentbit |
100m |
100Mi |
지정되지 않음 | 지정되지 않음 | fluentbit 컨테이너 리소스 요청은 PostgreSQL 서버에 대해 지정된 요청에 추가로 적용됩니다. |
postgres |
사용자가 지정되었거나 지정되지 않았습니다. | 사용자 지정되었거나 256Mi(기본값). |
사용자가 지정되었거나 지정되지 않았습니다. | 사용자가 지정되었거나 지정되지 않았습니다. | |
arc-postgresql-agent |
지정되지 않음 | 지정되지 않음 | 지정되지 않음 | 지정되지 않음 |
누적 크기 조정
Azure Arc 지원 데이터 서비스에 필요한 환경의 전체 크기는 주로 데이터베이스 인스턴스의 수와 크기에 따라 달라집니다. 각 데이터베이스 인스턴스에 필요한 리소스의 양이 증가 및 축소하고, 각 인스턴스 수가 변경된다는 사실을 알고 전체 크기를 예측하기가 어려울 수 있습니다.
지정된 Azure Arc 지원 데이터 서비스 환경의 기준 크기는 4개 코어와 16GB RAM이 필요한 데이터 컨트롤러의 크기입니다. 여기에서 데이터베이스 인스턴스에 필요한 총 코어 및 메모리를 추가합니다. SQL Managed Instance에는 인스턴스당 하나의 Pod가 필요합니다. PostgreSQL 서버는 각 서버마다 하나의 Pod를 만듭니다.
각 데이터베이스 인스턴스에 대해 요청하는 코어 및 메모리 외에도 에이전트 컨테이너에 대해 코어 250m개와 RAM 250Mi개를 추가해야 합니다.
사이즈 계산 예
요구 사항:
- "SQL1": 16GB RAM, 4개 코어를 갖춘 SQL Managed Instance 1개
- "SQL2": 256GB RAM, 16개 코어를 갖춘 SQL Managed Instance 1개
- "Postgres1": 12GB RAM의 PostgreSQL 서버 1개, 코어 4개
크기 조정 계산:
"SQL1"의 크기는
1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores])입니다. Pod당 에이전트의 경우16.25 GiRAM 및 4.25 코어를 사용합니다."SQL2"의 크기는
1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores])입니다. Pod당 에이전트의 경우256.25 GiRAM 및 16.25 코어를 사용합니다.SQL 1과 SQL 2의 총 크기는 다음과 같습니다.
(16.25 GB + 256.25 Gi) = 272.5-GB RAM(4.25 cores + 16.25 cores) = 20.5 cores
"Postgres1"의 크기는
1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores])입니다. Pod당 에이전트의 경우12.25 GiRAM 및4.25코어를 사용합니다.필요한 총 용량:
- 데이터베이스 인스턴스의 경우:
- 272.5GB RAM
- 20.5개 코어
- SQL의 경우:
- 12.25GB RAM
- 4.25개 코어
- PostgreSQL 서버의 경우
- 284.75GB RAM
- 24.75개 코어
- 데이터베이스 인스턴스의 경우:
데이터베이스 인스턴스와 데이터 컨트롤러에 필요한 총 용량은 다음과 같습니다.
- 데이터베이스 인스턴스의 경우
- 284.75GB RAM
- 24.75개 코어
- 데이터 컨트롤러의 경우
- 16GB RAM
- 코어 4개
- 전체:
- 300.75GB RAM
- 28.75개 코어
- 데이터베이스 인스턴스의 경우
스토리지 크기 조정에 관한 자세한 내용은 스토리지 구성 문서를 참조하세요.
기타 고려 사항
코어 또는 RAM용 지정된 데이터베이스 인스턴스 크기 요청은 클러스터에서 사용 가능한 Kubernetes 노드의 용량을 초과할 수 없습니다. 예를 들어, Kubernetes 클러스터에 있는 가장 큰 Kubernetes 노드가 256GB RAM 및 24개 코어인 경우 512GB RAM 및 48개 코어 요청으로 데이터베이스 인스턴스를 만들 수 없습니다.
Kubernetes 노드 전체에서 사용 가능한 용량의 25% 이상을 유지합니다. 이 용량을 통해 Kubernetes는 다음을 수행할 수 있습니다.
- Pod를 만들도록 효율적으로 예약
- 탄력적 크기 조정 사용
- Kubernetes 노드의 롤링 업그레이드 지원
- 수요에 따른 장기적인 성장 촉진
크기 조정 계산에서 동일한 Kubernetes 클러스터의 Azure Arc 지원 데이터 서비스와 용량을 공유할 수 있는 Kubernetes 시스템 Pod 및 기타 워크로드의 리소스 요구 사항을 추가합니다.
계획된 유지 관리 및 재해 발생 중 고가용성을 유지하기 위해 지정된 시점에 사용할 수 없는 클러스터의 Kubernetes 노드 중 하나 이상을 계획합니다. Kubernetes는 유지 관리 또는 오류로 인해 중단된 특정 노드에서 실행 중이던 Pod의 일정을 변경하려고 시도합니다. 남은 노드에 사용 가능한 용량이 없는 경우 해당 Pod는 사용 가능한 용량이 다시 생길 때까지는 다시 생성 예약이 되지 않습니다. 대형 데이터베이스 인스턴스에 특별히 주의해야 합니다. 예를 들어 큰 데이터베이스 인스턴스의 리소스 요구 사항을 충족하기에 충분할 만큼 Kubernetes 노드가 크고 해당 노드가 실패하는 경우 Kubernetes는 데이터베이스 인스턴스 Pod를 다른 Kubernetes 노드로 예약할 수 없습니다.
Kubernetes 클러스터 크기의 최대 제한을 염두에 두세요.
Kubernetes 관리자가 네임스페이스/프로젝트에서 리소스 할당량을 설정했을 수 있습니다. 데이터베이스 인스턴스 크기를 계획할 때 이러한 할당량을 염두에 두세요.