Bonjour,

Pour un projet en cours, j'ai besoin de présenter les solutions de hautes disponibilitées existantes sur 2012R2.

A ce jour, j'ai beau cherché un peu partout sur internet, j'ai un peu de mal à faire une synthèse de tout ca donc je vais mettre les différentes explications que j'ai pu comprendre pour le moment :

Soit on mets les roles en cluster, soit on met carrement les VM.
Lorsqu'on mets les VM on appelle ca un cluster Hyper-v.

Pourquoi utiliser une méthode plutot que l'autre ?

J'aurai dis que c'est bien de monter n cluster hyper-v dans le cas ou il y a plusieurs roles au seins d'une meme vm ou que les roles installés dans la vm ne supporte pas le cluster.

Différentes méthodes de cluster de roles :

1) cluster simple ou SOFS

Le SOFS est utilisé dans le cas de mise en cluster de role de BDD, Appli métier ou VM. Il ne supporte pas le DFS et les quotas (donc on évite de mettre le FS de cette manière). L'avantage est que derrière o met le stockage en CSV et donc plusieurs hotes peuvent accèder en meme temps à ce stockage partagé. Ce qui n'est pas le cas dans un cluster "simple".

Dans tous les cas, on se retrouve dans une configuration avec un quorum qui contient la configuration du cluster et un san est nécessaire.

2) cluster hyper v

Live migration
apparu avec 2012 Migration a chaud d'une vm d'un hote 1 vers un hote 2. Le san n'est pas obligatoire mais dans ce cas la, comment se passe le basculement si un hote tombe ? Et si on le remet en etat de marche ensuite ?
disponible entre 2 serveurs autonome ou un autonome et un en cluster ou deux en cluster.

Quick migration
je ne comprends pas vraiment la différence avec le live a part que c'etait la fonctionnalité utilisé avec 2008r2 qu'il y a un downtime plus important et qu'il faut une bonne bande passante.

réplica
Utilisé plutot en configuration multi site. Cela permet d'avoir une copie asynchrone d'un vhd(x) et de sa configuration vers un serveur distant. C'est donc une copie qui passe a travers le WAN avec le choix  du timing (5,15,30 min) de synchronisation. Est ce que si l'hote tombe l'autre prend la releve automatiquement ? Et si on le remet en etat comment cela se passe ?
Ce mode peut etre utilisé d'un serveur autonome vers autonome, cluster a autonome, autonome a cluster ou cluster a cluster.

J'ai du mal a comprendre car parfois je vois le live migration avec un cluster parfois non. Donc peut etre que les deux solutions sont possibles et dans ce cas la quelle est la différence ? Le cluster permet l'automatisatio nde la tache alors que sans ce dernier il faut réaliser l'action manuellement ?

Concretement, le besoin auquel li faut que je réponde est celui ci :

Ci un client a sur un hote hyper v et tous les roles dans des vm (certaines vm avec un roles, d'autres avec plusieurs) comment faire de la haute disponibilité ?
Sur un serveur sans virtualisation ?
Sur un serveur sur lequel il y a le serveur de fichier sur l'hote, et des vms avec d'autres roles dans hyper v ?

Pour ma part, si jamais il n'y a pas de virtualisation -> cluster de role obligatoire.
Si jamais il y a de la virtualisation -> live migration de ce que j'ai pu voir c'est ce qui est recommandé. J'aimerais simplement comprendre pourquoi etc...

C'est dans un environnement avec des petites structures (< 100personnes) mais je souhaiterais quand meme avoir vos avis pour savoir ce qu'il en est concrétement sur des pme ou des boites plus importantes et enfin arriver a avoir un peu plus de recul  )

Je vous remercie par avance pour toutes les explications qui pourraient m'etre données

Sans vouloir être méchant, tu mélanges un peu tout. Reprends la doc proposé par Microsoft sur Technet sur Hyper-V, et regarde les labs gratuits sur Internet qui sont proposés aussi par Microsoft pour te faire la main.

+1 tu mélanges tout. C'est comme si tu t'amusais à écrire tous les mots que tu as trouvé sur le net dans une même phrase en espérant que ça veuille dire quelque chose

en effet je vois des choses différentes selon les sites en fait je suis en train de voir.

