--> Sans aller jusque là, je pense qu'en restant sur l'Equallogic on peut déjà faire des choses sympa.
 

--> OK, et entre un RAID10 de 48 disques SATA et un RAID6 de 16 disques SAS ? .... est-ce qu'il est suffisamment intelligent pour savoir que le temps de latence d'un disque SAS est meilleur qu'un disque SATA ?
 

--> Je suis un peu du même avis, car trop d'IO cumulées, si on part sur du PS6500 c'est aussi pour avoir le luxe de pouvoir faire du RAID10 sur du SATA et donc de compenser un peu les pertes lié à la techno SATA, même si selon les avant vente de DELL, ils déconseillent du RAID10 sur du SATA à priori à cause de l'algo de priorisation des Equalogic qui aurait tendance à dire le RAID10 des SATA c'est mieux qu'un RAID6 de SAS ...
A voir dans les nouvelles release peut etre, il parait que les algo évoluent en permanence de ce coté.

Mais l'idée qui est intégré à EQL c'est vraiment :
 . toutes les baies dans le même san-group
 . on laisse l'EQL gérer les données
 . on ne joue pas à la main avec les datas
 . on laisse l'EQL gérer les données (je sais je me répète 8))

Dans ton idée, tu va "bloquer" une baie (ta baie "rapide") pour tes bases SQL.
Why not.
Sauf que dans la "vraie vie", peut-être que certaines bases pourraient être sur la baie intermédiaire (voire lente, en exagérant) et que certaines VM bénéficieraient d'être sur la baie "rapide".
Tu vois ce que je veux dire ?

---> OK, donc selon toi l’intérêt des Equallogic réside dans la gestion automatisée. C'est vrai que gérer une partie en manuel présente l'inconvénient de "réserver" des ressources rapides pour des VM dont ont sait qu'elles en ont "potentielement" besoin mais ce n'est pas toujours le cas en permanence.

De ce que j'ai compris, l'algo de ré allocation des Equallogic n'est pas "immédiat" dans le sens où il se base sur une analyse statistique des données les plus utilisées, a priori sur une période de 14 jours de ce que j’ai compris ...

Néanmoins, je voudrais éviter de tomber dans une situation un peu étrange ou dans certains mois des VM seront très sollicitées et déplacées 14 jours après sur des disques rapides alors que le mois d'après elle n'est quasiment pas utilisée ..
Concrètement ça arrive assez rarement mais c'est possible (déjà vu) et dans ce cas une allocation "manuelle" est peut être préférable afin d'avoir le meilleur type de ressource physique au moment voulu.

--> Bref ça se discute je pense, le rapport entre "full auto" et "semi auto" de la gestion du bouzin.

--> Je suis assez d'accord c'est aussi pour ça qu'on se pose réellement la question avant d'investir dans du lourd à l'aveugle comme ça a été souvent fait par le passé. Les costkillers sont là ..

Si on pousse la question jusqu'a l'extreme on pourrait aussi se demander finalement, sur une VM VMware, qu'est ce qui consomme le plus d'IO ou de débit , et en fonction de ça, où les placer ?

Genre:
-Fichier de la mémoire de la VM --> beaucoup d'IO , est-ce intelligent de le laisser sur le même volume de stockage ?
-fichier swap, généralement dans le vmdk, --> plus ou moins d'IO selon le dimensionnement du fichier mémoire, en gros mieux la VM est dimensionnées et moins on aura d'IO.
-Filesystem de la VM et notamment /var/log ---> trop de log génère beaucoup d'IO pour pas grand chose, centralisation des logs ?

Tout le reste sur une VM, au final l'applicatif qui tourne dessus, ça consomme pas tant d'IO que ça sauf dans les cas spécifiques ..

Bref, pour résumer le truc, je pense qu'on peut facilement imaginer un ensemble de "best practise" pour optimiser l'usage de son SAN quand on fait du VMware.

Jérémy