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 :
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
:
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 :
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
:
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 :
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 :
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
.
Montages de volumes
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.  ;
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 :
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.
Last updated