Donc la au final, je lis que le live migration :
migration sans downtime d'un host A vers B si jamais c'est planifié, sinon il y a redémarage de la vm sur l'hote B.

storage migration :
prévue justement pour un cas ou il y a une défaillance matérielle et permet a l'hote de démarer la vm avec la perte des données depuis la derniere sauvegarde (5 min minimum donc).

bref, je retourne sur microsoft voir ca

Non ce n'est pas du tout ça. Reprends les docs et les labs depuis le tout début, si tu te mélanges les pinceaux sur les définitions des termes de base tu ne pourras pas aller beaucoup plus loin.

c'est pas du tout ca O_o

Hyper-V Replica adds the following new features in Windows Server 2012 R2:
You can configure extended replication. In extended replication, your Replica server forwards information about changes that occur on the primary virtual machines to a third server (the extended Replica server). After a planned or unplanned failover from the primary server to the Replica server, the extended Replica server provides further business continuity protection. As with ordinary replication, you configure extended replication by using Hyper-V Manager, Windows PowerShell, or WMI.

The frequency of replication, which previously was a fixed value, is now configurable.

-> donc le réplica  :

permet de répliquer les vms d'un server vers un serveur de réplica.
En pratique, cette technique est utilisé lorsqu'une entreprise dispose de plusieurs sites. Si jamais le site 1 a un probleme( incendie, panne electrique...) , on peut facilement remettre le SI en route grace à tous les serveur réplica sur le site 2.

En terme d'avantage, la configuration de stockage n'a pas besoin d'etre la meme au niveau du site 1 et 2.
La synchronisation entre les vms du  site1 et 2 peut etre choisi (5,15 ou 30 min). Le transfert peut se faire en utilisant kerberos et de manière crypté
Ce qui veut dire que lorsqu'on à un probleme sur le site 1 il y a la perte du delta des données avec la dernière synchronisation.

jusque la c'est bon ?

PS : je sais pas pourquoi j'étais persuadé que le réplica c'etait le storage migration donc en effet ce sont 2 choses différentes.

storage migration : déplacement à chaud (sans interruption) d'une VM d'un lieuA vers un lieuB alors que sous 2008r2 il fallait éteindre la VM

Ouais tu parles de replica là alors que pas avant mais bon, on n'est plus à ça près

Bon j'ai un peu de temps devant moi je vais t'aider un peu.
 

Dans un monde idéal, je dirais qu'il y a plusieurs raisons :
- financier. Parfois, mettre une vm en cluster est moins onéreux que de mettre un rôle (SQL par éxemple) en cluster.
- technique : Certains rôles ne se clusterisent pas. Dans ce cas, pour avoir une tolérance de panne, on virtualise le serveur, et c'est la haute dispo hyper-V qui va prendre le relais.
 
A savoir, un cluster de rôle/application est toujours plus performant qu'une haute dispo de VM (valable pour de l'hyper-V ou autre). Pourquoi ? Car lors d'une bascule de VM suite à la perte d'un hôte du cluster hyper-v (pas en cas de live migration) il y aura un temps de redémarrage de la VM sur un autre hôte qui fait que l'application ne sera pas accessible pendant un laps de temps.
 
De plus, certaines applications n'acceptent pas le HA (haut dispo en anglais) niveau hyper-v, car quand ton hôte se coupe, il se peut que les données ne soient plus consistantes. On prendra par exemple le cas d'un serveur SQL qui est en cours de défrag sur la base, si une coupure se produit, pas sur qu'en redémarrant la base soit toujours en état de fonctionnement car on a coupé le serveur pendant une écriture.
 

Pas N cluster. Dans bien des cas, tu monte un cluster hyper-v constitué de n serveurs pour héberger X vms.
 

Live migration : Ben si pas de stockage partagé et que ton hôte 1 qui héberge la VM tombe ... Ben t'as plus de haute dispo, et ta vm est invisible. Normal. C'est pas vraiment de la haute dispo, ca permet de mettre l'hôte 1 en maintenance en basculant les VMs mais pas de parer à une panne. C'est déjà bien, mais on ne parle pas ici de haute dispo, puisqu'il n'y a pas de cluster. En effet, pour du clustering, il faut du stockage partagé.
 
