Reprise du message précédent :
Chez HP/Dell/Futji/IBM and co tu as des programmes Fast track cloud start tu pourrais regarder.

je vais jeter un oeil
merci

Alors. Voilà l'idée du truc :
 

 
Pour le premier devis je pars sur 3 serveurs de marque DELL R620 :
- Bi proc E5-2630
- 8*8Gb de ram à 1333Mhz (64Bg)
- 2 disques SAS 15K en raid 1 (300 Go pour avoir de la marge)
- 8 Cartes réseaux à 1Gb (4 intégrées et une extension ed 4 ports)
 
Pour les switchs, je m'orienterais sur des cisco 3750X 24 ports avec une carte 2 ou 4 ports (a voir selon cout/envie d'évolution) à 10 Gb à connecteur SFP+.
 
Pour le SAN, une equalogic PS4110XV (2 controleurs actif/passif à connecteur SFP+) équipée de 24 disques SAS 300Gb 15K (avec 2 disque de spare et un raid 50 à deux grappes je devrais avoir 6To utiles).
 
Le câblage entre le SAN et les switchs sera en twinax.

Question à la con, si ton coeur de réseau de droite tombe, tu n'as plus de livemigration ?

Si. LiveMigration peut utiliser un réseau définit en priorité, et en cas de panne, en utiliser un autre.
 
Comme pour chacun des réseaux du cluster
 
(Je précise que je prend une intervention à 4 heures sur le réseau et le SAN, et à J+1 sur les serveurs)
 
edit : Donc si mon réseau de droite tombe, je suis en mode dégradé pour 4 heures. C'est un risque que je peux largement prendre.

En fait c'est surtout sur le plan d'adressage du ISCSI que je me pose des qestions
 
