Bonjour.
 
Ca y est on y va ... Je dois préparer une infra sous cluster hyperv pour la société dans laquelle je travail, et j'ai grand besoin d'aide Je n'ai pas touché au HARD depuis un petit moment, et j'avoue que je n'aime pas me faire dicter une solution par un fournisseurs (même si je les rencontres régulièrement pour des "refresh" sur les technologies)
 
12/04/2012 : Création du Post
13/04/2012 : Ajout des rubriques CPU-Mémoire-Stockage & LAN
 
Context du Projet
L'idée est de créer une infra totalement indépendante (niveau hardware (pas de cpu, disk ou autre partagé), mais sur le même LAN) pour accueillir la nouvelle version system center que nous utiliserons les 4 a 5 prochaines années.
 
Sizing Logiciel
 
Le sizing a donc été réalisé en partenariat avec Microsoft (We are TAP) sur l'éxistant, le futur en prenant en compte les objectifs de la société à horizon 2015 sur le plan business et recrutement.
 
Actuellement nous utilisons les briques suivantes parmis toute la flotte System center :
- Configuration Manager (SCCM) : push d'appli, d'image sur poste/serveur
- Opération Manager (SCOM) : alertes et de monitoring
- Service Manager (SCSM) : Gestion ITIL and reporting
 
Demain, nous utiliserons en plus :
- Orchestrator (SCO) : Workflow de configuration
- Virtual Machine anager (SCVMM) : Gestion du cluster
 
Infrastructure Actuelle
Ajourd'hui, toute la game tourne sous 6 serveurs pysiques qui ont en tout (mutualisé):
 
Processors :

 
Memories :

 
J'ai collecté pendant un temps (2 Semaines). Et je constate que les préco microsofts sont, pour le moins ... Ambitieuses ...
 
Nouvelle infrastructure
 
Il me faut donc une infra me permettant d'habriter maintenant non plus 6 mais 25 machines. D'où le choix de la virtualisation.
 