Quick Migration : En 2008R2 on faisait déjà du live. Le quick permet, comme son nom l'indique, de migrer plus rapidement une vm d'un hôte à un autre. Par contre, durant la migration, cette machine est mise en pause et donc pas accessible.
 
Storage migration : Tu confonds avec l'hyper-v réplica qui permet d'avoir une copie à distance. Ce n'est absoluement pas un mécanisme de haute dispo, mais un plan de reprise d'activité en cas de problème important (on appelle cela un PRA "plan de reprise d'activité" ), non le storage migration est un mécanisme qui te permet de déplacer les fichier d'une VM :
- sur le même disque : Si tu veux ranger tes données
- sur un autre disque sur un même serveur : Si un disque devient plein par éxemple et que tu veux faire de la place.
- sur un autre serveur : Là on est dans le cas d'une infra sans stockage partagé.
 

Cas du live migration sans cluster :
En réalité le système réalise 2 actions :
- il fait un storage migration : Il déplace de l'hôte 1 vers l'hôte 2 les fichiers qui composent la VM.
- live migration : Il migre la VM (mémoire etc ...) vers l'hôte 2
 
Dans le cas d'un cluster :
Qui dit cluster, dit stockage partagé. Du coup, seul le live migration est nécessaire. Le stockage sera simplement "redirigé" sur le nouveau noeud.
 
Quoi qu'il en soit, dans les 2 cas, seul le cluster fait de la haute dispo.
 

Concrètement :
Si il veut un minimum de sécurité, il construit un cluster hyper-V avec minimum 2 hôtes et donc un stockage partagé sur lequel il hébergera toutes ces VM. Si une panne intervient sur un hôte, hyper-v se chargera de basculer les VM d'un noeuds à l'autre, mais il y aura une coupure de service le temps que les machines redémarrent.
 
Si toutefois il a plus de temps, plus de moyen, il pourrait par exemple classer ces services par criticité, et dans ce cas, mixer un cluster hyper-v et un cluster applicatif.
 
exemple ; Chez nous les fichiers ... C'est primordial. Nos machines sont toutes virtualisés sur hyper-V, au sein de nos vm de serveur de fichiers, nous avons monter un cluster de service de fichier, ce qui fait que si une VM se coupe ... L'autre VM, que nous avons pris soin de bloquer sur hôte différent, reprends le relais sans coupure, pendant que la VM en panne redémarre sur un autre serveur. De ce fait, notre risque (que nous avons comblé d'une autre manière mais ce n'est pas le sujet) est que pendant que la vm en rade redémarre, nous n'avons plus de secours .... Mais le service est rendu.
 

Il n'existe pas de solution miracle et parfaite à toute situation, il y a un minima, et un idéal avec des paliers entre les deux.

Mais non, "storage migration" c'est quand même explicite, regarde la traduction en français.
 
Et commence par attaquer la doc de la version 2008 R2 avant 2012, tu seras moins perdu.

Je te remercie ENORMEMENT parce que la c'est vraiment gentil de ta part. C'est des gens comme toi qui font du bien à ce forum et qui me permettent de venir écrire de temps en temps. J'apprécie vraiment ce geste.

En effet, le terme financier est plus que justifié, je n'y avais pas pensé.
en effet, cet aspet la je ne l'avais pas pour savoir la différence et donc le cluster le plus affiné (de role) est en effet le plus performant, ce qui parait quelque part "normal" mais c'es tmieux d'en etre sur.
Ca confirme donc ce que je commencais a comprendre également : impossible lors d'un cluster hyper-v de ne pas avoir d'interruption de service. Il faut donc que la vm redemarre. Parfait j'avance dans les connaissances !

Concernant la non possibilité de mettre des appli en cluster, ca je l'avais vu oui, le SQL le faisant en SOFS non me semble ? de maniere a ce que justement plusieurs serveurs puissent écrire sur le disque en meme temps.

faut de frappe de ma part, je voulais écrire un cluster et pas n cluster.

en effet, si il n'y a pas de stockage externe aux 2 hautes et qu'un tombe ce n'est pas d ela haute dispo. mais vu que le live ne permet d efaire des transfert que dans le cas d'arret planifié, le fait de passé par un san fait que c'est plus rapide ? quel est alors son avantage sinon ?

