FAQ
Онбординг и подготовка инфраструктуры
Как начать работу с BYOC?
Как начать работу с BYOC?
Свяжитесь с ClickHouse через контактную форму, и команда включит BYOC для вашей организации. Затем подготовьте выделенный облачный аккаунт (аккаунт AWS, проект GCP или подписку Azure) и следуйте руководству по стандартному онбордингу. Мы настоятельно рекомендуем использовать отдельный аккаунт, проект или подписку исключительно для BYOC.
Сколько занимает подготовка инфраструктуры и почему этот процесс иногда зависает?
Сколько занимает подготовка инфраструктуры и почему этот процесс иногда зависает?
Весь процесс обычно занимает от 45 до 90 минут. Такой широкий диапазон обусловлен тем, что большую часть времени облачный провайдер подготавливает ресурсы (кластер Kubernetes, балансировщики нагрузки, сетевые компоненты), а продолжительность этого процесса различается от запуска к запуску и не зависит от ClickHouse. Если подготовка инфраструктуры зависает, наиболее распространенные причины связаны с аккаунтом:
- Шаблон CloudFormation или модуль Terraform был изменен перед применением — например, добавлен
PermissionsBoundaryили роль IAM была переименована в соответствии с соглашением об именовании (в AWS сохраняйте имя по умолчаниюClickHouseManagementRole, если ClickHouse явно не одобрил другое). Применяйте артефакты в предоставленном виде: поддерживаемые настройки доступны в качестве параметров, а любые другие изменения должны быть предварительно одобрены ClickHouse. - Политики уровня организации (SCP AWS, политики организации GCP, например
iam.allowedPolicyMemberDomains, или политики Azure, ограничивающие назначения ролей) блокируют принятие роли или привязки IAM. - Несоответствие внешнего ID для роли онбординга (см. вопрос о внешнем ID ниже).
- Ограничения квот аккаунта (например, на Elastic IP или VPC в AWS).
Какое значение следует использовать для внешнего ID в шаблоне онбординга?
Какое значение следует использовать для внешнего ID в шаблоне онбординга?
Консоль ClickHouse Cloud генерирует внешний ID для вашего аккаунта AWS при запуске онбординга и предварительно заполняет его в ссылке CloudFormation (параметр
ExternalID); при использовании Terraform передайте то же значение как external_id. Все инфраструктуры BYOC в одном аккаунте AWS используют один внешний ID. Не задавайте собственное значение: оно должно соответствовать значению, ожидаемому автоматизацией ClickHouse, иначе межаккаунтную роль не удастся принять, а подготовка инфраструктуры завершится ошибкой. Подробнее см. Внешний ID AWS.Почему мой внешний ID — emptyid?
Почему мой внешний ID — emptyid?
Инфраструктуры BYOC, для которых онбординг был выполнен до введения внешних ID, используют значение-заполнитель
emptyid для обратной совместимости. Когда вы добавляете новую инфраструктуру в аккаунт AWS с существующим устаревшим развертыванием, консоль повторно использует этот заполнитель, чтобы все инфраструктуры в аккаунте сохраняли согласованную конфигурацию доверия. Если вы хотите перейти на уникальный внешний ID, обратитесь в ClickHouse Support.Может ли BYOC использовать существующий VPC? А как насчет общих VPC?
Может ли BYOC использовать существующий VPC? А как насчет общих VPC?
В AWS и GCP можно выполнить развертывание в существующий VPC, расположенный в том же аккаунте или проекте, что и инфраструктура BYOC. См. руководства по настройке для AWS и GCP. В GCP также поддерживается Shared VPC из отдельного хост-проекта — см. Shared VPC из хост-проекта, где описаны предварительные требования, поле в консоли, которое нужно заполнить, и права, которые модуль онбординга добавляет в ваш хост-проект. Возможность использования собственного VNet в Azure появится в ближайшее время.В AWS подсети, предоставленные из другого аккаунта через AWS Resource Access Manager (RAM), также поддерживаются, поэтому вы можете держать сеть централизованно в хаб-аккаунте, а инфраструктуру BYOC запускать в спок-аккаунте. Одно предварительное требование специфично для этой схемы: у ресурсов, предоставленных через RAM, представление тегов действует в рамках каждого аккаунта, поэтому необходимые теги VPC и подсетей должен применить сам спок-аккаунт — теги, примененные из хаб-аккаунта, не видны в спок-аккаунте, и без них подготовка инфраструктуры завершается ошибкой. Таблицы маршрутизации остаются во владении хаб-аккаунта, который по-прежнему отвечает за NAT и маршрутизацию исходящего трафика в общих подсетях. Теги и другие требования см. в руководстве по настройке AWS.Обратите внимание, что для управляемого клиентом VPC по умолчанию включен только частный балансировщик нагрузки (см. конфигурацию).
Можно ли установить BYOC в существующий кластер Kubernetes?
Можно ли установить BYOC в существующий кластер Kubernetes?
Нет. Кластер Kubernetes (EKS, GKE или AKS) создаётся и полностью управляется ClickHouse. Это необходимо, чтобы ClickHouse мог надёжно эксплуатировать платформу и своевременно её обновлять.
Можно ли запускать собственные рабочие нагрузки в кластере BYOC или облачном аккаунте?
Можно ли запускать собственные рабочие нагрузки в кластере BYOC или облачном аккаунте?
В облачном аккаунте: это возможно, но совместно размещённые ресурсы всегда в той или иной мере входят в область разрешений ClickHouse. В AWS большинство разрешений на запись ограничены тегами и префиксами (ресурсы, подготовленные ClickHouse, имеют
clickhouse-byoc=true), однако небольшое число действий EC2 нельзя ограничить тегами; в GCP и Azure identity для онбординга имеют разрешения на уровне проекта или подписки. Не размещайте свои ресурсы рядом с ресурсами, подготовленными ClickHouse, и по возможности используйте выделенный аккаунт, проект или подписку в каждом облаке — это по-прежнему настоятельная рекомендация.В Kubernetes-кластере: это возможно с ограничениями — используйте собственные группы узлов с taint и toleration, не используйте пространства имен, управляемые ClickHouse, и не устанавливайте контроллеры допуска или движки политик, действующие на уровне всего кластера, так как они могут заблокировать реконсиляцию компонентов ClickHouse. Опишите свой план службе поддержки, чтобы мы могли подтвердить отсутствие конфликтов.Вычислительные ресурсы и масштабирование
Можно ли создать несколько сервисов в одной инфраструктуре BYOC?
Можно ли создать несколько сервисов в одной инфраструктуре BYOC?
Да. Инфраструктуру (включая кластер Kubernetes) необходимо развернуть только один раз для каждой комбинации облачной учётной записи, проекта или подписки и региона; все создаваемые вами сервисы в этом регионе используют её совместно.
Какие регионы поддерживаются для BYOC?
Какие регионы поддерживаются для BYOC?
Для развёртываний BYOC доступны все публичные регионы, перечисленные в документации поддерживаемых регионов. BYOC развёртывается в трёх зонах доступности, поэтому регионы с менее чем тремя зонами и AWS Local Zones не поддерживаются. Если нужного вам региона нет в списке, обратитесь к представителю ClickHouse, чтобы обсудить возможность его использования.
Будут ли дополнительные затраты ресурсов? Какие ресурсы необходимы для запуска сервисов помимо экземпляров ClickHouse?
Будут ли дополнительные затраты ресурсов? Какие ресурсы необходимы для запуска сервисов помимо экземпляров ClickHouse?
Помимо самих экземпляров ClickHouse (серверов ClickHouse и ClickHouse Keeper), мы также запускаем вспомогательные сервисы, такие как
clickhouse-operator, cluster autoscaler, Istio и стек мониторинга.Потребление ресурсов этими общими компонентами относительно стабильно и не растёт линейно с количеством или размером ваших сервисов ClickHouse. В качестве приблизительного ориентира: выделенная системная группа узлов для этих рабочих нагрузок суммарно требует около 48 vCPU и 192 ГБ памяти — например, в AWS это примерно шесть инстансов 2xlarge. Кроме того, в каждом хранилище работает выделенный ансамбль ClickHouse Keeper из трёх узлов, общий для всех сервисов в этом хранилище. Подробнее см. в модели затрат.Поддерживает ли BYOC автомасштабирование?
Поддерживает ли BYOC автомасштабирование?
Автомасштабирование на уровне сервиса (вертикальное) находится в планах. Уже доступны: ручное вертикальное и горизонтальное масштабирование через консоль, запланированное масштабирование для предсказуемых шаблонов нагрузки, автоматический переход в режим простоя и выход из него для нерегулярных рабочих нагрузок, а также автоматическое масштабирование групп узлов на уровне инфраструктуры — вам никогда не нужно самостоятельно управлять узлами. ClickHouse Keeper отслеживается и масштабируется ClickHouse.
На каких типах инстансов работает BYOC? Можно ли изменить семейство инстансов?
На каких типах инстансов работает BYOC? Можно ли изменить семейство инстансов?
BYOC работает на тщательно подобранном наборе групп узлов, а не на произвольных типах инстансов. Группы узлов для рабочих нагрузок (серверы ClickHouse и Keeper) по умолчанию используют ARM-инстансы, оптимизированные для работы с памятью (Graviton в AWS), тогда как системная группа узлов обычно использует инстансы x86. Другие семейства инстансов, соотношения CPU и памяти или архитектуры могут быть предоставлены по запросу через поддержку; spot-инстансы не поддерживаются. См. конфигурацию.
Можно ли запускать очень маленькие реплики, чтобы снизить затраты?
Можно ли запускать очень маленькие реплики, чтобы снизить затраты?
Каждая реплика запускается как один pod на собственном узле — размер узла соответствует размеру реплики, узлы выделяются по требованию, и несколько реплик никогда не размещаются на одном узле. Поэтому очень маленькие реплики неэффективны: бо́льшая доля ресурсов оборудования приходится на накладные расходы, а пропускная способность сети и диска масштабируется вместе с размером инстанса. Размеры меньше предлагаемых в консоли доступны по индивидуальному запросу через поддержку.
Можно ли разделить рабочие нагрузки приёма данных и выполнения запросов?
Можно ли разделить рабочие нагрузки приёма данных и выполнения запросов?
Да. В BYOC поддерживаются хранилища (разделение вычислительных ресурсов): несколько сервисов совместно используют одни и те же данные, поэтому можно выделить одни сервисы для приёма данных, а другие — для выполнения запросов.
Сеть и безопасность
Можно ли ограничить или отозвать разрешения, выданные при установке?
Можно ли ограничить или отозвать разрешения, выданные при установке?
В AWS и GCP можно сразу сократить набор привилегий: артефакты онбординга параметризованы, поэтому при использовании собственной VPC можно не предоставлять разрешения на управление топологией сети VPC (
IncludeVPCWritePermissions в CloudFormation, include_vpc_write_permissions в модулях Terraform). В GCP это ограничивает только управление топологией: ClickHouse сохраняет доступ на запись к принадлежащим ему сетевым ресурсам внутри VPC, таким как подключение сервиса Private Service Connect и входящие адреса. NAT-подсеть Private Service Connect в их число не входит: при использовании собственной VPC вы создаёте её самостоятельно перед включением private link. В AWS также можно — в закрытой предварительной версии, доступ к которой предоставляется через поддержку, — самостоятельно управлять ролями IAM (IncludeIAMWritePermissions=false, см. роли IAM, управляемые клиентом); межаккаунтные роли защищены внешним ID от атак типа «confused deputy». В Azure модуль онбординга предоставляет фиксированную роль на уровне подписки без параметров ограничения области действия. Во всех облаках некоторые разрешения требуются только для определённых возможностей и могут быть удалены, если вы точно не будете их использовать. Если требуется дополнительно ограничить разрешения сверх того, что позволяют артефакты, обратитесь в поддержку.После подготовки не удаляйте разрешения у управляющей identity в одностороннем порядке: ClickHouse непрерывно сверяет состояние инфраструктуры, и отсутствие разрешений нарушит подготовку, обновления и поддержку. Чтобы изменить выданные разрешения или полностью вывести сервис из эксплуатации, согласуйте это с поддержкой (см. вопрос о выводе из эксплуатации ниже).Что именно ClickHouse может делать в нашем облачном аккаунте? Может ли наша команда безопасности проверить разрешения?
Что именно ClickHouse может делать в нашем облачном аккаунте? Может ли наша команда безопасности проверить разрешения?
Справочник по привилегиям содержит общее описание всех ролей и identity, а также их назначения в AWS, GCP и Azure. Для identity онбординга (bootstrap) точный набор политик определяется опубликованными артефактами — шаблоном CloudFormation и модулями Terraform, — которые команда безопасности может проверить напрямую. Дополнительные identity, создаваемые ClickHouse после онбординга (роли контроллера, сервисные аккаунты и управляемые identity), описаны для каждого провайдера в справочнике по привилегиям. Поскольку они находятся в вашем аккаунте, вы можете проверить их фактические политики в консоли облачного провайдера, а также увидеть их создание и использование в CloudTrail или аналогичных службах GCP/Azure. В AWS большинство разрешений на запись управляющей роли ограничены тегами ресурсов и префиксами имён, например
clickhouse-cloud-*, поэтому она, как правило, не может изменять ресурсы, которые не создавала (небольшое число действий EC2 нельзя ограничить тегами). Кроме того, у неё нет доступа к объектам в ваших бакетах данных: доступ к объектам ограничен identity внутри кластера, область действия которых ограничена рабочими нагрузками ClickHouse. В GCP и Azure identity онбординга вместо этого имеют разрешения на уровне проекта или подписки — это одна из причин, по которой настоятельно рекомендуется использовать выделенный проект или подписку. Разрешения на чтение шире, поскольку они необходимы для непрерывной сверки состояния.Какой доступ сотрудники ClickHouse имеют к нашему окружению и данным?
Какой доступ сотрудники ClickHouse имеют к нашему окружению и данным?
По умолчанию — никакого доступа к вашим данным. Для устранения неполадок инженеры должны пройти внутренний процесс эскалации just-in-time; доступ ограничен по времени, предоставляется на основе сертификатов, ограничен таблицами
system.* (без таблиц с данными клиентов), записывается в журнал и проверяется нашей командой безопасности. Любой запрос, выполненный инженером ClickHouse, отображается в вашем system.query_log. Для диагностики инфраструктуры та же эскалация с обязательным одобрением может также предоставить ограниченный по времени доступ к API-серверу Kubernetes и стеку мониторинга внутри кластера через Tailscale. См. доступ ClickHouse к данным для описания модели доступа к данным и сетевую безопасность для описания модели подключения.Рассматривали ли вы будущие средства контроля безопасности для доступа инженеров ClickHouse к инфраструктуре клиентов при устранении неполадок?
Рассматривали ли вы будущие средства контроля безопасности для доступа инженеров ClickHouse к инфраструктуре клиентов при устранении неполадок?
Да. В нашей дорожной карте предусмотрена реализация механизма, управляемого клиентом, который позволит клиентам одобрять доступ инженеров к кластеру. Сейчас инженеры должны пройти внутренний процесс эскалации, чтобы получить just-in-time доступ к кластеру. Все такие действия записываются в журнал и проверяются нашей командой безопасности.
Какие данные покидают наш аккаунт?
Какие данные покидают наш аккаунт?
Только операционные метаданные: события состояния сервиса и резервных копий, метрики использования для выставления счетов и уведомления об оповещениях. Ваши данные, резервные копии, журналы и данные мониторинга остаются в вашем аккаунте. Полный список исходящих потоков приведён в разделе сетевая безопасность.
Как плоскость управления ClickHouse обращается к Kubernetes API в нашем аккаунте? Требуется ли Tailscale?
Как плоскость управления ClickHouse обращается к Kubernetes API в нашем аккаунте? Требуется ли Tailscale?
По умолчанию конечная точка Kubernetes API публична, а то, чем ограничивается доступ к ней, различается в зависимости от облака: в AWS это список разрешённых IP, содержащий только NAT IP-адреса ClickHouse — пока используется этот вариант по умолчанию, не удаляйте записи ClickHouse из списка разрешённых адресов, поскольку они нужны плоскости управления для управления кластером, — а в GCP и Azure это облачный IAM, а не список разрешённых IP (см. Доступность API-сервера Kubernetes). Вместо этого конечную точку можно переключить на доступ только из частной сети, согласовав это с командой ClickHouse: через Tailscale (только исходящие подключения; также используется для доступа для устранения неполадок) или в AWS через VPC Lattice (закрытая предварительная версия) — см. конфигурацию. Обратите внимание: это относится только к Kubernetes API. Вызовы API облачного провайдера (например, EKS и EC2 в AWS) выполняются из сети ClickHouse Cloud с использованием межаккаунтного принятия роли и никогда не могут маршрутизироваться через Tailscale — см. API облачного провайдера и Kubernetes API.
Как работает сетевое взаимодействие между сетью BYOC и объектным хранилищем?
Как работает сетевое взаимодействие между сетью BYOC и объектным хранилищем?
В AWS трафик между вашим Customer BYOC VPC и S3 для данных таблиц и резервных копий, а также для долговременных архивов метрик и журналов, если они у вас включены, идёт по HTTPS (порт 443) через AWS S3 API. Актуальные журналы записываются на тома хранения, подключённые к вашим узлам ClickHouse, а не в объектное хранилище — см. границы сети. Этот трафик проходит через шлюзовую конечную точку VPC для S3, поэтому остаётся в сети AWS, не проходит через публичный интернет и не влечёт расходов на NAT-шлюз. В GCP доступ к Google API аналогично использует Private Google Access. В Azure данные хранятся в аккаунтах Azure Blob Storage в рамках вашей подписки.
Данные находятся в нашем собственном бакете — можем ли мы читать или изменять их напрямую?
Данные находятся в нашем собственном бакете — можем ли мы читать или изменять их напрямую?
Нет. Блобы с данными таблиц хранятся в общей структуре без отдельных путей для каждой таблицы, поэтому объекты нельзя однозначно сопоставить с таблицами, а любое прямое изменение может повредить ваши сервисы. Никогда не изменяйте содержимое бакета напрямую; если вы подозреваете проблему, создайте обращение в поддержку.
Какие порты используются для взаимодействия клиентов и кластера?
Какие порты используются для взаимодействия клиентов и кластера?
Клиентские подключения завершаются на балансировщике нагрузки через TLS-порты: 8443 (интерфейс HTTPS) и 9440 (собственный протокол через TLS); порт 443 также направляет трафик к интерфейсу HTTPS. Интерфейс MySQL (порт 3306) сейчас не открыт в BYOC — он включён в план развития (см. обзор).Внутри сети для внутрикластерного взаимодействия используются собственный протокол на порту 9000, HTTP на порту 8123 и межсерверное взаимодействие на порту 9009 для репликации и распределённых запросов. Эти внутренние порты и порты ClickHouse Keeper никогда не открываются ни на одном балансировщике нагрузки.
Доступны ли конечные точки наших сервисов из публичного интернета? Можно ли использовать только частный доступ?
Доступны ли конечные точки наших сервисов из публичного интернета? Можно ли использовать только частный доступ?
При использовании VPC, управляемого ClickHouse, каждый сервис по умолчанию получает публичный балансировщик нагрузки, защищённый списком разрешённых IP-адресов; в консоли ClickHouse Cloud также можно включить частный балансировщик нагрузки, доступный из вашей сети и связанных с ней сетей (см. Балансировщики нагрузки). При использовании VPC, управляемого клиентом, настройки по умолчанию обратные: включён только частный балансировщик нагрузки. IP-фильтрация применяется на уровне ingress-прокси, поэтому при сканировании порты балансировщика нагрузки могут выглядеть открытыми, однако подключения из источников, отсутствующих в списке, отклоняются. Публичную конечную точку можно полностью отключить, когда от неё больше ничего не зависит. В селекторе подключения консоли отображаются конечные точки для каждого пути подключения, включённого для вашего сервиса. См. раздел Подключение.
Можем ли мы использовать собственный DNS-домен или предоставить собственные TLS-сертификаты?
Можем ли мы использовать собственный DNS-домен или предоставить собственные TLS-сертификаты?
Пока нет. Конечные точки сервисов предоставляются в домене
clickhouse-byoc.com с сертификатами, управляемыми ClickHouse.Как настроить AWS PrivateLink, GCP Private Service Connect или Azure Private Link?
Как настроить AWS PrivateLink, GCP Private Service Connect или Azure Private Link?
Следуйте руководствам по настройке сети для AWS, GCP и Azure. Часто упускают два момента: конечные точки разрешаются для каждого сервиса отдельно, поэтому их необходимо заново регистрировать для каждого нового сервиса; кроме того, если вы используете собственный DNS, разрешение DNS-имен частных конечных точек необходимо настроить со своей стороны. После настройки воспользуйтесь селектором подключения в консоли, чтобы скопировать правильное имя хоста частной конечной точки.
Можно ли подключиться через PrivateLink из другого региона AWS?
Можно ли подключиться через PrivateLink из другого региона AWS?
Да, но переключатель Enable private link в консоли действует только для потребителей в том же регионе: AWS по умолчанию отключает межрегиональный доступ к сервисам конечных точек, а консоль ClickHouse им не управляет. Поскольку сервис конечной точки находится в вашем аккаунте BYOC, включить его нужно самостоятельно: добавьте регионы потребителей в список Supported regions сервиса конечной точки в консоли AWS, затем создайте конечную точку с межрегиональной опцией на стороне потребителя. ClickHouse не изменяет и не сбрасывает эти значения. Инструкции см. в руководстве по настройке PrivateLink; применяются тарифы AWS на межрегиональную передачу данных.
Есть ли список конечных точек, которые нужно разрешить в правилах брандмауэра или исходящего трафика?
Есть ли список конечных точек, которые нужно разрешить в правилах брандмауэра или исходящего трафика?
Единого опубликованного списка конечных точек нет. Кластеру необходим исходящий доступ в интернет (напрямую или через NAT), а также частный доступ к API облачного провайдера — см. требования к сетевому подключению. Если ваша сетевая политика требует явного перечня, обратитесь в службу поддержки, чтобы проверить вашу конфигурацию.
Наши средства безопасности отметили привилегированные контейнеры или монтирования хоста в кластере BYOC — это ожидаемо?
Наши средства безопасности отметили привилегированные контейнеры или монтирования хоста в кластере BYOC — это ожидаемо?
Некоторым компонентам платформы действительно требуются повышенные привилегии или доступ к файловой системе хоста: например, драйверу EBS CSI, заданиям по настройке узлов и Prometheus node exporter (который читает
/proc и /sys). Если сканер выявил проблемы, передайте их в службу поддержки — мы подтвердим, является ли каждая из них штатной или требует действий.Поддерживаете ли вы ключи шифрования, управляемые клиентом (CMEK)?
Поддерживаете ли вы ключи шифрования, управляемые клиентом (CMEK)?
Пока нет — для BYOC эта возможность недоступна. Данные при хранении шифруются ключами, управляемыми облачным провайдером. Актуальный список запланированных возможностей см. в обзоре.
Обновления и обслуживание
Как выполняются обновления версий ClickHouse? Можно ли выбрать частоту обслуживания?
Как выполняются обновления версий ClickHouse? Можно ли выбрать частоту обслуживания?
Обновления выполняются так же, как в ClickHouse Cloud: сервисы подключаются к каналам релизов (быстрому, стандартному, медленному) и следуют запланированным окнам обслуживания. Чтобы настроить их, обратитесь в службу поддержки. Обновления выполняются не реже одного раза в неделю. Обновление происходит последовательно, реплика за репликой (make-before-break), поэтому сервис целиком не простаивает. См. operations.
Кто отвечает за обновления Kubernetes и какого влияния следует ожидать?
Кто отвечает за обновления Kubernetes и какого влияния следует ожидать?
ClickHouse самостоятельно выполняет обновления Kubernetes заблаговременно, до окончания поддержки со стороны провайдера, и согласовывает окно через службу поддержки. Обновления плоскости управления проходят прозрачно; при обновлении групп узлов узлы обновляются по одному с семантикой make-before-break. Поэтому при перезапуске подов возможны кратковременные сбросы соединений, но потери данных не будет. См. operations.
Резервные копии и аварийное восстановление
Где хранятся резервные копии?
Где хранятся резервные копии?
В объектном хранилище вашего облачного аккаунта — резервные копии никогда не покидают вашу среду. Расписание резервного копирования и срок хранения можно настроить; для их изменения обратитесь в службу поддержки.
Что входит в резервную копию? Создаются ли резервные копии системных таблиц?
Что входит в резервную копию? Создаются ли резервные копии системных таблиц?
Все созданные пользователями базы данных, таблицы и объекты, а также объекты управления доступом (пользователи, роли, профили настроек, политики уровня строк, квоты) и пользовательские функции. Системные таблицы логов, такие как
system.query_log, не включаются.Почему с меня взимается плата за резервные копии, срок хранения которых уже истёк?
Почему с меня взимается плата за резервные копии, срок хранения которых уже истёк?
Резервные копии образуют цепочки: полная резервная копия и зависящие от неё инкрементальные копии. Базовая полная резервная копия необходима для восстановления любой инкрементальной копии в этой цепочке, поэтому она сохраняется, пока не истечёт срок хранения всех зависимых инкрементальных копий.
Как самостоятельно отслеживать состояние резервного копирования?
Как самостоятельно отслеживать состояние резервного копирования?
Есть два способа: конечные точки резервного копирования ClickHouse Cloud API и метрики резервного копирования (счётчики запуска, завершения и сбоев), предоставляемые стеком мониторинга в кластере. Рекомендуем настроить оповещения о сбоях в собственной системе мониторинга. См. раздел обсервабилити.
Как выполнить требования к аварийному восстановлению (RPO/RTO)?
Как выполнить требования к аварийному восстановлению (RPO/RTO)?
BYOC развёртывается в трёх зонах доступности, а операции записи подтверждаются только после подтверждения от объектного хранилища. Межрегиональная репликация пока недоступна, поэтому аварийное восстановление в пределах региона основано на резервном копировании, а достижимый RPO ограничен частотой создания резервных копий. Частоту резервного копирования и пункт назначения можно настроить в соответствии с вашими целевыми показателями, в том числе выполнять резервное копирование в бакет в другом регионе — для настройки обратитесь в службу поддержки.
Обсервабилити
Как интегрировать BYOC с собственными системами мониторинга и оповещений?
Как интегрировать BYOC с собственными системами мониторинга и оповещений?
Стек мониторинга (Prometheus, Grafana, AlertManager) работает в вашем аккаунте, и к нему можно обращаться напрямую по частному подключению: отправлять запросы через PromQL API, федеративно подключать его к собственному Prometheus или собирать метрики с конечной точки ClickHouse
/metrics_all для каждого сервиса. Готовой интеграции со сторонними платформами, такими как Datadog, пока нет — используйте их совместимый с Prometheus механизм ингестии. Сведения о конечных точках и настройке см. в разделе обсервабилити.Стоимость
За что мы платим при использовании BYOC?
За что мы платим при использовании BYOC?
Вы получите два отдельных счёта: ClickHouse Cloud взимает плату в зависимости от объёма памяти, выделенной вашим сервисам, а облачный провайдер напрямую выставляет счёт за базовую инфраструктуру по себестоимости, без наценки. Подробная справочная информация о стоимости сейчас доступна для AWS: см. модель стоимости, платные сервисы AWS и лимиты сервисов AWS.
Доступность и жизненный цикл
У каких облачных провайдеров доступна BYOC?
У каких облачных провайдеров доступна BYOC?
AWS, GCP и Azure доступны для общего использования. Сведения о поддерживаемых возможностях и регионах в каждом облаке см. в обзоре.
Как вывести среду BYOC из эксплуатации?
Как вывести среду BYOC из эксплуатации?
Завершите работу сервисов и инфраструктуры BYOC через консоль ClickHouse — не начинайте с удаления ресурсов или отзыва разрешений в консоли облачного провайдера: это разрывает соединение с плоскостью управления в процессе работы и требует ручной очистки. После завершения процедуры через консоль удалите стек онбординга (стек CloudFormation или модуль Terraform) и все оставшиеся ресурсы. В AWS все ресурсы, созданные ClickHouse, помечены тегом
clickhouse-byoc=true, поэтому затем можно перечислить их и убедиться, что ничего не осталось. В GCP и Azure область проверки ограничена выделенным проектом или подпиской, для которых вы прошли онбординг.SLA по доступности
Предоставляет ли ClickHouse SLA по доступности для BYOC?
Предоставляет ли ClickHouse SLA по доступности для BYOC?
Нет, поскольку плоскость данных размещается в облачной среде клиента, доступность сервиса зависит от ресурсов, которые находятся вне контроля ClickHouse. Поэтому ClickHouse не предоставляет формальный SLA по доступности для развертываний BYOC. Обратите внимание, что работающие сервисы функционируют независимо от плоскости управления ClickHouse: сбой плоскости управления не приводит к остановке сервисов, работающих в вашем аккаунте. Если у вас есть дополнительные вопросы, пожалуйста, обратитесь в службу поддержки: support@clickhouse.com.