Ce post n’est pas là pour débattre de l’utilité de la virtualisation, c’est en vogue, et ceux qui industrialisent l’hébergement virtualisé en tirent de nombreux bénéfices:
- Rationalisation du matériel, idéalement en répartissant les machines selon la charge CPU générée, ou la RAM, ou la criticité.
- Cluster “physique” indépendant de l’OS pour peu que le réseau et le SAN soient de la partie (bascule automatique de votre machine virtuelle, VM, vers un autre hôte en cas de problème).
- Evolutivité par simple clic (RAM, réseau, etc.).
- plein d’autres choses.
Alors pourquoi virtualiser SharePoint ? Question d’affinités, et de retour d’expérience. Pour ma part, après un an en hébergement Simple Farm physique, j’ai préféré offrir de la redondance de services amenée par la Middle Farm (Web, SQL), et virtualiser pour ne pas “gâcher” des machines physiques. En effet, la charge de mes clients ne justifie pas aujourd’hui de dédier du matériel. Mais la redondance est quand même agréable, quiconque vit un disaster recovery comprendra qu’il vaut mieux prendre son temps pour remonter un nœud web ou SQL, que de réinstaller une ferme en catastrophe. Surtout si vous hébergez beaucoup de customisations.
Le matériel utilisé chez nous est de type châssis de lames, aux performances correctes, “gavées” de RAM: 32Go. J’utilise 2 lames pour ma ferme SharePoint, j’ai donc réparti les VM de cette façon:
- Lame 1
- Web Front-end 1, 8Go
- Index/Excel, 16Go
- SQL 2, 8Go
- Lame 2
- Web Front-end 2, 8Go
- SQL 1, 12Go
- Web Front-end+Index/Excel pré-production, 8Go
- Machine vide usage futur, 4Go
J’ai bloqué la répartition automatique de VMWare (en fonction de la charge, de la RAM…) pour que mes VM restent bien réparties de chaque côté. Il serait fâcheux que mes 2 WFE production (en NLB) se retrouvent sur la même lame physique en cas de crash, non ? ;-)
Je n’aime pas virtualiser SQL, je préfère qu’il s’appuie sur des moyens d’accès dédiés à ses données. Vieille réticence peut-être obsolète aujourd’hui, en tout cas j’avais la place et beaucoup de RAM, j’ai donc franchi le pas.
Comme vous pouvez le voir, la répartition de charge CPU est relativement équitable pour la production, en temps normal:
- Lame 1: Web, Index/Excel
- Lame 2: Web, SQL
Maintenant passons au NLB, plus précisément, le Network Load Balancing de Windows 2008 Server x64 SP1.
Déjà, rappelons que l’Unicast fonctionne en mode “je noie le switch”. C’est à dire que chaque carte réseau va porter une adresse mac unicast de type 02-xx-xx-xx-xx-xx (les xx correspondent aux octets de la mac privée de la carte). Or cela signifie que le switch va devoir diriger le même flux sur 2 ports physiques, pour la plupart des switchs cela signifie “puisque j’ai des doublons, je passe en hub”, d’où la noyade. Il vaut mieux donc dédier un scope réseau pour ce type de NLB.
C’est le matériel recommandé en Unicast. Forcément, vu que la carte qui portera le flux commun sera dédiée au NLB, et ne pourra faire rien d’autre.
Comme rappelé en mode “2 cartes”, le mode “1 carte” empêche tout accès direct à la machine. Profitons donc de la virtualisation et de ses cartes réseau à 0 euros :-) .
Le multicast, c’est pareil mais différent. Là, la mac address est de type 03-xx-xx-xx-xx-xx. Cette mac est supposée être stockée dans la table ARP du routeur le plus proche. Or chez nous les services réseau n’ont pas souhaité activer cette possibilité bien que le matériel soit compatible (c’est un point à vérifier).
Il reste donc la solution d’entrer une résolution ARP statique, mais là encore, si votre réseau est complexe (double chaîne avec failover par exemple), créer ce type de règle spécifique est la meilleure façon de l’oublier au fil du temps, et de casser le NLB.
Je n’ai pas étudié ce mode, j’avoue que je ne l’ai jamais vu en pratique.
- Implémentation dans Windows 2008
Je ne vais pas m’étendre trop sur le sujet de l’installation et de la configuration, il y a sur le net suffisamment de ressources sur ce sujet. Sachez que la console n’a pas changé par rapport à Windows 2003.
Par contre, le NLB virtualisé a fait couler de l’encre sur la KB Microsoft, notamment en environnement Hyper-V, où il faut passer plein de correctifs (si si). Certains s’appliquent aussi à VMWare, bien qu’il ne soit pas forcément mentionné.
Notamment celui-ci: KB953828 “Windows Server 2008 Hyper-V virtual machines generate a Stop error when NLB is configured or when the NLB cluster does not converge as expected”.
Depuis le SP2 de Windows 2008, je ne sais pas où en est la situation, mais je vous recommande de bien tester avant de passer en production, en réalisant de multiples scenarios de perte de machine, de lien réseau, surcharge trafic etc.
En fait, VMWare n’a rien de tellement spécifique, mais sa configuration réseau peut provoquer des problèmes au NLB Windows si l’on n’y prête pas d’attention. Heureusement, la KB VMWare est très bien documentée sur ces points: Implementing Microsoft Network Load Balancing in a virtualized environment (PDF, ~500ko)..
En résumé, il faut sur la carte virtuelle cluster de chaque machine virtuelle hébergeant le NLB, passer l’option “notify switches” à “no”. J’attend encore l’explication technique détaillée, mais il semblerait que cette option provoque l’envoi de la mac privée de la carte, alors même que le NLB s’efforce de la masquer en se faisant passer pour la mac Unicast (02-xx…).
Voici ce que dit l’aide de VMWare au sujet du paramètre notify switches:
Select Yes or No to notify switches in the case of failover.
If you select Yes, whenever a virtual NIC is connected to the vSwitch or whenever that virtual NIC’s traffic is routed over a different physical NIC in the team because of a failover event, a notification is sent over the network to update the lookup tables on the physical switches. In almost all cases, this is desirable for the lowest latency of failover occurrences and migrations with VMotion.
Do not use this option when the virtual machines using the port group are using Microsoft Network Load Balancing in unicast mode. No such issue exists with NLB running in multicast mode.
Rien de particulier à faire si ce n’est la vigilance sur le matériel réseau en amont de vos machines (cf. le rappel des généralités NLB plus haut).
Et le troubleshooting dans tout ça ?
Voici pour l’instant les deux cas que j’ai eu à traiter:
- En mode unicast à 2 cartes, le cluster NLB converge, mais seule 1 machine reçoit le trafic.
Contexte: 1 VLAN dédié pour le NLB, VLAN public pour l’autre carte réseau.
En fait, lors de la configuration des machines virtuelles, le responsable s’est trompé de réseau, et a présenté à la carte NLB le même VLAN que la carte publique. Ce qui a permis au NLB de converger, mais qui empêchait à la carte de s’identifier auprès du switch en amont, et donc de recevoir du trafic.
- Tout les soirs à la même heure +/- 10mn, un nœud sort du NLB pour y revenir 10 secondes plus tard.
Sauf que le dernier soir, ça n’a pas re-convergé :-(
Solution: une solution de snapshots était mise en place au niveau de la baie de stockage SAN. Cette solution implique un très léger freeze de la machine virtuelle, qui apparemment désynchronise le heartbeat NLB. En temps normal, la convergence a lieu à nouveau, quelques secondes plus tard. Le soir de l’incident, la convergence NLB web n’a pas eu lieu, et le cluster MSCS SQL a basculé également. Problème réseau en simultané ?
Nous avons depuis désactivé les snapshots (activés sans mon consentement), étant déjà équipés d’une solution de backup 1:1, et de la sauvegarde quotidienne des données SharePoint.