Pourquoi est ce que le quick migration est capable de la migrer plus vite alors qu'il y a un temp d'arret car elle est mise en pause alors que le live migration ne fait que perdre 2/3 paquet icmp
quel avantage a utiliser le quick plutot que live du coup ?

Pour le storage migration, tu as tout dit, comme j'ai edite plus bas apres, je croyais que c'etait la meme chose mais en tappant les 2 mots dans google j'ai bien vu que non.... Donc merci quand meme la encore tes explications sont très claires.

ouais donc le storage migration va faire que l'action va etre plus ou moins longue selon le lien entre les deux serveurs. en gros le livemigration c'est juste le tranfert de la ram ? puisque c'est le storage migration qui va transferrer le vhd(x) + fichiers de conf.

absolument d'accord avec toi et je comprends tres bien la seconde partie.

Ce qui est con c'est que c'est quelque chose que j'ai mis en place pas mal de fois, mais sans jamais vraiment comprendre derrier epourquoi l'un plutot que l'autre etc, donc la au moins, c'est bien plus clair.

oui cluster de role ca j'avais bien compris par contre ! Le seul truc que je ne sais pas, c'est qu'evidement, le point de cassure plus qu'evident sur ce genre de topo, c'est le stockage partagé si jamais on imagine que c'est sur un 3eme serveur qui fait san virtuel, et que cet hote tombe.... catastrophe pour la boite plus rien ne tombe. donc il faut un 4eme et mettre en cluster le role isci ? ou une autre solution existe ?

Je suis tout a fait d'accord avec toi, la c'es tpour de la pme avec des moyens pas énormes.

Le fait d'avoir toutes ces solutions et de voir un peu plus clair chacunes des possibilitées permets de tiret profits de certaines.
Soit c'est un PRA via le rpelica du coup, soit c'est du livemigration en cluster.

Le cas du replica va obligatoirement nécessiter une intervention humaine (ou faire un script powershell) alors que le cluster live migration se fera automatiquement en cas de coupure donc parait plus approprié dans cette situation.

