From 2745c2e218dbe9e9f11165f419bc30308ed77163 Mon Sep 17 00:00:00 2001 From: Mickael Asseline Date: Tue, 11 May 2021 07:28:19 +0000 Subject: [PATCH] docs: update Openstack/Ocicli --- Openstack/Ocicli.html | 261 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 257 insertions(+), 4 deletions(-) diff --git a/Openstack/Ocicli.html b/Openstack/Ocicli.html index baadf06..7cd91dc 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-10T16:11:53.268Z +date: 2021-05-11T07:28:17.849Z tags: editor: ckeditor dateCreated: 2021-05-10T11:53:45.764Z @@ -396,9 +396,7 @@ ceph mon enable-msgr2
ocicli cluster-set z --initial-cluster-setup no

Cependant, il est fortement conseillé de définir la valeur sur no une fois que le cluster est en production.

-

Si les 3 contrôleurs de vos clusters exécutent avec succès puppet à - la première startup, ils appelleront "oci-report-puppet-success". Une fois le troisième contrôleur fait, initial-cluster-setup sera automatiquement défini sur - la valeur «no» dans la base de données OCI.

+

Si les 3 contrôleurs de vos clusters exécutent avec succès puppet à la première startup, ils appelleront "oci-report-puppet-success". Une fois le troisième contrôleur fait, initial-cluster-setup sera automatiquement défini sur la valeur «no» dans la base de données OCI.

 

Ajout d'autres types de nœuds

@@ -633,6 +631,261 @@ cat /proc/driver/nvidia/version

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

 

Automatisation avancée

+

Installation entièrement automatisée

+

Lors de la gestion de grands clusters, l'approvisionnement matériel peut prendre une longue partie de votre temps. Il n'y a malheureusement aucun moyen de compresser le temps nécessaire à l'installation physique du matériel, mais OCI est là pour fournir une installation complète sans même avoir à taper une seule ligne de commande.

+

Les nœuds matériels sont d'abord démarrés dans l'environnement Live, leur matériel est ensuite découvert, et s'il correspond à un profil matériel défini (par vous) dans OCI, le serveur peut être entièrement provisionné sans aucune action humaine.

+

Si l'on souhaite automatiser entièrement le provisionnement, voici la liste des directives à définir dans /etc/openstack-cluster-installer/openstack-cluster-installer.conf :

+
[megacli]
+megacli_auto_clear=yes
+megacli_auto_clear=yes
+megacli_auto_clear_num_of_discovery=3
+megacli_auto_apply=yes
+megacli_auto_apply_num_of_discovery=7
+
+[ipmi]
+automatic_ipmi_numbering=yes
+automatic_ipmi_username=ocirox
+
+[dns_plugin]
+call_dns_shell_script=yes
+
+[root_pass_plugin]
+call_root_password_change=yes
+
+[monitoring_plugin]
+call_monitoring_plugin=yes
+
+[auto_provision]
+auto_add_machines_to_cluster=yes
+auto_add_machines_cluster_name=cluster1
+auto_add_machines_num_of_discovery=9
+
+[auto_racking]
+auto_rack_machines_info=yes
+auto_rack_machines_num_of_discovery=7
+
+[auto_install_os]
+auto_install_machines_os=yes
+auto_install_machines_num_of_discovery=15
+

Notez que tout ce qui précède est défini sur no par défaut.

+

Sur ce qui précède, nous pouvons voir quelques directives avec "num_of_discovery". Ce qui se passe, c'est que lorsqu'une machine démarre dans l'image Live OCI, l'openstack-cluster-installer-agent s'exécute en boucle, toutes les 30 secondes (en fait, à tout moment pendant une période de 30 secondes, car le script attend au hasard pour éviter d'envoyer le rapport d'agent de découverte à OCI en même temps ... mais je m'écarte ici ...). Chaque fois que l'agent OCI signale une configuration matérielle pour un serveur, un compteur est incrémenté. C'est notre "num_of_discovery". Comme les valeurs de "num_of_discovery" sont différentes, une liste d'actions s'effectue sur les serveurs nouvellement découverts. Par exemple, avec les valeurs par défaut, voici la planification (voir ci-dessous pour les détails de chaque opération) :

+ +

Notez que les valeurs par défaut de "num_of_discovery" sont correctes, et il n'est pas conseillé de les changer à moins que vous ne soyez vraiment sûr de ce que vous faites. Par exemple, il est normal qu'un cycle de découverte matérielle est laissé entre «l'effacement de la configuration RAID» et «l'application du profil RAID», et la découverte LLDP est laissée après de nombreuses exécutions de l'agent car LLDP peut parfois prendre du temps.

+

Pour réinitialiser le nombre de compteur de découverte:

+
ocicli machine-report-counter-reset SERIAL

 

