Skip to main content

​
FAQ

​
Incorporación y aprovisionamiento

Póngase en contacto con ClickHouse mediante el formulario de contacto y el equipo habilitará BYOC para su organización. A continuación, prepare una cuenta en la nube dedicada (una cuenta de AWS, un proyecto de GCP o una suscripción de Azure) y siga la guía de incorporación estándar. Recomendamos encarecidamente usar una cuenta, un proyecto o una suscripción dedicados exclusivamente a BYOC.
Calcule entre 45 y 90 minutos de principio a fin. El intervalo es amplio porque la mayor parte de ese tiempo corresponde al aprovisionamiento de recursos por parte del proveedor de nube —el clúster de Kubernetes, los balanceadores de carga y los componentes de red—, cuya duración varía de una ejecución a otra y está fuera del control de ClickHouse. Cuando el aprovisionamiento se bloquea, las causas más frecuentes se deben a la cuenta:
  • La plantilla de CloudFormation o el módulo de Terraform se modificó antes de aplicarse; por ejemplo, al añadir un PermissionsBoundary o renombrar el rol de IAM para cumplir una convención de nomenclatura (en AWS, mantenga el nombre predeterminado ClickHouseManagementRole, a menos que ClickHouse haya aprobado explícitamente otro). Aplique los artefactos tal como se proporcionan: las personalizaciones compatibles se exponen como parámetros y cualquier otro cambio requiere la aprobación previa de ClickHouse.
  • Políticas a nivel de organización (SCP de AWS, políticas de organización de GCP como iam.allowedPolicyMemberDomains o políticas de Azure que restringen las asignaciones de roles) que bloquean la asunción de roles o las vinculaciones de IAM.
  • Una discrepancia en el ID externo del rol de incorporación (consulte la pregunta sobre el ID externo más abajo).
  • Límites de cuota de la cuenta (por ejemplo, IP elásticas o VPC en AWS).
El aprovisionamiento se reintenta automáticamente y se recupera una vez corregido el problema subyacente. Si su infraestructura permanece bloqueada durante más de un par de horas, contacte con soporte.
La consola de ClickHouse Cloud genera un ID externo para su cuenta de AWS al iniciar la incorporación y lo rellena previamente en el enlace de CloudFormation (el parámetro ExternalID); si usa Terraform, pase el mismo valor como external_id. Todas las infraestructuras BYOC de la misma cuenta de AWS comparten el mismo ID externo. No elija un valor propio: debe coincidir con el que espera la automatización de ClickHouse; de lo contrario, no se podrá asumir el rol entre cuentas y el aprovisionamiento fallará. Consulte ID externo de AWS para obtener más información.
Las infraestructuras BYOC incorporadas antes de que se introdujeran los ID externos usan el valor de marcador de posición emptyid para mantener la compatibilidad con versiones anteriores. Cuando añade infraestructura nueva a una cuenta de AWS con una implementación heredada existente, la consola reutiliza este marcador de posición para que todas las infraestructuras de la cuenta mantengan una configuración de confianza coherente. Si desea cambiar a un ID externo único, contacte con soporte de ClickHouse.
En AWS y GCP, puede desplegar una VPC existente que se encuentre en la misma cuenta o proyecto que la infraestructura BYOC. Consulte las guías de personalización para AWS y GCP. En GCP, también se admite una VPC compartida de un proyecto host independiente: el módulo de incorporación acepta directamente el proyecto host y la subred; consulte su sección “Shared VPC” para conocer la configuración y los requisitos previos. Próximamente podrá usar su propia VNet en Azure.En AWS, las subredes compartidas desde otra cuenta mediante AWS RAM no son compatibles; en su lugar, use una cuenta dedicada conectada a su red existente mediante peering de VPC o PrivateLink. Tenga en cuenta que, con una VPC gestionada por el cliente, solo se habilita de forma predeterminada el balanceador de carga privado (consulte la configuración).
No. ClickHouse crea y gestiona por completo el clúster de Kubernetes (EKS, GKE o AKS). Esto es necesario para que ClickHouse pueda operar la plataforma de forma fiable y mantenerla actualizada.
En la cuenta en la nube: es posible, pero los recursos ubicados en el mismo entorno siempre quedan, en cierta medida, dentro del ámbito de permisos de ClickHouse. En AWS, la mayoría de los permisos de escritura están restringidos por etiquetas y prefijos (los recursos aprovisionados por ClickHouse llevan clickhouse-byoc=true), pero un pequeño conjunto de acciones de EC2 no puede restringirse por etiquetas. En GCP y Azure, las identidades de incorporación tienen permisos con alcance de proyecto o suscripción. Mantenga sus recursos alejados de los aprovisionados por ClickHouse y, en cada nube, utilice preferiblemente una cuenta, un proyecto o una suscripción dedicados; esta sigue siendo la recomendación principal.En el clúster de Kubernetes: es posible, con restricciones. Use sus propios grupos de nodos con taints y tolerations, evite los espacios de nombres administrados por ClickHouse y no instale controladores de admisión ni motores de políticas para todo el clúster, ya que pueden bloquear la reconciliación de los componentes de ClickHouse. Describa primero su plan al equipo de soporte para que podamos confirmar que no haya conflictos.

