Mettre en place des règles d’affinité dans un cluster DRS sous VMware vSphere

Les règles d’affinité permettent de définir que certaines machines virtuelles doivent être placées sur le même hôte ESX (affinity) ou au contraire sur des hôtes distincts (anti-affinity).

En général, on présume que les règles d’affinité s’établissent pour améliorer les performances et que les règles d’anti-affinité privilégient au contraire la haute disponibilité. En effet, on n’agira pas de la même manière selon que l’on doit sécuriser un cluster Exchange ou donner le maximum de proximité – et donc de performances – à une base de données et son serveur applicatif.

Pour définir une règle sur un cluster DRS, il suffit de cliquer droit sur le cluster et sélectionner Edit Settings…

La fenêtre qui apparaît propose ensuite de régler les paramètres du cluster, que ce soit au niveau de VMware HA ou de VMware DRS. Ici, on s’astreindra à sélectionner le menu Rules et à cliquer sur le bouton Add… pour ajouter une nouvelle règle.

Après avoir donné un nom à la nouvelle règle, il suffit juste de sélectionner des machines virtuelles du cluster (toujours via un bouton Add…) et de sélectionner le type de règle qui nous intéresse :

• Separate Virtual Machines : impose aux machines virtuelles sélectionnées de s’exécuter sur des hôtes distincts
• Keep Virtual Machines Together : impose aux machines virtuelles sélectionnées de rester sur le même hôte ESX

Sachez également qu’une règle d’anti-affinité n’autorise que deux machines virtuelles à la fois. C’est dommage mais c’est ainsi pour le moment…

Une fois vos modifications effectuées, vous les retrouverez dans le menu Rule. En décochant la case, vous pourrez à tout moment désactiver cette règle sans la détruire.

Le bouton Details vous permettra d’obtenir un résumé de votre règle et déterminer si d’autres règles rentrent en conflit avec votre nouvelle règle.

Le vCenter indiquera enfin par une tâche récente que la reconfiguration du cluster a bien été prise en compte.

Bien que les règles d’affinité soient très facilement compréhensibles, n’oubliez jamais que le niveau d’automation de votre cluster DRS agira également sur vos réglages. Si vous optez pour une automation Manual ou Partially automated, votre cluster ne prendra pas de décision à votre place. En ce sens, il ne pourra qu’établir des recommandations suivant vos règles.

Par exemple, si vous sélectionnez trois machines qui doivent rester ensemble et qu’une de ces trois machines se trouve sur un autre hôte ESX, vous devrez manuellement appliquer la recommandation.

Dans l’onglet DRS de votre cluster, vous aurez peut-être remarqué qu’il existe trois vues : Recommandations, Faults et History. La première vous permet de visualiser et de valider les recommandations le cas échéant. La deuxième vous permet de rapidement déterminer les problèmes sur vos règles. Le vue History permet quant à elle de retracer l’évolution des opérations.

Changez votre niveau d’automation à Fully automated si vous voulez que vos règles s’exécutent immédiatement, et ce sans intervention supplémentaire.

En outre, utiliser le cmdlet Powershell Get-DrsRule, vous permettra également connaître à tout moment le détail des règles existantes (activées ou pas) qui s’appliquent sur un cluster donné (notez l’astérisque qui sert de wildcard…).

[vSphere PowerCLI] C:> Get-DrsRule -Name "*" -Cluster "Cluster Prod"

Name            Enabled KeepTogether VMIDs
----            ------- ------------ -----
Serveur web     True    True         {VirtualMachine-vm-789, VirtualMachine-vm-...

Créer un connecteur SMTP pour BPOS avec Microsoft Exchange Server 2003

La création de connecteurs SMTP a pour vocation de permettre à votre serveur Exchange de remettre des messages et d’en recevoir à partir de domaines externes. Imaginons par exemple que vous utilisiez un relais de messagerie antispam/antivirus tel que Postini, MessageLabs ou BPOS (Microsoft Business Productivity Online Suite), vous aurez besoin de les renseigner individuellement comme connecteur SMTP sur votre serveur Exchange. Si l’opération est basique, vous aurez compris qu’elle n’en est pas pour autant sans conséquence sur les flux de messagerie.

Pour illustrer l’exemple, nous allons donc créer un connecteur SMTP pour la solution Microsoft BPOS.

Dans votre Gestionnaire système Exchange, rendez-vous dans le dossier Messagerie (Exchange) > Groupes d’administration > Groupes de routage > Premier groupe de routage > Connecteurs, cliquez-droit et sélectionnez Nouveau > Connecteur SMTP…

Donnez ensuite un nom au connecteur et validez. Votre nouveau connecteur apparaît désormais avec les autres.

Editez le connecteur (clic droit > Propriétés) et dans l’onglet Général, sélectionnez l’option Transférer tous les courriers via ce connecter vers les hôtes actifs suivants puis entrez le nom de domaine du serveur distant communiqué par Microsoft. Ajoutez ensuite votre serveur Exchange tête de pont local qui fera office de serveur virtuel SMTP par défaut. Pensez à sécuriser ce serveur dans votre firewall car il aura un accès direct sur internet, certes restreint, mais un accès quand même. Sachez en outre que Microsoft impose le SMTP sécurisé via TLS pour justement sécuriser le plus possible les échanges.

Autre onglet à configurer, l’Espace d’adressage servira à renseigner votre sous-domaine SMTP personnalisé <moncompte>.emea.microsoftonline.com chez Microsoft. En clair, quand bien même vous communiqueriez avec l’adresse john.doe@mondomaine.com, vous existeriez également chez Microsoft BPOS en john.doe@moncompte.emea.microsoftonline.com

Les autres onglets n’ont pas vocation à être modifié pour une utilisation standard. A présent, tentez une connexion SMTP aux serveurs BPOS avec votre serveur Exchange tête de pont et continuez vos opérations de configuration. Du côté du connecteur SMTP en tous cas, les opérations sont terminées…

Régler les problèmes de freeze de Windows Server 2008 R2 sous VMware vSphere 4

Ceux d’entre vous qui déploient Windows Server 2008 R2 en environnement VMware vSphere 4 ont peut être eu la désagréable surprise de voir leur OS figé sans raison apparente. Dans ce cas, aucune autre alternative que d’éteindre en force le serveur. En cause, une incompatibilité graphique provoquée par un pilote SVGA après l’installation des VMware Tools relatée dans le KB VMware 1011709.

Si la solution – radicale – préconisée par l’éditeur est de passer votre hyperviseur en VMware vSphere 4 U1, vous n’avez peut-être pas de votre côté la possibilité d’observer tant de souplesse. Aussi, il vous faut une alternative.

Vous avez déjà installé les VMware Tools

Rendez-vous dans le Gestionnaire de périphériques, dépliez le dossier Cartes graphiques et repérez le driver incriminé VMware SVGA II.

A présent, cliquez droit > Désinstaller puis cochez Supprimer le pilote pour ce périphérique dans la fenêtre de confirmation qui apparaît.

Autrement, vous pouvez restaurer le pilote de carte précédent en passant par l’onglet Pilote de votre carte. Pour cela, passez par un clic droit sur le Bureau > Résolution d’écran > Paramètres avancés > bouton Propriétés

Après un redémarrage nécessaire pour prendre en compte les modifications, votre carte reprendra le driver graphique générique qui, à défaut d’être performant, ne vous fera pas planter le serveur.

Vous n’avez pas encore installé les VMware Tools

Lorsque vous lancerez les opérations d’installation, sélectionnez le type Personnalisé.

Ensuite, dans le menu Pilotes de périphériques VMware, désélectionnez simplement Pilote SVGA.