Руководство по определению размера
Обзор руководства по определению размера
При планировании развертывания служб данных Azure Arc спланируйте правильный объем:
- Службы вычислений
- Память
- Хранилище
Эти ресурсы необходимы для:
- Контроллер данных
- Управляемые экземпляры SQL
- Серверы PostgreSQL
Так как службы данных с поддержкой Azure Arc развертываются в Kubernetes, вы можете добавить большую емкость в кластер Kubernetes с течением времени вычислительными узлами или хранилищем. В этом руководстве описываются минимальные требования и рекомендуется использовать размеры для некоторых распространенных требований.
Общие требования к размерам
Примечание.
Если вы не знакомы с понятиями, изложенными в этой статье, см. дополнительные сведения в статьях Kubernetes resource governance (Управление ресурсами Kubernetes) и Kubernetes size notation (Нотации размеров Kubernetes).
Количество ядер — целое число, больше или равное 1.
При развертывании с помощью Azure CLI (az) используйте два числа, чтобы задать значения памяти. В частности, используйте суффиксы:
KiMiGi
Максимально допустимые значения должны быть всегда больше запрошенных значений, если они указаны.
Предельные значения для ядер — это оплачиваемая метрика на управляемых экземплярах SQL и серверах PostgreSQL.
Минимальные требования для развертывания
Развертывание служб данных с поддержкой Azure Arc минимального размера можно считать контроллером данных Azure Arc, а также одним управляемым экземпляром SQL и одним сервером PostgreSQL. Для этой конфигурации требуется по крайней мере 16 ГБ ОЗУ и 4 ядра доступной емкости в кластере Kubernetes. Убедитесь, что у вас есть минимальный размер узла Kubernetes размером 8 ГБ ОЗУ и 4 ядра, а общая емкость 16 ГБ ОЗУ доступна во всех узлах Kubernetes. Например, у вас может быть 1 узел в 32 ГБ ОЗУ и 4 ядра, или у вас может быть 2 узла с 16 ГБ ОЗУ и 4 ядрами.
Дополнительные сведения о размере хранилища см. в статье Конфигурация хранилища.
Сведения о размере контроллера данных
Контроллер данных — это коллекция объектов pod, развернутых в кластере Kubernetes для предоставления API, службы контроллера, начального загрузчика, а также баз данных и панелей мониторинга. В этой таблице описаны значения по умолчанию и ограничения размеров и запросов памяти и ЦП.
| Имя объекта pod | Запрос ЦП | Запрос памяти | Ограничение ЦП | Предельный объем памяти |
|---|---|---|---|---|
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 |
metricsdcdaemonset— это объект, созданный на каждом из узлов Kubernetes в кластере. Числа в таблице — на узел. Если вы задали allowNodeMetricsCollection = false файл профиля развертывания перед созданием контроллера данных, это daemonset не создается.
Вы можете переопределить параметры по умолчанию для controldb модулей pod и управлять ими в файле YAML контроллера данных. Пример:
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 должен иметь следующие минимальные запросы ресурсов и ограничения.
| Уровень служб | Общее назначение | Критически важный для бизнеса |
|---|---|---|
| Запрос ЦП | Минимум: 1 Максимальное количество: 24 По умолчанию: 2 |
Минимальное количество: 3 Максимальное значение: неограниченное По умолчанию: 4 |
| Ограничение ЦП | Минимум: 1 Максимальное количество: 24 По умолчанию: 2 |
Минимальное количество: 3 Максимальное значение: неограниченное По умолчанию: 4 |
| Запрос памяти | Минимум: 2GiМаксимум: 128GiПо умолчанию: 4Gi |
Минимум: 2GiМаксимальное значение: неограниченное По умолчанию: 4Gi |
| Предельный объем памяти | Минимум: 2GiМаксимум: 128GiПо умолчанию: 4Gi |
Минимум: 2GiМаксимальное значение: неограниченное По умолчанию: 4Gi |
Каждый объект pod управляемого экземпляра SQL при создании имеет три контейнера:
| Имя контейнера | Запрос ЦП | Запрос памяти | Ограничение ЦП | Предельный объем памяти | Примечания. |
|---|---|---|---|---|---|
fluentbit |
100m |
100Mi |
Не указано | Не указано | Запросы fluentbit ресурсов контейнера в дополнение к запросам, указанным для управляемого экземпляра SQL. |
arc-sqlmi |
Задается пользователем или не задано. | Задается пользователем или не задано. | Задается пользователем или не задано. | Задается пользователем или не задано. | |
collectd |
Не указано | Не указано | Не указано | Не указано |
Размер тома по умолчанию для всех постоянных томов равен 5Gi.
Сведения о размерах сервера PostgreSQL
Каждый узел сервера PostgreSQL должен иметь следующие минимальные запросы ресурсов:
- Память:
256Mi - Ядра: 1
Каждый созданный модуль pod сервера PostgreSQL содержит три контейнера:
| Имя контейнера | Запрос ЦП | Запрос памяти | Ограничение ЦП | Предельный объем памяти | Примечания. |
|---|---|---|---|---|---|
fluentbit |
100m |
100Mi |
Не указано | Не указано | Запросы fluentbit ресурсов контейнера в дополнение к запросам, указанным для сервера PostgreSQL. |
postgres |
Задается пользователем или не задано. | Указанный пользователь или 256Mi (по умолчанию). |
Задается пользователем или не задано. | Задается пользователем или не задано. | |
arc-postgresql-agent |
Не указано | Не указано | Не указано | Не указано |
Суммарные размеры
Общий размер среды, необходимой для служб данных с поддержкой Azure Arc, в основном является функцией количества и размера экземпляров базы данных. Общий размер может быть трудно предсказать заранее, зная, что количество экземпляров может увеличиваться и уменьшаться, а также объем ресурсов, необходимых для каждого экземпляра базы данных, может измениться.
Базовый размер для определенной среды служб данных с поддержкой Azure Arc — это размер контроллера данных, который требует 4 ядра и 16 ГБ ОЗУ. После этого добавьте совокупный общий объем ядер и памяти, необходимых для экземпляров базы данных. Управляемый экземпляр SQL требуется один модуль pod для каждого экземпляра. Сервер PostgreSQL создает один модуль pod для каждого сервера.
Помимо ядер и памяти, запрашиваемых для каждого экземпляра базы данных, следует добавить 250m ядра и 250Mi ОЗУ для контейнеров агента.
Пример вычисления размера
Требования:
- "SQL1": 1 управляемый экземпляр SQL с 16 ГБ ОЗУ, 4 ядра
- "SQL2": 1 управляемый экземпляр SQL с 256 ГБ ОЗУ, 16 ядер
- Postgres1: 1 сервер PostgreSQL в 12 ГБ ОЗУ, 4 ядра
Расчет размеров развертывания:
Размер SQL1:
1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores])Для агентов для каждого модуля pod используются16.25 GiОЗУ и 4,25 ядра.Размер sql2:
1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores])Для агентов для каждого модуля pod используются256.25 GiОЗУ и 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 GiОЗУ и4.25ядра.Общая емкость, требуемая:
- Для экземпляров базы данных:
- 272,5 ГБ ОЗУ
- 20,5 ядра
- Для SQL:
- ОЗУ 12.25 ГБ
- 4.25 ядер
- Для сервера PostgreSQL
- ОЗУ 284,75 ГБ
- 24.75 ядер
- Для экземпляров базы данных:
Общая емкость, необходимая для экземпляров базы данных, а также контроллер данных:
- Для экземпляра базы данных
- ОЗУ 284,75 ГБ
- 24.75 ядер
- Для контроллера данных
- 16 ГБ ОЗУ
- 4 ядра
- В общей сложности:
- 300,75 ГБ ОЗУ
- 28.75 ядер.
- Для экземпляра базы данных
Дополнительные сведения о размере хранилища см. в статье Конфигурация хранилища.
Другие вопросы
Помните, что заданный запрос размера экземпляра базы данных по количеству ядер или размеру ОЗУ не может превышать доступную емкость узлов Kubernetes в кластере. Например, если самый большой узел Kubernetes в кластере Kubernetes составляет 256 ГБ ОЗУ и 24 ядра, невозможно создать экземпляр базы данных с запросом 512 ГБ ОЗУ и 48 ядер.
Сохраняйте по крайней мере 25 % доступной емкости на узлах Kubernetes. Эта емкость позволяет Kubernetes:
- Эффективное планирование создания модулей pod
- Включение эластичного масштабирования
- Поддерживает последовательное обновление узлов Kubernetes
- Упрощает долгосрочный рост по требованию
В вычислениях размера добавьте требования к ресурсам системных модулей pod Kubernetes и любые другие рабочие нагрузки, которые могут совместно использовать емкость со службами данных с поддержкой Azure Arc в одном кластере Kubernetes.
Чтобы обеспечить высокий уровень доступности во время планового обслуживания и непрерывности аварий, запланируйте по крайней мере один из узлов Kubernetes в кластере, которые будут недоступны в любой момент времени. Kubernetes пытается перепланировать модули pod, работающие на определенном узле, который был снят для обслуживания или из-за сбоя. Если на оставшихся узлах эти модули pod не будут перепланированы для создания, пока не будет доступной емкости. Будьте внимательны с большими экземплярами баз данных. Например, если достаточно большого узла Kubernetes, чтобы удовлетворить требования к ресурсам большого экземпляра базы данных, и этот узел завершается ошибкой, Kubernetes не запланирует, что модуль pod экземпляра базы данных на другом узле Kubernetes.
Учитывайте максимальные ограничения для размера кластера Kubernetes.
Администратор Kubernetes может настроить квоты ресурсов на пространство имен или проект. Имейте в виду эти квоты при планировании размеров экземпляра базы данных.