​
Cómputo y escalado

Sí. La infraestructura (incluido el clúster de Kubernetes) solo debe aprovisionarse una vez por cada combinación de cuenta/proyecto/suscripción de Cloud y región, y todos los servicios que cree en esa región la comparten.
Todas las regiones públicas incluidas en nuestra documentación de regiones compatibles están disponibles para implementaciones BYOC. BYOC se aprovisiona en tres zonas de disponibilidad, por lo que no se admiten las regiones con menos de tres zonas ni las AWS Local Zones. Si la región que necesita no aparece en la lista, póngase en contacto con su representante de ClickHouse para consultar su disponibilidad.
Además de las propias instancias de ClickHouse (servidores de ClickHouse y ClickHouse Keeper), también ejecutamos servicios auxiliares como clickhouse-operator, el cluster autoscaler, Istio y la pila de monitorización.El consumo de recursos de estos componentes compartidos es relativamente estable y no aumenta linealmente con el número ni el tamaño de sus servicios de ClickHouse. Como orientación general, el grupo de nodos del sistema dedicado a estas cargas de trabajo suma aproximadamente 48 vCPU y 192 GB de memoria; en AWS, por ejemplo, equivale a unas seis instancias 2xlarge. Además, cada warehouse ejecuta un ensemble de Keeper dedicado de tres nodos, compartido por todos los servicios de ese warehouse. Consulte el modelo de costes para obtener más información.
El autoescalado vertical a nivel de servicio está en la hoja de ruta. Actualmente están disponibles el escalado vertical y horizontal manual mediante la consola, el escalado programado para patrones de carga previsibles, la inactividad y reactivación automáticas para cargas de trabajo intermitentes, y el escalado automático de los grupos de nodos a nivel de infraestructura; nunca tendrá que gestionar los nodos usted mismo. ClickHouse supervisa y escala ClickHouse Keeper.
BYOC se ejecuta en un conjunto seleccionado de grupos de nodos, en lugar de en tipos de instancia arbitrarios. Los grupos de nodos de carga de trabajo (servidores de ClickHouse y Keeper) se ejecutan de forma predeterminada en instancias basadas en ARM y optimizadas para memoria (Graviton en AWS), mientras que el grupo de nodos del sistema suele utilizar instancias x86. Se pueden aprovisionar otras familias de instancias, proporciones de CPU a memoria o arquitecturas previa solicitud a través de soporte; las instancias spot no son compatibles. Consulte la configuración.
Cada réplica se ejecuta como un pod en su propio nodo; el tamaño del nodo se ajusta al de la réplica, los nodos se aprovisionan bajo demanda y nunca se colocan varias réplicas en un mismo nodo. Por tanto, las réplicas muy pequeñas son ineficientes: una mayor proporción del hardware se destina a sobrecarga y el ancho de banda de red y disco escala con el tamaño de la instancia. Los tamaños inferiores a los que ofrece la consola requieren solicitudes personalizadas a través de soporte.
Sí. Los warehouses (separación de cómputo-cómputo) son compatibles con BYOC: varios servicios comparten los mismos datos, por lo que puede dedicar unos servicios a la ingestión y otros a las consultas.

​
Red y seguridad

