Skip to main content

​
FAQ

​
Intégration et provisionnement

Contactez ClickHouse via le formulaire de contact afin que l’équipe active BYOC pour votre organisation. Préparez ensuite un compte cloud dédié (compte AWS, projet GCP ou abonnement Azure) et suivez le guide d’intégration standard. Nous recommandons vivement d’utiliser un compte, projet ou abonnement exclusivement réservé à BYOC.
Comptez environ 45 à 90 minutes de bout en bout. Cette fourchette est large, car la majeure partie de ce temps est consacrée au provisionnement des ressources par le fournisseur cloud (cluster Kubernetes, équilibreurs de charge, composants réseau), dont la durée varie d’une exécution à l’autre et échappe au contrôle de ClickHouse. Lorsque le provisionnement se bloque, les causes les plus fréquentes sont liées au compte :
  • Le modèle CloudFormation ou le module Terraform a été modifié avant d’être appliqué — par exemple, par l’ajout d’un PermissionsBoundary ou le renommage du rôle IAM pour respecter une convention de nommage (sur AWS, conservez le nom par défaut ClickHouseManagementRole, sauf si ClickHouse a explicitement approuvé un autre nom). Appliquez les artefacts tels qu’ils sont fournis — les personnalisations prises en charge sont disponibles sous forme de paramètres, et toute autre modification doit d’abord être approuvée par ClickHouse.
  • Des politiques au niveau de l’organisation (SCP AWS, politiques d’organisation GCP telles que iam.allowedPolicyMemberDomains, ou politiques Azure restreignant les attributions de rôles) empêchent l’assumption de rôles ou les liaisons IAM.
  • Une non-correspondance de l’ID externe du rôle d’intégration (voir la question sur l’ID externe ci-dessous).
  • Des quotas de compte atteints (par exemple, pour les Elastic IP ou les VPC sur AWS).
Le provisionnement réessaie automatiquement et se rétablit une fois le problème sous-jacent résolu. Si votre infrastructure reste bloquée pendant plus de quelques heures, contactez l’assistance.
La console ClickHouse Cloud génère un ID externe pour votre compte AWS lorsque vous démarrez l’intégration et le préremplit dans le lien CloudFormation (le paramètre ExternalID) ; si vous utilisez Terraform, transmettez la même valeur sous la forme external_id. Toutes les infrastructures BYOC d’un même compte AWS partagent le même ID externe. Ne choisissez pas votre propre valeur : elle doit correspondre à celle attendue par l’automatisation de ClickHouse, faute de quoi le rôle intercompte ne peut pas être assumé et le provisionnement échoue. Consultez ID externe AWS pour plus de détails.
Les infrastructures BYOC intégrées avant l’introduction des ID externes utilisent la valeur d’espace réservé emptyid afin d’assurer la compatibilité descendante. Lorsque vous ajoutez une nouvelle infrastructure à un compte AWS comportant un déploiement hérité, la console réutilise cet espace réservé afin que toutes les infrastructures du compte conservent une configuration de confiance cohérente. Si vous souhaitez passer à un ID externe unique, contactez ClickHouse Support.
Sur AWS et GCP, vous pouvez effectuer le déploiement dans un VPC existant appartenant au même compte ou projet que l’infrastructure BYOC. Consultez les guides de personnalisation pour AWS et GCP. Sur GCP, un VPC partagé d’un projet hôte distinct est également pris en charge : le module d’intégration accepte directement le projet hôte et le sous-réseau — consultez sa section « Shared VPC » pour connaître la configuration requise et les prérequis. La possibilité d’utiliser votre propre VNet sur Azure sera bientôt disponible.Sur AWS, les sous-réseaux partagés depuis un autre compte (AWS RAM) ne sont pas pris en charge — utilisez plutôt un compte dédié connecté à votre réseau existant via l’appairage VPC ou PrivateLink. Notez qu’avec un VPC géré par le client, seul l’équilibreur de charge privé est activé par défaut (voir configuration).
Non. Le cluster Kubernetes (EKS, GKE ou AKS) est créé et entièrement géré par ClickHouse. Cela est nécessaire pour que ClickHouse puisse exploiter la plateforme de manière fiable et la maintenir à jour.
Dans le compte cloud : c’est possible, mais les ressources colocalisées relèvent toujours, dans une certaine mesure, du périmètre d’autorisations de ClickHouse — sur AWS, la plupart des autorisations d’écriture sont limitées par tag et préfixe (les ressources provisionnées par ClickHouse portent clickhouse-byoc=true), mais un petit nombre d’actions EC2 ne peuvent pas être limitées par tag ; sur GCP et Azure, les identités d’onboarding disposent d’autorisations limitées au projet ou à l’abonnement. Séparez vos ressources de celles provisionnées par ClickHouse et privilégiez un compte, un projet ou un abonnement dédié dans chaque cloud : cela reste vivement recommandé.Dans le cluster Kubernetes : c’est possible sous certaines contraintes — utilisez vos propres groupes de nœuds avec des taints et des tolerations, n’utilisez pas les espaces de noms gérés par ClickHouse et n’installez pas de contrôleurs d’admission ni de moteurs de politiques à l’échelle du cluster, car ils peuvent bloquer la réconciliation des composants ClickHouse. Décrivez votre projet au support afin que nous puissions confirmer qu’il n’y a pas de conflits.

