Deploy Ray using Helm

Pour répartir nos besoins de calcul et exécuter des tâches lourdes comme la synthèse de vos données, nous devrons déployer un cluster Ray à l'aide de Helm pour que notre API puisse s'y connecter. Le graphique peut être trouvé dans le dépôt ici ou peut être fourni par une URL de dépôt à utiliser dans Helm directement. Veuillez contacter l'équipe Syntho pour obtenir l'URL de ce dépôt.

Cette partie de la documentation suppose un accès au dossier helm/ray dans la branche master du dépôt GitHub mentionné ci-dessus.

Une note pour les utilisateurs d'OpenShift : Ray nous oblige à créer de nombreux threads au sein d'un pod, en particulier lors de la mise à l'échelle du cluster Ray. Par défaut, OpenShift limite le nombre de processus qu'un pod peut générer, en raison de l'utilisation de CRI-O comme interface d'exécution de conteneur (CRI). Nous recommandons de mettre à jour cette limite : voir la section #additional-changes-for-openshift-cri-o

Définition de l'image

Dans le fichier values.yaml dans helm/ray, définissez les champs suivants pour assurer l'utilisation de la bonne image Docker :

operatorImage :
  repository : syntho.azurecr.io/syntho-ray-operator
  tag : <tag>
  pullPolicy : IfNotPresent

image :
  dépôt : syntho.azurecr.io/syntho-ray
  tag : <tag>
  pullPolicy : IfNotPresent

La balise image sera fournie par l'équipe Syntho. Dans certains cas, la dernière balise peut être utilisée, mais nous recommandons de définir une balise spécifique.

En plus de définir l'image Docker correcte, définissez le Secret Kubernetes qui est créé sous imagePullSecrets :

imagePullSecrets :
    - name : syntho-cr-secret

Cette valeur est fixée par défaut à syntho-cr-secret.

Clé de licence - Ray

La clé de licence peut être définie sous SynthoLicense dans le fichier values.yaml. Un exemple de ceci serait :

SynthoLicense : <syntho-license-key>

Veuillez utiliser la clé de licence fournie par Syntho.

Nom du cluster

Le nom du cluster par défaut est ray-cluster. Si cela doit être modifié, vous pouvez le faire en changeant clustername :

clustername : ray-cluster

Travailleurs et nœuds

Tout d'abord, l'équipe Syntho aura des recommandations sur la taille exacte du cluster en fonction de vos besoins en données. Si vous n'avez pas reçu d'information à ce sujet, veuillez contacter l'équipe Syntho pour discuter de la configuration optimale. Le reste de cette section donne un exemple de configuration pour montrer ce que cela donne dans le graphique Helm.

En fonction de la taille et du nombre de nœuds de la grappe, ajustez le nombre de travailleurs que Ray a à sa disposition pour les tâches. Ray aura besoin d'au moins une instance de tête. Pour augmenter les performances, nous pouvons également créer des groupes de travailleurs supplémentaires. Sous head, nous pouvons définir les ressources pour le nœud principal. Ce nœud principal sera principalement utilisé pour les tâches administratives dans Ray et les nœuds travailleurs prendront en charge la plupart des tâches pour l'application Syntho.

Pour un environnement de production, nous recommandons un pool de travailleurs à côté du noeud principal. L'équipe Syntho peut indiquer quelles ressources doivent être assignées au nœud principal et aux nœuds de travail. Voici un exemple de configuration d'un cluster avec un nœud principal et un pool de nœuds, d'une machine, avec 16 CPUs et 64GB de RAM :

head :
  rayStartParams :
    dashboard-host : '0.0.0.0'
    block : 'true'
  containerEnv :
  - name : RAY_SCHEDULER_SPREAD_THRESHOLD
    value : "0.0"
  envFrom : []
  ressources :
    limites :
      cpu : "16"
      memory : "64G"
    demandes :
      cpu : "16"
      mémoire : "64G"
  annotations : {}
  nodeSelector : {}
  tolérances : []
  affinity : {}
  securityContext : {}
  ports :
  - containerPort : 6379
    name : gcs
  - containerPort : 8265
    name : dashboard
  - containerPort : 10001
    name : client
  volumes :
    - name : log-volume
      emptyDir : {}
  volumeMounts :
    - mountPath : /tmp/ray
      name : log-volume
  sidecarContainers : []


worker :
  # Si vous souhaitez désactiver le groupe de travail par défaut
  # décommentez la ligne ci-dessous
  # disabled : true
  groupName : workergroup
  replicas : 1
  labels : {}
  rayStartParams :
    block : 'true'
  initContainerImage : 'busybox:1.28'
  initContainerSecurityContext : {}
  containerEnv :
   - name : RAY_SCHEDULER_SPREAD_THRESHOLD
     value : "0.0"
  envFrom : []
  ressources :
    limites :
      cpu : "16"
      memory : "64G"
    demandes :
      cpu : "16"
      mémoire : "64G"
  annotations : {}
  nodeSelector : {}
  tolérances : []
  affinity : {}
  securityContext : {}
  volumes :
    - name : log-volume
      emptyDir : {}
  volumeMounts :
    - mountPath : /tmp/ray
      name : log-volume
  sidecarContainers : []

