carte Tcp Offload Engine (TOE) ISCSI
Le design du LAN
Par nature, le réseau Ethernet est un réseau de type broadcast avec gestion des collisions. Au début des années 90, la multiplication des périphériques par simple interconnexion des segments réseaux générèrent des congestions qu’il fallut éradiquer. A l’époque, seule la mise en place de routeurs permettait de séparer les domaines de broadcast mais avec un temps de latence plus important lié au traitement de niveau protocolaire. L’avènement du commutateur en mode cut through permis d’éradiquer le problème en ne lisant que le début des trames Ethernet afin d’extraire uniquement les adresses IP, les associer aux ports physiques concernés et ne mettre en relation lors de la communication que les ports source/destination concernés. Ainsi on segmentait avec une latence amoindrie.
La fin des années 90 vit de nouveau une prolifération importante des périphériques réseaux et de nouveau une saturation liée au traitement par la CPU des commutateurs réseaux et une nouvelle augmentation de la latence. Le concept du VLAN, d’abord local au commutateur, puis commun à l’ensemble des équipements du réseau autorisa de nouveau la séparation en domaines de brodacast disctincts, permettant ainsi de maîtriser le nombre d’équipements sur un même segment Ethernet et donc de diminuer le traitement CPU associé sur chaque commutateur. A cette époque, certains commutateurs dit de niveau 3 se virent doté d’une fonctionnalité de routage intégrée évitant ainsi les allers et retours de trames vers un routeur au centre du réseau. Ces pratiques ont toujours cours aujourd’hui.
Ainsi, lors de l’implémentation d’un stockage Ethernet au sein d’un réseau, il est judicieux de profiter des VLANs certes pour séparer les trafics dans un but de sécurité mais aussi pour diminuer les temps de réponse en limitant le nombre de machines susceptibles de l’utiliser. De même, en cas d’utilisation du protocole ISCSI, il est essentiel de dédier un VLAN spécifique à ce type de flux très bavard.
CAT6513VSS#sh run int giga 4/19
Current configuration : 115 bytes
interface GigabitEthernet4/19
description *** Acces vlan ISCSI ***
switchport
switchport access vlan 218
CAT6513VSS#sh vlan
../..
218 ISCSI active Gi4/19, Gi5/9, Gi5/11, Gi5/12
Maîtriser Spanning Tree
Le réseau Ethernet à un fonctionnement en mode hiérarchique qui s’appuie sur Spanning tree (STP), protocole permettant d’établir une topologie du réseau sans boucle au travers de trames spéciales appelées BPDUs (Bridge Protocol data Units). Grâce à se mécanisme, un bridge (switch) est désigné root et connaît l’ensemble des chemins les plus courts depuis tous les équipements du réseau pour venir jusqu’à lui. Du point de vue design, il est préférable que le commutateur root soit le plus au ‘centre’ du réseau et que ce soit une machine puissante : il serait dommage que le spanning-tree root soit un commutateur bas de gamme Netgear alors que l’on dispose d’un catalyst high-end Cisco 6513VSS sur le réseau. Dans la mesure ou les commutateurs disposent de cette fonctionnalité, activer le protocol PVST+ (Per Vlan Spanning-Tree) afin de créer une instance spanning –tree par VLAN, accélérant ainsi la convergence du réseau notamment en cas de changement fréquent sur les VLANs.
CAT6513VSS#(config)Spanning-tree mode rapid-pvst
CAT6513VSS#sh spanning-tree
VLAN0218
Spanning tree enabled protocol ieee
Root ID Priority 32768
Address 0002.7d74.e400
Cost 4100
Port 900 (TenGigabitEthernet8/4)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0025.84d9.3680
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Te7/4 Desg FWD 4096 128.772 P2p
Te8/4 Root FWD 8128 128.900 P2p
Gi9/1 Desg FWD 4 128.1025 P2p
Gi9/2 Desg FWD 4 128.1026 P2p
Gi9/3 Desg FWD 4 128.1027 P2p
Gi9/5 Desg FWD 4 128.1029 P2p
Gi9/7 Desg FWD 4 128.1031 P2p
Gi10/1 Desg FWD 4 128.1153 P2p
Gi10/2 Desg FWD 4 128.1154 P2p
Gi10/4 Desg FWD 4 128.1156 P2p
Gi10/5 Desg FWD 4 128.1157 P2p
....
Utiliser les Jumbo Frames
CAT6513VSS#sh run int giga 9/6
Current configuration : 120 bytes
!
interface GigabitEthernet9/5
switchport
switchport mode trunk
flowcontrol send on
mtu 9216
end
Dans la console vSphere :
esxcfg-vswitch -m 9000 vSwitch[x]
esxcfg-vmknic –a –i 192.168.x.x –n 255.255.255.0 –m 9000 –p [Nom]
~ # esxcfg-vmknic -l
Interface Port Group/DVPort IP Family IP Address netmask Broadcast MAC Address MTU TSO MSS Enabled Type
vmk0 Management Network IPv4 10.X.X.X 255.255.255.0 10.X.X.255 b8:ac:6f:13:76:9d 9000 65535 true STATIC
vmk1 VMkernel IPv4 10.X.X.X 255.255.255.0 10.X.X.255 00:50:56:79:29:1e 9000 65535 true STATIC
vmk2 ISCSI-1 IPv4 192.168.X.X 255.255.255.0 192.168.X.255 00:50:56:75:25:33 9000 65535 true STATIC
A noter que sur des commutateurs workgroup Cisco, on utilisera la commande « system mtu jumbo 9000 » ou la commande globale "system jumbomtu 9000" sur le Catalyst 6000.
Si le VLAN permet de séparer les trafics, l’agrégation de liens permet de doper la bande passante. En même temps, le nombre de ports sur un NAS n’est pas extensible à l’infini et le nombre de VLAN sur un réseau peut être important. La norme 802.1q vise à faire passer sur un même lien l’ensemble des VLANs : on parle de VLAN tagging. En utilisant un simple lien 10 Gigabit Ethernet, on bénéficie à la fois d’une grande bande passante et d’un accès à l’ensemble des VLANs.
CAT6513VSS#sh run interface port-channel 1
Building configuration...
Current configuration : 81 bytes
!
interface Port-channel1
switchport
switchport trunk encapsulation dot1q
end
Mutualiser les liens est une autre méthode pour augmenter la bande passante. La norme 802 .3ad permet de faire de faire de l’agrégation de liens en réalisant du load balancing sur les adresses MACs source et destination, les adresses IP source et destination ou selon la méthode l’un puis l’autre communément appelée ‘Round-Robin’. Dans tous les cas, il est nécessaire de mettre en adéquation à la fois la configuration des ports du NAS et celle du commutateur auquel il est connecté. La configuration peut-être statique ou dynamique en s’appuyant sur le standard Link Aggregation Control Protocol (LACP), cette dernière permettant accessoirement d’éviter aussi une perte du flux de données et supporte une connexion multi châssis (au travers de plusieurs commutateurs différents).
CAT6513VSS#sh run interface port-channel 1
Current configuration : 81 bytes
!
interface Port-channel1
switchport
switchport trunk encapsulation dot1q
end
…/…
CAT6513VSS#sh run int giga 9/7
Current configuration : 97 bytes
!
interface GigabitEthernet9/7
switchport
flowcontrol send off
channel-group 1 mode auto
end
Afin de prévenir toute interruption de service liée à un problème sur un commutateur réseau, il est recommandé de redonder les chemins réseaux. Le NAS devra être connecté à minima sur deux commutateurs réseaux disctincts voir sur deux cartes ligne différentes d’un même chassis réseau. Il ne faudra pas oublier dans vSphere de déclarer deux vMkernel disctincts rattachés à un même vSwitch et à deux vmnics elles-mêmes connectées aux deux commutateurs sus-cités afin de véhiculer les flux réseaux.
Utiliser les éventuelles capacités Tcp Offload Engine de vos cartes Ethernet ISCSI
~ # esxcli swiscsi vmnic list -d vmhba34
~ # esxcli swiscsi vmnic list -d vmhba35
~ # esxcfg-vmknic -l
Interface Port Group/DVPort IP Family IP Address netmask Broadcast MAC Address MTU TSO MSS Enabled Type
vmk0 Management Network IPv4 10.X.X.X 255.255.255.0 10.X.X.255 b8:ac:6f:13:76:9d 9000 65535 true STATIC
vmk1 VMkernel IPv4 10.X.X.X 255.255.255.0 10.X.X.255 00:50:56:79:29:1e 9000 65535 true STATIC
vmk2 ISCSI-1 IPv4 192.168.X.X 255.255.255.0 192.168.X.255 00:50:56:75:25:33 9000 65535 true STATIC
vmk3 ISCSI-2 IPv4 192.168.X.X 255.255.255.0 192.168.X.255 00:50:56:77:84:0d 9000 65535 true STATIC
~ # esxcli swiscsi nic add -n vmk2 -d vmhba34
~ # esxcli swiscsi nic add -n vmk3 -d vmhba35
~ # esxcli swiscsi vmnic list -d vmhba35
vmnic3
vmnic name: vmnic3
mac address: b8:ac:6f:13:76:a3
mac address settable: NO
maximum transfer rate: 1000
current transfer rate: 1000
maximum frame size: 9000
~ # esxcli swiscsi vmnic list -d vmhba34
vmnic2
vmnic name: vmnic2
mac address: b8:ac:6f:13:76:a1
mac address settable: NO
maximum transfer rate: 1000
current transfer rate: 1000
maximum frame size: 9000
Activer flow control
La fonction flow control permet prévenir une saturation réseau de la machine cible en pilotant le flot de données transmit par la source. Le bon compromis est d’activer le flow control à la fois sur le NAS et sur les switchs réseaux l’émission à « on » et la réception à « off »
CAT6513VSS#sh run int giga 9/6
Current configuration : 120 bytes
!
interface GigabitEthernet9/6
switchport
switchport mode trunk
flowcontrol send on
flowcontrol receive off
channel-group 1 mode auto
end
Profiter du Multipathing offert par ALUA
De manière générale, je recommande de créer des DATASTOREs avec une taille maximale de 500~600Go contenant au maximum 10 VM. On veillera à n’utiliser au maximum que 80% de la volumétrie, le restant étant dévolu à l’éventuel swap ou aux snapshots.
A l’inverse, Il n’est pas du tout recommandé de créer un DATASTORE éclaté sur plusieurs LUNs, car cela est source de contention d’I/Os sur le contrôleur et expose l’administrateur à un risque de perte accrue du fait de la multiplication des sources de pannes : un LUN perdu = tout le Datastore perdu.
Au passage, si on souhaite utiliser le boot from SAN pour les hosts ESX, il faut proscrire l’utilisation de datastores NFS car cela n’est pas supporté. En revanche, c’est possible via ISCSI.
A propos du Thin Provisionning
Lorsque l’on crée un volume, il est préférable de le provisionner en mode thick plutôt qu’en mode Thin. En effet, le mode thin va fragmenter le volume sur l’ensemble de l’aggrégat faisant ainsi baisser sa performance au fur et à mesure de son utilisation du fait de sa fragmentation. A l’inverse, on peut utiliser le mode thin au sein des VMs. De manière générale, lorsque l’on fait du Thin provisionning, on le fait soit au niveau volume, soit au niveau VM, jamais sur les deux.
La déduplication
Pour les RDM hautement volatiles, il est préférable d’éviter la déduplication du fait de l’inévitable réhydratation nécessaire à réaliser régulièrement sur les données du volume engendrant de fait une charge CPU importante. A l’inverse, un volume peu souvent utilisé est un bon candidat à cette fonctionnalité. Sur les stockages tels que les machines NetApp on peut recommander d’activer la fonction FAS data déduplication qui va permettre d’économiser drastiquement de l’espace disque lors du déploiement d’une VM depuis un Template. En utilisant cette fonctionnalité, l’intégralité des VMDKs ne sont pas copiés mais générés à partir d’un snapshot peu consommateur de disque.
L'auto-tiering
Pour les ceussent qui n'ont pas la chance de disposer comme moi d'un pool de même type de disque (SATA, SSD, FC ou SAS) déclinable en différents SLA (QOS Pillar), la grande mode du moment est de positionner plus ou moins dynamiquement (process d'optimisation lancé sous une heure pour un Equalogic à deux mois sur un Storwize v7000) les blocs de données les plus consultés sur les disques les plus rapides. En cas de grande volatilité des données, cela peut engendrer un certain engorgement du backend. Moralité, mettre en "data progression" ce qui ne bougera quasiment jamais : sauvegardes, archives, templates ...
La fonctionnalité Storage I/O Control (SIOC) pour le SAN introduite dans vSphere 4 permet de prioriser l’accès à certains volumes lors de périodes de contention en fixant la latence attendue. Par défaut la valeur est fixée à 30ms.
1 commentaire:
Vraiment un super article
Enregistrer un commentaire