​
Calcul et mise à l’échelle

Oui. L’infrastructure (y compris le cluster Kubernetes) ne doit être provisionnée qu’une seule fois pour chaque combinaison compte Cloud/projet/abonnement et région. Tous les services que vous créez dans cette région la partagent.
Toutes les régions publiques répertoriées dans notre documentation sur les régions prises en charge sont disponibles pour les déploiements BYOC. BYOC est provisionné sur trois zones de disponibilité. Les régions comptant moins de trois zones ainsi que les AWS Local Zones ne sont donc pas prises en charge. Si la région dont vous avez besoin n’est pas répertoriée, contactez votre représentant ClickHouse pour discuter de sa disponibilité.
Outre les instances ClickHouse elles-mêmes (les serveurs ClickHouse et ClickHouse Keeper), nous exécutons également des services de support tels que clickhouse-operator, le cluster autoscaler, Istio et la pile de supervision.La consommation de ressources de ces composants partagés est relativement stable et n’augmente pas linéairement avec le nombre ou la taille de vos services ClickHouse. À titre indicatif, le groupe de nœuds système dédié à ces charges de travail totalise environ 48 vCPU et 192 Go de mémoire — sur AWS, par exemple, environ six instances 2xlarge. En outre, chaque entrepôt exécute un ensemble ClickHouse Keeper dédié de trois nœuds, partagé par tous les services de cet entrepôt. Consultez le modèle de coûts pour plus de détails.
L’autoscaling vertical au niveau des services est prévu dans la feuille de route. Disponibles aujourd’hui : la mise à l’échelle verticale et horizontale manuelle via la Console, la mise à l’échelle planifiée pour les charges prévisibles, la mise en veille et le réveil automatiques pour les charges de travail intermittentes, ainsi que la mise à l’échelle automatique des groupes de nœuds au niveau de l’infrastructure — vous n’avez jamais à gérer les nœuds vous-même. ClickHouse Keeper est surveillé et mis à l’échelle par ClickHouse.
BYOC s’exécute sur un ensemble sélectionné de groupes de nœuds plutôt que sur des types d’instances arbitraires. Les groupes de nœuds dédiés aux charges de travail (serveurs ClickHouse et Keeper) s’exécutent par défaut sur des instances ARM optimisées pour la mémoire (Graviton sur AWS), tandis que le groupe de nœuds système utilise généralement des instances x86. D’autres familles d’instances, ratios CPU/mémoire ou architectures peuvent être provisionnés sur demande via le support ; les instances Spot ne sont pas prises en charge. Consultez la configuration.
Chaque réplique s’exécute sous la forme d’un pod sur son propre nœud — la taille du nœud est adaptée à celle de la réplique, les nœuds sont provisionnés à la demande et plusieurs répliques ne sont jamais regroupées sur un même nœud. Les très petites répliques sont donc inefficaces : une part plus importante du matériel est consacrée à la surcharge, et la bande passante réseau et disque évolue avec la taille de l’instance. Les tailles inférieures à celles proposées dans la Console nécessitent une demande personnalisée auprès du support.
Oui. Les entrepôts (séparation du calcul) sont pris en charge dans BYOC : plusieurs services partagent les mêmes données, ce qui vous permet de dédier certains services à l’ingestion et d’autres aux requêtes.

​
Réseau et sécurité

