Nous économisons sur un contrôleur RAID, ou comment nourrir Varia avec Iops

À notre époque des services cloud, AWS Lambda et autres hébergements partagés de ressources informatiques absolument intangibles, je veux parfois un peu de moi-même. En plus du désir, il est parfois nécessaire de tordre judicieusement l'un ou l'autre produit logiciel avec des coûts de plate-forme minimes. Vous pouvez presque toujours trouver un équipement en excès, parfois il s'avère même de tout assembler et de l'allumer. Si ces surplus représentent un processeur avec au moins 4 à 6 cœurs et une mémoire de 64 Go - généralement excellente, vous pouvez utiliser ESXi et travailler avec n'importe quoi. Un problème: avec une capacité de disque sur le matériel domestique de VMWare - absolument rien. Les performances des disques durs locaux uniques sont faibles, et perdre le contenu d'une seule vis dans le vide au 21e siècle est comme bonjour. Essayons de connecter quelque chose sur le réseau.

TL; DR> association, équilibrage, limite rr, c'est tout.

En fait, le texte ci-dessous ne concerne pas le fait que cela est généralement possible ou une sorte de savoir-faire. Internet regorge d'articles pour les nuls (cochez ici, puis Suivant, Suivant, Terminé) sur la façon de soumettre une capacité de disque iSCSI. J'écris juste pour exclure les «erreurs des survivants» et partager les moments où «tout ira mal» (et ça ira, Murphy avait raison), et quand vous essayez de charger la solution, elle plante tout simplement.

Nous allons donc essayer d'étouffer notre "hyperviseur domestique" avec une baie de disques externe connectée sur le réseau. Étant donné que tout tourne autour de nous «à peu de frais», que ce soit FreeNAS et 4 disques SATA, qui sont desservis par un médiocre 3 GHz à 45 nm pour cent. Nous regardons Ebay, et pour de l'argent comparable à un contrôleur RAID utilisé, ils en tirent quelques cartes réseau i350-T4. Ce sont des adaptateurs gigabit à quatre ports d'Intel. Selon eux, nous associerons le stockage à l'hyperviseur.

Comptez un peu. La vitesse de transfert de données moyenne d'un disque SATA moyen est de 160 à 180 Mo / s avec une largeur d'interface de 6 Go / s. En fait, le taux de transfert de données réel depuis le disque dur ne dépasse pas 2 Gb / s. Ce n'est pas un si gros chiffre, étant donné que nous prévoyons des ports 4 gigabits (comment transformer 4x1Gbps en 4Gbps - nous en discuterons plus loin). Tout avec des vitesses d'accès aléatoire est bien pire - ici, tout tombe presque au niveau des disquettes.


Étant donné que le profil de charge de disque de nombreux systèmes d'exploitation invités est loin d'être linéaire, j'aimerais voir des chiffres plus amusants. Pour corriger la situation dans le système de fichiers de l'hyperviseur (VMFS v6), la taille du bloc est de 1 Mo, ce qui permet de compacter de nombreuses opérations aléatoires et accélère l'accès aux données sur les disques virtuels. Mais même avec cela, un disque physique ne sera pas suffisant pour gérer les opérations d'E / S de tous les "invités".

