Skip to main content

​
FAQ

​
引导与预配

请通过联系表单联系 ClickHouse，我们的团队将为您的组织启用 BYOC。随后，准备一个专用云账户 (AWS 账户、GCP 项目或 Azure 订阅) ，并按照标准引导指南操作。我们强烈建议使用仅用于 BYOC 的专用账户、项目或订阅。
整个过程预计约需 45–90 分钟。时间跨度较大，是因为大部分时间都用于等待云提供商预配资源 (Kubernetes 集群、负载均衡器和网络组件) ；每次执行所需时间并不固定，且不受 ClickHouse 控制。预配停滞时，最常见的原因通常与账户有关：
  • 在应用 CloudFormation 模板或 Terraform 模块前对其进行了修改——例如添加 PermissionsBoundary，或为符合命名规范而重命名 IAM 角色 (在 AWS 上，请保留默认的 ClickHouseManagementRole 名称，除非 ClickHouse 已明确批准使用其他名称) 。请按原样应用这些文件——支持的自定义项会以参数形式提供，其他任何更改均需先获得 ClickHouse 批准。
  • 组织级策略 (AWS SCP、GCP 组织策略，例如 iam.allowedPolicyMemberDomains，或限制角色分配的 Azure 策略) 阻止角色承担或 IAM 绑定。
  • 引导角色的外部 ID 不匹配 (请参阅下方关于外部 ID 的问题) 。
  • 账户配额限制 (例如 AWS 上的 Elastic IP 或 VPC) 。
预配会自动重试，并会在解决根本问题后自动恢复。如果基础设施卡住超过数小时，请联系支持团队。
开始引导时，ClickHouse Cloud 控制台会为您的 AWS 账户生成外部 ID，并在 CloudFormation 链接中预填该值 (ExternalID 参数) ；如果使用 Terraform，请将相同的值作为 external_id 传入。同一 AWS 账户中的所有 BYOC 基础设施共享相同的外部 ID。请勿自行指定值：它必须与 ClickHouse 自动化流程预期的值相匹配，否则无法承担跨账户角色，预配将失败。有关详细信息，请参阅 AWS 外部 ID。
在引入外部 ID 之前完成引导的 BYOC 基础设施，会使用占位符值 emptyid 以保持向后兼容性。当您在已有旧版部署的 AWS 账户中添加新基础设施时，控制台会重复使用此占位符，以确保该账户中的所有基础设施保持一致的信任配置。如果您想切换为唯一的外部 ID，请联系 ClickHouse 支持团队。
在 AWS 和 GCP 上，您可以部署到与 BYOC 基础设施位于同一账户或项目中的现有 VPC。请参阅 AWS 和 GCP 自定义指南。在 GCP 上，还支持来自独立宿主项目的共享 VPC：引导模块可直接接受宿主项目和子网——有关设置和前置条件，请参阅其“共享 VPC”部分。Azure 的自带 VNet 支持即将推出。在 AWS 上，不支持来自其他账户的共享子网 (AWS RAM) ——请改用通过 VPC peering 或 PrivateLink 连接到现有网络的专用账户。请注意，使用客户管理的 VPC 时，默认仅启用私网负载均衡器 (请参阅配置) 。
不可以。Kubernetes 集群 (EKS、GKE 或 AKS) 由 ClickHouse 创建并完全管理。这是确保 ClickHouse 能够可靠运营平台并持续保持其更新所必需的。
在云账户中：可以，但共置资源始终会在一定程度上受到 ClickHouse 权限的影响——在 AWS 上，大多数写入权限都按标签和前缀限定 (由 ClickHouse 预配的资源带有 clickhouse-byoc=true) ，但少量 EC2 操作无法按标签限定；在 GCP 和 Azure 上，引导配置身份拥有项目级或订阅级权限。请将您的资源与 ClickHouse 预配的资源隔离，并优先在每个云平台使用专用账户、项目或订阅——这仍是我们的强烈建议。在 Kubernetes 集群中：可以，但有一定限制——请使用自己的节点组，并配置污点和容忍；避开由 ClickHouse 管理的命名空间；也不要安装集群级准入控制器或策略引擎，因为它们可能会阻碍 ClickHouse 组件的协调。请先向支持团队说明您的计划，以便我们确认不会产生冲突。

​
计算资源与扩缩容

