> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Архитектура

> Развертывание ClickHouse в собственной облачной инфраструктуре

export const Image = ({img, alt, size = "lg"}) => {
  const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
  return <div className={`ch-image-${normalizedSize}`}>
      <Frame>
        <img src={img} alt={alt} />
      </Frame>
    </div>;
};

<div id="key-concepts">
  ## Ключевые понятия
</div>

На диаграмме ниже показано, как соотносятся организации ClickHouse Cloud, облачные аккаунты и инфраструктура BYOC.

<Image img="https://mintcdn.com/private-7c7dfe99/96hCVnfqPOLWGWdD/images/cloud/reference/byoc-organization-hierarchy.svg?fit=max&auto=format&n=96hCVnfqPOLWGWdD&q=85&s=daf6af511f66dd875b79da156af40af9" size="lg" alt="Иерархия организации BYOC" width="960" height="720" data-path="images/cloud/reference/byoc-organization-hierarchy.svg" />

* **Организация ClickHouse Cloud:** Сущность верхнего уровня в ClickHouse Cloud, которая управляет пользователями, биллингом и сервисами ClickHouse, не относящимися к BYOC. Пользователи внутри организации могут получать доступ как к стандартным сервисам Cloud, так и к сервисам BYOC.
* **Организация ClickHouse BYOC:** Отдельная организация, предназначенная для управления развертываниями BYOC. Она использует общих пользователей с организацией Cloud, но связана с одним или несколькими облачными аккаунтами, в которых развернута инфраструктура BYOC.
* **Облачный аккаунт/проект/подписка:** Принадлежащий клиенту аккаунт AWS, проект GCP или подписка Azure, в которых развертывается инфраструктура BYOC. Каждый аккаунт/проект/подписка может размещать развертывания BYOC в одном или нескольких регионах. Для изоляции рекомендуется выделять отдельный аккаунт/проект/подписку для каждого развертывания BYOC.
* **Инфраструктура BYOC:** Набор облачных ресурсов, развернутых в определенном регионе облачного аккаунта, включая VPC/VNet, кластер Kubernetes (EKS/GKE/AKS), бакеты объектного хранилища, роли IAM/сервисные учетные записи/сервисные субъекты и вспомогательные сервисы. Один облачный аккаунт может содержать несколько инфраструктур BYOC в разных регионах.
* **Сервис ClickHouse:** Отдельный кластер ClickHouse, работающий в инфраструктуре BYOC. В одной и той же инфраструктуре BYOC может работать несколько сервисов.

<Note>
  Совмещать аккаунты AWS, проекты GCP и подписки Azure в рамках одной организации можно только для клиентов, которые не подключены через [маркетплейс облачного провайдера](/docs/ru/products/cloud/reference/billing/marketplace/overview).
</Note>

<div id="glossary">
  ## Глоссарий
</div>

* **VPC ClickHouse:** VPC, принадлежащая ClickHouse Cloud.
* **Customer BYOC VPC:** VPC в облачном аккаунте клиента, выделенная для развертывания ClickHouse Cloud BYOC, которая подготавливается и управляется ClickHouse Cloud.
* **Customer VPC:** Другие VPC в облачном аккаунте клиента, используемые для приложений, которым необходимо подключаться к Customer BYOC VPC.

<div id="architecture">
  ## Техническая архитектура
</div>

BYOC разделяет **плоскость управления ClickHouse**, работающую в VPC ClickHouse, и **плоскость данных**, полностью работающую в вашем облачном аккаунте. В VPC ClickHouse размещаются консоль ClickHouse Cloud, аутентификация, управление пользователями, API, биллинг, компоненты управления инфраструктурой, такие как контроллер BYOC, а также инструменты оповещения и управления инцидентами. Эти сервисы оркестрируют и контролируют ваше развертывание, но не хранят ваши данные.

В вашем **Customer BYOC VPC** ClickHouse разворачивает кластер Kubernetes (например, Amazon EKS), в котором работает плоскость данных ClickHouse. Как показано на схеме, сюда входят сам кластер ClickHouse, ClickHouse Operator и вспомогательные сервисы, такие как входной шлюз, DNS, управление сертификатами, экспортеры состояния и скрейперы. Выделенный стек мониторинга (Prometheus, Grafana, AlertManager и Thanos) также работает внутри вашего VPC, гарантируя, что метрики и оповещения создаются и остаются в вашей среде.

