Maintenir une ferme SharePoint On-Premise résiliente repose sur une brique d'architecture critique : la répartition de charge (Load Balancing). Lorsque vous disposez de plusieurs serveurs Web Front-End (WFE), la manière dont vous distribuez le trafic utilisateur dicte non seulement la fluidité de l'expérience globale, mais aussi la capacité de votre infrastructure à absorber les pannes matérielles ou logicielles.
Deux approches s'opposent radicalement dans le monde de la production : l'utilisation d'un contrôleur de livraison d'applications (ADC) comme le F5 BIG-IP (LTM), et la méthode historique du DNS Round Robin.
Voici une analyse technique approfondie de ces mécanismes, de leurs limites et des configurations indispensables sous SharePoint.
1. F5 BIG-IP LTM : Le Load Balancing intelligent de couche 7
Contrairement aux solutions de répartition purement réseau (comme le NLB Windows classique ou le routage de niveau 4), le F5 BIG-IP agit en tant que reverse-proxy de niveau 7 (couche Application). Il est capable d'analyser et de comprendre les spécificités du protocole HTTP et du trafic SharePoint.
Mécanismes clés pour SharePoint :
-
Virtual IP (VIP) & Pools : Le F5 expose une adresse IP virtuelle unique aux utilisateurs. En arrière-plan, un pool contient vos serveurs WFE (membres du pool).
-
Health Monitors (Vérification de santé active) : C'est le point fort du système. Le F5 ne se contente pas d'envoyer un ping au serveur. Il interroge en temps réel des pages spécifiques de SharePoint, idéalement le point de terminaison natif dédié à la santé du système :
/_layouts/15/healthscore.aspx. Si le serveur renvoie un code d'erreur (HTTP 5xx) ou si le score de santé se dégrade, le F5 isole immédiatement le serveur défaillant du trafic. -
Méthode de répartition "Least Connections" : Pour SharePoint, l'algorithme Least Connections est fortement recommandé. Il dirige dynamiquement le nouvel utilisateur vers le WFE qui gère le moins de connexions actives à l'instant T, assurant une distribution parfaite de la charge, contrairement au modèle Round Robin qui distribue aveuglément de manière séquentielle.
Persistance et Déchargement SSL (SSL Offloading)
SharePoint est une application d'entreprise complexe qui nécessite souvent une persistance de session (Sticky Sessions). Si un utilisateur change de serveur WFE au milieu de la validation d'un formulaire ou d'un flux d'authentification, la session peut se rompre. Le F5 résout ce problème via la Cookie Persistence : il injecte un cookie HTTP chiffré dans la réponse du client pour s'assurer que toutes les requêtes futures de ce même utilisateur soient routées vers le même WFE.
Un autre avantage majeur est le SSL Offloading. Le certificat SSL/TLS est hébergé directement sur le boîtier F5. Le F5 chiffre/déchiffre le trafic côté client, puis communique en HTTP clair (port 80) avec les serveurs SharePoint en interne. Cela libère des cycles CPU précieux sur vos serveurs SharePoint, améliorant le temps de réponse des pages.
2. Le DNS Round Robin : La simplicité aveugle
Le DNS Load Balancing (ou Round Robin) consiste à associer plusieurs enregistrements de type "A" au même nom d'hôte (ex: sharepoint.entreprise.local).
-
Enregistrement 1 :
sharepoint.entreprise.local->10.0.0.1(WFE 1) -
Enregistrement 2 :
sharepoint.entreprise.local->10.0.0.2(WFE 2)
À chaque requête DNS, le serveur Windows DNS permute l'ordre des adresses IP retournées au client (mécanisme de tourniquet).
Pourquoi cette méthode montre ses limites avec SharePoint :
Bien que gratuite et simple à mettre en œuvre, cette technique comporte des risques majeurs pour une application de production :
-
Absence de détection des pannes : Si le service IIS du WFE 1 plante ou si le serveur subit un écran bleu, le serveur DNS continuera de distribuer son adresse IP à 50 % des utilisateurs. Ces derniers feront face à une erreur "Page non trouvée" (HTTP 504).
-
Effet de cache DNS : Les navigateurs web et les systèmes d'exploitation conservent l'adresse IP en cache pendant la durée du TTL (Time To Live). Si un serveur tombe, l'utilisateur reste bloqué sur la mauvaise adresse IP jusqu'à l'expiration ou le vidage manuel de son cache.
-
Rupture de session : Le DNS ne gère pas la persistance. L'utilisateur peut être redirigé d'un serveur à l'autre de manière imprévisible, provoquant des déconnexions intempestives.
3. Scripts et Configurations
Script 1 : Automatiser la configuration des Alternate Access Mappings (AAM) pour le SSL Offloading
Lorsque vous configurez le SSL Offloading sur le F5, l'utilisateur accède au site en https://sharepoint.entreprise.local, mais le F5 interroge SharePoint en http://sharepoint.entreprise.local. Vous devez impérativement configurer les Mappages d'Accès de Rechange (AAM) dans SharePoint pour que l'application génère correctement les liens internes en HTTPS.
Voici le script PowerShell à exécuter sur la ferme SharePoint :
# Prérequis : SharePoint Management Shell exécuté en tant qu'administrateur de la ferme
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$WebAppUrl = "http://sharepoint.entreprise.local" # URL interne (HTTP)
$PublicUrl = "https://sharepoint.entreprise.local" # URL publique exposée par le F5 (HTTPS)
Write-Host "Configuration de la zone d'accès Internet pour le SSL Offloading..." -ForegroundColor Cyan
# Récupération de la Web Application
$WebApp = Get-SPWebApplication -Identity $WebAppUrl
if ($WebApp) {
# Ajout du mappage pour la zone Internet (Exposée publiquement via le F5)
New-SPAlternateUrl -WebApplication $WebApp -Url $PublicUrl -Zone Internet -ErrorAction SilentlyContinue
Write-Host "Mappage d'accès de rechange configuré avec succès." -ForegroundColor Green
Write-Host "URL Interne : $WebAppUrl"
Write-Host "URL Publique F5 : $PublicUrl (Zone: Internet)"
} else {
Write-Error "Impossible de trouver la Web Application spécifiée."
}
Script 2 : Tester le Health Score SharePoint depuis le Load Balancer
Pour valider que le point de terminaison de santé répond correctement avant de configurer le moniteur sur le F5, vous pouvez exécuter cette requête depuis votre réseau pour analyser les en-têtes HTTP retournés par SharePoint :
# Test de la page de santé SharePoint
$WfeUrl = "http://10.0.0.1/_layouts/15/healthscore.aspx"
try {
$Response = Invoke-WebRequest -Uri $WfeUrl -Method Get -TimeoutSec 5 -ErrorAction Stop
# Extraction du score de santé SharePoint (0 = Parfait, 10 = Critique)
$HealthScore = $Response.Headers["X-SharePointHealthScore"]
Write-Host "Statut HTTP du serveur : $($Response.StatusCode)" -ForegroundColor Green
if ($HealthScore) {
Write-Host "SharePoint Health Score actuel : $HealthScore (0 = Excellent, 10 = Surchargé)" -ForegroundColor Cyan
} else {
Write-Warning "Le serveur a répondu mais l'en-tête X-SharePointHealthScore est absent."
}
}
catch {
Write-Error "Le serveur WFE ne répond pas ou le service IIS est arrêté. Erreur : $_"
}
4. Références officielles Microsoft
Pour valider vos architectures de haute disponibilité et l'intégration d'équipements tiers, appuyez-vous sur les documentations officielles de l'éditeur :
Conclusion
Le DNS Round Robin peut suffire pour des environnements de test ou des maquettes non critiques. En revanche, pour une infrastructure SharePoint de production, l’usage d'un Load Balancer intelligent comme le F5 BIG-IP LTM est indispensable. Il apporte la granularité nécessaire pour absorber les pannes sans interruption de service perçue par les utilisateurs, tout en soulageant la charge de calcul de vos serveurs applicatifs grâce au déchargement SSL.