+

Racking automatique

+

OCI s'appuie sur le protocole LLDP pour découvrir à quel switch un serveur est connecté et utilise ces informations pour indiquer où il se trouve et quoi faire. Vos noms de switch vers les informations de mise en rack sont définis dans un fichier Json statique dans /etc/openstack-cluster-installer/auto-racking.json. C'est fait de cette façon, car on ne s'attend pas à ce que ces données changent avec le temps.

+

Ce fichier contient 3 sections principales:

+ +

Sous les productnames, il n'y a actuellement qu'une description du nombre d'unités de rack dont un serveur a besoin.

+

OCI suppose que chaque serveur de chaque U sera connecté au numéro de port du switch correspondant. Par exemple, le serveur en U-4 sera connecté au port 4 du switch, conformément au LLDP de votre switch.

+

OCI lira ensuite la description des noms de produits pour indiquer le nombre d'unités de rack qu'un serveur prend.

+

OCI suppose également que chacun de vos switch utilisera LLDP pour publier les noms et les ports des commutateurs, et que chaque switch est défini avec un nom d'hôte unique dans vos centres de données.

+

Prenons un exemple. Disons que nous avons un switch numéro 5, dans le rack 3 de la ligne b, dans le Datacenter 2. Prenons le nom d'hôte dc2-b3-5. Nous définirons ensuite dans /etc/openstack-cluster-installer/auto-racking.json :

