CloudStack : documentation d’administration¶

Vue d’ensemble de l’interface pour les utilisateurs¶

L’interface de CloudStack aide les utilisateurs de l’infrastructure cloud à visualiser et utiliser leurs ressources cloud, incluant les machines virtuelles, les modèles et les ISOs, les volumes de données et les instantanés, les réseaux invités et les adresses IP. Si l’utilisateur est un membre ou administrateur d’un ou plusieurs projets CloudStack, l’interface fournit une vue orientée projet.

Vue d’ensemble de l’interface pour les administrateurs¶

L’interface de CloudStack aide l’administrateur CloudStack à provisionner, voir et gérer l’infrastructure cloud, les domaines, les comptes utilisateurs, les projets et les paramètres de configuration. La première fois que vous démarrez l’interface utilisateur d’une nouvelle installation du serveur de gestion, vous pouvez choisir de suivre l’assistant de démarrage pour provisionner votre infrastructure cloud. Lors des connexions ultérieures, le tableau de bord de l’utilisateur connecté apparaît. Les différents liens de cet écran et de la barre de navigation sur la gauche fournissent un accès à une variété de fonctions administratives. L’administrateur peut également utiliser l’interface pour effectuer l’ensemble des tâches qui sont proposées à un utilisateur final.

Se connecter en tant qu’Administrateur¶

Après l’installation et le démarrage du logiciel de gestion, vous pouvez utiliser l’interface utilisateur de CloudStack. Cette interface est là pour vous aider à provisionner, voir et gérer votre infrastructure cloud.

1. Ouvrir votre navigateur web favori et aller à cette URL. Remplacer par l’adresse IP de votre serveur de gestion :

   http://<management-server-ip-address>:8080/client
   

   Après s’être connecté sur une nouvelle installation d’un serveur de gestion, un assistant de configuration apparaît. Lors des futures visites, vous serez directement redirigé vers le tableau de bord :

2. Si vous voyez l’écran de premier démarrage, choisissez une des options suivantes :

   • Continuer avec la configuration basique. Choisissez cette option si vous êtes juste en train d’essayer CloudStack et si vous voulez un guide pour vous aider dans la configuration la plus simple possible afin de vous permettre de démarrer rapidement. Nous vous aiderons à configurer un cloud avec les fonctionnalités suivantes : une machine unique qui fait fonctionner le logiciel CloudStack et qui utilise le service NFS comme stockage ; une machine unique faisant fonctionner des machines virtuelles sous les hyperviseurs XenServer ou KVM ; et un réseau public partagé.

     Les indications de cette visite guidée devraient vous fournir toutes les informations dont vous avez besoin, mais si vous désirez un peu plus de détails, vous pouvez suivre le Guide d’Installation.

   • J’ai déjà utilisé CloudStack. Choisissez cette option si vous avez déjà effectué une phase de design et planifié un déploiement plus sophistiqué ou si vous êtes prêts à démarrer la configuration d’un cloud d’essais que vous auriez configuré plus tôt avec les écrans de configuration basiques. Dans l’interface d’administration, vous pouvez commencer à utiliser les plus puissantes fonctionnalités de CloudStack, comme les réseaux avancés à base de VLAN, la haute disponibilité, les éléments réseaux additionnels comme les répartiteurs de charge et les pare-feu et le support de multiples hyperviseurs incluant Citrix XenServer, KVM et VMware vSphere.

     Le tableau de bord de l’administrateur apparaît.

3. Vous devriez fournir un nouveau mot de passe pour l’administrateur. Si vous choisissez la configuration basique, un nouveau mot de passe vous sera demandé juste après. Si vous choisissez Utilisateur expérimenté, suivre la procédure Changer le mot de passe Root.

Changer le mot de passe Root¶

Durant l’installation et tout au long de l’administration du cloud, vous devrez vous connecter à l’interface en tant qu’administrateur. Le compte administrateur gère le déploiement de CloudStack, incluant l’infrastructure physique. L’administrateur peut modifier les paramètres par défaut pour changer les fonctionnalités de base, créer ou supprimer des comptes utilisateurs et effectuer des actions qui ne peuvent l’être que par une personne autorisée. Lorsque vous installez CloudStack pour la première fois, pensez à changer le mot de passe par défaut pour un nouveau.

1. Ouvrir votre navigateur web favori et aller à cette URL. Remplacer par l’adresse IP de votre serveur de gestion :

   http://<management-server-ip-address>:8080/client
   

2. Se connecter à l’interface en utilisant le compte root et son mot de passe. Les valeurs par défaut sont admin, password.

3. Cliquer sur Comptes.

4. Cliquer sur le nom du compte administrateur.

5. Cliquer sur Voir les utilisateurs.

6. Cliquer sur le nom de l’administrateur.

7. Cliquer sur le bouton Changer le mot de passe.

8. Saisir le nouveau mot de passe et cliquer sur OK.

Rôles¶

Un rôle représente un ensemble de fonctions autorisées. Tous les comptes CloudStack ont un rôle qui leur est attaché et qui applique des règles qui lui autorisent ou qui lui refusent une requête d’API. Typiquement, il existe 4 rôles par défaut : admin root, admin de ressources, admin de domaine et utilisateur.

Comptes¶

Un compte représente généralement un client du fournisseur de service ou un département dans une grande organisation. Plusieurs utilisateurs peuvent exister dans un compte.

Domaines¶

Les comptes sont regroupés par domaines. Les domaines contiennent généralement plusieurs comptes qui ont une certaine relation logique entre eux et un ensemble d’administrateurs délégués avec une certaine autorité sur le domaine et ses sous-domaines. Par exemple, un fournisseur de services avec plusieurs revendeurs pourrait créer un domaine pour chaque revendeur.

Pour chaque compte créé, le Cloud crée trois types de comptes différents: administrateur root, administrateur de domaine et utilisateur.

Utilisateurs¶

Les utilisateurs sont comme des alias dans le compte. Les utilisateurs qui sont dans le même compte ne sont pas isolés les uns des autres mais sont isolés des utilisateurs des autres comptes. La plupart des installations n’ont aucune notion des utilisateurs; elles ont seulement un utilisateur par compte. Un même utilisateur ne peut pas appartenir à plusieurs comptes.

Le nom d’utilisateur est unique dans un domaine. Le même nom d’utilisateur peut exister dans d’autres domaines ou sous-domaines. Un nom de domaine peut être réutilisé seulement si le chemin complet est unique. Par exemple, vous pouvez créer root/d1, ainsi que root/exemple/d1 et root/ventes/d1.

Les administrateurs sont des comptes disposants de droits spéciaux dans le système. Il peut y avoir plusieurs administrateurs dans le système. Les administrateurs peuvent créer ou supprimer d’autres administrateurs et changer le mot de passe de n’importe quel utilisateur du système.

Administrateurs de domaine¶

Les administrateurs de domaine peuvent exécuter des opérations administratives pour les utilisateurs appartenant à leur domaine. Les administrateurs de domaine n’ont pas de visibilité sur les serveurs physiques ou sur les autres domaines.

Administrateur root¶

Les administrateurs racines ont un accès complet au système, incluant la gestion des modèles, les offres de service, les administrateurs de clientèles et les domaines.

Propriétaire d’une ressource¶

Les ressources appartiennent à un compte, elles n’appartiennent pas à un utilisateur individuel de ce compte. Par exemple, la facturation, les limites de ressources, etc. sont calculées pour un compte, elles ne le sont pas par utilisateurs. Un utilisateur peut opérer sur n’importe quelle ressource de son compte pour peu que le compte fournissant l’utilisateur dispose des privilèges pour cette opération. Les privilèges sont déterminés par le rôle. Un administrateur peut changer le propriétaire de n’importe quelle machine virtuelle d’un compte vers un autre compte en utilisant l’API assignVirtualMachine. Un administrateur de domaine ou de sous-domaine peut faire de même pour les machines virtuelles de son domaine d’un compte à un autre compte de son domaine ou de n’importe lequel de ses sous-domaines.

Comment utiliser les Hôtes Dédiés¶

Pour utiliser un hôte dédié explicitement, utiliser le type de groupe d’affinité Explicitement-dédié (voir “Groupes d’affinité”). Par exemple, lorsque une nouvelle VM est créée, un utilisateur final peut choisir de la placer dans son infrastructure dédiée. Cette opération fonctionnera seulement si une partie de son infrastructure a déjà été assignée comme dédiée au compte de l’utilisateur ou au domaine.

Comportement des hôtes, clusters, pods et zones dédiés¶

L’administrateur peut migrer à chaud des machines virtuelles depuis ses hôtes dédiés, s’il le désire, même si la destination est un hôte réservé pour un compte/domaine différent ou si un hôte est partagé (non dédié à un compte ou un domaine particulier). CloudStack va générer une alerte, mais l’opération sera permise.

Les hôtes dédiés peuvent être utilisés en conjonction avec les tags d’hôtes. Si à la fois un tag d’hôtes et une réservation sont demandées, la machine virtuelle sera placée seulement sur un hôte qui réponds aux deux requêtes. S’il n’y a pas de ressources dédiées disponible pour cet utilisateur qui n’aurait également le tag d’hôte demandé par l’utilisateur, alors la machine ne sera pas déployée.

Si vous supprimez un compte ou un domaine, tous les hôtes, les clusters, les pods, et les zones qui lui ont été dédiées sont libérées. Ils seront dorénavant disponibles pour être partagés par n’importe quel compte ou domaine, ou l’administrateur peut choisir de les dédier à nouveau à un autre compte ou un autre domaine.

Les machines virtuelles systèmes et les routeurs virtuels affecte le comportement de la réservation d’hôte. Les machines virtuelles et les routeurs virtuels appartiennent au compte système CloudStack et peuvent être déployé sur n’importe quel hôte. Ils ne respecte pas les réservations explicites. La présence de VM systèmes et de routeurs virtuels sur un hôte rendent la réservation explicite stricte inappropriée. L’hôte ne peut pas servir pour la réservation implicite puisque l’hôte a déjà des VMs d’un compte spécifique (le compte système par défaut). Toutefois, un hôte avec des VMs systèmes ou des routeurs virtuels peut être utilisé pour la réservation implicite préférée.

Restreindre les utilisateurs LDAP à un groupe :¶

• ldap.search.group.principle: ceci est optionnel et si positionné seuls les utilisateurs de ce groupe sont listés.

LDAP SSL :¶

Si le serveur LDAP nécessite SSL, vous devez activer les configurations ci-dessous. Avant d’activer SSL pour LDAP, vous devez obtenir le certificat utilisé par le serveur LDAP et l’ajouter à votre magasin de confiance. Vous devez connaître le chemin d’accès au magasin et le mot de passe.

• ldap.truststore : chemin d’accès au magasin de clefs

• ldap.truststore.password : mot de passe du magasin de clefs

Groupes LDAP :¶

• ldap.group.object: type d’objet pour un groupe au sein de LDAP. La valeur par défaut pour AD est group pour AD et groupOfUniqueNames pour openldap.

• ldap.group.user.uniquemember: attributs pour les membres d’un groupe. La valeur par défaut est member pour AD et uniquemember pour openldap.

Une fois configuré, sur la page Ajout de compte, vous verrez un bouton “Ajouter un compte LDAP” qui ouvre une boîte de dialogue et les utilisateurs sélectionnés peuvent être importés.

Vous pouvez également utiliser les commandes d’API : listLdapUsers, ldapCreateAccount et importLdapUsers.

Une fois que LDAP est activé, les utilisateurs ne seront plus autorisés à changer leurs mots de passe directement depuis depuis CloudStack.

Configurer les invitations¶

CloudStack peut être configuré de telle sorte que soit les administrateurs de projet peuvent ajouter des personnes directement à un projet ou si cela est nécessaire devoir leur envoyer une invitation qui doit être acceptée. L’invitation peut être envoyé par email ou via le compte utilisateur CloudStack. Si vous voulez que les administrateurs utilisent une invitation pour ajouter des membres à des projets, activer et configurer la fonctionnalité d’invitations dans CloudStack.

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

2. Dans la barre de navigation à gauche, cliquer sur Paramètres globaux.

3. Dans la zone de recherche, taper project et cliquer sur le bouton de recherche.

4. Dans les résultats de recherche, vous pouvez voir un petit nombre d’autres paramètres que vous devez fixer pour contrôler comment les invitations se comportent. Le tableau ci-dessous montre les paramètres de configuration globale en relation avec les invitations de projet. Cliquer sur le bouton Editer pour fixer chaque paramètre.

   Paramètres de configuration	Description
   project.invite.required	Positionner à true pour activer la fonctionnalité d’invitations.
   project.email.sender	L’adresse email à afficher dans le champ From des emails d’invitation.
   project.invite.timeout	Durée laissée à un nouveau membre pour répondre à une invitation.
   project.smtp.host	Nom de l’hôte qui agit comme serveur de messagerie pour gérer les invitations.
   project.smtp.password	(Optionnel) Mot de passe requis par le serveur SMTP. Vous devez également positionner le champ project.smtp.username et project.smtp.useAuth à true.
   project.smtp.port	Port d’écoute du serveur SMTP
   project.smtp.useAuth	Positionner à true si le serveur SMTP nécessite un utilisateur et un mot de passe.
   project.smtp.username	(Optionnel) Ne nom d’utilisateur requis par le serveur SMTP pour l’authentification.

5. Redémarrer le serveur de gestion :

   service cloudstack-management restart
   

Configurer les limitations de ressources pour les projets¶

L’administrateur de CloudStack peut fixer les limites par défaut globales pour contrôler la quantité de ressources qui peuvent appartenir à chaque projet dans le cloud. Cela permet de prévenir d’un usage incontrôlé des ressources comme les instantanés, les adresses IP et les instances de machines virtuelles. Les administrateurs de domaine peuvent passer outre ces limites de ressources pour des projets individuels de leurs domaines, tant que ces limites sont sous les valeurs globales par défaut fixée par l’administrateur racine de CloudStack. L’administrateur racine peut aussi fixer des limites inférieures pour n’importe quel projet dans le cloud.

Configurer les permissions de créateur de projet¶

Vous pouvez configurer CloudStack pour autoriser n’importe quel utilisateur à créer un nouveau projet, ou vous pouvez restreindre cette possibilité aux seuls administrateurs de CloudStack.

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

2. Dans la barre de navigation à gauche, cliquer sur Paramètres globaux.

3. Dans la boîte de recherche, saisir allow.user.create.projects.

4. Cliquer sur le bouton d’édition pour changer le paramètre .

   allow.user.create.projects

   Fixer à true pour autoriser les utilisateurs finaux à créer des projets. Fixer à false si vous voulez que seul l’administrateur racine de cloudstack et les administrateurs de domaine puisse le faire.

5. Redémarrez votre serveur de gestion.

   # service cloudstack-management restart
   

Envoyer des invitations d’adhésion au projet¶

Utiliser ces étapes pour ajouter un nouveau membre à un projet si la fonctionnalités d’invitations est activée dans le cloud comme décrit dans “Configurer les invitations”. Si la fonctionnalité d’invitations n’est pas activée, utiliser la procédure Ajouter des membres à un projet depuis l’interface.

1. Se connecter à l’interface CloudStack.

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

3. Dans la liste de choix de vue, choisir Projets.

4. Cliquer sur le nom du projet avec lequel vous voulez travailler.

5. Cliquer sur l’onglet Invitations.

6. Dans Ajouter par, sélectionner un des choix suivants :

   1. Compte - L’invitation va apparaître dans l’onglet Invitationsde l’utilisateur dans la vue Projet. Voir Utiliser la vue projet.

   2. Email - L’invitation sera envoyée à l’adresse email de l’utilisateur. Chaque invitation envoyée inclue un code unique appelé un jeton que le destinataire fournira en retour dans CloudStack lorsqu’il acceptera l’invitation. Les invitations par email fonctionneront seulement si les paramètres globaux en relation avec le serveur SMTP ont été positionnés. Voir “Configurer les invitations”.

7. Saisir le nom de l’utilisateur ou l’adresse email du nouveau membre que vous voulez ajouter et cliquer sur Inviter. Saisir le nom de l’utilisateur si vous avez choisi Compte à l’étape précédente. Si vous aviez choisi Email, saisir l’adresse email. Vous pouvez seulement inviter des personnes qui ont un compte dans ce cloud au sein du même domaine que le projet. Toutefois, vous pouvez envoyer l’invitation à n’importe quelle adresse email.

8. Pour voir et gérer les invitations que vous avez envoyés, retourner dans cet onglet. Quand une invitation est acceptée, les nouveaux membres vont apparaître dans l’onglet Comptes du projet.

Ajouter des membres à un projet depuis l’interface¶

Les étapes ci-dessous explique comment ajouter un nouveau membre à un projet si la fonctionnalité d’invitations n’est pas activée dans le cloud. Si les invitations sont activées, comme décris dans “Configurer les invitations”, utiliser la procédure “Envoyer des invitations aux membres d’un projet”.

1. Se connecter à l’interface CloudStack.

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

3. Dans la liste de choix de vue, choisir Projets.

4. Cliquer sur le nom du projet avec lequel vous voulez travailler.

5. Cliquer sur l’onglet Comptes. Les membres actuels du projet sont listés.

6. Saisir le nom de compte du nouveau membre que vous voulez ajouter et cliquer sur Ajouter le compte. Vous pouvez ajouter seulement les personnes qui ont un compte dans ce cloud et qui sont dans le même domaine que le projet.

Offre de calcul personnalisé¶

CloudStack vous fournis la flexibilité de spécifier les valeurs désirées pour le nombre de CPU, la vitesse CPU, la mémoire lorsque vous déployez une VM. En tant qu’administrateur, vous créez une offre de calcul en la marquant comme personnalisée et les utilisateurs pourront personnaliser dynamiquement les offres de calcule en spécifiant la mémoire, le CPU au moment de la création ou de la mise à jour de VM. Une offre de calcul personnalisée est la même chose qu’une offre de calcul normale à l’exception que les valeurs des paramètres dynamiques seront fixées à zéro dans les ensembles de modèles donnés. Utiliser cette offre pour déployer une VM en spécifiant des valeurs personnalisées pour les paramètres dynamiques. La mémoire, CPU et nombres de CPU sont considérés comme des paramètres dynamiques.

Les offres de calcul dynamiques peuvent être utilisées dans les cas suivants : déployer une VM, changer l’offre de calcul d’une VM stoppée et augmenter l’offre de VMs en cours de fonctionnement. Pour supporter cette fonctionnalité, un nouveau champs, Personnalisé, a été ajouté à la page Créer une offre de calcul. Si le champs personnalisé est coché, l’utilisateur sera capable de créer une offre de calcul personnalisé en remplissant les valeurs désirées du nombre de CPU, de vitesse CPU et de mémoire. Voir ? pour plus d’informations.

Enregistrer les évènements d’utilisation pour les ressources assignées dynamiquement.

Pour supporter cette fonctionnalité, les évènements d’utilisation ont été améliorées pour enregistrer les évènements des ressources assignée dynamiquement. Les évènements d’utilisation sont enregistrés lorsque la VM est créée depuis une offre de calcul personnalisée et lors des changements d’offre de calcul d’une VM stoppée ou en fonctionnement. Les valeurs de ces paramètres, comme le CPU, la vitesse, la RAM sont enregistrés.

Créer une nouvelle offre de calcul¶

Pour créer une nouvelle offre de calcul :

1. Se connecter avec les privilèges administrateur dans l’interface de CloudStack.

2. Dans la barre de navigation de gauche, cliquer sur Offres de service.

3. Dans Choisir une offre, choisir Offre de calcul.

4. Cliquer sur Ajouter une offre de calcul.