Mais voila ... Pour des raison de performance, il va me falloir des serveurs avec du direct attachement pour les disque abritants des DB (Exit Live migration donc Pas grave je trouverais un astuce pour la rendre plus Haute dispo (clustering SQL sur des barres métals ou sur un hyperviseur dédié ... On verra)
 
Voici donc les informations de sizing de la nouvelle infra pour les besoin logiciels
 

 
Donc il me faut une infra avec 72 VCPU, 208Gb de ram. Pour ça le sizing, je m'en sors, comme je connais l'utilisation actuel j'applique un ratio et un % d'évolution sur le CPU pour l'overcommitment, pour la ram, j'applique un % sur le total afin de gérer la perte d'un host (encore une fois pas de Live migration ... A la mano pour le moment)
 
Mes idées actuelles :
 
Ce qu'il faut savoir, c'est que ce projet est la première brique d'une refonte en profondeur de notre DATACENTER et de notre WAN. Jusqu'ici, nous avions une infra serveur en physique sans hyperviseur. Je suis entré dans la société il y a 3 mois afin de palier à un petit retard technologique, que la DSI souhaitait rattraper, trouvant un intérêt majeur à la Virtualisation.
 
Les serveurs
 
Pour cette infra, qui se veut séparé du reste des serveurs, je ne vois pas la nécessité d'un chassis capable d'héberger 8 lames ou plus pour seulement 4 Hosts. Je voyais plus un cluster de 4 Stands-alones avec 2 disques (flash, ssd, usb) en DAS pour héberger l'hyperviseur.
 
Mémoire
 
Pour la mémoire (en quantité), je partirais sur un calcul de la sorte :
 
(Mémoire_nécessaire_globale / (Nombre_host -1)) +10% du résultat = Mémoire_par_serveur(arrondi)  
Si je réduis le nombre d'host de 1, c'est parceque je souhaite que mon infra puisse perdre au moins un host (même si avec les DRS (je connais pas encore le nom de cette techno sous hyperv) je pourrais parvenir à sauver la prod sur 2 en ne redémarrant pas forcément certaines machines).
 
Donc :
 
(208/3)+10%=76 (comme je suis prudant ... Ce sera 96Go ... Ben oui ! 4 ANS !)
 
La mémoire devrait être sous la norme des 1333Mhz.
 
CPU
 
Bon là dessus, je pense partir sur du sandy bridge ... J'en saurais plus dans la journée
 
Stockage et réseau
 
Certain vont crier au loup !!!! Mais je compte bien mettre la question du stockage et celle du réseau sur le même chapitre. Et c'est mon chapitre Clé !
 
Stockage
 
Nous parlons ici d'un SAN capable de fournir du MPIO pour l'infra et du direct attachement aux VM. Pour les besoins de IOS de la baie, je partirais sur des disque en SAS 10K ou 15K avec un nombre de bras suffisant (première estimation à 24 si bon disques capables de sortir unitairement 160 io/s)
 
Le FC : semble hors de propos. L'infra sera empilée, donc avec des distances courtes. Le rapport PRIX/Perf semble ne pas forcément en sa faveur. Qui plus est, du fait d'un média particulier, niveau réseau, celà pourrait compliquer l'urbanisation.
 
Le ISCI : J'ai encore trop peu d'informations sur le sujet, je suis preneur de toutes vos remarques.
 
Le SAS : Première solution abordée par un fournisseur (HP). Le seul problème que je luis vois, c'est de ne pas être facilement extensible. En se sens qu'avec un SAN à 8 controleur, pour le double attachement, l'ajout d'un switch SAS devrait se faire si nous souhaitions rajouter des hosts ... Hors nous retomberions dans le problème de la techno FC ... Même si à moindre coup j'imagine.
 
Réseau
 
Le réseau LAN du datacenter va être entièrement revue dans quelques mois ... Pour le moment, je n'aurais pas les moyens techniques de faire du double attachement sur le coeur de réseau, même si le nombre de carte sera bien prévu pour celà.
Nous prévoyons de passer notre DATACENTER En 10 Gb/s, ce qui nous donneras l'occasiond e faire un upgrade RESEAU de cette infra en temps et en heure.
 
Même si j'avoue que monter un cluster avec du simple attachement sur le coeur de réseau est une érésie, il n'est réellement que temporaire. Et ne touchera pas la prod du métier, mais seulement celle de System Center    
 
QUESTIONS :
 
1 - Quelqu'un aurait-il un site démontrant les apport du SAS, ISCI ou FC pour joindre le stockage partagé ?

Juste pour infos tu comtes gérer combien de clients/serveurs avec tout ça ? Parce que ça me semble être pour des grosses infra ça déjà.
 
Après c'est pas un cluster hyper-v vu que tu as pas de stockage partagé. C'est juste 4 serveurs indépendants.

Si tu parles de tap, tu pars sur hyperv r3???
Je suis d'accord avec jeanb pourquoi pas de stockage partage. Vu le prix global de l'infra que tu montés, ce serait con de s'en passer.
Ou alors tu vas configurer des replicas et tu penses que ça fera l'affaire ?

Et pour finir, ne remet pas à plus tard l'installation de scvmm, c'est vraiment un plus dans une infra hyperv

Personnellement je suis TAP Windows. Là, c'est une personne du service helpdesk qui est TAP System center Et nous avons déjà une plateforme System center tournant sur windows 8, donc hyperv 3, mais elle n'est pas en prod, juste en test
 
Bien entendu puisque je parle de cluster, il y a un SAN de prévu à l'infra (d'où la première question sur le SAS, FC ou ISCSI ) Mais c'est un des points sombres de mes connaissances ... Travaillant chez les clients finaux, la dernière infra que j'ai eu l'occasion de construire était en FC, choix qui ne semble pas le plus opportun suivant mes premières lectures.
 
SCVMM sera installé de suite bien sur Orchestrator le sera plus tard
 

