Mise à niveau de CycleCloud

Il est possible de mettre à niveau l’application Azure CycleCloud en place au fur et à mesure que de nouvelles versions deviennent disponibles.

CycleCloud 8

CycleCloud 8 a un nom cyclecloud8 de package différent afin d’empêcher la mise à niveau accidentelle d’une version majeure vers la suivante. Il existe des modifications incompatibles entre les versions principales. Il se peut qu’il ne soit pas possible d’installer à la fois cyclecloud et cyclecloud8 sur le même ordinateur.

Le chemin d’accès à la mise à niveau pris en charge consiste à supprimer le cyclecloud package et à installer cyclecloud8. Vos répertoires de données et de configuration sont /opt/cycle_server conservés lors de la suppression du cyclecloud package. Lors de l’installation cyclecloud8, les scripts d’installation détectent les données existantes et la configuration, puis s’exécutent automatiquement via toutes les migrations de mise à niveau.

Mise à niveau sur Debian ou Ubuntu

Suivez les instructions de l’installation sur Debian ou Ubuntu pour configurer le référentiel Microsoft apt (s’il n’a pas déjà été effectué lors de l’installation).

Pour effectuer une mise à niveau indirecte prise en charge de CycleCloud 7 vers CycleCloud 8 :

sudo apt update
sudo apt -y remove cyclecloud
sudo apt -y install cyclecloud8

Pour effectuer une mise à niveau directe d’une version de CycleCloud 8 vers une version plus récente :

sudo apt update
sudo apt -y upgrade cyclecloud8

Mise à niveau sur les clones RHEL (Enterprise Linux)

Suivez les instructions de l’installation sur les clones RHEL (Enterprise Linux) pour configurer le référentiel yum Microsoft (s’il n’a pas déjà été effectué lors de l’installation).

Pour effectuer une mise à niveau indirecte prise en charge de CycleCloud 7 vers CycleCloud 8 :

sudo yum -y remove cyclecloud
sudo yum -y install cyclecloud8

Pour effectuer une mise à niveau directe d’une version de CycleCloud 8 vers une version plus récente :

sudo yum -y upgrade cyclecloud8

Important

La mise à niveau peut avoir des conséquences non souhaitées sur votre environnement CycleCloud et sur tous les clusters en cours d’exécution. Microsoft recommande de tester toutes les mises à niveau dans un environnement de développement ou de préproduction pour réduire les risques liés aux charges de travail de production.

Questions courantes sur la mise à niveau

Mes anciens modèles seront-ils compatibles avec cette nouvelle version ?

Les modèles doivent être compatibles pour les mises à niveau de version mineures. Les mises à niveau entre les versions principales peuvent nécessiter que vous épinglez des clusters à l’ancienne version pour laquelle vos modèles sont conçus.

Existe-t-il un temps d’arrêt associé à la mise à niveau ?

CycleCloud sera en panne pendant un certain temps que la mise à niveau se produit. La mise à niveau prend généralement 2 à 3 minutes.

Puis-je effectuer une mise à niveau pendant l’exécution des clusters ?

Oui, mais les clusters ne pourront pas communiquer avec CycleCloud alors qu’ils sont en panne. Cela signifie que la mise à l’échelle automatique, les demandes d’arrêt, etc. ne fonctionnera pas tant que la mise à niveau n’est pas terminée.

Migrer CycleCloud vers un nouvel hôte

La première installation de CycleCloud configure l’utilisateur de service et la configuration de démarrage. Celles-ci seront absentes si les données d’installation sont simplement copiées de l’hôte à l’hôte. Les instructions suivantes décrivent comment migrer une installation CycleCloud vers un autre hôte.

Remarque sur les clusters en cours d’exécution

Les clusters gérés par CycleCloud envoient des informations à CycleCloud via HTTPS et AMQP. Les informations d’accès pour configurer ces protocoles de communication sont reçues par les nœuds au moment du lancement. Par conséquent, si le nom d’hôte ou l’adresse IP de CycleCloud change pendant que les nœuds s’exécutent, la communication peut être interrompue. Il est recommandé de mettre fin à tous les clusters avant de migrer.

Une exception à ceci est les nœuds configurés avec IsReturnProxy = true. Dans ce cas, les canaux de communication sont lancés sortants de CycleCloud et seront automatiquement recréé après la migration.

Pour migrer un hôte CycleCloud :

1. Arrêter cycle_server sur l’hôte source : service cycle_server stop (scripts init LSB) ou systemctl stop cycle_server (init systemd )
2. Exécutez groupadd cycle_server et useradd cycle_server sur l’hôte cible. Utilisez le GID d’origine et l’UID si possible.
3. Installer openjdk version 8 sur l’hôte cible en cours d’exécution apt-get -y install openjdk-8-jre-headless ou yum install -y java-1.8.0-openjdk
4. Transférer vers l’hôte cible à l’aide rsync -a /opt/cycle_server username@remote_host:/opt/cycle_server d’un autre outil de transfert de conservation des métadonnées.
5. Activer l’init LSB ou systemd init for CycleCloud en exécutant /opt/cycle_server/util/autostart.sh on
6. Démarrer le service CycleCloud avec l’un service cycle_server start ou l’autre systemctl start cycle_server

Les instructions peuvent être simplifiées si, au lieu de migrer vers un nouvel hôte, la migration d’installation provient d’un répertoire non standard vers /opt/cycle_server :

1. Arrêter cycle_server sur l’hôte source : service cycle_server stop (scripts init LSB) ou systemctl stop cycle_server (init systemd )
2. Transférer vers l’emplacement rsync -a /usr/share/hpc/cycle_server /opt/cycle_serverpar défaut .
3. Activer l’init LSB ou systemd init for CycleCloud en exécutant /opt/cycle_server/util/autostart.sh on
4. Démarrer le service CycleCloud avec l’un service cycle_server start ou l’autre systemctl start cycle_server

Après la migration vers un nouvel hôte ou la migration vers le répertoire d’installation par défaut, les mises à niveau peuvent être effectuées comme décrit dans la première section.