可以。对于每个云账户/项目/订阅与区域的组合，基础设施 (包括 Kubernetes 集群) 只需预配一次，您在该区域创建的所有服务都会共享该基础设施。
支持的区域文档中列出的所有公共区域均可用于 BYOC 部署。BYOC 会跨三个可用区进行预配，因此可用区少于三个的区域以及 AWS Local Zones 均不受支持。如果您需要的区域未列出，请联系您的 ClickHouse 代表了解可用性。
除 ClickHouse 实例本身 (ClickHouse 服务器和 ClickHouse Keeper) 外，我们还会运行 clickhouse-operator、集群自动扩缩器、Istio 和监控栈等支持服务。这些共享组件的资源消耗相对稳定，不会随 ClickHouse 服务的数量或规模线性增长。作为粗略参考，运行这些工作负载的专用系统节点组总计约需 48 个 vCPU 和 192 GB 内存；例如在 AWS 上，大致相当于六个 2xlarge 实例。此外，每个仓库都会运行一个专用的三节点 ClickHouse Keeper ensemble，由该仓库中的所有服务共享。有关详细信息，请参阅成本模型。
服务级别的 (纵向) 自动扩缩容已列入路线图。目前可用的功能包括：通过控制台手动进行纵向和横向扩缩容、针对可预测负载模式的定时扩缩容、针对间歇性工作负载的自动闲置和唤醒，以及基础设施级别的自动节点组扩缩容——您无需自行管理节点。ClickHouse Keeper 由 ClickHouse 监控并进行扩缩容。
BYOC 使用一组经过筛选的节点组，而非任意实例类型。工作负载节点组 (ClickHouse 服务器和 Keeper) 默认使用基于 ARM 的内存优化型实例 (AWS 上为 Graviton) ，而系统节点组通常使用 x86 实例。可通过支持请求预配不同的实例系列、CPU 与内存配比或架构；不支持竞价实例。请参阅配置。
每个副本均以一个 pod 的形式运行在独立节点上——节点大小与副本大小相匹配，节点按需预配，且绝不会将多个副本部署到同一节点上。因此，非常小的副本效率较低：更大比例的硬件资源会用于开销，网络和磁盘带宽也会随实例大小而变化。低于控制台所提供规格的大小需通过支持提交定制请求。
可以。BYOC 支持仓库 (计算资源分离) ：多个服务共享相同的数据，因此您可以将部分服务专用于摄取，其他服务专用于查询。

​
网络与安全