+
"switchhostnames": {
+    "dc2-b3-5": {
+        "dc": "2",
+        "row": "b",
+        "rack": "3",
+        "location-name": "zone-3",
+        "compute-aggregate": "AZ3"
+    },
+

Ce qui précède indique que tout ce qui est connecté à ce switch sera provisionné dans la zone d'emplacement 3 d'OCI (selon le paramètre d'emplacement "ocicli machine-add"), et s'il s'agit d'un serveur de calcul Nova, il peut être utilisé dans un agrégat nommé AZ3. Cela sera utilisé ci-dessous.

+

Pour pouvoir déboguer, quelques commandes sont disponibles:

+
ocicli machine-guess-racking SERIAL
+

Cela dira où la machine est en rack, étant donné les informations dans le fichier auto-racking.json et les informations LLDP publiées par le commutateur.

+
ocicli machine-auto-rack SERIAL
+

Sert à remplir les informations de mise en rack.

+
ocicli machine-auto-add SERIAL
+

Ajoutera le serveur à l'emplacement défini dans auto-racking.json et avec le rôle défini dans le profil matériel.

 

+

Profils matériels

+

Pour pouvoir prendre des décisions, OCI doit détecter automatiquement le matériel et le faire correspondre à un profil matériel. OCI prend un matériel donné et se compare à la liste des profils. Chaque fois que quelque chose ne correspond pas, un profil matériel est supprimé de la liste. Si l'utilisateur a correctement conçu les profils matériels, à la fin, il ne reste qu'un seul profil. Dans ce cas, le rôle défini dans ce profil peut être utilisé et le profil RAID appliqué à l'aide de MegaCli.

+

Voici un exemple:

+
    "compute-with-var-lib-nova-instance": {
+        "role": "compute",
+        "product-name": [
+            "PowerEdge R640",
+        ],
+        "ram": {
+            "min": 256,
+            "max": 512
+            },
+        "hdd": {
+            "controller": "megacli",
+            "hdd-num-exact-match": "yes",
+            "layout": {
+                "0": {
+                    "raid-type": 1,
+                    "software-raid": "no",
+                    "options": "WB RA Direct",
+                    "size_min": 220,
+                    "size_max": 250,
+                    "num_min": 2,
+                    "num_max": 2
+                },
+                "1": {
+                    "raid-type": 1,
+                    "software-raid": "no",
+                    "options": "WB RA Direct",
+                    "size_min": 800,
+                    "size_max": 1800,
+                    "num_min": 2,
+                    "num_max": 4
+                }
+            }
+        },
+        "machine-set": [ "--use_ceph_if_available no --cpu-mode custom --cpu-model Skylake-Server-IBRS"],
+        "after-puppet-controller-command": [
+            "openstack compute service set --disable %%HOSTNAME%%",
+            "openstack aggregate add host %%COMPUTE_AGGREGATE%% %%HOSTNAME%%",
+            "openstack aggregate add host INTEL_COMPUTE %%HOSTNAME%%"
+            ]
+    },
+

Le profil ci-dessus ne correspondra qu'aux machines avec le nom de produit «PowerEdge R640», avec entre 256 et 512 Go de RAM, un contrôleur RAID LSI, avec exactement 2 disques système de 220 à 250 Go et 2 à 4 disques de données de 800 à 1800 GB. Lorsque le profil RAID est appliqué, il fournira 2 matrices RAID1, une pour le système avec les plus petits disques et une autre plus grande qui sera utilisée plus tard dans /var/lib/nova/instances.

+

Ce qui est dans machine-set sont des commandes ocicli à émettre lorsque le profil matériel est reconnu. Sur l'exemple ci-dessus, nous pouvons voir que nous configurons un modèle de CPU en fonction du profil matériel. Évidemment, on peut définir un autre profil matériel pour "PowerEdge R6525" (c'est une machine AMD) avec un modèle de CPU différent, par exemple.

+

Le contenu de la commande after-puppet-controller-command sera émis une fois que la première exécution de Puppet aura réussi. N'hésitez pas à y ajouter n'importe quelle commande OpenStack, sachant que %% HOSTNAME %% sera remplacé par le FQDN réel du serveur provisionné, et %% COMPUTE_AGGREGATE %% sera remplacé par tout ce qui est défini dans auto-racking.json. Ici, nous utilisons le profil matériel pour définir la machine dans un agrégat INTEL_COMPUTE, car ce cluster possède également des nœuds de calcul AMD. Nous utilisons également %% COMPUTE_AGGREGATE %% pour définir automatiquement la bonne zone de disponibilité.

+

Pour vérifier quel profil matériel correspond à un serveur donné, on peut taper :

+
ocicli machine-guessed-profile SERIAL
+

Il est également possible d'appliquer manuellement un profil RAID avec :

+
ocicli machine-megacli-reset-raid SERIAL
+ocicli machine-megacli-apply SERIAL
+
+

Attention à ne pas faire ce qui précède sur un serveur en production.

+
+

 

+

Plug-in DNS

+

OCI peut appeler votre propre script personnalisé pour publier les noms d'hôte des nœuds dans votre DNS. A vous de l'écrire. Le script sera appelé chaque fois que des serveurs sont ajoutés à un cluster (automatiquement ou manuellement).

+

Pour tester le plugin DNS, il est possible de l'appeler manuellement en utilisant :

+
ocicli machine-to-dns HOSTNAME
+

 

+

Plug-in de mot de passe root

+

Lorsqu'une machine est déclarée comme installée, il est possible de définir automatiquement un mot de passe pour elle. Ce mot de passe peut être enregistré quelque part (par exemple en utilisant hashicorp vault, ou un simple fichier texte), en utilisant le script du plugin.

+

Pour tester le plugin de mot de passe root, une fois qu'une machine est installée, il est possible de l'appeler manuellement en utilisant :

+
ocicli machine-gen-root-pass HOSTNAME
+

 

+

Plugin de supervision

+

OCI ne fournit pas de surveillance, mais si vous avez un tel service, par exemple Zabbix, vous pouvez appeler un script de plugin pour enregistrer les machines dans votre solution de supervision.

+

Pour appeler manuellement le plugin d'enregistrement de surveillance, on peut taper :

+
ocicli machine-to-monitoring HOSTHANE
+

 

+

Gérer le déploiement d'OpenStack

+

Activer la classification cloudkitty

+

Tout d'abord, ajoutez le rôle rating à l'utilisateur cloudkitty :

+
openstack role add --user cloudkitty --project services rating
+

Ensuite, activez le module hashmap :

+
cloudkitty module enable hashmap
+cloudkitty module set priority hashmap 100
+

Notez que l'erreur 503 peut être simplement ignorée, elle fonctionne toujours, comme le montre la liste des modules. Maintenant, ajoutons une note pour les instances :

+
cloudkitty hashmap group create instance_uptime_flavor
+cloudkitty hashmap service create compute
+cloudkitty hashmap field create 96a34245-83ae-406b-9621-c4dcd627fb8e flavor
+

L'ID ci-dessus est celui du service de hashmap create. Ensuite, nous réutilisons l'ID du champ create que nous venons d'avoir pour le paramètre -f, et l'ID de groupe pour le paramètre -g ci-dessous:

+
cloudkitty hashmap mapping create --field-id ce85c041-00a9-4a6a-a25d-9ebf028692b6 --value demo-flavor -t flat -g 2a986ce8-60a3-4f09-911e-c9989d875187 0.03
+

 

+

Création de sondes pour la facturation

+

Dans cet exemple, nous allons présenter que nous voulons facturer n'importe quel port sur un réseau spécifique appelé "ext-net1" qui contient des adresses IP publiques. Pour ce faire, nous avons besoin d'un ceilometer-polling, dans les 3 contrôleurs, pour interroger l'API Neutron toutes les 5 minutes, et demander tous les ports utilisant le réseau "ext-net1". Chaque port associé à un projet OpenStack aura besoin d'un enregistrement personnalisé dans la série chronologique Gnocchi.

+

Donc, tout d'abord, nous devons concevoir notre sondeur (c'est-à-dire: l'élément qui interrogera l'API). Disons que lorsque nous faisons cela:

