Centre d’information VMware vSphere ESX et VMware vSphere ESXi

Présentation de la gestion

La fonction de gestion assurée par les agents exécutant la console du service VMware ESX est désormais disponible via des API dans la nouvelle architecture d’hyperviseur vSphere ESXi. Ainsi, la surveillance du matériel et la gestion du système se font désormais sans agent. VMware a également créé des interfaces de ligne de commande à distance, telles que vSphere Command Line Interface (vCLI) et PowerCLI, afin de permettre l’exécution de scripts et de commandes avec un contrôle accru. Ces interfaces comportent un large choix de commandes de configuration, de diagnostic et de résolution des problèmes. Pour les diagnostics à portée restreinte et la configuration initiale, des interfaces avec menus et lignes de commandes sont disponibles sur la console locale du serveur.

Guide opérationnel de vSphere ESXi

Découvrez comment réaliser les tâches de data center courantes dans votre environnement VMware ESXi en examinant ce qui différencie sur le plan opérationnel les architectures ESX et ESXi.

L’application de correctifs et la mise à jour des hôtes vSphere exécutant VMware ESXi optimisent la flexibilité et le contrôle. Pendant l’application de correctifs, seuls les modules spécifiques mis à jour sont modifiés, ce qui permet à l’administrateur de préserver les mises à jour antérieures apportées à d’autres composants. Qu’il soit installé sur disque ou sur mémoire flash intégrée, VMware ESXi s’appuie sur une approche « image double », qui permet la présence juxtaposée de l’image mise à jour et de l’image antérieure. Lorsqu’un correctif est installé, la nouvelle image est copiée sur l’hôte et le chargeur de démarrage est modifié de manière à utiliser cette nouvelle image. En cas de problème avec la mise à jour ou si l’administrateur souhaite revenir à l’image antérieure, l’hôte est simplement redémarré. L’administrateur peut alors interrompre le processus de démarrage en appuyant simultanément sur les touches « Maj » et « R » pour obliger l’hôte à utiliser l’image antérieure à la mise à jour.

Déploiement

Installation à l’aide de scripts : il est possible d’effectuer une installation à l’aide de scripts du logiciel de l’hyperviseur vSphere ESXi sur le disque local d’un serveur. Plusieurs méthodes de déploiement sont prises en charge, telles que le démarrage du programme d’installation vSphere à partir d’un CD/DVD ou via le réseau en utilisant PXE, et l’accès au fichier de configuration via le réseau en utilisant plusieurs protocoles, tels que HTTP sécurisé. Le fichier de configuration peut également spécifier les scripts suivants à exécuter lors de l’installation :

  • Avant installation
  • Après installation
  • Premier démarrage

Ces scripts, qui s’exécutent localement sur l’hôte vSphere, peuvent effectuer plusieurs tâches telles que la configuration de la mise en réseau virtuel de l’hôte et son ajout à vCenter Server.

Démarrage à partir du SAN : la prise en charge du démarrage à partir du SAN existe également dans l’architecture VMware ESXi. Elle comprend les SAN Fibre Channel, ainsi que iSCSI et FCoE pour certains adaptateurs de stockage compatibles.

Surveillance du matériel (avec SNMP)

Le modèle de données unifié (Common Information Model, CIM) est un standard ouvert qui définit une architecture pour la surveillance des ressources matérielles, sans agent et basée sur des standards, pour les hôtes vSphere sur lesquels VMware ESXi est installé. Cette structure se compose d’un CIM Object Manager, souvent appelé courtier (broker) CIM, et d’un ensemble de fournisseurs CIM.

Les fournisseurs CIM sont utilisés comme mécanisme pour octroyer les accès de gestion aux pilotes de périphériques et au matériel sous-jacent. Les fabricants de matériel, notamment les fabricants de serveurs et les fournisseurs de périphériques spécifiques, peuvent créer ce type de fournisseurs afin d’assurer la surveillance et la gestion de leurs périphériques spécifiques. VMware crée également des fournisseurs qui mettent en œuvre la surveillance de l’infrastructure de stockage du matériel serveur et les ressources spécifiques à la virtualisation. Ces fournisseurs sont exécutés au sein même de l’hôte vSphere. Ils sont donc conçus pour être extrêmement légers et dédiés à des tâches de gestion spécifiques. Le courtier CIM recueille des informations auprès de tous les fournisseurs CIM et les diffuse à l’extérieur par le biais d’API standard, telles que WS-MAN et CIM-XML. Tout outil logiciel capable de comprendre l’une de ces API, par exemple HP SIM ou Dell OpenManage, peut alors lire ces informations et donc assurer la surveillance du matériel de l’hôte vSphere.