Vous pouvez réduire les autorisations dès le départ sur AWS et GCP : les artefacts d’onboarding sont paramétrables, ce qui vous permet de ne pas accorder les autorisations de gestion de la topologie réseau de votre VPC lorsque vous utilisez votre propre VPC (IncludeVPCWritePermissions dans CloudFormation, include_vpc_write_permissions dans les modules Terraform). Sur GCP, cela limite uniquement la gestion de la topologie ; ClickHouse conserve un accès en écriture aux ressources réseau qu’il possède dans le VPC, telles que le sous-réseau NAT de Private Service Connect, l’attachement de service et les adresses d’entrée. Sur AWS, vous pouvez également — en aperçu privé, sur activation par le support — gérer vous-même les rôles IAM (IncludeIAMWritePermissions=false, voir rôles IAM gérés par le client). Les rôles intercomptes sont protégés par un ID externe contre les attaques de type « confused deputy ». Sur Azure, le module d’onboarding accorde actuellement un rôle fixe à l’échelle de l’abonnement, sans paramètres de restriction. Dans tous les clouds, certaines autorisations ne sont requises que pour des fonctionnalités spécifiques et peuvent être supprimées si vous n’utiliserez jamais ces fonctionnalités ; contactez le support si vous devez restreindre davantage les autorisations au-delà de ce que permettent les artefacts.Après le provisionnement, ne supprimez pas unilatéralement les autorisations de l’identité de gestion : ClickHouse réconcilie continuellement l’infrastructure, et l’absence d’autorisations bloque le provisionnement, les mises à niveau et le support. Pour modifier les autorisations accordées ou désactiver entièrement le service, coordonnez-vous avec le support (voir la question sur le déclassement ci-dessous).
La référence des privilèges offre une vue d’ensemble de chaque rôle et identité, ainsi que de leur fonction, sur AWS, GCP et Azure. Pour l’identité d’onboarding (bootstrap), l’ensemble exact des politiques est défini par les artefacts publiés — le modèle CloudFormation et les modules Terraform — que votre équipe de sécurité peut auditer directement. Les identités supplémentaires créées par ClickHouse après l’onboarding (rôles de contrôleur, comptes de service et identités gérées) sont décrites pour chaque fournisseur dans la référence des privilèges. Comme elles résident dans votre compte, vous pouvez inspecter leurs politiques effectives dans votre console cloud et consulter leur création et leur utilisation dans CloudTrail ou les équivalents GCP/Azure. Sur AWS, la plupart des autorisations d’écriture du rôle de gestion sont limitées par des tags de ressources et des préfixes de nom tels que clickhouse-cloud-*, de sorte qu’il ne peut généralement pas modifier les ressources qu’il n’a pas créées (un petit nombre d’actions EC2 ne peuvent pas être limitées par tag). Il ne dispose d’aucun accès aux objets de vos compartiments de données : l’accès aux objets est limité aux identités du cluster, elles-mêmes limitées aux charges de travail ClickHouse. Sur GCP et Azure, les identités d’onboarding disposent plutôt d’autorisations à l’échelle du projet ou de l’abonnement, ce qui explique notamment pourquoi un projet ou un abonnement dédié est fortement recommandé. Les autorisations de lecture sont plus étendues, car elles sont nécessaires à la réconciliation continue.
Par défaut, ils n’ont aucun accès à vos données. Pour le dépannage, les ingénieurs doivent passer par un processus interne d’escalade juste-à-temps ; l’accès est limité dans le temps, basé sur des certificats, restreint aux tables system.* (à l’exclusion des tables de données client), journalisé et audité par notre équipe de sécurité. Toute requête exécutée par un ingénieur ClickHouse est visible dans votre propre system.query_log. Pour les diagnostics d’infrastructure, cette même procédure d’escalade soumise à approbation peut également accorder un accès limité dans le temps au Kubernetes API server et à la pile de Monitoring du cluster via Tailscale. Consultez ClickHouse data access pour le modèle d’accès aux données et sécurité réseau pour le modèle de connexion.
Oui. La mise en œuvre d’un mécanisme contrôlé par le client permettant aux clients d’approuver l’accès des ingénieurs au cluster figure sur notre feuille de route. À l’heure actuelle, les ingénieurs doivent passer par notre processus interne d’escalade pour obtenir un accès juste-à-temps au cluster. Cet accès est journalisé et audité par notre équipe de sécurité.
Uniquement des métadonnées opérationnelles : événements d’état du service et des sauvegardes, métriques d’utilisation à des fins de facturation et notifications d’alerte. Vos données, sauvegardes, logs et données de Monitoring restent dans votre compte. Consultez sécurité réseau pour obtenir la liste complète des flux sortants.
Par défaut, l’endpoint de l’API Kubernetes est public, mais limité aux adresses IP NAT de ClickHouse. Tant que cette configuration par défaut est utilisée, ne supprimez pas les entrées de la liste d’autorisation ClickHouse, car le plan de contrôle en a besoin pour gérer le cluster. L’endpoint peut également être configuré pour un accès privé uniquement, en coordination avec l’équipe ClickHouse : via Tailscale (sortant uniquement, également utilisé pour l’accès de dépannage) ou, sur AWS, via VPC Lattice (aperçu privé) — consultez la configuration. Notez que cela s’applique uniquement à l’API Kubernetes : les appels aux API du fournisseur Cloud (par exemple EKS et EC2 sur AWS) proviennent du réseau de ClickHouse Cloud via l’assomption de rôle intercompte et ne peuvent jamais être acheminés via Tailscale — consultez API du fournisseur Cloud et API Kubernetes.
Sur AWS, le trafic entre votre Customer BYOC VPC et S3 utilise HTTPS (port 443) via l’API AWS S3 pour les données de tables, les sauvegardes et les journaux. Ce trafic passe par un endpoint VPC de type Gateway pour S3 : il reste donc au sein du réseau AWS, ne transite pas par Internet public et n’entraîne aucuns frais de passerelle NAT. Sur GCP, l’accès aux API Google utilise de même Private Google Access. Sur Azure, les données sont stockées dans des comptes Azure Blob Storage de votre abonnement.
Non. Les blobs de données de tables sont stockés dans une disposition partagée, sans chemins par table. Les objets ne peuvent donc pas être attribués à des tables, et toute modification directe risque de corrompre vos services. Ne modifiez jamais directement le contenu du bucket ; si vous suspectez un problème, ouvrez un ticket de support.
Les connexions client aboutissent au équilibreur de charge sur les ports TLS suivants : 8443 (interface HTTPS) et 9440 (protocole natif sur TLS) ; le port 443 achemine également vers l’interface HTTPS. L’interface MySQL (port 3306) n’est actuellement pas exposée dans BYOC — elle figure sur la feuille de route (consultez l’aperçu).Au sein du réseau, les communications internes au cluster utilisent le protocole natif sur le port 9000, HTTP sur le port 8123, ainsi que la communication interserveur sur le port 9009 pour la réplication et les requêtes distribuées. Ces ports internes et les ports ClickHouse Keeper ne sont jamais exposés par un équilibreur de charge.
Avec un VPC géré par ClickHouse, chaque service dispose par défaut d’un équilibreur de charge public protégé par une liste d’accès IP ; un équilibreur de charge privé, accessible depuis votre réseau et les réseaux appairés, peut également être activé dans la ClickHouse Cloud console (consultez Load Balancers). Avec un VPC géré par le client, les paramètres par défaut sont inversés et seul l’équilibreur de charge privé est activé. Le filtrage IP est appliqué au niveau du proxy d’entrée ; les ports de l’équilibreur de charge peuvent donc sembler ouverts lors d’analyses, mais les connexions provenant de sources non répertoriées sont rejetées. L’endpoint public peut être entièrement désactivé dès lors que plus rien n’en dépend. Le sélecteur de connexion de la console affiche les endpoints associés à chaque chemin de connexion activé pour votre service. Consultez la connectivité.
Pas encore. Les endpoints de service sont provisionnés sous clickhouse-byoc.com avec des certificats gérés par ClickHouse.
Il n’existe pas de liste unique d’endpoints publiée. Le cluster nécessite un accès Internet sortant fonctionnel (directement ou via NAT), ainsi qu’un accès privé aux API du fournisseur Cloud ; consultez les exigences de connectivité réseau. Si votre politique réseau exige un inventaire explicite, contactez l’assistance afin d’examiner votre configuration.
Certains composants de la plateforme nécessitent légitimement des privilèges élevés ou un accès au système de fichiers hôte, notamment le pilote EBS CSI, les tâches de configuration des nœuds et l’exporter de nœud Prometheus (qui lit /proc et /sys). Si votre scanner signale des problèmes, transmettez-les à l’assistance : nous confirmerons si chacun est prévu ou nécessite une action.
Pas actuellement pour BYOC. Les données au repos sont chiffrées à l’aide de clés gérées par le fournisseur Cloud. Consultez la vue d’ensemble pour obtenir la liste actuelle des fonctionnalités prévues.