+
openstack port list --network ext-net1 --long --debug
+

le mode de débogage montre que nous pouvons traduire cela en cette requête curl:

+
curl -g -X GET "https://pub1-api.cloud.infomaniak.ch/network/v2.0/ports?network_id=5a7f5f53-627c-4d0e-be89-39efad5ac54d" \
+	-H "Accept: application/json" -H "User-Agent: openstacksdk/0.50.0 keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.7.3" \
+	-H "X-Auth-Token: "$(openstack token issue --format value -c id) | jq .
+

l'API OpenStack répondant de cette façon:

+
{
+  "ports": [
+    {
+      "id": "c558857c-d010-41ba-8f93-08c3cb876ebe",
+      "name": "",
+      "network_id": "5a7f5f53-627c-4d0e-be89-39efad5ac54d",
+      "tenant_id": "ac4fafd60021431585bbb23470119557",
+      "mac_address": "fa:16:3e:d5:3f:13",
+      "admin_state_up": true,
+      "status": "ACTIVE",
+      "device_id": "0c2b0e8f-0a59-4d81-9545-fd90dc7fee73",
+      "device_owner": "compute:b4",
+      "fixed_ips": [
+        {
+          "subnet_id": "615ddc30-2ed5-4b0a-aba7-acb19b843276",
+          "ip_address": "203.0.113.14"
+        },
+        {
+          "subnet_id": "2c7d6ee4-d317-4749-b6a5-339803ac01f2",
+          "ip_address": "2001:db8:1:1::2e8"
+        }
+      ],
+      "allowed_address_pairs": [],
+      "extra_dhcp_opts": [],
+      "security_groups": [
+        "5d9b69fb-2dae-4ed2-839c-91f645d53eeb",
+        "c901c534-fd90-4738-aa6b-007cd7a5081b"
+      ],
+      "description": "",
+      "binding:vnic_type": "normal",
+      "binding:profile": {},
+      "binding:host_id": "cl1-compute-8.example.com",
+      "binding:vif_type": "ovs",
+      "binding:vif_details": {
+        "connectivity": "l2",
+        "port_filter": true,
+        "ovs_hybrid_plug": true,
+        "datapath_type": "system",
+        "bridge_name": "br-int"
+      },
+      "port_security_enabled": true,
+      "qos_policy_id": null,
+      "qos_network_policy_id": null,
+      "resource_request": null,
+      "ip_allocation": "immediate",
+      "tags": [],
+      "created_at": "2021-02-25T08:57:30Z",
+      "updated_at": "2021-02-25T09:42:47Z",
+      "revision_number": 8,
+      "project_id": "ac4fafd60021431585bbb23470119557"
+    }
+  ]
+}
+

Nous créons ensuite le type de ressource correspondant dans Gnocchi:

+

TODO: ce n'est pas encore clair quoi faire ...

+
gnocchi resource-type create -a status:string:true:max_length=3 -a device_id:uuid:false -a mac_address:string:true:max_length=20  network.ports.ext-net1
+gnocchi resource-type create -a status:string:false:max_length=3 -a mac_address:string:false:max_length=20 public_ip
+gnocchi resource-type create -a cidr:string:false:max_length=4 -a network_id:uuid:false -a description:string:false:max_length=64 public_subnet
+

Dans /etc/openstack-cluster-installer/pollsters.d, nous écrivons simplement un nouveau fichier qui ressemble à ceci:

+
---
+
+- name: "network.ports.ext-net1"
+  sample_type: "gauge"
+  unit: "ip"
+  endpoint_type: "network"
+  url_path: "/network/v2.0/ports?network_id=5a7f5f53-627c-4d0e-be89-39efad5ac54d"
+  value_attribute: "status"
+  response_entries_key: "ports"
+  project_id_attribute: "project_id"
+  value_mapping:
+    ACTIVE: "1"
+  metadata_fields:
+    - "mac_address"
+    - "device_id"
+    - "device_owner"
+    - "fixed_ips"
+    - "binding:vnic_type"
+    - "binding:host_id"
+    - "binding:vif_type"
+    - "created_at"
+    - "updated_at"
+

Le url_path ci-dessus correspond à ce que nous écrivons dans la requête curl. Le response_entries_key est le nom de l'objet de niveau supérieur l'objet json auquel Neutron répond. Ecrire ceci dans /etc/openstack-cluster-installer/pollsters.d/ext-net-ports.yaml est la seule chose nécessaire. OCI écrira automatiquement ce fichier dans /etc/ceilometer/pollsters.d dans les nœuds du contrôleur, et listera ce sondeur dans /etc/ceilometer/polling.yaml.

+