From beb7a5e72b88b2d459a6f169ea8c840ec9ed7dcc Mon Sep 17 00:00:00 2001 From: Mickael Asseline Date: Mon, 10 May 2021 16:11:55 +0000 Subject: [PATCH] docs: update Openstack/Ocicli --- Openstack/Ocicli.html | 184 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 175 insertions(+), 9 deletions(-) diff --git a/Openstack/Ocicli.html b/Openstack/Ocicli.html index 3a45728..baadf06 100644 --- a/Openstack/Ocicli.html +++ b/Openstack/Ocicli.html @@ -2,7 +2,7 @@ title: Ocicli description: Installer un cluster Openstack avec ocicli sous Debian published: true -date: 2021-05-10T15:45:56.658Z +date: 2021-05-10T16:11:53.268Z tags: editor: ckeditor dateCreated: 2021-05-10T11:53:45.764Z @@ -438,8 +438,8 @@ ocicli network-set ipmi --role ipmi --ipmi-match-addr 192.168.100.0 --ipmi-match 
ocicli ipmi-assign-check

Cette commande demandera à OCI de parcourir chaque machine enregistrée dans la base de données et de vérifier l'adresse IPMI détectée. Si cette adresse existe dans la base de données, rien n'est fait. Sinon, un nouvel enregistrement sera ajouté à la base de données pour cette machine, pour éviter un conflit d'adresse ultérieur.

 

-

Mise à niveau automatique du BIOS et du micrologiciel IPMI

-

La mise à niveau du BIOS et du micrologiciel IPMI des serveurs peut prendre beaucoup de temps si vous gérez un grand nombre de serveurs. OCI offre donc la possibilité d'effectuer ces mises à niveau automatiquement. Ceci est contrôlé à l'aide d'un fichier de configuration qui peut être trouvé ici: /etc/openstack-cluster-installer/oci-firmware-upgrade-config.json. Voici un exemple de fichier de configuration valide:

+

MAJ automatique du BIOS et du micrologiciel IPMI

+

La mise à niveau du BIOS et du micrologiciel IPMI des serveurs peut prendre beaucoup de temps si vous gérez un grand nombre de serveurs. OCI offre donc la possibilité d'effectuer ces mises à niveau automatiquement. Ceci est contrôlé à l'aide d'un fichier de configuration qui peut être trouvé ici: /etc/openstack-cluster-installer/oci-firmware-upgrade-config.json. Voici un exemple de fichier de configuration valide:

{
 	"CL2800 Gen10": {
 		"BIOS": {
@@ -452,9 +452,9 @@ ocicli network-set ipmi --role ipmi --ipmi-match-addr 192.168.100.0 --ipmi-match
 			}
 	},
 }
-

Avec ce qui précède, si OCI trouve un serveur HP Cloud Line CL2800 dont le micrologiciel BIOS est inférieur à 2.1.0, il tentera de le mettre à niveau en lançant le script /root/hp-bios-upgrade-2.1.0. Pour ajouter ledit script, l'image en direct doit être personnalisée. Pour ce faire, ajoutez simplement quelques fichiers dans le dossier / etc / openstack-cluster-installer / live-image-additions. Tous les fichiers qui s'y trouvent seront ajoutés à l'image en direct. Ensuite, l'image en direct doit être régénérée:

-
# openstack-cluster-installer-build-live-image
-

Une fois que cela est fait, redémarrez les serveurs qui doivent être mis à niveau. À mesure qu'ils démarrent sur l'image en direct, la mise à niveau sera effectuée. Pour référence, voici un exemple de script hp-bios-upgrade-2.1.0, qui sera sauvegardé ici: /etc/openstack-cluster-installer/live-image-additions/root/hp-bios-upgrade-2.1.0 .

+

Avec ce qui précède, si OCI trouve un serveur HP Cloud Line CL2800 dont le micrologiciel BIOS est inférieur à 2.1.0, il tentera de le mettre à niveau en lançant le script /root/hp-bios-upgrade-2.1.0. Pour ajouter ledit script, l'image live doit être personnalisée. Pour ce faire, ajoutez simplement quelques fichiers dans le dossier /etc/openstack-cluster-installer/live-image-additions. Tous les fichiers qui s'y trouvent seront ajoutés à l'image live. Ensuite, l'image live doit être régénérée :

