Gérer le cloud¶

Utiliser les étiquettes pour organiser les ressources dans le Cloud¶

Une étiquette est une paire clé-valeur qui stocke des métadonnées sur une ressource dans le cloud. Les étiquettes sont utiles pour catégoriser les ressources. Par exemple, vous pouvez étiqueter une VM utilisateur avec une valeur qui indique la ville de résidence de l’utilisateur. Dans ce cas, la clé serait «ville» et la valeur pourrait être «Toronto» ou «Tokyo». Vous pouvez alors demander à CloudStack de trouver toutes les ressources qui ont une étiquette donnée ; Par exemple, les VM pour les utilisateurs d’une ville donnée.

Vous pouvez étiqueter une machine virtuelle utilisateur, un volume, un instantané, un réseau invité, un modèle, une ISO, une règle de pare-feu, une règle de transfert de port, une adresse IP publique, un groupe de sécurité, une règle de répartition de charge, un projet, un VPC, une ACL réseau ou une route statique. Vous ne pouvez pas marquer un VPN à accès distant.

Vous pouvez travailler avec des étiquettes via l’interface utilisateur ou via les commandes API createTags, deleteTags et listTags. Vous pouvez définir plusieurs étiquettes pour chaque ressource. Il n’y a pas de limite sur le nombre d’étiquettes que vous pouvez définir. Chaque étiquette peut comporter jusqu’à 255 caractères. Les utilisateurs peuvent définir des étiquettes sur les ressources dont ils sont les propriétaires et les administrateurs peuvent définir des étiquettes sur toutes les ressources du cloud.

Un paramètre d’entrée optionnel, “tags”, existe sur plusieurs commandes list* API. L’exemple suivant montre comment utiliser ce nouveau paramètre pour trouver tous les volumes ayant l’étiquette region=canada OR etiquette city=Toronto:

command=listVolumes
   &listAll=true
   &tags[0].key=region
   &tags[0].value=canada
   &tags[1].key=city
   &tags[1].value=Toronto

Les commandes d’API suivantes ont le paramètre d’entrée “tags” :

• listVirtualMachines
• listVolumes
• listSnapshots
• listNetworks
• listTemplates
• listIsos
• listFirewallRules
• listPortForwardingRules
• listPublicIpAddresses
• listSecurityGroups
• listLoadBalancerRules
• listProjects
• listVPCs
• listNetworkACLs
• listStaticRoutes

Rapport sur les sockets CPU¶

PRODUCT gère différents types d’hôtes qui contiennent une ou plusieurs sockets de CPU physiques. La socket du CPU est considéré comme une unité de mesure utilisée les licences et la facturation de l’infrastructure cloud. PRODUCT fournit à la fois l’interface utilisateur et le support API pour collecter les statistiques du socket du CPU à des fins de facturation. L’onglet Infrastructure comporte un nouvel onglet pour les sockets CPU. Vous pouvez afficher les statistiques des sockets CPU gérés par PRODUCT, qui reflètent en retour la taille du cloud. La page Socket CPU vous donnera le nombre d’hôtes et de sockets utilisés pour chaque type d’hôte.

1. Se connecter à l’interface utilisateur PRODUCT.

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

3. Sur Sockets CPU, cliquer sur Voir tout

   La page Socket CPU est affichée. La page montre le nombre d’hôtes et de sockets CPU basé sur le type d’hyperviseur.

Changer la configuration de la base de données¶

Le serveur de gestion CloudStack stocke les informations de configuration de sa base de données (par exemple nom de machine, port, mot de passes) dans le fichier /etc/cloudstack/management/db.properties. Pour prendre en compte les changements, editer ce fichier sur chaque serveur de Gestion, puis redémarrer le serveur de gestion.

Changer le mot de passe de la base de données¶

Vous devrez peut-être modifier le mot de passe du compte MySQL utilisé par CloudStack. Dans ce cas, vous devrez changer le mot de passe dans MySQL, puis ajouter le mot de passe crypté dans /etc/cloudstack/management/db.properties.