<br />

<Image img="https://mintcdn.com/private-7c7dfe99/96hCVnfqPOLWGWdD/images/cloud/reference/byoc-1.webp?fit=max&auto=format&n=96hCVnfqPOLWGWdD&q=85&s=06372fea5796921895e0dfa2c616e132" size="lg" alt="Архитектура BYOC" background="black" width="1667" height="1006" data-path="images/cloud/reference/byoc-1.webp" />

<br />

Основные облачные ресурсы, которые ClickHouse Cloud развернет в вашем аккаунте:

* **VPC:** Virtual Private Cloud, выделенная для вашего развертывания ClickHouse. Она может управляться как ClickHouse, так и вами, клиентом, и обычно соединяется с VPC ваших приложений через peering.
* **Роли IAM и политики:** Роли и разрешения, необходимые для Kubernetes, сервисов ClickHouse и стека мониторинга. Они могут быть подготовлены ClickHouse или предоставлены клиентом.
* **Бакеты хранилища:** Используются для хранения частей данных, резервных копий и (при необходимости) долгосрочных архивов метрик и логов.
* **Кластер Kubernetes:** Это может быть Amazon EKS, Google GKE или Azure AKS в зависимости от вашего облачного провайдера. В нем размещаются серверы ClickHouse и вспомогательные сервисы, показанные на схеме архитектуры.

По умолчанию ClickHouse Cloud создает новый выделенный VPC и настраивает необходимые роли IAM, чтобы обеспечить безопасную работу сервисов Kubernetes. Для организаций с более сложными требованиями к сети или безопасности также доступна возможность самостоятельно управлять VPC и ролями IAM. Такой подход дает больше гибкости при настройке сетевой конфигурации и более точный контроль разрешений. Однако самостоятельное управление этими ресурсами увеличивает вашу операционную нагрузку.

<div id="data-storage">
  ### Хранение данных
</div>

Все данные ClickHouse, резервные копии и данные обсервабилити остаются в вашем облачном аккаунте. Части данных и резервные копии хранятся в вашем Объектном хранилище (например, Amazon S3), а журналы — на томах хранилища, подключённых к узлам ClickHouse. В одном из будущих обновлений журналы будут записываться в LogHouse — сервис логирования на базе ClickHouse, который также работает внутри вашего BYOC VPC. Метрики могут храниться локально или в отдельном бакете в вашем BYOC VPC для длительного хранения. Связь плоскости управления между VPC ClickHouse и вашим BYOC VPC обеспечивается по защищённому, жёстко ограниченному каналу (например, через Tailscale, как показано на схеме); он используется только для операций управления, а не для трафика запросов.

<div id="control-plane-communication">
  ### Взаимодействие с плоскостью управления
</div>

VPC ClickHouse взаимодействует с вашей BYOC VPC по HTTPS (порт 443) для операций управления сервисом, включая изменение конфигурации, проверки работоспособности и команды развертывания. Этот трафик передает только данные плоскости управления, необходимые для оркестрации. Критически важные телеметрия и оповещения передаются из вашей BYOC VPC в VPC ClickHouse, чтобы обеспечить мониторинг использования ресурсов и работоспособности.

<div id="key-requirements">
  ## Основные требования для BYOC
</div>

Для модели развертывания BYOC необходимы два ключевых компонента, обеспечивающих надежную работу, простоту сопровождения и безопасность:

<div id="cross-account-iam-permissions">
  ### Межаккаунтные IAM-разрешения
</div>

Для подготовки и управления ресурсами в вашем облачном аккаунте ClickHouse Cloud требуются межаккаунтные IAM-разрешения. Это позволяет ClickHouse:

* **Подготавливать инфраструктуру**: создавать и настраивать VPC, подсети, группы безопасности и другие сетевые компоненты
* **Управлять кластерами Kubernetes**: развертывать и поддерживать кластеры EKS/GKE/AKS, группы узлов и компоненты кластера
* **Создавать ресурсы хранилища**: выделять S3 бакеты или эквивалентное объектное хранилище для данных и резервных копий
* **Управлять ролями IAM**: создавать и настраивать роли IAM для сервисных учетных записей Kubernetes и вспомогательных сервисов
* **Обеспечивать работу вспомогательных сервисов**: развертывать и управлять стеками мониторинга, контроллерами входного шлюза и другими компонентами инфраструктуры

