Cr

[LeGregox]

​

Bonjour à tous,

C'est le premier post d'une série qui sera consacrée à la virtualisation (VMWare dans un premier temps, KVM peut-être après)

Ce message s'adresse clairement (et peut-être uniquement ?) aux personnes qui s'intéressent à la virtualisation (ou a minima au stockage SAN en iSCSI)

Avant-propos :
------------
J'ai acheté une nouvelle config récemment pour remplacer ma vieille bécane. Équipée pour le moment d'un seul disque (SSD Samsung 840 Pro, de 256 Go ; une belle bête qui tire 100 k IOs…)

Vu que j'utilise la machine en multi-système, que j'y dépose quand même des fichiers ou des programmes (en plus de ce que je mets sur le NAS) et que je me lance dans la virtu VMWare, il me fallait un stockage déporté (SAN : Storage Area Network)

J'ai donc profité de mon Synology 1512+ (http://www.synology.com/en-us/products/overview/DS1512+) pour le paramétrer comme SAN. L'avantage du Syno étant bien sûr son interface qui rend tout plus simple (et globalement, je lui dois une belle partie de mon expertise informatique récente)

Les étapes :
------------

1) création d'un LUN (logical-unit-number)

Il faut choisir le type parmi :

• LUN en mode fichier avec ThinProvisionning (allocation de l'espace par "petits bouts") qui offre de moins bonnes performances que les autres (puisqu'il s'appuie sur le système de fichiers du système hôte) ;
• LUN en mode bloc (directement sur le disque) avec un seul volume sur RAID (si on veut) ce qui offre les meilleurs performances, mais aucune flexibilité ;
• LUN en mode bloc avec multiples volumes sur RAID grâce à la surcouche LVM (logical volume management) qui offre de bonnes performances, et qui permet d'ajuster "à la main" la taille des espaces alloués.

Comme je risque de créer à terme pas mal de LUN différents, je voulais que seul l'espace réellement consommé soit effectif au compteur de la baie (l'espace n'est pas illimité). Et comme en plus je n'ai pas d'espace non alloué par le système de fichiers du NAS, je n'ai pas eu le choix. Donc, c'est le premier mode que j'ai choisi (perfs dégradées, mais de toute façon le lien est "seulement" de l'ethernet gigabit non redondé, donc pas de multipath, multisession ou ce genre de choses)

Sur ce premier LUN, j'ai activé les extensions VAAI pour VMWare (déport de certaines opérations de stockage directement sur la baie), l'équivalent ODX pour la virtualisation sous Windows, ainsi que le snapshot et le clonage de LUN à chaud. Dans ces deux derniers cas, le système fige artificiellement l'image du stockage, le temps de la copie. Mais le système reste utilisable grâce à l'écriture différentielle des données.

J'ai mis 50 Go de capacité (taille vue par le client) mais on peut changer ça n'importe quand.

2) création d'un iSCSI target pour héberger le LUN

Affectation d'un nom commun et d'un IQN (iSCSI Qualified Name) : identifiant globalement unique du target. Pour garantir l'unicité, la RFC 3720 définie une norme pour cet identifiant (basé notamment sur le Domain Name, une date, le littéral "iqn" et un identifiant de nommage.

Pour la sécurité, j'ai configuré CHAP (Challenge-Handshake Authentication Protocol) avec un login et un mot de passe qui devra être connu du/des client(s). CHAP, comme son nom l'indique, permet l'authentification par mot de passe, mais avec un challenge : le mot de passe, ou secret commun, est utilisé mais jamais communiqué. Ainsi, l'authentification se passe sans l'échange du mot de passe, et sans rejeu possible du paquet d'auth. MS-CHAP est la version Microsoft du protocole, qui apporte des améliorations, et est utilisée notamment dans les réseaux Wifi.

En plus, j'ai rajouté un filtrage par IQN : seule la machine avec le bon IQN sera autorisée en lecture/écriture. Les autres en lecture seulement.

Je n'ai pas utilisé le CHAP mutuel, parce que je fais suffisamment confiance à mes identifiants et à leur stockage pour être sûr que personne ne les découvrira.

Enfin, pour la sureté des données, j'ai activé le contrôle d'erreur (CRC) sur les données (mais pas sur les entêtes, je ne pense pas que mon réseau soit si mauvais)

Comme je le disais plus haut, mon lien est un classique ethernet (gigabit quand même) donc je n'ai pas activé le multipath, ce qui m'évitera en plus de configurer ça dans le client : il faut définir des chemins différents d'accès et leur donner des poids en fonction des préférences. Notons que le multipath sert aussi à l'accès par plusieurs clients, mais qu'il faut pour cela que le système de fichiers utilisé soit multitenant (accès concurrents sans corruption des données, notamment en utilisant des verrous)

Finalement, j'ai foutu la taille des paquets send/recv à fond, parce que je suis un particulier et pas une entreprise : mon réseau est globalement sous-exploité, de même que la baie (quoique… TTRSS + MySQL avec binlogs est consommateur). Puis je pense que tout ça est stable et que les erreurs de liens sont très rares (il y a 5 mètres maximum entre les équipements et pas tellement de perturbations)

3) iSNS