Je m'explique. J'ai deux controleurs actif/passif sur le SAN et 1 carte réseau (en tous cas sfp+ ... de mémoire j'ai aussi un port 10GB base T dessus). Mon but n'est pas d'utiliser "bêtement" la moitié de l'armoire (immaginons coté droit) pour le réseau de stockage en insérant 2 plans d'adressages différents. En effet, tant qu'à multiplier les cartes je préfèrerais que les serveurs les utilisent toutes.
 
Edit : et pour info le 10 gb coute environ 15 a 20% plus chère suivant les devis

J'comprends pas pourquoi tu parles de teaming, vlan et adresses IP sur un SAN ? Spa du FC ?

equallogic est un SAN avec uniquement le protocole iSCSI en front-end

Mais heu attends tu choques mes convictions là. Une baie de disques attachée au réseau, st'un NAS, pas un SAN ?

NAS = stockage en réseau
SAN = réseau de stockage
 
Le NAS permet d'apporter du service de stockage sur un réseau existant, comme par exemple un serveur de fichiers. On simplifie la chose en appelant cela du stockage en mode fichier
 
Le SAN nécessite très souvent un réseau dédié pour apporter ce même service de stockage, mais souvent en mode bloc (schématiquement appelé stockage en mode bloc)
 
Du coup pour l'histoire du SAN en FC, ce n'est ni plus ni moins que des commandes SCSI (protocole utilisé pour dialoguer avec des disques) transporté en FC
 
Mais vu qu'une infrastructure fibre est (très) chère, le protocole iSCSI est une bonne alternative au FC : on encapsule du SCSI dans du TCP/IP
Du coup tu peux te monter une infra moins onéreuse (avec des switches réseau existant ou des switches dédiés) et facile à administrer qui peut parfaitement convenir à tes besoins par rapport à de la fibre

En gros, ce qui fait que ton synologie est un NAS par éxemple, c'est la méthode de transport de l'info et la couche logicier d'accès
 
Typiquement je pourrais avoir une baie de stockage, connecter en SAN (FC, ISCSI ou SAS) à un serveur.
 
Après pour les clients, tu pourrais avoir une appli sur ce serveur qui ferait que les client verrait cette infra comme un gros NAS (typiquement si tu installer une des nombreuse distribs te permettant de monter un NAS personnel)

Voila. Mon infra est installée et je commence à déployer mes VM.
 
J'ai donc choisis :
3 DELL PowerEdge R620 avec 8 connections Réseaux en Gb
2 Switchs Cisco 3750X avec 24 ports GB + 2 ports 10Gb vers SAN.
1 SAN equalogic PS 4110XV
 
La conf c'est bien passé, mais je pense que j'ai encore un peu de tunning à réaliser, car les perfs niveau connexion au SAN Semble assez longues.
 
J'ai l'impression que toutes les connexions sont redirigées par le OWNER du CSV dans le cluster.
 
Donc forcément, il fait tout le travail avec ses 4 connexions au SAN.

effectivement, dans la console du san, sur les 3 serveurs en cluster, je vois que c'est toujours le même qui écrit
 
Ca rame fort !

La meilleure chose à faire est de vérifier avec iometer les perfs de ton stockage . Pendant le temps d’exécution vérifie le trafic sur les commutateurs
Avant de mettre la production direct dessus mieux vaut tester les capacités de son infra .
Tes VMs sont tous sur un seul hôte ? Même CSV ?
++

non elles sont sur tous les hotes mais sur le même CSV.
 
je vais lancer iometer pour voire.
 
Effectivement je suis encore en test ... je ne passe pas en prod de suite

Bon... En fait, j'ai l'impression que nous sommes en redirigé.
 
Propriétaire du CSV : HYPV-03
Serveur qui héberge la VM : HYPV-02
 
Et bien quand l'ordre de création du VHD arrive, celà passe par la carte LAN CSV de hypv-02 vers hypv-03, puis ce dernier écrit sur le SAN depuis ses cartes réseaux dédiées.

C'est bon j'ai trouvé ...
 
en fait, lors du provisionning de machine, le serveur propriétaire du stockage reçoit bien les info du serveur hébergeant la VM en cours de création par le biais du réseau de CSV. Car lors de la création, le serveur hote de la VM ne peut pas attaquer directement le stockage, il passe par un mini driver au dessus de SMB2 qui lui fait croire qu'il attaque le serveur, alors qu'en fait pas du tout.
 
Une fois en prod, le serveur qui héberge la VM est capable de locker les fichiers de conf et de disque de la VM, et là de l'attaquer directement.
 
Premier point qui semble pour moi être toujours à l'avantage de VMWARE.
 
Enfin, si je ne me trompe pas ...

Ton projet ouf (pour moi) m’intéresse

Hello Demes.
 
Et bien j'essaie d'avancer un peu (entre 2 projets). Pour l'instant, mon seul "regret" c'est d'avoir un poil sous estimé les débit du réseau CSV du coup la création d'un disque volumineux est plus pratique (rapide) à faire sur le Nœud propriétaire du volume CSV.
 
Enfin d'après ce que j'ai lu, cela sera corrigé en hyperV3.
 
Je vais essayer de prendre le temps de détailler et mettre une ou deux photos de l'installation.
 
Juste pour info en therme de perf :
- SAN : Lorsque je tape le SAN en direct I/O je sors à peu près du 500 - 550 Mo secondes en écriture d'un gros fichier (VHD)
 
- Proc : Rien à redire pour le moment, à voir pendant monté en charge.
 
- Idrac 7 : Ces puces de nouvelles générations sont vraiment top !
 
Seul regrêt donc, le réseau de CSV, que j'aurais peut être inscrit en 10 GB (après c'est aussi une question de cout) ou en double attachement mini (utile pour la création de VM et pendant le BACKUP via VSS D'une machine ... Encore une fois sous hyperV2)

Faut dire que ça change encore pas mal les archis avec Hyperv 3 mais je dirai que c'est pas idiot aujourd'hui de prévoir une archi v3

Ben pour l'instant j'ai lu que pour la sauvegarde (utilisant VSS) les ios ne seraient pas redirigés ... Mais à la création d'une machine je ne sais pas ...
 
Ce qui est con, c'est pour orchestrator .... Si il faut privilégié un hôte plutôt qu'un autre pour la création de machine ... Ca complexifie un peu le truc.
 
Dés que j'ai deux machines dispos sous la main je test hyperv

Si tu dois privilégier un hôte plutôt que'un autre, c'est que t'as pas saisi l'intérêt de ce que tu mets en place ...

Salut,

Ca me parait louche ton histoire de redirection constant... C'est pas compliqué, si tu es en mode redirigé (le trafic passe par le réseau CSV) il est noté sur tes disques CSV dans la console gestionnaire de cluster de basculement (la flèche sera orange), et ce n'est pas normal !

Il y à peu de raisons pour lesquel le CSV se met en mode redirigé :
1- Tu effectue une sauvegarde de ta VM (hors VSS Hardware)
2- Un de tes liens (fibre ou cuivre dans ton cas) entre le noeud hébergeant la VM et le SAN est cassé
Ou après tu peux le forcer mais je vois pas l'intérêt...

Pour rappel, le noeud coordinateur du CSV est celui qui gère la structure des fichiers (impact réseau ultra faible), l'écriture à proprement parler du contenu du fichier est effectuée directement entre l'hôte hébergeant ta VM et ton SAN. Encore une fois, si ce n'est pas le cas il y à un problème grave dans ton infra !

J'ai mis en place une archi similaire à  noeud, et les seules fois où j'étais en redirigé c'était pendant les sauvegardes.

Si si j'ai bien compris. Je parle de la création de gros fichiers VHD ... En résumé :
 
A la création d'un disque virtuel (VHD) seul le nœud propriétaire du disque peut taper le disque en direct I/O. Donc lui passe par ses 4 brins gigabit. Si je créé le VHD depuis une machine non propriétaire du volume partagé, alors celle-ci doit passer par le propriétaire (donc réseaux CSV à 1 gb) pour créer le fichier.
 
Et pour info, ce que j'ai écris plus haut, c'est le fonctionnement normal d'hyperv.  
 
Après une fois la machine créée et lancée, l'hôte qui héberge la machine (propriétaire ou non du stockage), tape le stockage en direct sur le réseau dédié ISCSI. Donc pas de soucis de perf en fonctionnement, mais la création de la machine, si elle n'est pas un minima préparée, sera plus longue sur ce nœud non coordinateur.
 

Ben écoutes ... Même mon ingé MS dit que à la CREATION du vhd, cela passe par le Coordinateur, car c'est une création.
 
Bien entendu si l'infra tournait en redirection constante ... J'aurais remarqué un soucis   Mais je n'ai pas de soucis en fonctionnement, juste en création
 
Par contre si tu n'as pas eu le soucis ... C'est peut être parce-que tu as paramétré ton réseau de CSV sur ton réseau ISCSI ... Ou encore que tous tes brins sont à la même vitesse (1 - 10 Gb) du coup tu ne vois pas la différence. Mais je peux te garantir que la création du VHD se fait par le coordinateur.

Bonjour,
 
OK autant pour moi j'avais compris que tu était tout le temps en mode redirigé (ouf ^^)
Honnêtement, je ne me suis jamais posé la question mais ça parait logique que la création du VHD passe par le noeud coordinateur, mais quand tu dis créer c'est parce que tu crée des VHD de taille fixe ?
 
J'avais jamais à me poser la question parce que j'utilisais des templates avec SCVMM 2008 R2 et j'avais pas d'attachement au SAN depuis cette machine, donc ça passé par le réseau (à 1 Gbit)
 
Sinon le reste du temps j'étais en dynamique donc le VHD se créait en quelques secondes.

Désolé du retard
 
Oui je travail en vhd de taille fixe, notamment à cause du nombre de sql serveur qui ne supporte pas bien les VHD dynamique

Ça fais un peu déterrage ... Mais comme je viens de réinstaller ce cluster (cette fois ci en mode core ... Il a fallu être persuasif envers l'équipe) j'en ai profité pour écrire une doc que je vais mettre à dispo ici. L'infra est très très stable ... Peut être même trop car j'ai jamais à y mettre les mains

Prochainement, je devrais migrer cette infra en 2012 R2 et également nos infras de prod, preprod et PRA ce qui me permettra de mettre des docs qui pourront servir à d'autres ... Je compte la compléter par le paramétrage du BROKER REPLICA et du CAU (cluster Aware Updating) ... Mais on va déjà les laisser digérer tout ça.

Petit rappel de l'infra :
3 serveurs Hyper-v connectés à un SAN EQUALOGIC au travers de switchs cisco 3750X.

Tout est en Gb/s

Liens vers la procédure : https://onedrive.live.com/redir?res [...] ile%2cdocx

PS : Toutes remarques constructives sont les bienvenues

Aucune remarque constructive pour ma part, juste un "j'aime"
Je vais lire ta doc avec intérêt

Merci pour le partage    
 
Je vais lire ça avec intérêt aussi.

Je viens de me rendre compte que toute la partie Clustering avait sautée ...  Bosser tard c'est mal, faut toute que je me la retape.

Au boulot !