5. Dans la boîte de dialogue, faire les choix suivants :

   • Nom : N’importe quel nom souhaité pour l’offre de service.

   • Description : Une description courte pour l’offre qui peut être affichée aux utilisateurs

   • Type de stockage : Le type de disque qui doit être alloué. Les allocations locales depuis les stockages directement attachés à l’hôte sur lequel la VM est en fonctionnement. Les allocations partagées depuis un stockage accessible via NFS.

   • Personnalisée : Offres de calcul personnalisée peuvent être utilisée dans les cas suivants : déployer une VM, changer l’offre de calcul pour des VM stoppées ou en fonctionnement.

     Si le champ Personnalisé est validée, l’utilisateur final doit remplir les valeurs désirées pour le nombre de CPU, la vitesse CPU et la mémoire RAM lors du choix d’une offre de calcul personnalisée. Lorsque vous cochez la case, ces trois champs de saisie sont masquées dans la boîte de dialogue.

   • # de coeurs CPU : le nombre de coeurs qui devraient être allouée à une VM système avec cette offre. Si Personnalisé est coché, ce champ n’apparaît pas.

   • CPU (en MHz) : La vitesse CPU des coeurs qui sont alloués à cette VM système. Par exemple, “2000” fournira une fréquence d’horloge de 2GHz. Si Personnalisé est coché, ce champ n’apparaît pas.

   • Mémoire (en MB) : La quantité de mémoire en mégabytes que la VM système aura d’alloué. Par exemple, “2048” devrait fournir une allocation de 2GB de RAM. Si Personnalisé est validé, ce champ n’apparaît pas.

   • Vitesse Réseau : vitesse de transfert de données autorisée par seconde.

   • Taux de lecture disque : taux de lecture disque autorisé en bits par seconde.

   • Taux d’écriture disque : taux d’écriture disque autorisé en bits par seconde.

   • Taux de lecture disque : taux de lecture disque autorisé en IOPS (opération d’entrées/sorties par seconde).

   • Taux d’écriture disque : taux d’écriture disque autorisé en IOPS (opérations d’entrées/sorties par seconde).

   • Offre HA : Si oui, l’administrateur peut choisir d’avoir la VM système de monitorée et d’être aussi hautement disponible que possible.

   • Type de QoS : Trois options : Vide (pas de qualité de service), hyperviseur (taux de limitation forcé du côté hyperviseur) et stockage (IOPS minimum et maximum garantis forcé du côté stockage). Si vous tirez parti de la QoS, soyez sur que le système de l’hyperviseur ou du stockage supporte cette fonctionnalité.

   • IOPS personnalisé : si coché, l’utilisateur peut fixer ses propres IOPS. Si non coché, l’administrateur racine peut définir les valeurs. Si l’admin racine ne fixe pas les valeurs lors de l’utilisation de la QoS du stockage, les valeurs par défaut sont utilisés (les valeurs par défaut peuvent être changée si les paramètres par défaut sont passés à CloudStack lors de la création du stockage primaire en question).

   • IOPS min : apparaît seulement si la QoS du stockage doit être utilisée. Fixer un nombre de IOPS garanties forcé du côté du stockage.

   • IOPS Max : Apparaît seulement si la QoS doit être utilisée. Fixer un nombre de IOPS maximum a forcer du côté stockage (le système peut aller au delà de ces limites dans certaines circonstances pour des intervalles courts).

   • Réserve d’instantanés sur l’Hyperviseur : Pour les stockages gérés seulement. C’est une valeur qui est un pourcentage de la taille du disque racine. Si le disque racine est de 20GB et que la réserve d’instantanée sur l’hyperviseur est de 200%, le volume de stockage qui est réservé sur le dépôt de stockage (XenServer) ou sur le datastore (VMware) en question est taillée à 60GB (20 GB + (20 GB * 2)). Ceci valide de l’espace pour les instantanés en complément du disque virtuel qui représente le disque racine. Ceci ne s’applique pas à KVM.

   • Étiquettes de stockage : Les étiquettes qui devraient être associées avec le stockage primaire utilisé par la VM système.

   • Étiquettes d’hôte : (Optionnel) Toutes étiquettes que vous utilisez pour organiser vos hôtes

   • CPU cap : Pour limiter le taux d’utilisation du CPU ou si les réserves de capacités sont disponibles.

   • Public : Indique si l’offre de service doit être disponible pour tous les domaines ou seulement pour certains domaines. Choisir Oui pour rendre disponible à tous les domaines. Choisir No pour limiter la portée à un sous-domaine ; CloudStack va alors demander le nom du sous-domaine.

   • Est volatile : Si coché, la VM crée depuis cette offre de service aura ces disques racines réinitialisés à chaque redémarrage. C’est utilise pour sécuriser des environnements qui ont besoin d’un démarrage neuf à chaque démarrage et pour les bureaux qui ne doivent pas retenir les états.

   • Planning de déploiement : Choisir la technique que vous voulez que Cloudstack utilise lorsqu’il déploie la VM basée sur cette offre de service.

     First Fit place les nouvelles VMs sur le premier hôte qu’il trouve disposant de suffisamment de capacité pour supporter les besoins de la VM.

     User Dispersing fait le maximum d’efforts pour distribuer équitablement les VMs appartenant au même compte sur des clusters ou des pods différents.

     User Concentrated préfère déployer les VMs appartenant au même compte sur un pod unique.

     L’attribution implicite va déployer les VMs sur une infrastructure privée qui est dédiée à un domaine spécifique ou un compte. Si vous choisissez cette planification, alors vous devez aussi choisir une valeur pour le Mode de planification. Voir “Dédier des ressources à des comptes et des domaines”.

     Bare Metal est utilisé avec les hôtes bare metal. Voir Installation Bare Metal dans le guide d’installation.

   • Mode de planification : Utilisé quand ImplicitDedicationPlanner est sélectionné dans le champ précédent. Le mode de planification détermine comment les VMs vont être déployée sur une infrastructure privée qui est dédiée à un seul domaine ou à un compte.

     Strict : Un hôte ne sera pas partagé par plusieurs comptes. Par exemple, la attribution implicite stricte est utile pour le déploiement de certains types d’applications, comme les Bureaux, où aucune hôte ne peut être partagé entre différents comptes sans violer les termes de licence du logiciel de bureau.

     Préférée : La VM sera déployée dans une infrastructure dédiée si possible. Sinon, la VM peut être déployée dans une infrastructure partagée.

   • GPU Assigne un GPU physique (GPU-passthrough) ou un portion d’un GPU physique

     Carte GPU (vGPU) à la VM invitée. Cela permet à des applications graphique de fonctionner sur la VM. Sélectionner la carte depuis la liste des cartes supportées.

     Les options proposées sont NVIDIA GRID K1 et NVIDIA GRID K2. Ces cartes vGPU sont capables d’autoriser plusieurs vGPUs sur un seul GPU physique. Si vous voulez utiliser une carte plutôt que celles-ci, suivre les instructions dans la page “Support GPU et vGPU pour les VMs invitées CloudStack” dans le document de conception CloudStack Version 4.4 que vous trouverez dans le wiki CloudStack.

   • Type vGPU : Représente le type de GPU virtuel à assigner à la VM invitée. Dans ce cas, seulement une partie de la carte physique GPU (vGPU) est attribuée à la VM invitée.

     En complément, le type passthrough vGPU est défini pour représenter un périphérique GPU physique. Un passthrough vGPU peu être directement assigné à une seule VM invitée. Dans ce cas, un périphérique physique GPU est exclusivement alloué à une seule VM invitée.

6. Cliquer sur Ajouter.

Créer une Nouvelle offre de disque.¶

Pour créer une nouvelle offre de disque :

1. Se connecter avec les privilèges administrateur dans l’interface de CloudStack.

2. Dans la barre de navigation de gauche, cliquer sur Offres de service.

3. Dans Sélectionner une offre, choisir Offre de disque.

4. Cliquer sur Ajouter une offre de disque.

5. Dans la boîte de dialogue, faire les choix suivants :

   • Nom : N’importe quel nom souhaité pour l’offre de disque.

   • Description : Une description courte pour l’offre qui peut être affichée aux utilisateurs

   • Taille de disque personnalisée : Si cochée, l’utilisateur peut fixer sa propre taille de disque. Si non cochée, l’administrateur racine doit définir une taille de disque.

   • Taille de disque : Apparaît seulement si la taille de disque personnalisée n’est pas sélectionnée. Définir une taille de volume en GB (2^30 1GB = 1,073,741,824 Bytes).

   • Type de QoS : Trois options : Vide (pas de qualité de service), hyperviseur (taux de limitation forcé du côté hyperviseur) et stockage (IOPS minimum et maximum garantis forcé du côté stockage). Si vous tirez parti de la QoS, soyez sur que le système de l’hyperviseur ou du stockage supporte cette fonctionnalité.

   • IOPS personnalisé : si coché, l’utilisateur peut fixer ses propres IOPS. Si non coché, l’administrateur racine peut définir les valeurs. Si l’admin racine ne fixe pas les valeurs lors de l’utilisation de la QoS du stockage, les valeurs par défaut sont utilisés (les valeurs par défaut peuvent être changée si les paramètres par défaut sont passés à CloudStack lors de la création du stockage primaire en question).

   • IOPS min : apparaît seulement si la QoS du stockage doit être utilisée. Fixer un nombre de IOPS garanties forcé du côté du stockage.

   • IOPS Max : Apparaît seulement si la QoS doit être utilisée. Fixer un nombre de IOPS maximum a forcer du côté stockage (le système peut aller au delà de ces limites dans certaines circonstances pour des intervalles courts).

   • Rétention d’instantanés de l’hyperviseur : pour le stockage de gestion seulement. C’est une valeur qui est un pourcentage de la taille du disque de données. Par exemple, si le disque de données fait 20GB et que la rétention d’instantanés de l’hyperviseur est de 200%, alors le stockage de volume qui soutient le stockage de données (XenServer) ou le datastore (VMware) en question est taillé à 60 GB (20 GB + (20 GB *2)). Cela active de l’espace pour les instantannés de l’hyperviseur en complétement au disque virtuel qui représente les données du disque. Cela ne s’applique pas à KVM.

   • (Optionnel) Etiquettes de stockage : Les étiquettes qui devraient être associées avec le stockage primaire pour ce disque. Les étiquettes sont des listes d’attributs du stockage séparés par des virgules. Par exemple “ssd,bleu”. Les étiquettes sont aussi ajoutées sur le stockage primaire. CloudStack fait correspondre les étiquettes de l’offre de disque aux étiquettes sur le stockage. Si une étiquette est présente sur une offre de disque cette ou ces étiquettes doivent aussi être présente sur le stockage primaire pour que le volume soit provisionné. S’il n’existe pas un tel stockage primaire, l’attribution depuis l’offre de disque va échouer.

   • Public : Indique si l’offre de service doit être disponible pour tous les domaines ou seulement pour certains domaines. Choisir Oui pour rendre disponible à tous les domaines. Choisir No pour limiter la portée à un sous-domaine ; CloudStack va alors demander le nom du sous-domaine.

6. Cliquer sur Ajouter.

Modifier ou détruire une offre de service¶

Les offres de service ne peuvent pas être changée une fois crée. Ceci s’applique à la fois aux offres de calcul et aux offres de disque.

Une offre de service peut être supprimée. Si elle n’est plus utilisée, elle est détruite immédiatement et de façon permanente. Si l’offre de service est toujours utlisée, elle restera en base de données jusqu’à ce que toutes les machines virtuelles la référençant ont été supprimées. Après la suppression par l’administrateur, l’offre de service ne sera plus disponible pour les utilisateurs finaux qui créent de nouvelles instances.

Créer une Nouvelle offre de service système¶

Pour créer une offre de service système :

1. Se connecter avec les privilèges administrateur dans l’interface de CloudStack.

2. Dans la barre de navigation de gauche, cliquer sur Offres de service.

3. Dans Choisir l’offre, choisir Offre système.

4. Cliquer sur Ajouter une offre de service système.

5. Dans la boîte de dialogue, faire les choix suivants :

   • Nom. N’importe quel nom pour l’offre système.

   • Description. Une description courte pour l’offre qui peut être affichée aux utilisateurs.

   • Type de VM système. Sélectionner le type de machine virtuelle système que cette offre est destinée à supporter.

   • Type de stockage. Le type de disque qui peut être alloué. L’allocation locale depuis un stockage attaché directement à l’hôte où la VM système fonctionne. Les partagées allouent depuis un stockage accessible via NFS.

   • # de coeurs CPU : le nombre de coeurs qui devraient être alloués à la VM système avec cette offre.

   • CPU (en MHz). La vitesse CPU des coeurs alloués à la VM système. Par exemple, “2000” devrait fournir une vitesse d’horloge de 2Ghz.

   • Mémoire (en MB). La quantité de mémoire en mégabytes qui devrait être allouée à la VM système. Par exemple, “2048” devrait fournir une allocation de 2 GB de RAM.

   • Vitesse réseau. Vitesse de transfert de données autorisé en MB par seconde.

   • Offre HA. Si oui, l’administrateur peut choisir d’avoir la VM système de monitorée et d’être aussi hautement disponible que possible.

   • Etiquettes de stockage. Les étiquettes qui sont associées avec le stockage primaire utilisé par la VM système.

   • Etiquettes d’hôtes. (Optionnel) N’importe quelle étiquette que vous utilisez pour organiser vos hôtes.

   • CPU cap. Pour limiter le taux d’utilisation du CPU si la capacité de réserve est disponible.

   • Public. Indique si l’offre de service devrait être disponible dans tous les domaines ou seulement certains domaines. Choisir Oui pour le rendre disponible à tous les domaines. Choisir No pour limiter la portée à un sous-domaine ; CloudStack va alors demander le nom du sous-domaine.

6. Cliquer sur Ajouter.

Réseaux isolés¶

Un réseau isolé peut être accédé seulement par les machines virtuelles d’un seul compte. Les réseaux isolés ont les propriétés suivantes.

• Les ressources comme les VLAN sont alloués et recyclés dynamiquement

• Il y a une offre réseau pour le réseau entier

• L’offre réseau peut être amélioré ou rétrogradé mais pour le réseau entier

Pour plus d’information, voir “Configurer le Trafic Invité dans une Zone Avancée”.

Réseaux partagés¶

Un réseau partagé peut être accédé par les machines virtuelles qui appartiennent à pleins de comptes différents. L’isolation du réseau dans les réseaux partagés est obtenue en utilisant des techniques comme les groupes de sécurité, qui sont supportés seulement dans les zones Basiques dans CloudStack 3.0.3 et versions ultérieures.

• Les Réseaux Partagés sont créés par l’administrateur

• Les Réseaux Partagés peuvent être désignés pour un domaine particulier

• Les ressources d’un Réseau Partagé comme les VLAN et le réseau physique qui lui est attaché sont désignés par l’administrateur

• Les Réseaux Partagés peuvent être isolés par les groupes de sécurité

• Le Réseau Public est un réseau partagé qui n’est pas affiché aux utilisateurs finaux.

• Le NAT source par zone n’est pas supporté dans un Réseau Partagé quand le fournisseur de service est un routeur virtuel. Toutefois, le NAT source par compte est supporté. Pour plus d’information, voir “Configurer un Réseau Partagé Invité”.

L’allocation à chaud de Ressources de Réseau Virtuel¶

Quand vous définissez un nouveau réseau virtuel, tous vos paramètres pour ce réseau sont stockés dans CloudStack. Les ressources du réseau actuel sont activées seulement lorsque la première machine virtuelle dans le réseau démarre. Quand toutes les machines virtuelles ont quittés le réseau virtuel, les ressources du réseau sont récupérés et recyclée afin de pouvoir être à nouveau allouée. Cela aide à conserver les ressources réseaux.

Créer une nouvelle offre de service Réseau¶

Pour créer une offre de réseau :

1. Se connecter avec les droits d’administrateur à l’interface CloudStack.

2. Dans la barre de navigation de gauche, cliquer sur les Offres de Service.

3. Dans Sélectionner une offre, choisir une offre réseau.

4. Cliquer sur Ajouter une offre de réseau.

5. Dans la boîte de dialogue, faire les choix suivants :

   • Nom : N’importe quel nom souhaité pour l’offre de réseau.

   • Description : Une description courte pour l’offre qui peut être affichée aux utilisateurs.

   • Vitesse Réseau : Vitesse de transfert de données autorisée en MB par seconde.

   • Type d’invité. Choisir si le réseau invité est isolé ou partagé.

     Pour une description de ces termes, voir “A propos des Réseaux Virtuels”.

   • Persistent. Indique si le réseau invité est persistent ou pas. Le réseau que vous pouvez provisionner sans avoir à déployer une VM sur celui-ci est appelé réseau persistant. Pour plus d’informations, voir “Réseaux Persistants”.

   • Spécifier un VLAN. (Réseaux invités isolés seulement) Indique si un VLAN peut être spécifié quand cette offre est utilisée. Si vous sélectionnez cette option et plus tard utilisez cette offre réseau lors de la création d’un VPC ou un réseau isolé, vous pourrez spécifier un ID de VLAN pour le réseau que vous créez.

   • VPC. Cette option indique si le réseau invité est activable pour un Cloud Virtuel Privé. Un Cloud Virtuel Privé (VPC) est une partie de CloudStack privée, isolée. Un VPC peut avoir sa propre topologie réseau virtuelle qui ressemble a un réseau privé traditionnel. Pour plus d’informations sur les VPC, voir “A propos des Clouds Privés Virtuels”.

   • Services supportés. Sélectionner un ou plusieurs des services réseaux possibles. Pour certains services, vous devez aussi choisir le fournisseur de service ; par exemple, si vous sélectionnez un Répartiteur de Charge, vous pouvez choisir le routeur virtuel CloudStack ou n’importe quels autres répartiteurs qui ont été configurés dans la cloud. En fonction du service que vous avez choisi, des champs additionnels peuvent apparaître dans le reste de la boîte de dialogue.

     En fonction du type de réseau invité sélectionné, vous pouvez voir les services supportés suivants :

     Services supportés	Description	Isolé	Partagé
     DHCP	Pour plus d’informations, voir “DNS et DHCP”.	Supporté	Supporté
     DNS	Pour plus d’informations, voir “DNS et DHCP”.	Supporté	Supporté
     Répartition de charge	Si vous choisissez Répartiteur de Charge, vous pouvez choisir le routeur virtuel CloudStack ou n’importe quel répartiteur de charge qui a été configuré dans le cloud.	Supporté	Supporté
     Pare-feu	Pour plus d’informations, voir le Guide d’Administration.	Supporté	Supporté
     Source NAT	Si vous sélectionnez Source NAT, vous pouvez choisir le routeur virtuel CloudStack ou n’importe quel autre fournisseur de Source NAT qui a été configuré dans le cloud.	Supporté	Supporté
     Static NAT	Si vous sélectionnez NAT Statique, vous pouvez choisir le routeur virtuel CloudStack ou n’importe quel autre fournisseur de NAT Statique qui a été configuré dans le cloud.	Supporté	Supporté
     Port Forwarding	Si vous sélectionnez Transmission de Port, vous pouvez choisir le routeur virtuel CloudStack ou n’importe quel fournisseur de Transmission de Port qui a été configuré dans le cloud.	Supporté	Non supporté
     VPN	Pour plus d’informations, voir “Accès distant VPN”.	Supporté	Non supporté
     Donnée utilisateur	Pour plus d’informations, voir “Données et Méta-données utilisateur”.	Non supporté	Supporté
     ACL réseau	Pour plus d’informations, voir “Configurer les Listes de Contrôles d’Accès Réseau”.	Supporté	Non supporté
     Groupes de sécurité	Pour plus d’informations, voir “Ajouter un groupe de sécurité”.	Non supporté	Supporté

   • Offre système. Si le fournisseur de service pour n’importe lequel des services sélectionnés dans les Services Supportés est un routeur virtuel, le champ Offre Système apparaît. Choisir l’offre de service système que vous voulez que les routeurs virtuels utilisent dans ce réseau. Par exemple, si vous avez sélectionné Répartiteur de Charge dans les Services Supportés et sélectionné un routeur virtuel pour fournir la répartition de charge, le champ Offre Système apparaît afin que vous puissiez choisir entre l’offre de service système par défaut de CloudStack ou n’importe quelle offre de service système personnalisée qui a été définie par l’administrateur CloudStack.

     Pour plus d’informations, voir “Offres de service système”.

   • LB Isolation : Spécifie quel type d’isolation par répartiteur de charge vous voulez pour le réseau : Partagé ou Dédié.

     Dédié : Si vous sélectionnez une isolation par LB dédié, un périphérique répartiteur de charge dédié est assignée pour le réseau depuis la réserve de périphériques de répartition de charge dédiés provisionnés dans la zone. Si aucun périphérique de répartition de charge dédié n’est disponible dans la zone, la création du réseau échoue. Un périphérique dédié est un bon choix pour les réseaux à fort trafic qui font un usage complet des ressources du périphérique.

     Partagé : Si vous sélectionnez une isolation par LB partagé, un périphérique de répartition de charge partagé est assigné pour le réseau depuis la réserve des périphériques de répartiteurs de charge partagés provisionnés dans la zone. Lors du provisionnement, CloudStack choisit le périphérique de répartition de charge partagé qui est utilisé par le plus petit nombre de comptes. Une fois que le périphérique a atteint le maximum de ses capacités, le périphérique ne sera plus attribué à de nouveaux comptes.

   • Mode : Vous pouvez sélectionner soit le mode En ligne ou le mode Côte à Côte.

     Mode en ligne : Supporté seulement par les pare-feu Juniper SRX et les périphériques de répartition de charge BigF5. Dans le mode en ligne, un périphérique parefeu est placé devant un périphérique de répartition de charge. Le parefeu agit comme une passerelle pour tout le trafic entrant qui redirige tout le trafic à répartir au répartiteur de charge derrière lui. Le répartiteur de charge dans ce cas n’aura pas laccès directement au réseau public.

     Côte à côte : Dans le mode côte à côte, un périphérique de parefeu est déployé en parallèle du périphérique de répartition de charge. Le trafic vers l’adresse IP publique du répartiteur de charge n’est pas routé via le parefeu, et par conséquent il est exposé au réseau public.

   • IP publique associée : Sélectionnez cette option si vous voulez assigner une adresse IP publique aux VMs déployées dans le réseau invité. Cette option est disponible seulement si

     • Le réseau invité est partagé.

     • Le NAT-age statique est activé.

     • Elastic IP est activé.

     Pour des informations sur Elastic IP, voir “A propos d’Elastic IP”.

   • Capacité de routeur redondant : disponible seulement quand le Routeur Virtuel est sélectionné comme fournisseur de Source NAT. Sélectionner cette option si vous voulez utiliser 2 routeurs virtuels dans le réseau pour des connexion ininterrompues : un opère comme routeur virtuel maître et l’autre comme secours. Le routeur virtuel maître reçoit les requêtes des VMs utilisateurs et leur envoi les réponses. Le routeur virtuel de secours est activé seulement quand le maître est indisponible. Après la panne, le secours devient le routeur virtuel maître. CloudStack déploie les routeurs sur des hôtes différents pour assurer la fiabilité si un des hôtes est indisponible.

   • Mode conservation : Indique si le mode conservation est utilisé. Dans ce mode, les ressources réseaux sont allouée seulement lorsque la première machine virtuelle démarre dans le réseau. Quand le mode de conservation est arrêté, l’IP publique peut seulement être utilisée pour un seul périphérique. Par exemple, une IP publique utilisée pour une règle de transmission de port ne peut pas être utilisée pour définir d’autres services, comme le StaticNAT ou la répartition de charge. Quand le mode de conservation est activé, vous pouvez définir plus d’un service avec la même IP publique.

     Note

     Si le StaticNAT est activé, quelque soit le statut du mode conservé, aucune transmission de port ou règle de répartition de charge he peut être crée pour l’IP. Toutefois, vous pouvez ajouter les règles de pare-feu en utilisant la commande createFirewallRule.

   • Etiquettes : Etiquette réseau pour spécifier quel réseau physique utiliser.

   • Politique de sortie par défaut : Configurer la politique par défaut pour les règles sortantes par défaut. Les options sont Autoriser ou Refuser. La valeur par défaut est Autoriser si aucune règle sortante n’est spécifiée, ce qui indique que tout le trafic sortant est accepté lorsque le réseau invité est crée depuis cette offre.

     Pour bloquer le trafic sortant pour un réseau invité, sélectionner Refuser. Dans ce cas, lorsque vous configurez des règles sortantes pour un réseau invité isolé, les règles sont ajoutées pour autoriser le trafic spécifié.

