Albirew/Wiki-Tech.io
Albirew/Wiki-Tech.io
1
0
Bifurcation 0
miroir de https://github.com/PAPAMICA/Wiki-Tech.io.git synchronisé 2024-11-07 18:20:33 +01:00
Code Tickets Publications Activité
Wiki-Tech.io/Openstack/Ocicli.html
Mickael Asseline 207fe1fb04 docs: update Openstack/Ocicli
2021-05-10 15:40:08 +00:00

441 lignes
42 Kio
HTML
Brut Annotations Historique

<!--
title: Ocicli
description: Installer un cluster Openstack avec ocicli sous Debian
published: true
date: 2021-05-10T15:40:06.844Z
tags:
editor: ckeditor
dateCreated: 2021-05-10T11:53:45.764Z
-->
<figure class="image image_resized" style="width:28.86%;"><img src="https://upload.wikimedia.org/wikipedia/commons/thumb/e/e6/OpenStack%C2%AE_Logo_2016.svg/1200px-OpenStack%C2%AE_Logo_2016.svg.png" alt="OpenStack — Wikipédia"></figure>
<h1>Présentation</h1>
<p>OCI (OpenStack Cluster Installer) est un logiciel permettant de provisionner automatiquement des clusters OpenStack. Ce package installe une machine d'approvisionnement, qui utilise les composants ci-dessous:</p>
<ul>
<li>un serveur DHCP (isc-dhcp-server)</li>
<li>un serveur de démarrage PXE (tftp-hpa)</li>
<li>un serveur web (apache2)</li>
<li>un serveur Puppet</li>
</ul>
<p>Lors du premier des machines du cluster, un système Debian live est proposé en PXE par OCI, pour agir comme une image de découverte. Ce système remonte directement les caractéristiques matérielles à OCI. Les machines peuvent alors être installés avec Debian à partir de ce système, configurés avec un agent Puppet &nbsp;qui se connectera au master Puppet de OCI. Une fois Debian installé, le serveur redémarre et les services OpenStack sont provisionnés, en fonction du rôle du serveur dans le cluster.</p>
<p>OCI est entièrement intégré à Debian, y compris tous les modules Puppet. Après avoir installé le package OCI et ses dépendances, aucun autre soft n'est necessaire pour l'installation du cluster, ce qui signifie que si un miroir Debian local est disponible, l'installation du cluster OpenStack peut être effectuée complètement hors ligne.</p>
<p>&nbsp;</p>
<h2>Les services OpenStack installés</h2>
<p>Actuellement, OCI peut installer:</p>
<ul>
<li>Swift (avec des nœuds proxy dédiés en option)</li>
<li>Keystone</li>
<li>Cinder (backend LVM ou Ceph)</li>
<li>Glance (backend File, Swift ou Ceph, Swift peut être externalisé)</li>
<li>Heat</li>
<li>Horizon</li>
<li>Nova (avec prise en charge du GPU)</li>
<li>Neutron</li>
<li>Barbican</li>
<li>Octavia</li>
<li>Telemetry (Ceilometer, Gnocchi, Panko, Aodh)</li>
<li>Cloudkitty</li>
</ul>
<p>Des efforts sont actuellement en cours pour intégrer:</p>
<ul>
<li>Magnum</li>
<li>Designate</li>
</ul>
<p>De plus, OCI prend désormais en charge l'exécution de CephOSD sur les nœuds de calcul (ce que l'on appelle «hyper-converged») en tant qu'option pour chaque nœud de calcul. (compute nodes)&nbsp;</p>
<p>Tout cela avec de la haute disponibilité, en utilisant haproxy et corosync sur les nœuds de contrôleur pour tous les services.</p>
<p>Tous les services utilisent uniquement TLS, même au sein du cluster.</p>
<p>En règle générale, OCI vérifie quel type de nœuds fait partie du cluster et prend des décisions en fonction de celui-ci. Par exemple, s'il existe des nœuds OSD Ceph, OCI utilisera Ceph comme backend pour la sauvegarde Glance, Nova et Cinder. S'il y a des nœuds Cinder Volume, OCI les utilisera avec le backend LVM. S'il existe des nœuds Swiftstore, Swift sera utilisé pour les sauvegardes et les images Glance. S'il existe des nœuds Ceph OSD, mais pas de nœuds Ceph MON dédiés, les contrôleurs agiront comme des moniteurs Ceph. S'il existe des nœuds de calcul, Cinder, Nova et Neutron seront installés sur les nœuds de contrôleur. Etc…</p>
<p>Le nombre minimum de nœuds de contrôleur est de 3, bien qu'il soit possible, avec un peu de bidouille d'installer les 3 contrôleurs sur des machines virtuelles sur un seul serveur (bien sûr, perdre la fonctionnalité de haute disponibilité en cas de panne du matériel).</p>
<p>&nbsp;</p>
<h2>Qui est derrière ce projet ?</h2>
<p>OCI a été entièrement écrit par Thomas Goirand (zigo). Le travail est entièrement sponsorisé par Infomaniak Networks, qui l'utilise en production dans des clusters raisonnablement grands. Il y a eu quelques contributions sporadiques au sein d'Infomaniak, ainsi que quelques correctifs de contributeurs externes, mais aucune fonctionnalité majeure (pour le moment). Espérons que ce projet, au fil du temps, rassemblera plus de contributeurs.</p>
<p>&nbsp;</p>
<h2>Présentation vidéo</h2>
<p>Si vous souhaitez avoir une présentation rapide de ce que l'OCI peut faire, pour voir si cela répond à vos besoins, vous pouvez regarder la présentation faite pour le sommet OpenStack en novembre 2020. Ce n'est pas long (19 minutes) : <a href="https://www.youtube.com/watch?v=Q25jT2fYDjc">Youtube</a>&nbsp;</p>
<figure class="media">
<oembed url="https://www.youtube.com/watch?v=Q25jT2fYDjc"></oembed>
</figure>
<p>&nbsp;</p>
<h1>Installation</h1>
<h2>Exigences minimales</h2>
<p>OCI lui-même fonctionnera bien avec environ 20 Go de disque dur et quelques Go de RAM. Cependant, pour installer OpenStack, vous aurez besoin d'au moins 3 contrôleurs avec un minimum de 16 Go de RAM, 32 Go sont recommandés et le mieux est de 64 Go de RAM. Si vous voulez Ceph, un minimum de 3 Ceph OSD est nécessaire, cependant, nous ne parlons que lorsque votre cluster atteint 100 disques. La recommandation Ceph est qu'un serveur donné ne supprime pas plus de 10% de la capacité totale. Donc, 10 serveurs OSD au début, c'est bien. En ce qui concerne Swift, le nombre minimum de serveurs serait de 3, mais si l'un d'entre eux échoue, vous obtiendrez des délais d'attente. Il est donc probablement préférable de commencer avec au moins 6 nœuds de stockage Swift, et peut-être avec 2 proxies. Pour les autres ressources, c'est à vous de choisir : quelques compute nodes (nœuds de calcul), et probablement 2 nœuds de réseau et quelques nœuds de volume.</p>
<p>Si vous avez l'intention d'exécuter le package openstack-cluster-installer-poc pour faire du développement ou du test OCI dans un environnement virtualisé, nous vous recommandons un serveur unique avec 1 To de disque dur et 256 Go de RAM. Cette configuration est suffisante pour provisionner 19 VM sur lesquelles OpenStack sera installé. Il est possible de fonctionner avec moins, mais alors peu de nœuds seront disponibles, et vous devrez ajuster le nombre de serveurs dans <code>/etc/oci-poc/oci-poc.conf</code>.</p>
<p>&nbsp;</p>
<h2>Installation du paquet</h2>
<h3>Le dépôt du paquet</h3>
<p>Le paquet est soit disponible depuis Debian Sid / Buster, soit depuis les référentiels de backport stables d'OpenStack.</p>
<h3>Utilisation d'Extrepo</h3>
<p>La nouvelle (meilleure) façon d'utiliser les backports Debian Stable d'OpenStack est d'utiliser extrepo. Extrepo est disponible dans les buster-backports officiels. Voici comment installer OpenStack, par exemple (vous avez besoin du dépôt buster-backports dans votre <code>sources.list</code>) :</p>
<pre><code class="language-plaintext">apt-get install extrepo
extrepo enable openstack_wallaby
apt-get update
</code></pre>
<p>Consultez la documentation d'extrepo pour en savoir plus.</p>
<p>&nbsp;</p>
<h3>Configuration manuelle des dépôts Debian</h3>
<p>Si vous souhaitez utiliser Buster avec OpenStack Train, les dépôts ci-dessous doivent être ajoutés au fichier <code>sources.list</code> :</p>
<pre><code class="language-plaintext">deb http://buster-train.debian.net/debian buster-train-backports main
deb-src http://buster-train.debian.net/debian buster-train-backports main
deb http://buster-train.debian.net/debian buster-train-backports-nochange main
deb-src http://buster-train.debian.net/debian buster-train-backports-nochange main
</code></pre>
<p>Vous pouvez remplacer buster ci-dessus par n'importe quelle distribution stable Debian (au moment de l'écriture, seuls Stretch et Buster sont pris en charge), et pareil pour le nom de la version OpenStack du jour.</p>
<p>La clé du dépôt est disponible de cette façon :</p>
<pre><code class="language-plaintext">apt-get update
apt-get install --allow-unauthenticated -y openstack-backports-archive-keyring
apt-get update
</code></pre>
<p>Il existe également un miroir contenant TOUTES les versions d'OpenStack en un seul endroit : <a href="http://osbpo.debian.net/debian/">http://osbpo.debian.net/debian/</a></p>
<p>&nbsp;</p>
<h3>Installer le paquet</h3>
<p>Installez simplement <code>openstack-cluster-installer</code> avec :</p>
<pre><code class="language-plaintext">apt-get install openstack-cluster-installer</code></pre>
<p>&nbsp;</p>
<h3>Installer un serveur de base de données</h3>
<p>Pour MariaDB :</p>
<pre><code class="language-plaintext">apt-get install mariadb-server dbconfig-common</code></pre>
<p>Il est possible de créer la base de données et les informations d'identification à la main, ou de laisser OCI le gérer automatiquement avec <code>dbconfig-common</code>. Si APT s'exécute en mode non interactif, ou si pendant l'installation, l'utilisateur ne demande pas la gestion automatique de la base de données par <code>dbconfig-common</code>, voici comment créer la base de données :&nbsp;</p>
<pre><code class="language-plaintext">apt-get install openstack-pkg-tools
. /usr/share/openstack-pkg-tools/pkgos_func
PASSWORD=$(openssl rand -hex 16)
pkgos_inifile set /etc/openstack-cluster-installer/openstack-cluster-installer.conf database connection mysql+pymysql://oci:${PASSWORD}@localhost:3306/oci"
mysql --execute 'CREATE DATABASE oci;'
mysql --execute "GRANT ALL PRIVILEGES ON oci.* TO 'oci'@'localhost' IDENTIFIED BY '${PASSWORD}';"
</code></pre>
<p>Il faut alors s'assurer que la directive "<code>connection</code>" dans <code>/etc/openstack-cluster-installer/openstack-cluster-installer.conf</code> ne contient pas d'espaces avant et après le signe égal.</p>
<p>&nbsp;</p>
<h3>Configurer OCI</h3>
<p>Assurez-vous que la base de données est synchronisée (si c'est le cas, vous verrez que'il y a des erreurs dans le tableau) :</p>
<pre><code class="language-plaintext">apt-get install -y php-cli
cd /usr/share/openstack-cluster-installer ; php db_sync.php
</code></pre>
<p>Puis éditez <code>/etc/openstack-cluster-installer/openstack-cluster-installer.conf</code> et configurer les options comme vous le souhaitez (par exemple: changer les valeurs du réseau, etc.).</p>
<p>&nbsp;</p>
<h3>Générer l'autorité de certification racine d'OCI</h3>
<p>Pour supporter TLS, OCI utilise sa propre autorité de certification racine. Le certificat d'autorité de certification racine est distribué sur tous les nœuds du cluster. Pour créer l'autorité de certification racine initiale, il existe un script pour tout faire :</p>
<pre><code class="language-plaintext">oci-root-ca-gen</code></pre>
<p>À ce stade, vous devriez pouvoir naviguer dans l'interface Web d'OCI : <code>http://your-ip-address/oci/</code></p>
<p>Cependant, vous avez besoin d'un login / pass pour entrer. Il y a un utilitaire shell pour gérer vos noms d'utilisateur. Pour ajouter un nouvel utilisateur, procédez comme suit :</p>
<pre><code class="language-plaintext">oci-userdb -a mylogin mypassword</code></pre>
<p>Les mots de passe sont hachés en utilisant la fonction PHP <code>password_hash () </code>en utilisant l'algo BCRYPT.</p>
<p>De plus, OCI est capable d'utiliser un Radius externe pour son authentification. Cependant, vous devez toujours ajouter manuellement des connexions dans la base de données. Ce qui est ci-dessous insère un nouvel utilisateur qui a une entrée dans le serveur Radius :</p>
<pre><code class="language-plaintext">oci-userdb -r newuser@example.com</code></pre>
<p>&nbsp;</p>
<blockquote>
<p>&nbsp;Vous devez également configurer votre adresse de serveur Radius et votre secret partagé dans <code>openstack-cluster-installer.conf</code>.</p>
</blockquote>
<blockquote>
<p>Même s'il existe un système d'authentification, il est fortement conseillé de ne pas exposer OCI à Internet. La meilleure configuration est si votre serveur d'approvisionnement n'est pas du tout accessible de l'extérieur.</p>
</blockquote>
<p>&nbsp;</p>
<h2>Installation des services annexes</h2>
<h3>ISC-DHCPD</h3>
<p>Configurez <code>isc-dhcp</code> pour qu'il corresponde à votre configuration réseau. Notez que "<code>next-server</code>" doit être l'adresse de votre nœud master Puppet (c'est-à-dire : le serveur DHCP que nous sommes en train de configurer).</p>
<p>Modifiez <code>/etc/default/isc-dhcpd</code> :</p>
<pre><code class="language-plaintext">sed -i 's/INTERFACESv4=.*/INTERFACESv4="eth0"/' /etc/default/isc-dhcp-server</code></pre>
<p>Puis éditez <code>/etc/dhcp/dhcpd.conf</code> :</p>
<pre><code class="language-plaintext">allow booting;
allow bootp;
default-lease-time 600;--
max-lease-time 7200;
ddns-update-style none;
authoritative;
ignore-client-uids On;
subnet 192.168.100.0 netmask 255.255.255.0 {
range 192.168.100.20 192.168.100.80;
option domain-name example.com;
option domain-name-servers 9.9.9.9;
option routers 192.168.100.1;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.100.255;
next-server 192.168.100.2;
if exists user-class and option user-class = "iPXE" {
filename "http://192.168.100.2/oci/ipxe.php";
} else {
filename "lpxelinux.0";
}
}</code></pre>
<p>Notez soigneusement que <code>192.168.100.2</code> doit être l'adresse de votre serveur OCI, car il sera utilisé pour servir PXE, TFTP et Web pour les nœuds esclaves. Il est bien sûr très bien d'utiliser une autre adresse si votre serveur OCI le fait, alors n'hésitez pas à adapter ce qui précède à votre guise.</p>
<p>Notez qu'à partir de la version 28 d'OCI et au-dessus, le chargement de l'initrd et du noyau se fait via HTTP, donc l'utilisation de <code>lpxelinux.0</code> est obligatoire (<code>pxelinux.0</code> ne devrait plus être utilisé, car il ne supporte que TFTP).</p>
<p>De plus, pour qu'OCI autorise les requêtes à partir de la plage DHCP, vous devez ajouter vos sous-réseaux DHCP à <code>TRUSTED_NETWORKS</code> dans <code>openstack-cluster-installer.conf</code>. Sinon, le reporting matériel ne fonctionnera jamais.</p>
<p>&nbsp;</p>
<h3>tftpd</h3>
<p>Configurez <code>tftp-hpa</code> pour servir les fichiers depuis OCI:</p>
<pre><code class="language-plaintext">sed -i 's#TFTP_DIRECTORY=.*#TFTP_DIRECTORY="/var/lib/openstack-cluster-installer/tftp"#' /etc/default/tftpd-hpa</code></pre>
<p>Puis redémarrez <code>tftpd-hpa</code>.</p>
<p>&nbsp;</p>
<h2>Préparation de l'installation des serveurs</h2>
<h3>Configuration des clés SSH</h3>
<p>Lors de la configuration, OCI créera une paire de clés ssh publique / privée ici:</p>
<pre><code class="language-plaintext">/etc/openstack-cluster-installer/id_rsa</code></pre>
<p>Une fois cela fait, il copiera le contenu <code>id_rsa.pub</code> correspondant dans:</p>
<pre><code class="language-plaintext">/etc/openstack-cluster-installer/authorized_keys</code></pre>
<p>et ajoutera également toutes les clés publiques qu'il trouve sous <code>/root/.ssh/authorized_keys</code>. Plus tard, ce fichier sera copié dans l'image live OCI Debian, et dans tous les nouveaux systèmes qu'OCI installera. OCI utilisera plus tard la clé privée qu'il a générée pour se connecter aux serveurs, tandis que vos clés seront également présentes afin que vous puissiez vous connecter à chaque serveur individuel en utilisant votre clé privée. Par conséquent, il est fortement conseillé de personnaliser <code>/etc/openstack-cluster-installer/allowed_keys</code> <i><u>avant</u> de</i> construire l'image OCI Debian Live.</p>
<p>&nbsp;</p>
<h3>Construire l'image en direct d'OCI</h3>
<pre><code class="language-plaintext">mkdir -p /root/live-image
cd /root/live-image
openstack-cluster-installer-build-live-image --pxe-server-ip 192.168.100.2 --debian-mirror-addr http://deb.debian.org/debian --debian-security-mirror-addr http://security.debian.org/
cp -auxf /var/lib/openstack-cluster-installer/tftp/* /usr/share/openstack-cluster-installer
cd ..
rm -rf /root/live-image</code></pre>
<p>Il est possible d'utiliser des serveurs proxy de paquets comme <code>approx</code>, ou des miroirs locaux, ce qui donne la possibilité de déconnecter complètement votre cluster et OCI lui-même d'Internet.</p>
<p>&nbsp;</p>
<h3>Configurer l'ENC de Puppet</h3>
<p>Une fois le service master Puppet installé, ses directives de classificateur de nœud externe (ENC) doivent être définies, de sorte que OCI agisse comme ENC (ce qui signifie que OCI définira les rôles et les classes de puppet à appeler lors de l'installation d'un nouveau serveur avec puppet) :</p>
<pre><code class="language-plaintext">. /usr/share/openstack-pkg-tools/pkgos_func
pkgos_add_directive /etc/puppet/puppet.conf master "external_nodes = /usr/bin/oci-puppet-external-node-classifier" "# Path to enc"
pkgos_inifile set /etc/puppet/puppet.conf master external_nodes /usr/bin/oci-puppet-external-node-classifier
pkgos_add_directive /etc/puppet/puppet.conf master "node_terminus = exec" "# Tell what type of ENC"
pkgos_inifile set /etc/puppet/puppet.conf master node_terminus exec</code></pre>
<p>Puis redémarrez le service Puppet-Master.</p>
<p>&nbsp;</p>
<h3>Facultatif: approx</h3>
<p>Pour accélérer le téléchargement du paquet, il est fortement recommandé d'installer approx &nbsp;localement sur votre serveur de provisionnement OCI et d'utiliser son adresse lors de la configuration des serveurs (l'adresse est définie dans <code>/etc/openstack-cluster-installer/openstack-cluster-installer.conf</code>).</p>
<p>&nbsp;</p>
<h1>Utiliser OCI</h1>
<h2>Démarrage des serveurs</h2>
<p>Démarrez plusieurs ordinateurs, en les bootant avec PXE. Si tout se passe bien, ils attraperont le DHCP de l'OCI et redémarreront l'image en direct Debian de l'OCI. Une fois le serveur en marche, un agent s'exécutera pour faire un rapport à l'interface Web d'OCI. Rafraîchissez simplement l'interface Web d'OCI et vous verrez des machines. Vous pouvez également utiliser l'outil CLI:</p>
<pre><code class="language-plaintext">apt-get install openstack-cluster-installer-cli
ocicli machine-list
serial ipaddr memory status lastseen cluster hostname
2S2JGM2 192.168.100.37 4096 live 2018-09-20 09:22:31 null
2S2JGM3 192.168.100.39 4096 live 2018-09-20 09:22:50 null</code></pre>
<p>Notez qu'ocicli peut soit utiliser un login / mot de passe qui peut être défini dans la base de données interne de l'OCI, soit l'adresse IP du serveur sur lequel ocicli s'exécute peut être inscrite dans la liste blanche dans <code>/etc/openstack-cluster-installer/openstack-cluster-installer.conf</code>.</p>
<p>&nbsp;</p>
<h2>Création de régions, d'emplacements, de réseaux, de rôles et de clusters Swift</h2>
<h3>Avant de commencer</h3>
<p>Dans cette documentation, tout se fait via la ligne de commande en utilisant ocicli. Cependant, absolument tout peut également être fait à l'aide de l'interface Web. Il est simplement plus facile d'expliquer l'utilisation de l'interface de ligne de commande, car cela évite d'avoir à afficher des screenshots de l'interface Web.</p>
<p>Ici, le seul réseau que vous ajouterez à OCI serait les réseaux internes d'OpenStack. Jamais, vous n'ajouterez les réseaux publics ou ceux des VM OpenStack. Par exemple, un réseau pour la gestion des nœuds, un pour <code>vm-net</code>, un pour le réseau <code>ceph-cluster</code> ... Tous les réseaux que vous utiliserez sur OpenStack, doivent être provisionnés avec OpenStack lui-même à l'aide de l'API OpenStack .</p>
<p>&nbsp;</p>
<h3>Création de régions et d'emplacements Swift</h3>
<p>Avant d'installer les systèmes sur vos serveurs, des clusters doivent être définis. Cela commence par la configuration des régions Swift. Dans un cluster Swift, il existe des zones et des régions. Lors du téléchargement d'un fichier sur Swift, il est répliqué sur N zones (généralement 3). Si 2 régions sont définies, Swift essaie de répliquer des objets sur les deux régions.</p>
<p>Sous OCI, vous devez d'abord définir les régions Swift. Pour ce faire, cliquez sur "Swift region" sur l'interface web, ou en utilisant ocicli, saisissez :</p>
<pre><code class="language-plaintext">ocicli swift-region-create datacenter-1
ocicli swift-region-create datacenter-2</code></pre>
<p>Créez ensuite des emplacements associés à ces régions:</p>
<pre><code class="language-plaintext">ocicli dc1-zone1 datacenter-1
ocicli dc1-zone2 datacenter-1
ocicli dc2-zone1 datacenter-2</code></pre>
<p>Plus tard, lors de l'ajout d'un nœud de données Swift à un cluster (les nœuds de données sont les serveurs qui effectueront réellement le stockage Swift), un emplacement doit être sélectionné.</p>
<p>Une fois les emplacements définis, il est temps de définir les réseaux. Les réseaux sont également rattachés à des emplacements. Les zones et régions Swift seront liées à ces emplacements et régions.</p>
<p>&nbsp;</p>
<h3>Créer des réseaux</h3>
<pre><code class="language-plaintext">ocicli network-create dc1-net1 192.168.101.0 24 dc1-zone1 no</code></pre>
<p>La commande ci-dessus créera un sous-réseau <code>192.168.101.0/24,</code> situé dans <code>dc1-zone1</code>. Créons 2 réseaux supplémentaires:</p>
<pre><code class="language-plaintext">ocicli network-create dc1-net2 192.168.102.0 24 dc1-zone2 no
ocicli network-create dc2-net1 192.168.103.0 24 dc2-zone1 no</code></pre>
<p>Ensuite, pour que le cluster soit accessible, créons un réseau public sur lequel les clients se connecteront:</p>
<pre><code class="language-plaintext">ocicli network-create pubnet1 203.0.113.0 28 public yes</code></pre>
<p>Notez que si vous utilisez un /32, il sera configuré sur l'interface <code>lo</code> de votre contrôleur. La configuration attendue consiste à utiliser BGP pour acheminer cette adresse IP publique sur le contrôleur. Pour ce faire, il est possible de personnaliser l'ENC et d'ajouter le peering BGP à votre routeur. Voir à la fin de cette documentation pour cela.</p>
<p>&nbsp;</p>
<h3>Créer un nouveau cluster</h3>
<p>Créons un nouveau cluster:</p>
<pre><code class="language-plaintext">ocicli cluster-create swift01 example.com</code></pre>
<p>Maintenant que nous avons un nouveau cluster, les réseaux que nous avons créés peuvent y être ajoutés:</p>
<pre><code class="language-plaintext">ocicli network-add dc1-net1 swift01 all eth0
ocicli network-add dc1-net2 swift01 all eth0
ocicli network-add dc2-net1 swift01 all eth0
ocicli network-add pubnet1 swift01 all eth0</code></pre>
<p>Lors de l'ajout du réseau public, automatiquement, une adresse IP sera réservée au VIP (Virtual Private IP). Cette adresse IP sera plus tard partagée par les nœuds du contrôleur, pour effectuer la haute disponibilité (HA), contrôlée par pacemaker / corosync. Le principe est le suivant: si l'un des nœuds du contrôleur héberge le VIP (et il est affecté à son eth0), et devient indisponible (disons, le serveur plante ou le câble réseau est débranché), alors le VIP est réaffecté au eth0 d'un autre nœud de contrôleur du cluster.</p>
<p>Si vous sélectionnez 2 interfaces réseau (par exemple, eth0 et eth1), la liaison sera utilisée. Notez que votre équipement réseau (commutateurs, etc.) doit être configuré en conséquence (LACP, etc.), et que la configuration de ces équipements sort du cadre de cette documentation. Consultez votre fournisseur d'équipement réseau pour plus d'informations.</p>
<p>&nbsp;</p>
<h2>Véritable certificat pour l'API</h2>
<p>Par défaut, OCI générera un certificat auto-signé pour tout. Bien que cela fonctionne bien à quelques exceptions près (cela ne fonctionne visiblement pas pour Heat, Magnum et si l'on veut activer le chiffrement sur disque Swift), il est préférable, en production, d'utiliser un vrai certificat API, afin que les clients puissent faites confiance à votre serveur. Pour ce faire, il faut d'abord choisir un nom d'hôte pour l'API. Ceci est défini de cette façon:</p>
<pre><code class="language-plaintext">ocicli cluster-set z --vip-hostname cloud-api.example.com</code></pre>
<p>Une fois cela fait, dans le serveur OCI, générez un certificat pour ce nom d'hôte:</p>
<pre><code class="language-plaintext">oci-gen-slave-node-cert cloud-api.example.com</code></pre>
<p>Le <code>cd</code> vers <code>/var/lib/oci/ssl/slave-nodes/cloud-api.example.com</code>. Ensuite, vous pouvez trouver le c<code>loud-api.example.com.csr</code> (.csr signifie certificat de signature de certificat) qui peut être utilisé pour opter pour un vrai certificat. Faites signer le certificat, puis remplacez les fichiers <code>.crt</code> et <code>.pem</code> par le vrai contenu signé. Si vous réutilisez un certificat générique, vous souhaitez probablement également remplacer le fichier<code> .key</code>. Notez que le fichier <code>.pem</code> doit contenir le certificat <i><u>et</u></i> la clé privée, concaténés, et peut-être aussi tous les certificats intermédiaires.</p>
<p>Une fois cela fait, informez simplement OCI que nous utilisons un vrai certificat signé:</p>
<pre><code class="language-plaintext">ocicli cluster-set z --self-signed-api-cert no</code></pre>
<p>Désormais, Puppet sera démarré sans utiliser la racine ca de l'OCI comme environnement, et ca_file ne sera pas utilisé dans tous les fichiers de configuration d'OpenStack (une chaîne vide sera définie à la place).</p>
<p>Si vous avez mis votre cluster en production avant de signer le certificat, il est possible d'utiliser, sur le serveur de Puppet, l'utilitaire <code>oci-update-cluster-certs</code> :</p>
<pre><code class="language-plaintext">oci-update-cluster-certs z</code></pre>
<p>Cela remplacera le certificat <code>cloud-api.example.com</code> partout dans le cluster et redémarrera les services pour l'utiliser. Cet utilitaire shell est également utile chaque fois que votre certificat SSL expire et doit être mis à jour.</p>
<p>&nbsp;</p>
<h2>Inscription de serveurs dans un cluster</h2>
<p>Maintenant que nous avons des réseaux affectés au cluster, il est temps d'ajouter des serveurs d'attribution au cluster. Disons que nous avons la sortie ci-dessous:</p>
<pre><code class="language-plaintext">ocicli machine-list
serial ipaddr memory status lastseen cluster hostname
C1 192.168.100.20 8192 live 2018-09-19 20:31:57 null
C2 192.168.100.21 8192 live 2018-09-19 20:31:04 null
C3 192.168.100.22 8192 live 2018-09-19 20:31:14 null
C4 192.168.100.23 5120 live 2018-09-19 20:31:08 null
C5 192.168.100.24 5120 live 2018-09-19 20:31:06 null
C6 192.168.100.25 5120 live 2018-09-19 20:31:14 null
C7 192.168.100.26 4096 live 2018-09-19 20:31:18 null
C8 192.168.100.27 4096 live 2018-09-19 20:31:26 null
C9 192.168.100.28 4096 live 2018-09-19 20:30:50 null
CA 192.168.100.29 4096 live 2018-09-19 20:31:00 null
CB 192.168.100.30 4096 live 2018-09-19 20:31:07 null
CC 192.168.100.31 4096 live 2018-09-19 20:31:20 null
CD 192.168.100.32 4096 live 2018-09-19 20:31:28 null
CE 192.168.100.33 4096 live 2018-09-19 20:31:33 null
CF 192.168.100.34 4096 live 2018-09-19 20:31:40 null
D0 192.168.100.35 4096 live 2018-09-19 20:31:47 null
D1 192.168.100.37 4096 live 2018-09-21 20:31:23 null
D2 192.168.100.39 4096 live 2018-09-21 20:31:31 null</code></pre>
<p>Ensuite, nous pouvons inscrire des machines dans le cluster de cette manière:</p>
<pre><code class="language-plaintext">ocicli machine-add C1 swift01 controller dc1-zone1
ocicli machine-add C2 swift01 controller dc1-zone2
ocicli machine-add C3 swift01 controller dc2-zone1
ocicli machine-add C4 swift01 swiftproxy dc1-zone1
ocicli machine-add C5 swift01 swiftproxy dc1-zone2
ocicli machine-add C6 swift01 swiftproxy dc2-zone1
ocicli machine-add C7 swift01 swiftstore dc1-zone1
ocicli machine-add C8 swift01 swiftstore dc1-zone2
ocicli machine-add C9 swift01 swiftstore dc2-zone1
ocicli machine-add CA swift01 swiftstore dc1-zone1
ocicli machine-add CB swift01 swiftstore dc1-zone2
ocicli machine-add CC swift01 swiftstore dc2-zone1</code></pre>
<p>En conséquence, il y aura 1 contrôleur, 1 proxy Swift et 2 nœuds de données Swift sur chaque zone de nos clusters. Les adresses IP seront automatiquement attribuées aux serveurs lorsque vous les ajoutez aux clusters. Ils ne sont pas affichés dans ocicli, mais vous pouvez les vérifier via l'interface Web. Le résultat devrait être comme ceci:</p>
<pre><code class="language-plaintext">ocicli machine-list
serial ipaddr memory status lastseen cluster hostname
C1 192.168.100.20 8192 live 2018-09-19 20:31:57 7 swift01-controller-1.example.com
C2 192.168.100.21 8192 live 2018-09-19 20:31:04 7 swift01-controller-2.example.com
C3 192.168.100.22 8192 live 2018-09-19 20:31:14 7 swift01-controller-3.example.com
C4 192.168.100.23 5120 live 2018-09-19 20:31:08 7 swift01-swiftproxy-1.example.com
C5 192.168.100.24 5120 live 2018-09-19 20:31:06 7 swift01-swiftproxy-2.example.com
C6 192.168.100.25 5120 live 2018-09-19 20:31:14 7 swift01-swiftproxy-3.example.com
C7 192.168.100.26 4096 live 2018-09-19 20:31:18 7 swift01-swiftstore-1.example.com
C8 192.168.100.27 4096 live 2018-09-19 20:31:26 7 swift01-swiftstore-2.example.com
C9 192.168.100.28 4096 live 2018-09-19 20:30:50 7 swift01-swiftstore-3.example.com
CA 192.168.100.29 4096 live 2018-09-19 20:31:00 7 swift01-swiftstore-4.example.com
CB 192.168.100.30 4096 live 2018-09-19 20:31:07 7 swift01-swiftstore-5.example.com
CC 192.168.100.31 4096 live 2018-09-19 20:31:20 7 swift01-swiftstore-6.example.com
CD 192.168.100.32 4096 live 2018-09-19 20:31:28 null
CE 192.168.100.33 4096 live 2018-09-19 20:31:33 null
CF 192.168.100.34 4096 live 2018-09-19 20:31:40 null
D0 192.168.100.35 4096 live 2018-09-19 20:31:47 null
D1 192.168.100.37 4096 live 2018-09-21 20:31:23 null
D2 192.168.100.39 4096 live 2018-09-21 20:31:31 null</code></pre>
<p>Comme vous pouvez le voir, les noms d'hôte sont également calculés automatiquement.</p>
<p>&nbsp;</p>
<h2>Calcul du ring Swift</h2>
<p>Avant de commencer à installer les serveurs, le ring Swift doit être construit. Exécutez simplement cette commande:</p>
<pre><code class="language-plaintext">ocicli swift-calculate-ring swift01</code></pre>
<p>Notez que cela peut prendre très longtemps, en fonction de la taille de votre cluster.C'est normal, soyez juste patient.</p>
<p>&nbsp;</p>
<h2>Installation des serveurs</h2>
<p>Il n'y a pas (encore) de gros bouton «installer le cluster» sur l'interface Web ou sur la CLI. Au lieu de cela, les serveurs doivent être installés un par un:</p>
<pre><code class="language-plaintext">ocicli machine-install-os C1
ocicli machine-install-os C2
ocicli machine-install-os C3</code></pre>
<p>Il est conseillé d'installer d'abord les nœuds de contrôleur, de vérifier manuellement qu'ils sont correctement installés (par exemple, vérifier que "<code>openstack user list</code>" fonctionne), puis les nœuds de stockage Swift, puis les nœuds proxy Swift. Cependant, les nœuds du même type peuvent être installés en même temps. De plus, en raison de l'utilisation d'un VIP et d'un corosync / pacemaker, les nœuds de contrôleur <i><u>doivent</u></i> être installés à peu près en même temps.</p>
<p>Il est également possible de voir les dernières lignes du journal d'installation d'un serveur à l'aide de l'interface de ligne de commande:</p>
<pre><code class="language-plaintext">ocicli machine-install-log C1</code></pre>
<p>Cela affichera les journaux de l'installation du système à partir de <code>/var/log/oci</code>, puis une fois que le serveur aura redémarré, il affichera les journaux de Puppet depuis <code>/var/log/puppet-first-run</code>.</p>
<p>&nbsp;</p>
<h2>Vérification de votre installation</h2>
<p>Connectez-vous sur un nœud de contrôleur. Pour ce faire, listez son IP:</p>
<pre><code class="language-plaintext">CONTROLLER_IP=$(ocicli machine-list | grep C1 | awk '{print $2}')
ssh root@${CONTROLLER_IP}</code></pre>
<p>Une fois connecté au contrôleur, vous verrez les informations de connexion sous <code>/root/oci-openrc.sh</code>. Trouvez-le et essayez:</p>
<pre><code class="language-plaintext">. /root/oci-openrc.sh
openstack user list</code></pre>
<p>Vous pouvez également essayer Swift:</p>
<pre><code class="language-plaintext">. /root/oci-openrc.sh
openstack container create foo
echo "test" &gt;bar
openstack object create foo bar
rm bar
openstack object delete foo bar</code></pre>
<p>&nbsp;</p>
<h2>Activation du chiffrement d'objets Swift</h2>
<p>Localement sur le store Swift, Swift stocke l'objet sous une forme claire. Cela signifie que toute personne ayant un accès physique au centre de données peut extraire un disque dur et que les objets sont accessibles à partir du dossier <code>/srv/node</code>. Pour atténuer ce risque, Swift peut chiffrer les objets qu'il stocke. Les métadonnées (comptes, containters, etc.) seront toujours stockées sous une forme claire, mais au moins, les données stockées chiffrées.</p>
<p>La façon dont cela est implémenté dans OCI consiste à utiliser Barbican. C'est la raison pour laquelle Barbican est provisionné par défaut sur les nœuds du contrôleur. Par défaut, le chiffrement n'est pas activé. Pour l'activer, vous devez d'abord stocker la clé de chiffrement d'objet dans le store Barbican. Cela peut être fait de cette façon:</p>
<pre><code class="language-plaintext">ENC_KEY=$(openssl rand -hex 32)
openstack secret store --name swift-encryption-key \
--payload-content-type=text/plain --algorithm aes \
--bit-length 256 --mode ctr --secret-type symmetric \
--payload ${ENC_KEY}
+---------------+--------------------------------------------------------------------------------------------+
| Field | Value |
+---------------+--------------------------------------------------------------------------------------------+
| Secret href | https://swift01-api.example.com/keymanager/v1/secrets/6ba8dd62-d752-4144-b803-b32012d707d0 |
| Name | swift-encryption-key |
| Created | None |
| Status | None |
| Content types | {'default': 'text/plain'} |
| Algorithm | aes |
| Bit length | 256 |
| Secret type | symmetric |
| Mode | ctr |
| Expiration | None |
+---------------+--------------------------------------------------------------------------------------------+</code></pre>
<p>Une fois cela fait, l'ID de clé (ici: <code>6ba8dd62-d752-4144-b803-b32012d707d0</code>) doit être entré dans l'interface Web de l'OCI, dans la définition du cluster, sous "ID de clé de chiffrement Swift (vide: pas de chiffrement) :". Une fois que cela est fait, une autre exécution de Puppet est nécessaire sur les nœuds proxy Swift:</p>
<pre><code class="language-plaintext">OS_CACERT=/etc/ssl/certs/oci-pki-oci-ca-chain.pem puppet agent --test --debug</code></pre>
<p>Cela devrait activer le chiffrement. Notez que la clé de cryptage doit être stockée dans Barbican sous les services utilisateur swift et project, afin que Swift y ait accès.</p>
<p>&nbsp;</p>
<h2>Correction de node1 inutile dans corosync</h2>
<p>Parfois, "<code>node1</code>" apparaît lors de l'exécution de "<code>crm status</code>". Pour nettoyer cela, faites simplement:</p>
<pre><code class="language-plaintext">crm_node -R node1 --force</code></pre>
<p>&nbsp;</p>
<h2>Correction de ceph -s</h2>
<p>Cela corrige tous les avertissements Ceph après une configuration:</p>
<pre><code class="language-plaintext">ceph osd pool application enable glance rbd
ceph osd pool application enable nova rbd
ceph osd pool application enable cinder rbd
ceph osd pool application enable gnocchi rbd
ceph osd pool application enable cinderback rbd
ceph mon enable-msgr2</code></pre>
<p>&nbsp;</p>
<h2>Variable de configuration initiale du cluster</h2>
<p>Pour éviter de faire trop de choses lorsque le cluster est en production (comme, par exemple, démarrer MySQL pour faire la configuration initiale du cluster Galera), OCI a une variable appelée "<code>initial-cluster-setup</code>". Elle est activée par défaut lors des premières exécutions, et une fois que tous les contrôleurs ont signalé une exécution réussie à Puppet, cette variable est automatiquement définie sur <code>no</code>. Voici une liste (probablement non exhaustive) de choses qu'OCI ne fait que si i<code>nitial-cluster-setup</code> est défini sur <code>yes</code> :</p>
<ul>
<li>ressource openstack-api-vip dans corosync</li>
<li>Cluster Galera</li>
<li>Faire en sorte que les contrôleurs rejoignent le cluster rabbitmq</li>
<li>Utilisateurs du domaine Heat et Magnum</li>
<li>Configuration des cellules Nova v2</li>
</ul>
<p>A tout moment, il est possible de basculer la valeur sur <code>yes</code> ou <code>no</code> :</p>
<pre><code class="language-plaintext">ocicli cluster-set z --initial-cluster-setup no</code></pre>
<p>Cependant, il est fortement conseillé de définir la valeur sur no une fois que le cluster est en production.</p>
<blockquote>
<p>Si les 3 contrôleurs de vos clusters exécutent avec succès puppet à
la première startup, ils appelleront "<code>oci-report-puppet-success</code>". Une fois le troisième contrôleur fait, <code>initial-cluster-setup</code> sera automatiquement défini sur
la valeur «<code>no</code>» dans la base de données OCI.</p>
</blockquote>
<p>&nbsp;</p>
<h2>Ajout d'autres types de nœuds</h2>
<p>OCI peut gérer, par défaut, les types de nœuds ci-dessous:</p>
<ul>
<li>cephmon : moniteur Ceph</li>
<li>cephosd : machines de données Ceph</li>
<li>compute : nœuds Nova compute et Neutron DVR</li>
<li>controller : nœuds de contrôle OpenStack, exécutant toutes les API et démons</li>
<li>swiftproxy : serveurs proxy Swift</li>
<li>swiftstore : machines de données Swift</li>
<li>volume : nœuds Cinder LVM</li>
<li>réseau : routage DHCP, SNAT IPv4 et IPv6</li>
</ul>
<p>Il est seulement obligatoire d'installer 3 contrôleurs, puis tout le reste est facultatif. Il n'y a rien à configurer, OCI comprendra ce que l'utilisateur veut en fonction du type de nœuds mis à disposition.</p>
<p>Si les nœuds <code>cephosd</code> sont déployés, alors tout utilisera Ceph :</p>
<ul>
<li>Nova (c'est-à-dire : <code>/var/lib/nova/instances</code> sur Ceph)</li>
<li>Glance (images stockées sur Ceph)</li>
<li>Cinder (<code>cinder-volume</code> déployé sur les nœuds de calcul utilisera le backend Ceph)</li>
</ul>
<p>Même avec Ceph, la configuration de nœuds de volume ajoutera la capacité de backend LVM. Avec ou sans nœuds de volume, si certains nœuds OSD sont déployés, cinder-volume et cinder-backup avec le backend Ceph seront installés sur les nœuds de calcul.</p>
<p>La migration en direct des machines virtuelles entre les nœuds de calcul n'est possible que si vous utilisez Ceph (c'est-à-dire si certains nœuds Ceph OSD sont déployés), ou si vous utilisez l'option <code>--block-migration</code>.</p>
<p>Les nœuds Ceph MON sont facultatifs. S'ils ne sont pas déployés, le Ceph MON et MGR seront installés sur les nœuds du contrôleur.</p>
<p>Les nœuds de réseau sont facultatifs. S'ils ne sont pas déployés, les contrôleurs agiront en tant que nœuds de routage SNAT et IPv6, et les serveurs DHCP seront installés sur les nœuds de calcul.</p>
<p>&nbsp;</p>
<h1>Utilisation avancée</h1>
<h2>Utilisation de la configuration d'adresse IPMI automatisée</h2>
<p>Étant donné que la gestion manuelle de cela peut prendre trop de temps, OCI offre la possibilité de configurer automatiquement les adresses IPMI de tous les serveurs découverts. Et comme il est possible que dans la configuration de votre réseau, il y ait plusieurs réseaux IPMI en fonction de l'emplacement physique du serveur, OCI offre la possibilité de choisir automatiquement un réseau IPMI en fonction du réseau DHCP qu'un serveur démarre sur l'image en direct Debian.</p>
<p>La première chose à faire est de définir un réseau IPMI, de le définir avec le rôle "ipmi", puis de le faire correspondre à l'adresse IP du réseau DHCP:</p>
<pre><code class="language-plaintext"># ocicli network-create ipmi 192.168.200.0 24 zone-1 no
# ocicli network-set ipmi --role ipmi --ipmi-match-addr 192.168.100.0 --ipmi-match-cidr 24</code></pre>
<p>Une fois cela fait, l'option automatic_ipmi_numbering = yes doit être définie dans /etc/openstack-cluster-installer/openstack-cluster-installer.conf.</p>
<p>Lorsque cette option est définie, chaque fois qu'un serveur signale sa configuration matérielle, OCI vérifie s'il possède une IP IPMI correcte. Sinon, OCI effectuera un ssh dans le serveur et exécutera les commandes "ipmitool" nécessaires pour définir une configuration réseau valide. Ce faisant, l'adresse IP sera réservée dans la table "ips" de l'OCI, en veillant à ce que jamais, une adresse IP ne soit utilisée deux fois.</p>
<p>Avec l'exemple ci-dessus, si un serveur PXE démarre sur le réseau 192.168.100.0/24, une adresse IP IPMI lui sera automatiquement attribuée sur le réseau 192.168.200.0/24. Notez que le mot de passe IPMI est choisi au hasard. Comme nous utilisons openssl rand -base64, il peut être judicieux de vous assurer que votre serveur OCI a une bonne source d'entropie.</p>
<p>Si auparavant, certains serveurs avaient leur adresse IPMI déjà définie sur quelque chose qui correspond au réseau IPMI, mais que OCI ne l'a pas enregistrée, il est possible d'obtenir cette adresse IP enregistrée dans la base de données d'OCI. Il suffit de taper cette commande pour le faire:</p>
<pre><code class="language-plaintext"># ocicli ipmi-assign-check</code></pre>
<p>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.</p>
<h2>&nbsp;</h2>
<p>&nbsp;</p>
Référencer dans un nouveau ticket Voir Git blame Copier le lien permanent