Travailler avec les hôtes¶

Le vCenter et le Mode de Maintenance¶

Pour entrer en mode maintenance sur un hôte du vCenter, à la fois le vCenter et CloudStack doivent être utilisés de concert. CloudStack et vCenter ont des modes de maintenance séparés qui fonctionnent en étroite collaboration.

1. Placer l’hôte dans le mode de “maintenance planifiée” de CloudStack. Cela n’invoque pas le mode de maintenance du vCenter, mais cause la migration des VMs hors de l’hôte.

   Quand le mode de maintenance de CloudStack est demandée, l’hôte se met d’abord dans l’état Préparation pour Maintenance. Dans cet état, il ne peut pas être la cible du démarrage d’une nouvelle VM. Alors toutes les VMs vont être migrée hors du serveur. La migration à chaud sera utilisée pour bouger les VMs hors de l’hôte. Cela permet de migrer les invités de l’hôte sans causer de perturbation pour les invités. Après que la migration soit finie, l’hôte va entrer dans le mode Prêt pour Maintenance.

2. Attendre l’apparition de l’indicateur “Prêt pour la Maintenance” dans l’interface.

3. Maintenant utiliser le vCenter pour accomplir toutes les actions nécessaires pour entretenir l’hôte. Durant ce temps, l’hôte ne peut pas être la cible de l’allocation d’une nouvelle VM.

4. Lorsque les tâches de maintenance sont terminées, sortir l’hôte du mode maintenance comme ceci :

   1. Utiliser d’abord le vCenter pour sortir du mode maintenance du vCenter.

      Cela rend le hôte prêt pour que CloudStack puisse le réactiver.

   2. Utiliser alors l’interface d’administration de CloudStack pour annuler le mode de maintenance de CloudStack

      Quand l’hôte reviens en ligne, les VMs qui ont étés migrées peuvent être re-migrées manuellement et de nouvelles VMs peuvent être ajoutées.

Le XenServer et le Mode Maintenance¶

Pour le XenServer, vous pouvez mettre un serveur hors ligne temporairement en utilisant la fonctionnalité de Mode Maintenance dans XenCenter. Quand vous placer un serveur dans le mode maintenance, toutes les VMs sont automatiquement migrées vers un autre hôte du même groupe. Si le serveur est le maître du groupe, un nouveau maître sera aussi sélectionné pour le groupe. Pendant qu’un serveur est en Mode Maintenance, vous ne pouvez pas créer ou démarrer de VMs sur lui.

Pour basculer un serveur en Mode Maintenance :

1. Dans le panneau Ressources, sélectionner le serveur, puis effectuer l’une des actions suivantes :

   • Clic-droit, puis Entrer en Mode Maintenance dans le menu de raccourcis.

   • Dans le menu Serveur, cliquer Entrer en Mode Maintenance.

2. Cliquer sur Entrer en Mode Maintenance.

Le statut du serveur dans le panneau Ressources affichera lorsque toutes les VMs fonctionnant auront étés migrées avec succès du serveur.

Pour sortir un serveur du Mode Maintenance :

1. Dans le panneau Ressources, sélectionner le serveur, puis effectuer l’une des actions suivantes :

   • Clic-droit, puis Sortir dun Mode Maintenance dans le menu de raccourcis.

   • Dans le menu Serveur, cliquer Sortir du Mode Maintenance.

2. Cliquer sur Sortir du Mode Maintenance

Retirer des hôtes XenServer et KVM¶

Un noeud ne peut pas être supprimé d’un cluster jusqu’à ce qu’il ait été placé en mode maintenance. Cela va assurer que toutes les VM ont été migrées vers d’autres hôtes. Pour retirer un hôte du cloud :

1. Placer le noeud en mode maintenance.

   Voir “Maintenance programmée et mode de maintenance pour les hôtes”.

2. Pour KVM, stopper le service cloud-agent.

3. Utiliser l’option de l’interface pour supprimer le noeud.

   Alors vous pouvez éteindre l’hôte, réutiliser son adresse IP, le réinstaller, etc.

Retirer des hôtes vSphere¶

Pour retirer ce type d’hôte, dans un premier temps, le placer en mode maintenance, comme décrit dans “Maintenance programmée et mode de maintenance pour les hôtes”. Utiliser ensuite CloudStack pour supprimer l’hôte. CloudStack ne va pas diriger de commandes à un hôte qui a été supprimé en utilisant CloudStack. Toutefois l’hôte peut toujours exister dans le cluster dans le vCenter.

Limitations de la sur-allocation pour XenServer et KVM¶

• Dans XenServer, à cause d’une limitation de cet hyperviseur, vous ne pouvez pas utiliser un facteur plus grand que 4.