+
openstack-cluster-installer-build-live-image
+

Une fois que cela est fait, redémarrez les serveurs qui doivent être mis à jour. À mesure qu'ils démarrent sur l'image live, la mise à jour sera effectuée. Pour référence, voici un exemple de script hp-bios-upgrade-2.1.0, qui sera sauvegardé ici: /etc/openstack-cluster-installer/live-image-additions/root/hp-bios-upgrade-2.1.0.

#!/bin/sh
 
 set -e
@@ -466,7 +466,173 @@ cd CL2600_CL2800_Gen10_BIOS_v2.1.0_11052019_Linux/FlashTool/
 ./flash_bios.sh
 reboot
 sleep 20000
-

Le "sleep 20000" permet de s'assurer que l'agent OCI ne redémarre pas avant le redémarrage de la machine. YMMV en fonction de la mise à niveau à effectuer.

-

 

-

 

+

Le "sleep 20000" permet de s'assurer que l'agent OCI ne redémarre pas avant le redémarrage de la machine. Cela dépend de la mise à jour à effectuer.

+

 

+

Personnalisation du /etc/hosts de tout votre cluster

+

Il est possible d'ajouter des entrées sur tous les /etc/hosts des clusters, si vous ajoutez des entrées à ce fichier sur le serveur OCI:

+

/etc/openstack-cluster-installer/hosts_append

+

Tout ce que génère OCI se trouve entre ces balises:

+
# OCISTA_MAINTAINED: Do not touch between these lines, this is a generated content.
+... some generated content ...
+# OCIFIN_MAINTAINED: Do not touch between these lines, this is a generated content.
+

Ensuite, il est possible d'ajouter manuellement des entrées à chaque /etc/hosts après la balise ci-dessus, et ces entrées seront conservées.

+

 

+

Personnalisation de l'ENC

+

Dans /etc/openstack-cluster-installer/hiera, vous trouverez 2 dossiers et un fichier all.yaml. Celles-ci doivent permettre de personnaliser la sortie de l'ENC de l'OCI. Par exemple, si vous mettez:

+
   ntp:
+      servers:
+         - 0.us.pool.ntp.org iburst
+

dans /etc/openstack-cluster-installer/hiera/all.yaml, alors tous les nœuds seront configurés avec ntp en utilisant 0.us.pool.ntp.org pour synchroniser l'heure.

+

Si nous avons un cluster swift01, la structure complète des dossiers est la suivante:

+
/etc/openstack-cluster-installer/hiera/roles/controller.yaml
+/etc/openstack-cluster-installer/hiera/roles/swiftproxy.yaml
+/etc/openstack-cluster-installer/hiera/roles/swiftstore.yaml
+/etc/openstack-cluster-installer/hiera/nodes/-hostname-of-your-node-.yaml
+/etc/openstack-cluster-installer/hiera/all.yaml
+/etc/openstack-cluster-installer/hiera/clusters/swift01/roles/controller.yaml
+/etc/openstack-cluster-installer/hiera/clusters/swift01/roles/swiftproxy.yaml
+/etc/openstack-cluster-installer/hiera/clusters/swift01/roles/swiftstore.yaml
+/etc/openstack-cluster-installer/hiera/clusters/swift01/nodes/-hostname-of-your-node-.yaml
+/etc/openstack-cluster-installer/hiera/clusters/swift01/all.yaml
+

 

+

Personnalisation du serveur installé au moment de la configuration

+

Parfois, il est souhaitable de configurer un serveur au moment de l'installation. Par exemple, il peut être nécessaire de configurer le routage (à l'aide de BGP) pour que l'adresse IP virtuelle soit disponible au moment de la configuration. OCI offre tout ce qui est nécessaire pour enrichir la configuration du serveur au moment de l'installation, avant même que l'agent Puppet ne démarre.

