Le port 3343 Dans Windows Server 2012 et 2012 R2 – Les communications Intra-Clusters expliquées

 

Bonjour à tous

Aujourd’hui nous allons étudier le fonctionnement des communications réseau au sein d’un cluster, ce qui devrait vous permettre de trouver plus facilement la meilleure configuration réseau pour vos clusters en fonction de vos contraintes d’infrastructure.

Failover Cluster Virtual Adapter (Netft)

Netft est un adaptateur réseau virtuel qui établit des connexions TCP sur toutes les interfaces réseau du cluster. Il apparaît via ipconfig /all, avec une adresse APIPA

NetFT permet au cluster d'utiliser tous les "cluster networks" disponibles pour ses communications

• Priorités sur les routes, et routage entre différents sous réseaux
• Bascule sur un autre chemin réseau en cas de perte d'un chemin
• Compatible avec le teaming de cartes

Si les communications clusters ne sont plus possibles sur un réseau, NetFT bascule sur un autre réseau (en utilisant les priorités en place).
NetFT reçoit une adresse MAC créée automatiquement, avec détection et résolution de conflits automatique depuis Windows Server 2012. Aucune configuration manuelle n'est nécessaire.

Les communications cluster passent par le port 3343 :

• ClusSvc communique avec NetFT (via IP et NDIS) sur le port TCP 3343
• NetFT communique avec le réseau externe (via IP, NDIS et NIC) sur le port UDP 3343