​
Mises à niveau et maintenance

Les mises à niveau fonctionnent de la même manière que dans ClickHouse Cloud : les services sont inscrits à des canaux de publication (rapide, régulier, lent) et respectent les fenêtres de maintenance planifiées. Contactez le support pour les configurer. Prévoyez au minimum une mise à jour par semaine. Les mises à niveau sont effectuées de manière progressive, réplique par réplique (make before break), de sorte que l’ensemble du service ne connaît aucune indisponibilité. Consultez les opérations.
ClickHouse prend en charge et effectue les mises à niveau de Kubernetes de manière proactive, avant les dates de fin de support du fournisseur, et coordonne la fenêtre avec vous via le support. Les mises à niveau du plan de contrôle sont transparentes ; les mises à niveau des groupes de nœuds s’effectuent nœud par nœud selon une stratégie make before break. Vous pourrez donc observer de brèves réinitialisations de connexion lors du redémarrage des pods, mais aucune perte de données. Consultez les opérations.

​
Sauvegardes et reprise après sinistre

Dans le stockage d’objets de votre propre compte cloud : les sauvegardes ne quittent jamais votre environnement. La planification et la rétention des sauvegardes sont configurables ; contactez le support pour les modifier.
Toutes les bases de données, tables et objets créés par les utilisateurs, ainsi que les entités d’accès (utilisateurs, rôles, profils de paramètres, politiques de lignes, quotas) et les fonctions définies par l’utilisateur. Les tables de journaux système telles que system.query_log ne sont pas incluses.
Les sauvegardes forment des chaînes : une sauvegarde complète suivie de sauvegardes incrémentielles qui en dépendent. La sauvegarde complète de base est nécessaire pour restaurer toute sauvegarde incrémentielle de sa chaîne ; elle est donc conservée (et stockée) jusqu’à ce que chaque sauvegarde incrémentielle dépendante ait dépassé sa période de rétention.
Deux options : les endpoints de sauvegarde de l’API ClickHouse Cloud et les métriques de sauvegarde (compteurs de démarrage, de fin et d’échec) exposées par la pile de monitoring du cluster. Nous vous recommandons de configurer des alertes sur les échecs dans votre propre système de monitoring. Consultez l’observabilité.
BYOC est déployé sur trois zones de disponibilité et les écritures ne sont confirmées qu’une fois validées par le stockage d’objets. La réplication inter-régions n’est pas disponible actuellement ; la reprise après sinistre à l’échelle régionale repose donc sur les sauvegardes, et le RPO atteignable est limité par leur fréquence. La fréquence et la destination des sauvegardes peuvent être configurées pour répondre à vos objectifs, notamment en effectuant les sauvegardes dans un bucket situé dans une autre région : contactez le support pour mettre cela en place.