• L’hyperviseur KVM ne peut pas gérer l’allocation de mémoire dynamique aux VM. CloudStack défini le minimum et le maximum de quantité de mémoire qu’une VM peut utiliser. L’hyperviseur ajuste la mémoire dans les limites définies en fonction de la contention de la mémoire.

Pré-requis pour la sur-allocation¶

Plusieurs conditions préalables sont requises pour que la sur-allocation fonctionne correctement. Cette fonctionnalité est dépendante du type d’OS, des capacités de l’hyperviseur et de certains scripts. Il est de la responsabilité de l’administrateur de s’assurer que ces exigences soient réunies.

Fixer les ratios de sur-allocation¶

Il existe deux façons pour l’administrateur racine de définir des rapport de sur-allocation du CPU et de la RAM. Tout d’abord, les paramètres de configuration globaux cpu.overprovisioning.factor et mem.overprovisioning.factor seront appliqués lors de la création d’un nouveau cluster. Puis les facteurs pourront être modifiés pour un cluster existant.

Seules les machines virtuelles déployées après la modification sont affectées par le nouveau paramètre. Si vous voulez que les machines virtuelles déployées avant la modification adoptent le nouveau facteur de sur-allocation, vous devrez arrêter et redémarrer les machines virtuelles. Lorsque cela est fait, CloudStack recalculera ou évaluera les capacités utilisées et réservées en fonction des nouveaux facteurs de sur-allocation pour s’assurer que CloudStack calcule correctement la quantité de capacité disponible.

Pour changer les facteurs de sur-allocation pour un cluster existant :

1. Se connecter en tant qu’administrateur dans l’interface de CloudStack.

2. Dans la barre de navigation de gauche, cliquer sur Infrastructure.

3. Sous Clusters, cliquer sur Voir tout.

4. Sélectionner le cluster sur lequel vous voulez travailler, et cliquer sur le bouton Editer.

5. Saisissez vos multiplicateurs de sur-allocation désirés dans les champs CPU overcommit ratio et RAM overcommit ratio. La valeur indiquée initialement dans ces champs est la valeur par défaut héritée des paramètres de configuration globaux.

   Note

   Dans XenServer, à cause d’une limitation de cet hyperviseur, vous ne pouvez pas utiliser un facteur plus grand que 4.

Limites d’offre de service et sur-allocation¶

Les limites d’offre de service (par exemple 1 GHz, 1 coeur) sont strictement appliquées pour le nombre de noyaux. Par exemple, un invité disposant d’une offre de service d’un coeur n’aura qu’un seul coeur disponible, indépendamment de toute autre activité sur l’hôte.

Les limites de service offertes en gigahertz sont appliquées uniquement lorsqu’il y a contention des ressources CPU. Par exemple, supposons qu’un invité ait été créé avec une offre de service de 1 GHz sur un hôte disposant de coeurs à 2 GHz et que cet invité est le seul client en cours d’exécution sur l’hôte. L’invité aura à sa disposition la totalité des 2 GHz. Lorsque plusieurs invités tentent d’utiliser le CPU, un facteur de pondération est utilisé pour planifier les ressources CPU. Le poids est basé sur la vitesse d’horloge de l’offre de service. Les clients reçoivent une allocation CPU proportionnelle au GHz de leur offre de service. Par exemple, un invité créé à partir d’une offre de service à 2 GHz recevra l’équivalent de deux fois l’allocation CPU d’un invité créé à partir d’une offre de service à 1 GHz. CloudStack n’effectue pas de sur-allocation de la mémoire.

Exemple d’allocation de VLAN¶

Les VLAN sont requis pour le trafic public et privé. Voici un exemple de schéma d’allocation VLAN:

Ajouter des intervalles de VLAN non contiguës.¶

CloudStack vous offre la flexibilité d’ajouter des plages de VLAN non contiguës à votre réseau. L’administrateur peut mettre à jour une plage de VLAN existante ou ajouter plusieurs plages de VLAN non contiguës lors de la création d’une zone. Vous pouvez également utiliser l’API UpdatephysicalNetwork pour étendre la plage de VLAN.

1. Se connecter à l’interface de CloudStack comme administrateur ou utilisateur final.

2. S’assurer que l’intervalle VLAN n’existe pas déjà.

3. Choisissez Infrastructure dans le panneau de navigation à gauche.

4. Sur Zones, cliquer sur Voir plus, puis cliquer sur la zone avec laquelle vous voulez travailler.

5. Cliquer sur le réseau physique.

6. Dans le noeud Invité du diagramme, cliquer sur Configurer.

7. Cliquer sur Editer .

   Le champ intervalle VLAN est maintenant éditable.