+

Supposons que vous souhaitiez configurer swift01-controller-1 dans votre cluster swift01, y ajouter quagga et ajouter des fichiers de configuration. Créez simplement le dossier, remplissez-y le contenu et ajoutez un fichier oci-packages-list :

+
mkdir -p /var/lib/oci/clusters/swift01/swift01-controller-1.example.com/oci-in-target
+cd /var/lib/oci/clusters/swift01/swift01-controller-1.example.com
+echo -n "quagga,tmux" >oci-packages-list
+mkdir -p oci-in-target/etc/quagga
+echo "some conf" >oci-in-target/etc/quagga/bgpd.conf
+

Lorsque OCI provisionne le serveur baremetal, il vérifie si le fichier oci-packages-list existe. Si tel est le cas, les packages sont ajoutés lors de l'installation. Ensuite, le contenu oci-in-target est copié dans le système cible.

+

 

+

Utilisation d'un BGP VIP

+

De la même manière, vous pouvez par exemple décider d'avoir le VIP de vos contrôleurs pour utiliser le routage BGP. Pour ce faire, écrivez dans /etc/openstack-cluster-installer/roles/controller.yaml :

+
   quagga::bgpd:
+      my_asn: 64496,
+      router_id: 192.0.2.1
+      networks4:
+         - '192.0.2.0/24'
+      peers:
+         64497:
+            addr4:
+               - '192.0.2.2'
+            desc: TEST Network
+

Cependant, vous souhaiterez peut-être le faire uniquement pour un nœud spécifique d'un seul cluster de serveurs, plutôt que pour tous. Dans ce cas, utilisez simplement ce schéma de chemin de fichier : /etc/openstack-cluster-installer/clusters/cloud1/nodes/cloud1-controller-1.example.com.yaml

+

Pour tous les contrôleurs du cluster cloud1, utilisez : /etc/openstack-cluster-installer/clusters/cloud1/roles/controller.yaml

+

 

+

Faire un test dans les manifestes OCI à des fins de débogage

+

Si vous souhaitez tester un changement dans les fichiers de marionnettes de l'OCI, éditez-les dans /usr/share/puppet/modules/oci, puis sur le master run, par exemple :

+
puppet master --compile swift01-controller-1.example.com
+/etc/init.d/puppet-master stop
+/etc/init.d/puppet-master start
+

puis sur swift01-controller-1.example.com vous pouvez exécuter :

+
OS_CACERT=/etc/ssl/certs/oci-pki-oci-ca-chain.pem puppet agent --test --debug
+

 

+

Personnalisation des fichiers et des packages de vos serveurs

+

Si vous souhaitez personnaliser le contenu des fichiers de vos hôtes, écrivez simplement n'importe quel fichier, par exemple :

+
/var/lib/oci/clusters/swift01/swift01-controller-1.example.com/oci-in-target
+

et il sera copié sur le serveur que vous installerez.

+

De la même manière, vous pouvez ajouter des packages supplémentaires à votre serveur en ajoutant leurs noms dans ce fichier :

+
/var/lib/oci/clusters/swift01/swift01-controller-1.example.com/oci-packages-list
+

Les packages doivent être répertoriés sur une seule ligne, séparés par des virgules. Par exemple :

+
quagga,bind
+

Activer Hiera pour l'environnement

+

Si vous devez activer Hiera, vous pouvez le faire de cette façon :

+
mkdir -p /etc/puppet/code/environments/production/manifests/
+echo "hiera_include('classes')" > /etc/puppet/code/environments/production/manifests/site.pp
+cat /etc/puppet/code/hiera/common.yaml
+---
+classes:
+  - xxx
+...
+

 

+

Une fois le déploiement prêt

+

Il y a actuellement quelques problèmes qui doivent être résolus manuellement. Espérons que tous ces éléments seront automatisés dans un proche avenir. En attendant, veuillez contribuer aux correctifs si vous découvrez comment, ou procédez simplement comme indiqué ci-dessous.

+

 

+