VMware vCenter Server est l’un des utilisateurs de ces informations CIM. À partir d’un onglet dédié dans vSphere Client, vous pouvez afficher le statut matériel de n’importe quel hôte vSphere de votre environnement. Vous avez donc accès à une vue centralisée de l’intégrité matérielle et virtuelle de vos systèmes. Vous pouvez également configurer des alarmes vCenter Server qui se déclenchent en cas d’événements spécifiques sur le matériel, par exemple une variation de température, une panne de courant ou des avertissements.

vSphere affiche également des informations sur le statut du matériel via SNMP pour d’autres outils de gestion qui utilisent cette norme. Les pièges SNMP sont disponibles à la fois depuis l’hôte vSphere et vCenter Server.

Gestion et sauvegarde des systèmes

Les produits de gestion et de sauvegarde des systèmes s’intègrent avec vSphere via les API VMware vSphere. Ce modèle d’intégration basé sur les API réduit considérablement le temps système de gestion en évitant toute installation et toute gestion d’agents dans le COS.

VMware a travaillé en étroite collaboration avec son écosystème afin d’assurer la transition de tous les produits partenaires vers le modèle d’intégration de l’hyperviseur VMware ESXi basé sur les API. En conséquence, la majorité des fournisseurs de solutions de gestion et de sauvegarde des systèmes au sein de l’écosystème VMware prennent à présent en charge VMware ESXi. Des fournisseurs tels que BMC, CA, HP, IBM, EMC, NetIQ, Quest Software, Commvault, Vizioncore, Double-Take Software, SteelEye et Symantec font partie des nombreux partenaires dont les produits de gestion et de sauvegarde des systèmes prennent en charge la nouvelle architecture VMware ESXi. Si vous utilisez une solution partenaire basée sur des agents et intégrée à l’architecture antérieure VMware ESX, contactez votre fournisseur afin de savoir si une version plus récente du produit prend en charge VMware ESXi.

Journalisation

La journalisation est importante pour résoudre les problèmes et garantir la conformité. vSphere diffuse les fichiers journaux de tous les composants système au format syslog standard. Ces fichiers peuvent être transmis à un serveur de journalisation central. La consignation permanente dans un fichier d’une banque de données locale, accessible à l’hôte vSphere, peut s’effectuer automatiquement si une banque de données adaptée est disponible.

La synchronisation de l’hôte vSphere avec une source temporelle précise est primordiale pour garantir l’exactitude des fichiers journaux et obligatoire pour des raisons de conformité. Elle est également importante si vous utilisez l’hôte pour assurer l’exactitude des horloges sur les machines virtuelles clientes. Les hôtes vSphere intègrent des fonctions NTP pour la synchronisation avec les serveurs d’horloge NTP.

Authentification des utilisateurs

Bien que les opérations courantes soient effectuées dans vCenter Server, il faut, dans certains cas, intervenir directement dans l’hôte vSphere. Par exemple, pour l’accès aux fichiers journaux et la sauvegarde des configurations. Pour contrôler les accès à l’hôte, vous pouvez configurer l’hôte vSphere de façon à l’associer à un domaine Active Directory. Ainsi, les utilisateurs qui tentent d’accéder à l’hôte sont automatiquement authentifiés par rapport à l’annuaire utilisateur centralisé. Les utilisateurs locaux peuvent aussi être définis et gérés hôte par hôte, et configurés à l’aide de vSphere Client, de vCLI ou de PowerCLI. Cette seconde méthode peut remplacer ou compléter la technique d’intégration à Active Directory.