Je me suis mal exprimer peut etre mais pour moi ca parrait clair (ou t'as peut etre envie de jouer sur les mots ? ). Quand je dis la vm, je parle de tout le stockage (vhd(x), les fichiers de conf, snapshots. en gros, elle apparaitra plus dans l'hyperviseur de l'hote A si jamais tu la deplace sur l'hyperviseur de l'hote B mais bien sur ce dernier.
Donc en gros, tu change l'emplacement de stockage de la vm, donc c'est bien un déplacement me semble.....

Sauf que déplacer la VM et déplacer les fichiers de la VM ce n'est pas la même chose, c'est un truc fondamental que tu n'as pas compris

"Concernant la non possibilité de mettre des appli en cluster, ca je l'avais vu oui, le SQL le faisant en SOFS non me semble ? de maniere a ce que justement plusieurs serveurs puissent écrire sur le disque en meme temps."
Attention cependant. C'et pas impossible ! C'est juste pas conseillé pour les raisons évoqués. Si tu appel MS on parlant d'un pb de base de données suite à une migration de VM ils te le ferons savoir et à juste titre.
 
"en effet, si il n'y a pas de stockage externe aux 2 hautes et qu'un tombe ce n'est pas d ela haute dispo. mais vu que le live ne permet d efaire des transfert que dans le cas d'arret planifié, le fait de passé par un san fait que c'est plus rapide ? quel est alors son avantage sinon ?"
Ben le gros avantage, c'est d'avoir de la haute dispo, de la presque vrai, avec un redémarrage automatique même si coupure. C'est déjà pas mal non ?
 
"Pourquoi est ce que le quick migration est capable de la migrer plus vite alors qu'il y a un temp d'arret car elle est mise en pause alors que le live migration ne fait que perdre 2/3 paquet icmp"
Tu penses bien que quand hyper-v doit migrer en LIVE la RAM d'un serveur en cours de fonctionnement, il doit "prendre des pincettes", pour ce faire, il va copier la ram, puis les modifs de la ram apportées pendant le transfert de la RAM d'origine par la VM. Jusqu'à ce que le delta entre la RAM de la VM et celle du serveur soit minime. Là il freeze la VM le temps de faire passer le reste de la RAM et de l'attribué sur le nouvel hôte. D'où les 2 pings perdus (chez nous on en perds pas car gros réseau sauf sur 2 ou 3 VM qui travaillent graves en RAM) qui dépendent de l'infra.
 
"quel avantage a utiliser le quick plutot que live du coup ?"
Ben aller plus vite, quand un service peut supporter la coupure (même si c'est de plus en plus rare) ... Pourquoi pas aller plus vite ? De plus, le quick migration est moins gourmands en ressources sur l'hôte ... Même si en 2014 .... C'est pas méchant.
 
"ouais donc le storage migration va faire que l'action va etre plus ou moins longue selon le lien entre les deux serveurs. en gros le livemigration c'est juste le tranfert de la ram ?"
Pour une même machine ... Si il y a storage migration surtout en PME ce sera énormément plus long.
 
"oui cluster de role ca j'avais bien compris par contre !"
Attention y a pas que des rôles qui se clusterisent. Tu as aussi des applications.
 
"'est le stockage partagé si jamais on imagine que c'est sur un 3eme serveur qui fait san virtuel, et que cet hote tombe.... catastrophe pour la boite plus rien ne tombe. donc il faut un 4eme et mettre en cluster le role isci ? ou une autre solution existe ?"
Les SAN de nos jours corrige ce SPOF (single point of failure) en multipliant les contrôleurs (au moins 2 pour de la resistance) dans le cas d'une PME ... Oui ... j'imagine que si tu passe par un serveur il faudrait mettre en place un cluster. Jamais fais.
 
Mais isci c'est une feature ... Je crois pas que ça soit clusterisable. Je verrais plus le clustering d'un rôle comme storage server ...
 
Dernier point, et non des moindres ... Stockage partagé c'est pas forcément du SAN ou du storage serveur ... Ca peut aussi être du NAS depuis windows serveur 2012, pour du cluster hyper-V ca marche. Même si jamais testé.

 
tu vas m'expliquer en quoi j'ai pas compris ?
 
donc je vais te dire ce que j'en comprends :
 
tu peux déplacer la vm sans déplacer en soit aucun fichier de ta vm. c'est l'exemple typique d'une vm stocker sur un san alors elle passe d'un serveur A a B sans qu'aucun fichier en liaison avec la vm ne soit déplacé.
 
Les fichiers de la vms, tu as le vhd qui est comme un disque dur pour notre os, donc c'est le corps du systeme, et ensuite tu as le fichier de conf qui est la configuration de ta vm, les vhd attachés, sio monté, nb de processeur, ram , carte reseau, emplacement des snapshots etc etc....
 
Right or not ?

 
"storage migration : déplacement à chaud (sans interruption) d'une VM d'un lieuA vers un lieuB alors que sous 2008r2 il fallait éteindre la VM"
Pour être précis ... Le storage migration est apparu avec windows 2K12. En 2008 R2 il fallait passer par un simple export/import et donc oui ca se faisait à froid, mais c'est pas tout à fais la même techno.
 
En 2012 il vaut mieux être en VHDX  

Concernant la non possibilité de mettre des appli en cluster, ca je l'avais vu oui, le SQL le faisant en SOFS non me semble ? de maniere a ce que justement plusieurs serveurs puissent écrire sur le disque en meme temps."
Attention cependant. C'et pas impossible ! C'est juste pas conseillé pour les raisons évoqués. Si tu appel MS on parlant d'un pb de base de données suite à une migration de VM ils te le ferons savoir et à juste titre.

Donc pour du SQL en haute dispo c'est une autre solution qu'il faut privilégier j'imagine ?

"en effet, si il n'y a pas de stockage externe aux 2 hautes et qu'un tombe ce n'est pas de la haute dispo. mais vu que le live ne permet de faire des transfert que dans le cas d'arret planifié, le fait de passé par un san fait que c'est plus rapide ? quel est alors son avantage sinon ?"
Ben le gros avantage, c'est d'avoir de la haute dispo, de la presque vrai, avec un redémarrage automatique même si coupure. C'est déjà pas mal non ?

ok donc en gros quand c'est une opération plannifié -> live migration quand c'est un serveur qui tombe c'est le mécanisme de quick migration qui est utilisé ?

"Pourquoi est ce que le quick migration est capable de la migrer plus vite alors qu'il y a un temp d'arret car elle est mise en pause alors que le live migration ne fait que perdre 2/3 paquet icmp"
Tu penses bien que quand hyper-v doit migrer en LIVE la RAM d'un serveur en cours de fonctionnement, il doit "prendre des pincettes", pour ce faire, il va copier la ram, puis les modifs de la ram apportées pendant le transfert de la RAM d'origine par la VM. Jusqu'à ce que le delta entre la RAM de la VM et celle du serveur soit minime. Là il freeze la VM le temps de faire passer le reste de la RAM et de l'attribué sur le nouvel hôte. D'où les 2 pings perdus (chez nous on en perds pas car gros réseau sauf sur 2 ou 3 VM qui travaillent graves en RAM) qui dépendent de l'infra.

ouep ok, c'est exactement ce que j'ai vu ce matin oui, l'operation de la copie de la ram iterative jusqu'a ce que le delta soit infime.

"quel avantage a utiliser le quick plutot que live du coup ?"
Ben aller plus vite, quand un service peut supporter la coupure (même si c'est de plus en plus rare) ... Pourquoi pas aller plus vite ? De plus, le quick migration est moins gourmands en ressources sur l'hôte ... Même si en 2014 .... C'est pas méchant.

Ok donc en gros si le role supporte une interruption de service on fait du quick, sinon live obligatoire. Dans le cas d'une migration planifié bien sur.

"ouais donc le storage migration va faire que l'action va etre plus ou moins longue selon le lien entre les deux serveurs. en gros le livemigration c'est juste le tranfert de la ram ?"
Pour une même machine ... Si il y a storage migration surtout en PME ce sera énormément plus long.

j'ai pas compris ta réponse sur ce point. En PME cela va etre plus long car il n'y aura pas d'infini bande c'est sur...

"oui cluster de role ca j'avais bien compris par contre !"
Attention y a pas que des rôles qui se clusterisent. Tu as aussi des applications.

oui les appli aussi en effet, dont certaines ou il faudra faire appel a la societe pour que cela soit compatible.

"'est le stockage partagé si jamais on imagine que c'est sur un 3eme serveur qui fait san virtuel, et que cet hote tombe.... catastrophe pour la boite plus rien ne tombe. donc il faut un 4eme et mettre en cluster le role isci ? ou une autre solution existe ?"
Les SAN de nos jours corrige ce SPOF (single point of failure) en multipliant les contrôleurs (au moins 2 pour de la resistance) dans le cas d'une PME ... Oui ... j'imagine que si tu passe par un serveur il faudrait mettre en place un cluster. Jamais fais.

Mais isci c'est une feature ... Je crois pas que ça soit clusterisable. Je verrais plus le clustering d'un rôle comme storage server ...

ok je vais regarder si jamais je trouve des infos sur ce point, car ca reste nettement moins cher qu'un san physique.

Dernier point, et non des moindres ... Stockage partagé c'est pas forcément du SAN ou du storage serveur ... Ca peut aussi être du NAS depuis windows serveur 2012, pour du cluster hyper-V ca marche. Même si jamais testé.

j'ai un NAS a disposition, je vais voir si eventuellement on me laisse testé

En 2012 il vaut mieux être en VHDX  
tout a fait d'accord. Apres en passant les certif, en prod il est stipulé qu'il faut utiliser du VHD. c'est plus d'actualité ? La seule grosse différence que je connais a ce sujet est qu'un vhdx est dynamique en terme de taille donc il peut aller jusqu'a 500Go par exemple mais utilisé seulement 20 a un instant T alors qu'un vhd est fixe.

Non pas du tout.

"Donc pour du SQL en haute dispo c'est une autre solution qu'il faut privilégier j'imagine ?"

Oui propre à SQL. Il y en a plusieurs fonction de l'environnement.

"ok donc en gros quand c'est une opération plannifié -> live migration quand c'est un serveur qui tombe c'est le mécanisme de quick migration qui est utilisé ?"

Pas tout à fait. Lorsqu'un hôte tombe, la machine est redémarré. Ce qui n'est pas le cas pendant un quick migration.

"j'ai pas compris ta réponse sur ce point. En PME cela va etre plus long car il n'y aura pas d'infini bande c'est sur..."

Je disais ça car les technos seront pas forcément aussi évoluée.

"tout a fait d'accord. Apres en passant les certif, en prod il est stipulé qu'il faut utiliser du VHD. c'est plus d'actualité ? La seule grosse différence que je connais a ce sujet est qu'un vhdx est dynamique en terme de taille donc il peut aller jusqu'a 500Go par exemple mais utilisé seulement 20 a un instant T alors qu'un vhd est fixe."

En passant les certifs    Attends .... Tu es certifié ????

La limite du vhdx en taille est bien bien plus importante que 500Go On parle de plusieurs Tera de données. Et le disque dynamique (qui grossi fonction de l'utilisation) ça existais déjà en VHD. Et les différences VHD VHDX ne se limitent pas à la taille.

Plus sérieusement ... Tu es entrain de passer une certification ??? Tain .... C'est pas méchant hein .... Mais t'es clairement pas prêt ... Tu débutes là ?

Tu connais pas le personnage toi . C'est un expert Xen, proxmox, esxi
 
Concernant SQL, oui c'est supporté en virtualisé sur un cluster. C'est juste que c'est un autre niveau d'abstraction.
Après en pratique on priviliégie des fermes de cluster SQL sur serveur physique pour les clients qui ont des besoins SQL. Et on "virtualise" au niveau de l'instance. C'est pas toujours possible après. Sur des plus petites structures, un serveur SQL sur un cluster Hyper-V ça fait sens, ça marche, c'est supporté (c'est ce qui est utilisé dans le cloud aussi)

Je te remercie pour les précisions sur sql jean et je n ai jamais dis que j étais expert en quoi que ce soit
Je sais juste faire des vms avec chacune de ces solutions mais je reste un admin de bas étage a qui il reste beaucoup a apprendre mais un jour viendra ou j aurai ce recul

Et oui je suis certifier mais la 70-412 ne pose pas de questions aussi techniques

En gros c était juste il y a interruption de service avec quelle méthode
Si les deux processeur de deux serveur sont différent qu'elle méthode peut être utilisé etc. Etc bref c est loin d être aussi sommaire on va dire et vu que j ai appris avec les cbt nuggets et que je suis pas bilingue j ai compris en gros mais pas tout en détail
Et la 412 a clairemet été celle ou j ai galerer au niveau de ça du dac et surtout de ad fs ou j ai toujours rien compris

Mais bref oui ce que je veux dire c est que la au moins je comprends beaucoup mieux les concept

Et pour être totalement honnête je me rends surtout compte que sur tech et je ne sais pas chercher les information.
C est un peu moins efficace que quand je cherche sur Google donc va falloir que j apprenne

Bref j ai refais un serveur de fichier en cluster avec quorum disque et aucun soucis avec 3 postes (2 hyper v et un san virtuel)
Je comprends juste pas pourquoi on dit que le quick migration est plus rapide quand je fais le test ça va plus vite avec un live qu un Quick ?

Au niveau des test :

je mets un FS en cluster entre 2 postes (avec une config différente) sur 2012 r2 et un 3eme encore avec une config différente qui sert de san.

Lorsque je mets en pause un des 2 FS le role bascule bien sur l'autre par contre, si jamais j'étais en train de faire un transfert, celui ci est interrompu.

Il me semblait que dans le cas d'un role en cluster il n'y avait aucune interruption de service et que cela était transparent pour l'utilisateur.
C'est le cas normalement ou pas ?
Si oui, d'ou peut venir mon problème ?

Merci par avance

voila ce que j'ai trouvé sur technet :
Un cluster de basculement est un groupe d'ordinateurs indépendants qui travaillent conjointement pour accroître la disponibilité des applications et des services. Les serveurs en cluster (appelés nœuds) sont connectés par des câbles physiques et par des logiciels. En cas de défaillance de l'un des nœuds, un autre prend sa place pour fournir le service (processus appelé « basculement »), garantissant ainsi des interruptions minimales de service pour les utilisateurs.

Donc j'imagine que le problème est normal?

Pourtant il me semblait que cela était transparent pour l'utilisateur et qu'il n'etait pas perturbé dans son travail

 
Tu as une entité logique qui est ta VM et est hébergée sur un hôte, et sa représentation physique qui est un ensemble de fichiers. Tu peux déplacer les deux mais il s'agit de deux opérations différentes.
 
Pour ton histoire de serveur non ce n'est pas forcément transparent, il te faut du SMB v3 et la configuration qui va bien.
 
Mais la haute disponibilité ne signifie pas forcément que toute panne ou bascule va être transparente pour l'utilisateur.
 
Pour ta certification tu as dû apprendre les dumps par coeur non ? Car là il te manque toutes les notions de base
 

lors d'un transfert, oui ca coupe.
 
Par contre un fichier ouvert, ne pose pas de problème, car les fichiers de locks sont repris par la second noeuds.
 
Donc oui ... Ca ferme une copie.

Dans les certifs il n y a pas de questions sur les bases ... Et non j ai pas appris par cœur il y a 80% des réponses que je suis capable d expliquer. C est bien pour ça que j ai pas fait 1000
Bref aujourd hui j en sais plus qu hier
Et j ai tout reste niveau live et Quick . Avec une vm debian et le live est plus rapide dans mon cas mais c est juste oarce que la vm ne faut rien donc il n y a pas de ram sollicite  sinon je vous fait confiance ce serait plus long.

Bref en tous cas je vous remercie pour toutes ces réponses

J ai de nombreuses questions comme ça sur des trucs basiques aussi faut pas croire je suis pas expert e suis débutant ....

Et en effet je suis. Accord avec toi pour le support physique de la vm et la vm
Je me suis mal exprimé mais c est bien ce que j avais compris
Je n ai pas assez détaillé le fond de ma pense et c est pour ça que du coup c est mal compris donc c est ma faute !

Au début tu mélangeais Storage migration et Live migration

TL;DR, mais je te conseil très très sérieusement si tu as de si grosses lacunes d'acheter un livre ou deux sur Hyper-V 2012R2 (éventuellement ceux proposés par les MVPs).
 
Je crois que sincèrement ce serait le meilleur point de départ que tu puisses avoir.

non, ce que j'ai mélangé c'est storage migration et réplica.
Pour moi c'etait pas un mélange en fait, je pensais juste que c'etait la meme chose comme expliqué plus haut.

Bref, au final, j'ai beaucoup appris grace a ce post donc c'est une tres bonne chose

Je parlais pas de question concernant hyper v dans ce cas la mais merci du conseil.

Pour info par exemple, j'ai été confronté a plusieurs problemes lors de mes test comme aller coché la compatibilité de processeur car c'était pas la meme génération et j'ai pas eu besoin d'internet. C'est comme tout le monde sur un sujet au pif, il y a des choses qu'on sait et d'autre qu'on apprend!

Aujourd'hui au moins je suis capable de comprendre et mettre en oeuvre des solution d'haute disponibilité de roles, de vms, et un PRA (réplica) si jamais on me pose ce genre de question. Et tout cela en moins de 24h ce qui est plutot pas mal
Demain je m'attaque juste a aller un peu plus loin sur les replicas avec un transfert en http parce que j'ai un peu la flemme de monter une PKI juste pour ca....

Autre question que je me pose : Un cluster en dehors d'un SOFS c'est un seul noeud qui est propriétaire du role. Comment font les grosses structures pour tenir 500/600 ou plus de personnes avec un seul serveur actif en temps que serveur de fichier par exemple ?
Car je connais juste le cluster avec son fonctionnement de ces 2 manières sinon c'est le NLB qui permet de répartir la charge sur plusieurs serveurs (IIS par exemple) mais on ne peut pas cumuler les deux....

Donc quelle est la solution lorsqu'on utilise un cluster "simple" avec un seul noeud propriétaire donc ?
et lorsqu'on fait du SOFS comment cela marche t'il ? on fait du round robin ou quelque chose de plus intélligent a été inventé ?

Merci par avance encore une fois !