Réparation des contrôleurs

+

Malheureusement, parfois, il y a des problèmes de planification dans Puppet. Si cela se produit, on peut essayer de relancer Puppet :

+
OS_CACERT=/etc/ssl/certs/oci-pki-oci-ca-chain.pem puppet agent --test --debug 2>&1 | tee /var/log/puppet-run-1
+

Faites-le d'abord sur le nœud du contrôleur 1, attendez qu'il se termine, puis redémarrez-le sur les autres nœuds de contrôleur.

+

 

+

Ajout de règles de pare-feu personnalisées

+

OCI utilise puppet-module-puppetlabs-firewall et vide les iptables à chaque exécution. Par conséquent, si vous avez besoin de règles de pare-feu personnalisées, vous devez également le faire via Puppet. Si vous souhaitez appliquer les mêmes règles de pare-feu sur tous les nœuds, modifiez simplement site.pp comme ceci dans /etc/puppet/code/environments/production/manifests/site.pp :

+
hiera_include('classes')
+
+firewall { '000 allow monitoring network':
+  proto       => tcp,
+  action      => accept,
+  source      => "10.3.50.0/24",
+}
+

Notez que la règle de pare-feu est précédée d'un nombre. Ceci est obligatoire. Assurez-vous également que ce numéro n'entre pas en conflit avec une règle déjà existante.

+

Ce que fait OCI, c'est : protéger le VIP du contrôleur (lui refuser l'accès de l'extérieur) et protéger les ports swiftstore pour les serveurs de comptes, de conteneurs et d'objets contre toute requête ne provenant pas du cluster. Ainsi, ce qui précède permettra à un serveur de surveillance à partir de 10.3.50.0/24 de surveiller votre swiftstore.

+

Si vous souhaitez appliquer ce qui précède uniquement à un nœud spécifique, il est possible de le faire en ne faisant correspondre que certains noms d'hôte. Voici un exemple simple, avec une adresse IP différente autorisée en fonction des rôles de la machine :

+
hiera_include('classes')
+
+node /^z-controller.*/ {
+  firewall { '000 allow monitoring network':
+    proto       => tcp,
+    action      => accept,
+    source      => "10.1.2.0/24",
+  }
+}
+
+node default {
+  firewall { '000 allow monitoring network':
+    proto       => tcp,
+    action      => accept,
+    source      => "10.3.4.0/24",
+  }
+}
+

 

+

Ajout de nœuds de calcul

+

Avec la dernière version d'OCI, ceci est effectué automatiquement : après qu'un nœud de calcul exécute puppet avec succès, il appelle oci-report-puppet-success, qui contacte le nœud d'approvisionnement, qui à son tour ssh à l'un des contrôleurs pour exécuter "nova -manage cell_v2 Discover_hosts ". Donc, ce qui suit n'est nécessaire que si le nœud de calcul ne s'est pas installé correctement directement.

+

Pour ajouter le nœud de calcul au cluster et vérifier qu'il est là, sur le contrôleur, procédez comme suit:

+
 . oci-openrc
+ su nova -s /bin/sh -c "nova-manage cell_v2 discover_hosts"
+ openstack hypervisor list
+	+----+-------------------------------+-----------------+---------------+-------+
+	| ID | Hypervisor Hostname           | Hypervisor Type | Host IP       | State |
+	+----+-------------------------------+-----------------+---------------+-------+
+	|  4 | swift01-compute-1.example.com | QEMU            | 192.168.103.7 | up    |
+	+----+-------------------------------+-----------------+---------------+-------+
+

Il n'y a rien de plus ... :)

+

 

+

Ajout de la prise en charge du GPU dans un nœud de calcul

+

Actuellement, seuls les cartes Nvidia sont prises en charge. Tout d'abord, localisez votre GPU dans votre hôte de calcul. Voici un exemple avec une carte Nvidia T4 :

+
lspci -nn | grep -i nvidia
+	5e:00.0 3D controller [0302]: NVIDIA Corporation TU104GL [Tesla T4] [10de:1eb8] (rev a1)
+