Je ferai une réservation tout de suite - tout est plus logique si vous avez plus de deux adaptateurs pour le "réseau de stockage". ESXi avec une licence uniprocesseur gratuite peut se connecter, en plus des disques locaux, à deux types de stockage - NFS et iSCSI. NFS implique un accès au niveau du fichier et est également bon à sa manière. Sur celui-ci, vous pouvez déployer des invités peu exigeants sur les performances du disque. C’est un plaisir de les sauvegarder. vous pouvez ouvrir la même boule NFS ailleurs et copier des instantanés vm. En général, avec une interface réseau (si ce n'est pas 10GE, bien sûr) - NFS est votre choix.

ISCSI présente plusieurs avantages par rapport à NFS. Afin de les réaliser pleinement, nous avons déjà préparé - ayant déjà prévu 4 ports gigabits pour le réseau de stockage. Comment l'extension de la bande passante du réseau se produit-elle généralement à une vitesse d'interface connue? C'est vrai, l'agrégation. Mais pour l'utilisation complète du canal agrégé, un certain nombre de conditions sont nécessaires, et cela est plus approprié pour la communication entre les commutateurs ou pour une liaison montante réseau d'un hyperviseur. L'implémentation du protocole iSCSI fournit une fonction telle que le multichemin (littéralement, de nombreux chemins) - la possibilité de connecter le même volume via différentes interfaces réseau. Bien sûr, sur la possibilité d'équilibrage de charge là aussi, bien que l'objectif principal soit la tolérance aux pannes du réseau de stockage. (En toute honnêteté, NFSv4.1 prend en charge la jonction de session basée sur la magie la plus avancée telle que RDMA et MPTCP, mais c'est une tentative de déplacer les problèmes d'accès aux fichiers d'une tête douloureuse à une tête saine à des niveaux inférieurs.)

Donc, pour commencer, nous publierons notre objectif. Nous pensons que FreeNAS est installé, l'adresse IP de la direction nous envoie régulièrement l'interface Web, nous coupons le tableau et zvolons dessus en totale conformité avec nos convictions internes. Dans notre cas, il s'agit d'un lecteur 4 x 500 Go combiné en raidz1 (qui ne donne que 1,3 TiB de capacité effective), et zvol est exactement de 1 To. Nous allons configurer les interfaces réseau i350, pour plus de simplicité, nous acceptons que tout le monde appartienne à des sous-réseaux différents.


Ensuite, nous configurons la balle iSCSI en utilisant la méthode «Next, Next, Done». Lors de la configuration du portail, n'oubliez pas d'y ajouter toutes les interfaces réseau dédiées à iSCSI. Cela devrait ressembler à quelque chose sur les photos.



Un peu plus d'attention devra être accordée à la définition de l'étendue - lors de la présentation d'un volume, il est nécessaire de forcer une taille de bloc de 512 octets. Sans cela, l'initiateur ESXi a refusé d'identifier les volumes présentés. Pour des raisons de fidélité, il est préférable de désactiver les tailles de probros du bloc physique (qui sur zvol n'est pas et ne peut pas l'être) et d'activer le mode de support Xen.
Avec FreeNAS pour l'instant.

Côté ESXi, il est un peu plus difficile de configurer un réseau. Encore une fois, nous pensons que l'hyperviseur lui-même est installé et également géré sur un port séparé. Vous devrez sélectionner 4 interfaces VM Kernel appartenant à 4 groupes de ports différents dans 4 commutateurs virtuels différents. Chacun de ces commutateurs possède son propre port physique de liaison montante. Nous prenons les adresses vmk #, bien sûr, dans les sous-réseaux correspondants, de manière similaire à la configuration des ports de stockage. L'ordre de définition des adresses est, en général, important - soit nous connectons des cartes de port à port sans commutateur, soit nous donnons des liens différents à différents réseaux (enfin, c'est à la manière d'un adulte), donc la correspondance physique des ports est importante.




Lors de la configuration d'un réseau pour iSCSI, nous accordons une attention particulière au paramètre MTU. C'est exactement le cas lorsque «la taille compte» - nous prenons le maximum que tous les composants réseau peuvent installer. Si les cartes sont connectées directement, vous pouvez pointer le mtu 9000 des deux côtés, sur ESXi et FreeNAS. Cependant, les commutateurs normaux prendront en charge cette valeur. On fait un ping, on voit que le réseau est normal, et les paquets de la taille requise passent. Super. Nous avons mis le feu à l'initiateur.

