[Math33]

Il y a du cache SSD en lecture/réécriture mais avec 10 workers qui font du random, le cache n'intervient qu'au début du test. Au bout d'1 heure de test normalement c'est censé être fiable (sauf si le device de 40G est entièrement mis en cache).

Si un spécialiste d'IOMeter a une méthodologie différente, je peux refaire un bench avec

[dougyz]

3500+ IOPS. Il n'y aurait pas un cache ?

[Math33]

Datastore : NFS 1,2To RAID 10 de 4 DD SAS 15k RPM
Host : type L avec 2 NIC 1 Gbit/s

Je n'utilise pas les disques locaux pour le stockage des VMs, HA oblige

[Math33]

Hello !

Comme promis, test IOMeter effectué sur une VM WK28 R2 Enterprise (1 vCPU, 4 Go RAM).

Le datastore est un 1,1To un peu utilisé par d'autres VMs.

J'ai lancé 10 workers en "All in one" pendant une bonne heure, voici le résultat :
http://www.toopix.eu/userfiles/4d17c...08920716f9.png

Sur vScope, les IOs correspondent (1k8 en read, 1k8 en write). Je testerai un DS SSD dès qu'il y en aura de dispo (je suis toujours en PCC 2011) mais en tout cas c'est plutôt rassurant comme résultat

[superkikim]

Difficile à dire sans des tests approfondis, mais si ta base n'est pas neuve tu dois bien avoir une idée. Ca dépend tout de ce que fait ta base, sa taille, sa charge en lecture et en écriture, etc.

Donc je dirais: oui, pour ça c'est jouable, mais c'est à mesurer et à monitorer, bien entendu.

[dougyz]

Hello

La machine dont je parle est une slave mysql qui ne fait fonctionner que mysql. Je peux donc lui allouer un maximum de mémoire. Ca te parait pas jouable ?

[superkikim]

Je ne vois pas en quoi 64GB de RAM te permettent de mettre une croix sur les soucis d'IOs. Même si tu mets en place un mécanisme de cache disque dans la RAM, si tes disques sont très lents, et que tu as des pics d'IOPS, tu risques de remplir ton cache à un moment donné où a un autre. Et j'imagine que ta RAM a un autre usage que le cache disque, non ?

D'autre part, suivant le type de transaction que tu as, la cache te fera une belle jambe. Il faut avoir un sacré cache hit pour que tu puisses espérer totalement te dédouaner de perf disques / NAS insuffisantes.

[dougyz]

Cette annonce de Oles pourrait t'intéresser et te faire patienter http://forum.ovh.com/showthread.php?t=83415

L'idée, je pense, c'est d'avoir un datastore de base et de commander des nouveaux hosts en paiement à l'heure en fonction de la charge.

Salut Gaboul

A priori Oles fait référence au Private Cloud deja dispo ici ? http://www.ovh.com/fr/private_cloud/...64_0000250_0_0

A priori dispo dans un mois (a partir du 12 octobre, donc dispo mi novembre). Cependant le Private Cloud est deja dispo. Dans la roadmap je ne retrouve pas d'infos particulière (http://www.ovh.com/fr/roadmap).

Quand il parle de "ressources garanties, high IO disque", a quoi fait il référence ? Dans mon cas c'est le point le plus critique. Cependant quand je vois que la plus part des serveurs dediés version 2013 ont 64G de RAM, on peut faire une croix sur les soucis IO :-)

[gaboul49]

site de sport, gros trafic pendant les matchs, bcp bcp moins en dehors

Cette annonce de Oles pourrait t'intéresser et te faire patienter http://forum.ovh.com/showthread.php?t=83415

L'idée, je pense, c'est d'avoir un datastore de base et de commander des nouveaux hosts en paiement à l'heure en fonction de la charge.

[dougyz]

Salut Math

La BDD est optimisé. Les requêtes exploitent bien les clefs, j'ai pas de clefs inutiles. Cependant je dois avouer que la base est assez mastoc. Certaines tables contiennent des millions de lignes et je dois faire de belles grosses jointures. Le serveur qui héberge c'est BDD (et ne fait que ca, c'est un slave mysql) est un MG SSD Max (Belle bête).

Je ne fais que du innodb car j'ai beaucoup d'accès concurrents (écriture vs lecture).

Autant pour mois la BDD total ne fait pas 70go mais 40go. Je pourrais surement gagner qqs giga en optimisant les types. L'idéale serait peut être de monter une VM avec un host de type L+ dedié. Il aurait assez de mémoire pour faire tenir toute la BDD :-) Niveau prix ca pourrait passé (417e TTC / mois) mais peut être pas full time, uniquement en cas de pics de trafic (site de sport, gros trafic pendant les matchs, bcp bcp moins en dehors).

Pour mes besoins MySQL j'ai besoin de SSD. Les perfs des HDD sont une catastrophe (pas mal de grosses jointures dans les requetes). J'ai peur pour les perfs d'un NAS contre un SSD local :-o

[Math33]

Difficile de dire là comme ça de but en blanc. Tout dépend si la BDD est bien conçue, du moteur de stockage (MyISAM ou InnoDB) et de la configuration du serveur MySQL.

Après tout dépend du nombre de VMs utilisant le DS, si tu mets une seule VM dessus les perfs de ta BDD vont être bonnes, si d'autres VMs pompent sur le DS par contre ce sera peut-être plus problématique en heure de pointe :/

[dougyz]

Le datastore vous semble adapté à de grosse bdd mysql (70go) avec une utilisation massive de jointures + beaucoup d'insert / update ?

[superkikim]

A voir, de mon côté sur un host c'est 50/50 niveau trafic

En fait, oui, tu arrives à 50/50 mais c'est "artificiel". Chaque transaction (par VM) utilise une seule NIC mais les transactions sont partagées sur les deux cartes.

Ainsi, si une VM comment une transaction via une NIC, elle ne passera que par cette NIC. Le trafic se fait donc toujours sur 1Gb/s.

Pareil pour les connexions NFS. Une fois qu'une connexion est établie, elle se fera toujours par la même NIC. Mais un DS peut passer par une NIC, et un autre DS passera par l'autre NIC. Tu as donc une répartition du trafic, mais pas une véritable balance de charge.

[gaboul49]

Merci pour tous ces tests. C'est très instructif.

Je ne m'attendais pas à des perfs exceptionnelles avec le SSD du fait du NFS. Mais on peut également se dire que les SSD en cache sur le NAS 1.2To fonctionnent très bien.

Comme dit plus haut, si on comparait le SSD et le NAS 300go, on verrait une différence plus net.

[Math33]

Le datastore de 300GB est ben un volume fait sur deux disques SAS 300GB 10krpm en RAID1. Le Datastore de 1.2TB est un RAID 10 sur quatre disques SAS 600GB 10krpm. On aura, de nouveau sans compter le problème du réseau, bien plus d'IOpS sur le 1.2TB que sur le 300.

Tout à fait, le cache SSD peut aussi pas mal jouer, cache R+W à partir du 1,2T

A noter que maintenant quand tu prends un PCC, tu as deux DS de 300GB (une chose semble-t-il imposée par vSphere 5.1... ). Tant mieux, on va pas s'en plaindre. Mais perso, j'ai commandé en sus un DS 1.2TB. Je ferai des tests pour comparer les perfs entre les deux. Mais il y a fort à parier que j'aurai le même genre de résultat que toi... C'est le réseau qui va fixer la limite.

En effet, cependant en n'atteignant pas 100mo/s, je n'ai à priori pas réussi à atteindre 80% du lien réseau, je suis pas certain que ce soit le seul élément limitant, à moins que ce soit le lien du DS, cependant il est censé être sur du 10G (à voir si la tête elle-même n'a pas son lien réseau limitant).

Par contre, peut-on faire la config du réseau à notre guise ?

Non, aucun accès à la configuration des NIC ou du VLAN (sur vSphere 4.1 en tout cas). Sur le PCC 2013, ce sera à priori possible à partir de demain (à check).

Si oui, je dédierai une carte au stockage, et une carte au trafic utilisateurs... Je ne veux pas que mes périodes de sauvegarde prétéritent l'usage des sites par les visiteurs... Tout mettre sur deux cartes en teaming, stockage et trafic utilisateur est un non sens. Même si je comprends l'intérêt de la redondance, l'impact sur les performances est pour moi trop cher payé. Et avec un HA, au final, c'est pas vraiment un drame. Au pire, le serveur redémarre... (en espérant... il est vrai, que la base ne soit pas corrompue au redémarrage).

En faisant les backups de nuits, en les organisant bien, tu ne devrais pas bousiller les perfs de la prod pendant le backup

Une dernière remarque sur le teaming de vSphere: le teaming de vSphere ne distribue pas le trafic en temps réel sur deux interfaces. En tout cas pas avec les vSwitch par défaut. Avec les Nexus 1000v, on doit pouvoir faire du ether channel. Mais là, à voir comment OVH a configurer ça. Je me réjouis d'avoir ça entre les mains. Quoi qu'il en soit, avec le vswitch de base, le trafic passe toujours par un seul chemin. C'est ce qui explique aussi que même avec deux carte Gb/s en teaming, tu dépasses pas les 80MB/s (640Mb/s = 64% de 1Gb/s ce qui est plutôt bon comme taux d'utilisation d'un réseau Gigabit Ethernet).

A voir, de mon côté sur un host c'est 50/50 niveau trafic, sur l'autre j'ai une NIC qui plafonne à 0, bug potentiel avec ticket en cours, je verrai ce qu'il en est.
Après niveau répartition, il est probable qu'une NIC fasse passer le trafic, l'autre le trafic vers les DS de manière à peu près automatique.

[superkikim]

J'ai demandé des détails au support.

Je pensais que les DS étaient des LUNs coupés dans des groupes partagés par différents utilisateurs mais il n'en est rien.

Si on fait abstraction du problème de goulot d'étranglement du réseau, les datastore de 300GB auront de bien moins bonnes performances que les datastores de 1.2TB.

Le datastore de 300GB est ben un volume fait sur deux disques SAS 300GB 10krpm en RAID1. Le Datastore de 1.2TB est un RAID 10 sur quatre disques SAS 600GB 10krpm. On aura, de nouveau sans compter le problème du réseau, bien plus d'IOpS sur le 1.2TB que sur le 300.

A noter que maintenant quand tu prends un PCC, tu as deux DS de 300GB (une chose semble-t-il imposée par vSphere 5.1... ). Tant mieux, on va pas s'en plaindre. Mais perso, j'ai commandé en sus un DS 1.2TB. Je ferai des tests pour comparer les perfs entre les deux. Mais il y a fort à parier que j'aurai le même genre de résultat que toi... C'est le réseau qui va fixer la limite.

Par contre, peut-on faire la config du réseau à notre guise ?

Si oui, je dédierai une carte au stockage, et une carte au trafic utilisateurs... Je ne veux pas que mes périodes de sauvegarde prétéritent l'usage des sites par les visiteurs... Tout mettre sur deux cartes en teaming, stockage et trafic utilisateur est un non sens. Même si je comprends l'intérêt de la redondance, l'impact sur les performances est pour moi trop cher payé. Et avec un HA, au final, c'est pas vraiment un drame. Au pire, le serveur redémarre... (en espérant... il est vrai, que la base ne soit pas corrompue au redémarrage).

Je pourrais envisager de faire le serveur SQL sur un serveur tiers en fait, puisque je ne suis pas limité en VM.

De toute façon, je monterai une machine windows 7 pour faire des tests des différents scénarios avec IOMeter. Je posterai les résultats ici. Mais ce sera dans les quatre prochaines semaines.

Une dernière remarque sur le teaming de vSphere: le teaming de vSphere ne distribue pas le trafic en temps réel sur deux interfaces. En tout cas pas avec les vSwitch par défaut. Avec les Nexus 1000v, on doit pouvoir faire du ether channel. Mais là, à voir comment OVH a configurer ça. Je me réjouis d'avoir ça entre les mains. Quoi qu'il en soit, avec le vswitch de base, le trafic passe toujours par un seul chemin. C'est ce qui explique aussi que même avec deux carte Gb/s en teaming, tu dépasses pas les 80MB/s (640Mb/s = 64% de 1Gb/s ce qui est plutôt bon comme taux d'utilisation d'un réseau Gigabit Ethernet).

[Math33]

Les hosts sont équipés de 2 NIC normalement configurées en teaming, je n'ai pas testé dans les faits si la répartition se fait uniformément.

Des hosts S à L++, c'est 2 liens Gigabits par host, au-delà les hosts L2/XL sont équipés en 2x10G mais on est dans une autre tranche de prix niveau hosts. A tester en effet si sur ces hosts l'apport de liens réseaux nettement dimensionnés permettent de davantage profiter de l'apport du SSD.

Concernant le dimensionnement réseau entre hosts et datastores, OVH mentionne que les DS sont connectés en 10G (à voir combien de DS tirent sur le même lien 10G du coup) sur les hosts L2/XL, 1G pour les autres.

Dans les faits, les I/O de NAS SSD ne sont pas mauvaises, reste à tester en condition réelle si une BDD MySQL de plusieurs dizaines de Go tient bien la charge à coup de quelques milliers de requêtes/s.

Par contre, j'ai de base avec le starter de mon PCC un Datastore de 300Go en Raid 1 (au lieu de 10) et cache SSD en écriture seulement et à l'utilisation c'est bien plus lent. Faudra que je benche un de ces 4 mais une petite VM de monitoring à elle seule arrive à un peu trop tirer dessus. Dans tous les cas, ces datastores ne sont plus dispos dans le PCC 2013, seulement avec les starters, ce qui m'apparaît dommage.
De mon côté, je m'en sers pour les petites VMs d'infra, pas pour mes clients...

[superkikim]

Je ne suis pas étonné par tes résultats.

Le problème est simple. On est en NFS... avec probablement un seul lien gigabit entre le serveur et les stockage. Ton goulot d'étranglement est donc le réseau et non les disques.

Le NAS hybrid est intéressant à l'échelle de OVH pour éviter que des utilisateurs avec beaucoup d'I/O saturent le cache des baies NAS, puisqu'une baie est dans la majorité des cas partagées par plusieurs utilisateurs.

Par contre, le NAS SSD a peut-être un intérêt pour une base de donnée qui fait beaucoup d'accès mais lit et écrit de très petits blocs. Par contre pour un usage moyen quotidien, ça n'apporte rien.

D'ailleurs, je me demande si on a une interface réseau dédiée pour le NAS. est-ce que tu peux me dire ça ? Combien d'interfaces réseaux sont disponibles dans les hosts du PCC ?

[Math33]

En ce dimanche pluvieux, test d'un datastore SSD.

J'ai pris une VM mieux dotée et plus véloce pour mieux comparer le datastore 1,2To DD et le 100Go SSD. Petit comparatif au niveau de simples benchmarks :

/dev/sdb -> DD
/dev/sdc -> SSD

NB : Gamme PCC 2011 sur vSphere 4.1 U2, VM 1vCPU, 1Go RAM

Commande DD : time sh -c "dd if=/dev/zero of=/XXX/test bs=4096 count=2097152 && sync"

DD

2097152+0 enregistrements lus
2097152+0 enregistrements écrits
8589934592 octets (8,6 GB) copiés, 142,793 s, 60,2 MB/s

real	2m25.995s
user	0m0.350s
sys	0m10.350s

SSD

2097152+0 enregistrements lus
2097152+0 enregistrements écrits
8589934592 octets (8,6 GB) copiés, 87,071 s, 98,7 MB/s

real	1m28.635s
user	0m0.150s
sys	0m10.470s

HDParm

DD

/dev/sdb:
 Timing buffered disk reads: 218 MB in  3.05 seconds =  71.58 MB/sec
root@debian:/mnt# hdparm -t /dev/sdb

SSD

/dev/sdc:
 Timing buffered disk reads: 244 MB in  3.01 seconds =  81.12 MB/sec
root@debian:/mnt# hdparm -t /dev/sdc

Seeker

DD

Benchmarking /dev/sdb [51200MB], wait 30 seconds..............................
Results: 388 seeks/second, 2.58 ms random access time

SSD

Benchmarking /dev/sdc [20480MB], wait 30 seconds.............................
Results: 478 seeks/second, 2.09 ms random access time

Conclusion : Un datastore SSD inutilisé semble ne faire qu'à peine mieux qu'un datastore 1,2To classique alors que ce dernier est sollicité par quelques VMs.
Le protocole de tests n'est pas nécessairement fiable, à confirmer sur un benchmark plus réaliste. Ceci dit, je serais curieux de connaître les résultats des tests côté OVH de ces Datastores SSD dont le prix au Go par rapport un Datastore classique est au moins 32 fois plus élevé (0,05€HT/Go/mois pour un 1,2T contre 1,59€HT/Go/mois pour du SSD).

Pour ma part c'est assez décevant au premier abord, à moins que le datastore ssd ait un problème quelconque... Je referai des tests bientôt pour confirmer/infirmer tout ça.

[Math33]

Arf je voulais tester là dans l'immédiat mais pas de filer SSD libre. Je zieuterai dans les prochains jours

[superkikim]

Hello.

As-tu pu faire des tests de perf ?

[gaboul49]

J'avais cru lire REdémarrés... Au temps pour moi :x

C'est rassurant ! J'ai eu peur en lisant ton commentaire initial.

[Math33]

Erreur de lecture de ma part, dans le manager il est inscrit :
"L'operation que vous demandez requiert que tous les hosts du datacenter soient démarrés."

J'avais cru lire REdémarrés... Au temps pour moi :x

[HeleneC]

Pas encore de mesure effectuée. J'ai cru comprendre qu'il faut reboot les hosts pour la prise en compte de l'ajout de datastore

Ah ?

[Math33]

Pas encore de mesure effectuée. J'ai cru comprendre qu'il faut reboot les hosts pour la prise en compte de l'ajout de datastore et ayant une vingtaine de VMs et enchaînant les MEP, je vais éviter de trop stresser l'infra dans l'immédiat.

Si j'ai le temps durant le weekend je fais ça =)

[gaboul49]

Demande effectuée sur le support commercial, merci par avance

Si tu pouvais également poster ici les mesures sur de datastore SSD ça m'intéresse également.

[Math33]

Demande effectuée sur le support commercial, merci par avance

[HeleneC]

Oui. Pas de soucis.

[Math33]

Serait-il d'ailleurs possible de tester sur une courte durée un Datastore SSD ?

[HeleneC]

Sinon, le mieux c'est aussi de contacter le support et de demander à tester le pCC.
C'est le meilleur moyen de se rendre compte par soi-même si les performances sont suffisantes.

[Math33]

Certes mais ce test est aussi fait sur un datastore qui est en prod et qui est donc un peu sollicité donc c'est pas un test rigoureusement "à vide". Ne pas oublier aussi que ça passe par du NFS qui bien qu'étant un protocole tout à fait fiable n'est pas le plus performant qui soit pour une telle utilisation

Pour ce qui est de vSphere 5.0 ça arrive, cf la roadmap :
http://www.ovh.com/fr/roadmap

[superkikim]

Génial merci

Ca fait des mois que j'essaie d'obtenir cette information.

Ces performances sont tout à fait raisonnables. Elles correspondent à ce que j'avais avec les disques locaux sur des SP.

En passant sur des EG avec le RAID Hard .... je suis tombé au quart des perfs....

Le private cloud me fait sérieusement de l'oeil

J'essaie maintenant de savoir si OVH va déployer vSphere 5.0 ou vSphere 5.1. Vu les améliorations apportées par vSphere 5.1, ça promet

[Math33]

Pour le test via dd ça donne :

2097152+0 enregistrements lus
2097152+0 enregistrements écrits
8589934592 octets (8,6 GB) copiés, 126,609 s, 67,8 MB/s

real	2m8.100s
user	0m0.800s
sys	0m35.740s

Via hdparm -t /dev/sda :

 Timing buffered disk reads: 262 MB in  3.04 seconds =  86.18 MB/sec

Et via le binaire seeker de l'article linké j'ai :

Results: 106 seeks/second, 9.38 ms random access time

A noter qu'il s'agit d'un datastore 1,2To Hybrid (cache SSD lecture/écriture), il est probable que les datastores de configuration supérieure soit plus performants.

EDIT : La VM utilisée a pas mal de CPU Ready, je retesterai sur une autre VM pour confirmer

[superkikim]

Hello. Merci pour ta proposition.

En fait, en préparant ma réponse, j'ai découvert que pour faire un test sur Linux, il faut IOmeter sur un windows, et ensuite Dynamo sur le linux. Faisable mais contraignant.

Finalement, je te propose soit un simple test séquentiel avec dd avec la ligne de commande suivante, générant, et ensuite lisant un fichier de 8GB fait de blocs de 4kb.

time sh -c "dd if=/dev/zero of=/home/test bs=4096 count=2097152 && sync"

Ou, si tu peux faire un test un peu plus étendu, il y a un article ici expliquant comment procéder.

Pour référence, le test d'écriture DD ci-dessus donne chez moi les résultats suivant sur un EG Hybrid (dans une VM dont le VMDK est sur les disques SATA du serveur dédié):

2097152+0 records in
2097152+0 records out
8589934592 bytes (8.6 GB) copied, 418.792 s, 20.5 MB/s

real 7m3.889s
user 0m0.344s
sys 0m7.776s

[Math33]

Si tu me donnes un outil de benchmark particulier qui fonctionne sous un Linux 64 bits je te fais ça :-)

[superkikim]

Gros up....

Bonjour,

Personne n'a fait de test de perfs disque sur le private cloud ?

[admin_root]

Bonjour,

Ce test m'aurait bien interressé mais iometer n'est disponible qu'en version Windows ou linux 32bits.

Si quelqu'un peut tester çà sur son pCC ou proposer un autre outils ...

[superkikim]

Bonjour,

J'aimerais faire le saut Private Cloud, mais avant ça, j'aimerais avoir une idée des performances disques, car je quitterais des EG qui sont catastrophiques.

Qui parmi vous pourrait faire un test IO Meter avec le fichier icf ci-dessous et poster les résultats agrégés par le site http://vmktree.org/iometer/ ?

http://vmktree.org/iometer/OpenPerformanceTest.icf

Idéalement, il faut faire 5 fois le test. Ensuite supprimer le plus haut et le plus bas, et faire la moyenne des trois autres.

Merci d'avance a qui prendra le temps de le faire. Ca serait très intéressant.

POur référence, sur un EG, je ne dépasse pas 10 à 20MB/s avec des latences de 50 à 100ms.....