Auteur Sujet: Mon Hp Proliant micro serveur Gen8 v2 / tuto installation vos échanges astuces (Lu 53778 fois)

BadMax · « **Réponse #60 le:** 02 juin 2016 à 18:54:44 »

Plus simple: RDM local. Pas besoin de VT-d.

tivoli · « **Réponse #61 le:** 02 juin 2016 à 18:59:22 »

Oui mais tu ne peux pas partager un disque entre deux VM

vergeaow · « **Réponse #62 le:** 02 juin 2016 à 19:04:46 »

Citation de: tivoli le 02 juin 2016 à 18:30:25

VT-d mais sans utilisation du Directpath I/O (je ne dedie pas un HDD ou une carte reseau a chaque VM)
Juste l'optimisation par defaut de la gestion des disques.
Je parle de passer de 20mo/s a 100mo/s (voir meme 250 sur le SSD) en copie reseau, ce n'est pas le reseau qui gene mais le disque

Si tu trouves un xeon pas cher d'occasion tu verras la difference

Je ne peux pas comparer c'est ma 1ère config sous ESXi et c'est du Xéon.
20Mo/s en copie réseau c'était à l'époque des cartes 10/100 ?
Perso je tourne environ à 115Mo/s, je pense que c'est la carte réseau au Giga qui sature. J'ai bien une 2ème carte sur le serveur mais mon switch ne supporte pas le 802.3ad.
Pour les disques j'ai acheté en occaz 4 x 300Go en SAS 15K donc je pense que ce n'est pas le facteur limitant.

~~@BadMax, tu peux expliquer RDM local ?~~ --> Google m'a expliqué

tivoli · « **Réponse #63 le:** 02 juin 2016 à 19:31:19 »

Tu as du xeon tout va bien (la preuve tu atteints >100mo/s

Belle config amuse toi bien avec

BadMax · « **Réponse #64 le:** 02 juin 2016 à 19:35:05 »

@vergeaow: en effet c'est la limite du Gigabit.

Sur ESXI tu peux affecter la 2ème carte à d'autres VM et faire de la redondance avec la 1ère sans utiliser 802.3ad. Ce n'est pas un agrégat, c'est de l'actif/passif et on peut "croiser" le trafic actif/vm/carte.

RDM c'est pratique si tu fais du ZFS et que tu n'as pas VT-d et/ou un ctrl dédié. Y'a p'tet d'autres use cases mais c'est rare. Pose problème avec HA.

vergeaow · « **Réponse #65 le:** 03 juin 2016 à 17:24:08 »

Citation de: tivoli le 02 juin 2016 à 19:31:19

Tu as du xeon tout va bien (la preuve tu atteints >100mo/s

Belle config amuse toi bien avec

Pour les disques et le réseau, aucun souci.
C'est plutôt la gestion du (des) CPU qui me pose problème.

Mon serveur est un Proliant ML110 G7 équipe d'un Xéon E31220, ESXi 6.0 ISO HP.

Ce que je souhaite optimiser (parce que souvent réalisé) est l'extraction de 200 parties de fichiers RAR de 15Mo chacune pour former au final un seul fichier de 45Go.
Temps mesuré : VM sous W10 20 minutes, VM sous Ubuntu 16.04 18 minutes.
Vous allez me dire "Ce temps me paraît correct car l'opération est lourde", oui mais un simple PC de bureau équipé d'un Core i5 sous W7 (un vrai pas une VM) réalise l'opération en moins de 15 minutes.

J'ai tout de suite pensé que les autres VM sur mon hôte prenaient toutes les ressources. J'ai éteint toutes les autres VM et aucune amélioration des performances (je n'ai que 5 autres VM en fonctionnement).
Ensuite, sur mes VM j'ai lancé le moniteur de ressources / gestionnaire de taches pour voir que le CPU est occupé à 100% pendant l'opération.
Pensant que WinRAR et unrar sont des applications multithread, j'ai modifié les paramètres de mes VM "nombre de sockets virtuels" et "nombre de noyaux par socket" sous vSphere (d'ailleurs si quelqu'un peut m'expliquer la différence je suis preneur).
Légère amélioration des performances mais rien de bien folichon.
J'ai ensuite consulté le diagramme des performances de mon hôte sous vSphere pour voir que j'étais bien loin des 100% d'occupation CPU de l'hôte.

Donc si je comprends bien, la VM utilise 100% des ressources que lui attribue l'hôte.
Mais comment faire pour que l'hôte attribue plus de ressources à telle ou telle VM ?
Je pensais qu'un Xéon pour extraire du RAR ça devait envoyer du pâté !

Merci de votre aide.

BadMax · « **Réponse #66 le:** 03 juin 2016 à 19:08:37 »

Tu ne serai pas plutôt limité par les I/O ?

Citer

j'ai modifié les paramètres de mes VM "nombre de sockets virtuels" et "nombre de noyaux par socket" sous vSphere (d'ailleurs si quelqu'un peut m'expliquer la différence je suis preneur)

Nombre de sockets : nombre de CPU physique du point de vue de la VM
Nombre de noyaux : nombre de cores par CPU physique du point de vue la VM

2xsocket, 1xnoyau = 2vCPU
1xsocket, 2xnoyau = 2vCPU

C'est donc quoi l'intérêt ? C'est juste à des problématiques de l'OS (différence entre Windows 10 et Windows Server) et/ou d'une (vieille) application propriétaire qui contrôlerait le nombre de CPU "physique" pour des problématiques de licence

vergeaow · « **Réponse #67 le:** 04 juin 2016 à 10:54:28 »

Citation de: BadMax le 03 juin 2016 à 19:08:37

Tu ne serai pas plutôt limité par les I/O ?

Qu'entends-tu par les I/O ? Les opérations d'entrée / sortie du disque dur ?
Sais-tu comment je peux mesurer cela ?

BadMax · « **Réponse #68 le:** 06 juin 2016 à 10:22:46 »

Regardes les temps de latence dans performance->disque.

< 1ms : tranquillou bilou
< 10ms: ça gratte
> 10ms: ça creuse
> 100ms: ça fume

vergeaow · « **Réponse #69 le:** 06 juin 2016 à 12:16:37 »

Citation de: BadMax le 06 juin 2016 à 10:22:46

Regardes les temps de latence dans performance->disque.

< 1ms : tranquillou bilou
< 10ms: ça gratte
> 10ms: ça creuse
> 100ms: ça fume

Merci du tuyau, je regarderai ça.
Mais si le souci vient des disques je serai dégouté : contrôleur Smart Array P410 + barrette 1Go + batterie + 4 disques SAS 15K en raid 5
Ou alors il y a un souci de config.

vergeaow · « **Réponse #70 le:** 07 juin 2016 à 17:34:39 »

Citation de: BadMax le 06 juin 2016 à 10:22:46

Regardes les temps de latence dans performance->disque.

< 1ms : tranquillou bilou
< 10ms: ça gratte
> 10ms: ça creuse
> 100ms: ça fume

Pointe à 23 ms en latence d'écriture
Pointe à 7 ms en latence de lecture

Je suppose donc que le souci ne vient pas des disques

BadMax · « **Réponse #71 le:** 08 juin 2016 à 09:39:10 »

Pas terrible non plus : 23ms en écriture alors que ta carte contrôleur devrait faire cache. Un disque SAS 15k répond en 7-8ms -> y'a un pb.