Maintenance Planifiée et Mode Maintenance pour les hôtes
Vous pouvez faire entrer un hôte en mode maintenance. Quand le mode maintenance est activé, l’hôte devient indisponible pour recevoir de nouvelles VMs, et les VMs invitées déjà en fonctionnement sur l’hôte sont migrées de façon transparente vers un autre hôte qui n’est pas en mode maintenance. Cette migration utilise la technologie de migration à chaud et n’interrompt pas l’exécution de l’invité.
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.
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.
Attendre l’apparition de l’indicateur “Prêt pour la Maintenance” dans l’interface.
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.
Lorsque les tâches de maintenance sont terminées, sortir l’hôte du mode maintenance comme ceci :
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.
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 :
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.
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 :
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.
Cliquer sur Sortir du Mode Maintenance
Désactiver et activer des Zones, Pods et Clusters
Vous pouvez activer ou désactiver une zone, un pod ou cluster sans le supprimer définitivement du cloud. C’est utile pour la maintenance ou lorsqu’il y a des problèmes qui rendent une partie de l’infrastructure du Cloud non fiable. Aucune nouvelle allocation ne sera faîte à une zone, pod ou cluster désactivé tant que son état n’est pas de nouveau Activé. Quand une zone, pod ou cluster est ajouté au cloud, il est désactivé par défaut.
Pour déactiver et activer une zone, un pod ou un cluster :
Se connecter à l’interface de CloudStack comme administrateur
Dans la barre de navigation de gauche, cliquer sur Infrastructure.
Dans Zones, cliquer sur Voir plus.
Si vous êtes en train de désactiver ou d’activer une zone, trouver le nom de la zone dans la liste, et cliquer sur le bouton Activer/Désactiver.
Si vous êtes en train de désactiver ou d’activer un pod ou un cluster, cliquer sur le nom de la zone qui contient le pod ou le cluster.
Cliquer sur l’onglet Offre de calcul.
Dans les noeuds Pods ou les Clusters du diagramme, cliquer sur Totu voir.
Cliquer sur le nom du pod ou du cluster dans la liste.
Cliquer sur le bouton Activer/Désactiver.
Entretenir les hyperviseurs sur les hôtes
Lorsque vous utilisez des logiciels hyperviseur sur des hôtes, assurez-vous que toutes les mises à jour fournies par le vendeur de l’hyperviseur soit appliquées. Suivez les sorties des correctifs de l’hyperviseur via les moyens du support du vendeur de l’hyperviseur, et appliquez les correctifs aussitôt que possible après leurs sorties. CloudStack ne va pas suivre ni vous notifier des correctifs requis pour l’hyperviseur. Il est essentiel que vos hôtes soient totalement à jour de leurs correctifs. Le vendeur de l’hyperviseur refusera probablement de supporter un système qui n’est pas à jour de correctifs.
Note
L’absence des dernières mise à jour peut mener à la corruption de données et la perte de VM.
(XenServer) Pour plus d’informations, voir `Mises à jour hautement recommandées pour XenServer dans la base de connaissance CloudStack<http://docs.cloudstack.org/Knowledge_Base/Possible_VM_corruption_if_XenServer_Hotfix_is_not_Applied/Highly_Recommended_Hotfixes_for_XenServer_5.6_SP2>`_.
Sur-allocation et Limites d’Offre de Service.
(Supporté par XenServer, KVM et VMware)
Les facteurs de sur-allocation de CPU et de mémoire (RAM) peuvent être paramétrés pour chaque cluster pour changer le nombre de VM qui peuvent fonctionner sur chaque hôte du cluster. Cela aide à optimiser l’utilisation des ressources. En augmentant le ration de sur-allocation, une plus grosse capacité de la ressource va être utilisée. Si le ration est fixé à 1, aucune sur-allocation n’est effectuée.
L’administrateur peut aussi paramétrer les facteurs globaux par défaut de sur-allocation dans les variables de la configuration globale cpu.overprovisioning.factor et mem.overprovisioning.factor. La valeur par défaut de ces variables est de 1 : la sur-allocation est désactivée par défaut.
Les facteurs d’Over-provisionning sont dynamiquement substitué dans les calculs de capacités de CloudStack. Par exemple :
Capacité = 2 GB facteur d’Over-provisionning = 2 Capacité après over-provisionning = 4 GB
Avec cette configuration, en supposant que vous déployez 3 VM de 1 GB chacune :
Utilisé = 3 GB Libre = 1 GB
L’administrateur peut spécifier un facteur de sur-allocation de mémoire, et peut spécifier à la fois les facteurs de sur-allocation de CPU et de mémoire par cluster.
Dans n’importe quel cloud, le nombre optimal de VM par hôte est affecté par des variables comme l’hyperviseur, le stockage et la configuration matérielle. Ils peuvent être différent pour chaque cluster dans le même cloud. Un simple paramètre global de sur-allocation ne peut pas représenter le meilleur moyen pour tous les différents cluster du cloud. Il doit être défini au niveau du plus petit dénominateur commun. La configuration par cluster fournie une granularité plus fine pour une meilleur utilisation des ressources, sans relation avec l’endroit où l’algorithme de placement de CloudStack décide de placer une VM.
Les paramètres de sur-allocation peuvent être utilisés avec les ressources dédiées (assigner un cluster spécifique à un compte) pour effectivement offrir des niveaux de services différents à différents comptes. Par exemple, un compte payant pour un niveau de service plus cher peut être assigné à un cluster dédié avec un rapport de sur-allocation de 1, et un compte moins onéreux à un cluster avec un rapport de 2.
Lorsqu’un nouvel hôte est ajouté à un cluster, CloudStack supposera que l’hôte à la capacité d’exécuter la sur-allocation en CPU et en RAM configurée pour ce cluster. Il appartient à l’administrateur d’être sur que l’hôte est actuellement approprié au niveau de sur-allocation paramétré.
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.
Driver pour le ballooning
Toutes les machines virtuelles devraient avoir un driver de ballooning installé. L’hyperviseur communique avec le driver du ballooning pour libérer ou rendre la mémoire disponible à une machine virtuelle.
XenServer
Le driver de ballooning sont fournis par les xen pv ou les drivers PVHVM. Les drivers pvhvm xen sont inclus dans les kernels linux supérieurs à 2.6.36+.
VMware
Les drivers de ballooning sont fournis par les VMware tools. Toutes les VM qui sont déployées dans un cluster avec sur-allocation devraient avoir les VMware tools d’installés.
KVM
Toutes les VM doivent supporter les drivers virtio. Ces drivers sont installés dans toutes les versions du kernel Linux 2.6.25 et supérieur. L’administrateur doit paramètrer CONFIG_VIRTIO_BALLOON=y dans la configuration virtio.
Capacités de l’hyperviseur
L’hyperviseur doit être capable d’utiliser le memory-balloning.
XenServer
La capacité DMC (Dynamic Memory Control) de l’hyperviseur devrait être activée. Seul XenServer Advanced et versions supérieures disposent de cette fonctionnalité.
VMware, KVM
Le memory ballooning est supporté par défaut.
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.
Note
Il est plus prudent de ne pas déployer de nouvelles machines virtuelles supplémentaires pendant que le re-calcul des capacités est en cours, au cas où les nouvelles valeurs de la capacité disponible ne seraient pas suffisamment élevées pour accueillir les nouvelles machines virtuelles. Il suffit d’attendre que les nouvelles valeurs utilisées / disponibles deviennent disponibles, pour être sûr qu’il y ait de la place pour toutes les nouvelles machines virtuelles que vous désirez.
Pour changer les facteurs de sur-allocation pour un cluster existant :
Se connecter en tant qu’administrateur dans l’interface de CloudStack.
Dans la barre de navigation de gauche, cliquer sur Infrastructure.
Sous Clusters, cliquer sur Voir tout.
Sélectionner le cluster sur lequel vous voulez travailler, et cliquer sur le bouton Editer.
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.
Approvisionnement de VLAN
CloudStack crée et détruit automatiquement les interfaces reliées aux VLAN sur les hôtes. En général, l’administrateur n’a pas besoin de gérer ce processus.
CloudStack gère les VLAN différemment en fonction du type d’hyperviseur. Pour XenServer ou KVM, les VLAN sont créés uniquement sur les hôtes où ils seront utilisés, puis ils sont détruits lorsque tous les invités qui en ont besoin ont été supprimés ou déplacés vers un autre hôte.
Pour vSphere, les VLAN sont provisionnés sur tous les hôtes du cluster, même s’il n’y a pas d’invité nécessitant le VLAN en cours d’exécution sur un hôte particulier. Cela permet à l’administrateur d’effectuer une migration à chaud et autres fonctions du vCenter sans avoir à créer le VLAN sur l’hôte de destination. De plus, les VLAN ne sont pas supprimés des hôtes lorsqu’ils ne sont plus nécessaires.
Vous pouvez utiliser les mêmes VLAN sur différents réseaux physiques à condition que chaque réseau physique possède sa propre infrastructure de niveau 2, comme des commutateurs. Par exemple, vous pouvez spécifier une plage de VLAN de 500 à 1000 lors du déploiement des réseaux physiques A et B dans une configuration de type zone avancée. Cette fonctionnalité vous permet de configurer une infrastructure physique de niveau 2 supplémentaire sur une carte réseau physique différente et d’utiliser le même ensemble de VLAN si vous veniez à être à court de VLAN. Un autre avantage est que vous pouvez utiliser le même ensemble d’IP pour différents clients, chacun avec leurs propres routeurs et réseaux invités sur différentes interfaces physiques.
Exemple d’allocation de VLAN
Les VLAN sont requis pour le trafic public et privé. Voici un exemple de schéma d’allocation VLAN:
ID VLAN
|
Type de trafic
|
Portée
|
Moins de 500
|
Trafic de gestion.
|
Réservé pour des besoins administratifs. Le logiciel CloudStack, les hyperviseurs et les VMs système peuvent y accéder.
|
500-599 |
VLAN transportant le trafic public.
|
Comptes CloudStack.
|
600-799 |
VLAN transportant le trafic invité.
|
Comptes CloudStack. Le VLAN spécifique au compte est choisi depuis cette réserve.
|
800-899 |
VLAN transportant le trafic invité.
|
Comptes CloudStack. Le VLAN spécifique au compte choisi par l’administrateur CloudStack pour être assigneé à ce compte.
|
900-999 |
VLAN transportant le trafic public.
|
Comptes CloudStack. Peut être limité à un projet, à un domaine ou pour tous les comptes.
|
Supérieur à 1000
|
Réservé pour un usage futur.
|
|
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.
Se connecter à l’interface de CloudStack comme administrateur ou utilisateur final.
S’assurer que l’intervalle VLAN n’existe pas déjà.
Choisissez Infrastructure dans le panneau de navigation à gauche.
Sur Zones, cliquer sur Voir plus, puis cliquer sur la zone avec laquelle vous voulez travailler.
Cliquer sur le réseau physique.
Dans le noeud Invité du diagramme, cliquer sur Configurer.
Cliquer sur Editer .
Le champ intervalle VLAN est maintenant éditable.
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.
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,
Créer une offre de réseau en spécifiant ce qui suit :
Pour plus d’informations, voir le Guide d’Installation de CloudStack.
Utiliser l’offre de réseau, créer un réseau.
Vous pouvez créer un tier VPC ou un réseau isolé.
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.
Note
Vous ne pouvez pas changer un VLAN une fois qu’il est affecté à un réseau. Le VLAN reste avec le réseau pendant tout son cycle de vie.
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é.
Configuration globale
|
Valeurs par défaut
|
Description |
outofbandmanagement.action.timeout |
60 |
Le délai d’attente de l’action du out of band management en secondes, configurable par cluster
|
outofbandmanagement.ipmitool.interface |
lanplus |
L’interface du pilote IpmiTool pour le out of band management à utiliser. Les valeurs valides sont: lan, lanplus, etc.
|
outofbandmanagement.ipmitool.path |
/usr/bin/ipmitool |
Le chemin de l’ipmitool du out of band management utilisé par le pilote de l’IpmiTool
|
outofbandmanagement.ipmitool.retries |
1 |
L’option de nouvelle essais -R du pilote IpmiTool du out of band management
|
outofbandmanagement.sync.interval |
300 |
L’intervalle en secondes du thread de synchronisation en arrière-plan du gestionnaire out of band.
|
outofbandmanagement.sync.poolsize |
50 |
The out of band management background sync thread pool size 50 |
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.