在 AWS 和 GCP 上，您可以从一开始就缩减授权范围：引导制品支持参数配置，因此在使用自有 VPC 时，您可以不授予管理 VPC 网络拓扑的权限 (CloudFormation 中的 IncludeVPCWritePermissions、Terraform 模块中的 include_vpc_write_permissions) 。在 GCP 上，这仅会缩小拓扑管理的权限范围——ClickHouse 仍保留对其在 VPC 内拥有的网络资源的写入权限，例如 Private Service Connect NAT 子网、服务附件和入口地址。在 AWS 上，您还可以——目前处于私有预览阶段，需通过支持团队启用——自行管理 IAM 角色 (IncludeIAMWritePermissions=false，请参阅客户管理的 IAM 角色) ；跨账户角色则通过外部 ID 防范混淆代理访问。在 Azure 上，引导模块目前授予固定的订阅范围角色，且不提供范围限定参数。对于所有云平台，某些权限仅为特定功能所需；如果您永远不会使用这些功能，则可移除这些权限——如需将权限范围缩小至制品提供的范围以外，请联系支持团队。完成预配后，请勿单方面从管理身份中移除权限：ClickHouse 会持续协调基础设施，缺少权限会导致预配、升级和支持工作受阻。若要更改已授予的权限或完全退役，请与支持团队协调 (请参阅下方有关退役的问题) 。
权限参考概述了 AWS、GCP 和 Azure 中每个角色和身份及其用途。对于引导 (bootstrap) 身份，确切的策略范围由已发布的制品定义——CloudFormation 模板和Terraform 模块——您的安全团队可直接审核。ClickHouse 在引导后创建的其他身份 (控制器角色、服务账户和托管身份) 均在权限参考中按云服务商说明；由于它们位于您的账户中，您可以在云控制台中检查其实际策略，并在 CloudTrail 或 GCP/Azure 的对应服务中查看其创建和使用情况。在 AWS 上，管理角色的大多数写入权限都通过资源标签和名称前缀 (如 clickhouse-cloud-*) 限定范围，因此通常无法修改并非由其创建的资源 (少量 EC2 操作无法按标签限定范围) ；并且它没有对您的数据存储桶的对象级访问权限——对象访问仅限于权限范围限定为 ClickHouse 工作负载的集群内身份。在 GCP 和 Azure 上，引导身份则拥有项目或订阅范围的权限——这也是强烈建议使用专用项目或订阅的原因之一。读取权限范围更广，因为持续协调需要这些权限。
默认情况下，无法访问您的数据。为进行故障排查，工程师必须经过内部即时处理流程；访问具有时限、基于证书、仅限于 system.* 表 (不包括客户数据表) 、会被记录并由我们的安全团队审计。ClickHouse 工程师运行的任何查询都会显示在您自己的 system.query_log 中。对于基础设施诊断，同样需经审批的处理流程还可授予通过 Tailscale 访问 Kubernetes API server 和集群内监控栈的限时权限。有关数据访问模型，请参阅 ClickHouse data access；有关连接模型，请参阅网络安全。
是的。我们的路线图中计划实现一种由客户控制的机制，使客户能够批准工程师访问集群。目前，工程师必须经过内部处理流程，才能获得对集群的即时访问权限。此过程会被记录并由我们的安全团队审计。
仅有运营元数据：服务和备份状态事件、用于计费的使用指标以及告警通知。您的数据、备份、日志和监控数据均保留在您的账户中。有关完整的出站流量列表，请参阅网络安全。
默认情况下，Kubernetes API 端点为公网端点，但仅允许来自 ClickHouse NAT IP 地址的访问。使用此默认设置时，请勿移除 ClickHouse 允许列表条目，因为控制平面需要这些条目来管理集群。也可在与 ClickHouse 团队协调后，将端点切换为仅私网访问：通过 Tailscale (仅出站，也用于故障排查访问) ，或者在 AWS 上通过 VPC Lattice (私有预览) ——请参阅配置。请注意，这仅适用于 Kubernetes API：云提供商 API 调用 (例如 AWS 上的 EKS 和 EC2) 通过跨账户角色承担从 ClickHouse Cloud 网络发起，绝不能经由 Tailscale 路由——请参阅云提供商 API 与 Kubernetes API。
在 AWS 上，您的 Customer BYOC VPC 与 S3 之间的流量通过 AWS S3 API 使用 HTTPS (端口 443) 传输表数据、备份和日志。该流量经由 S3 网关 VPC 端点，因此始终位于 AWS 网络内，不经过公网，也不会产生 NAT 网关费用。在 GCP 上，访问 Google API 同样使用 Private Google Access。在 Azure 上，数据存储在您的订阅中的 Azure Blob 存储账户内。
不能。表数据 blob 采用共享布局存储，不存在按表划分的路径，因此无法将对象归属到特定表，任何直接修改都可能导致服务损坏。切勿直接修改存储桶内容；如怀疑存在问题，请提交支持工单。
客户端连接终止于负载均衡器的 TLS 端口：8443 (HTTPS 接口) 和 9440 (通过 TLS 的原生协议) ；端口 443 也会路由至 HTTPS 接口。MySQL 接口 (端口 3306) 目前未在 BYOC 中暴露，已列入路线图 (请参阅概述) 。在网络内部，集群内部通信使用端口 9000 上的原生协议、端口 8123 上的 HTTP，以及用于复制和分布式查询的端口 9009 上的服务器间通信。这些内部端口和 ClickHouse Keeper 端口绝不会暴露在任何负载均衡器上。
对于 ClickHouse 管理的 VPC，默认情况下，每个服务都配备一个受 IP 访问列表保护的公网负载均衡器；此外，还可在 ClickHouse Cloud 控制台中启用私网负载均衡器，供您的网络及其对等网络访问 (请参阅负载均衡器) 。对于客户管理的 VPC，默认设置则相反，仅启用私网负载均衡器。IP 过滤在入口代理层实施，因此负载均衡器端口在扫描中可能显示为开放，但来自未列出来源的连接会被拒绝。待不再有任何依赖项后，可完全禁用公网端点。控制台的连接方式选择器会显示服务已启用的每条连接路径对应的端点。请参阅连接性。
目前还不支持。服务端点在 clickhouse-byoc.com 域名下预配，并使用由 ClickHouse 管理的证书。
没有统一发布的端点列表。除通过私网访问云提供商 API 外，集群还需要可用的出站互联网访问 (直接访问或通过 NAT) ——请参阅网络连接要求。如果您的网络策略要求提供明确清单，请联系支持团队审核您的配置。
某些平台组件确实需要提升的权限或访问主机文件系统，例如 EBS CSI 驱动程序、节点配置作业和 Prometheus 节点 exporter (会读取 /proc 和 /sys) 。如果扫描器发现问题，请与支持团队分享——我们将确认每项发现是设计如此，还是需要采取措施。
BYOC 目前尚不支持。静态数据使用云提供商管理的密钥加密。有关当前计划功能的列表，请参阅概述。

