Стандартный онбординг

Первоначальную настройку BYOC можно выполнить с помощью шаблона CloudFormation (AWS), модуля Terraform (GCP) или модуля Terraform (Azure). При этом создается высокопривилегированное удостоверение (роль IAM/сервисный аккаунт/сервисный субъект), которое позволяет контроллерам BYOC из ClickHouse Cloud управлять вашей инфраструктурой.

Модуль Terraform для AWS

Если для развертываний в AWS вы предпочитаете Terraform вместо CloudFormation, используйте модуль terraform-byoc-onboarding:

module "clickhouse_onboarding" {
  source      = "github.com/ClickHouse/terraform-byoc-onboarding.git//modules/aws?ref=<version>"
  external_id = "<external-id-provided-by-clickhouse>"
}

Замените <version> на последний тег со страницы релизов модуля — всегда используйте самый свежий релиз.

Модуль выводит clickhouse_management_role_arn. В стандартном сценарии никаких действий с ним не требуется: онбординг продолжается в консоли ClickHouse Cloud. Однако сохраните его: ClickHouse запросит его, если ваша конфигурация отличается от стандартной (например, если требуется согласовать пользовательское имя роли).

Внешний ID AWS

В AWS роль IAM, созданная при настройке, доверяет ClickHouse Cloud, используя внешний ID (sts:ExternalId) для защиты от атак типа «confused deputy». При запуске онбординга консоль ClickHouse Cloud генерирует внешний ID для вашего аккаунта AWS и предварительно заполняет его в ссылке CloudFormation. Если вы используете Terraform, передайте то же значение в параметре external_id. Все инфраструктуры BYOC в рамках одного аккаунта AWS используют один и тот же внешний ID.

В консоли ClickHouse Cloud вам будет предложено настроить инфраструктуру, включая бакеты объектного хранилища, VPC/VNet и кластер Kubernetes. На этом этапе необходимо выбрать некоторые параметры, так как позже их изменить нельзя. В частности:

• Регион: Для развертываний BYOC доступны все публичные регионы, перечисленные в нашей документации по поддерживаемым регионам. Частные регионы в настоящее время не поддерживаются.

• Диапазон CIDR VPC/VNet: По умолчанию для диапазона CIDR VPC BYOC (AWS/GCP) или VNet (Azure) используется 10.0.0.0/16. Если вы планируете настроить пиринг VPC/VNet с другим аккаунтом, убедитесь, что диапазоны CIDR не пересекаются. Минимальный размер зависит от облачного провайдера:

  • AWS: /23
  • Azure: /23
  • GCP: /20

  Это минимальные требования, а не рекомендации: каждая реплика использует IP-адреса, поэтому для крупных развертываний требуется больший диапазон.

• Зоны доступности: Если вы планируете использовать пиринг VPC, согласование зон доступности между исходным аккаунтом и аккаунтом BYOC может помочь снизить затраты на межзональный трафик. Например, в AWS суффиксы зон доступности (a, b, c) могут соответствовать разным идентификаторам физических зон в разных аккаунтах. Подробнее см. в руководстве AWS.

Предварительная проверка

Когда вы нажимаете Set up Infrastructure, ClickHouse Cloud выполняет в вашем аккаунте набор предварительных проверок только для чтения, прежде чем создавать какие-либо ресурсы. Если все проверки пройдены, подготовка инфраструктуры продолжается. Если проверка не пройдена, настройка приостанавливается, и консоль показывает, в чём именно проблема, чтобы вы могли устранить её до создания каких-либо ресурсов.

Проверки подтверждают, что:

• Разрешения — удостоверение для управления (роль IAM / сервисный аккаунт / сервисный субъект) обладает разрешениями, необходимыми ClickHouse Cloud для подготовки инфраструктуры и работы вашего развертывания.
• Включенные сервисы (GCP) — в вашем проекте включены необходимые API Google Cloud (Compute Engine, Kubernetes Engine, Cloud Storage, Network Connectivity, IAM).
• Сеть (AWS с собственной VPC) — ваша VPC и подсети соответствуют сетевым требованиям: размер подсетей, необходимые теги, распределение по зонам доступности, исходящее подключение и доступные IP-адреса.
• Квоты и ограничения (AWS) — в вашем аккаунте достаточно квот сервисов (VPC, шлюзы NAT, Elastic IP, кластеры EKS, vCPU), и ни одна политика организации (SCP) не блокирует необходимые действия.

Если проверки не пройдены, для каждой из них указывается соответствующее действие и причина сбоя (например, iam:CreateRole · explicitDeny). Разверните Show passed checks, чтобы просмотреть все успешно пройденные проверки.

Чтобы устранить сбои, повторно примените последнюю версию стека ClickHouse CloudFormation или Terraform — либо выдайте указанные действия управляющему удостоверению (роль IAM / сервисный аккаунт / сервисный субъект) — а затем выберите один из вариантов:

• Повторно проверить — повторно запускает предварительные проверки. Используйте эту функцию после устранения указанных проблем, чтобы убедиться, что перед подготовкой ресурсов все готово.
• Всё равно продолжить — продолжает подготовку ресурсов, несмотря на неуспешные проверки. Используйте этот вариант только если вы уверены, что указанная ошибка — ложное срабатывание; иначе подготовка ресурсов, скорее всего, завершится сбоем.

Используйте приведённую ниже таблицу для устранения типичных сбоев.