On peut enregistrer sa target sur un service en ligne iSNS afin de la rendre accessible facilement. Par exemple de l'extérieur. L'avantage c'est que ça simplifie pas mal la configuration des clients, qui récupère une grande partie de la conf depuis le service iSNS.
Bref, je n'ai ni ce type de service à dispo, ni l'envie de l'utiliser, ni le besoin. Au contraire.

FYI only.

4) le client ou initiateur iSCSI

Là, ça se corse.

L'initiateur est généralement vu comme un driver ou un module noyau du côté de la machine cliente (afin d'obtenir de bonnes perfs, mais aussi parce qu'on est dans des couches systèmes très basses, eg. SCSI)

Sous XP il fallait ajouter le driver, c'était pas super. Mais sous Seven Pro, il préexiste. Et semble bien mieux géré. Problème : la configuration est toujours aussi dégueulasse.

En gros, il faut :

• configurer l'IQN du client dans "Configuration" (le dernier onglet, faut pas chercher​, c'Windows) ;
• ​entrer le nom DNS/réseau ou adresse IP de la machine hôte pour découvrir les targets (sauf si on a changé le port par défaut) ;​
• ​se connecter sur la target en créant une session (c'est ici qu'on rentrera les login/secret pour le CHAP, mais aussi qu'on indiquera les options qui nous intéressent : CRC des données ;​
• ne pas configurer RADIUS, CHAP mutuel, IPsec, etc. Ni de multipath (ni au niveau du système hôte, ni target, ni LUN ; ouf) ;​
• éventuellement, fixer les attributs variables (mon IP, l'IP du système hôte, etc.)

​Ici, il faut vérifier que l'initiateur se souviendra de cette configuration et la réutilisera à chaque démarrage du système.

​5)​​ utiliser son nouveau périph !

Il ne reste plus qu'à aller dans "gestion des disques". Dès qu'on arrive, Windows va nous dire "oh, t'as branché de nouveaux devices ! On va les formater". Donc il faut choisir entre deux types d'enregistrement de partitions :

1. le vieux MBR (Master Boot Record) ;
2. le nouveau GPT (GUID Partition Table) qui fait partie du standard (U)EFI.

J'ai choisi ce dernier pour toutes les raisons données ici : https://fr.wikipedia.org/wiki/GUID_Partition_Table (et puis c'est compatible Linux tout comme le MBR)

Enfin, partitionner le disque virtuel (donc en une seule partition, sans RAID ni stripping ni JBOD, sinon, aucun intérêt d'avoir fait des LUN)

Pour ma part, j'ai déplacé mon dossier USER sur ce disque et j'ai activé (côté NAS) une sauvegarde régulière.

------------

Pour finir, j'ai préparé la future virtualisation :

1. j'ai bien sûr activé la technologie Intel VT-d sur ma machine (j'ai pris un Intel i7-4771 justement pour avoir VT-d sans être obligé de revendre ma meuf pour acheter un Xeon)
2. l'extension VAAI (déport d'opérations relatives au stockage VMWare vSphere 5 vers la baie) a été activée sur le Syno
3. enfin, j'ai activé SMB2 (aucun rapport ici, mais ils sont liés) et LargeMTU¹ et augmenté manuellement la largeur de trame MTU sur Ethernet²

Si quelqu'un veut m'offrir une licence maintenant…

¹ : notons qu'il faut aller activer ça dans le registre Windows : c'est supporté mais pas activé par défaut, afin d'assurer un maximum de compatibilité descendante avec les vieilles infra réseau [cf: http://technet.microsoft.com/en-us/library/ff625695%28v=ws.10%29.aspx]

² : pour l'instant, le reste des machines du réseau semblent continuer de fonctionner correctement… Bizarre, j'avais lu qu'il fallait que toutes les valeurs MTU soient partagées ? Peut-être une fonction géniale du switch et/ou point d'accès Wifi ?

P.S : j'suis vraiment content d'être passé sur Windows 7 et d'avoir abandonné mon vieux XP qui m'a rendu tant de services. Beaucoup de technologies actuelles sont supportées nativement dans ce système (et donc mieux) et surtout on travaille vraiment plus efficacement.