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


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 :
https://aka.ms/jeveuxwindows2012

d’un fichier VHD avec un système préinstallé : https://aka.ms/jeveuxwindows2012

 
Stanislas Quastana

Comments (20)

  1. denis.eche@12si.fr says:

    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 ?

  2. 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

  3. mguirao@live.fr says:

    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

  4. @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

  5. Tony D. says:

    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,

  6. @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^32×4096 = 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)

  7. tony says:

    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 ?

  8. 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 😉

  9. Anonymous says:

    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 ?

  10. 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 😉

  11. Anonymous says:

    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 🙂

  12. Anonymous says:

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

  13. 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

  14. 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

  15. Anonymous says:

    ok je vais regarder tout ça 🙂 pour te détailler l'archi de test actuelle, c'est un esxi qui est relié a un stockage san. J'ai donc donné au serveur virtuel 3 disques en mappage de périphériques bruts. Et de la, impossible de créer un storage pool. Mais je vais regarder ton lien et te faire un retour

  16. Anonymous says:

    Bon, j'ai (je pense) l'explication de pourquoi cela ne marchait pas : en fait, je n'avais pas passé la commande suivante : Install-WindowsFeature Failover-Clustering, RSAT-Clustering -IncludeAllSubFeature … J'ai donc pu créer mon pool. Pour le strip sur les Luns j'ai la réponse également, lorsque l'on créé sur ce pool des vdisk, il nous propose 3 modes. Le simple (qui est stripé sur les disques physiques composant le Pool) le Mirror (tout le monde connait je pense) et le Parity (qui strip sur les disques physiques ET qui protège les données avec une parité mais du coup on perd "un peu" d'espace dispo).

  17. On est donc en dehors de la configuration de cet article qui lui est dédié au stockage sur du SMB 3.0 🙂
    concernant les modes : le mode Mirroir permet aussi une sécurité accrue à partir de 3 disques et devient intéressant à partir de 5 disques. A noter c’est qu’en terme de performances, le mode miroir (à une ou 2 colonnes) est plus performant que le mode Parité qui n’est pas terrible en terme d’écriture

  18. Anonymous says:

    intéressant ça, pourquoi le mode miroir deviendrait-il plus intéressant à partir de 5 disques ? Je comprends qu'il soit plus performant que de la parité (pas de calcul de parité a effectuer) mais il est surtout très gourmant en volumétrie ^^ 50% pour le miroir contre 20% pour du Raid5 par exemple. Mais effectivement, si on court après les IO (pour une BDD par exemple) un Raid 1-0 peut-être très efficace
    PS : dsl pour le HS mais à la base mes posts concernaient la taille max des partages et de fil en aiguille …

  19. csmsarr says:

    Article très intéressant . Merci