6. Cliquer sur Ajouter.

Surveiller la capacité maximale de VM¶

The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.

Installez les outils et les pilotes requis¶

Be sure the following are installed on each VM:

• For XenServer, install PV drivers and Xen tools on each VM. This will enable live migration and clean guest shutdown. Xen tools are required in order for dynamic CPU and RAM scaling to work.
• For vSphere, install VMware Tools on each VM. This will enable console view to work properly. VMware Tools are required in order for dynamic CPU and RAM scaling to work.

To be sure that Xen tools or VMware Tools is installed, use one of the following techniques:

• Create each VM from a template that already has the tools installed; or,
• When registering a new template, the administrator or user can indicate whether tools are installed on the template. This can be done through the UI or using the updateTemplate API; or,
• If a user deploys a virtual machine with a template that does not have Xen tools or VMware Tools, and later installs the tools on the VM, then the user can inform CloudStack using the updateVirtualMachine API. After installing the tools and updating the virtual machine, stop and start the VM.

Affinity Groups¶

By defining affinity groups and assigning VMs to them, the user or administrator can influence (but not dictate) which VMs should run on separate hosts. This feature is to let users specify that VMs with the same “host anti-affinity” type won’t be on the same host. This serves to increase fault tolerance. If a host fails, another VM offering the same service (for example, hosting the user’s website) is still up and running on another host.

The scope of an affinity group is per user account.

Limitations on VM Snapshots¶

• If a VM has some stored snapshots, you can’t attach new volume to the VM or delete any existing volumes. If you change the volumes on the VM, it would become impossible to restore the VM snapshot which was created with the previous volume structure. If you want to attach a volume to such a VM, first delete its snapshots.
• VM snapshots which include both data volumes and memory can’t be kept if you change the VM’s service offering. Any existing VM snapshots of this type will be discarded.
• You can’t make a VM snapshot at the same time as you are taking a volume snapshot.
• You should use only CloudStack to create VM snapshots on hosts managed by CloudStack. Any snapshots that you make directly on the hypervisor will not be tracked in CloudStack.

Configuring VM Snapshots¶

The cloud administrator can use global configuration variables to control the behavior of VM snapshots. To set these variables, go through the Global Settings area of the CloudStack UI.

Configuration Setting Name

Description

vmsnapshots.max

The maximum number of VM snapshots that can be saved for any given virtual machine in the cloud. The total possible number of VM snapshots in the cloud is (number of VMs) * vmsnapshots.max. If the number of snapshots for any VM ever hits the maximum, the older ones are removed by the snapshot expunge job.

vmsnapshot.create.wait

Number of seconds to wait for a snapshot job to succeed before declaring failure and issuing an error.

Using VM Snapshots¶

To create a VM snapshot using the CloudStack UI:

1. Log in to the CloudStack UI as a user or administrator.

2. Click Instances.

3. Click the name of the VM you want to snapshot.

4. Click the Take VM Snapshot button.

   Note

   If a snapshot is already in progress, then clicking this button will have no effect.

5. Provide a name and description. These will be displayed in the VM Snapshots list.

6. (For running VMs only) If you want to include the VM’s memory in the snapshot, click the Memory checkbox. This saves the CPU and memory state of the virtual machine. If you don’t check this box, then only the current state of the VM disk is saved. Checking this box makes the snapshot take longer.

7. Quiesce VM: check this box if you want to quiesce the file system on the VM before taking the snapshot. Not supported on XenServer when used with CloudStack-provided primary storage.

   When this option is used with CloudStack-provided primary storage, the quiesce operation is performed by the underlying hypervisor (VMware is supported). When used with another primary storage vendor’s plugin, the quiesce operation is provided according to the vendor’s implementation.

8. Cliquez sur OK.

To delete a snapshot or restore a VM to the state saved in a particular snapshot:

1. Navigate to the VM as described in the earlier steps.

2. Click View VM Snapshots.

3. In the list of snapshots, click the name of the snapshot you want to work with.

4. Depending on what you want to do:

   To delete the snapshot, click the Delete button.

   To revert to the snapshot, click the Revert button.

CPU and Memory Scaling for Running VMs¶

(Supported on VMware and XenServer)

It is not always possible to accurately predict the CPU and RAM requirements when you first deploy a VM. You might need to increase these resources at any time during the life of a VM. You can dynamically modify CPU and RAM levels to scale up these resources for a running VM without incurring any downtime.

Dynamic CPU and RAM scaling can be used in the following cases:

• User VMs on hosts running VMware and XenServer.
• System VMs on VMware.
• VMware Tools or XenServer Tools must be installed on the virtual machine.
• The new requested CPU and RAM values must be within the constraints allowed by the hypervisor and the VM operating system.
• New VMs that are created after the installation of CloudStack 4.2 can use the dynamic scaling feature. If you are upgrading from a previous version of CloudStack, your existing VMs created with previous versions will not have the dynamic scaling capability unless you update them using the following procedure.

Updating Existing VMs¶

If you are upgrading from a previous version of CloudStack, and you want your existing VMs created with previous versions to have the dynamic scaling capability, update the VMs using the following steps:

1. Make sure the zone-level setting enable.dynamic.scale.vm is set to true. In the left navigation bar of the CloudStack UI, click Infrastructure, then click Zones, click the zone you want, and click the Settings tab.
2. Install Xen tools (for XenServer hosts) or VMware Tools (for VMware hosts) on each VM if they are not already installed.
3. Stop the VM.
4. Click the Edit button.
5. Click the Dynamically Scalable checkbox.
6. Click Apply.
7. Restart the VM.

Configuring Dynamic CPU and RAM Scaling¶

To configure this feature, use the following new global configuration variables:

• enable.dynamic.scale.vm: Set to True to enable the feature. By default, the feature is turned off.
• scale.retry: How many times to attempt the scaling operation. Default = 2.

How to Dynamically Scale CPU and RAM¶

To modify the CPU and/or RAM capacity of a virtual machine, you need to change the compute offering of the VM to a new compute offering that has the desired CPU and RAM values. You can use the same steps described above in “Changing the Service Offering for a VM”, but skip the step where you stop the virtual machine. Of course, you might have to create a new compute offering first.

When you submit a dynamic scaling request, the resources will be scaled up on the current host if possible. If the host does not have enough resources, the VM will be live migrated to another host in the same cluster. If there is no host in the cluster that can fulfill the requested level of CPU and RAM, the scaling operation will fail. The VM will continue to run as it was before.

Limitations¶

• You can not do dynamic scaling for system VMs on XenServer.
• CloudStack will not check to be sure that the new CPU and RAM levels are compatible with the OS running on the VM.
• When scaling memory or CPU for a Linux VM on VMware, you might need to run scripts in addition to the other steps mentioned above. For more information, see Hot adding memory in Linux (1012764) in the VMware Knowledge Base.
• (VMware) If resources are not available on the current host, scaling up will fail on VMware because of a known issue where CloudStack and vCenter calculate the available capacity differently. For more information, see https://issues.apache.org/jira/browse/CLOUDSTACK-1809.
• On VMs running Linux 64-bit and Windows 7 32-bit operating systems, if the VM is initially assigned a RAM of less than 3 GB, it can be dynamically scaled up to 3 GB, but not more. This is due to a known issue with these operating systems, which will freeze if an attempt is made to dynamically scale from less than 3 GB to more than 3 GB.

Adding an ISO¶

To make additional operating system or other software available for use with guest VMs, you can add an ISO. The ISO is typically thought of as an operating system image, but you can also add ISOs for other types of software, such as desktop applications that you want to be installed as part of a template.

1. Log in to the CloudStack UI as an administrator or end user.

2. In the left navigation bar, click Templates.

3. In Select View, choose ISOs.

4. Click Add ISO.

5. In the Add ISO screen, provide the following:

   • Name: Short name for the ISO image. For example, CentOS 6.2 64-bit.

   • Description: Display test for the ISO image. For example, CentOS 6.2 64-bit.

   • URL: The URL that hosts the ISO image. The Management Server must be able to access this location via HTTP. If needed you can place the ISO image directly on the Management Server

   • Zone: Choose the zone where you want the ISO to be available, or All Zones to make it available throughout CloudStack.

   • Bootable: Whether or not a guest could boot off this ISO image. For example, a CentOS ISO is bootable, a Microsoft Office ISO is not bootable.

   • OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.

     • If the operating system of your desired ISO image is listed, choose it.
     • If the OS Type of the ISO is not listed or if the ISO is not bootable, choose Other.
     • (XenServer only) If you want to boot from this ISO in PV mode, choose Other PV (32-bit) or Other PV (64-bit)
     • (KVM only) If you choose an OS that is PV-enabled, the VMs created from this ISO will have a SCSI (virtio) root disk. If the OS is not PV-enabled, the VMs will have an IDE root disk. The PV-enabled types are:
       • Fedora 13
       • Fedora 12
       • Fedora 11
       • Fedora 10
       • Fedora 9
       • Other PV
       • Debian GNU/Linux
       • CentOS 5.3
       • CentOS 5.4
       • CentOS 5.5
       • Red Hat Enterprise Linux 5.3
       • Red Hat Enterprise Linux 5.4
       • Red Hat Enterprise Linux 5.5
       • Red Hat Enterprise Linux 6

     Note

     It is not recommended to choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will usually not work. In these cases, choose Other.

   • Extractable: Choose Yes if the ISO should be available for extraction.

   • Public: Choose Yes if this ISO should be available to other users.

   • Featured: Choose Yes if you would like this ISO to be more prominent for users to select. The ISO will appear in the Featured ISOs list. Only an administrator can make an ISO Featured.

6. Cliquez sur OK.

   The Management Server will download the ISO. Depending on the size of the ISO, this may take a long time. The ISO status column will display Ready once it has been successfully downloaded into secondary storage. Clicking Refresh updates the download percentage.

7. Important: Wait for the ISO to finish downloading. If you move on to the next task and try to use the ISO right away, it will appear to fail. The entire ISO must be available before CloudStack can work with it.

Attacher une ISO à une VM¶

1. Sur la gauche, cliquez sur Instances

2. Choisissez la machine virtuelle avec laquelle vous souhaitez travailler.

3. Click the Attach ISO button.

4. Dans la boîte de dialogue Attacher une ISO, sélectionnez l’ISO voulue.

5. Cliquez sur OK.

Changing a VM’s Base Image¶

Every VM is created from a base image, which is a template or ISO which has been created and stored in CloudStack. Both cloud administrators and end users can create and modify templates, ISOs, and VMs.

In CloudStack, you can change an existing VM’s base image from one template to another, or from one ISO to another. (You can not change from an ISO to a template, or from a template to an ISO).

For example, suppose there is a template based on a particular operating system, and the OS vendor releases a software patch. The administrator or user naturally wants to apply the patch and then make sure existing VMs start using it. Whether a software update is involved or not, it’s also possible to simply switch a VM from its current template to any other desired template.

To change a VM’s base image, call the restoreVirtualMachine API command and pass in the virtual machine ID and a new template ID. The template ID parameter may refer to either a template or an ISO, depending on which type of base image the VM was already using (it must match the previous type of image). When this call occurs, the VM’s root disk is first destroyed, then a new root disk is created from the source designated in the template ID parameter. The new root disk is attached to the VM, and now the VM is based on the new template.

You can also omit the template ID parameter from the restoreVirtualMachine call. In this case, the VM’s root disk is destroyed and recreated, but from the same template or ISO that was already in use by the VM.

Creating an Instance Template that Supports SSH Keys¶

Create an instance template that supports SSH Keys.

1. Create a new instance by using the template provided by cloudstack.

   For more information on creating a new instance, see

2. Download the cloudstack script from The SSH Key Gen Script to the instance you have created.

   wget http://downloads.sourceforge.net/project/cloudstack/SSH%20Key%20Gen%20Script/cloud-set-guest-sshkey.in?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fcloudstack%2Ffiles%2FSSH%2520Key%2520Gen%2520Script%2F&ts=1331225219&use_mirror=iweb
   

3. Copy the file to /etc/init.d.

   cp cloud-set-guest-sshkey.in /etc/init.d/
   

4. Give the necessary permissions on the script:

   chmod +x /etc/init.d/cloud-set-guest-sshkey.in
   

5. Run the script while starting up the operating system:

   chkconfig --add cloud-set-guest-sshkey.in
   

6. Stop the instance.

Creating the SSH Keypair¶

You must make a call to the createSSHKeyPair api method. You can either use the CloudStack Python API library or the curl commands to make the call to the cloudstack api.

For example, make a call from the cloudstack server to create a SSH keypair called “keypair-doc” for the admin account in the root domain:

1. Run the following curl command:

   curl --globoff "http://localhost:8096/?command=createSSHKeyPair&name=keypair-doc&account=admin&domainid=5163440e-c44b-42b5-9109-ad75cae8e8a2"
   

   The output is something similar to what is given below:

   <?xml version="1.0" encoding="ISO-8859-1"?><createsshkeypairresponse cloud-stack-version="3.0.0.20120228045507"><keypair><name>keypair-doc</name><fingerprint>f6:77:39:d5:5e:77:02:22:6a:d8:7f:ce:ab:cd:b3:56</fingerprint><privatekey>-----BEGIN RSA PRIVATE KEY-----
   MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
   dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
   AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
   mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
   QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
   VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
   lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
   nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
   4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
   KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
   -----END RSA PRIVATE KEY-----
   </privatekey></keypair></createsshkeypairresponse>
   

2. Copy the key data into a file. The file looks like this:

   -----BEGIN RSA PRIVATE KEY-----
   MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
   dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
   AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
   mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
   QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
   VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
   lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
   nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
   4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
   KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
   -----END RSA PRIVATE KEY-----
   

3. Save the file.

Creating an Instance¶

After you save the SSH keypair file, you must create an instance by using the template that you created at Section 5.2.1, “ Creating an Instance Template that Supports SSH Keys”. Ensure that you use the same SSH key name that you created at Section 5.2.2, “Creating the SSH Keypair”.

A sample curl command to create a new instance is:

curl --globoff http://localhost:<port number>/?command=deployVirtualMachine\&zoneId=1\&serviceOfferingId=18727021-7556-4110-9322-d625b52e0813\&templateId=e899c18a-ce13-4bbf-98a9-625c5026e0b5\&securitygroupids=ff03f02f-9e3b-48f8-834d-91b822da40c5\&account=admin\&domainid=1\&keypair=keypair-doc

Substitute the template, service offering and security group IDs (if you are using the security group feature) that are in your cloud environment.

Logging In Using the SSH Keypair¶

To test your SSH key generation is successful, check whether you can log in to the cloud setup.

For example, from a Linux OS, run:

ssh -i ~/.ssh/keypair-doc <ip address>

The -i parameter tells the ssh client to use a ssh key found at ~/.ssh/keypair-doc.

Resetting SSH Keys¶

With the API command resetSSHKeyForVirtualMachine, a user can set or reset the SSH keypair assigned to a virtual machine. A lost or compromised SSH keypair can be changed, and the user can access the VM by using the new keypair. Just create or register a new keypair, then call resetSSHKeyForVirtualMachine.

Utiliser Cloud-Init¶

Cloud-Init peut être utiliser pour accéder aux données utilisateurs depuis les machines virtuelles. Cloud-init peut être installé dans les modèles et néssite aussi les scripts CloudStack password et sshkey (Ajouter un mot de passe de gestion à votre modèle et utiliser les clefs ssh). La gestion du mot de passe utilisateur et l’API resetSSHKeyForVirtualMachine ne sont pas encore supportés par cloud-init.

1. Installer le paquet cloud-init dans le modèle :

   # yum install cloud-init
     or
   $ sudo apt-get install cloud-init
   

2. Créer un fichier de configuration de source de données : /etc/cloud/cloud.cfg.d/99_cloudstack.cfg

   datasource:
     CloudStack: {}
     None: {}
   datasource_list:
     - CloudStack
   

Exemple de donnée utilisateur¶

Cet exemple utilise cloud-init pour mettre à jour le système d’exploitation d’une VM nouvellement crée :

#cloud-config

# Upgrade the instance on first boot
# (ie run apt-get upgrade)
#
# Default: false
# Aliases: apt_upgrade
package_upgrade: true

formatée en base64 :

I2Nsb3VkLWNvbmZpZw0KDQojIFVwZ3JhZGUgdGhlIGluc3RhbmNlIG9uIGZpcnN0IGJvb3QNCiMgKGllIHJ1biBhcHQtZ2V0IHVwZ3JhZGUpDQojDQojIERlZmF1bHQ6IGZhbHNlDQojIEFsaWFzZXM6IGFwdF91cGdyYWRlDQpwYWNrYWdlX3VwZ3JhZGU6IHRydWUNCg==

Se référer à la documentation Cloud-Init CloudStack datasource pour les dernières possibilitées. Cloud-Init et source de données Cloud-Init CloudStack ne sont pas supportées par la communauté Apache CloudStack.

Prerequisites and System Requirements¶

Before proceeding, ensure that you have these prerequisites:

• The vGPU-enabled XenServer 6.2 and later versions. For more information, see Citrix 3D Graphics Pack.
• GPU/vPGU functionality is supported for following HVM guest operating systems: For more information, see Citrix 3D Graphics Pack.
• Windows 7 (x86 and x64)
• Windows Server 2008 R2
• Windows Server 2012
• Windows 8 (x86 and x64)
• Windows 8.1 (“Blue”) (x86 and x64)
• Windows Server 2012 R2 (server equivalent of “Blue”)
• CloudStack does not restrict the deployment of GPU-enabled VMs with guest OS types that are not supported by XenServer for GPU/vGPU functionality. The deployment would be successful and a GPU/vGPU will also get allocated for VMs; however, due to missing guest OS drivers, VM would not be able to leverage GPU resources. Therefore, it is recommended to use GPU-enabled service offering only with supported guest OS.
• NVIDIA GRID K1 (16 GiB video RAM) AND K2 (8 GiB of video RAM) cards supports homogeneous virtual GPUs, implies that at any given time, the vGPUs resident on a single physical GPU must be all of the same type. However, this restriction doesn’t extend across physical GPUs on the same card. Each physical GPU on a K1 or K2 may host different types of virtual GPU at the same time. For example, a GRID K2 card has two physical GPUs, and supports four types of virtual GPU; GRID K200, GRID K220Q, GRID K240Q, AND GRID K260Q.
• NVIDIA driver must be installed to enable vGPU operation as for a physical NVIDIA GPU.
• XenServer tools are installed in the VM to get maximum performance on XenServer, regardless of type of vGPU you are using. Without the optimized networking and storage drivers that the XenServer tools provide, remote graphics applications running on GRID vGPU will not deliver maximum performance.
• To deliver high frames from multiple heads on vGPU, install XenDesktop with HDX 3D Pro remote graphics.

Before continuing with configuration, consider the following:

• Deploying VMs GPU/vGPU capability is not supported if hosts are not available with enough GPU capacity.
• A Service Offering cannot be created with the GPU values that are not supported by CloudStack UI. However, you can make an API call to achieve this.
• Dynamic scaling is not supported. However, you can choose to deploy a VM without GPU support, and at a later point, you can change the system offering to upgrade to the one with vGPU. You can achieve this by offline upgrade: stop the VM, upgrade the Service Offering to the one with vGPU, then start the VM.
• Live migration of GPU/vGPU enabled VM is not supported.
• Limiting GPU resources per Account/Domain is not supported.
• Disabling GPU at Cluster level is not supported.
• Notification thresholds for GPU resource is not supported.

Supported GPU Devices¶

GPU/vGPU Assignment Workflow¶

CloudStack follows the below sequence of operations to provide GPU/vGPU support for VMs:

1. Ensure that XenServer host is ready with GPU installed and configured. For more information, see Citrix 3D Graphics Pack.

2. Add the host to CloudStack. CloudStack checks if the host is GPU-enabled or not. CloudStack queries the host and detect if it’s GPU enabled.

3. Create a compute offering with GPU/vGPU support: For more information, see Creating a New Compute Offering..

4. Continue with any of the following operations:

   • Deploy a VM.

     Deploy a VM with GPU/vGPU support by selecting appropriate Service Offering. CloudStack decide which host to choose for VM deployment based on following criteria:

     • Host has GPU cards in it. In case of vGPU, CloudStack checks if cards have the required vGPU type support and enough capacity available. Having no appropriate hosts results in an InsufficientServerCapacity exception.
     • Alternately, you can choose to deploy a VM without GPU support, and at a later point, you can change the system offering. You can achieve this by offline upgrade: stop the VM, upgrade the Service Offering to the one with vGPU, then start the VM. In this case, CloudStack gets a list of hosts which have enough capacity to host the VM. If there is a GPU-enabled host, CloudStack reorders this host list and place the GPU-enabled hosts at the bottom of the list.

   • Migrate a VM.

     CloudStack searches for hosts available for VM migration, which satisfies GPU requirement. If the host is available, stop the VM in the current host and perform the VM migration task. If the VM migration is successful, the remaining GPU capacity is updated for both the hosts accordingly.

   • Destroy a VM.

     GPU resources are released automatically when you stop a VM. Once the destroy VM is successful, CloudStack will make a resource call to the host to get the remaining GPU capacity in the card and update the database accordingly.