8. Spécifier le début et la fin de l’intervalle VLAN dans une liste séparée par une virgule.

   Spécifier tous les VLAN que vous voulez utiliser, les VLAN non spécifiés seront supprimés si vous ajoutez une nouvelle plage à la liste existante.

9. Cliquer sur Appliquer.

Assigner les VLAN à des réseaux isolés.¶

CloudStack vous offre la possibilité de contrôler l’assignation de VLAN aux réseaux isolés. En tant qu’administrateur racine, vous pouvez attribuer un ID de VLAN lorsqu’un réseau est créé, comme c’est le cas pour les réseaux partagés.

Le comportement précédent est également pris en charge - un VLAN est alloué de façon aléatoire à un réseau à partir de la plage VNET du réseau physique lorsque le réseau passe à l’état Implémenté. Le VLAN est libéré dans le pool VNET lorsque le réseau s’arrête par le Network Garbage Collection. Le VLAN peut être réutilisé soit par le même réseau lors de sa remise en œuvre, soit par n’importe quel autre réseau. Sur chaque implémentation ultérieure d’un réseau, un nouveau VLAN peut être assigné.

Seul l’administrateur racine peut attribuer des VLAN car les utilisateurs réguliers ou l’administrateur de domaine ne connaissent pas la topologie du réseau physique. Ils ne peuvent même pas voir quel VLAN est affecté à un réseau.

Pour vous permettre d’assigner des VLAN à des réseaux isolés,

1. Créer une offre de réseau en spécifiant ce qui suit :

   • Type d’invité : Sélectionner Isolé.

   • Spécifier le VLAN : Sélectionner l’option.

   Pour plus d’informations, voir le Guide d’Installation de CloudStack.

2. Utiliser l’offre de réseau, créer un réseau.

   Vous pouvez créer un tier VPC ou un réseau isolé.

3. Spécifier le VLAN lorsque vous créez le réseau.

   Lorsqu’un VLAN est spécifié, un CIDR et une passerelle sont affectés à ce réseau et l’état est changé à Setup. Dans cet état, le réseau ne sera pas récupérés.

Gestion des Out-of-band¶

CloudStack fournit aux administrateurs racine la possibilité de configurer et d’utiliser les interfaces out-of-band supportées (par exemple, IPMI, iLO, DRAC, etc.) sur un hôte physique pour gérer les opérations d’alimentation de l’hôte telles que marche, arrêt, reset, etc. Par défaut, les controlleurs IPMI 2.0 sont pris en charge nativement par le pilote de gestion IPMITOOL out-of-band dans CloudStack qui utilise ipmitool pour effectuer des opérations de gestion IPMI 2.0.

Voici quelques paramètres globaux qui contrôlent différents aspects de cette fonctionnalité.

Une modification des paramètres outofbandmanagement.sync.interval ou` outofbandmanagement.sync.poolsize` requiert le redémarrage des serveurs de gestion puisque le pool de threads et un thread de synchronisation en arrière-plan (état d’alimentation) sont configurés pendant le chargement lorsque le serveur de gestion CloudStack démarre. Le reste des paramètres globaux peut être modifié sans nécessiter le redémarrage du ou des serveurs de gestion.

Le Outofbandmanagement.sync.poolsize est le nombre maximal de scanners ipmitool en arrière plan d’état d’alimentation pouvant être exécutés à la fois. En fonction du nombre maximal d’hôtes que vous avez, vous pouvez augmenter / diminuer la valeur en fonction de la quantité de stress que votre serveur hôte de gestion peut supporter. Il faudra calculer le plus grand nombre d’hôtes out-of-band activés par la formule * outofbandmanagement.action.timeout / outofbandmanagement.sync.poolsize secondes pour compléter une analyse de synchronisation de l’état d’alimentation en arrière-plan en un seul tour.

Pour utiliser cette fonctionnalité, l’administrateur racine doit d’abord configurer la gestion out-of-band pour un hôte à l’aide de l’interface utilisateur ou de l’API configureOutOfBandManagement. Ensuite, l’administrateur racine doit l’activer. La fonction peut être activée ou désactivée dans une zone, un cluster ou un hôte,

Une fois que le management out-of-band est configuré et activé pour un hôte (et pourvu qu’il ne soit pas désactivée au niveau de la zone ou du cluster), les administrateurs racines sont en mesure d’exécuter des actions de gestion de l’alimentation telles que marche, arrêt, réinitialisation, cycle, logiciel et statut.

Si un hôte est en mode maintenance, les administrateurs Root sont toujours autorisés à effectuer des actions de gestion d’allumage ou d’extinction mais dans l’interface une alerte est affichée.