Puede reducir los permisos desde el principio en AWS y GCP: los artefactos de incorporación están parametrizados, por lo que puede omitir permisos para administrar la topología de red de su VPC al usar su propia VPC (IncludeVPCWritePermissions en CloudFormation, include_vpc_write_permissions en los módulos de Terraform). En GCP, esto limita únicamente la administración de la topología; ClickHouse conserva acceso de escritura a los recursos de red de su propiedad dentro de la VPC, como la subred NAT de Private Service Connect, el adjunto de servicio y las direcciones de entrada. En AWS, además, en vista previa privada y previa habilitación por parte de soporte, puede administrar usted mismo los roles de IAM (IncludeIAMWritePermissions=false, consulte roles de IAM gestionados por el cliente); los roles entre cuentas están protegidos mediante un ID externo contra ataques de suplante de identidad. En Azure, el módulo de incorporación concede actualmente un rol fijo con ámbito de suscripción, sin parámetros para limitar su alcance. En todos los proveedores de nube, algunos permisos solo son necesarios para funciones específicas y pueden eliminarse si nunca va a utilizar esas funciones; contacte con soporte si necesita limitar los permisos más allá de lo que permiten los artefactos.Después del aprovisionamiento, no elimine unilateralmente los permisos de la identidad de administración: ClickHouse reconcilia continuamente la infraestructura, y la falta de permisos interrumpe el aprovisionamiento, las actualizaciones y el soporte. Para modificar los permisos concedidos o retirar el servicio por completo, coordínese con soporte (consulte la pregunta sobre desmantelamiento más adelante).
La referencia de privilegios ofrece una descripción general de cada rol e identidad y de su propósito en AWS, GCP y Azure. Para la identidad de incorporación (bootstrap), el alcance exacto de las políticas se define en los artefactos publicados: la plantilla de CloudFormation y los módulos de Terraform, que su equipo de seguridad puede auditar directamente. Las identidades adicionales que ClickHouse crea después de la incorporación (roles de controlador, cuentas de servicio e identidades administradas) se describen para cada proveedor en la referencia de privilegios y, como residen en su cuenta, puede inspeccionar sus políticas reales en la consola de su proveedor de nube y consultar su creación y uso en CloudTrail o sus equivalentes de GCP/Azure. En AWS, la mayoría de los permisos de escritura del rol de administración están restringidos mediante etiquetas de recursos y prefijos de nombre como clickhouse-cloud-*, por lo que, por lo general, no puede modificar recursos que no haya creado (un pequeño número de acciones de EC2 no puede restringirse mediante etiquetas), y no tiene acceso a nivel de objeto a sus buckets de datos: el acceso a objetos se limita a identidades dentro del clúster restringidas a las cargas de trabajo de ClickHouse. En GCP y Azure, las identidades de incorporación tienen permisos con ámbito de proyecto o suscripción; este es uno de los motivos por los que se recomienda encarecidamente utilizar un proyecto o una suscripción dedicados. Los permisos de lectura son más amplios porque se requieren para la reconciliación continua.
De forma predeterminada, no tienen acceso a sus datos. Para solucionar problemas, los ingenieros deben pasar por un proceso interno de escalación just-in-time; el acceso tiene una duración limitada, se basa en certificados, está restringido a las tablas system.* (sin tablas con datos de clientes), se registra y es auditado por nuestro equipo de seguridad. Cualquier consulta ejecutada por un ingeniero de ClickHouse es visible para usted en su propio system.query_log. Para diagnósticos de infraestructura, la misma escalación sujeta a aprobación también puede conceder acceso temporal al servidor de API de Kubernetes y a la pila de monitorización dentro del clúster mediante Tailscale. Consulte acceso a datos de ClickHouse para conocer el modelo de acceso a datos y seguridad de red para conocer el modelo de conexión.
Sí. Tenemos en nuestra hoja de ruta implementar un mecanismo controlado por el cliente que permita a los clientes aprobar el acceso de los ingenieros al clúster. Actualmente, los ingenieros deben pasar por nuestro proceso interno de escalación para obtener acceso just-in-time al clúster. Este acceso se registra y es auditado por nuestro equipo de seguridad.
Solo metadatos operativos: eventos sobre el estado del servicio y las copias de seguridad, métricas de uso para facturación y notificaciones de alertas. Sus datos, copias de seguridad, logs y datos de Monitoring permanecen en su cuenta. Consulte seguridad de red para obtener la lista completa de flujos salientes.
De forma predeterminada, el endpoint de la API de Kubernetes es público, pero está restringido a las direcciones IP NAT de ClickHouse. Mientras se utilice esta configuración predeterminada, no elimine las entradas de la lista de permitidos de ClickHouse, ya que el plano de control las necesita para administrar el clúster. Como alternativa, el endpoint puede configurarse para acceso exclusivamente privado, en coordinación con el equipo de ClickHouse: mediante Tailscale (solo saliente, también utilizado para el acceso de resolución de problemas) o, en AWS, mediante VPC Lattice (vista previa privada). Consulte la configuración. Tenga en cuenta que esto se aplica únicamente a la API de Kubernetes: las llamadas a las API del proveedor de nube (por ejemplo, EKS y EC2 en AWS) se originan en la red de ClickHouse Cloud mediante la asunción de roles entre cuentas y nunca pueden enrutarse a través de Tailscale. Consulte las API del proveedor de nube frente a la API de Kubernetes.
En AWS, el tráfico entre su VPC BYOC del cliente y S3 utiliza HTTPS (puerto 443) a través de la API de S3 de AWS para los datos de las tablas, las copias de seguridad y los registros. Este tráfico pasa por un endpoint de gateway de VPC para S3, por lo que permanece dentro de la red de AWS, no atraviesa la internet pública y no genera cargos de gateway NAT. En GCP, el acceso a las API de Google utiliza de forma similar Private Google Access. En Azure, los datos se almacenan en cuentas de Azure Blob Storage dentro de su suscripción.
No. Los blobs de datos de las tablas se almacenan en una estructura compartida sin rutas por tabla, por lo que no es posible atribuir los objetos a tablas y cualquier modificación directa puede corromper sus servicios. Nunca modifique directamente el contenido del bucket; si sospecha que hay algún problema, abra un ticket de soporte.
Las conexiones del client terminan en el balanceador de carga en puertos TLS: 8443 (interfaz HTTPS) y 9440 (protocolo nativo sobre TLS); el puerto 443 también se enruta a la interfaz HTTPS. La interfaz MySQL (puerto 3306) no está expuesta actualmente en BYOC; está prevista en la hoja de ruta (consulte la descripción general).Dentro de la red, la comunicación interna del clúster utiliza el protocolo nativo en el puerto 9000, HTTP en el puerto 8123 y comunicación entre servidores en el puerto 9009 para la replicación y las consultas distribuidas. Estos puertos internos y los puertos de ClickHouse Keeper nunca se exponen en ningún balanceador de carga.
Con una VPC gestionada por ClickHouse, cada servicio dispone de forma predeterminada de un balanceador de carga público protegido por una lista de acceso de IP; además, puede habilitarse en la consola de ClickHouse Cloud un balanceador de carga privado, accesible desde su red y redes emparejadas (consulte Balanceadores de carga). Con una VPC gestionada por el cliente, los valores predeterminados se invierten y solo se habilita el balanceador de carga privado. El filtrado de IP se aplica en la capa del proxy de entrada, por lo que los puertos del balanceador de carga pueden parecer abiertos en los análisis, aunque se rechazan las conexiones procedentes de orígenes que no figuran en la lista. El endpoint público puede deshabilitarse por completo cuando ya no dependa de él ningún componente. El selector de conexión de la consola muestra los endpoints de cada ruta de conexión habilitada para su servicio. Consulte la conectividad.
No por el momento. Los endpoints de servicio se aprovisionan bajo clickhouse-byoc.com con certificados gestionados por ClickHouse.
No existe una única lista publicada de endpoints. El clúster requiere acceso saliente a Internet funcional (directamente o mediante NAT), además de acceso privado a las API del proveedor de nube; consulte los requisitos de conectividad de red. Si su política de red requiere un inventario explícito, contacte con soporte para revisar su configuración.
Algunos componentes de la plataforma requieren legítimamente privilegios elevados o acceso al filesystem del host, como el controlador CSI de EBS, los trabajos de configuración de nodos y el exporter de nodos de Prometheus (que lee /proc y /sys). Si su escáner detecta incidencias, compártalas con soporte; confirmaremos si cada una es intencionada o requiere medidas.
Actualmente, no para BYOC. Los datos en reposo se cifran con claves gestionadas por el proveedor de nube. Consulte la descripción general para ver la lista actual de funcionalidades planificadas.