Préparation du système pour Linux¶

Les étapes suivantes vont préparer une installation Linux basique pour devenir un modèle.

1. Installation

   C’est une bonne pratique de nommer votre VM avec quelque chose de générique durant l’installation, ce qui va assurer que des composants comme LVM n’apparaisse pas unique à une machine. Il est recommandé que le nom “localhost” soit utilisé pour l’installation.

   Avertissement

   Pour CentOS, il est nécessaire de supprimer l’identifiant unique du fichier de configuration, pour cela éditer le fichier /etc/sysconfig/network-scripts/ifcfg-eth0 et changer le contenu pour celui-ci.

   DEVICE=eth0
   TYPE=Ethernet
   BOOTPROTO=dhcp
   ONBOOT=yes
   

   Les étapes suivantes mettent à jour les paquets sur le modèle maître.

   • Ubuntu

     sudo -i
     apt-get update
     apt-get upgrade -y
     apt-get install -y acpid ntp
     reboot
     

   • CentOS

     ifup eth0
     yum update -y
     reboot
     

2. Gestion du mot de passe

   Note

   De préférence, les utilisateurs personnalisés (comme comme ceux créés durant l’installation d’Ubuntu) doivent être retirés. D’abord s’assurer que compte de l’utilisateur root est activé en lui donnant un mot de passe et ensuite se connecter en root pour continuer.

   sudo passwd root
   logout
   

   En tant que root, supprimer tous les comptes utilisateurs personnalisés créés durant le processus d’installation.

   deluser myuser --remove-home
   

   Voir Ajouter un mot de passe de gestion à votre modèle pour les instructions pour configurer le script de gestion du mot de passe, qui permettra à CloudStack de changer le mot de passe root depuis l’interface web.

3. Gestion du nom de machine

   CentOS configure le nom d’hôte par défaut au démarrage. Malheureusement, Ubuntu n’a pas cette fonctionnalité, pour les installations d’Ubuntu utiliser les étapes suivantes :

   • Ubuntu

     Le nom d’hôte d’une VM déployée depuis un modèle est fixé par un script personnalisé dans /etc/dhcp/dhclient-exit-hooks.d, ce script vérifie d’abord si la valeur courante est localhost, si c’est le cas, il va obtenir le nom d’hôte, le nom de domaine et l’adresse IP fixe depuis le fichier de bail DHCP et utiliser ces valeurs pour fixer le nom d’hôte et l’ajouter le fichier /etc/hosts pour la résolution locale du nom d’hôte. Une fois que ce script, ou un utilisateur, a changé le nom d’hôte, il ne va plus ajuster les fichiers systèmes en relation avec son nouveau nom d’hôte. Le script recrée également les clefs du serveur SSH, qui ont été supprimées juste avant la transformation en modèle (voir ci-dessous). Sauvegarder le script suivant sous /etc/dhcp/dhclient-exit-hooks.d/sethostname, et ajuster les permissions.

     #!/bin/sh
     # dhclient change hostname script for Ubuntu
     oldhostname=$(hostname -s)
     if [ $oldhostname = 'localhost' ]
     then
         sleep 10 # Wait for configuration to be written to disk
         hostname=$(cat /var/lib/dhcp/dhclient.eth0.leases  |  awk ' /host-name/ { host = $3 }  END { printf host } ' | sed     's/[";]//g' )
         fqdn="$hostname.$(cat /var/lib/dhcp/dhclient.eth0.leases  |  awk ' /domain-name/ { domain = $3 }  END { printf     domain } ' | sed 's/[";]//g')"
         ip=$(cat /var/lib/dhcp/dhclient.eth0.leases  |  awk ' /fixed-address/ { lease = $2 }  END { printf lease } ' | sed     's/[";]//g')
         echo "cloudstack-hostname: Hostname _localhost_ detected. Changing hostname and adding hosts."
         printf " Hostname: $hostname\n FQDN: $fqdn\n IP: $ip"
         # Update /etc/hosts
         awk -v i="$ip" -v f="$fqdn" -v h="$hostname" "/^127/{x=1} !/^127/ && x { x=0; print i,f,h; } { print $0; }" /etc/hosts > /etc/hosts.dhcp.tmp
         mv /etc/hosts /etc/hosts.dhcp.bak
         mv /etc/hosts.dhcp.tmp /etc/hosts
         # Rename Host
         echo $hostname > /etc/hostname
         hostname -b -F /etc/hostname
         echo $hostname > /proc/sys/kernel/hostname
         # Recreate SSH2
         export DEBIAN_FRONTEND=noninteractive
         dpkg-reconfigure openssh-server
     fi
     ### End of Script ###
     
     chmod 774  /etc/dhcp/dhclient-exit-hooks.d/sethostname
     

   Avertissement

   Les étapes suivantes devraient être lancée lorsque vous être prêt à transformer votre Modèle Maître en modèle. Si le Modèle Maître est redémarré durant ces étapes vous devrez relancer toutes les étapes à nouveau. A la fin de ce processus, le Modèle Maître devrait être arrêté et le modèle créé pour créer et déployer le modèle final.