Vous pouvez également créer des rôles locaux, similaires aux rôles dans vCenter, qui déterminent ce que l’utilisateur est autorisé à effectuer sur l’hôte. En l’occurrence, un utilisateur peut se voir accorder un accès en lecture seule. Il ne peut alors que consulter les informations de l’hôte. Il peut aussi bénéficier d’un accès en administrateur, ce qui lui permet à la fois de consulter et de modifier la configuration de l’hôte. Si l’hôte est intégré à Active Directory, des rôles locaux peuvent également être accordés aux groupes et utilisateurs AD.

Le seul utilisateur défini par défaut sur le système est l’utilisateur root. Le mot de passe racine initial est généralement défini via la DCUI (Direct Console User Interface) ou pendant une installation automatique. Il peut ensuite être modifié à partir de vSphere Client, de vCLI ou de PowerCLI.

Dans vSphere 5.5, les utilisateurs peuvent se voir octroyer des privilèges administratifs leur permettant de bénéficier automatiquement d’un accès complet au shell. Grâce à cet accès complet au shell, les utilisateurs bénéficiant de privilèges administratifs n’ont plus besoin de s’authentifier comme superutilisateurs pour exécuter des commandes soumises à des droits d’accès.

Dans vSphere 5.5, toutes les activités de l’hôte, à partir du shell comme de l’interface DCUI (Direct Console User Interface), sont désormais journalisées dans le compte de l’utilisateur connecté. Cette délégation du contrôle aux utilisateurs permet de simplifier la surveillance et l’audit des activités sur l’hôte.

Diagnostics

Direct Console User Interface (DCUI)

La DCUI (Direct Console User Interface) est l’interface à menus disponible sur la console du serveur physique sur lequel VMware ESXi est installé ou intégré. Sa principale fonction est d’effectuer la configuration initiale de l’hôte (adresse IP, nom d’hôte, mot de passe racine) et les diagnostics.

La DCUI comporte plusieurs éléments de menu pour les diagnostics permettant aux administrateurs d’effectuer les opérations suivantes :

  • Redémarrer tous les agents de gestion, parmi lesquels :
    • hostd
    • Vpxa
  • Réinitialiser les paramètres de configuration, tels que :
    • Corriger vNetwork Distributed Switch en cas de mauvaise configuration
    • Réinitialiser toutes les configurations sur les paramètres d’origine
  • Activer VMware ESXi Shell pour le dépannage, y compris :
    • Accès local (sur la console de l’hôte)
    • Accès distant (protocole SSH)
Accès aux fichiers sur navigateur

Vous pouvez également configurer un navigateur Web ordinaire afin qu’il pointe vers l’hôte et afficher les fichiers, notamment :

  • Fichiers journaux
  • Fichiers de configuration
  • Fichiers de la machine virtuelle
vSphere Command Line Interface (vCLI)

L’interface vCLI présente de nombreuses commandes pour la résolution des problèmes, parmi lesquelles :

  • vmkfstools
  • vmware-cmd
  • resxtop

Dans vSphere 5.5, l’interface vCLI a été modifiée pour offrir une fonctionnalité et une flexibilité optimales. Désormais, quasiment toutes les opérations d’ESXi Shell peuvent également s’effectuer avec vCLI.

ESXi Shell

VMware ESXi Shell (anciennement Mode Support technique) est une console locale destinée au support technique avancé. Disponible sur la console locale d’un hôte, elle est aussi accessible à distance via SSH. L’accès à ESXi Shell est contrôlé comme suit :

  • L’accès à ESXi Shell en local et à distance peut être activé et désactivé séparément dans la DCUI et vCenter Server.
  • ESXi Shell est accessible à tout utilisateur autorisé, et pas seulement à l’utilisateur racine. Les utilisateurs reçoivent l’autorisation quand le rôle d’administrateur leur est affecté sur un hôte (notamment via l’appartenance AD dans un groupe privilégié).
  • Toutes les commandes générées dans VMware ESXi Shell sont consignées, ce qui garantit un journal d’audit complet. Si un serveur syslog est configuré, ce journal d’audit est inclus automatiquement dans la consignation distante.
  • Un délai d’attente peut être configuré pour ESXi Shell (local et distant), de telle sorte qu’une fois activé, il sera désactivé automatiquement une fois le délai configuré écoulé.