Activez iSCSI, ajoutez des adresses IP à la section de configuration dynamique (Stockage -> Adaptateurs -> Configurer iSCSI -> Cibles dynamiques). Après l'enregistrement, les portails iSCSI seront interrogés à ces adresses, l'initiateur déterminera que chacun d'eux a le même volume et s'y connectera à toutes les adresses disponibles (le même chemin d'accès multiple). Ensuite, nous devons créer une banque de données sur l'appareil qui apparaît.

Après cela, vous pouvez déployer la machine virtuelle et mesurer ce que nous avons obtenu.


Des résultats pas si impressionnants. Ouvrez la console de stockage, affichez l'état actuel du réseau et exécutez les tests.

root@freenas:~ # systat -ifstat
Que voyons-nous?
  /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average Interface Traffic Peak Total lo0 in 0.319 KB/s 0.893 KB/s 3.041 MB out 0.319 KB/s 0.893 KB/s 3.041 MB alc0 in 0.478 KB/s 1.233 KB/s 3.934 MB out 0.412 KB/s 1.083 KB/s 2.207 MB igb3 in 0.046 KB/s 0.105 KB/s 181.434 KB out 0.073 KB/s 0.196 KB/s 578.396 KB igb2 in 0.046 KB/s 0.105 KB/s 120.963 KB out 0.096 KB/s 0.174 KB/s 517.221 KB igb1 in 4.964 MB/s 121.255 MB/s 10.837 GB out 6.426 MB/s 120.881 MB/s 3.003 GB igb0 in 0.046 KB/s 0.105 KB/s 139.123 KB out 0.073 KB/s 0.210 KB/s 869.938 KB 


Un seul des quatre ports réseau (igb1) a été utilisé. Cela se produit car le mécanisme d'équilibrage fourni par défaut pour les trajets multiples sélectionne le même adaptateur avec chaque paquet de données. Nous devons utiliser de tout.
Nous sommes connectés à l'hyperviseur via SSH et commande.
Voyons d'abord quel ID la lune a avec les trajets multiples et comment cela fonctionne:

[root@localhost:~] esxcfg-mpath -b
naa.6589cfc000000b478db42ca922bb9308 : FreeNAS iSCSI Disk (naa.6589cfc000000b478db42ca922bb9308)

[root@localhost:~] esxcli storage nmp device list -d naa.6589cfc000000b478db42ca922bb9308 | grep PSP
Path Selection Policy: VMW_PSP_MRU


La politique de sélection de chemin est MRU, c'est-à-dire la plus récemment utilisée. Toutes les données vont au même port, la resélection du chemin ne se produit que lorsque la connexion réseau n'est pas disponible. On passe au round-robin, dans lequel toutes les interfaces changent tour à tour après un certain nombre d'opérations:

[root@localhost:~] esxcli storage nmp device set -d naa.6589cfc000000b478db42ca922bb9308 -P VMW_PSP_RR

Nous redémarrons ESXi, ouvrons la surveillance, exécutons des tests. Nous voyons que la charge est répartie uniformément sur les adaptateurs réseau (au moins les valeurs de pointe, trop grattées), les résultats des tests sont également plus amusants.

  Interface Peak igb3 in 43.233 MB/s out 46.170 MB/s igb2 in 42.806 MB/s out 45.773 MB/s igb1 in 43.495 MB/s out 45.489 MB/s igb0 in 43.208 MB/s out 46.079 MB/s 

Il y a quelques écarts sur les ports, cela est dû aux limites de la stratégie de sélection de chemin - le nombre d'opérations ou d'octets, après quoi le passage à un autre port a lieu. Par défaut, 1000 IOPS, c'est-à-dire que si l'échange de données est dans les 999 opérations, il passera par un port réseau. Vous pouvez modifier, comparer et sélectionner la valeur appropriée. Vous ne pouvez pas changer, la valeur par défaut est suffisante pour la plupart des tâches.

Nous prenons des mesures, testons, travaillons. Les résultats sont nettement supérieurs aux capacités d'un seul disque, de sorte que nos machines virtuelles ne peuvent plus être coudées lors d'opérations d'E / S. Les vitesses et la tolérance aux pannes résultantes de la baie dépendent du matériel et de la configuration du volume.

Source: https://habr.com/ru/post/fr423513/


All Articles