Stanislas Quastana's blog on TechNet

Windows Server, Windows Client, Cloud Computing, DirectAccess, sécurité des Systèmes d Information

Windows Server 2012 - création d’un partage de fichiers SMB 3.0 pour Hyper-V et Storage Migration

Windows Server 2012 - création d’un partage de fichiers SMB 3.0 pour Hyper-V et Storage Migration

  • Comments 20
  • Likes

Une des nouveautés d’Hyper-V dans Windows Server 2012 est la possibilité de stocker les fichiers des machines virtuelles sur un partage de fichiers. Ce partage de fichiers doit utiliser la nouvelle version du protocole SMB c’est à dire la version 3.0 qui propose de nouvelles fonctionnalités telles que le multicanal (cf. l’article d’Arnaud Lheureux à ce sujet) ou encore le chiffrement.

Cet article a pour objectif de montrer (1) la création pas à pas d’un partage de fichiers SMB 3.0 destiné à recevoir les fichiers de machines virtuelles exécutées sur des hyperviseurs Windows Server 2012 et (2) le déplacement à chaud des fichiers d’une machine virtuelle.

Ainsi, il sera possible ensuite de faire du Live Migration sans déplacement des fichiers disques des machines virtuelles (ceux-ci restant stockage sur un espace partagé et accessible par les différents hyperviseurs).

Sur le serveur de fichier, ouvrir le gestionnaire de serveur et se positionner dans l’arborescence File and Storage Services puis Shares

Cliquer sur Tasks puis New Share

Sélectionner SMB Share - Applications

Choisir l’emplacement fichier du partage (ici : S:\vm partage smb3)

Dans un partage destiné à des fichiers de machines virtuelles, il n’y a pas d’access-based enumeration ni de BranchCache (appelé ici caching of share). Il est par contre possible de chiffrer la charge utile transportée par SMB 3.0 (à voir l’intérêt car cela va impliquer une charge CPU additionnelle)

Définir ensuite les permissions sur le partage. Ici, j’ai donné les droits de modification à mes différents hyperviseurs (HyperStan1$, HyperStan2$ et HyperStan3$)

Petit récapitulatif

Cliquer sur Create

Et hop le partage est opérationnel.

Il reste à tester le bon fonctionnement en faisant un Storage Migration d’une machine virtuelle stockée localement et exécutée sur un hyperviseur.

Pour tester Windows Server 2012, vous pouvez télécharger gratuitement la version d’évaluation disponible sous la forme :
- d'une image ISO :
http://aka.ms/jeveuxwindows2012

- d'un fichier VHD avec un système préinstallé : http://aka.ms/jeveuxwindows2012

 
-
Stanislas Quastana -