Si l'autoscaling est activé dans Kubernetes, de nouveaux nœuds seront créés dès que les besoins en Ray seront plus élevés que les ressources disponibles. Veuillez discuter avec l'équipe Syntho de la situation qui correspondrait à vos besoins en données.

Pour les environnements de développement ou d'expérimentation, la plupart du temps une configuration moins avancée est nécessaire. Dans ce cas, nous recommandons de ne configurer qu'un type de nœud principal pour commencer, sans travailleurs ni configuration supplémentaire de mise à l'échelle automatique. L'équipe Syntho vous conseillera sur la taille de ce nœud, en fonction des besoins en données. Un exemple de configuration utilisant un nœud avec 16 CPUs et 64 GB de RAM serait :

head :
  rayStartParams :
    dashboard-host : '0.0.0.0'
    block : 'true'
  containerEnv :
  - name : RAY_SCHEDULER_SPREAD_THRESHOLD
    value : "0.0"
  envFrom : []
  ressources :
    limites :
      cpu : "16"
      # Pour éviter les problèmes de mémoire, ne jamais allouer moins de 2G de mémoire pour la tête de Ray.
      memory : "64G" # En fonction des besoins en données
    demandes :
      cpu : "16"
      mémoire : "64G" # En fonction des données requises
  annotations : {}
  nodeSelector : {}
  tolérances : []
  affinity : {}
  securityContext : {}
  ports :
  - containerPort : 6379
    name : gcs
  - containerPort : 8265
    name : dashboard
  - containerPort : 10001
    name : client
  volumes :
    - name : log-volume
      emptyDir : {}
  volumeMounts :
    - mountPath : /tmp/ray
      name : log-volume
  sidecarContainers : []

worker :
  # Si vous souhaitez désactiver le groupe de travail par défaut
  # décommentez la ligne ci-dessous
  disabled : true

# La clé de la carte est utilisée comme nom de groupe.
# Par exemple, key:small-group dans la carte ci-dessous
# sera utilisé comme nom de groupe
additionalWorkerGroups :
  smallGroup :
    # Désactivé par défaut
    disabled : false

De plus, nodeSelector, tolerations et affinity peuvent être définis pour chaque type de noeud, afin d'avoir un certain contrôle sur l'affectation des pods/noeuds. securityContext et annotiations peuvent aussi être définis pour chaque type de nœud worker/head.

Stockage partagé des travailleurs Ray

Nous avons besoin d'un volume persistant supplémentaire pour les travailleurs Ray afin de partager certaines métadonnées sur les tâches en cours d'exécution. Il est inclus dans le tableau Helm et a le type de volume persistant ReadWriteMany. Dans la section storage vous pouvez ajuster le storageClassName à utiliser pour cela. Assurez-vous que vous utilisez un storageClass qui supporte le type ReadWriteMany.

storage :
  storageClassName : default # Changez pour la bonne storageClass

Montages de volumes

Optionnel

Si certains volumes doivent être montés, les valeurs volumes et volumeMounts peuvent être ajustées pour les définir. Gardez à l'esprit lors de l'utilisation de PV que Ray peut planifier plusieurs pods utilisant ce volume particulier, il devra donc être accessible à partir de plusieurs machines.

Changements supplémentaires pour OpenShift/CRI-O

Certains orchestrateurs ou configurations utilisent CRI-O comme interface d'exécution de conteneur (CRI). Dans OpenShift 4.x, CRI-O fixe actuellement une limite de 1024 processus par défaut. Lors de la mise à l'échelle, cette limite peut facilement être atteinte en utilisant Ray. Nous recommandons de fixer cette limite à environ 8096 processus.&#x20 ;

La documentation Openshift décrit les étapes pour augmenter cette limite ici. Le lien suivant contient plus d'informations sur les paramètres qui peuvent être utilisés dans CRI-O.

Déployer

Une fois que les valeurs ont été définies correctement dans values.yaml sous helm/ray, nous pouvons déployer l'application sur le cluster en utilisant la commande suivante :

helm install ray-cluster ./helm/ray --values values.yaml --namespace syntho

Une fois déployé, nous pouvons trouver le nom du service dans Kubernetes pour l'application Ray. Dans le cas de l'utilisation du nom ray-cluster comme c'est le cas dans la commande ci-dessus, le nom du service (et le nom d'hôte à utiliser dans la variable ray_address pour la section Core API values) est ray-cluster-ray-head.

Enfin, nous pouvons vérifier le pod ray-operator et les pods Ray head ou Ray worker suivants. Lancer kubectl logs deployment/ray-operator -n syntho nous montrera les logs de l'opérateur.