Эти разрешения предоставляются через межаккаунтную роль IAM (AWS), сервисную учетную запись (GCP) или мультитенантный сервисный субъект (Azure), которые вы создаете на этапе первоначального онбординга. Роль соответствует принципу минимально необходимых привилегий, а разрешения выдаются только в объеме, необходимом для работы BYOC.

Подробную информацию о конкретных требуемых разрешениях см. в разделе [Справочник по привилегиям BYOC](/docs/ru/products/bring-your-own-cloud/reference/privilege).

<div id="tailscale-private-network">
  ### Подключение к частной сети Tailscale
</div>

Tailscale предоставляет безопасное подключение к частной сети по модели нулевого доверия между управляющими сервисами ClickHouse Cloud и вашим развертыванием BYOC. Это подключение позволяет:

* **Непрерывный мониторинг**: инженеры ClickHouse могут получать доступ к стеку мониторинга Prometheus, развернутому в вашем BYOC VPC, чтобы отслеживать состояние и производительность сервиса
* **Проактивное обслуживание**: инженеры могут выполнять плановое обслуживание, обновления и устранение неполадок
* **Экстренная поддержка**: в случае проблем с сервисом инженеры могут быстро получить доступ к вашему окружению, чтобы диагностировать и устранить проблему
* **Управление инфраструктурой**: управляющие сервисы могут координировать работу с вашей инфраструктурой BYOC для выполнения автоматизированных операций

Подключение Tailscale является **только исходящим** из вашего BYOC VPC — входящие подключения не требуются, что снижает риски для безопасности. Весь доступ:

* **Согласуется и аудитируется**: инженеры должны запрашивать доступ через внутреннюю систему согласования
* **Ограничен по времени**: срок действия доступа автоматически истекает через заданный период
* **Ограничен**: инженеры могут получать доступ только к системным таблицам и компонентам инфраструктуры, но никогда — к данным клиентов
* **Зашифрован**: весь обмен данными защищен сквозным шифрованием

Подробную информацию о том, как Tailscale работает в BYOC и какие меры безопасности применяются, см. в [документации по сетевой безопасности](/docs/ru/products/bring-your-own-cloud/reference/network-security#tailscale-private-network).

<div id="why-requirements-matter">
  ### Почему эти требования важны
</div>

Вместе эти два компонента позволяют ClickHouse Cloud:

* **Поддерживать надежность**: Заблаговременно отслеживать состояние развертывания и предотвращать проблемы
* **Обеспечивать безопасность**: Использовать доступ с минимально необходимыми привилегиями и полной возможностью аудита
* **Упрощать эксплуатацию**: Автоматизировать управление инфраструктурой, сохраняя за вами контроль
* **Предоставлять поддержку**: Быстро реагировать на проблемы и устранять их при возникновении

Все данные клиентов остаются в пределах вашего облачного аккаунта и никогда не передаются через эти каналы управления; доступ к ним через эти каналы также не осуществляется.

**Дополнительные рекомендации и соображения:**

* Убедитесь, что диапазоны CIDR сети для вашего BYOC VPC не пересекаются с существующими VPC, с которыми вы планируете настроить пиринг VPC.
* Четко помечайте свои ресурсы, чтобы упростить управление и поддержку.
* Заранее предусмотрите достаточный размер подсетей и их распределение по зонам доступности для обеспечения высокой доступности.
* Ознакомьтесь с [руководством по безопасности](/docs/ru/products/cloud/guides/security/audit-logging/byoc-security-playbook), чтобы понять зоны общей ответственности и лучшие практики при работе ClickHouse Cloud в вашей среде.
* Ознакомьтесь с полным руководством по онбордингу, где приведены пошаговые инструкции по первоначальной настройке учетной записи, конфигурации VPC, сетевому подключению (например, пирингу VPC) и делегированию роли IAM.

Если у вас есть особые требования или ограничения, обратитесь в ClickHouse Support за рекомендациями по расширенным сетевым конфигурациям или пользовательским политикам IAM.