​
Actualizaciones y mantenimiento

Las actualizaciones funcionan igual que en ClickHouse Cloud: los servicios se adhieren a canales de lanzamiento (rápido, regular o lento) y respetan las ventanas de mantenimiento programadas; contacte con soporte para configurarlas. Espere una programación de actualizaciones de al menos una vez por semana. Las actualizaciones se realizan de forma gradual, réplica por réplica (make-before-break), por lo que no hay tiempo de inactividad de todo el servicio. Consulte operations.
ClickHouse se encarga de realizar proactivamente las actualizaciones de Kubernetes, antes de las fechas de finalización del soporte del proveedor, y coordina la ventana con usted a través de soporte. Las actualizaciones del plano de control son transparentes; las de los grupos de nodos se realizan nodo por nodo con semántica make-before-break, por lo que puede experimentar breves restablecimientos de conexión mientras se reinician los pods, pero sin pérdida de datos. Consulte operations.

​
Copias de seguridad y recuperación ante desastres

En el almacenamiento de objetos de su propia cuenta en la nube; las copias de seguridad nunca salen de su entorno. La programación y la retención de las copias de seguridad se pueden configurar; póngase en contacto con el soporte técnico para ajustarlas.
Todas las bases de datos, tablas y objetos creados por el usuario, además de las entidades de acceso (usuarios, roles, perfiles de configuración, políticas de fila, cuotas) y las funciones definidas por el usuario. Las tablas de registro del sistema, como system.query_log, no se incluyen.
Las copias de seguridad forman cadenas: una copia de seguridad completa seguida de copias incrementales que dependen de ella. La copia de seguridad completa base es necesaria para restaurar cualquier copia incremental de su cadena, por lo que se conserva (y almacena) hasta que todas las copias incrementales dependientes hayan superado el período de retención.
Hay dos opciones: los endpoints de copias de seguridad de la ClickHouse Cloud API y las métricas de copias de seguridad (contadores de inicio, finalización y errores) expuestas por la pila de monitorización del clúster. Recomendamos configurar alertas para los errores en su propia monitorización. Consulte observabilidad.
BYOC se despliega en tres zonas de disponibilidad, y las escrituras solo se confirman cuando el almacenamiento de objetos las confirma. La replicación entre regiones no está disponible actualmente, por lo que la recuperación ante desastres regional se basa en copias de seguridad y el RPO alcanzable está limitado por la frecuencia de las copias de seguridad. La frecuencia y el destino de las copias de seguridad se pueden configurar para ajustarse a sus objetivos, incluido realizar copias de seguridad en un bucket de otra región; póngase en contacto con el soporte técnico para configurarlo.