Comments
  • et l'article d'Arnaud sur le chiffrement dans SMB 3.0 : blogs.technet.com/.../am-233-liorations-de-s-233-curit-233-de-smbv3.aspx

  • Super article y'a plus qu'a tester !.

    Merci.

    Qu'en est-il des performance sur du SMB3.0 par rapport à du iscsi par exemple ?

  • J'ai déjà débuté une ébauche de réponse sur ce point dans les commentaires de l'article suivant blogs.technet.com/.../monter-son-nas-san-personnel-sous-windows-server-2012-partie-5-la-cible-iscsi.aspx  

    Cordialement

  • Grace à vos formidables sessions des Techdays (Merci !), je sais maintenant qu'il faut un minimum de 500Mbit pour le live transfert de Machine, mais je souhaiterais savoir les préconisations pour le lien entre le partage et l'hyper-v pour le fonctionnement d'une machine avec le vhdx sur le partage ?

    Cordialement

  • @Michael : Plutôt qu'un long discours, un bon lien :-)

    Un article très intéressant sur SMB 3.0 et Hyper-V : blogs.technet.com/.../hyper-v-over-smb-performance-considerations.aspx

  • Bonjour, la volumétrie des partages est-elle limité a 16To (je ne trouve pas d'infos dessus) ? Car sur d'autres types de baies, les FileSystem sont limités à 16To. Cordialement,

  • @Tony Si le volume est formaté en NTFS, alors la taille maximale est de 2^32 allocations uniques (= clusters de disques). Désormais sur les gros disques, la taille des clusters est de 4k. 2^32x4096 = 16 To Ref : http://technet.microsoft.com/en-us/library/cc938432.aspx ==> la limite de 2^32 allocations uniques par volume NTFS ReFS supporte par contre des volumes allant jusqu'à 2^78 octets avec des clusters de 16k (Ref: http://technet.microsoft.com/en-us/library/hh831724.aspx et http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx)

  • Merci pour ce retour, cependant, en faisant quelques recherches, je suis tombé la dessus : http://blogs.technet.com/b/askcore/archive/2010/02/18/understanding-the-2-tb-limit-in-windows-storage.aspx (dans les commentaires) et quelqu'un disait que sous WS2K12, la limite était passé a 256To en NTFS. Tu confirmes ?

  • huuumm à la lecture de cet article, effectivement il semblerait qu'on puisse aller au delà des 16 To. Ce qui m'étonne en fait dans ce post blog c'est qu'il est daté de 2010 et qu'après moultes recherches, je viens de trouver que ce serait dans Windows Server 2012 R2 que ces changements de taille seraient supportés (cf. http://technet.microsoft.com/en-us/library/dn466522.aspx) extrait : "Supporting large volumes. NTFS allows you to create an NTFS volume up to 16 terabytes using the default cluster size (4 KB) for large volumes. You can create NTFS volumes up to 256 terabytes using the maximum cluster size of 64 KB" Donc le calcul que j'avais donné ci-dessus demeure juste mais donne donc un résultat différent avec des clusters de 64KB : 2^32*64 = 256 To Mais c'est donc confirmé une partition NTFS sur Windows Server 2012 R2 est supportée jusqu'à 256 To. Donc merci d'avoir posé la question car elle a permis de lever le doute sur ce point ;-)

  • Ok merci pour le lien :) Par contre, petite question (car j'ai pas les moyens techniques de tester ^^) : lorsque tu veux créer un partage de plus de 16 To (imaginons 24 To), tu as (il me semble) 2 solutions. Soit tu fais 1 Métalun (sur ta baie) composé de X lun que tu présentes à ton système; Soit tu présentes 6 Luns de 4To à WS2012, ensuite tu créés un storage pool ou tu y mets tes 6 luns et tu arrives bien au 24To. Par contre, question, comment est géré l'écriture sur ces Luns ? Je précise ma question : sur les baies il y a des mécanismes de "striping" (pas sur que ça se dise mais bon) ce qui répartit les données envoyées sur ton espace logique vers tes différents disques physiques (parralélisation des flux), windows fait-il la même chose ?

  • J'avoue que je n'en ai aucune idée. Je vais donc me renseigner et la réponse va probablement prendre un peu plus de temps ;-)

  • Alors, via un ESXi j'ai présenté 3 Luns à ma VM Windows Server 2012. Malheureusement, je n'ai pas réussi à créer un Storage Pools (il me disait que je n'avais pas de disques dispos alors que dans Disks, il y avait bien mes 3 luns ...) du coup en cherchant je suis tombé sur le Disk Management qui m'a permis de faire un clic droit "new stripped volume" et donc de faire un volume strippé de mes 3 luns ... je vais essayé de creusé un peu tout ça mais si tu as de la doc dessus je suis preneur :)

  • par contre, le formatage d'un volume stripé de 3 disques de 2Go chacun est super long ... (1h15 pour 8%)

  • Si j'ai bien compris l'ESXi a également une cible iSCSI c'est bien cela ? Pour configurer un StoragePool, il ne faut pas passer par l'interface Disk Manager mais par le gestionnaire de serveur ou la ligne de commande PowerShell. La configuration d'un storage pool à partir de 3 disques est détaillée ici : http://blogs.technet.com/b/stanislas/archive/2013/09/13/windows-server-2012-r2-et-stockage-montage-d-une-plateforme-de-tests-partie-3-storage-spaces-et-disques-virtuels.aspx

  • Ce temps de formatage me parait bien trop long. Dans tous les cas, la manipulation de "stripper" les 3 disques via le gestionnaire de disque n'est pas la bonne (car ici c'est simplement une gestion RAID software "à l'ancienne" comme on sait le faire depuis NT 4.0) car ce n'est pas l'utilisation des Storage Pools et disques virtuels

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment