Il y a "pire" maintenant, chez des concurrents. Eux par exemple : http://www.nimblestorage.com/

SSD + SATA + software développé pour dans le même boitier... Et hop, une solution "all in one" pour le stockage primaire, secondaire, backup, snapshots, auto-adaptatif, etc.

--> Sans aller jusque là, je pense qu'en restant sur l'Equallogic on peut

déjà faire des choses sympa.

...

La question que je me pose (et là j'ai besoin d'un retour d'expérience) c'est est-ce qu'il est capable de répartir de façon intelligente entre un RAID6 de SAS et un RAID6 de sata ?

Oui. Parce qu'il (le soft EQL) sait que le RAID6 est plus rapide en SAS qu'en SATA.

--> 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 ?

Bon après, moi, le RAID6 je suis contre sur du SATA avec des gros disques. Mais c'est perso...

--> 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é.

...

Peut-être peut-on même envisager de gérer en partie manuellement le truc,

Si tu fais ça, ça veut dire que tu ne mets pas tes baies EQL dans le même san-group, donc que tu perds AMHA l'intérêt de prendre une baie SATA EQL pour faire ce que tu veux (et tu devrais regarder des solutions tierces, genre Open-E ou NexentaStor).

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.

Faut pas oublier ce que je disais hier (repris par d'autres sur la ML) : vu

le nombre d'IOPs qu'on sort d'un disque aujourd'hui... Qui a _vraiment_ besoin d'une baie SAS 15K en RAID10 (ou pire SSD) ? Pas moi en tout cas, je vais même passer ma baie SAS 15K RAID10 en RAID50 tellement elle ne fout rien (elle héberge du LAMP principalement).

--> 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