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

# Configurer une instance W&B Weave autogérée

> Déployez et gérez Weave sur votre propre infrastructure

Auto-héberger W\&B Weave vous permet de mieux contrôler son environnement et sa configuration. Vous pouvez ainsi créer un environnement plus isolé et satisfaire à des exigences de conformité supplémentaires en matière de sécurité.

Ce document explique comment déployer les composants nécessaires à l’exécution de W\&B Weave dans un déploiement [W\&B autogéré](/fr/products/wandb/platform/hosting/hosting-options/self-managed) à l’aide de l’Altinity ClickHouse Operator. Au terme de ce guide, vous disposerez d’une instance Weave prête pour la production, exécutée sur votre propre cluster Kubernetes et adossée à une base de données ClickHouse répliquée ainsi qu’à un stockage d’objets compatible S3. Ce guide s’adresse aux administrateurs Kubernetes et aux ingénieurs de plateforme chargés du déploiement et de l’exploitation de W\&B au sein de leur organisation.

Les déploiements Weave autogérés s’appuient sur [ClickHouseDB](https://clickhouse.com/) pour leur backend. Ce déploiement utilise :

* **Altinity ClickHouse Operator** : gestion de ClickHouse de niveau entreprise pour Kubernetes.
* **ClickHouse Keeper** : service de coordination distribué (remplace ZooKeeper).
* **Cluster ClickHouse** : cluster de base de données à haute disponibilité pour le stockage des traces.
* **Stockage compatible S3** : stockage d’objets assurant la persistance des données ClickHouse.

<Tip>
  Pour une architecture de référence détaillée, voir [Architecture de référence W\&B autogéré](/fr/products/wandb/platform/hosting/self-managed/ref-arch#models-and-weave).
</Tip>

<h2 id="important-setup-notes">
  Remarques importantes sur la configuration
</h2>

Les exemples de configuration de ce guide sont fournis à titre de référence uniquement. L’environnement Kubernetes de chaque organisation étant unique, vous devrez probablement ajuster les éléments suivants pour votre instance auto-hébergée :

* **Sécurité et conformité** : les contextes de sécurité, les valeurs `runAsUser` ou `fsGroup` et les autres paramètres de sécurité, conformément aux politiques de sécurité de votre organisation et aux exigences de Kubernetes ou d’OpenShift.
* **Dimensionnement des ressources** : les allocations de ressources indiquées ne sont que des points de départ. Consultez votre équipe Solutions Architect W\&B pour obtenir un dimensionnement adapté au volume de traces attendu et à vos exigences de performances.
* **Spécificités de l’infrastructure** : adaptez les classes de stockage, les sélecteurs de nœuds et les autres paramètres propres à l’infrastructure à votre environnement.

Considérez ces configurations comme des modèles, et non comme des solutions clés en main.

<h2 id="architecture">
  Architecture
</h2>

Le diagramme suivant montre comment la plateforme W\&B, le cluster ClickHouse, le service de coordination ClickHouse Keeper et le stockage S3 s’articulent dans un déploiement autogéré de Weave.

```mermaid theme={"system"}
graph TD
    A["Plateforme W&B (wandb)<br/>weave-trace · app/API · console/parquet"] --> B["Cluster ClickHouse"]
    B --> C["ch-server-0"]
    B --> D["ch-server-1"]
    B --> E["ch-server-2"]
    C --> F["Cluster ClickHouse Keeper<br/>keeper-0 <br/>keeper-1 <br/>keeper-2"]
    D --> F
    E --> F
    C --> G["Stockage S3<br/>(AWS/MinIO)"]
    D --> G
    E --> G
```

<h2 id="prerequisites">
  Prérequis
</h2>

Avant de commencer, assurez-vous que votre environnement répond aux exigences suivantes. Les instances Weave autogérées nécessitent les ressources suivantes :

* **Cluster Kubernetes** : version 1.29 ou ultérieure.
* **Nœuds Kubernetes** : cluster multi-nœuds (au moins 3 nœuds recommandés pour la haute disponibilité).
* **Classe de stockage** : une StorageClass fonctionnelle pour les volumes persistants (par exemple, `gp3`, `standard` ou `nfs-csi`).
* **Bucket S3** : bucket S3 ou compatible S3 préconfiguré, avec les autorisations d'accès appropriées.
* **plateforme W\&B** : déjà installée et en cours d'exécution. Voir le [guide de déploiement de W\&B autogéré](/fr/products/wandb/platform/hosting/hosting-options/self-managed).
* **Licence W\&B** : licence incluant Weave, fournie par l'assistance W\&B.

<Warning>
  Ne vous fiez pas uniquement à cette liste de prérequis pour dimensionner votre déploiement. Les besoins en ressources varient selon le volume de traces et les modes d'utilisation. Pour plus d'informations, voir [Exigences en ressources](#resource-requirements).
</Warning>

<h3 id="required-tools">
  Outils requis
</h3>

Pour configurer votre instance, vous avez besoin des outils suivants :

* `kubectl` configuré avec un accès au cluster.
* `helm` en version 3.0 ou ultérieure.
* Des identifiants d’authentification AWS (si vous utilisez S3) ou un accès à un stockage compatible S3.

<h3 id="network-requirements">
  Exigences réseau
</h3>

Votre cluster Kubernetes nécessite la configuration réseau suivante :

* Les pods du namespace `clickhouse` doivent pouvoir communiquer avec les pods du namespace `wandb`.
* Les nœuds ClickHouse doivent pouvoir communiquer entre eux sur les ports `8123`, `9000`, `9009` et `2181`.

<h2 id="deploy-your-self-managed-weave-instance">
  Déployer votre instance Weave autogérée
</h2>

Les étapes suivantes vous guident dans le déploiement de l’opérateur, la préparation du stockage, le déploiement de ClickHouse Keeper et du cluster ClickHouse, puis l’activation de Weave dans la plateforme W\&B. Suivez ces étapes dans l’ordre, car chacune s’appuie sur les ressources créées lors de l’étape précédente.

<h3 id="deploy-the-altinity-clickhouse-operator">
  Déployer l’Altinity ClickHouse Operator
</h3>

L’Altinity ClickHouse Operator gère les installations ClickHouse dans Kubernetes. Installer l’opérateur en premier permet, lors des étapes suivantes, de déclarer des ressources ClickHouse Keeper et de cluster ClickHouse que l’opérateur réconcilie pour vous.

<h4 id="add-the-altinity-helm-repository">
  Ajouter le dépôt Helm Altinity
</h4>

```bash theme={"system"}
helm repo add altinity https://helm.altinity.com
helm repo update
```

<h4 id="create-the-operator-configuration">
  Créer la configuration de l’opérateur
</h4>

Créez un fichier nommé `ch-operator.yaml`. Ce fichier définit le contexte de sécurité et les métadonnées du déploiement de l’opérateur :

```yaml theme={"system"}
operator:
  image:
    repository: altinity/clickhouse-operator

  # Contexte de sécurité - à ajuster selon les exigences de votre cluster
  containerSecurityContext:
    runAsGroup: 0
    runAsNonRoot: true
    runAsUser: 10001 # À adapter selon vos politiques de sécurité OpenShift/Kubernetes
    allowPrivilegeEscalation: false
    capabilities:
      drop:
        - ALL
    privileged: false
    readOnlyRootFilesystem: false

metrics:
  enabled: false

# Redéfinition du nom - à personnaliser si nécessaire
nameOverride: "wandb"
```

Les valeurs `containerSecurityContext` présentées ici conviennent à la plupart des distributions Kubernetes. Pour OpenShift, vous devrez peut-être ajuster `runAsUser` et `fsGroup` en fonction de la plage d'UID attribuée à votre projet.

<h4 id="install-the-operator">
  Installer l’opérateur
</h4>

```bash theme={"system"}
helm upgrade --install ch-operator altinity/altinity-clickhouse-operator \
  --namespace clickhouse \
  --create-namespace \
  -f ch-operator.yaml
```

<h4 id="verify-the-operator-installation">
  Vérifier l’installation de l’opérateur
</h4>

```bash theme={"system"}
# Vérifier que le pod de l’opérateur est en cours d’exécution
kubectl get pods -n clickhouse

# Sortie attendue :
# NAME                                 READY   STATUS    RESTARTS   AGE
# ch-operator-wandb-xxxxx              1/1     Running   0          30s

# Vérifier la version de l’image de l’opérateur
kubectl get pods -n clickhouse -o jsonpath="{.items[*].spec.containers[*].image}" | \
  tr ' ' '\n' | grep -v 'metrics-exporter' | sort -u

# Sortie attendue :
# altinity/clickhouse-operator:0.25.4
```

Maintenant que l’opérateur est en cours d’exécution, vous pouvez provisionner le stockage persistant et les services de coordination dont dépend le cluster ClickHouse.

<h3 id="prepare-s3-storage">
  Préparer le stockage S3
</h3>

ClickHouse nécessite un stockage S3 ou compatible S3 pour assurer la persistance des données. Au cours de cette étape, vous allez créer le bucket et configurer la méthode d’authentification de ClickHouse auprès de celui-ci.

<h4 id="create-an-s3-bucket">
  Créer un bucket S3
</h4>

Créez un bucket S3 dans votre compte AWS ou chez votre fournisseur de stockage compatible S3. Remplacez `[BUCKET-NAME]` par le nom de votre bucket et `[REGION]` par votre région AWS :

```bash theme={"system"}
# Exemple pour AWS
aws s3 mb s3://[BUCKET-NAME] --region [REGION]
```

<h4 id="configure-s3-credentials">
  Configurer les identifiants d’authentification S3
</h4>

ClickHouse a besoin d’identifiants d’authentification pour lire et écrire dans le bucket. Deux options s’offrent à vous pour fournir les identifiants d’accès S3. Sur AWS, W\&B recommande l’option A (IRSA), car elle évite de stocker des secrets à longue durée de vie dans le cluster.

<h5 id="option-a-use-aws-iam-roles-irsa-recommended-for-aws">
  Option A : utiliser les rôles IAM AWS (IRSA, recommandé pour AWS)
</h5>

Si vos nœuds Kubernetes disposent d’un rôle IAM donnant accès à S3, ClickHouse peut utiliser les métadonnées de l’instance EC2 :

```yaml theme={"system"}
# Dans ch-server.yaml, définissez :
<use_environment_credentials>true</use_environment_credentials>
```

Politique IAM requise (attachée au rôle IAM de vos nœuds) :

```json theme={"system"}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::[BUCKET-NAME]",
        "arn:aws:s3:::[BUCKET-NAME]/*"
      ]
    }
  ]
}
```

<h5 id="option-b-use-access-keys">
  Option B : utiliser des clés d’accès
</h5>

Si vous préférez utiliser des identifiants d’authentification statiques, créez un secret Kubernetes :

Remplacez `[ACCESS-KEY]` par votre clé d’accès AWS et `[SECRET-KEY]` par votre clé secrète AWS :

```bash theme={"system"}
kubectl create secret generic aws-creds \
  --namespace clickhouse \
  --from-literal aws_access_key=[ACCESS-KEY] \
  --from-literal aws_secret_key=[SECRET-KEY]
```

Configurez ensuite ClickHouse pour qu’il utilise le secret (voir la configuration ch-server.yaml à l’étape 4).

<h3 id="deploy-clickhouse-keeper">
  Déployer ClickHouse Keeper
</h3>

[ClickHouse Keeper](https://clickhouse.com/docs/guides/sre/keeper/clickhouse-keeper) fournit le système de coordination nécessaire à la réplication des données et à l’exécution des requêtes DDL distribuées. Vous devez déployer Keeper avant le cluster ClickHouse, car les serveurs ClickHouse de l’étape 4 se connectent à Keeper dès leur démarrage.

<h4 id="create-the-keeper-configuration">
  Créer la configuration de Keeper
</h4>

Créez un fichier nommé `ch-keeper.yaml`. Ce manifeste définit un cluster Keeper à trois réplicas avec anti-affinité et stockage persistant, ainsi que les paramètres utilisés par l’opérateur Altinity pour provisionner les pods Keeper :

```yaml theme={"system"}
apiVersion: "clickhouse-keeper.altinity.com/v1"
kind: "ClickHouseKeeperInstallation"
metadata:
  name: wandb
  namespace: clickhouse
  annotations: {}
spec:
  defaults:
    templates:
      podTemplate: default
      dataVolumeClaimTemplate: default

  templates:
    podTemplates:
      - name: keeper
        metadata:
          labels:
            app: clickhouse-keeper
        spec:
          # Contexte de sécurité du pod - à adapter à votre environnement
          securityContext:
            fsGroup: 10001 # À mettre à jour selon les exigences de sécurité de votre cluster
            fsGroupChangePolicy: Always
            runAsGroup: 0
            runAsNonRoot: true
            runAsUser: 10001 # Pour OpenShift, utilisez la plage d’UID attribuée à votre projet
            seccompProfile:
              type: RuntimeDefault

          # Anti-affinité pour répartir les keepers sur plusieurs nœuds (recommandé pour la haute disponibilité)
          # À personnaliser ou supprimer selon la taille de votre cluster et vos exigences de disponibilité
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchExpressions:
                      - key: "app"
                        operator: In
                        values:
                          - clickhouse-keeper
                  topologyKey: "kubernetes.io/hostname"

          containers:
            - name: clickhouse-keeper
              imagePullPolicy: IfNotPresent
              image: "clickhouse/clickhouse-keeper:25.10"
              # Demandes de ressources - valeurs données à titre d’exemple, à ajuster selon la charge de travail
              resources:
                requests:
                  memory: "256Mi"
                  cpu: "0.5"
                limits:
                  memory: "2Gi"
                  cpu: "1"

              securityContext:
                allowPrivilegeEscalation: false
                capabilities:
                  drop:
                    - ALL
                privileged: false
                readOnlyRootFilesystem: false

    volumeClaimTemplates:
      - name: data
        metadata:
          labels:
            app: clickhouse-keeper
        spec:
          storageClassName: gp3 # Remplacez par votre StorageClass
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 10Gi

  configuration:
    clusters:
      - name: keeper # Nom du cluster Keeper - utilisé pour le nommage DNS du service
        layout:
          replicasCount: 3
        templates:
          podTemplate: keeper
          dataVolumeClaimTemplate: data

    settings:
      logger/level: "information"
      logger/console: "true"
      listen_host: "0.0.0.0"
      keeper_server/four_letter_word_white_list: "*"
      keeper_server/coordination_settings/raft_logs_level: "information"
      keeper_server/enable_ipv6: "false"
      keeper_server/coordination_settings/async_replication: "true"
```

Mises à jour importantes de la configuration :

* **StorageClass** : modifiez `storageClassName: gp3` pour qu'il corresponde à la StorageClass disponible dans votre cluster.
* **Contexte de sécurité** : ajustez les valeurs `runAsUser` et `fsGroup` pour respecter les politiques de sécurité de votre organisation.
* **Anti-affinité** : personnalisez ou supprimez la section `affinity` en fonction de la topologie de votre cluster et de vos exigences de haute disponibilité.
* **Ressources** : les valeurs de CPU et de mémoire sont fournies à titre d'exemple. Consultez les Solutions Architects W\&B pour un dimensionnement adapté.
* **Nommage** : si vous modifiez `metadata.name` ou `configuration.clusters[0].name`, vous devez mettre à jour en conséquence les noms d'hôte Keeper dans `ch-server.yaml` (étape 4).

<h4 id="deploy-clickhouse-keeper-resources">
  Déployer les ressources ClickHouse Keeper
</h4>

```bash theme={"system"}
kubectl apply -f ch-keeper.yaml
```

<h4 id="verify-the-keeper-deployment">
  Vérifier le déploiement de Keeper
</h4>

```bash theme={"system"}
# Vérifier les pods Keeper
kubectl get pods -n clickhouse -l app=clickhouse-keeper

# Sortie attendue :
# NAME                     READY   STATUS    RESTARTS   AGE
# chk-wandb-keeper-0-0-0   1/1     Running   0          2m
# chk-wandb-keeper-0-1-0   1/1     Running   0          2m
# chk-wandb-keeper-0-2-0   1/1     Running   0          2m

# Vérifier les services Keeper
kubectl get svc -n clickhouse | grep keeper

# Les services Keeper doivent apparaître sur le port 2181
```

Maintenant que Keeper est opérationnel, vous pouvez déployer le cluster ClickHouse qui s’appuie sur lui pour la coordination.

<h3 id="deploy-the-clickhouse-cluster">
  Déployer le cluster ClickHouse
</h3>

Déployez maintenant le cluster de serveurs ClickHouse qui stocke les données de trace Weave. Il s’agit de l’étape la plus longue du guide, car le cluster se connecte à la fois au service Keeper de l’étape 3 et au bucket S3 de l’étape 2.

<h4 id="create-the-clickhouse-server-configuration">
  Créer la configuration du serveur ClickHouse
</h4>

Créez un fichier nommé `ch-server.yaml`. Ce manifeste déclare le cluster ClickHouse, sa connexion à Keeper, le compte utilisateur Weave ainsi que la stratégie de stockage S3 utilisée pour les données de trace :

```yaml theme={"system"}
apiVersion: "clickhouse.altinity.com/v1"
kind: "ClickHouseInstallation"
metadata:
  name: wandb
  namespace: clickhouse
  annotations: {}
spec:
  defaults:
    templates:
      podTemplate: default
      dataVolumeClaimTemplate: default

  templates:
    podTemplates:
      - name: clickhouse
        metadata:
          labels:
            app: clickhouse-server
        spec:
          # Contexte de sécurité du pod - à personnaliser selon votre environnement
          securityContext:
            fsGroup: 10001 # À ajuster selon vos politiques de sécurité
            fsGroupChangePolicy: Always
            runAsGroup: 0
            runAsNonRoot: true
            runAsUser: 10001 # Pour OpenShift, utiliser la plage d’UID attribuée
            seccompProfile:
              type: RuntimeDefault

          # Règle d’anti-affinité - garantit que les serveurs s’exécutent sur des nœuds différents (facultatif, mais recommandé)
          # À ajuster ou à supprimer selon la taille de votre cluster et vos exigences
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchExpressions:
                      - key: "app"
                        operator: In
                        values:
                          - clickhouse-server
                  topologyKey: "kubernetes.io/hostname"

          containers:
            - name: clickhouse
              image: clickhouse/clickhouse-server:25.10
              # Exemple d’allocation de ressources - à ajuster selon la charge de travail
              resources:
                requests:
                  memory: 1Gi
                  cpu: 1
                limits:
                  memory: 16Gi
                  cpu: 4

              # Identifiants AWS (supprimer cette section si vous utilisez IRSA)
              env:
                - name: AWS_ACCESS_KEY_ID
                  valueFrom:
                    secretKeyRef:
                      name: aws-creds
                      key: aws_access_key
                - name: AWS_SECRET_ACCESS_KEY
                  valueFrom:
                    secretKeyRef:
                      name: aws-creds
                      key: aws_secret_key

              securityContext:
                allowPrivilegeEscalation: false
                capabilities:
                  drop:
                    - ALL
                privileged: false
                readOnlyRootFilesystem: false

    volumeClaimTemplates:
      - name: data
        metadata:
          labels:
            app: clickhouse-server
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 50Gi
          storageClassName: gp3 # Remplacer par votre StorageClass

  configuration:
    # Configuration de Keeper (ZooKeeper)
    # IMPORTANT : ces noms d’hôte DOIVENT correspondre à votre déploiement Keeper de l’étape 3
    zookeeper:
      nodes:
        - host: chk-wandb-keeper-0-0.clickhouse.svc.cluster.local
          port: 2181
        - host: chk-wandb-keeper-0-1.clickhouse.svc.cluster.local
          port: 2181
        - host: chk-wandb-keeper-0-2.clickhouse.svc.cluster.local
          port: 2181
      # Facultatif : décommenter pour ajuster les délais d’expiration si nécessaire
      # session_timeout_ms: 30000
      # operation_timeout_ms: 10000

    # Configuration des utilisateurs : https://clickhouse.com/docs/operations/configuration-files#user-settings
    # En production, utiliser un mot de passe haché en SHA-256 plutôt qu’un mot de passe en clair :
    # printf "your-password" | sha256sum
    # Puis utiliser : weave/password_sha256_hex: <hash> au lieu de weave/password
    users:
      weave/password: [WEAVE-PASSWORD]  # Remplacer par un mot de passe robuste avant le déploiement
      weave/access_management: 1
      weave/profile: default
      weave/networks/ip:
        - "0.0.0.0/0"
        - "::"

    # Paramètres du serveur
    settings:
      disable_internal_dns_cache: 1

    # Configuration du cluster
    clusters:
      - name: weavecluster # Nom du cluster - personnalisable, mais doit correspondre à wandb-cr.yaml
        layout:
          shardsCount: 1
          replicasCount: 3 # Nombre de réplicas - à ajuster selon vos exigences de haute disponibilité
        templates:
          podTemplate: clickhouse
          dataVolumeClaimTemplate: data

    # Fichiers de configuration
    files:
      config.d/network_configuration.xml: |
        <clickhouse>
            <listen_host>0.0.0.0</listen_host>
            <listen_host>::</listen_host>
        </clickhouse>

      config.d/logger.xml: |
        <clickhouse>
            <logger>
                <level>information</level>
            </logger>
        </clickhouse>

      config.d/storage_configuration.xml: |
        <clickhouse>
            <storage_configuration>
                <disks>
                    <s3_disk>
                        <type>s3</type>
                        <!-- Mettre à jour avec le point de terminaison et la région de votre bucket S3 -->
                        <endpoint>https://[BUCKET-NAME].s3.[REGION].amazonaws.com/s3_disk/{replica}</endpoint>
                        <metadata_path>/var/lib/clickhouse/disks/s3_disk/</metadata_path>
                        <use_environment_credentials>true</use_environment_credentials>
                        <region>[REGION]</region>
                    </s3_disk>
                    <s3_disk_cache>
                        <type>cache</type>
                        <disk>s3_disk</disk>
                        <path>/var/lib/clickhouse/s3_disk_cache/cache/</path>
                        <!-- La taille du cache DOIT être inférieure à celle du volume persistant -->
                        <max_size>40Gi</max_size>
                        <cache_on_write_operations>true</cache_on_write_operations>
                    </s3_disk_cache>
                </disks>
                <policies>
                    <s3_main>
                        <volumes>
                            <main>
                                <disk>s3_disk_cache</disk>
                            </main>
                        </volumes>
                    </s3_main>
                </policies>
            </storage_configuration>
            <merge_tree>
                <storage_policy>s3_main</storage_policy>
            </merge_tree>
        </clickhouse>
```

Mises à jour de configuration essentielles :

1. **StorageClass** : modifiez `storageClassName: gp3` pour qu’il corresponde à la StorageClass de votre cluster.
2. **Point de terminaison S3** : remplacez `[BUCKET-NAME]` et `[REGION]` par vos propres valeurs.
3. **Taille du cache** : la valeur `<max_size>40Gi</max_size>` doit être inférieure à la taille du volume persistant (50Gi).
4. **Contexte de sécurité** : ajustez `runAsUser`, `fsGroup` et les autres paramètres de sécurité conformément aux politiques de votre organisation.
5. **Allocation des ressources** : les valeurs de CPU et de mémoire sont fournies à titre d’exemple. Consultez votre Solutions Architect W\&B pour obtenir un dimensionnement adapté au volume de traces attendu.
6. **Règles d’anti-affinité** : personnalisez-les ou supprimez-les en fonction de la topologie de votre cluster et de vos besoins en haute disponibilité.
7. **Noms d’hôte Keeper** : les noms d’hôte des nœuds Keeper doivent correspondre au nommage de votre déploiement Keeper défini à l’étape 3 (voir « Nommage Keeper »).
8. **Nommage du cluster** : le nom de cluster `weavecluster` peut être modifié, mais il doit correspondre à la valeur `WF_CLICKHOUSE_REPLICATED_CLUSTER` de l’étape 5.
9. **Identifiants d’authentification** :
   * Pour IRSA : conservez `<use_environment_credentials>true</use_environment_credentials>` ou utilisez vos clés secrètes mappées sur des variables d’environnement.

<h4 id="update-the-s3-configuration">
  Mettre à jour la configuration S3
</h4>

Modifiez la section `storage_configuration.xml` dans `ch-server.yaml`.

Exemple pour AWS S3 :

```xml theme={"system"}
<endpoint>https://my-wandb-clickhouse.s3.eu-central-1.amazonaws.com/s3_disk/{replica}</endpoint>
<region>eu-central-1</region>
```

Exemple pour MinIO :

```xml theme={"system"}
<endpoint>https://minio.example.com:9000/my-bucket/s3_disk/{replica}</endpoint>
<region>us-east-1</region>
```

<Warning>
  Ne supprimez pas `{replica}`. Ce paramètre garantit que chaque réplica ClickHouse écrit dans son propre dossier au sein du bucket.
</Warning>

<h4 id="configure-credentials-option-b-only">
  Configurer les identifiants d’authentification (option B uniquement)
</h4>

Si vous utilisez l’option B (clés d’accès) de l’étape 2, vérifiez que la section `env` du fichier `ch-server.yaml` fait bien référence au secret :

```yaml theme={"system"}
env:
  - name: AWS_ACCESS_KEY_ID
    valueFrom:
      secretKeyRef:
        name: aws-creds
        key: aws_access_key
  - name: AWS_SECRET_ACCESS_KEY
    valueFrom:
      secretKeyRef:
        name: aws-creds
        key: aws_secret_key
```

Si vous utilisez l’option A (IRSA), supprimez toute la section `env`.

<h4 id="keeper-naming">
  Nommage des Keepers
</h4>

Il est essentiel de bien définir les noms d'hôte des Keepers. S'ils ne correspondent pas aux services créés à l'étape 3, ClickHouse ne démarrera pas. Les noms d'hôte des nœuds Keeper dans la section `zookeeper.nodes` suivent un modèle précis, basé sur votre déploiement Keeper de l'étape 3.

Modèle de nom d'hôte : `chk-[INSTALLATION-NAME]-[CLUSTER-NAME]-[CLUSTER-INDEX]-[REPLICA-INDEX].[NAMESPACE].svc.cluster.local`

Où :

* `chk` est le préfixe de ClickHouseKeeperInstallation (fixe).
* `[INSTALLATION-NAME]` correspond à la valeur `metadata.name` de `ch-keeper.yaml` (par exemple, `wandb`).
* `[CLUSTER-NAME]` correspond à la valeur `configuration.clusters[0].name` de `ch-keeper.yaml` (par exemple, `keeper`).
* `[CLUSTER-INDEX]` est l'index du cluster, généralement `0` pour un cluster unique.
* `[REPLICA-INDEX]` est le numéro du réplica : `0`, `1` ou `2` pour 3 réplicas.
* `[NAMESPACE]` est le namespace Kubernetes (par exemple, `clickhouse`).

Exemple avec les noms par défaut :

```text theme={"system"}
chk-wandb-keeper-0-0.clickhouse.svc.cluster.local
chk-wandb-keeper-0-1.clickhouse.svc.cluster.local
chk-wandb-keeper-0-2.clickhouse.svc.cluster.local
```

Si vous personnalisez le nom de l’installation Keeper (par exemple, `metadata.name: myweave`) :

```text theme={"system"}
chk-myweave-keeper-0-0.clickhouse.svc.cluster.local
chk-myweave-keeper-0-1.clickhouse.svc.cluster.local
chk-myweave-keeper-0-2.clickhouse.svc.cluster.local
```

Si vous personnalisez le nom du cluster Keeper (par exemple, `clusters[0].name: coordination`) :

```text theme={"system"}
chk-wandb-coordination-0-0.clickhouse.svc.cluster.local
chk-wandb-coordination-0-1.clickhouse.svc.cluster.local
chk-wandb-coordination-0-2.clickhouse.svc.cluster.local
```

Pour vérifier les noms d’hôte réels de vos Keepers :

```bash theme={"system"}
# Lister les services Keeper pour afficher leurs noms réels
kubectl get svc -n clickhouse | grep keeper

# Lister les pods Keeper pour vérifier le schéma de nommage
kubectl get pods -n clickhouse -l app=clickhouse-keeper
```

<Note>
  Les noms d’hôte Keeper définis dans `ch-server.yaml` doivent correspondre exactement aux noms des services réellement créés par le déploiement Keeper, faute de quoi les serveurs ClickHouse ne pourront pas se connecter au service de coordination.
</Note>

<h4 id="deploy-the-clickhouse-cluster-resources">
  Déployer les ressources du cluster ClickHouse
</h4>

```bash theme={"system"}
kubectl apply -f ch-server.yaml
```

<h4 id="verify-the-clickhouse-deployment">
  Vérifier le déploiement de ClickHouse
</h4>

```bash theme={"system"}
# Vérifier les pods ClickHouse
kubectl get pods -n clickhouse -l app=clickhouse-server

# Sortie attendue :
# NAME                           READY   STATUS    RESTARTS   AGE
# chi-wandb-weavecluster-0-0-0   1/1     Running   0          3m
# chi-wandb-weavecluster-0-1-0   1/1     Running   0          3m
# chi-wandb-weavecluster-0-2-0   1/1     Running   0          3m

# Tester la connexion à ClickHouse
kubectl exec -n clickhouse chi-wandb-weavecluster-0-0-0 -- \
  clickhouse-client --user weave --password [WEAVE-PASSWORD] --query "SELECT version()"

# Vérifier le statut du cluster
kubectl exec -n clickhouse chi-wandb-weavecluster-0-0-0 -- \
  clickhouse-client --user weave --password [WEAVE-PASSWORD] --query \
  "SELECT cluster, host_name, port FROM system.clusters WHERE cluster='weavecluster'"
```

À ce stade, vous disposez d’un cluster ClickHouse opérationnel, qui s’appuie sur Keeper et S3. Les étapes restantes consistent à connecter la Plateforme W\&B à ce cluster, puis à vérifier que les traces Weave circulent de bout en bout.

<h3 id="enable-weave-in-the-wb-platform">
  Activer Weave dans la plateforme W\&B
</h3>

Configurez maintenant la plateforme W\&B afin qu’elle utilise le cluster ClickHouse pour les traces Weave. Cette étape indique au W\&B Operator où trouver votre instance ClickHouse gérée en externe et active le service `weave-trace`.

<h4 id="gather-clickhouse-connection-information">
  Rassembler les informations de connexion ClickHouse
</h4>

Vous aurez besoin des éléments suivants :

* **Hôte** : `clickhouse-wandb.clickhouse.svc.cluster.local`
* **Port** : `8123`
* **Utilisateur** : `weave` (tel que configuré dans `ch-server.yaml`)
* **Mot de passe** : le mot de passe que vous avez défini dans `ch-server.yaml`
* **Base de données** : `weave` (créée automatiquement)
* **Nom du cluster** : `weavecluster` (tel que configuré dans `ch-server.yaml`)

Le nom d’hôte respecte le format suivant : `clickhouse-[INSTALLATION-NAME].[NAMESPACE].svc.cluster.local`

<h4 id="update-the-wb-custom-resource">
  Mettre à jour la Ressource personnalisée W\&B
</h4>

Modifiez la Ressource personnalisée (CR) de votre Plateforme W\&B pour y ajouter la configuration de Weave :

```yaml theme={"system"}
apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  name: wandb
  namespace: wandb
spec:
  values:
    global:
      # ... configuration existante ...

      # Ajouter la configuration ClickHouse
      clickhouse:
        install: false # Déployé séparément
        host: clickhouse-wandb.clickhouse.svc.cluster.local
        port: 8123
        user: weave
        password: [WEAVE-PASSWORD]
        database: weave
        replicated: true # REQUIS pour une configuration à plusieurs réplicas

      # Activer Weave Trace
      weave-trace:
        enabled: true

    # Configuration de Weave Trace
    weave-trace:
      install: true
      extraEnv:
        WF_CLICKHOUSE_REPLICATED: "true"
        WF_CLICKHOUSE_REPLICATED_CLUSTER: "weavecluster"
      image:
        repository: wandb/weave-trace
        tag: 0.74.1
      replicaCount: 1
      size: "default"
      sizing:
        default:
          autoscaling:
            horizontal:
              enabled: false
          # Exemple d’allocation de ressources : à ajuster en fonction de la charge de travail
          resources:
            limits:
              cpu: 4
              memory: "8Gi"
            requests:
              cpu: 1
              memory: "4Gi"
      # Contexte de sécurité du pod : à personnaliser selon votre environnement
      podSecurityContext:
        fsGroup: 10001 # À ajuster selon vos exigences de sécurité
        fsGroupChangePolicy: Always
        runAsGroup: 0
        runAsNonRoot: true
        runAsUser: 10001 # Pour OpenShift, utilisez la plage d’UID attribuée
        seccompProfile:
          type: RuntimeDefault
      # Contexte de sécurité du conteneur
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        privileged: false
        readOnlyRootFilesystem: false
```

Paramètres essentiels :

* `clickhouse.replicated: true` : requis si vous utilisez 3 réplicas.
* `WF_CLICKHOUSE_REPLICATED: "true"` : requis pour une configuration répliquée.
* `WF_CLICKHOUSE_REPLICATED_CLUSTER: "weavecluster"` : doit correspondre au nom du cluster défini dans `ch-server.yaml`.

<Note>
  Les contextes de sécurité, les allocations de ressources et les autres configurations propres à Kubernetes présentés ici sont fournis à titre d’exemple. Personnalisez-les selon les exigences de votre organisation et consultez votre équipe Solutions Architect W\&B pour dimensionner correctement les ressources.
</Note>

<h4 id="apply-the-updated-configuration">
  Appliquer la configuration mise à jour
</h4>

```bash theme={"system"}
kubectl apply -f wandb-cr.yaml
```

<h4 id="verify-the-weave-trace-deployment">
  Vérifier le déploiement de Weave Trace
</h4>

```bash theme={"system"}
# Vérifier le statut du pod weave-trace
kubectl get pods -n wandb | grep weave-trace

# Sortie attendue :
# wandb-weave-trace-bc-xxxxx   1/1     Running   0          2m

# Vérifier la connexion à ClickHouse dans les journaux de weave-trace
kubectl logs -n wandb [WEAVE-TRACE-POD-NAME] --tail=50

# Rechercher les messages confirmant la connexion à ClickHouse
```

<h3 id="initialize-the-weave-database">
  Initialiser la base de données Weave
</h3>

Le service weave-trace crée automatiquement le schéma de base de données requis lors de son premier démarrage. Au cours de cette étape, vous vérifiez que la migration s’est bien déroulée avant de mettre Weave à la disposition des utilisateurs finaux.

<h4 id="monitor-the-database-migration">
  Surveiller la migration de la base de données
</h4>

```bash theme={"system"}
# Suivez les journaux de weave-trace pendant le démarrage
kubectl logs -n wandb [WEAVE-TRACE-POD-NAME] -f

# Repérez les messages de migration confirmant que la base de données a bien été initialisée
```

<h4 id="verify-database-creation">
  Vérifier la création de la base de données
</h4>

```bash theme={"system"}
# Se connecter à ClickHouse et vérifier la base de données
kubectl exec -n clickhouse chi-wandb-weavecluster-0-0-0 -- \
  clickhouse-client --user weave --password [WEAVE-PASSWORD] --query \
  "SHOW DATABASES"

# La base de données « weave » doit figurer dans la liste

# Vérifier les tables de la base de données weave
kubectl exec -n clickhouse chi-wandb-weavecluster-0-0-0 -- \
  clickhouse-client --user weave --password [WEAVE-PASSWORD] --query \
  "SHOW TABLES FROM weave"
```

<h3 id="verify-that-weave-is-enabled">
  Vérifier que Weave est activé
</h3>

Cette dernière étape permet de confirmer que Weave dispose d’une licence, qu’il est accessible depuis la console W\&B et qu’il peut enregistrer des traces depuis un SDK client.

<h4 id="access-the-wb-console">
  Accéder à la console W\&B
</h4>

Accédez à l’URL de votre instance W\&B dans un navigateur web.

<h4 id="check-the-weave-license-status">
  Vérifier le statut de la licence Weave
</h4>

Dans la console W\&B :

1. Accédez à **menu en haut à droite** > **tableau de bord de l’organisation**.
2. Vérifiez que **Weave access** est activé.

<h4 id="test-weave-functionality">
  Tester le fonctionnement de Weave
</h4>

Créez un test Python pour vérifier que Weave fonctionne :

```python theme={"system"}
import os
import weave

# Faire pointer Weave vers votre instance W&B autogérée
os.environ["WANDB_BASE_URL"] = "https://[WANDB-HOST]"  # Remplacez par l’URL de votre instance W&B

weave.init('test-project')

# Créer une fonction simple tracée
@weave.op()
def hello_weave(name: str) -> str:
    return f"Hello, {name}!"

# Appeler la fonction
result = hello_weave("World")
print(result)
```

Après avoir exécuté ce code, vérifiez que des traces apparaissent dans l’interface Weights & Biases, sur la page des traces de votre organisation. Si la trace s’affiche, votre déploiement Weave autogéré est opérationnel.

<h2 id="troubleshooting">
  Dépannage
</h2>

Les sections suivantes décrivent les problèmes de déploiement courants et leur résolution, regroupés selon le composant où le symptôme se manifeste en premier.

<h3 id="clickhouse-keeper-issues">
  Problèmes liés à ClickHouse Keeper
</h3>

**Problème** : les pods Keeper restent bloqués à l’état `Pending`

**Solution** : vérifiez plusieurs causes possibles :

1. **Problèmes liés au PVC et à la StorageClass** :

```bash theme={"system"}
kubectl get pvc -n clickhouse
kubectl describe pvc -n clickhouse
```

Assurez-vous que votre StorageClass est correctement configurée et dispose de capacité disponible.

2. **Anti-affinité et disponibilité des nœuds** :

```bash theme={"system"}
# Vérifier si des règles d’anti-affinité empêchent la planification des pods
kubectl describe pod -n clickhouse [POD-NAME] | grep -A 10 "Events:"

# Vérifier les nœuds disponibles et leurs ressources
kubectl get nodes
kubectl describe nodes | grep -A 5 "Allocated resources"
```

Problèmes courants :

* L’anti-affinité requiert 3 nœuds distincts, mais le cluster en compte moins.
* Les nœuds ne disposent pas de suffisamment de CPU ou de mémoire pour satisfaire les requêtes de ressources des pods.
* Des taints sur les nœuds empêchent la planification des pods.

**Solutions** :

* Supprimez ou ajustez les règles d’anti-affinité si vous disposez de moins de 3 nœuds.
* Utilisez `preferredDuringSchedulingIgnoredDuringExecution` au lieu de `requiredDuringSchedulingIgnoredDuringExecution` pour une anti-affinité plus souple.
* Réduisez les requêtes de ressources si les ressources des nœuds sont limitées.
* Ajoutez des nœuds supplémentaires à votre cluster.

***

**Problème** : pods Keeper en état `CrashLoopBackOff`

**Solution** : consultez les journaux et vérifiez la configuration :

```bash theme={"system"}
kubectl logs -n clickhouse [KEEPER-POD-NAME]
```

Problèmes courants :

* Contexte de sécurité incorrect (vérifiez `runAsUser` et `fsGroup`).
* Problèmes d’autorisations sur les volumes.
* Conflits de ports.
* Erreurs de configuration dans `ch-keeper.yaml`.

<h3 id="clickhouse-server-issues">
  Problèmes liés au serveur ClickHouse
</h3>

**Problème** : ClickHouse ne parvient pas à se connecter à S3

**Solution** : Vérifiez les identifiants d’authentification et les autorisations S3 :

```bash theme={"system"}
# Vérifier que le secret existe (si vous utilisez des clés d’accès)
kubectl get secret aws-creds -n clickhouse

# Rechercher les erreurs S3 dans les journaux ClickHouse
kubectl logs -n clickhouse [CLICKHOUSE-POD-NAME] | grep -i s3

# Vérifier le point de terminaison S3 dans la configuration du stockage
kubectl get chi wandb -n clickhouse -o yaml | grep -A 10 storage_configuration
```

***

**Problème** : ClickHouse ne parvient pas à se connecter à Keeper

**Solution** : Vérifiez les points de terminaison et le nommage de Keeper :

```bash theme={"system"}
# Vérifier les services Keeper et leurs noms réels
kubectl get svc -n clickhouse | grep keeper

# Vérifier les pods Keeper pour confirmer le schéma de nommage
kubectl get pods -n clickhouse -l app=clickhouse-keeper

# Comparer avec la configuration zookeeper.nodes dans ch-server.yaml
# Les noms d’hôte DOIVENT correspondre aux noms réels des services

# Rechercher les erreurs de connexion dans les journaux ClickHouse
kubectl logs -n clickhouse chi-wandb-weavecluster-0-0-0 | grep -i keeper
```

Si la connexion échoue, les noms d'hôte Keeper dans `ch-server.yaml` ne correspondent probablement pas à votre déploiement Keeper réel. Voir la section « Nommage de Keeper » de l'étape 4 pour connaître le modèle de nommage.

<h3 id="weave-trace-issues">
  Problèmes liés à Weave Trace
</h3>

**Problème** : le pod `weave-trace` ne démarre pas

**Solution** : vérifiez la connectivité à ClickHouse :

```bash theme={"system"}
# Obtenir le nom du pod weave-trace
kubectl get pods -n wandb | grep weave-trace

# Consulter les journaux de weave-trace
kubectl logs -n wandb [WEAVE-TRACE-POD-NAME]

# Erreur courante : « connection refused » ou « authentication failed »
# Vérifier que les identifiants d’authentification ClickHouse de wandb-cr.yaml correspondent à ceux de ch-server.yaml
```

***

**Problème** : Weave n’apparaît pas comme activé dans la Console

**Solution** : Vérifiez la configuration :

1. Vérifiez que la licence inclut Weave :

   ```bash theme={"system"}
   kubectl get secret license-key -n wandb -o jsonpath='{.data.value}' | base64 -d | jq
   ```

2. Assurez-vous que `weave-trace.enabled: true` et `clickhouse.replicated: true` sont définis dans `wandb-cr.yaml`.

3. Consultez les journaux de l’opérateur W\&B :
   ```bash theme={"system"}
   kubectl logs -n wandb deployment/wandb-controller-manager
   ```

***

**Problème** : La migration de la base de données échoue

**Solution** : Vérifiez que le nom du cluster correspond :

La variable d’environnement `WF_CLICKHOUSE_REPLICATED_CLUSTER` doit correspondre au nom du cluster défini dans `ch-server.yaml` :

```yaml theme={"system"}
# Dans ch-server.yaml :
clusters:
  - name: weavecluster # <-- Ce nom

# Doit être identique dans wandb-cr.yaml :
weave-trace:
  extraEnv:
    WF_CLICKHOUSE_REPLICATED_CLUSTER: "weavecluster" # <-- Cette valeur
```

<h2 id="resource-requirements">
  Ressources requises
</h2>

Cette section fournit des exemples d’allocation de ressources pour deux profils de déploiement courants. Utilisez-les comme point de départ pour planifier votre cluster, puis ajustez les valeurs en fonction de la charge de travail observée.

<Warning>
  Les allocations de ressources présentées dans cette section sont des points de départ indicatifs. Les exigences réelles varient en fonction des éléments suivants :

  * Volume d’importation des traces (traces par seconde)
  * Profils de requêtes et simultanéité
  * Durée de rétention des données
  * Nombre d’utilisateurs simultanés

  Consultez toujours votre équipe de Solutions Architects W\&B afin de déterminer le dimensionnement adapté à votre cas d’utilisation. Des ressources sous-provisionnées peuvent entraîner des problèmes de performances, tandis qu’un surprovisionnement engendre des coûts d’infrastructure inutiles.
</Warning>

<h3 id="minimum-production-setup">
  Configuration de production minimale
</h3>

| Composant | Réplicas | CPU (requête, limite) | Mémoire (requête, limite) | Stockage |
| - | - | - | - | - |
| ClickHouse Keeper | 3 | 0.5, 1 | 256Mi, 2Gi | 10Gi chacun |
| Serveur ClickHouse | 3 | 1, 4 | 1Gi, 16Gi | 50Gi chacun |
| Weave Trace | 1 | 1, 4 | 4Gi, 8Gi | - |
| **Total** | **7 pods** | **\~4.5, 15 CPU** | **\~7.8Gi, 58Gi** | **180Gi** |

Convient aux environnements de développement, de test ou de production à faible volume.

<h3 id="recommended-production-setup">
  Configuration de production recommandée
</h3>

Pour les charges de travail de production générant un volume de traces élevé :

| Composant | Réplicas | CPU (requête, limite) | Mémoire (requête, limite) | Stockage |
| - | - | - | - | - |
| ClickHouse Keeper | 3 | 1, 2 | 1Gi, 4Gi | 20Gi chacun |
| Serveur ClickHouse | 3 | 1, 16 | 8Gi, 64Gi | 200Gi chacun |
| Weave Trace | 2 à 3 | 1, 4 | 4Gi, 8Gi | - |
| **Total** | **8 à 9 pods** | **\~6 à 9, 52 à 64 CPU** | **\~27 à 33Gi, 204 à 216Gi** | **660Gi** |

Cette configuration convient aux environnements de production à fort volume.

Pour les déploiements à très fort volume, contactez votre équipe de Solutions Architects W\&B afin d’obtenir des recommandations de dimensionnement personnalisées, basées sur votre volume de traces et vos exigences de performances.

<h2 id="advanced-configuration">
  Configuration avancée
</h2>

Cette section présente les options de personnalisation des déploiements Weave autogérés, notamment l’augmentation de la capacité de ClickHouse par mise à l’échelle verticale ou horizontale, la mise à jour des versions de ClickHouse par la modification des tags d’image dans les configurations du keeper et du serveur, ainsi que la surveillance de l’état de santé de ClickHouse.

W\&B recommande de consulter votre équipe Solutions Architect W\&B avant d’apporter des modifications avancées à votre instance, afin de vous assurer qu’elles répondent à vos exigences de performances et de fiabilité.

<h3 id="scale-clickhouse">
  Mettre à l’échelle ClickHouse
</h3>

Pour augmenter la capacité de ClickHouse, vous pouvez recourir à :

1. **Mise à l’échelle verticale** : augmentez les ressources de chaque pod (approche la plus simple).

   ```yaml theme={"system"}
   resources:
     requests:
       memory: 8Gi
       cpu: 1
     limits:
       memory: 64Gi
       cpu: 16
   ```

   Recommandation : surveillez l’utilisation réelle des ressources et ajustez-les en conséquence. Pour les déploiements à très fort volume, contactez votre équipe Solutions Architect W\&B.

2. **Mise à l’échelle horizontale** : ajoutez des réplicas (nécessite une planification rigoureuse).
   * L’augmentation du nombre de réplicas implique un rééquilibrage des données.
   * Consultez la documentation de ClickHouse pour la gestion des shards.
   * Contactez un Solutions Architect W\&B avant de mettre en œuvre la mise à l’échelle horizontale en production.

<h3 id="use-a-different-clickhouse-version">
  Utiliser une autre version de ClickHouse
</h3>

Pour utiliser une autre version de ClickHouse, mettez à jour le tag d’image dans `ch-keeper.yaml` et dans `ch-server.yaml` :

```yaml theme={"system"}
image: clickhouse/clickhouse-keeper:25.10   # Version de Keeper
image: clickhouse/clickhouse-server:25.10   # Version du serveur
```

Pour garantir la compatibilité, les versions de Keeper et du serveur doivent être identiques, ou la version de Keeper doit être supérieure ou égale à celle du serveur.

<Warning>
  Lorsque vous mettez à niveau le serveur ClickHouse, mettez également à niveau ClickHouse Keeper vers une version compatible. Avant de changer de version de ClickHouse pour un déploiement W\&B autogéré, consultez la section [Compatibilité de ClickHouse pour les mises à niveau](/fr/products/wandb/platform/hosting/self-managed/operator#clickhouse-compatibility-for-upgrades) ainsi que la page [Versions du serveur W\&B prises en charge](/fr/release-notes/server-releases).
</Warning>

<h3 id="monitor-clickhouse">
  Surveiller ClickHouse
</h3>

Accédez aux tables système de ClickHouse pour en assurer la surveillance :

```bash theme={"system"}
# Vérifier l’utilisation des disques
kubectl exec -n clickhouse chi-wandb-weavecluster-0-0-0 -- \
  clickhouse-client --user weave --password [WEAVE-PASSWORD] --query \
  "SELECT name, path, formatReadableSize(free_space) as free, formatReadableSize(total_space) as total FROM system.disks"

# Vérifier le statut de la réplication
kubectl exec -n clickhouse chi-wandb-weavecluster-0-0-0 -- \
  clickhouse-client --user weave --password [WEAVE-PASSWORD] --query \
  "SELECT database, table, is_leader, total_replicas, active_replicas FROM system.replicas WHERE database='weave'"

# Vérifier le statut du serveur ClickHouse
kubectl get pods -n clickhouse -l app=clickhouse-server
```

<h3 id="backup-and-recovery">
  Sauvegarde et récupération
</h3>

ClickHouse stocke les données dans S3, ce qui offre des capacités de sauvegarde intégrées grâce aux fonctionnalités de gestion des versions et de réplication de buckets S3. Pour définir une stratégie de sauvegarde adaptée à votre déploiement, consultez votre équipe Solutions Architect W\&B et reportez-vous à la [documentation ClickHouse sur la sauvegarde](https://clickhouse.com/docs/en/operations/backup).

<h2 id="security-considerations">
  Considérations de sécurité
</h2>

Pour les déploiements en production, renforcez les valeurs par défaut présentées dans ce guide. La liste suivante récapitule les principaux points à examiner avec votre équipe de sécurité.

1. **Identifiants d’authentification** : stockez les mots de passe ClickHouse dans des secrets Kubernetes, et non en texte clair.
2. **Stratégies réseau** : envisagez de mettre en place des NetworkPolicies pour restreindre l’accès à ClickHouse.
3. **RBAC** : assurez-vous que les comptes de service ne disposent que des autorisations strictement nécessaires.
4. **Bucket S3** : activez le chiffrement au repos et limitez l’accès au bucket aux seuls rôles IAM nécessaires.
5. **TLS** : facultatif. En production, activez TLS pour les connexions client à ClickHouse.

<h2 id="upgrade">
  Mise à niveau
</h2>

Les procédures suivantes décrivent les mises à niveau courantes des composants suivants : l’opérateur, le serveur ClickHouse et Weave Trace. Mettez à niveau un seul composant à la fois et vérifiez que le déploiement est opérationnel avant de passer au suivant.

<Note>
  Weave nécessite une version de ClickHouse prise en charge. Consultez [Compatibilité de ClickHouse pour les mises à niveau](/fr/products/wandb/platform/hosting/self-managed/operator#clickhouse-compatibility-for-upgrades) et [Versions du serveur W\&B prises en charge](/fr/release-notes/server-releases) avant de mettre à niveau ClickHouse ou le serveur W\&B. Mettez à niveau le serveur ClickHouse et ClickHouse Keeper simultanément.
</Note>

<h3 id="upgrade-the-clickhouse-operator">
  Mettre à niveau l’opérateur ClickHouse
</h3>

```bash theme={"system"}
helm upgrade ch-operator altinity/altinity-clickhouse-operator \
  --namespace clickhouse \
  -f ch-operator.yaml
```

<h3 id="upgrade-clickhouse-server">
  Mettre à niveau le serveur ClickHouse
</h3>

Mettez à jour la version de l’image dans les fichiers `ch-keeper.yaml` et `ch-server.yaml`, puis appliquez le manifeste du serveur :

```bash theme={"system"}
# Modifiez les tags d'image dans ch-keeper.yaml et ch-server.yaml
kubectl apply -f ch-keeper.yaml
kubectl apply -f ch-server.yaml

# Surveillez les pods
kubectl get pods -n clickhouse
```

<h3 id="upgrade-weave-trace">
  Mettre à niveau Weave Trace
</h3>

Mettez à jour le tag d’image dans `wandb-cr.yaml`, puis appliquez la configuration :

```bash theme={"system"}
kubectl apply -f wandb-cr.yaml

# Surveiller le redémarrage du pod weave-trace
kubectl get pods -n wandb | grep weave-trace
```

<h2 id="additional-resources">
  Ressources supplémentaires
</h2>

* [Configurer l’échantillonnage à l’ingestion](/fr/products/wandb/weave/guides/platform/ingest-sampling) : ne conservez qu’une partie des traces entrantes afin de maîtriser les coûts de stockage et d’évaluation par LLM lorsque le volume de traces est élevé.
* [Documentation de l’opérateur ClickHouse d’Altinity](https://docs.altinity.com/altinitykubernetesoperator/)
* [Documentation de ClickHouse](https://clickhouse.com/docs)
* [Documentation de W\&B Weave](/fr/products/wandb/weave)
* [Configuration du stockage S3 pour ClickHouse](https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree#s3-virtual-hosted-style)

<h2 id="support">
  Assistance
</h2>

Pour les déploiements en production ou en cas de problème :

* **Assistance CoreWeave Forge** : `forge-support@coreweave.com`
* **Architectes de solutions** : pour les déploiements à très grand volume, le dimensionnement personnalisé et la planification des déploiements.
* **À inclure dans vos demandes d’assistance** :
  * Les journaux de `weave-trace`, des pods ClickHouse et de l’opérateur.
  * Les versions de W\&B, de ClickHouse et de Kubernetes.
  * Les informations sur le cluster et le volume de traces.

<h2 id="faq">
  FAQ
</h2>

**Q : Puis-je utiliser un seul réplica ClickHouse au lieu de 3 ?**

R : Oui, mais ce n’est pas recommandé en production. Définissez `replicasCount: 1` dans `ch-server.yaml` et `clickhouse.replicated: false` dans `wandb-cr.yaml`.

**Q : Puis-je utiliser une autre base de données que ClickHouse ?**

R : Non. Weave Trace nécessite ClickHouse pour ses capacités de stockage en colonnes hautes performances.

**Q : De quelle capacité de stockage S3 ai-je besoin ?**

R : Les besoins en stockage S3 dépendent de votre volume de traces, de la durée de rétention et de la compression des données. Surveillez votre utilisation réelle après le déploiement et ajustez en conséquence. Le format en colonnes de ClickHouse compresse efficacement les données de trace.

**Q : Dois-je configurer le nom de la `database` dans ClickHouse ?**

R : Non. Le service weave-trace crée automatiquement la base de données `weave` lors du premier démarrage.

**Q : Que faire si le nom de mon cluster n’est pas `weavecluster` ?**

R : Vous devez définir la variable d’environnement `WF_CLICKHOUSE_REPLICATED_CLUSTER` sur le nom de votre cluster, faute de quoi les migrations de base de données échoueront.

**Q : Dois-je reprendre à l’identique les contextes de sécurité présentés dans les exemples ?**

R : Non. Les contextes de sécurité tels que `runAsUser` et `fsGroup` fournis dans ce guide sont des exemples de référence. Vous devez les adapter aux politiques de sécurité de votre organisation, en particulier pour les clusters OpenShift, qui imposent des plages d’UID et de GID spécifiques.

**Q : Comment puis-je savoir si mon cluster ClickHouse est correctement dimensionné ?**

R : Contactez l’équipe Solutions Architect W\&B en lui indiquant votre volume de traces prévu et vos profils d’utilisation. Elle vous fournira des recommandations de dimensionnement. Surveillez l’utilisation des ressources de votre déploiement et ajustez-la si nécessaire.

**Q : Puis-je personnaliser les conventions de nommage utilisées dans les exemples ?**

R : Oui, mais vous devez garantir leur cohérence entre tous les composants :

1. **Noms ClickHouse Keeper** : ils doivent correspondre aux noms d’hôte des nœuds Keeper dans la section `zookeeper.nodes` de `ch-server.yaml`.
2. **Nom du cluster ClickHouse** (`weavecluster`) : il doit correspondre à `WF_CLICKHOUSE_REPLICATED_CLUSTER` dans `wandb-cr.yaml`.
3. **Nom de l’installation ClickHouse** : il détermine le nom d’hôte du service utilisé par `weave-trace`.

Voir la section « Nommage de Keeper » de l’étape 4 pour en savoir plus sur le modèle de nommage et sur la façon de vérifier vos noms réels.

**Q : Que faire si mon cluster a des exigences d’anti-affinité différentes ?**

R : Les règles d’anti-affinité présentées sont des recommandations pour la haute disponibilité. Ajustez-les ou supprimez-les en fonction de la taille, de la topologie et des exigences de disponibilité de votre cluster. Pour les petits clusters ou les environnements de développement, les règles d’anti-affinité ne sont pas forcément nécessaires.