Lorsque vous avez cela, entrez-le simplement avec ocicli :

+
ocicli machine-set 1CJ9FV2 --use-gpu yes --gpu-vendor-id 10de --gpu-produc-id 1eb8 --gpu-name nvidia-t4 --gpu-device-type type-PF --vfio-ids 10de:1eb8+10de:0fb9
+

Veuillez noter que les identifiants dans --vfio-ids doivent être séparés par + et non par une virgule (la conversion est effectuée plus tard par OCI et Puppet).

+

De plus, le type de périphérique --gpu dépend du type de carte GPU et du micrologiciel que vous utilisez. Par exemple, les anciens micrologiciels Nvidia T4 nécessitent le type-PCI, tandis que les nouveaux micrologiciels nécessitent le type-PF. Si vous faites une erreur ici, le nova-scheduler ne saura pas où créer une VM et retournera "no valid host".

+

Cela remplira /etc/modprobe.d/blacklist-nvidia.conf pour mettre sur liste noire le pilote Nvidia et quelques autres, /etc/modules-load.d/vfio.conf pour charger le module vfio-pci, et /etc/modprobe.d/vfio.conf avec ce contenu (pour permettre d'exposer des appareils aux invités):

+
options vfio-pci ids=10de:1eb8,10de:0fb9
+

Le fichier /etc/default/grub doit ensuite être modifié à la main pour ajouter ceci (manuellement) :

+
intel_iommu=on
+

Redémarrez la machine de calcul, appliquez Puppet à la fois sur le nœud de calcul et sur les contrôleurs.

+

Maintenant, créons l'image Glance et Nova pour utiliser ce nouveau GPU et démarrer l'instance:

+
openstack image set bionic-server-cloudimg-amd64_20190726_GPU --property img_hide_hypervisor_id='true'
+openstack flavor create --ram 6144 --disk 20 --vcpus 2 cpu2-ram6-disk20-gpu-nvidia-t4
+openstack flavor set cpu6-ram20-disk20-gpu-t4 --property pci_passthrough:alias=nvidia-t4:1
+openstack server create --image bionic-server-cloudimg-amd64_20190726_GPU --nic net-id=demo-net --key-name demo-keypair --flavor cpu6-ram20-disk20-gpu-nvidia-t4 my-instance-with-gpu
+

Dans l'instance, nous pouvons utiliser Cuda et le vérifier:

+
wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/cuda-repo-ubuntu1804_10.1.168-1_amd64.deb
+apt-get update
+apt-get install cuda cuda-toolkit-10-1  nvidia-cuda-toolkit
+cat /proc/driver/nvidia/version
+	NVRM version: NVIDIA UNIX x86_64 Kernel Module  430.26  Tue Jun  4 17:40:52 CDT 2019
+	GCC version:  gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
+

 

+

Plusieurs backends Cinder LVM

+

Si vous utilisez plusieurs types de backend LVM (par exemple, SSD et HDD), il peut être utile de sélectionner le nom du backend lors de la configuration d'un nouveau nœud de volume. Ceci est fait de cette façon:

+
ocicli machine-set 1CJ9FV2 --lvm-backend-name HDD_1
+

Vous pouvez également avoir plusieurs backends sur un seul serveur. Dans ce cas, il est possible d'utiliser un seul backend par lecteur, au lieu de tous les utiliser sur un seul VG. Pour ce faire, faites quelque chose comme ceci:

+
ocicli machine set 5KC2J63 --cinder-separate-volume-groups yes --cinder-enabled-backends LVM_SDA:LVM_SDB:LVM_SDC
+

Cela configurera de nouveaux types de volume LVM_SDA, LVM_SDB et LVM_SDC. Pour revenir à la manière normale (c'est-à-dire: un gros VG), il est possible de remettre la valeur de non-remplacement:

+
ocicli machine-set 5KC2J63 no-override
+

Attention cependant, OCI ne fera ce qu'il faut qu'une seule fois, lors du provisionnement du système.

+

 

+

Automatisation avancée

+

 

+