​
Observabilidad

La pila de monitorización (Prometheus, Grafana, AlertManager) se ejecuta dentro de su cuenta y puede utilizarla directamente mediante conectividad privada: consultarla a través de la API PromQL, federarla en su propio Prometheus o recopilar métricas del endpoint /metrics_all de ClickHouse para cada servicio. Actualmente no existe una integración lista para usar con plataformas de terceros como Datadog; intégrela mediante su ingestión compatible con Prometheus. Consulte observabilidad para conocer los endpoints y la configuración.

​
Coste

Dos facturas independientes: ClickHouse Cloud cobra en función de la memoria asignada a tus servicios, y tu proveedor de nube te factura directamente el coste de la infraestructura subyacente, sin recargo. Actualmente, las páginas de referencia detallada sobre costes cubren AWS: consulta el modelo de costes, los servicios facturables de AWS y los límites de servicio de AWS.

​
Disponibilidad y ciclo de vida

AWS, GCP y Azure están disponibles de forma general. Consulte la descripción general para conocer las funcionalidades y regiones compatibles en cada nube.
Finalice sus servicios y la infraestructura BYOC desde la consola de ClickHouse; no empiece por eliminar recursos ni revocar permisos en la consola de su proveedor de nube, ya que esto interrumpe la conexión con el plano de control durante el proceso y obliga a realizar una limpieza manual. Una vez completada la finalización desde la consola, elimine la pila de incorporación (pila de CloudFormation o módulo de Terraform) y los recursos restantes. En AWS, todos los recursos creados por ClickHouse están etiquetados con clickhouse-byoc=true, por lo que puede enumerarlos posteriormente para verificar que no quede nada; en GCP y Azure, el proyecto o la suscripción dedicados que incorporó delimitan lo que debe revisar.

​
SLA de disponibilidad

No, dado que el plano de datos está alojado en el entorno de nube del cliente, la disponibilidad del servicio depende de recursos que no están bajo el control de ClickHouse. Por lo tanto, ClickHouse no ofrece un SLA formal de disponibilidad para las implementaciones de BYOC. Tenga en cuenta que los servicios en ejecución operan de forma independiente del plano de control de ClickHouse: una interrupción del plano de control no detiene los servicios que se ejecutan en su cuenta. Si tiene alguna pregunta adicional, póngase en contacto con support@clickhouse.com.
Última modificación el 14 de agosto de 2026