​
升级与维护

升级方式与 ClickHouse Cloud 相同：服务会加入发布渠道 (快速、常规、慢速) ，并遵循预定的维护窗口——请联系支持团队进行配置。更新频率至少为每周一次。升级采用滚动方式，逐个副本进行 (先创建后删除) ，因此不会导致整个服务停机。请参阅操作。
ClickHouse 会在提供商终止支持日期之前主动执行 Kubernetes 升级，并通过支持团队与您协调维护窗口。控制平面升级对您无感；节点组升级会以先创建后删除的方式逐个滚动升级节点，因此 pod (容器组) 重启时，可能会出现短暂的连接重置，但不会丢失数据。请参阅操作。

​
备份和灾难恢复

备份存储在您自己的云账户中的对象存储内，绝不会离开您的环境。您可以配置备份计划和保留期限；如需调整，请联系支持团队。
所有用户创建的数据库、表和对象，以及访问实体 (用户、角色、profile、行策略、配额) 和用户自定义函数。system.query_log 等系统日志表不包含在内。
备份会形成链：一个全量备份及其后依赖该备份的增量备份。恢复该链中的任何增量备份都需要基础全量备份，因此在所有依赖它的增量备份均超出保留期之前，该全量备份都会被保留并存储。
有两种方式：使用 ClickHouse Cloud API 的备份端点，或使用集群内监控栈公开的备份指标 (启动、完成和失败计数器) 。建议在您自己的监控系统中针对失败设置告警。请参阅可观测性。
BYOC 跨三个可用区部署，且只有在对象存储确认写入后，写入操作才会得到确认。目前不支持跨区域复制，因此区域级灾难恢复依赖备份，可实现的 RPO 受备份频率限制。您可以配置备份频率和目标端以满足自身目标，包括备份到其他区域的 bucket；如需设置，请联系支持团队。

​
可观测性

监控栈 (Prometheus、Grafana、AlertManager) 在您的账户内运行，您可以通过私有连接直接使用：通过 PromQL API 查询、将其联邦到您自己的 Prometheus，或抓取每个服务的 ClickHouse /metrics_all 端点。目前尚未提供与 Datadog 等第三方平台的开箱即用集成，可通过其兼容 Prometheus 的摄取方式进行集成。有关端点和设置，请参阅可观测性。

​
成本

账单分为两部分：ClickHouse Cloud 按分配给您的服务的内存计费；云提供商则直接向您收取底层基础设施的成本，不加价。目前，详细成本参考页面涵盖 AWS：请参阅成本模型、计费 AWS 服务和 AWS 服务限制。

​
可用性和生命周期

AWS、GCP 和 Azure 均已正式发布。有关各云平台支持的功能和区域，请参阅概览。
请在 ClickHouse 控制台中终止服务和 BYOC 基础设施——不要先在云提供商控制台中删除资源或撤销权限，否则会在操作过程中中断与控制平面的连接，并导致需要手动清理。通过控制台完成终止后，请移除引导技术栈 (CloudFormation stack 或 Terraform 模块) 及所有剩余资源。在 AWS 上，所有由 ClickHouse 创建的资源均带有 clickhouse-byoc=true 标签，因此您可以随后枚举这些资源，确认没有遗漏；在 GCP 和 Azure 上，您引导的专用项目或订阅界定了需要检查的范围。

​
运行时间 SLA

不提供。由于数据平面托管在客户自己的云环境中，服务可用性取决于 ClickHouse 无法控制的资源。因此，ClickHouse 不为 BYOC 部署提供正式的运行时间 SLA。请注意，正在运行的服务独立于 ClickHouse 控制平面运行：控制平面发生故障不会导致您账户中运行的服务停止。如有其他问题，请联系 support@clickhouse.com。
最后修改于 2026年8月14日