C'est là que le bas blaisse ... Nous comptons aujourd'hui 1400 Machines clientes et environ 100 Serveurs ... Après, les objectifs de la société sont de multiplier le nombre de collaborateur par 2 d'ici 2015. Soit 2800. En tenant compte que sous 3 ans nous aurons donc plus d'utilisateurs, plus de serveurs et surtout du fait que cette infra est construite pour 4 a 5 ans ... Ca donne un besoin. Après les précos microsoft sont monstrueuses ... (j'adore monter des serveur pour des DB de 10 Go !) mais forcément, ils prenent encore par dessus les calculs, une marge énorme
 
Et stockage partagé il y aura bien entendu, mais comme les DB sont sur des disques physiques (des luns sur le SAN ! Je ne veux pas de disque DATA sur les barres métals) le live migration ne servira dans un premier temps, pas à grand chose, car même si un des serveurs peut bouger ... Le serveur avec la base de donnée et sa lun attaché lui, ne pourra pas l'être dynamiquement. (je cherche une solution à base de script, mais franchement cela me parait un peu bidouille ... Je pense que pour palier à ce problème, je passerais par des cluster SQL dont un membre sera hors infra hyperv)

SAS, FC ou ISCSI
comparer SAS et FC, ISCSI je vois pas le rapport !
2 sont des protocoles et l'autres une connectique de disque.

Tu as des SAN que tu peux parfaitement attacher en SAS sur tes HOSTS à la mannière d'un ISCSI ou FC
 
FC est également une techno d'attachement de disque  
 
Info sur le petit P2000 D'HP en SAS : http://jpaul.me/?p=1709

pour éviter les erreurs, je préfère parler de front-end (ce que tu présentes à l'extérieur de la baie, donc tes serveurs) et back-end (câblage interne à la baie)
Et effectivement il est possible de mettre du SAS en front-end, même si ce n'est pas une chose courante
On voit généralement du SAS en back-end, et du FC ou iSCSI en front-end

si tu attaches en sas, c'est pas un SAN, c'est une baie:
disk != baie != san, il faut pas tout mélanger.
Quand tu achetes une boite avec 10 disques dedans, tu achetes pas un SAN contrairement a ce que beaucoup aimeraient penser.
ton histoire de sql et de lun mappé tout ca ... rien compris, et je penses que tu as pas tout compris non plus.
Revois BIEN le concepts de SAN, de Lun, de zoning et autres wwpn. Parce que là, je crois que tu fais pas mal de confusions qui vont malheureusement te conduire à un design bancal(dans ton projet, le type de disque devrait vraiment etre le cadet de tes soucis).

Je ne suis pas un spécisaliste SAN ... Comme je le dis dans le poste d'origine ...
 
Mais pour moi un SAN, c'est une unité de stockage que l'on peut partager entre plusieurs équipements sur un réseau dédié sur lequel trafic du bas niveau. Donc, à ce stade, pour moi, une unité de stockage en SAS sur 4 HOST (auquel tu peux adjoindre un switch) c'est une baie de disque, que l'on utilise en mode SAN. Après je suis prêt à le revoir, si argumentation plosible
 

Si si je comprends bien Mais je peux réexpliquer si je n'ai pas été clair ... Enfin apès y a aussi une façon de le demander
Les VM hébergeant des bases SQL devront avoir des lecteur qui eux ne seront pas virtualisé (en gros le lecteur D ne sera pas un .vhd, mais une lun d'une baie/SAN (puisque tu y tiens)). On appel celà du direct attachement, concept qui conciste à attacher un disque physique (ou une lun d'un SAN/BAIE) à une machine virtuel.
 

Pour cracher 3790 iops, je ne pense pas que le disque soit le cadet de mes soucis   EDIT : Je dirais même que le stockage est le centre même de l'infra ... d'où ma prudence vue le retard que j'accuse dans les techno de stockage déporté.
 
Enfin, merci, si tu souhaites participer à ce post, ce que j'apprécie grandement car si je suis là c'est, comme dis dans mon post, me rafraichir la mémoire, d'utiliser un minimum de formule de courtoisie, et d'être un minimum sympa

  Effectivement, front-end et back-end me semble être un bon principe de nommage !
 
En l'occurence, je souhaiterais utiliser en back-end une techno SAS (raison de cout) et en front-end, aujourd'hui je plenche entre du SAS et du ISCSI.

Tu peux bien évidemment migrer des VM même si tu attaches directement tes LUNS aux VM en passthrough. Par contre tu auras un plus gros lag voir des décos clients le temps que le LUN se démonte de l'host 1 pour se monter sur l'host 2.
 
Perso je trouve ça vraiment overkill ton infra pour le nb de client que tu auras (ainsi que dans 4/5 ans).
 
Par exemple :
- Intéret d'un CAS dans ton cas ? Pour une potentielle évolutivité ?
- Pourquoi avoir 10 serveurs SQL ? Mutualise ça (pour certains) avec le produit ou fais toi un cluster SQL multi instances
- Intéret de 3 Management server SCOM pour gérer 100 serveurs ?
- Mutualise les web services IIS de SCORCH sur le management server ou les runbook servers
- Pareil ton infra SCSM pour gérer même 5000 machines ça me semble vraiment overkill.

Mais le unmount/mount de la Lun peut être automatisée par SCVMM ? Ou par un moyen plus transverse genre script ou autre ?
 

Je trouve aussi. Maintenant, je monte l'infra proposée par MS, dans les règles, quand la DSI verra le coup de l'infra, elle m'écoutera peut être un peu plus Si non, j'aurais un beau joujou.
 
Edit : Pour moi on a 2 fois trop de ressources dans cette infra.
 

En résumé, comme je le dis dans le post principal :
J'ai collecté pendant un temps (2 Semaines). Et je constate que les préco microsofts sont, pour le moins ... Ambitieuses ...
Je tente de faire comprendre à la personne TAP chez nous (elle dit amen a toute préco microsoft) qu'avec cette infra, la solution System center va représenter 25% de nos serveurs ... Et pour m'aider, je compte sur la DSI pour tenir ses responsabilités via un budget qui va, je pense, en choquer plus d'un.
 
Je tiens quand même à bien chiffrer le projet et de façon optimale, pour pas que l'on puisse me reprocher de gonfler la note
 
Et si celà ne les choques pas ... Et bien j'aurais un beau projet dans les main et du matos de dingues.
 
Après, là où je veux consolider les ressources, c'est au niveau processeur, car il faut savoir que sur les 42 coeurs présent aujourd'hui, ils sont chargés à 95% du temps à hauteur de 13% de charge ... Déjà qu'ils dorment aujourd'hui ... Imagines demain

Je précise !!!! Si quelqu'un utilise System Center sur un large réseau, j'apprécierais beaucoup qu'il me donne des chiffres sur son infra ! Que je puisse aussi m'appuyer sur un exemple concret pour leur faire comprendre

25 serveurs, 72 VCPU, 208Gb de ram, juste pour la partie serveurs de gestion microsoft destinée à gérer 4000 users et 200 serveurs à terme ?
C'est moi ou c'est  

Avec ton infra je ferais tourner au moins 10 à 20 fois plus de clients et serveurs.
 
C'est quoi leurs arguments parce que bon là ça fait peur
 

C'est juste 25% de nos serveur aujourd'hui, et peut être 12% demain    Comme j'ai dis à la miss TAP SC, microsoft prend ceinture, bretelles et pantalon en fer pour se prénumir de tout mécontentement ... Mais c'est le portefeuille de la boite qui rac Mais bon ... Comme elle n'est pas branchée infra du tout ... Elle ne se rends pas compte.
 
Je suis dans la boite depuis 3 mois, elle boss avec ms depuis des années ... La confiance pour le moment est à MS Ca je comprends.
 

Ils n'en ont pas apparement (en tous cas ils ne sont pas arrivés jusque moi). Ils se cachent derrière des préconisations
 
Après l'utilisation de system center qu'en a l'équipe qui s'en charge est certainement poussée. J'en conviens. Mais une question à laquelle personne n'a su me répondre ....
 
"Qui se charge de la maintenance des bases de données actuelles ?". Je suspect qu'ils aient une vision sur la gourmandise de l'infra, basé sur l'infra actuelle. Hors l'infra d'aujourd'hui semble effectivement bien chargée. MAIS ! Je pense aussi que personne ne s'occupe de son optimisation ... Je parle SQL, et personne ne tic ... Un SQL non maintenu voit ses perf descendre en flèche. J'ai pas encore parlé d'opti sur l'os ou sur les tâches. Juste du SQL  

Les précos sont pas du tout ça en tout cas si tu regardes les guides de sizing sur technet

Ah merci j'avais pas pensé a Technet !!!!!!!!!!!
Mais bon je vois déjà son argument
 
"Oui mais nous on l'utilise à fond" ... Ben forcément elle va pas dire le contraire
 
Mais quand même je vais jeter un oeil
 
Edit : Magnifique !!!!!
 
http://technet.microsoft.com/en-us [...] 19601.aspx
 
However, if you plan to add additional supported computers in the Service Manager database, you should plan to increase the amount of RAM for the Service Manager database server beyond the minimum requirements listed in this document. For example, in the baseline test 8 GB of RAM was installed in the Service Manager database server that contained records for 20,000 computers. Afterward, you should add 8 GB of RAM for each increment of 10,000 of computers that you plan to support. For example, for 50,000 computers plan for 32 GB of RAM. During testing of the 50,000-computer configuration with 32 GB of RAM installed on the computer running SQL Server, performance was improved to a state where there was no longer any decreased effect compared to testing of the configuration before additional computers were added.
 
Donc pour SCSM, ils me demandent : 16+8+8=32G de mémoire pour les bases ... soit ... L'équivalent de 50.000 users/machines.
 
Congrat jeanb ! 10 fois à peu près ce que nous devrions être dans 4 ans !

Faut pas présenter ça comme ça, plutôt comme une augmentation de 800% de l'infra de management pour une augmentation de 100% maxi de votre infra à gérer.
Et là, soit tu tiques, soit t'en as rien à foutre de combien ça coûte (et là tant mieux pour Microsoft après tout hein).

 
Euh dans ton calcul, c'est que la DB de service manager (CMDB), pas la DW/DM.
Mais si tu regardes tu prends l'infra à 2 serveurs de SCSM tu rentres largement dans le scope.

Effectivement    
 
Pour le scope je me fais pas de soucis. Je reste quand même à me dire que l'optimisation devrait nous permettre de toute remettre à plat

Bon sortons du concept "en ai-je vraiment besoin ?" ... Ca me rend dingue.
 
Si nous restons sur cette infra, j'hésite donc entre l'iSCI et le SAS en front-end.
 
Si on devait donner les avantages sous forme d'un tableau :
 
Evolutivité :
Vitesse :
Distance possible :
 
Je suis à l'écoute de toute autre donnée importante à prendre en compte !

Prends le plus cher prévu pour 10 fois plus grand, comme le reste  

 ok ! (joke)

Pour avoir mis en place des infra utilisant ISCSI ou SAS en front , seul l'évolutivité prévue t'arrêtera sur l'un ou l'autre .
Pour les performances une baie 24 disques 15k fera largement l'affaire pour ceux que tu prévois d'héberger c'est même assez large .

Si ton choix se porte sur l'ISCSI, il ne faudra pas négliger les commutateurs qui se chargeront du traffic host<---->san , vérifie bien que les ports des commutateurs peuvent supportés jumbo frame et flow control en simultané, le buffer doit être assez important , quitte à demander au constructeur directement le buffer/port. On trouve de tout ...
Vérifie aussi le support du TOE et ISCSI offload en hardware sur les hôtes.
Vérifie que la baie supporte de l'active/active si tu comptes mettre en place du Multipath.
En gros ça demande un investissement en temps et des compétences supplémentaires pour mettre en place l'infra iscsi.

Pour le SAS au final, il y a moins à s'inquiéter sur la connectivité à mettre en place et tu sais à quoi t'attendre au niveau des perfs, meilleure latence , meilleure bande passante. C'est l'avantage aussi .

Pour ma part nous avons mis SCOM, SCCM et SCSM avec 5 vm sur un ESX :
- 1 SQL Serveur
- 1 SCCM
- 1 SCSM
- 1 SCSM DW
- 1 SCOM
 
Le tout avec 40 Go de RAM.
Pour l'instant nous n'avons que SCCM en production, SCSM est en cour de config et d'optimisation, SCOM est repoussé à la 2ème moitié de l'année (car en ce moment on bascule les postes en W7 avec Office, packaging de certaine appli en Appv, on met en place Sharepoint, et en automatise la gestion des comptes AD avec la base de données des RH)
 
On a 350 Postes sur une forêt à 4 domaines (à cause de contrainte légale) et une filliale sur une forêt à part.
 
Un seul gros regret sur la partie infra d'avoir mis un serveur SQL dédié. Nous devons de temps en temps tout redémarrer a cause de SCSM qui s'il malgré qu'il ne soit pas en exploitation consomme et ralenti beaucoup. C'est peut-être config mal optimisé qui en est à l'origine, mais bon les choses viendront plus tard.
 
 
Au niveau du stockage on est sur du FC (on a réutilisé notre baie EMC deja existante)
 
Je confirme que technet permet de mieux dimensionner les éléments, je l'ai utilisé comme source d'info pour SC et SharePoint.

  Merci énormément pour ce retour. Mon week end studieux m'a incité dans cette façon de voire la chose, ta confirmation est la bienvenue.
 
Effectivement, cette infra n'a pas réellement vocation à "gonfléée", mais conjointement, il y a un autre projet qui verra bientôt le jour, celui de la refonte global de l'infra serveur. C'est pourquoi, je me demande si capitaliser sur le ISCSI un peu en avance ne serait pas un point positif.
 
Je vais commencer à pouvoir me renseigner. Merci
 

Ouep Consolider toutes les bases sur un seul serveur, dans notre infra, me semble un peu risqué
 
Ce que je trouve cependant dommage, c'est que là avec la propal MS, on ne consolide plus rien Un SQL par soft (SCCM, SCSM, ORCHESTRATOR, SCOM ...) m'aurait semblé plus réaliste. Mais bon ... Après tout ce n'est pas mon argent
 
Merci pour ton retour d'expérience. Je vais commencer à me renseigner sur le ISCSI et je pense ce soir pouvoir revenir avec une propale d'infra
 
Merci pour votre aide.

moi j'aurai tendance à dire de privilégier une infra qui va évoluer : quand on commence à entrevoir les gains de la virtualisation, d'un coup toute l'infra se fait rapidement virtualisée
 
Essaie d'avoir pour cible un nombre d'hôtes physiques qui hébergera tout ton datacenter + les projets qui arriveront dans les 3 ans à venir

Le reste de l'infra datacenter sera physiquement séparée Elle représentera certainement un nombre d'hote plus important.
 
Cette infra est aussi pour nous l'occasion de mettre à l'épreuve des constructeurs\solutions, car elle reste moins critique que l'infra métier (même si nous préfèrerions qu'elle tourne).

Ok aujourd'hui j'ai le temps de plancher un peu ...
 
Question ! Un stockage rapide (type SSD) sur les hôtes est-il un point important à prendre en compte ? Permettra-t-il un accès plus rapide des Systems Virtualisés à leur VHD ?

petite idée d'infra sur le réseau de stockage.
 
Nous avons décidé de partir sur un réseau de stockage ISCSI. 10 Gb/s me semblant un peu démesuré pour cette infra, je pensais réaliser quelque chose de ce style :
 

 
Avec donc par serveur 4 ports Gb/s en direction de switchs, qui eux même serait lié par un trunk à chaque contrôleur du SAN en 10 Gb/S, pour éviter d'éventuels congestion sur le lien controleur <----> Switchs
 
Ce système aurait pour avantage d'est évolutif de façon granulaire, même si en terme d'urbanisation celà complique un peu l'affaire.
 
Celà vous semble-t-il une bonne idée ?
 
Avez vous des remarques ?
 
Même si celà reste déconseillé apparement (de ce que j'ai pu lire) connecteriez vous vos réseau de Live migration, CSV ou heartbit sur les switchs, en les isolants dans des VLANs ? c'est quand même bête de pas pouvoir consolider son réseau

il n'y a pas de réseau de Live Migration ni de réseau CSV
Pour le heartbeat il est conseillé de l'isoler dans un VLAN, surtout que c'est par ce lien que transite les Live Migration et Storage Migration (encore un truc super bien fait)

Euh perso j'éviterai de tout mettre (heartbeat/live migration/csv) sur la même carte.
Fais une carte CSV/heartbeat, une carte live migration, une carte management, une carte mini pour les VM (2 c'est mieux).

Dédier un réseau au CSV celà se fait, et encore heureux
Storage migration ne sera pas utilisé, tout du moins pour le moment.

Ah mais je me suis mal exprimé ! Ceci est le réseau de stockage !!!! tout ne transite pas uici.
 
Je ne veux pas consolider les réseaux sur le serveur. Mais utiliser les switch ISCSI en créant des Vlans pour y connecter le réseau SAN, le réseau LAN, le réseaut de CSV/HEARTBIT et le réseau Live migration.
 
Apres sur un serveur là tel que je le vois je verrais bien 8 cartes :
4 * 1Gb -> SAN
2 * 1Gb -> LAN
1 * 1Gb -> Live migration
1 * 1Gb -> CSV + HeartBit
 
Edit : C'est surtout sur les débits ... Je ne connais pas ISCSI hors mis dans les livres, donc je me demandais si celà restais cohérent Quand j'ai la tête dans le guidon, j'ai parfois du mal à prendre un peu de recule sur les infras.

Je sais que beaucoup diront qu'il est préférable d'avoir un nombre pair d'hyperviseur, mais dans mon cas, j'accepte de perdre un noeuds mais pas plus. De toute façon le dernier n'aura certainement pas de quoi supporter la charge, et en cas de panne, certains services pourront être arrêter plus d'une journée sans probleme.
 
Déjà, j'ai réussi à obtenir de baisser les besoins ... Ce qui pour moi est juste un exploit
 
Voici donc l'idée d'infra :

 
Mes remarques :
- peut être prévoire 2 ports réseaux supplémentaires pour teaming heartbit, CSV et Livemigration.

Bonsoir,
 
Je te conseillerai si tu en as la possibilité de monter à 10 Gbit la carte Live Migration, j'ai vu dans ton premier poste que tu avais des VMs avec 32 Go de RAM, ça risque de poser problème pour la migration des VMs à chaud. En plus comme HyperV R2 est limité à 1 LiveMigration à la fois, ça prendra du temps de mettre en maintenance un noeud par exemple.

C'est dommage j'avais un blog pas mal qui expliquait l'intéret du 10GB et où en mettre. Je crois même avoir vu il y a qq temps un lien sur ce forum pour ce blog. Je l'ai dans mes favoris au boulot mais suis en vacs .
 
Après mutualiser les switchs, pk pas mais sur ton réseau de stockage active le jumbo frames et flow control, tu gagneras pas mal en débit et moins de conso CPU.
 
Après des fois faut se poser la question sur le cout de 4*1Gbps (surtout pour la perf ici) par rapport à 2*10Gbps (pour redondance) (ça coute 2 cartes double port, 4 ports sur les switchs au lieu de la moitié et le port 10Gbps a pas mal baissé).s

Merci du conseil Mais ma plus grosse machine a 16 Go de mémoire et ne supportera pas le Live Migration pour la haute dispo (Tous les gros serveurs de DB on des disques attachés)
 

Je préfère ne pas te donner le chiffre du premier devis HP ... Le soucis étant principalement le cout des switchs pas tellement dans la carte.
 
Devis HP pour une infra 4 serveurs (bi proc sandybridge, 64 Giga de RAM), SAN et Réseau de stockage en 10Gb/s on est à 70K ...
 
C'est pour celà que l'on taille la soluce

Chez HP/Dell/Futji/IBM and co tu as des programmes Fast track cloud start tu pourrais regarder.