NetFT utilise les optimisations réseau telles que RSS (réduction de la charge CPU pour le traffic entrant) et SMB multi-channel (utilisation de plusieurs réseaux en parallèle pour transporter un même flux) depuis Windows Server 2012. Il supporte IPv4 et IPv6, mais IPv6 est utilisé en premier si disponible, c’est pourquoi, si IPv6 est activé sur les serveurs, il ne faut surtout pas qu’un firewall bloque les trames IPv6.
Le cluster crée un maillage de toutes les interfaces réseaux de tous les hôtes (il n'y a plus de réseau dédié au "heartbeat").
Le fonctionnement de ce maillage est configurable via la commande PowerShell :
(get-cluster).PlumbAllCrossSubnetRoutes = X

Interactions avec Network Topology Manager

Network topology manager établi pour Netft les routes à prendre en compte
Netft indique à NTM les changements d'états des routes (déconnexions)
NTM indique à Netft la nouvelle route à utiliser
NTM indique sur quelles routes les ressources IP du cluster sont mises en ligne

Netft Virtual Adapter Performance filter

Le NetFT Virtual Adapter Performance Filter est ajouté aux cartes réseaux physiques des nœuds de cluster.
Il améliore les performances réseau du cluster en contournant la pile UDP / IP pour délivrer le trafic du port 3343 de la carte réseau directement à Netft, ceci incluant les redirections CSV.
Il doit être désactivé en cas de cluster de VMs, sinon les heartbeats des nœuds virtualisés seront perdus.

Configuration des « heartbeats »

Chaque hôte envoi un “heartbeat” à chacun des autres hôtes pour détecter ceux indisponibles. Quand un serveur ne répond plus, les opérations de récupération du cluster sont lancées (par exemple la bascule des ressources hébergées par cet hôte).
Les requêtes se font en unicast et en mode requête - réponse pour la fiabilité et la sécurité : ce ne sont pas de simples pings.
Une interface est considérée déconnectée quand le nombre de heartbeats perdus dépasse le seuil configuré.
Le nœud est considéré hors ligne par le cluster quand toutes ses interfaces sont considérées comme déconnectées.

Les paramètres sont les suivants :

Propriété	Défaut	Maximum
SameSubnetDelay	1 seconde	2 secondes
SameSubnetThreshold	5 heartbeats (10 si Hyper-V 2012 R2)	120 heartbeats
CrossSubnetDelay	1 seconde	4 secondes
CrossSubnetThreshold	5 heartbeats (20 si Hyper-V 2012 R2)	120 heartbeats

La configuration se fait par Powershell, par exemple :
(get-cluster).SameSubnetDelay = 2 enverra un heartbeat toutes les 2 secondes au lieu de toutes les secondes.

Pour compenser une mauvaise qualité de réseau, il est recommandé d’augmenter le seuil et non le délai.
Exemple : Pour avoir une durée de 10 secondes, conserver le délais à 1s et monter le seuil à 10 au lieu de laisser le seuil à 5 et monter le délais à 2 secondes.
Ces valeurs ne sont modifiables qu’une fois le cluster créé.
Si les latences réseaux perturbent la création du cluster, il est possible de modifier une clé de registre pour rendre les tests exécutés à la création du cluster plus tolérants :

• La modification est à faire sur chaque noeud
• Dans la clé HKLM\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters
• Créer une valeur DWORD « SetHeartbeatThresholdOnClusterCreate »
• La configurer à 10 permet de perdre 10 heartbeats avant de considérer le nœud injoignable
• Cette valeur est prise en charge dans Windows Server 2012 et 2012 R2

Augmenter le délai avant de considérer un réseau comme déconnecté permet de compenser un réseau à forte latence mais ne résout pas le problème : cela ne fait que le masquer.

3 Types de communications Cluster

On peut identifier 3 types de communications intra-cluster différentes

Heartbeats

Usage :

• Monitore l'état des interfaces réseau
• Envoyés sur tous les réseaux clusters autorisés

Pré requis :

• Bande passante très faible (134bytes / nœud / secondes)
• Sensible à la latence (si les heartbeats passent par une carte saturée, ils peuvent être perdus, et le nœud éjecté du cluster)

Il est inutile d’allouer de la bande passante à ces communications, mais la QOS doit protéger ces trames.

Synchronisation Intra-cluster

Usage :

• Mises à jour de la database cluster, synchronisation de la configuration
• Utilise une seule carte réseau à un instant t

Pré requis :

• Le trafic dépend de l'usage du cluster : faible sur un cluster de fichiers ou Hyper-V, plus important sur un cluster SQL ou exchange
• Sensible à la latence : la latence va ralentir les changements d'état du cluster, par exemple les bascules

Il est inutile d’allouer beaucoup de bande passante à ces communications, mais la QOS doit protéger ces trames.

CSV I/Os

Usage :

• Synchronisation d’I/Os (Mises à jour de metadatas)
• Ensemble des I/O en mode redirigé
• Même réseau que les communications intra cluster
• Le SMB multi-channel peut équilibrer la charge sur plusieurs cartes

Pré requis :

Il y a 2 cas à prendre en compte :

Synchronisation d’I/Os :

• Léger et rare
• La latence va diminuer les performances I/O
• La QOS est le plus important

Redirection d’I/Os :

• Toutes les I/O sont forwardées via le réseau au nœud coordinateur
• Une bande passante importante est nécessaire pour limiter l'impact sur les performances

Utilisation du SMB multi channel par la redirection des I/O CSV

Utilisation de la QOS pour gérer la priorité et la bande passante des réseaux

Windows Server 2012 R2 intègre un profil QOS pour les communications cluster.
Pour donner une haute priorité et affecter au minimum 30% de la bande passante à ces communications (surtout utile pour les redirections d’I/O CSV), on utilisera la commande PowerShell suivantes :

• New-NetQosPolicy “Cluster Policy” -Cluster –Priority 6 –MinBandwidthWeightAction 30

Windows Server 2012 n’intègre pas le profil « -cluster », on va donc simplement appliquer la policy QOS au trafic utilisant le port 3343 :

• New-NetQosPolicy “Cluster Policy” -IPDstPort 3343 –Priority 6 –MinBandwidthWeightAction 30

On pourra compléter ces règles de QOS avec celles pour le SMB (utilisé par le CSV) et les live migrations avec les paramètres suivant par exemple:

• New-NetQosPolicy “Live Migration Policy” –LiveMigration –Priority 5 –MinBandwidthWeightAction 20
• New-NetQosPolicy “SMB Policy” -SMB –Priority 3 –MinBandwidthWeightAction 50

L’exemple ci-dessous convient spécialement si vous avez l’intention de dédier un teaming de 2x1Gb ou 2x10Gb pour l’administration du cluster.

Un autre article présentera plus de configurations possibles.

Gestion des rôles des Cluster Network

Un Cluster network peut avoir une de ces 3 configurations :

Valeur	Description
0 – Désactivé	Aucune communication cluster envoyées sur ce réseau
1 – Privé	Communications intra cluster et redirections CSV envoyées sur ce réseau
3 - Public	Ce réseau peut être utilisé par le cluster comme un réseau privé, mais il sera également possible de créer des ressources clusters de type adresses IP sur ce réseau.

Par défaut, une configuration automatique est proposée selon les règles ci-dessous :

• Si le réseau est utilisé par un Initiateur iSCSI, il sera désactivé
• Si un réseau n’a pas de passerelle par défaut, il sera considéré comme un réseau privé
• Si un réseau a une passerelle par défaut, il sera considéré comme un réseau public

La configuration peut se faire graphiquement :

Ou par Powershell via la commande (Get-ClusterNetwork « Cluster Network 1 »).role = X

Gestion de la priorité entre les différents réseaux

Lors de la configuration automatique des réseaux du cluster, une métrique est affectée à chaque réseau utilisable (ce qui exclut donc les réseaux dont le rôle est à 0).
Les réseaux Privés ont une métrique partant de 40000 et pouvant descendre jusqu’à 0, les réseaux Publics ont une métrique partant de 80000 et descendant jusqu’à 40001.
Plus la métrique est basse et plus le réseau sera prioritaire, le cluster utilisera donc en premier ses réseaux privés pour ses communications et pour la redirection CSV.

La règle de calcul est la suivant :
(40000 si Rôle 1 ou 80000 si Rôle 3) – (19200 si compatible RDMA) – (9600 si compatible RSS [les bonus RSS et RDMA ne sont pas cumulatifs]) – ((16 (utilisé pour constituer les groups de load balancing NetFT) * (10 si réseau 10Gb/s, 1 si réseau 1Gb/s, 0 si bande passante < 1Gb/s) = Valeur de la métrique

(Ouf !!)

Exemple :

- Prenons 2 réseaux sans passerelle, carte 10Gb/s, compatible RDMA :

• Pour le 1^er : 40000 – 19200 – (16*10) = 20640
• Pour le 2^ème : 39999 – 19200 – (16*10) = 20639

- Un 3eme réseau sans passerelle est disponible, une carte 1Gb/s ni compatible RDMA ni RSS :

• 39998 – (16*1) = 39982

- Enfin, un réseau avec passerelle, carte 1GB/s, non compatible RDMA ou RSS :

• 80000-(16*1) = 79984

SMB multi-channel peut utilise en parallèle tous les réseaux ayant la même bande passante et offrant les mêmes fonctionnalités.

Contrairement à 2008R2, dans le fonctionnement normal du cluster, il est inutile de toucher à ces métriques :

• Les réseaux utilisés par le cluster se choisissent via les rôles attribués
• Les réseaux de live migration sont configurés dans le cluster (en powershell ou via l’interface graphique)
• SMB multi-channel cherchera la meilleure solution parmi les réseaux privés pour les I/Os CSV
• Seulement si le SMB multi-channel est désactivé, NetFT utilisera les métriques pour les I/Os CSV
• SMB Multi-channel peut-être désactivé via la commande “Set-SMBClientConfiguration –EnableMultichannel $False” à exécuter sur chacun des nœuds.

Attention : Si vous créez des interfaces virtuelles sur un teaming de cartes réseaux, ces interfaces sont présentées avec une bande passante de 10Gb/s, quelle que soit la bande passante réelle des cartes utilisées et du teaming créé. Ces cartes seront donc prioritaires pour SMB multi-channel par rapport à des cartes 1Gb/s. Ce point est à prendre en compte dans le design de la configuration réseau du cluster.

Jumbo Frames

Si l’ensemble de la chaine réseau les supportent, les jumbo frames améliorent les performances des Live Migrations et ne font pas de mal sur les I/Os CSV, même si le gain n’est pas si flagrant.

Les jumbo frames sont à configurer dans les paramètres avancées des cartes réseau, la méthode va donc varier selon le constructeur de la carte, le paramètre peut s’appeler MTU, Jumbo packets ou différemment. Par défaut ce paramètre est à 1500, et il peut être augmenté à 9000 ou 9014 selon les constructeurs.

Il est très important de vérifier que les switches physiques supportent ce paramètre, pour cela, réaliser un ping entre 2 hôtes ayant un MTU de 9000 (ou 9014) via la commande : ping X.X.X.X –f –l 8000. Ceci va envoyer un ping avec une trame de 8K qui ne passera que si les jumbo frames sont activées partout.

Pour être utilisés par une machine virtuelle, les Jumbo frames doivent être activées dans les cartes réseau concernées de la VM, il n’y a rien à configurer sur le Switch virtuel.

Conclusion

Nous avons parcouru le fonctionnement et la configuration avancée des réseaux clusters.

Comme nous l’avons vu, en usage régulier, le plus important est de bien gérer la priorité sur le port 3343 pour s’assurer que les heartbeats et les ordres de mises à jour de la configuration du cluster soient correctement diffusés. De plus, SMB multi-channel va aider à optimiser la bande passante allouée aux I/Os CSV.

Tous ces mécanismes imposent de bien penser la répartition des cartes réseaux disponibles dès le début pour offrir la meilleure redondance et les meilleures performances possibles même en fonctionnement dégradé.

Arnaud Torres