1. Avant de changer le mot de passe, vous devrez stopper le serveur de gestion de CloudStack et le moteur d’usage si vous avez déployé ce composant.

   # service cloudstack-management stop
   # service cloudstack-usage stop
   

2. Ensuite, vous allez mettre à jour le mot de passe pour l’utilisateur CloudStack sur le serveur MySQL.

   # mysql -u root -p
   

   Au prompt de MySQL, vous allez changer le mot de passe et appliquer les privilèges :

   update mysql.user set password=PASSWORD("newpassword123") where User='cloud';
   flush privileges;
   quit;
   

3. L’étape suivante consiste à crypter le mot de passe et à copier le mot de passe crypté dans la configuration de la base de données de CloudStack (/etc/cloudstack/management/db.properties).

   # java -classpath /usr/share/cloudstack-common/lib/jasypt-1.9.0.jar \ org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI encrypt.sh \ input="newpassword123" password="`cat /etc/cloudstack/management/key`" \ verbose=false
   

Type de cryptage de fichiers¶

Notez que cela concerne le type de cryptage de fichier. Si vous utilisez le type de cryptage web alors vous allez utiliser password=”management_server_secret_key”

1. Maintenant, vous allez mettre à jour /etc/cloudstack/management/db.properties avec le nouveau ciphertext. Ouvrez /etc/cloudstack/management/db.properties dans un éditeur de texte et mettez à jour ces paramètres :

   db.cloud.password=ENC(encrypted_password_from_above)
   db.usage.password=ENC(encrypted_password_from_above)
   

2. Après avoir copier le nouveau mot de passe, vous pouvez maintenant démarrer CloudStack (et le moteur d’usage, si nécessaire).

   # service cloudstack-management start
   # service cloud-usage start
   

Alertes pour administrateur¶

Le système fournit des alertes et des évènements pour aider à la gestion du cloud. Les alertes sont des avis pour les administrateurs, généralement délivrés par mail, le notifiant qu’une erreur s’est produite dans le cloud. Le comportement des alertes est configurable.

Les événements tracent toutes les actions de l’utilisateur et de l’administrateur dans le cloud. Par exemple, chaque VM invitée démarrée crée un événement associé. Les événements sont stockés dans la base de données du serveur d’administration.

Des emails seront envoyés aux administrateurs dans les circonstances suivantes :

• Les ressources du cluster de serveurs de gestion sont faibles en CPU, en mémoire ou en ressources de stockage

• Le serveur de gestion a perdu le battement de coeur d’un hôte depuis plus de 3 minutes.

• Les ressources du cluster d’hôtes sont faibles en CPU, en mémoire ou en ressources de stockage

MEMORY = 0 // Available Memory below configured threshold

CPU = 1 // Unallocated CPU below configured threshold

STORAGE =2 // Available Storage below configured threshold

STORAGE_ALLOCATED = 3 // Remaining unallocated Storage is below configured threshold

PUBLIC_IP = 4 // Number of unallocated virtual network public IPs is below configured threshold

PRIVATE_IP = 5 // Number of unallocated private IPs is below configured threshold

SECONDARY_STORAGE = 6 //  Available Secondary Storage in availability zone is below configured threshold

HOST = 7 // Host related alerts like host disconnected

USERVM = 8 // User VM stopped unexpectedly

DOMAIN_ROUTER = 9 // Domain Router VM stopped unexpectedly

CONSOLE_PROXY = 10 // Console Proxy VM stopped unexpectedly

ROUTING = 11 // Lost connection to default route (to the gateway)

STORAGE_MISC = 12 // Storage issue in system VMs

USAGE_SERVER = 13 // No usage server process running

MANAGMENT_NODE = 14 // Management network CIDR is not configured originally

DOMAIN_ROUTER_MIGRATE = 15 // Domain Router VM Migration was unsuccessful

CONSOLE_PROXY_MIGRATE = 16 // Console Proxy VM Migration was unsuccessful