​
Observabilité

La stack de monitoring (Prometheus, Grafana, AlertManager) s’exécute dans votre compte et vous pouvez l’utiliser directement via une connectivité privée : interrogez-la via l’API PromQL, fédérez-la dans votre propre instance Prometheus ou récupérez les métriques de l’endpoint ClickHouse /metrics_all pour chaque service. Il n’existe actuellement aucune intégration clé en main avec des plateformes tierces telles que Datadog ; utilisez leur ingestion compatible Prometheus. Consultez l’observabilité pour connaître les endpoints et la configuration.

​
Coût

Deux factures distinctes : ClickHouse Cloud facture la mémoire allouée à vos services, tandis que votre fournisseur cloud vous facture directement l’infrastructure sous-jacente au prix coûtant, sans majoration. Les pages de référence détaillées sur les coûts couvrent actuellement AWS : consultez le modèle de coûts, les services AWS facturables et les limites de service AWS.

​
Disponibilité et cycle de vie

AWS, GCP et Azure sont tous disponibles en disponibilité générale. Consultez la vue d’ensemble pour connaître les fonctionnalités et les régions prises en charge sur chaque cloud.
Résiliez vos services et l’infrastructure BYOC depuis la console ClickHouse — ne commencez pas par supprimer des ressources ou révoquer des autorisations dans la console de votre fournisseur cloud, car cela interrompt la connexion au plan de contrôle en cours d’opération et impose un nettoyage manuel. Une fois la résiliation depuis la console terminée, supprimez la pile d’onboarding (pile CloudFormation ou module Terraform) ainsi que les ressources restantes. Sur AWS, toutes les ressources créées par ClickHouse portent le tag clickhouse-byoc=true, ce qui vous permet de les répertorier ensuite afin de vérifier qu’il ne reste rien ; sur GCP et Azure, le projet ou l’abonnement dédié utilisé lors de l’onboarding délimite les éléments à examiner.

​
SLA de disponibilité

Non. Comme le plan de données est hébergé dans l’environnement cloud du client, la disponibilité du service dépend de ressources qui ne sont pas sous le contrôle de ClickHouse. Par conséquent, ClickHouse n’offre pas de SLA de disponibilité formel pour les déploiements BYOC. Notez que les services en cours d’exécution fonctionnent indépendamment du plan de contrôle ClickHouse : une panne du plan de contrôle n’interrompt pas les services exécutés dans votre compte. Si vous avez d’autres questions, veuillez contacter le support à l’adresse support@clickhouse.com.
Dernière modification le 14 août 2026