4. Supprimer les règles udev des périphériques persistants

   Cet étape retire les informations unique de votre Modèle Maître comme les adresses réseaux MAC, les fichiers de baux et les périphériques de type bloc comme les CD. Les fichiers sont générés automatiquement au démarrage suivant;

   • Ubuntu

     rm -f /etc/udev/rules.d/70*
     rm -f /var/lib/dhcp/dhclient.*
     

   • CentOS

     rm -f /etc/udev/rules.d/70*
     rm -f /var/lib/dhclient/*
     

5. Supprimer les clefs SSH

   Cet étape s’assure que toutes vos VMs issuent de modèles n’aient pas les mêmes clefs SSH, ce qui réduirait la sécurité de vos machines dramatiquement.

   rm -f /etc/ssh/*key*
   

6. Nettoyer les fichiers de logs

   C’est une bonne habitude de supprimer les vieux fichiers de logs du Modèle Maître.

   cat /dev/null > /var/log/audit/audit.log 2>/dev/null
   cat /dev/null > /var/log/wtmp 2>/dev/null
   logrotate -f /etc/logrotate.conf 2>/dev/null
   rm -f /var/log/*-* /var/log/*.gz 2>/dev/null
   

7. Configurer le nom d’hôte

   Pour que le script DHCP pour Ubuntu fonctionne et que le client dhclient de CentOS puisse fixer le nom d’hôte ils nécessitent tous les deux que le nom d’hôte du Modèle Maître soit “localhost”. Lancer les commandes suivantes pour changer le nom d’hôte.

   hostname localhost
   echo "localhost" > /etc/hostname
   

8. Forcer l’expiration du mot de passe utilisateur

   Cet étape force l’utilisateur à changer le mot de passe de la VM après que le modèle ait été déployé.

   passwd --expire root
   

9. Nettoyer l’historique utilisateur

   L’étape suivante retire les commandes bash que vous venez de lancer.

   history -c
   unset HISTFILE
   

10. Éteindre la VM

    Vous êtes maintenant prêt pour éteindre votre Modèle Maître et créer un modèle !

    halt -p
    

11. Créer le modèle !

    Vous êtes maintenant prêts à créer le modèle, pour plus d’informations voir “Créer un modèle depuis une machine virtuelle existante”.

Préparation du système pour Windows Server 2008 R2¶

Pour Windows 2008 R2, vous lancer Windows System Image Manager pour créer un fichier XML de réponse sysprep personnalisé. Windows System Image Manager est installé comme partie du Windows Automated Installation Kit (AIK). Windows AIK peut être téléchargé depuis Microsoft Download Center.

Utiliser les étapes suivantes pour lancer sysprep pour Windows 2008 R2 :

1. Télécharger et installer Windows AIK

   Note

   Windows AIK ne devrait pas être installé sur la VM Windows 2008 R2 que vous venez de créer. Windows AIK ne devrait pas faire partie d’un modèle que vous créez. Il est juste utilisé pour créer le fichier de réponse sysprep.

2. Copier le fichier install.wim du répertoire \sources du DVD d’installation Windows 2008 R2 sur le disque dur. C’est un très gros fichier et peut mettre du temps à se copier. Windows AIK nécessite que le fichier WIM soit en écriture.

3. Démarrer le Windows System Image Manager, qui est une partie du Windows AIK.

4. Dans le paneau Image Windows, clic-droit sur Sélectionner une image Windows ou sur option Fichier catalogue pour charger le fichier install.wim que vous venez de copier.

5. Sélectionner Windows 2008 R2 Edition.

   Vous pouvez être avertit par une alerte que le fichier catalogue ne peut pas être ouvert. Cliquer sur Oui pour créer un nouveau fichier catalogue.

6. Dans le paneau Fichier Réponse, cliquer droit pour créer un nouveau fichier de réponse.

7. Générer un fichier de réponse depuis Windows System Image Manager en utilisant les étapes suivantes :

   1. La première page que vous devez automatiser est la page de Selection de Langage et de Pays ou de Région. Pour automatiser cela, développer les composants dans votre panneau Image Windows, clic-droit et ajouter le paramètre Microsoft-Windows-International-Core pour passer 7 oobeSystem. Dans votre panneau Fichier de réponse, configurer le InputLocale, SystemLocale, UILanguage et UserLocale avec les paramètres appropriés pour votre langue et pays ou région. Si vous avez une question à propos de n’importe quel paramètre, vous pouver faire un clic-droit sur le paramètre spécifique et sélectionner Aide. Cela va ouvrir le fichier d’aide CHM approprié avec plus d’informations, incluant des examples sur le paramètre que vous êtes en train d’essayer de configurer.

      

   2. Vous devez automatiser la page de Sélection des Termes de Licence Logiciel, aussi connue comme End-User Licence Agreement (EULA). Pour cela, étendre le composant Microsoft-Windows-Shell-Setup. Surligner le paramètre OOBE et ajouter le paramètre à la Pass 7 oobeSystem. Dans paramètres, fixer HideEULAPage à vrai.

      

   3. Assurez vous que la clé de licence est correctement configurée. Si vous utilisez une clé MAK, vous pouvez juste saisir la clé MAK sur la VM Windows 2008 R2. Vous ne devez pas introduire la MAK dans le Windows System Image Manager. Si vous utilisez un hôte KMS pour l’activation vous ne devez pas saisir de clé de produit. Des détails sur l’activation en volume de Windows peuvent être trouvés ici http://technet.microsoft.com/en-us/library/bb892849.aspx

   4. Vous devez automatiser la page Modifier le mot de passe administrateur. Développez le composant Microsoft-Windows-Shell-Setup (s’il n’est pas encore développé), développez UserAccounts, cliquez avec le bouton droit sur AdministratorPassword et ajoutez le paramètre de configuration Pass 7 oobeSystem de votre fichier de réponses. Sous Paramètres, spécifiez un mot de passe après Valeur.

      

      Vous devriez lire la documentation AIK et configurer beaucoup plus d’options pour pour convenir à votre déploiement Les étapes ci-dessus sont le minimum requis pour rendre fonctionnel la configuration sans assistance de Windows.

8. Sauvegarder le fichier de réponse sous unattend.xml. Vous pouvez ignorer les messages d’alertes qui apparaissent dans la fenêtre de validation.

9. Copier le fichier unattend.xml sous le dossier c:\windows\system32\sysprep de la machine virtuelle Windows 2008 R2.

10. Une fois que vous avez placé le fichier unattend.xml dans le dossier c:\windows\system32\sysprep, vous lancer l’outil sysprep comme ci-dessous :

    cd c:\Windows\System32\sysprep
    sysprep.exe /oobe /generalize /shutdown
    

    La VM Windows 2008 R2 va s’éteindre automatiquement après que le sysprep soit terminé.

Préparation du système pour Windows Server 2003 R2¶

Les versions précédentes de Windows ont un outil sysprep différent. Suivre ces étapes pour Windows Server 2003 R2.

1. Extrayez le contenu de \support\tools\deploy.cab du CD d’installation de Windows dans le répertoire appelé c:\sysprep dans la VM Windows 2003 R2.

2. Lancer c:\sysprep\setupmgr.exe pour créer le fichier sysprep.inf.

   1. Sélectionner Créer un nouveau pour créer un nouveau fichier de réponses.

   2. Entrer “Sysprep setup” pour le type de Setup.

   3. Sélectionner la version et l’édition appropriée d’OS.

   4. Dans l’écran Agrément Licence, sélectionner “Oui automatisation complète de l’installation”.

   5. Fournir le nom et l’organisation.

   6. Laisser les paramètres d’affichage par défaut.

   7. Sélectionner la zone horaire appropriée.

   8. Fournir votre clef de produit.

   9. Sélectionner un mode de licence approprié pour votre déploiement

   10. Sélectionner “Générer automatiquement un nom d’ordinateur”.

   11. Saisissez un mot de passe par défaut pour l’administrateur. Si vous activez la fonctionnalité de réinitialisation de mot de passe, les utilisateurs n’utiliseront pas ce mot de passe. Ce mot de passe sera réinitialisé par le gestionnaire d’instance après les démarrage des invités.

   12. Laisser les Composants Réseaux à “Paramètres par défaut”.

   13. Sélectionner l’option “WORKGROUP”.

   14. Laisser les options Téléphonie par défaut.

   15. Sélectionner les paramètres Régionaux appropriés.

   16. Sélectionner les paramètres de langage approprié.

   17. Ne pas installer d’imprimantes.

   18. Ne pas spécifier “Lancer une fois les commandes”.

   19. Vous ne devez pas spécifier une chaîne d’identification.

   20. Sauvegarde le fichier de réponse sous c:\sysprep\sysprep.inf.

3. Lancer la commande suivante pour syspreper l’image :

   c:\sysprep\sysprep.exe -reseal -mini -activated
   

   Après cette étape la machine va automatiquement s’arrêter

Installation d’un OS Linux¶

Utiliser les étapes suivantes pour commencer l’installation d’un OS Linux :

1. Télécharger le fichier du script cloud-set-guest-password :

   • http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in

2. Renommer le fichier :

   mv cloud-set-guest-password.in cloud-set-guest-password
   

3. Copier ce fichier sous /etc/init.d.

   Sur certaines distributions Linux, copier le fichier sous /etc/rc.d/init.d.

4. Lancer la commande suivante pour rendre le script exécutable :

   chmod +x /etc/init.d/cloud-set-guest-password
   

5. En fonction de la distribution Linux, continuer avec l’étape appropriée.

   Sous Fedora, CentOS/RHEL et Debian, lancer :

   chkconfig --add cloud-set-guest-password
   

Installation d’un OS Windows¶

Télécharger l’installateur, CloudInstanceManager.msi depuis la page de Téléchargement et lancer l’installateur dans la VM windows nouvellement créée.

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.

Meilleurs pratiques pour le stockage primaire¶

• La vitesse du stockage primaire va impacter les performances des invités. Si possible, choisissez des disques plus petits, avec des RPM plus élevés ou des disques SSD pour le stockage primaire.

• Il y a deux façons pour CloudStack d’exploiter le stockage primaire :

  Static: This is CloudStack’s traditional way of handling storage. In this model, a preallocated amount of storage (ex. a volume from a SAN) is given to CloudStack. CloudStack then permits many of its volumes to be created on this storage (can be root and/or data disks). If using this technique, ensure that nothing is stored on the storage. Adding the storage to CloudStack will destroy any existing data.

  Dynamic: This is a newer way for CloudStack to manage storage. In this model, a storage system (rather than a preallocated amount of storage) is given to CloudStack. CloudStack, working in concert with a storage plug-in, dynamically creates volumes on the storage system and each volume on the storage system maps to a single CloudStack volume. This is highly useful for features such as storage Quality of Service. Currently this feature is supported for data disks (Disk Offerings).

Comportement à l’exécution du stockage primaire¶

Root volumes are created automatically when a virtual machine is created. Root volumes are deleted when the VM is destroyed. Data volumes can be created and dynamically attached to VMs. Data volumes are not deleted when VMs are destroyed.

Administrators should monitor the capacity of primary storage devices and add additional primary storage as needed. See the Advanced Installation Guide.

Administrators add primary storage to the system by creating a CloudStack storage pool. Each storage pool is associated with a cluster or a zone.

With regards to data disks, when a user executes a Disk Offering to create a data disk, the information is initially written to the CloudStack database only. Upon the first request that the data disk be attached to a VM, CloudStack determines what storage to place the volume on and space is taken from that storage (either from preallocated storage or from a storage system (ex. a SAN), depending on how the primary storage was added to CloudStack).

Hypervisor Support for Primary Storage¶

The following table shows storage options and parameters for different hypervisors.

XenServer uses a clustered LVM system to store VM images on iSCSI and Fiber Channel volumes and does not support over-provisioning in the hypervisor. The storage server itself, however, can support thin-provisioning. As a result the CloudStack can still support storage over-provisioning by running on thin-provisioned storage volumes.

KVM supports “Shared Mountpoint” storage. A shared mountpoint is a file system path local to each server in a given cluster. The path must be the same across all Hosts in the cluster, for example /mnt/primary1. This shared mountpoint is assumed to be a clustered filesystem such as OCFS2. In this case the CloudStack does not attempt to mount or unmount the storage as is done with NFS. The CloudStack requires that the administrator insure that the storage is available

With NFS storage, CloudStack manages the overprovisioning. In this case the global configuration parameter storage.overprovisioning.factor controls the degree of overprovisioning. This is independent of hypervisor type.

Local storage is an option for primary storage for vSphere, XenServer, and KVM. When the local disk option is enabled, a local disk storage pool is automatically created on each host. To use local storage for the System Virtual Machines (such as the Virtual Router), set system.vm.use.local.storage to true in global configuration.

CloudStack supports multiple primary storage pools in a Cluster. For example, you could provision 2 NFS servers in primary storage. Or you could provision 1 iSCSI LUN initially and then add a second iSCSI LUN when the first approaches capacity.

Storage Tags¶

Storage may be “tagged”. A tag is a text string attribute associated with primary storage, a Disk Offering, or a Service Offering. Tags allow administrators to provide additional information about the storage. For example, that is a “SSD” or it is “slow”. Tags are not interpreted by CloudStack. They are matched against tags placed on service and disk offerings. CloudStack requires all tags on service and disk offerings to exist on the primary storage before it allocates root or data disks on the primary storage. Service and disk offering tags are used to identify the requirements of the storage that those offerings have. For example, the high end service offering may require “fast” for its root disk volume.

The interaction between tags, allocation, and volume copying across clusters and pods can be complex. To simplify the situation, use the same set of tags on the primary storage for all clusters in a pod. Even if different devices are used to present those tags, the set of exposed tags can be the same.

Maintenance Mode for Primary Storage¶

Primary storage may be placed into maintenance mode. This is useful, for example, to replace faulty RAM in a storage device. Maintenance mode for a storage device will first stop any new guests from being provisioned on the storage device. Then it will stop all guests that have any volume on that storage device. When all such guests are stopped the storage device is in maintenance mode and may be shut down. When the storage device is online again you may cancel maintenance mode for the device. The CloudStack will bring the device back online and attempt to start all guests that were running at the time of the entry into maintenance mode.

Creating a New Volume¶

You can add more data disk volumes to a guest VM at any time, up to the limits of your storage capacity. Both CloudStack administrators and users can add volumes to VM instances. When you create a new volume, it is stored as an entity in CloudStack, but the actual storage resources are not allocated on the physical storage device until you attach the volume. This optimization allows the CloudStack to provision the volume nearest to the guest that will use it when the first attachment is made.

Uploading an Existing Volume to a Virtual Machine¶

Existing data can be made accessible to a virtual machine. This is called uploading a volume to the VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root administrators, domain administrators, and end users can all upload existing volumes to VMs.

The upload is performed using HTTP. The uploaded volume is placed in the zone’s secondary storage

You cannot upload a volume if the preconfigured volume limit has already been reached. The default limit for the cloud is set in the global configuration parameter max.account.volumes, but administrators can also set per-domain limits that are different from the global default. See Setting Usage Limits

To upload a volume:

1. (Optional) Create an MD5 hash (checksum) of the disk image file that you are going to upload. After uploading the data disk, CloudStack will use this value to verify that no data corruption has occurred.

2. Log in to the CloudStack UI as an administrator or user

3. In the left navigation bar, click Storage.

4. Click Upload Volume.

5. Provide the following:

   • Name and Description. Any desired name and a brief description that can be shown in the UI.

   • Availability Zone. Choose the zone where you want to store the volume. VMs running on hosts in this zone can attach the volume.

   • Format. Choose one of the following to indicate the disk image format of the volume.

     Hypervisor	Disk Image Format
     XenServer	VHD
     VMware	OVA
     KVM	QCOW2

   • URL. The secure HTTP or HTTPS URL that CloudStack can use to access your disk. The type of file at the URL must match the value chosen in Format. For example, if Format is VHD, the URL might look like the following:

     http://yourFileServerIP/userdata/myDataDisk.vhd

   • MD5 checksum. (Optional) Use the hash that you created in step 1.

6. Wait until the status of the volume shows that the upload is complete. Click Instances - Volumes, find the name you specified in step 5, and make sure the status is Uploaded.

Attacher un Volume¶

Vous pouvez attacher un volume à une VM pour lui fournir plus d’espace disque de stockage. Vous pouvez attacher un volume lors de sa création, lorsque vous déplacer un volume d’une VM existante vers une autre, ou après avoir migré le volume d’un groupe de stockage à un autre.

1. Log in to the CloudStack UI as a user or admin.

2. Dans la navigation à gauche, cliquez sur Stockage.

3. Dans la Sélection de Vue, choisissez Volumes.

4. Click the volume name in the Volumes list, then click the Attach Disk button

5. Dans la popup d’instance, choisissez la VM sur laquelle vous désirez attacher le volume. Vous ne verrez que les instances sur lesquelles vous êtes autorisé à attacher le volume ; par exemple, un utilisateur ne verra que ses propres instances, mais l’administrateur aura plus de choix.

6. Lorsqu’un volume a été attaché, vous devriez pouver le voir en cliquant sur instances, puis le nom de l’instance et “Voir les Volumes”.

Detaching and Moving Volumes¶

A volume can be detached from a guest VM and attached to another guest. Both CloudStack administrators and users can detach volumes from VMs and move them to other VMs.

If the two VMs are in different clusters, and the volume is large, it may take several minutes for the volume to be moved to the new VM.

1. Log in to the CloudStack UI as a user or admin.
2. In the left navigation bar, click Storage, and choose Volumes in Select View. Alternatively, if you know which VM the volume is attached to, you can click Instances, click the VM name, and click View Volumes.
3. Click the name of the volume you want to detach, then click the Detach Disk button.
4. To move the volume to another VM, follow the steps in “Attaching a Volume”.

VM Storage Migration¶

Supported in XenServer, KVM, and VMware.

You can migrate a virtual machine’s root disk volume or any additional data disk volume from one storage pool to another in the same zone.

You can use the storage migration feature to achieve some commonly desired administration goals, such as balancing the load on storage pools and increasing the reliability of virtual machines by moving them away from any storage pool that is experiencing issues.

On XenServer and VMware, live migration of VM storage is enabled through CloudStack support for XenMotion and vMotion. Live storage migration allows VMs to be moved from one host to another, where the VMs are not located on storage shared between the two hosts. It provides the option to live migrate a VM’s disks along with the VM itself. It is possible to migrate a VM from one XenServer resource pool / VMware cluster to another, or to migrate a VM whose disks are on local storage, or even to migrate a VM’s disks from one storage repository to another, all while the VM is running.

Resizing Volumes¶

CloudStack provides the ability to resize data disks; CloudStack controls volume size by using disk offerings. This provides CloudStack administrators with the flexibility to choose how much space they want to make available to the end users. Volumes within the disk offerings with the same storage tag can be resized. For example, if you only want to offer 10, 50, and 100 GB offerings, the allowed resize should stay within those limits. That implies if you define a 10 GB, a 50 GB and a 100 GB disk offerings, a user can upgrade from 10 GB to 50 GB, or 50 GB to 100 GB. If you create a custom-sized disk offering, then you have the option to resize the volume by specifying a new, larger size.

Additionally, using the resizeVolume API, a data volume can be moved from a static disk offering to a custom disk offering with the size specified. This functionality allows those who might be billing by certain volume sizes or disk offerings to stick to that model, while providing the flexibility to migrate to whatever custom size necessary.

This feature is supported on KVM, XenServer, and VMware hosts. However, shrinking volumes is not supported on VMware hosts.

Before you try to resize a volume, consider the following:

• The VMs associated with the volume are stopped.
• The data disks associated with the volume are removed.
• When a volume is shrunk, the disk associated with it is simply truncated, and doing so would put its content at risk of data loss. Therefore, resize any partitions or file systems before you shrink a data disk so that all the data is moved off from that disk.

To resize a volume:

1. Log in to the CloudStack UI as a user or admin.

2. In the left navigation bar, click Storage.

3. Dans la Sélection de Vue, choisissez Volumes.

4. Select the volume name in the Volumes list, then click the Resize Volume button

5. In the Resize Volume pop-up, choose desired characteristics for the storage.

   

   1. If you select Custom Disk, specify a custom size.

   2. Click Shrink OK to confirm that you are reducing the size of a volume.

      This parameter protects against inadvertent shrinking of a disk, which might lead to the risk of data loss. You must sign off that you know what you are doing.

6. Cliquez sur OK.

Reset VM to New Root Disk on Reboot¶

You can specify that you want to discard the root disk and create a new one whenever a given VM is rebooted. This is useful for secure environments that need a fresh start on every boot and for desktops that should not retain state. The IP address of the VM will not change due to this operation.

To enable root disk reset on VM reboot:

When creating a new service offering, set the parameter isVolatile to True. VMs created from this service offering will have their disks reset upon reboot. See “Creating a New Compute Offering”.

Volume Deletion and Garbage Collection¶

The deletion of a volume does not delete the snapshots that have been created from the volume

When a VM is destroyed, data disk volumes that are attached to the VM are not deleted.

Volumes are permanently destroyed using a garbage collection process. The global configuration variables expunge.delay and expunge.interval determine when the physical deletion of volumes will occur.

• expunge.delay: determines how old the volume must be before it is destroyed, in seconds
• expunge.interval: determines how often to run the garbage collection check

Administrators should adjust these values depending on site policies around data retention.

How to Snapshot a Volume¶

1. Log in to the CloudStack UI as a user or administrator.
2. In the left navigation bar, click Storage.
3. In Select View, be sure Volumes is selected.
4. Click the name of the volume you want to snapshot.
5. Click the Snapshot button.

Automatic Snapshot Creation and Retention¶

(Supported for the following hypervisors: XenServer, VMware vSphere, and KVM)

Users can set up a recurring snapshot policy to automatically create multiple snapshots of a disk at regular intervals. Snapshots can be created on an hourly, daily, weekly, or monthly interval. One snapshot policy can be set up per disk volume. For example, a user can set up a daily snapshot at 02:30.

With each snapshot schedule, users can also specify the number of scheduled snapshots to be retained. Older snapshots that exceed the retention limit are automatically deleted. This user-defined limit must be equal to or lower than the global limit set by the CloudStack administrator. See “Globally Configured Limits”. The limit applies only to those snapshots that are taken as part of an automatic recurring snapshot policy. Additional manual snapshots can be created and retained.

Incremental Snapshots and Backup¶

Snapshots are created on primary storage where a disk resides. After a snapshot is created, it is immediately backed up to secondary storage and removed from primary storage for optimal utilization of space on primary storage.

CloudStack does incremental backups for some hypervisors. When incremental backups are supported, every N backup is a full backup.

Volume Status¶

When a snapshot operation is triggered by means of a recurring snapshot policy, a snapshot is skipped if a volume has remained inactive since its last snapshot was taken. A volume is considered to be inactive if it is either detached or attached to a VM that is not running. CloudStack ensures that at least one snapshot is taken since the volume last became inactive.

When a snapshot is taken manually, a snapshot is always created regardless of whether a volume has been active or not.

Snapshot Restore¶

There are two paths to restoring snapshots. Users can create a volume from the snapshot. The volume can then be mounted to a VM and files recovered as needed. Alternatively, a template may be created from the snapshot of a root disk. The user can then boot a VM from this template to effect recovery of the root disk.

Snapshot Job Throttling¶

When a snapshot of a virtual machine is requested, the snapshot job runs on the same host where the VM is running or, in the case of a stopped VM, the host where it ran last. If many snapshots are requested for VMs on a single host, this can lead to problems with too many snapshot jobs overwhelming the resources of the host.

To address this situation, the cloud’s root administrator can throttle how many snapshot jobs are executed simultaneously on the hosts in the cloud by using the global configuration setting concurrent.snapshots.threshold.perhost. By using this setting, the administrator can better ensure that snapshot jobs do not time out and hypervisor hosts do not experience performance issues due to hosts being overloaded with too many snapshot requests.

Set concurrent.snapshots.threshold.perhost to a value that represents a best guess about how many snapshot jobs the hypervisor hosts can execute at one time, given the current resources of the hosts and the number of VMs running on the hosts. If a given host has more snapshot requests, the additional requests are placed in a waiting queue. No new snapshot jobs will start until the number of currently executing snapshot jobs falls below the configured limit.

The admin can also set job.expire.minutes to place a maximum on how long a snapshot request will wait in the queue. If this limit is reached, the snapshot request fails and returns an error message.

VMware Volume Snapshot Performance¶

When you take a snapshot of a data or root volume on VMware, CloudStack uses an efficient storage technique to improve performance.

A snapshot is not immediately exported from vCenter to a mounted NFS share and packaged into an OVA file format. This operation would consume time and resources. Instead, the original file formats (e.g., VMDK) provided by vCenter are retained. An OVA file will only be created as needed, on demand. To generate the OVA, CloudStack uses information in a properties file (*.ova.meta) which it stored along with the original snapshot data.

Utiliser un certificat SSL pour la Console Proxy¶

Par défaut, la fonctionnalité de visualisation de la console utilise le HTTP en clair. Dans n’importe quel environnement de production, la connexion à la console proxy devrait être cryptée via SSL au minimum.

Un administrateur CloudStack dispose de 2 façons pour sécuriser la communication à la console proxy avec SSL :

• Configurer un certificat générique SSL et la résolution de nom de domaine

• Configurer un certificat pour un FQDN spécifique et configurer la répartition de charge

Changer le Certificat SSL et le domaine de la Console Proxy¶

L’administrateur peut configurer le cryptage SSL en sélectionnant un domaine et en téléchargent un nouveau certificat et une clef privée. Le domaine doit fournir le service DNS capable de résoudre les requêtes pour les adresses de la forme aaa-bbb-ccc-ddd.votre.domaine en adresses IPv4 dans la forme aaa.bbb.ccc.ddd, par exemple, 202.8.44.1. Pour modifier le domaine de la console proxy, le certificat SSL et la clef privée :

1. Configurer la résolution de nom dynamique ou peupler tous les noms DNS possibles de votre plage d’adresses IP publique au sein de votre serveur DNS avec le format aaa-bbb-ccc-ddd.consoleproxy.societe.com -> aaa.bbb.ccc.ddd.

   Note

   Dans ces étapes, vous noterez consoleproxy.societe.com – Pour des raisons de sécurité, nous recommandons de créer un certificat SSL générique pour un sous-domaine séparé. Dans le cas où ce certificat serait compromis, un utilisateur mal intentionné ne pourrait pas usurper l’identité du domaine societe.com.

2. Générer la clef privée et la demande de certificat signé (CSR). Lorsque vous utilisez openssl pour générer les paires de clefs privées/publiques et les CSRs, pour la clef privée que vous allez copier dans l’interface de CloudStack, assurez-vous de convertir dans le format PKCS#8.

   1. Générer une nouvelle clef privée de 2048 bits

      openssl genrsa -des3 -out yourprivate.key 2048
      

   2. Générer un nouveau certificat CSR. Assurez-vous de la création d’un certificat générique, comme *.consoleproxy.societe.com

      openssl req -new -key yourprivate.key -out yourcertificate.csr
      

   3. Sur le site web de votre Autorité de Certification favorite, commander un certificate SSL et soumettre le CSR. Vous devriez recevoir un certificat valide en retour.

   4. Convertir votre clef privée au format PKCS#8 crypté.

      openssl pkcs8 -topk8 -in yourprivate.key -out yourprivate.pkcs8.encrypted.key
      

   5. Convertir votre clef privée cryptée PKCS#8 au format PKCS#8 conforme avec CloudStack.

      openssl pkcs8 -in yourprivate.pkcs8.encrypted.key -out yourprivate.pkcs8.key
      

3. Dans l’écran de mise à jour du certificate SSL de l’interface CloudStack, coller ce qui suit :

   • Le certificat que vous venez de générer.

   • La clef privée que vous venez juste de générer.

   • Le nom de domaine souhaité, préfixé d’un *. ; par exemple : *.consoleproxy.societe.com

   

4. Cela va arrêter toutes les VM console proxy en fonctionnement, et les redémarrer avec le nouveau certificat et la clef. Les utilisateurs peuvent noter une brève interruption de la disponibilité de la console.

Le serveur de gestion génère des URLS de la forme “aaa-bbb-ccc-ddd.consoleproxy.societe.com” après que les changements aient été effectués. Les nouvelles requêtes aux consoles seront faîtes avec le nouveau nom de domaine, certificat et clef.

Télécharger la CA Racine et la CA intermédiaire¶

Si vous avez besoin de télécharger un certificat personnalisé avec la CA racine et la CA intermédiaire, vous pouvez trouver plus de détails ici : https://cwiki.apache.org/confluence/display/CLOUDSTACK/Procedure+to+Replace+realhostip.com+with+Your+Own+Domain+Name

NOTES IMPORTANTES :

Dans le but d’éviter toutes erreurs et problèmes durant le téléchargement de certificats personnalisés, merci de vérifier ce qui suit :

1. While doing URL encoding of ROOT CA and any Intermediate CA, be sure that the plus signs (“+”) inside certificates are not replaced by space (” ”), because some URL/string encoding tools tend to do that.

2. If you are renewing certificates it might happen you need to upload new ROOT CA and Intermediate CA, together with new Server Certificate and key. In this case please be sure to use same names for certificates during API upload of certificate, example:

http://123.123.123.123:8080/client/api?command=uploadCustomCertificate&...&name=root1... http://123.123.123.123:8080/client/api?command=uploadCustomCertificate&...&name=intermed1...

Ici les noms “root1” et “intermed1”. Si vous utilisiez d’autres noms auparavant, merci de vérifier la table cloud.keystore pour obtenir les noms utilisés.

Si vous avez toujours des problèmes et les erreurs suivantes dans le management.log lors de la destruction du CPVM :

• Unable to build keystore for CPVMCertificate due to CertificateException
• Cold not find and construct a valid SSL certificate

cela signifie toujours que certains certificats racine/intermédiaire/serveur ou la clef n’est pas dans le bon format, ou encodée incorrectement ou plusieurs CA racine/CA intermédiaire sont présente dans la base de données par erreur.

Une autre façon de renouveller les certificats (racine, intermédiaires, certificats serveurs ou clef) - bien que non recommandée sauf si vous la trouvez confortable, est d’éditer directement la base de données, tant que vous respectez la principale exigence que la clef soit encodée en PKCS8, alors que la CA racine, intermédiaire et les certificats serveurs sont toujours au format par défaut PEM (pas besoin d’encodage d’URL ici). Après avoir éditer la base de données, merci de redémarrer le serveur de gestion, de détruire la machine SSVM et CPVM après ça, pour que les nouvelles SSVM et CPVM soient créées avec les nouveaux certificats.

Les consoles proxys de répartition de charge¶

Une alternative à utiliser les DNS dynamique ou de créer une plage d’entrées DNS comme décrit ans la section précédente serait de créer un certificat SSl pour un nom de domaine spécifique, de configurer CloudStack pour utiliser ce FQDN particulier et alors de configurer un répartiteur de charge pour l’adresse IP de la console proxy derrière ce FQDN. Comme cette fonctionnalitée est toujours nouvelle, merci de voir https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes pour plus de détails.

Configurer le routeur virtuel¶

Vous pouvez paramétrer :²

• Plage IP

• Services réseaux supportés

• Le nom de domaine par défaut pour les services servis par le routeur virtuel

• Adresse IP de la passerelle

• A quelle fréquence CloudStack rapporte les statistiques d’utilisation du réseau depuis les routeurs virtuels CloudStack. Si vous voulez collecter les données métriques du trafic depuis les routeur virtuel, fixer le paramètre de configuration global router.stats.interval. Si vous n’utilisez pas de routeur virtuel pour recueillir les statistiques d’utilisation du réseau, le positionner à 0.

Mettre à jour un routeur virtuel avec les offres de service système¶

Quand CloudStack crée un routeur virtuel, il utilise des paramètres par défaut qui sont définis dans une offre de service système par défaut. Voir “Offres de service système”. Tous les routeurs virtuels du même réseau invité utilise la même offre de service système. Vous pouvez mettre à jour les capacités du routeur virtuel en créant et appliquant une offre de service système personnalisée.

1. Définir votre offre de service système personnalisé. Voir “Créer une nouvelle offre de service système”. Dans le type de VM système, choisir Routeur de domaine.

2. Associer l’offre de service système avec l’offre de service. Voir “Créer une nouvelle offre de réseau”.

3. Appliquer l’offre de réseau au réseau dans lequel vous voulez les routeurs virtuels utilisant la nouvelle offre de service système. S’il s’agit d’un nouveau réseau, suivre les étapes de Ajouter un réseau invité additionnel de la page 66. Pour changer l’offre de service d’un routeur virtuel existant, suivre les étapes de “Changer l’offre réseau d’un réseau invité”.

Meilleurs pratiques pour les routeurs virtuels¶

• ATTENTION : rédémarrer un routeur virtuel depuis une console de l’hyperviseur efface toutes les règles iptables. Pour contourner ce probluème, stopper le routeur virtuel et le démarrer depuis l’interface CloudStack.

• Avertissement

  N’utilisez pas l’API destroyRouter lorsqu’un seul routeur n’est disponible dans le réseau, parce que l’API restartNetwork avec le paramètre cleanup=false ne pourra pas le récréer plus tard. Si vous voulez détruire et recréer un seul routeur disponible dans le réseau, utiliser l’API restartNetwork avec le paramètre cleanup=true.

Outil de surveillance de service pour Routeur Virtuelle¶

Des services variés fonctionnant sur les routeurs virtuels CloudStack peuvent être surveillés en utilisant l’outil de Surveillance Système. L’outil garantit que les services fonctionnent correctement jusqu’à ce que CloudStack les désactive délibérément. Si un service tombe, l’outil redémarre automatiquement le service et si cela n’aide pas à remonter le service, une alerte et un évènement sont générés indiquant la panne. A nouveau paramètre global, network.router.enableservicemonitoring, a été introduit pour contrôler cette fonctionnalité. La valeur par défaut est à false, ce qui implique que la surveillance est désactivée. Quand vous l’activez, s’assurer que le serveur de gestion et le routeur soient redémarrer.

Les outils de surveillance peuvent aider à démarrer un service VR, qui est planté à cause d’une raison inconnue. Par exemple :

• Le service a planté à cause de défauts dans le code source.

• Les services qui sont arrêtés par l’OS quand la mémoire ou le CPU ne sont plus suffisamment disponible pour le service.

Les services suivants sont contrôlés par un VR :

• DNS
• HA Proxy
• SSH
• Apache Web Server

Les réseaux suivant sont supportés :

• Les réseaux isolés

• Les réseaux partagés dans les zones Avancées et Basiques

  Note

  Les réseaux VPC ne sont pas supportés

Cette fonctionnalité est supporté sur les hyperviseurs suivants : XenServer, VMware et KVM.

Mise à jour améliorée pour les routeurs virtuels¶

Mettre à jour un VR est rendu souple. L’administrateur CloudStack est capable de contrôler la séquence des mises à jour du VR. Le séquencement est basé sur la hiérarchie de l’infrastructure, comme par Cluster, Pod ou Zone et la hiérarchie (de comptes) administrative, comme par Utilisateur ou Domain. En tant qu’administrateur, vous pouvez aussi déterminer quand un service client particulier, comme les VR, est mis à jour dans les limites d’un intervalle de mise à jour spécifiée. L’opération de mise à jour est améliorée pour augmenter la vitesse de mise à jour en autorisant autant d’opérations en parallèle que possible.

Durant la durée complète de la mise à jour, les utilisateurs ne peuvent pas lancer de nouveaux services ou faire des modifications sur un service existant.

En complément, utiliser plusieurs versions de VRs dans une seule instance est supporté. Dans l’onglet Détails d’un VR, vous pouvez voir la version et si il nécessite une mise à jour. Durant la mise à jour du serveur de gestion, CloudStack vérifie si le VR est à la dernière version avant d’effectuer toute opération sur le VR. Pour supporter cela, un nouveau paramètre global, ``router.version.check``, a été ajouté. Ce paramètre est fixé à true par défaut, ce qui implique que la version minimum requise est vérifiée avant d’effectuer toute opération. Aucune opération n’est effectuée si le VR n’est pas à la version requise. Les services de la vieille version du VR continue d’être disponible, mais aucune nouvelle opération ne peut être effectuée sur le VR jusqu’à ce qu’il soit mis à jour à la dernière version. Cela va assurer que la disponibilité des services VR et l’état des VR n’est pas impacté à cause de la mise à jour du serveur de gestion.

Le service suivant sera disponible même si le VR n’est pas mis à jour. Toutefois, aucun changement pour aucun des services ne peut être envoyé au VR jusqu’à ce qu’il soit mis à jour :

• Groupe de sécurité

• Données utilisateur

• DHCP
• DNS
• LB

• Redirection de port

• VPN

• NAT statique

• Source NAT

• Parefeu

• Passerelle

• ACL réseau

Globally Configured Limits¶

In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network to 254 running instances. It can be adjusted as needed, but this must be done before any instances are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.

The following table lists limits set in the Global Configuration:

To modify global configuration parameters, use the global configuration screen in the CloudStack UI. See Setting Global Configuration Parameters

Limiting Resource Usage¶

CloudStack allows you to control resource usage based on the types of resources, such as CPU, RAM, Primary storage, and Secondary storage. A new set of resource types has been added to the existing pool of resources to support the new customization model—need-basis usage, such as large VM or small VM. The new resource types are now broadly classified as CPU, RAM, Primary storage, and Secondary storage. The root administrator is able to impose resource usage limit by the following resource types for Domain, Project, and Accounts.

• CPU

• Memory (RAM)
• Primary Storage (Volumes)
• Secondary Storage (Snapshots, Templates, ISOs)

To control the behaviour of this feature, the following configuration parameters have been added:

User Permission¶

The root administrator, domain administrators and users are able to list resources. Ensure that proper logs are maintained in the vmops.log and api.log files.

• The root admin will have the privilege to list and update resource limits.
• The domain administrators are allowed to list and change these resource limits only for the sub-domains and accounts under their own domain or the sub-domains.
• The end users will the privilege to list resource limits. Use the listResourceLimits API.

Limit Usage Considerations¶

• Primary or Secondary storage space refers to the stated size of the volume and not the physical size— the actual consumed size on disk in case of thin provisioning.

• If the admin reduces the resource limit for an account and set it to less than the resources that are currently being consumed, the existing VMs/templates/volumes are not destroyed. Limits are imposed only if the user under that account tries to execute a new operation using any of these resources. For example, the existing behavior in the case of a VM are:

  • migrateVirtualMachine: The users under that account will be able to migrate the running VM into any other host without facing any limit issue.
  • recoverVirtualMachine: Destroyed VMs cannot be recovered.

• For any resource type, if a domain has limit X, sub-domains or accounts under that domain can have there own limits. However, the sum of resource allocated to a sub-domain or accounts under the domain at any point of time should not exceed the value X.

  For example, if a domain has the CPU limit of 40 and the sub-domain D1 and account A1 can have limits of 30 each, but at any point of time the resource allocated to D1 and A1 should not exceed the limit of 40.

• If any operation needs to pass through two of more resource limit check, then the lower of 2 limits will be enforced, For example: if an account has the VM limit of 10 and CPU limit of 20, and a user under that account requests 5 VMs of 4 CPUs each. The user can deploy 5 more VMs because VM limit is 10. However, the user cannot deploy any more instances because the CPU limit has been exhausted.

Limiting Resource Usage in a Domain¶

CloudStack allows the configuration of limits on a domain basis. With a domain limit in place, all users still have their account limits. They are additionally limited, as a group, to not exceed the resource limits set on their domain. Domain limits aggregate the usage of all accounts in the domain as well as all the accounts in all the sub-domains of that domain. Limits set at the root domain level apply to the sum of resource usage by the accounts in all the domains and sub-domains below that root domain.

To set a domain limit:

1. Se connecter à l’interface CloudStack.

2. In the left navigation tree, click Domains.

3. Select the domain you want to modify. The current domain limits are displayed.

   A value of -1 shows that there is no limit in place.

4. Click the Edit button

5. Edit the following as per your requirement:

   • Parameter Name

   • Description

   • Instance Limits

     The number of instances that can be used in a domain.

   • Public IP Limits

     The number of public IP addresses that can be used in a domain.

   • Volume Limits

     The number of disk volumes that can be created in a domain.

   • Snapshot Limits

     The number of snapshots that can be created in a domain.

   • Template Limits

     The number of templates that can be registered in a domain.

   • VPC limits

     The number of VPCs that can be created in a domain.

   • CPU limits

     The number of CPU cores that can be used for a domain.

   • Memory limits (MB)

     The number of RAM that can be used for a domain.

   • Primary Storage limits (GB)

     The primary storage space that can be used for a domain.

   • Secondary Storage limits (GB)

     The secondary storage space that can be used for a domain.

6. Cliquer sur Appliquer.

Default Account Resource Limits¶

You can limit resource use by accounts. The default limits are set by using Global configuration parameters, and they affect all accounts within a cloud. The relevant parameters are those beginning with max.account, for example: max.account.snapshots.

To override a default limit for a particular account, set a per-account resource limit.

1. Se connecter à l’interface CloudStack.

2. In the left navigation tree, click Accounts.

3. Select the account you want to modify. The current limits are displayed.

   A value of -1 shows that there is no limit in place.

4. Click the Edit button.

5. Edit the following as per your requirement:

   • Parameter Name

   • Description

   • Instance Limits

     The number of instances that can be used in an account.

     The default is 20.

   • Public IP Limits

     The number of public IP addresses that can be used in an account.

     The default is 20.

   • Volume Limits

     The number of disk volumes that can be created in an account.

     The default is 20.

   • Snapshot Limits

     The number of snapshots that can be created in an account.

     The default is 20.

   • Template Limits

     The number of templates that can be registered in an account.

     The default is 20.

   • VPC limits

     The number of VPCs that can be created in an account.

     The default is 20.

   • CPU limits

     The number of CPU cores that can be used for an account.

     The default is 40.

   • Memory limits (MB)

     The number of RAM that can be used for an account.

     The default is 40960.

   • Primary Storage limits (GB)

     The primary storage space that can be used for an account.

     The default is 200.

   • Secondary Storage limits (GB)

     The secondary storage space that can be used for an account.

     The default is 400.

6. Cliquer sur Appliquer.

Virtual Machine Usage Record Format¶

For running and allocated virtual machine usage, the following fields exist in a usage record:

• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usage – String representation of the usage, including the units of usage (e.g. ‘Hrs’ for VM running time)
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• virtualMachineId – The ID of the virtual machine
• name – The name of the virtual machine
• offeringid – The ID of the service offering
• templateid – The ID of the template or the ID of the parent template. The parent template value is present when the current template was created from a volume.
• usageid – Virtual machine
• type – Hypervisor
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record

Network Usage Record Format¶

For network usage (bytes sent/received), the following fields exist in a usage record.

• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• usageid – Device ID (virtual router ID or external device ID)
• type – Device type (domain router, external load balancer, etc.)
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record

IP Address Usage Record Format¶

For IP address usage the following fields exist in a usage record.

• account - name of the account
• accountid - ID of the account
• domainid - ID of the domain in which this account resides
• zoneid - Zone where the usage occurred
• description - A string describing what the usage record is tracking
• usage - String representation of the usage, including the units of usage
• usagetype - A number representing the usage type (see Usage Types)
• rawusage - A number representing the actual usage in hours
• usageid - IP address ID
• startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record
• issourcenat - Whether source NAT is enabled for the IP address
• iselastic - True if the IP address is elastic.

Disk Volume Usage Record Format¶

For disk volumes, the following fields exist in a usage record.

• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usage – String representation of the usage, including the units of usage (e.g. ‘Hrs’ for hours)
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• usageid – The volume ID
• offeringid – The ID of the disk offering
• type – Hypervisor
• templateid – ROOT template ID
• size – The amount of storage allocated
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record

Template, ISO, and Snapshot Usage Record Format¶

• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usage – String representation of the usage, including the units of usage (e.g. ‘Hrs’ for hours)
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• usageid – The ID of the the template, ISO, or snapshot
• offeringid – The ID of the disk offering
• templateid – – Included only for templates (usage type 7). Source template ID.
• size – Size of the template, ISO, or snapshot
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record

Load Balancer Policy or Port Forwarding Rule Usage Record Format¶

• account - name of the account
• accountid - ID of the account
• domainid - ID of the domain in which this account resides
• zoneid - Zone where the usage occurred
• description - A string describing what the usage record is tracking
• usage - String representation of the usage, including the units of usage (e.g. ‘Hrs’ for hours)
• usagetype - A number representing the usage type (see Usage Types)
• rawusage - A number representing the actual usage in hours
• usageid - ID of the load balancer policy or port forwarding rule
• usagetype - A number representing the usage type (see Usage Types)
• startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record

Network Offering Usage Record Format¶

• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usage – String representation of the usage, including the units of usage (e.g. ‘Hrs’ for hours)
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• usageid – ID of the network offering
• usagetype – A number representing the usage type (see Usage Types)
• offeringid – Network offering ID
• virtualMachineId – The ID of the virtual machine
• virtualMachineId – The ID of the virtual machine
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record

VPN User Usage Record Format¶

• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usage – String representation of the usage, including the units of usage (e.g. ‘Hrs’ for hours)
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• usageid – VPN user ID
• usagetype – A number representing the usage type (see Usage Types)
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record

Configurer le trafic invité dans une Zone Avancée¶

Ces étapes assume que vous êtes déjà connecté dans l’interface CloudStack. Pour configurer le réseau invité de base :

1. Dans le menu de gauche, choisir Infrastructure. Dans Zones, cliquer sur Voir Plus, puis cliquer sur la zone à laquelle vous voulez ajouter un réseau.

2. Cliquer sur l’onglet Réseau.

3. Cliquer sur Ajouter un réseau invité.

   La fenêtre Ajouter un réseau invité est affichée :

   

4. Fournir l’information suivante :

   • Nom : Le nom du réseau. Cela sera visible de l’utilisateur.

   • Texte affiché: La description du réseau. Cela sera visible de l’utilisateur.

   • Zone : La zone pour laquelle vous êtes en train de configurer le réseau invité.

   • Offre réseau : Si l’administrateur a configuré plusieurs offres de réseau, sélectionner celui que vous voulez utiliser pour ce réseau.

   • Passerelle invitée : La passerelle que les invités devraient utiliser.

   • Masque de sous réseau invité : Le masque de sous réseau utilisé sur le sous réseau que les invités vont utiliser.

5. Cliquez sur OK.

Configurer le trafic public dans une Zone Avancée¶

Dans une zone qui utilise un réseau avancé, vous devez configurer au moins une plage d’adresses IP pour le trafic Internet.

Configurer un réseau invité partagé¶

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

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

3. Dans zones, cliquez sur Voir tout.

4. Cliquer sur la zone à laquelle vous voulez ajouter un réseau invité.

5. Cliquer sur l’onglet Réseau.

6. Cliquer sur le réseau physique avec lequel vous voulez travailler.

7. Sur le noeud Invité du diagramme, cliquer sur Configurer.

8. Cliquer sur l’onglet Réseau.

9. Cliquer sur Ajouter un réseau invité.

   La fenêtre Ajouter un réseau invité est affichée :

10. Spécifier les informations suivantes :

    • Nom : Le nom du réseau. Cela sera visible de l’utilisateur.

    • Description : La description courte du réseau qui peut être affichée aux utilisateurs

    • ID VLAN : L’ID unique du VLAN.

    • ID du VLAN isolé : L’ID unique du VLAN secondaire isolé.

    • Portée : Les portées possibles sont Domaine, Compte, Projet et Tous.

      • Domaine : Sélectionner Domaine limite la partée de ce réseau invité au domaine que vous spécifiez. Le réseau ne sera pas disponible pour les autres domaines.Si vous sélectionnez Accès Sous Domaine, le réseau invité est disponible à tous les sous domaines au sein du domaine sélectionné.

      • Compte : Le compte pour lequel le réseau invité est créé. Vous devez spécifier le domaine auquel appartient le compte.

      • Projet : Le projet pour lequel le réseau invité est créé. Vous devez spécifier le domaine auquel le projet appartient.

      • Tous : Le réseau invité est disponible pour tous les domaines, comptes, projets au sein de la zone sélectionnée.

    • Offre réseau : Si l’administrateur a configuré plusieurs offres de réseau, sélectionnez celle que vous voulez utiliser pour ce réseau.

    • Passerelle : La passerelle que les invités devraient utiliser.

    • Masque de sous réseau : Le masque de sous réseau du réseau que les utilisateurs vont utiliser.

    • Plage IP : Une plage d’adresses IP qui sont accessibles depuis l’Internet est qui sont assignées aux VMs invitées.

      Si une interface est utilisée, ces IP devrait être dans le même CIDR dans le cas de l’IPv6.

    • IPv6 CIRD : Le préfixe réseau qui défini le sous réseau du réseau invité. C’est le CIDR qui décrit les adresses IPv6 en usage dans les réseaux invités de cette zone. Pour autoriser les adresses IP depuis un bloc d’adresse particulier, entrer un CIDR.

    • Domaine Réseau : Un suffixe DNS personnalisé au niveau du réseau. Si vous voulez assigner un nom de domaine spécial au réseau des VM invitées, spécifier un suffixe DNS.

11. Cliquer OK pour confirmer.

Ajouter un réseau invité supplémentaire¶

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Cliquez sur Ajouter un réseau invité. Donnez les informations suivantes:

   • Nom : Le nom du réseau. Cela sera visible de l’utilisateur.

   • Texte affiché: La description du réseau. Cela sera visible de l’utilisateur.

   • Zone. Le nom de la zone à laquelle le réseau s’applique. Chaque zone est un domaine de diffusion, et par conséquent, chaque zone a une plage d’IP différente comme réseau d’invité. L’administrateur doit configurer la plage d’IP pour chaque zone.

   • Offre réseau : Si l’administrateur a configuré plusieurs offres de réseau, sélectionnez celle que vous voulez utiliser pour ce réseau.

   • Passerelle invitée : La passerelle que les invités devraient utiliser.

   • Masque de sous réseau invité : Le masque de sous réseau utilisé sur le sous réseau que les invités vont utiliser.

4. Cliquer sur Créer.

Reconfigurer les Réseaux dans les VMs¶

CloudStack vous offre la possibilité de déplacer des VMs d’un réseau à un autre et de reconfigurer son réseau. Vous pouvez retirer une VM d’un réseau et l’ajouter à un nouveau réseau. Vous pouvez aussi changer le réseau par défaut d’une machine virtuelle. Avec cette fonctionnalité, les charges d’un serveur traditionnel ou hybride peut être facilement adapté.

Cette fonctionnalité est supportée sur les hyperviseurs XenServer, VMware et KVM.

Changer l’offre de réseau pour un réseau invités.¶

Un utilisateur ou un administrateur peut changer l’offre de réseau qui est associée avec un réseau d’invité existant.

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

2. Si vous êtes en train de changer d’une offre de réseau qui utilise le routeur virtuel CloudStack vers une qui utilise des périphériques externes comme fournisseurs de services réseaux, vous devez d’abord stopper toutes les VMs de ce réseau.

3. Dans la navigation à gauche, choisissez Réseau.

4. Cliquer sur le nom du réseau que vous voulez modifier.

5. Dans l’onglet Détails, cliquer sur Editer.

6. Dans Offre de Réseau, choisir la nouvelle offre de réseau, puis cliquer sur Appliquer.

   Une invite est affichée demandant si vous voulez conserver le CIDR existant. Ceci vous permet de savoir que si vous changer l’offre de réseau, le CIDR sera réaffecté.

   Si vous évoluez entre un routeur virtuel comme fournisseur et un périphérique réseau externe comme fournisseur, accepter le changement du CIDR pour continuer en cliquant sur Oui.

7. Attendre que la mise à jour soit finie. Ne pas essayer de redémarrer les VMs tant que le changement du réseau ne soit pas fini.

8. Si vous avez stoppé des VMs, redémarrer les.

Considérations sur la réservation d’IP¶

Prenez en compte ce qui suit avant de réserver une plage d’IP pour les machines externes à CloudStack :

• La réservation IP est prise en charge uniquement dans les réseaux isolés.

• La réservation IP ne peut être appliquée que lorsque le réseau est dans l’état Implementé.

• Aucune réservation d’IP n’est effectuée par défaut.

• Le CIDR des VM Invités que vous spécifiez doit être un sous-réseau du CIDR du réseau.

• Spécifiez un CIDR de VM Invités valide. La réservation d’IP n’est appliquée que si aucune IP active n’existe à l’extérieur du CIDR des VM invités.

  Vous ne pouvez pas appliquer une réservation d’IP si une machine virtuelle s’est vue allouer une adresse IP se trouvant en dehors du CIDR des VM Invités.

• Pour réinitialiser une réservation d’IP existante, appliquez la réservation IP en spécifiant la valeur du réseau CIDR dans le champ CIDR.

  Par exemple, le tableau suivant décris trois scénarios de création de réseau invité :

  Cas	CIDR	CIDR du réseau	Interval d’IP réservées pour les VMs Non-CloudStack	Description
  1	10.1.1.0/24	Aucun	Aucun	Aucune réservation d’IP.
  2	10.1.1.0/26	10.1.1.0/24	10.1.1.64 à 10.1.1.254	La réservation d’IP est configurée par l’API UpdateNetwork avec guestvmcidr=10.1.1.0/26 ou saisir 10.1.1.0/26 dans le champ CIDR de l’interface utilisateur.
  3	10.1.1.0/24	Aucun	Aucun	La suppression d’une réservation d’IP est effectuée par l’API UpdateNetwork avec guestvmcidr=10.1.1.0/24 ou saisir 10.1.1.0/24 dans le champ CIDR de l’interface utilisateur.

Limitations¶

• La réservation d’IP n’est pas supportée si des IP actives sont trouvées à l’extérieur du CIDR des VM invités.

• La mise à niveau d’une offre réseau qui provoque une modification de son CIDR (comme une mise à niveau d’une offre sans périphériques externes vers une avec un périphérique externe), fait que la réservation d’IP devient nulle, le cas échéant. Reconfigurez la réservation d’IP dans le nouveau réseau ré-implémenté.

Recommandations¶

Appliquez la Réservation d’IP à un réseau invité dès que l’état du réseau passe à Implementé. Si vous appliquez la réservation peu de temps après le déploiement de la première VM invitée, des conflits mineurs surviennent lors de l’application de la réservation.

Réserver un intervalle d’IP¶

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Cliquer sur le nom du réseau que vous voulez modifier.

4. Dans l’onglet Détails, cliquer sur Editer.

   Le champ CIDR devient éditable.

5. Dans CIDR, spécifier le CIDR des VM invités.

6. Cliquer sur appliquer.

   Attendre que la mise à jour soit finie. Le CIDR du réseau et la plage d’IP réservée sont affichées dans la page de Détails.

Dédier un intervalle d’adressses IP à un compte¶

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

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

3. Dans Zones, cliquer sur Voir toutes.

4. Choisir la zone avec laquelle vous voulez travailler.

5. Cliquer sur l’onglet Réseau.

6. Dans le noeud Public du diagramme, cliquer sur Configure.

7. Cliquer sur l’onglet intervalle IP.

   You can either assign an existing IP range to an account, or create a new IP range and assign to an account.

8. Pour assigner un intervalle d’IP existant à un compte, effectuer les actions suivantes :

   1. Localiser l’intervalle d’IP avec lequel vous voulez travailler.

   2. Cliquer sur le bouton Ajouter un compte .

      La boîte de dialogue Ajouter un compte est affichée.

   3. Spécifier les informations suivantes :

      • Account: The account to which you want to assign the IP address range.
      • Domain: The domain associated with the account.

      To create a new IP range and assign an account, perform the following:

      1. Spécifier les informations suivantes :

         • Passerelle

         • Masque de sous-réseau

         • VLAN

         • IP de départ

         • IP de fin

         • Compte : Effectuer au choix :

           1. Cliquer sur Compte.

              La page Ajouter un compte est affichée.

           2. Spécifier les informations suivantes :

              • Account: The account to which you want to assign an IP address range.
              • Domain: The domain associated with the account.

           3. Cliquez sur OK.

      2. Cliquer sur Ajouter.

Dédier des plages de VLAN à un compte¶

1. After the CloudStack Management Server is installed, log in to the CloudStack UI as administrator.

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

3. Dans Zones, cliquer sur Voir toutes.

4. Choisir la zone avec laquelle vous voulez travailler.

5. Cliquer sur l’onglet Réseau.

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

7. Select the Dedicated VLAN Ranges tab.

8. Cliquersur Dédié un intervalle de VLAN

   The Dedicate VLAN Range dialog is displayed.

9. Spécifier les informations suivantes :

   • VLAN Range: The VLAN range that you want to assign to an account.
   • Account: The account to which you want to assign the selected VLAN range.
   • Domain: The domain associated with the account.

Cas d’usages¶

Les exemples suivants sont des cas d’usages :

• Les périphériques réseaux, comme les pare-feu ou les répartiteurs de charge, fonctionnent généralement mieux lorsqu’ils ont accès à plusieurs adresses IP sur l’interface réseau.

• Déplacer des adresses IP privées entre interfaces ou instances. Les applications qui sont liées à des adresses IP spécifiques peuvent être déplacées entre les instances.

• Héberger plusieurs sites webs SSL sur une seule instance. Vous pouvez installer plusieurs certificats sur une seule instance, chacun associé avec une adresse IP distincte.

Lignes directrices¶

Pour éviter des conflits IP, configurer différents sous-réseaux lorsque plusieurs réseaux sont connectés à la même VM.

Assigner des IPs additionnelles à une VM¶

1. Se connecter à l’interface CloudStack.

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

3. Cliquez sur le nom de l’instance avec laquelle vous souhaitez travailler.

4. Dans l’onglet Détails, cliquer sur Interfaces.

5. Cliquer sur Voir les IPs secondaires.

6. Cliquez sur Obtenir une nouvelle adresse IP, et cliquez sur Oui dans la boîte de dialogue de confirmation.

   Vous devez configurer l’IP sur l’interface de la VM invitée manuellement. CloudStack ne va pas automatiquement configurer l’IP acquise sur la VM. Assurez vous que la configuration de l’adresse IP soit persistante après le redémarrage.

   Au bout de quelques instants, la nouvelle adresse IP devrait apparaître dans l’état Allouée. Vous pouvez maintenant utiliser l’adresse IP pour la redirection de port ou les règles de NAT statiques.

Changements de services de redirection de port et de StaticNAT¶

Étant donné que plusieurs IP peuvent être associées par carte réseau, vous êtes autorisé à sélectionner l’adresse IP désirée pour les services Port Forwarding et StaticNAT. La valeur par défaut est l’adresse IP principale. Pour activer cette fonctionnalité, un paramètre optionnel supplémentaire ‘vmguestip’ est ajouté aux API du port forwarding et du StaticNAT (enableStaticNat, createIpForwardingRule) pour indiquer sur quelle adresse IP le NAT doit être configuré. Si vmguestip est passé, le NAT est configuré sur l’IP privée spécifiée de la VM. Si elle n’est pas passée, le NAT est configuré sur l’adresse IP principale de la VM.

A propos des IP portables¶

Les IP portables dans CloudStack sont des réserves d’adresses IP de niveau région, qui sont élastiques de nature, qui peuvent être transférées entre zones géographiquement séparées. En tant qu’administrateur, vous pouvez provisionner un ensemble d’IP publiques portables au niveau de la région et les rendre disponibles pour utilisation par les utilisateurs. Les utilisateurs peuvent acquérir des adresses IP portables si l’administrateur a fourni des IP portables au niveau de la région dont ils font partie. Ces IP peuvent être utilisées pour n’importe quel service dans une zone avancée. Vous pouvez également utiliser des adresses IP portables pour les services EIP dans les zones basiques.

Les principales caractéristiques d’une IP portable sont :

• L’IP est attribuée de manière statique

• Il n’est pas nécessaire d’associer une IP à un réseau

• L’association IP est transférable entre les réseaux

• Les IP sont transférables entre à la fois les zones basiques et les zones avancées.

• Une IP est transférable entre VPC et les réseaux partagés ou isolés non-VPC

• Le transfert d’IP portable n’est disponible que pour le NAT static.

Configuration des IP portables¶

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

2. Dans la barre de navigation de gauche, cliquer sur Régions.

3. Choisir les régions avec lesquelles vous voulez travailler.

4. Cliquer sur voir l’IP Portable.

5. Cliquer sur la plage d’IP portable

   La fenêtre Ajouter une plage d’IP portable s’affiche.

6. Spécifier les informations suivantes :

   • IP de début, IP de fin : Une plage d’adresses IP qui sera accessible depuis Internet et sera associée aux VM invités. Saisir la première et la dernière adresse qui définissent une plage que CloudStack peut assigner aux VM invités.

   • Passerelle : La passerelle à utiliser pour les adresses IP portables que vous êtes en train de configurer.

   • Masque de sous-réseau : Le masque de sous-réseau associé avec la plage d’IP portable.

   • VLAN : Le VLAN qui va être utilisé pour le trafic public.

7. Cliquez sur OK.

Aquérir une IP portable¶

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Cliquez sur le nom du réseau avec lequel vous souhaitez travailler.

4. Cliquez sur Voir les adresses IP.

5. Cliquer sur Acquérir une nouvelle IP.

   La fenêtre Acquérir une nouvelle IP est affichée.

6. Spécifier si vous voulez une IP transverse à la zone ou non.

7. Cliquer sur Oui dans la boite de dialogue de confirmation.

   Après quelques instants, la nouvelle adresse IP devrait apparaître avec l’état Allouée. Vous pouvez utiliser l’adresse IP dans la redirection de port ou les règles de NATage statiques.

Transférer une IP Portable¶

Une IP peut être transférée depuis un réseau vers un autre seulement si le Static NAT est activé. Cependant, lorsqu’une IP portable est associée à un réseau, vous pouvez l’utiliser pour n’importe quel service du réseau.

Pour transférer une IP portable entre des réseaux, exécutez l’API suivante :

http://localhost:8096/client/api?command=enableStaticNat&response=json&ipaddressid=a4bc37b2-4b4e-461d-9a62-b66414618e36&virtualmachineid=a242c476-ef37-441e-9c7b-b303e2a9cb4f&networkid=6e7cd8d1-d1ba-4c35-bdaf-333354cbd49810

Remplacez l’UUID par l’UUID approprié. Par exemple, si vous souhaitez transférer une adresse IP portable vers le réseau X et une VM Y dans un réseau, exécutez les opérations suivantes:

http://localhost:8096/client/api?command=enableStaticNat&response=json&ipaddressid=a4bc37b2-4b4e-461d-9a62-b66414618e36&virtualmachineid=Y&networkid=X

Prérequis et lignes directrives¶

• Cette fonctionnalité ne peut seulement être implémentée :

  • Sur des adresses IPv4

  • Si le routeur virtuel est le fournisseur DHCP

  • Sur les hyperviseurs KVM, xenServer et VMware

• Configurez manuellement la passerelle du nouveau sous-réseau avant d’ajouter la plage d’IP.

• CloudStack supporte une seule passerelle par sous-réseau ; le chevauchement de réseau n’est pas actuellement pris en compte.

Ajout de plusieurs sous-réseaux à un Réseau Partagé¶

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

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

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

4. Cliquer sur le réseau physique.

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

6. Cliquer sur Réseaux.

7. Choisir les réseaux avec lesquelles vous voulez travailler.

8. Cliquer sur Voir les intervalles IP.

9. Cliquer sur Ajouter une plage d’IP.

   La boîte de dialogue Ajouter une plage d’IP s’affiche comme suit :

   

10. Spécifier les informations suivantes :

    Tous les champs sont obligatoires.

    • Passerelle : La passerelle pour le segment que vous créez. S’assurer que la passerelle est inclue dans l’intervalle du Super CIDR que vous avez spécifié lors de la création du VPC et qu’elle n’est pas en conflit avec un segment du VPC.

    • Masque de sous-réseau : Le masque de sous-réseau pour le segment que vous créez.

      Par exemple, si le CIDR du VPC est 10.0.0.0/16 et que le réseau CIDR du tiers est 10.0.1.0/24, la passerelle du tiers est 10.0.1.1, et le masque de sous réseau du tiers est 255.255.255.0.

    • IP de début, IP de fin : Une plage d’adresses IP qui sera accessible depuis Internet et sera associée aux VM invités. Saisir la première et la dernière adresse qui définissent une plage que CloudStack peut assigner aux VM invités.

11. Cliquez sur OK.

A propos des VLAN Privés¶

In an Ethernet switch, a VLAN is a broadcast domain where hosts can establish direct communication with each another at Layer 2. Private VLAN is designed as an extension of VLAN standard to add further segmentation of the logical broadcast domain. A regular VLAN is a single broadcast domain, whereas a private VLAN partitions a larger VLAN broadcast domain into smaller sub-domains. A sub-domain is represented by a pair of VLANs: a Primary VLAN and a Secondary VLAN. The original VLAN that is being divided into smaller groups is called Primary, which implies that all VLAN pairs in a private VLAN share the same Primary VLAN. All the secondary VLANs exist only inside the Primary. Each Secondary VLAN has a specific VLAN ID associated to it, which differentiates one sub-domain from another.

Three types of ports exist in a private VLAN domain, which essentially determine the behaviour of the participating hosts. Each ports will have its own unique set of rules, which regulate a connected host’s ability to communicate with other connected host within the same private VLAN domain. Configure each host that is part of a PVLAN pair can be by using one of these three port designation:

• Promiscuous: A promiscuous port can communicate with all the interfaces, including the community and isolated host ports that belong to the secondary VLANs. In Promiscuous mode, hosts are connected to promiscuous ports and are able to communicate directly with resources on both primary and secondary VLAN. Routers, DHCP servers, and other trusted devices are typically attached to promiscuous ports.
• Isolated VLANs: The ports within an isolated VLAN cannot communicate with each other at the layer-2 level. The hosts that are connected to Isolated ports can directly communicate only with the Promiscuous resources. If your customer device needs to have access only to a gateway router, attach it to an isolated port.
• Community VLANs: The ports within a community VLAN can communicate with each other and with the promiscuous ports, but they cannot communicate with the ports in other communities at the layer-2 level. In a Community mode, direct communication is permitted only with the hosts in the same community and those that are connected to the Primary PVLAN in promiscuous mode. If your customer has two devices that need to be isolated from other customers’ devices, but to be able to communicate among themselves, deploy them in community ports.

For further reading:

• Understanding Private VLANs
• Cisco Systems’ Private VLANs: Scalable Security in a Multi-Client Environment
• Private VLAN (PVLAN) on vNetwork Distributed Switch - Concept Overview (1010691)

Prérequis¶

• Use a PVLAN supported switch.

  See Private VLAN Catalyst Switch Support Matrix for more information.

• All the layer 2 switches, which are PVLAN-aware, are connected to each other, and one of them is connected to a router. All the ports connected to the host would be configured in trunk mode. Open Management VLAN, Primary VLAN (public) and Secondary Isolated VLAN ports. Configure the switch port connected to the router in PVLAN promiscuous trunk mode, which would translate an isolated VLAN to primary VLAN for the PVLAN-unaware router.

  Note that only Cisco Catalyst 4500 has the PVLAN promiscuous trunk mode to connect both normal VLAN and PVLAN to a PVLAN-unaware switch. For the other Catalyst PVLAN support switch, connect the switch to upper switch by using cables, one each for a PVLAN pair.

• Configure private VLAN on your physical switches out-of-band.

• Before you use PVLAN on XenServer and KVM, enable Open vSwitch (OVS).

  Note

  OVS on XenServer and KVM does not support PVLAN natively. Therefore, CloudStack managed to simulate PVLAN on OVS for XenServer and KVM by modifying the flow table.

Creating a PVLAN-Enabled Guest Network¶

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

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

3. Dans zones, cliquez sur Voir tout.

4. Cliquer sur la zone à laquelle vous voulez ajouter un réseau invité.

5. Cliquer sur l’onglet Réseau.

6. Cliquer sur le réseau physique avec lequel vous voulez travailler.

7. Sur le noeud Invité du diagramme, cliquer sur Configurer.

8. Cliquer sur l’onglet Réseau.

9. Cliquer sur Ajouter un réseau invité.

   La fenêtre Ajouter un réseau invité est affichée :

10. Spécifier les informations suivantes :

    • Nom : Le nom du réseau. Cela sera visible de l’utilisateur.

    • Description : La description courte du réseau qui peut être affichée aux utilisateurs

    • ID VLAN : L’ID unique du VLAN.

    • Secondary Isolated VLAN ID: The unique ID of the Secondary Isolated VLAN.

      For the description on Secondary Isolated VLAN, see About Private VLAN”.

    • Portée : Les portées possibles sont Domaine, Compte, Projet et Tous.

      • Domaine : Sélectionner Domaine limite la partée de ce réseau invité au domaine que vous spécifiez. Le réseau ne sera pas disponible pour les autres domaines.Si vous sélectionnez Accès Sous Domaine, le réseau invité est disponible à tous les sous domaines au sein du domaine sélectionné.

      • Compte : Le compte pour lequel le réseau invité est créé. Vous devez spécifier le domaine auquel appartient le compte.

      • Projet : Le projet pour lequel le réseau invité est créé. Vous devez spécifier le domaine auquel le projet appartient.

      • Tous : Le réseau invité est disponible pour tous les domaines, comptes, projets au sein de la zone sélectionnée.

    • Offre réseau : Si l’administrateur a configuré plusieurs offres de réseau, sélectionnez celle que vous voulez utiliser pour ce réseau.

    • Passerelle : La passerelle que les invités devraient utiliser.

    • Masque de sous réseau : Le masque de sous réseau du réseau que les utilisateurs vont utiliser.

    • Plage IP : Une plage d’adresses IP qui sont accessibles depuis l’Internet est qui sont assignées aux VMs invitées.

    • Domaine Réseau : Un suffixe DNS personnalisé au niveau du réseau. Si vous voulez assigner un nom de domaine spécial au réseau des VM invitées, spécifier un suffixe DNS.

11. Cliquer OK pour confirmer.

A propos des groupes de sécurité¶

Security groups provide a way to isolate traffic to VMs. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM. Security groups are particularly useful in zones that use basic networking, because there is a single guest network for all guest VMs. In advanced zones, security groups are supported only on the KVM hypervisor.

Each CloudStack account comes with a default security group that denies all inbound traffic and allows all outbound traffic. The default security group can be modified so that all new VMs inherit some other desired set of rules.

Any CloudStack user can set up any number of additional security groups. When a new VM is launched, it is assigned to the default security group unless another user-defined security group is specified. A VM can be a member of any number of security groups. Once a VM is assigned to a security group, it remains in that group for its entire lifetime; you can not move a running VM from one security group to another.

You can modify a security group by deleting or adding any number of ingress and egress rules. When you do, the new rules apply to all VMs in the group, whether running or stopped.

If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.

Ajouter un groupe de sécurité¶

Un utilisateur ou un administrateur peut définir un nouveau groupe de sécurité.

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Dans la zone de sélection, choisir Groupes de Sécurité.

4. Cliquer sur Ajouter un groupe de sécurité.

5. Fournir un nom et une description.

6. Cliquez sur OK.

   Le nouveau groupe de sécurité apparaît dans l’onglet Détails des Groupes de Sécurité.

7. Pour rendre le groupe de sécurité utile, continuez par Ajouter des règles Ingress et Egress à un groupe de sécurité.

Groupes de Sécurité dans les Zones Avancées (KVM uniquement)¶

CloudStack provides the ability to use security groups to provide isolation between guests on a single shared, zone-wide network in an advanced zone where KVM is the hypervisor. Using security groups in advanced zones rather than multiple VLANs allows a greater range of options for setting up guest isolation in a cloud.

Activer les groupes de sécurités.¶

In order for security groups to function in a zone, the security groups feature must first be enabled for the zone. The administrator can do this when creating a new zone, by selecting a network offering that includes security groups. The procedure is described in Basic Zone Configuration in the Advanced Installation Guide. The administrator can not enable security groups for an existing zone, only when creating a new zone.

Ajout de règles Ingress et Egress à un Groupe de Sécurité¶

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Dans la liste de choix, choisir Groupes de sécurité puis cliquer sur le groupe de sécurité désiré.

4. To add an ingress rule, click the Ingress Rules tab and fill out the following fields to specify what network traffic is allowed into VM instances in this security group. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.

   • Add by CIDR/Account. Indicate whether the source of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow incoming traffic from all VMs in another security group
   • Protocol. The networking protocol that sources will use to send traffic to the security group. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
   • Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
   • ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be accepted.
   • CIDR. (Add by CIDR only) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
   • Account, Security Group. (Add by Account only) To accept only traffic from another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter the same name you used in step 7.

   L’exemple qui suit autorise l’accès HTTP entrant depuis n’importe où :

   

5. To add an egress rule, click the Egress Rules tab and fill out the following fields to specify what type of traffic is allowed to be sent out of VM instances in this security group. If no egress rules are specified, then all traffic will be allowed out. Once egress rules are specified, the following types of traffic are allowed out: traffic specified in egress rules; queries to DNS and DHCP servers; and responses to any traffic that has been allowed in through an ingress rule

   • Add by CIDR/Account. Indicate whether the destination of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow outgoing traffic to all VMs in another security group.
   • Protocol. The networking protocol that VMs will use to send outgoing traffic. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
   • Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the outgoing traffic. If you are opening a single port, use the same number in both fields.
   • ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be sent
   • CIDR. (Add by CIDR only) To send traffic only to IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
   • Account, Security Group. (Add by Account only) To allow traffic to be sent to another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter its name.

6. Cliquer sur Ajouter.

About Using a NetScaler Load Balancer¶

Citrix NetScaler is supported as an external network element for load balancing in zones that use isolated networking in advanced zones. Set up an external load balancer when you want to provide load balancing through means other than CloudStack’s provided virtual router.

When NetScaler load balancer is used to provide EIP or ELB services in a Basic zone, ensure that all guest VM traffic must enter and exit through the NetScaler device. When inbound traffic goes through the NetScaler device, traffic is routed by using the NAT protocol depending on the EIP/ELB configured on the public IP to the private IP. The traffic that is originated from the guest VMs usually goes through the layer 3 router. To ensure that outbound traffic goes through NetScaler device providing EIP/ELB, layer 3 router must have a policy-based routing. A policy-based route must be set up so that all traffic originated from the guest VM’s are directed to NetScaler device. This is required to ensure that the outbound traffic from the guest VM’s is routed to a public IP by using NAT.For more information on Elastic IP, see “About Elastic IP”.

The NetScaler can be set up in direct (outside the firewall) mode. It must be added before any load balancing rules are deployed on guest VMs in the zone.

The functional behavior of the NetScaler with CloudStack is the same as described in the CloudStack documentation for using an F5 external load balancer. The only exception is that the F5 supports routing domains, and NetScaler does not. NetScaler can not yet be used as a firewall.

To install and enable an external load balancer for CloudStack management, see External Guest Load Balancer Integration in the Installation Guide.

The Citrix NetScaler comes in three varieties. The following summarizes how these variants are treated in CloudStack.

MPX

• Physical appliance. Capable of deep packet inspection. Can act as application firewall and load balancer
• In advanced zones, load balancer functionality fully supported without limitation. In basic zones, static NAT, elastic IP (EIP), and elastic load balancing (ELB) are also provided.

VPX

• Virtual appliance. Can run as VM on XenServer, ESXi, and Hyper-V hypervisors. Same functionality as MPX
• Supported on ESXi and XenServer. Same functional support as for MPX. CloudStack will treat VPX and MPX as the same device type.

SDX

• Physical appliance. Can create multiple fully isolated VPX instances on a single appliance to support multi-tenant usage
• CloudStack will dynamically provision, configure, and manage the life cycle of VPX instances on the SDX. Provisioned instances are added into CloudStack automatically - no manual configuration by the administrator is required. Once a VPX instance is added into CloudStack, it is treated the same as a VPX on an ESXi host.

Configuring SNMP Community String on a RHEL Server¶

The SNMP Community string is similar to a user id or password that provides access to a network device, such as router. This string is sent along with all SNMP requests. If the community string is correct, the device responds with the requested information. If the community string is incorrect, the device discards the request and does not respond.

The NetScaler device uses SNMP to communicate with the VMs. You must install SNMP and configure SNMP Community string for a secure communication between the NetScaler device and the RHEL machine.

1. Ensure that you installed SNMP on RedHat. If not, run the following command:

   yum install net-snmp-utils
   

2. Edit the /etc/snmp/snmpd.conf file to allow the SNMP polling from the NetScaler device.

   1. Map the community name into a security name (local and mynetwork, depending on where the request is coming from):

      Note

      Use a strong password instead of public when you edit the following table.

      #         sec.name   source        community
      com2sec   local      localhost     public
      com2sec   mynetwork  0.0.0.0       public
      

      Note

      Setting to 0.0.0.0 allows all IPs to poll the NetScaler server.

   2. Map the security names into group names:

      #       group.name    sec.model  sec.name
      group   MyRWGroup     v1         local
      group   MyRWGroup     v2c        local
      group   MyROGroup     v1         mynetwork
      group   MyROGroup     v2c        mynetwork
      

   3. Create a view to allow the groups to have the permission to:

      incl/excl subtree mask view all included .1
      

   4. Grant access with different write permissions to the two groups to the view you created.

      # context     sec.model     sec.level      prefix     read     write    notif
        access      MyROGroup ""  any noauth     exact      all      none     none
        access      MyRWGroup ""  any noauth     exact      all      all      all
      

3. Unblock SNMP in iptables.

   iptables -A INPUT -p udp --dport 161 -j ACCEPT
   

4. Start the SNMP service:

   service snmpd start
   

5. Ensure that the SNMP service is started automatically during the system startup:

   chkconfig snmpd on
   

Initial Setup of External Firewalls and Load Balancers¶

When the first VM is created for a new account, CloudStack programs the external firewall and load balancer to work with the VM. The following objects are created on the firewall:

• A new logical interface to connect to the account’s private VLAN. The interface IP is always the first IP of the account’s private subnet (e.g. 10.1.1.1).
• A source NAT rule that forwards all outgoing traffic from the account’s private VLAN to the public Internet, using the account’s public IP address as the source address
• A firewall filter counter that measures the number of bytes of outgoing traffic for the account

The following objects are created on the load balancer:

• A new VLAN that matches the account’s provisioned Zone VLAN
• A self IP for the VLAN. This is always the second IP of the account’s private subnet (e.g. 10.1.1.2).

Ongoing Configuration of External Firewalls and Load Balancers¶

Additional user actions (e.g. setting a port forward) will cause further programming of the firewall and load balancer. A user may request additional public IP addresses and forward traffic received at these IPs to specific VMs. This is accomplished by enabling static NAT for a public IP address, assigning the IP to a VM, and specifying a set of protocols and port ranges to open. When a static NAT rule is created, CloudStack programs the zone’s external firewall with the following objects:

• A static NAT rule that maps the public IP address to the private IP address of a VM.
• A security policy that allows traffic within the set of protocols and port ranges that are specified.
• A firewall filter counter that measures the number of bytes of incoming traffic to the public IP.

The number of incoming and outgoing bytes through source NAT, static NAT, and load balancing rules is measured and saved on each external element. This data is collected on a regular basis and stored in the CloudStack database.

Règles de répartition de charge¶

A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs.

Configuring AutoScale¶

AutoScaling allows you to scale your back-end services or application VMs up or down seamlessly and automatically according to the conditions you define. With AutoScaling enabled, you can ensure that the number of VMs you are using seamlessly scale up when demand increases, and automatically decreases when demand subsides. Thus it helps you save compute costs by terminating underused VMs automatically and launching new VMs when you need them, without the need for manual intervention.

NetScaler AutoScaling is designed to seamlessly launch or terminate VMs based on user-defined conditions. Conditions for triggering a scaleup or scaledown action can vary from a simple use case like monitoring the CPU usage of a server to a complex use case of monitoring a combination of server’s responsiveness and its CPU usage. For example, you can configure AutoScaling to launch an additional VM whenever CPU usage exceeds 80 percent for 15 minutes, or to remove a VM whenever CPU usage is less than 20 percent for 30 minutes.

CloudStack uses the NetScaler load balancer to monitor all aspects of a system’s health and work in unison with CloudStack to initiate scale-up or scale-down actions.

About Global Server Load Balancing¶

Global Server Load Balancing (GSLB) is an extension of load balancing functionality, which is highly efficient in avoiding downtime. Based on the nature of deployment, GSLB represents a set of technologies that is used for various purposes, such as load sharing, disaster recovery, performance, and legal obligations. With GSLB, workloads can be distributed across multiple data centers situated at geographically separated locations. GSLB can also provide an alternate location for accessing a resource in the event of a failure, or to provide a means of shifting traffic easily to simplify maintenance, or both.

Configuring GSLB¶

To configure a GSLB deployment, you must first configure a standard load balancing setup for each zone. This enables you to balance load across the different servers in each zone in the region. Then on the NetScaler side, configure both NetScaler appliances that you plan to add to each zone as authoritative DNS (ADNS) servers. Next, create a GSLB site for each zone, configure GSLB virtual servers for each site, create GLSB services, and bind the GSLB services to the GSLB virtual servers. Finally, bind the domain to the GSLB virtual servers. The GSLB configurations on the two appliances at the two different zones are identical, although each sites load-balancing configuration is specific to that site.

Perform the following as a cloud administrator. As per the example given above, the administrator of xyztelco is the one who sets up GSLB:

1. In the cloud.dns.name global parameter, specify the DNS name of your tenant’s cloud that make use of the GSLB service.

2. On the NetScaler side, configure GSLB as given in Configuring Global Server Load Balancing (GSLB):

   1. Configuring a standard load balancing setup.

   2. Configure Authoritative DNS, as explained in Configuring an Authoritative DNS Service.

   3. Configure a GSLB site with site name formed from the domain name details.

      Configure a GSLB site with the site name formed from the domain name.

      As per the example given above, the site names are A.xyztelco.com and B.xyztelco.com.

      For more information, see Configuring a Basic GSLB Site.

   4. Configurer un serveur virtuel GSLB

      For more information, see Configuring a GSLB Virtual Server.

   5. Configure a GSLB service for each virtual server.

      For more information, see Configuring a GSLB Service.

   6. Bind the GSLB services to the GSLB virtual server.

      For more information, see Binding GSLB Services to a GSLB Virtual Server.

   7. Bind domain name to GSLB virtual server. Domain name is obtained from the domain details.

      For more information, see Binding a Domain to a GSLB Virtual Server.

3. In each zone that are participating in GSLB, add GSLB-enabled NetScaler device.

   For more information, see Enabling GSLB in NetScaler.

As a domain administrator/ user perform the following:

1. Add a GSLB rule on both the sites.

   Voir “Adding a GSLB Rule”.

2. Assign load balancer rules.

   Voir “Assigning Load Balancing Rules to GSLB”.

Limitations connues¶

Currently, CloudStack does not support orchestration of services across the zones. The notion of services and service providers in region are to be introduced.

Activer ou désactiver un NAT Statique¶

Si les règles de redirection de port sont déjà mise en oeuvre pour une adresse IP, vous ne pouvez pas activer le static NAT pour cette IP.

Si une VM invitée fait partie de plus d’un réseau, les règles de static NAT ne fonctionneront uniquement si elle sont définies sur le réseau par défaut.

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Cliquez sur le nom du réseau avec lequel vous souhaitez travailler.

4. Cliquez sur Voir les adresses IP.

5. Cliquer sur l’adresse IP avec laquelle vous voulez travailler.

6. Cliquer sur le bouton Static NAT .

   Le bouton bascule entre Activer et Désactiver, selon que le static NAT est actuellement activé pour l’adresse IP.

7. Si vous activez le static NAT, une boite de dialogue apparaît dans laquelle vous pouvez choisir la VM cible et cliquer sur Appliquer.

Règles du pare-feu¶

By default, all incoming traffic to the public IP address is rejected by the firewall. To allow external traffic, you can open firewall ports by specifying firewall rules. You can optionally specify one or more CIDRs to filter the source IPs. This is useful when you want to allow only incoming requests from certain IP addresses.

You cannot use firewall rules to open ports for an elastic IP address. When elastic IP is used, outside access is instead controlled through the use of security groups. See “Adding a Security Group”.

In an advanced zone, you can also create egress firewall rules by using the virtual router. For more information, see “Egress Firewall Rules in an Advanced Zone”.

Firewall rules can be created using the Firewall tab in the Management Server UI. This tab is not displayed by default when CloudStack is installed. To display the Firewall tab, the CloudStack administrator must set the global configuration parameter firewall.rule.ui.enabled to “true.”

Pour créer une règle de pare-feu :

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Cliquez sur le nom du réseau avec lequel vous souhaitez travailler.

4. Cliquez sur Voir les adresses IP.

5. Cliquer sur l’adresse IP avec laquelle vous voulez travailler.

6. Click the Configuration tab and fill in the following values.
   • Source CIDR: (Optional) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. Example: 192.168.0.0/22. Leave empty to allow all CIDRs.
   • Protocol: The communication protocol in use on the opened port(s).
   • Start Port and End Port: The port(s) you want to open on the firewall. If you are opening a single port, use the same number in both fields
   • ICMP Type and ICMP Code: Used only if Protocol is set to ICMP. Provide the type and code required by the ICMP protocol to fill out the ICMP header. Refer to ICMP documentation for more details if you are not sure what to enter

7. Cliquer sur Ajouter.

Egress Firewall Rules in an Advanced Zone¶

The egress traffic originates from a private network to a public network, such as the Internet. By default, the egress traffic is blocked in default network offerings, so no outgoing traffic is allowed from a guest network to the Internet. However, you can control the egress traffic in an Advanced zone by creating egress firewall rules. When an egress firewall rule is applied, the traffic specific to the rule is allowed and the remaining traffic is blocked. When all the firewall rules are removed the default policy, Block, is applied.

Redirection de port¶

A port forward service is a set of port forwarding rules that define a policy. A port forward service is then applied to one or more guest VMs. The guest VM then has its inbound network access managed according to the policy defined by the port forwarding service. You can optionally specify one or more CIDRs to filter the source IPs. This is useful when you want to allow only incoming requests from certain IP addresses to be forwarded.

A guest VM can be in any number of port forward services. Port forward services can be defined but have no members. If a guest VM is part of more than one network, port forwarding rules will function only if they are defined on the default network

You cannot use port forwarding to open ports for an elastic IP address. When elastic IP is used, outside access is instead controlled through the use of security groups. See Security Groups.

Pour configurer la redirection de port :

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

2. If you have not already done so, add a public IP address range to a zone in CloudStack. See Adding a Zone and Pod in the Installation Guide.
3. Add one or more VM instances to CloudStack.

4. Dans la barre de navigation de gauche, cliquer sur Réseau.

5. Click the name of the guest network where the VMs are running.
6. Choose an existing IP address or acquire a new IP address. See “Acquiring a New IP Address”. Click the name of the IP address in the list.

7. Cliquer sur l’onglet Configuration.

8. In the Port Forwarding node of the diagram, click View All.

9. Remplissez les champs suivants:

   • Public Port: The port to which public traffic will be addressed on the IP address you acquired in the previous step.
   • Private Port: The port on which the instance is listening for forwarded public traffic.
   • Protocol: The communication protocol in use between the two ports

10. Cliquer sur Ajouter.

Configuring Remote Access VPN¶

To set up VPN for the cloud:

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

2. In the left navigation, click Global Settings.
3. Set the following global configuration parameters.
   • remote.access.vpn.client.ip.range - The range of IP addresses to be allocated to remote access VPN clients. The first IP in the range is used by the VPN server.
   • remote.access.vpn.psk.length - Length of the IPSec key.
   • remote.access.vpn.user.limit - Maximum number of VPN users per account.

To enable VPN for a particular network:

1. Log in as a user or administrator to the CloudStack UI.

2. In the left navigation, click Network.

3. Click the name of the network you want to work with.

4. Cliquez sur Voir les adresses IP.

5. Click one of the displayed IP address names.

6. Click the Enable VPN button.

   The IPsec key is displayed in a popup window.

Configuring Remote Access VPN in VPC¶

On enabling Remote Access VPN on a VPC, any VPN client present outside the VPC can access VMs present in the VPC by using the Remote VPN connection. The VPN client can be present anywhere except inside the VPC on which the user enabled the Remote Access VPN service.

To enable VPN for a VPC:

1. Log in as a user or administrator to the CloudStack UI.

2. In the left navigation, click Network.

3. Dans la vue de Sélection, choisissez VPC.

   All the VPCs that you have created for the account is listed in the page.

4. Click the Configure button of the VPC.

   For each tier, the following options are displayed:

   • Internal LB
   • Public LB IP
   • Static NAT

   • Machines Virtuelles

   • CIDR

   The following router information is displayed:

   • Passerelles privées

   • Adresses IP publiques

   • Site-to-Site VPNs

   • Listes d’ACL réseau

5. In the Router node, select Public IP Addresses.

   The IP Addresses page is displayed.

6. Click Source NAT IP address.

7. Click the Enable VPN button.

   Click OK to confirm. The IPsec key is displayed in a pop-up window.

Now, you need to add the VPN users.

1. Click the Source NAT IP.
2. Select the VPN tab.
3. Add the username and the corresponding password of the user you wanted to add.

4. Cliquer sur Ajouter.

5. Repeat the same steps to add the VPN users.

Setting Up a Site-to-Site VPN Connection¶

A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. You can also establish a secure connection between two VPC setups or high availability zones in your environment. Having this facility eliminates the need to establish VPN connections to individual VMs.

The difference from Remote VPN is that Site-to-site VPNs connects entire networks to each other, for example, connecting a branch office network to a company headquarters network. In a site-to-site VPN, hosts do not have VPN client software; they send and receive normal TCP/IP traffic through a VPN gateway.

The supported endpoints on the remote datacenters are:

• Cisco ISR with IOS 12.4 or later
• Juniper J-Series routers with JunOS 9.5 or later
• CloudStack virtual routers

To set up a Site-to-Site VPN connection, perform the following:

1. Create a Virtual Private Cloud (VPC).

   See “Configurer un Cloud Privé Virtuel”.

2. Create a VPN Customer Gateway.

3. Create a VPN gateway for the VPC that you created.

4. Create VPN connection from the VPC VPN gateway to the customer VPN gateway.

A propos des Clouds Privés Virtuels¶

Un Cloud Privé Virtuel CloudStack est une partie privée, isolée de CloudStack. Un VPC peut avoir sa propre topologie de réseau virtuel qui ressemble à un réseau physique traditionnel. Vous pouvez lancer des VMs dans le réseau virtuel qui peuvent avoir des adresses privées dans l’intervalle de votre choix, par exemple : 10.10.10.0/16. Vous pouvez définir des parties de réseau dans l’étendue du réseau de votre VPC, permettant le regroupement des types d’instances similaires en fonction de leur intervalle d’adresse IP.

Par exemple, si un VPC dispose de la plage privée d’adresses IP 10.0.0.0/16, ses réseaux invités peuvent être dans les plages réseaux 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, etc.

Ajouter un Cloud Privé Virtuel¶

Lorsque vous créer le VPC, vous fournissez simplement la zone et un ensemble d’adresses IP pour l’espace d’adresse du réseau du VPC. Vous spécifiez cet ensemble d’adresses dans le format d’un bloc Classless Inter-Domain Routing (CIDR).

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Dans la vue de Sélection, choisissez VPC.

4. Cliquer sur Ajouter VPC. La page Ajouter VPC est affichée comme suivant :

   

   Fournir l’information suivante :

   • Nom : Un nom court pour le VPC que vous êtes en train de créer.

   • Description : Une description courte du VPC.

   • Zone : Choisir la zone dans laquelle vous voulez que le VPC soit disponible.

   • Super CIDR pour les réseaux invités : définir l’intervalle CIDR pour tous les segments (réseaux invités) au sein du VPC. Lorsque vous créez un segment, assurez vous que son CIDR soit compris dans la valeur du Super CIDR que vous avez entré. Le CIDR doit être conforme à la RFC1918.

   • Domaine DNS pour les réseaux invités : si vous voulez assigner un nom de domaine spécial, spécifier le suffixe DNS. Ce paramètre est appliqué à tous les segments au sein du VPC. Cela implique que tous les segments que vous créez dans le VPC appartiennent au même domaine DNS. Si le paramètre n’est pas spécifié, un nom de domaine DNS est généré automatiquement.

   • Fournisseur publique de répartition de charge : Vous avez deux options : Routeur Virtuel VPC et Netscaler.

5. Cliquez sur OK.

Ajouter des segments¶

Les Segments sont des endroits distincts à l’intérieur d’un VPC qui agissent comme des réseaux isolés, et qui n’ont pas accès aux autres tiers par défaut. Les Segments sont configurés sur différents VLANs qui peuvent communiquer entre eux en utilisant un routeur virtuel. Les Tiers fournissent un moyen simple et à faible latence pour se connecter avec d’autres tiers au sein d’un VPC.

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Dans la vue de Sélection, choisissez VPC.

   Tous les VPC que vous avez créé sur ce compte sont listés dans cette page.

   Note

   L’utilisateur final peut voir ses propres VPCs, alors que l’administrateur du domaine ou le root peuvent voir n’importe quel VPC qu’ils sont autorisés à visualier.

4. Cliquez sur le bouton Configurer du VPC pour lequel vous désirez configurer un segment.

5. Cliquer sur Créer un réseau.

   La boîte de dialogue Ajouter un nouveau segment s’affiche comme suit :

   

   Si vous avez déjà créé un segment, le diagramme du VPC est affiché. Cliquez sur Créer un segment pour en ajouter un nouveau.

6. Spécifier les informations suivantes :

   Tous les champs sont obligatoires.

   • Nom : Un nom unique pour le segment que vous créez.

   • Offre réseau : Les offres par défaut de réseaux sont listées : Internal LB, DefaultIsolatedNetworkOfferingForVpcNetworksNoLB, DefaultIsolatedNetworkOfferingForVpcNetworks

     Dans un VPC, un seul segment peut être créé en utilisant une offre réseau avec répartition de charge activée.

   • Passerelle : La passerelle pour le segment que vous créez. S’assurer que la passerelle est inclue dans l’intervalle du Super CIDR que vous avez spécifié lors de la création du VPC et qu’elle n’est pas en conflit avec un segment du VPC.

   • VLAN : L’ID du VLAN pour le segment que l’administrateur root créé.

     Cette option n’est seulement visible que si l’offre réseau que vous avez sélectionné est VLAN-enabled.

     Pour plus d’informations, voir “Assigner des VLANs à des réseaux isolés”.

   • Masque de sous-réseau : Le masque de sous-réseau pour le segment que vous créez.

     Par exemple, si le CIDR du VPC est 10.0.0.0/16 et que le réseau CIDR du tiers est 10.0.1.0/24, la passerelle du tiers est 10.0.1.1, et le masque de sous réseau du tiers est 255.255.255.0.

7. Cliquez sur OK.

8. Continuer avec la configuration des contrôle d’accès pour ce segment.

Configurer une liste de contrôle d’accès réseau¶

Définissez la liste de contrôle d’accès réseau (ACL) sur le routeur virtuel VPC pour contrôler le trafic entrant (ingress) et sortant (egress) entre les VPC des segments, les segments et Internet. Par défaut, tout le trafic entrant vers les réseaux invités est bloqué et tout le trafic sortant des réseaux invités est autorisé, une fois que vous ajoutez une règle ACL pour le trafic sortant, seul le trafic sortant spécifié dans cette règle ACL est autorisé, le reste est bloqué. Pour ouvrir les ports, vous devez créer une nouvelle ACL réseau. Les ACL réseau ne peuvent être créées pour les segments que si le service NetworkACL est pris en charge.

Ajouter une passerelle privée à un VPC¶

A private gateway can be added by the root admin only. The VPC private network has 1:1 relationship with the NIC of the physical network. You can configure multiple private gateways to a single VPC. No gateways with duplicated VLAN and IP are allowed in the same data center.

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Dans la vue de Sélection, choisissez VPC.

   All the VPCs that you have created for the account is listed in the page.

4. Click the Configure button of the VPC to which you want to configure load balancing rules.

   The VPC page is displayed where all the tiers you created are listed in a diagram.

5. Cliquer sur l’icône Paramètres.

   Les options suivantes sont affichées.

   • Internal LB
   • Public LB IP
   • Static NAT

   • Machines Virtuelles

   • CIDR

   The following router information is displayed:

   • Passerelles privées

   • Adresses IP publiques

   • Site-to-Site VPNs

   • Listes d’ACL réseau

6. Sélectionner Passerelles privées.

   La page Passerelles est affichée.

7. Cliquer sur Ajouter une nouvelle passerelle :

   add-new-gateway-vpc.png|

8. Spécifier les informations suivantes :

   • Réseau physique : Le réseau physique que vous avez créé dans la zone.

   • Adresse IP : L’adresse IP associée avec la passerelle du VPC.

   • Passerelle : La passerelle par laquelle le trafic est routé depuis et vers le VPC.

   • Masque de sous-réseaux : Le masque de sous-réseaux associé avec la passerelle du VPC.

   • VLAN : Le VLAN associé avec la passerelle du VPC.

   • Source NAT : Sélectionner cette option pour activer le service de NAT source sur la passerelle privée du VPC.

     Voir “Source NAT on Private Gateway”.

   • ACL: Controls both ingress and egress traffic on a VPC private gateway. By default, all the traffic is blocked.

     Voir “ACL sur une passerelle privée”.

   The new gateway appears in the list. You can repeat these steps to add more gateway for this VPC.

Déployer des VM dans un segment¶

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Dans la vue de Sélection, choisissez VPC.

   All the VPCs that you have created for the account is listed in the page.

4. Click the Configure button of the VPC to which you want to deploy the VMs.

   The VPC page is displayed where all the tiers you have created are listed.

5. Click Virtual Machines tab of the tier to which you want to add a VM.

   

   The Add Instance page is displayed.

   Follow the on-screen instruction to add an instance. For information on adding an instance, see the Installation Guide.

Deploying VMs to VPC Tier and Shared Networks¶

CloudStack allows you deploy VMs on a VPC tier and one or more shared networks. With this feature, VMs deployed in a multi-tier application can receive monitoring services via a shared network provided by a service provider.

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

2. Dans la barre de navigation de gauche, choisir Instances.

3. Cliquer sur Ajouter une instance.

4. Sélectionner une zone.

5. Select a template or ISO, then follow the steps in the wizard.

6. Ensure that the hardware you have allows starting the selected service offering.

7. Under Networks, select the desired networks for the VM you are launching.

   You can deploy a VM to a VPC tier and multiple shared networks.

   

8. Click Next, review the configuration and click Launch.

   Your VM will be deployed to the selected VPC tier and shared network.

Acquérir une nouvelle adresse IP pour un VPC¶

When you acquire an IP address, all IP addresses are allocated to VPC, not to the guest networks within the VPC. The IPs are associated to the guest network only when the first port-forwarding, load balancing, or Static NAT rule is created for the IP or the network. IP can’t be associated to more than one network at a time.

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Dans la vue de Sélection, choisissez VPC.

   All the VPCs that you have created for the account is listed in the page.

4. Click the Configure button of the VPC to which you want to deploy the VMs.

   The VPC page is displayed where all the tiers you created are listed in a diagram.

   Les options suivantes sont affichées.

   • Internal LB
   • Public LB IP
   • Static NAT

   • Machines Virtuelles

   • CIDR

   The following router information is displayed:

   • Passerelles privées

   • Adresses IP publiques

   • Site-to-Site VPNs

   • Listes d’ACL réseau

5. Sélectionner les adresses IP.

   La page des Adresses IP Publiques est affichée.

6. Cliquez sur Obtenir une nouvelle adresse IP, et cliquez sur Oui dans la boîte de dialogue de confirmation.

   You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding, load balancing, and static NAT rules.

Releasing an IP Address Alloted to a VPC¶

The IP address is a limited resource. If you no longer need a particular IP, you can disassociate it from its VPC and return it to the pool of available addresses. An IP address can be released from its tier, only when all the networking ( port forwarding, load balancing, or StaticNAT ) rules are removed for this IP address. The released IP address will still belongs to the same VPC.

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Dans la vue de Sélection, choisissez VPC.

   All the VPCs that you have created for the account is listed in the page.

4. Click the Configure button of the VPC whose IP you want to release.

   The VPC page is displayed where all the tiers you created are listed in a diagram.

   Les options suivantes sont affichées.

   • Internal LB
   • Public LB IP
   • Static NAT

   • Machines Virtuelles

   • CIDR

   The following router information is displayed:

   • Passerelles privées

   • Adresses IP publiques

   • Site-to-Site VPNs

   • Listes d’ACL réseau

5. Sélectionner Adresses IP Publiques.

   The IP Addresses page is displayed.

6. Cliquer sur l’IP que vous voulez rendre.

7. In the Details tab, click the Release IP button

Enabling or Disabling Static NAT on a VPC¶

A static NAT rule maps a public IP address to the private IP address of a VM in a VPC to allow Internet traffic to it. This section tells how to enable or disable static NAT for a particular IP address in a VPC.

Si les règles de redirection de port sont déjà mise en oeuvre pour une adresse IP, vous ne pouvez pas activer le static NAT pour cette IP.

Si une VM invitée fait partie de plus d’un réseau, les règles de static NAT ne fonctionneront uniquement si elle sont définies sur le réseau par défaut.

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

2. Dans la navigation à gauche, choisissez Réseau.

3. Dans la vue de Sélection, choisissez VPC.

   All the VPCs that you have created for the account is listed in the page.

4. Click the Configure button of the VPC to which you want to deploy the VMs.

   The VPC page is displayed where all the tiers you created are listed in a diagram.

   For each tier, the following options are displayed.

   • Internal LB
   • Public LB IP
   • Static NAT

   • Machines Virtuelles

   • CIDR

   The following router information is displayed:

   • Passerelles privées

   • Adresses IP publiques

   • Site-to-Site VPNs

   • Listes d’ACL réseau

5. In the Router node, select Public IP Addresses.

   The IP Addresses page is displayed.

6. Cliquer sur l’IP avec laquelle vous voulez travailler.

7. In the Details tab,click the Static NAT button. The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.

8. If you are enabling static NAT, a dialog appears as follows:

   

9. Select the tier and the destination VM, then click Apply.

Adding Load Balancing Rules on a VPC¶

In a VPC, you can configure two types of load balancing: external LB and internal LB. External LB is nothing but a LB rule created to redirect the traffic received at a public IP of the VPC virtual router. The traffic is load balanced within a tier based on your configuration. Citrix NetScaler and VPC virtual router are supported for external LB. When you use internal LB service, traffic received at a tier is load balanced across different VMs within that tier. For example, traffic reached at Web tier is redirected to another VM in that tier. External load balancing devices are not supported for internal LB. The service is provided by a internal LB VM configured on the target tier.