USERVM_MIGRATE = 17 // User VM Migration was unsuccessful

VLAN = 18 // Number of unallocated VLANs is below configured threshold in availability zone

SSVM = 19 // SSVM stopped unexpectedly

USAGE_SERVER_RESULT = 20 // Usage job failed

STORAGE_DELETE = 21 // Failed to delete storage pool

UPDATE_RESOURCE_COUNT = 22 // Failed to update the resource count

USAGE_SANITY_RESULT = 23 // Usage Sanity Check failed

DIRECT_ATTACHED_PUBLIC_IP = 24 // Number of unallocated shared network IPs is low in availability zone

LOCAL_STORAGE = 25 // Remaining unallocated Local Storage is below configured threshold

RESOURCE_LIMIT_EXCEEDED = 26 //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots only

Date severity_level Management_Server_IP_Address/Name  alertType:: value dataCenterId:: value  podId:: value  clusterId:: value  message:: value

Mar  4 10:13:47    WARN    localhost    alertType:: managementNode message:: Management server node 127.0.0.1 is up

Personnaliser le Nom de domaine du réseau¶

L’administrateur racine peut optionnellement affecter un suffixe DNS personnalisé au niveau d’un réseau, d’un compte, d’un domaine, d’une zone ou de toute l’installation de CloudStack, et un administrateur de domaine peut le faire dans son propre domaine. Pour spécifier un nom de domaine personnalisé et le mettre en œuvre, procédez comme ceci :

1. Définir le suffixe DNS sur la portée souhaitée

   • Au niveau du réseau, le suffixe DNS peut être attribué via l’interface utilisateur à la création d’un nouveau réseau, comme décrit dans “Ajout d’un réseau d’invités supplémentaire” ou via la commande updateNetwork de l’API CloudStack.

   • Au niveau du compte, du domaine ou de la zone, le suffixe DNS peut être attribué avec les commandes appropriées de l’API CloudStack : createAccount, editAccount, createDomain, editDomain, createZone ou editZone.

   • Au niveau global, utilisez le paramètre de configuration guest.domain.suffix. Vous pouvez également utiliser la commande updateConfiguration de l’API CloudStack. Après avoir modifié cette configuration globale, redémarrez le serveur de gestion pour prendre en compte le nouveau paramètre.

2. Pour que le nouveau suffixe DNS prenne effet pour un réseau existant, appelez la commande updateNetwork de l’API CloudStack. Cette étape n’est pas nécessaire lorsque le suffixe DNS a été spécifié lors de la création d’un nouveau réseau.

La source du domaine du réseau qui est utilisée dépend des règles suivantes.

• Pour tous les réseaux, si un domaine réseau est spécifié comme faisant partie de la configuration propre à son réseau, cette valeur est utilisée.

• Pour un réseau spécifique à un compte, le domaine réseau spécifié pour le compte est utilisé. Si aucun n’est spécifié, le système recherche une valeur dans le domaine, la zone et la configuration globale, dans cet ordre.

• Pour un réseau spécifique à un domaine, le domaine réseau spécifié pour le domaine est utilisé. Si aucun n’est spécifié, le système recherche une valeur dans la zone et dans la configuration globale, dans cet ordre.

• Pour un réseau spécifique à une zone, le domaine réseau spécifié pour la zone est utilisé. Si aucun n’est spécifié, le système recherche une valeur dans la configuration globale.

Arrêter et redémarrer le serveur de gestion¶

L’administrateur racine va devoir stopper et redémarrer le serveur de gestion de temps en temps.

Par exemple, après avoir changé un paramètre de configuration global, un redémarrage est requis. Si vous avez plusieurs noeuds de serveurs de gestion, tous les redémarrer pour rendre la nouvelle valeur du paramètre effectivement permanente dans le cloud.

Pour stopper le serveur de gestion, exécuter la commande suivante à l’invite de commande du système d’exploitation sur le noeud du serveur de gestion.

# service cloudstack-management stop

Pour démarrer le serveur de gestion :

# service cloudstack-management start