Compartilhar via

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

  • Artigo

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

  • Anonymous
    January 22, 2013
    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

  • Anonymous
    January 23, 2013
    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 ?

  • Anonymous
    January 23, 2013
    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

  • Anonymous
    February 18, 2013
    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

  • Anonymous
    February 27, 2013
    @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

  • Anonymous
    December 18, 2013
    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,

  • Anonymous
    December 18, 2013
    @TonySi 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 ToRef : http://technet.microsoft.com/en-us/library/cc938432.aspx ==> la limite de 2^32 allocations uniques par volume NTFSReFS 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)

  • Anonymous
    December 18, 2013
    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 ?

  • Anonymous
    December 19, 2013
    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 ToMais 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 ;-)

  • Anonymous
    December 19, 2013
    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 ?

  • Anonymous
    December 19, 2013
    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 ;-)

  • Anonymous
    December 23, 2013
    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 :)

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

  • Anonymous
    December 23, 2013
    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

  • Anonymous
    December 23, 2013
    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

  • Anonymous
    December 23, 2013
    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

  • Anonymous
    December 23, 2013
    The comment has been removed

  • Anonymous
    December 23, 2013
    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

  • Anonymous
    December 24, 2013
    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 efficacePS : dsl pour le HS mais à la base mes posts concernaient la taille max des partages et de fil en aiguille ...

  • Anonymous
    July 16, 2014
    Article très intéressant . Merci