none
CPU hyper-v non utilisée RRS feed

  • Discussion générale

  • Bonjour

    J'ai un serveur hyper-v 2012 r3 qui possède 2 processeurs octocoeurs, soit 16 coeurs au total.

    Sur ce serveur j'ai 13 VM avec un total de 43 vcpu, dont 3 VM pour une application GED qui prennent 8 vcpu chacune (l'éditeur demande 8 coeurs par VM).

    Quand je regarde le moniteur de taches de la VM du serveur d'application (IIS) et de la VM base de données (oracle 11), je vois en moyenne 40 à 80 %. Sur la VM de numérisation par contre on est plus près des 80 à 100%.

    Pourtant dans le gestionnaire des taches de l'hyper-v, celui ci reste à 10% quelque soit l'activité des VM alors que d'après l'éditeur de l’application l'hyper-v devrait être à au moins à 80% compte tenu du besoin de 24 coeurs.

    Qu'en pensez vous ?

    Merci


    • Modifié stef-VSTT dimanche 6 juillet 2014 16:01
    • Type modifié Florin Ciuca jeudi 31 juillet 2014 09:46
    dimanche 6 juillet 2014 15:59

Toutes les réponses

  • Bonjour

    J'ai un serveur hyper-v 2012 r3 qui possède 2 processeurs octocoeurs, soit 16 coeurs au total.

    Sur ce serveur j'ai 13 VM avec un total de 43 vcpu, dont 3 VM pour une application GED qui prennent 8 vcpu chacune (l'éditeur demande 8 coeurs par VM).

    Quand je regarde le moniteur de taches de la VM du serveur d'application (IIS) et de la VM base de données (oracle 11), je vois en moyenne 40 à 80 %. Sur la VM de numérisation par contre on est plus près des 80 à 100%.

    Pourtant dans le gestionnaire des taches de l'hyper-v, celui ci reste à 10% quelque soit l'activité des VM alors que d'après l'éditeur de l’application l'hyper-v devrait être à au moins à 80% compte tenu du besoin de 24 coeurs.

    Qu'en pensez vous ?

    Merci


    Bonjour,

    Il ne faut pas confondre le nombre de coeur affectée, et l'utilisation des coeurs.

    Si tu veux vraiment savoir l'utilisation CPU de ton hôte Hyper-V, il faut passer par les compteurs de performances.


    Blog
    Scripts

    lundi 7 juillet 2014 05:45
  • Finalement on a baissé à 2 vcpu les 3 VM pour voir le changement mais il n'y en a pas l'application rame. Je viens de regarder les compteurs sur l'hyper-v, les valeurs moyennes sont les suivantes :

    - % temps processeur (celui par defaut) : 6 %
    - processeur logique hyperv \ % temps execution invité _ total : 27 %
    - processeur virtuel hyper-v \ % de la durée d'execution invité numérisation 97 % par instance
    - processeur virtuel hyper-v \ % de la durée d'execution invité serveur application : 65 % par instance
    - processeur virtuel hyper-v \ % de la durée d'execution invité sgbd 70 % par instance

    Donc le serveur hyper-v ne semble pas trop sollicité (si ce sont les bons compteurs ?) ?

    lundi 7 juillet 2014 07:59
  • Bonjour,

    Contrairement à VMware, Hyper-V ne fait pas de "Gang scheduling" des vCPU, c'est à dire qu'il n'attend pas que tous les coeurs soient disponibles pour les donner à la VM de manière synchronisés. Il les donnes à la VM dès qu'un coeur logique est disponible. Donc réduire le nombre de coeurs réduira les performances dans certaines conditions, contrairement à VMware.

    Vérifiez que votre application est bien multithread. J'ai déjà vu pas mal d'applications de ce type ayant des problèmes de performances...mais n'utilisant qu'un seul coeur à la fois. Dans ce cas, ajouter des coeurs ne change rien !

    Avant d'aller plus loin:

    • Le host Hyper-V est à jour ?
    • Les Integration tools sont à jours sur toutes les VMs ?
    • Qu'en est-il de la RAM ? Utilisez-vous beaucoup de RAM ? Est-ce que vous utilisez Dynamic Memory ?
    • Qu'en est-il des disques ? Sont-ils dimensionnés pour cette charge en terme d'IOPS ?
    • Pouvez-vous donner la valeur moyenne du moniteur Contect Switches/sec de l'Hyper-V ?

    Bien cordialement,


    Guillaume http://www.vinfra.ch

    lundi 7 juillet 2014 13:04
  • pour répondre à votre dernière question, à l'instant présent (17h30) donc très peu d'activité utilisateur :
    ==> processeur logique \ changements de contexte/s _ total à 110.000 en moyenne avec min 73.000 et max 140.000, avec 
    - % temps processeur (celui par defaut) : 3.5 %
    -
     processeur logique hyperv \ % temps execution invité _ total : 15 %
    - processeur virtuel hyper-v \ % de la durée d'execution invité numérisation 1.5 % par instance
    - processeur virtuel hyper-v \ % de la durée d'execution invité serveur application : 30% par instance
    - processeur virtuel hyper-v \ % de la durée d'execution invité sgbd 30% par instance

    Pour la RAM le serveur de num est à 4 Go, celui d'appli à 8 Go et celui de données à 16 Go. On dépasse pas les 70% je crois, là il y a 35% sur le serveur de num, 75% sur le serveur d'appli et 43% sur le serveur de données. Mais je regarde dans le gestionnaire des taches ce qui n'est sans doute pas bon ? Je ne sais pas pour Dynamic Memory mais je ne crois pas car pas entendu parler et obligé d'eteindre la VM pour modifier la RAM

    Pour les disques on est sur du SAN avec du RAID 10 pour le sgbd et du RAID50 pour les 2 autres serveurs. La longueur file d'attente sur le serveur sgbd est à 0.1 en écriture et 0.5 en lecture, mais il nous est arrivé d'aller à 15 sur ces compteurs (il me semble que le max doit etre à 1). Je viens de regarder les compteurs sur ces disques sgbd
    - longueur file attente lecture pour la journée : moyenne 1.13, max 37, avec pointe au dessus de 20 pendant 30 min ce matin
    - longueur file attente ecriture pour la journée : moyenne 0.5, max 127, avec pointe au dessus de 20 pendant la même période

    Pour les mises à jour, l'installation date de février et c'est notre partenaire qui doit les faire. On va voir ca effectivement. Et pour les integration tools ca ne me parle pas non plus, je vais vérifier

    En tout cas merci pour tout.


    • Modifié stef-VSTT lundi 7 juillet 2014 16:07 ajout de données
    lundi 7 juillet 2014 15:52
  • Bonjour

    Avez vous pensé à basculer sur le mode haute performance pour le host et les guests dans le gestionnaire d'option alimentation ?

    Eventuellement, réitérez l'opération niveau BIOS. Perso pour les SGBD et les Hosts, je désactive systématiquement l'économie d'énergie dans le BIOS.

    Pour la file d'attente disque, ce n'est pas un bon indicateur, pris seul car en fonction du nombre de disques le chiffre ne veut pas dire la même chose :

    . file d'attente de 20 pour un RAID 5 de 3 disques : danger

    . file d'attente de 20 pour un RAID 5 sur une baie de disque avec une centaine d'axes : insignifiant

    Focalisez vous plutôt sur la latence disque. C'est votre meilleur indicateur de la performance disque.

    Cdlt

    Christophe


    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

    mardi 8 juillet 2014 19:24
  • Bonjour Christophe

    Non effectivement, l'hyper-v et la vm sont en mode normal.

    Pour les disques, côté sgbd c'est sur un disque virtuel de 4 disques en RAID 10.

    Pour la latence, je suppose que ce sont ces compteurs de cette journée sur le serveur de données :
    - disque logique \ moyenne disque s/lecture : 0.012 avec un max à 1.28
    - disque logique \ moyenne disque s/ecriture: 0.016 avec un max à 4.28
    Le total se fait en gros pour moitié sur le LUN data Oracle et pour l'autre moitié sur le LUN du LOB Oracle

    Mais dans les "instants t" difficiles pour les utilisateurs on a plutôt 0.050 s en lecture et 0.070 s en écriture ce qui à priori n'est pas bon d'après ce que j'ai vu sur le site de Microsoft : 15-25ms danger, > 25ms critique. Et si je prends la formule pour un raid 10, j'ai (ecriture+(2*lecture))/4=0.048 ce qui n'est pas mieux. Mais c'est peut être pas ca :)
    • Modifié stef-VSTT mardi 8 juillet 2014 21:26 complément
    mardi 8 juillet 2014 21:17
  • Effectivement, le sous système disque est un peu faible. Vous êtes en RAID10, donc déjà cas favorable pour l'écriture (moins pénalisant qu'un RAID5) e vous avez bcp de latence ...

    Pour SQL Server, je demande a ce qu'il y ait 5 ms de latence sur la partie écriture, pour Oracle, je pense qu'il devrait en être de même. Et pour améliorer la perf, il n'y a pas des tonnes de solutions : augmenter le nombre d'axes ou passer sur des technos flash (SSD ou cartes PCI Express).

    Désactivez également l'économie d'énergie (pas de coupure de service pour cette manip).

    Christophe


    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

    mercredi 9 juillet 2014 07:43
  • Bonjour,

    il est très important de prendre en compte le fait que le gestionnaire de tâche du serveur HyperV ne prend pas en compte l'activité des machines virtuelles, mais uniquement la sienne!!!

    => Donc, c'est normal qu'il soit peu sensible à l'activité des machines virtuelles. (La séparation est très bien faite).

    Il faut regarder l'activité sur les compteurs spécifiques à chaque machine virtuelle ou dans la machine virtuelle elle-même.

    A bientôt,


    Thierry DEMAN. Exchange MVP. MCSE:Messaging 2013,MCSE:Server Infrastructure 2012(80 MCPs). MCSA Office 365 https://mvp.microsoft.com/en-us/mvp/Thierry%20Deman-7660 http://base.faqexchange.info

    mercredi 9 juillet 2014 07:50
  • Bonjour

    OK merci pour les conseils. Pour info, les VM sont sur un SAN équipé d'une une baie HP MSA P2000 G3 iSCSI avec des disques SAS 10.000 tr/min donc effectivement ca peut être juste pour une GED.

    Pour les axes, si on parle de la m^me chose, on a créé 6 LUN pour les besoins Oracle (data, lob, index, archive, sauve, système) donc 6 volumes logiques sur le disque virtuel en RAID 10. On nous a aussi parlé de mettre les disques Oracle en dehors du système virtuel (accès direct).

    mercredi 9 juillet 2014 11:21
  • Bonjour,

    Christophe parle du nombre de disques quand il parle d'axes. Plus il y a de disques, plus il y a d'IOPS. Avec des disques en 10KRPM, si votre baie HP a 24 disques, vous avez un total *raw* *d'environ* 3000 IOPS. 

    Il s'agit ensuite de connaitre le workload de chacun de vos serveurs en IOPS (Total IOPS, pourcentage écriture/lecture).

    Depuis powershell, vous pouvez lancer la commande suivante depuis votre (unique ?) serveur Hyper-V:

    Get-VM | Enable-Enable-VMResourceMetering

    Cela vous permettra de mesurer la charge de vos VMs.

    Lancez-la pendant les heures de charges, sur plusieurs heures pour avoir les moyennes, puis lancez la commande suivante:

    Get-VM | Measure-VM | fl *

    Cela vous donnera les informations de base (avgCPU, avgRAM, avgIOPS, avgLatency et le nombre de lecture et d'écritures, en 2012 R2 uniquement).

    Pour calculer le besoin en IOPS d'une VM, vous prenez à partir des valeurs précédentes:

    ReadIOPS + WriteIOPS = TotalIOPS

    %Read = ReadIOPS/TotalIOPS

    %Write = WriteIOPS/TotalIOPS

    RAID_Penalty = 2 (RAID 10

    VM_IOPS = (avgIOPS* %Read) + (TotalIOPS * %Write * RAID_Penalty)

    Enfin vous additionnez le tout pour savoir si ça rentre sur votre baie HP :-)

    Pour arrêter les mesures:

    Get-VM | Disable-VMResourceMetering

    Une fois qu'on aura écarté la thèse des disques, pouvez-vous nous indiquer comment sont connectés ces disques à l'Hyper-V ? Est-ce que vous avez dédié 2 cartes à l'iSCSI ou est-ce que vous convergez vos cartes ? Sur les cartes iSCSI et les éléments de la chaine hyper-v <--> HP MSA, avez-vous activé le jumbo-frame ? Est-ce que le switch est prévu pour absorber la charge du stockage ? Est-ce que les VHDX sont en fixed-size ? Est-ce qu'ils sont connectés au controlleur virtuel SCSI ?

    Ensuite: avez-vous suffisamment de RAM sur le host (combien de RAM pour chaque processeur ?), est-ce que vous vous êtes assuré qu'aucune VM ne swap ? Si vous n'utilisez pas le dynamic memory, avez-vous essayé de désactiver le numa-spanning ? Avez-vous défini un maximum de RAM dans la base de donnée (je ne connais pas Oracle, mais c'est recommandé sur SQL Server) ? 

    Enfin, comme l'a mis en avant Christophe précédemment, mettez-bien, dans le bios de votre serveur, les options d'alimentation à "maximum performance".

    Bon courage ! Les problèmes de performance, c'est comme un épisode de Dr House: notez toutes les possibilités sur un tableau blanc, puis rayez une par une les possibilités !


    Guillaume http://www.vinfra.ch

    mercredi 9 juillet 2014 16:42

  • Bonjour Guillaume

    Je suis bien en 2012 R2 mais je n'ai pas les compteurs dont vous parlez, ci dessous un extrait des compteurs pour les 3 serveurs de la plateforme de GED uniquement, j'ai pris 3 mesures pour les disques sur les 2 dernière heure (séparées par ->). Je peux m'appuyer sur quel compteur pour faire les opérations globales finalement ?

    On est sur un cluster de 2 serveurs hyper-v avec 192 Go de RAM chacun. il y a 20 VM sur le premier serveur et 13 sur le deuxième dont ces 3 pour la GED.

    La baie a bien 24 disques.

    Oui on est en fixed-size pour les vhdx sur cette plateforme (uniquement). Pour le stockage, les vhdx du sgbd correspondent à des disques virtuels hyper-v mappés chacun sur un LUN de la baie. Côté physique on a 2 attachements iSCSI par serveurs (8 ports sinon) qui vont sur 2 switchs qui vont sur la baie qui a 2 controleurs avec en tout 6 ports iSCSI occupés (sur 8).
    Ce que je vois sur l'hyper-v (gestionnaire réseau), c'est 9 connexions réseau, dont 2connexion iSCSI 1Gb 4 ports (marqué réseau non identifié) et 1 connexion Teaming prod mais qui a l'air d'être plutot pour le réseau que le SAN et il a la case commutateur hyper-v. Je suis en congés ce midi jusqu'à la fin de semaine prochaine donc je n'avancera plus pendant ce temps là :)

    ----------------------------------------------------------------------------------------------------------

    AvgCPU                          : 1236
    AvgRAM                          : 8192
    MinRAM                          : 8192
    MaxRAM                          : 8192
    TotalDisk                       : 768004
    ComputerName                    : xxxxxxxxxxxxxxxxxx
    VMId                            : xxxxxxxxxxxxxxxxxxxxx
    VMName                          : serveur d application
    HardDiskMetrics                 : {Microsoft.HyperV.PowerShell.VirtualHardDiskMetrics}
    MeteringDuration                : 00:00:23.9180000
    AverageProcessorUsage           : 1236
    AverageMemoryUsage              : 8192
    MaximumMemoryUsage              : 8192
    MinimumMemoryUsage              : 8192
    TotalDiskAllocation             : 768004
    AggregatedAverageNormalizedIOPS : 21 -> 26 -> 155 -> 37
    AggregatedAverageLatency        : 61186 -> 4777 -> 3816 -> 3728
    AggregatedDiskDataRead          : 1 -> 212 -> 580 -> 949
    AggregatedDiskDataWritten       : 3 -> 316 -> 592 -> 1442
    NetworkMeteredTrafficReport     : {Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                                      Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                                      Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                                      Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport}
    ----------------------------------------------------------------------------------------------------------

    AvgCPU                          : 9171
    AvgRAM                          : 4096
    MinRAM                          : 4096
    MaxRAM                          : 4096
    TotalDisk                       : 102404
    ComputerName                    : xxxxxxxxxxxxxxxxxx
    VMId                            : xxxxxxxxxxxxxxxxxxxxxxx
    VMName                          : serveur de numérisation
    HardDiskMetrics                 : {Microsoft.HyperV.PowerShell.VirtualHardDiskMetrics}
    MeteringDuration                : 00:00:23.9780000
    AverageProcessorUsage           : 9171
    AverageMemoryUsage              : 4096
    MaximumMemoryUsage              : 4096
    MinimumMemoryUsage              : 4096
    TotalDiskAllocation             : 102404
    AggregatedAverageNormalizedIOPS : 16 -> 43 -> 18 -> 13
    AggregatedAverageLatency        : 64297 -> 3856 -> 2440 -> 1479
    AggregatedDiskDataRead          : 1 -> 68 -> 92 -> 241
    AggregatedDiskDataWritten       : 7 -> 388 -> 485 -> 1109
    NetworkMeteredTrafficReport     : {Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                                      Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                                      Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                                      Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport}

    ----------------------------------------------------------------------------------------------------------

    AvgCPU                          : 1082
    AvgRAM                          : 16384
    MinRAM                          : 16384
    MaxRAM                          : 16384
    TotalDisk                       : 1382424
    ComputerName                    : xxxxxxxxxxxxxxxxxx
    VMId                            : xxxxxxxxxxxxxxxxxx
    VMName                          : Serveur de données
    HardDiskMetrics                 : {Microsoft.HyperV.PowerShell.VirtualHardDiskMetrics,
                                      Microsoft.HyperV.PowerShell.VirtualHardDiskMetrics,
                                      Microsoft.HyperV.PowerShell.VirtualHardDiskMetrics,
                                      Microsoft.HyperV.PowerShell.VirtualHardDiskMetrics...}
    MeteringDuration                : 00:00:24.2020000
    AverageProcessorUsage           : 1082
    AverageMemoryUsage              : 16384
    MaximumMemoryUsage              : 16384
    MinimumMemoryUsage              : 16384
    TotalDiskAllocation             : 1382424
    AggregatedAverageNormalizedIOPS : 8420 -> 7291 -> 10467 -> 13303
    AggregatedAverageLatency        : 28622 -> 12202 -> 21380 -> 19778
    AggregatedDiskDataRead          : 2052 -> 117522 -> 150623 -> 386621
    AggregatedDiskDataWritten       : 17 -> 1519 -> 2207 -> 6024
    NetworkMeteredTrafficReport     : {Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                                      Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                                      Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport,
                                      Microsoft.HyperV.PowerShell.VMNetworkAdapterPortAclMeteringReport}

    jeudi 10 juillet 2014 10:21
  • Bonjour,

    Il faudrait laisser mesure pendant un peu plus longtemps que 25 secondes pour avoir des valeurs réaliste: entre 1/2 journée et 1 journée pour bien faire :-)

    Avec les valeurs que vous donnez il faudrait une baie de stockage susceptible d'accepter une charge de 30000 IOPS en RAID10 (28351 exactement), soit 240 disques de 10KRPM, ou 162 disques de 15RPM, ou 5 SSD !

    Refaites les mesures sur une plus longue durée, puis nous verrons si c'est réellement un problème disque.

    Autrement, vous pouvez toujours dans un premier temps activer le cache CSV qui limitera les problèmes de performance en lecture, mais nécessite d'arrêter les VMs et de mettre en offline puis en online le CSV. Dans un deuxième temps, si les performances sont problématiques sur l'ensemble des VMs, il faudra limiter l'utilisation des IOPS sur les VMs les plus gourmandes pour redonner du soufle aux autres VMs.

    Bien cordialement,



    Guillaume http://www.vinfra.ch

    vendredi 11 juillet 2014 12:48
  • Bonjour guillaume

    En fait la 2° commande que vous m'avez donnée s’exécute en quelques sec, il doit me manquer une option pour le faire sur une demi journée ou alors il fallait attendre pour taper la 2° commande ? Donc là j'avais mis 4 mesures à 4 instants différents sur un espace de 2 heures.
    Je ne trouve pas tout à fait comme vous mais je pense que la formule RAID_Penalty n'est pas ecrite totalement dans votre precedent message ? avec 4 disque ca ne fait pas 4*2 ? J'ai aussi mis le calcul avec un raid-penalty à 2.
    Sinon tant que j'y suis comment calculez vous le nb de disques en fonction des IOPS ?
    Encore merci pour tout

    Serveur d'application
    1° mesure : 29,25
    2° mesure : 2538
    3° mesure : 4812
    4° mesure : 15550
    Moyenne : 4731


    Serveur de numérisation
    1° mesure : 58
    2° mesure : 3110
    3° mesure : 3882
    4° mesure : 8874
    Moyenne : 3981


    Serveur de données
    1° mesure : 8486
    2° mesure : 19349
    3° mesure : 27971
    4° mesure : 61290
    Moyenne : 29 259

    Total sur cette application : 
    Mesure 1 8 574,07   
    Mesure 2 24 998,82   
    Mesure 3 36 667,42   
    Mesure 4 81 715,91   
    Moyenne 37 989,05   

    Avec un RAID-penalty à 2 : 

    Total Application
    Mesure 1 8 412,07   
    Mesure 2 11 660,82   
    Mesure 3 16 963,42   
    Mesure 4 30 265,91   
    Moyenne 16 825,55


    • Modifié stef-VSTT vendredi 11 juillet 2014 14:05
    vendredi 11 juillet 2014 13:44
  • Le raid penalty est une valeur connue, c'est le nombre d'IOPS nécessaire pour chaque écriture d'1 IOPS système:

    RAID 0: 1

    RAID 1: 2

    RAID 10: 2

    RAID 5: 4

    RAID 6: 6

    Après pour le nombre de disques,  *en moyenne*, les disques ont les performances suivantes:

    SATA 7.2K: 75 IOPS

    SAS 10K: 125 IOPS

    SAS 15K: 175 IOPS

    SSD: ~6000IOPS

    (http://www.yellow-bricks.com/2009/12/23/iops/ ou autre)

    Ce ne sont pas des valeurs exactes mais suffisent pour de la planification hardware (on ne compte pas le cache ou les différents mécanismes d'optimisation des baies qui varient d'un constructeur à l'autre, mais ça permet d'être pas trop loin de la vérité). Après chaque constructeur a ses outils pour avoir les performances théoriques au plus proche.

    Donc au final, vous prenez la somme des IOPS de chaque VM, vous divisez par les performances disques, et vous avez leur nombre (le nombre d'axes donné par Christophe).

    Dommage que le format du forum ait déformé votre copier-coller :-( .

    Bon week-end.
    Bien cordialement,


    Guillaume http://www.vinfra.ch

    vendredi 11 juillet 2014 14:00
  • Alors avec la valeur raid penalty à 2, je trouve en cumulant les 3 serveurs

    VM_IOPS Nb de disques SAS 10KE 
    Mesure 1 8 412,07   67,30   
    Mesure 2 11 660,82 93,29   
    Mesure 3 16 963,42   135,71   
    Mesure 4 30 265,91   242,13   
    Moyenne 16 825,55   134,60 

    Quelque soit le cas, sans compter les autres VM de l'hyper-v, ca passe pas sur 24 disques, et là ma VM sgbd aurait besoin de 67 à 200 disques (moyenne à 117) alors qu'elle a 4 disques dans son RAID :)

    Je reprendrai des mesures mercredi mais je ne vois que la possibilité de prendre à plusieurs moments puis de faire la moyenne. Sinon maintenant que j'ai compris le principe, je dois aussi pouvoir passer par le moniteur windows perfmon de l'hyper-v, là j'aurai une moyenne sur une période sans doute. 

    Bon week end également



    • Modifié stef-VSTT vendredi 11 juillet 2014 14:27
    vendredi 11 juillet 2014 14:22
  • Lorsque vous faites enable-VMresourcemetering, celà active le moniteur. Tant que vous ne faites pas de reset-vmresourcemetering (qui remet les compteurs à 0) ou disable-vmresourcemetering, les valeurs moyennes sont valable sur cette durée (y compris si la VM est arrêtée !)

    Mercredi, en arrivant le matin, faites un enable + reset et laissez tourner jusqu'au soir, puis lancez le measure-vm, vous aurez les valeurs moyennes sur la journée.

    Pour la SGDB, j'ai effectivement relevé que c'était les plus gourmandes, mais en lecture essentiellement (~95-98% read, 2-5% write), c'est là que le cache CSV peut aider, si ce sont toujours les mêmes données qui sont lues.


    Guillaume http://www.vinfra.ch

    vendredi 11 juillet 2014 15:29
  • Parfait, alors le plus représentatif de la journée déjà mesuré est la 4° mesure qui a du se faire de 09h30 à 11h30 donc avec 

    - VM_IOPS serveur d'application à environ 2.900

    - VM_IOPS serveur de numérisation à environ 2.200

    _VM_IOPS serveur de données à environ 25.100

    Soit une totalité de VM_IOPS d'environ 30.000 effectivement, uniquement pour l'application en question.

    D'autre part faudra que je revois notre éditeur car pour lui l'application fait beaucoup d'écritures ;)

    Merci pour le mode opératoire et à mercredi soir alors ;)

    vendredi 11 juillet 2014 18:06
  • Effectivement, je trouve que les valeurs sont lunaires. Je n'ai aucune référence GED, mais je trouve que les valeurs de lecture des db sont assez importantes. Est-ce qu'il y a déjà beaucoup de data dessus ? Est-ce qu'il n'y a pas un antivirus qui multiplie les IOPS ? Est-ce que les secteurs sont bien alignés ? Quelle est la géométrie des disques (taille des secteurs) ? Sur quel OS tourne les bases de donnes ?

    Guillaume http://www.vinfra.ch

    samedi 12 juillet 2014 16:59
  • Bonsoir Guillaume

    J'ai cherché sur Internet des informations sur les données extraites de l'hyper-v. D'après ce que j'ai compris, AggregatedDiskDataRead et AggregatedDiskDataWritten sont des données cumulées alors que AggregatedAverageNormalizedIOPS est une moyenne.
    Or dans votre formule on parle d'IOPS donc par seconde.
    Donc je me suis peut etre trompé : si je prends la dernière mesure sur 2 heures et que je divise ces 2 compteurs par 7200 alors j'ai

    - VM_IOPS serveur d'application à environ 15 au lieu de 2.900

    - VM_IOPS serveur de numérisation à environ 2,6 au lieu de 2.200

    _ VM_IOPS serveur de données à environ 13.100 au lieu de 25.100. Il y a peu de changement car on reste sur une moyenne elevé (13300) avec de 99% lecture.
    dimanche 13 juillet 2014 18:04
  • Bonsoir,

    L'AggregatedAverageNormalizedIOPS est bien une moyenne, c'est la moyennes d'IOPS (lecture et écritures) générées au niveau disque du disque logique sur la durée donnée à la ligne MeteringDuration.

    Cette valeur permet d'avoir déjà un ordre d'idée du besoin en performances disque des VMs.

    Comme nous travaillons avec du RAID, les 2 autres valeurs nous permettent de de calculer, sur cette moyenne, la répartition entre lecture et écriture.

    Si la VM faisait 100% de lecture, nous aurions VM_IOPS = AggregatedAverageNormalizedIOPS + 0*2, c'est à dire qu'au niveau de la baie de disque, pour 1 IOPS logique, la VM à besoin d'1 IOPS physique.

    Si la VM faisait 100% d'écriture, avec le RAID penalty du RAID 10, égal à 2, nous aurions VM_IOPS = 0 + AggregatedAverageNormalizedIOPS * 2.

    Effectivement, je viens de relire la formule plus haut, il y a une coquille, il s'agit bien de AggregatedAverageNormalizedIOPS pour avgIOPS et non TotalIOPS pour l'écriture. C'est bien:

    VM_IOPS = (AggregatedAverageNormalizedIOPS * %Read) + (AggregatedAverageNormalizedIOPS * %Write * RAID_Penalty)

    Les DB sont très gourmandes en lecture quoi qu'il en soit, et c'est certainement la source de vos problèmes de performances ! 

    Si vous en avez la possibilité, activez le cache CSV sur votre cluster:

    (Get-Cluster).BlockCacheSize = 512

    512 pour 512MB, c'est de la mémoire qui sera pris sur chacun des Hyper-V pour mettre les données de lecture en cache.

    Sur Hyper-V 2012 R2, le cache est actif par défaut, mais =0... donc il suffit de modifier sa taille pour voir la différence. Aucun downtime.

    http://blogs.msdn.com/b/clustering/archive/2013/07/19/10286676.aspx

    Bien cordialement,


    Guillaume http://www.vinfra.ch

    dimanche 13 juillet 2014 21:44
  • Ok merci je vais voir ca

    Et pour les autres données : AggregatedDiskDataRead  et AggregatedDiskDatawrite, comme il semble que ce soit du cumulé il faudrait que je divise par meetingduration (c'est à dire par la durée sur lequel on mesure) non ?

    lundi 14 juillet 2014 12:31
  • Hello,

    Non car on ne s'en sert que pour avoir un pourcentage. L'unité au final est la même:

    Total_IOPS = AggregatedDiskDataRead  + AggregatedDiskDatawrite

    %Read = AggregatedDiskDataRead  / Total_IOPS 

    %Write = AggregatedDiskDatawrite Total_IOPS

    Bien cordialement,


    Guillaume http://www.vinfra.ch

    lundi 14 juillet 2014 12:43
  • Hello,

    Non car on ne s'en sert que pour avoir un pourcentage. L'unité au final est la même:

    Total_IOPS = AggregatedDiskDataRead  + AggregatedDiskDatawrite

    %Read = AggregatedDiskDataRead  / Total_IOPS 

    %Write = AggregatedDiskDatawrite Total_IOPS

    Bien cordialement,


    Guillaume http://www.vinfra.ch

    Pour simplifier les dires de Guillaume, tu peux utiliser :

    Get-VM | Measure-VM | select VMName,
        @{Label='TotalIOPS';Expression = {$_.AggregatedDiskDataRead + $_.AggregatedDiskDataWritten}},
        @{Label='%Read';Expression={"{0:P2}" -f ($_.AggregatedDiskDataRead/($_.AggregatedDiskDataRead + $_.AggregatedDiskDataWritten))}},
        @{Label='%Write';Expression={"{0:P2}" -f ($_.AggregatedDiskDataWritten/($_.AggregatedDiskDataRead + $_.AggregatedDiskDataWritten))}}
    



    Blog
    Scripts

    lundi 14 juillet 2014 18:40
  • Merci Emmanuel, c'est tellement plus simple avec un script :-)

    Je met de côté celui là !


    Guillaume http://www.vinfra.ch

    mardi 15 juillet 2014 08:21
  • Je suis en train de prendre les mesures, y a t il un pb à lancer la commande "Get-VM | Measure-VM | fl *" vers midi pour faire un premier point puis ce soir pour un deuxième point : ca ne remet pas à zéro d'après ce que j'ai compris ?

    Sinon quelques éléments de réponses :
    1) Quelle est la géométrie des disques (taille des secteurs)
    - taille des segments du RAID 10 où se trouve le sgbd : 64K. Il y a 4 disques SAS 10K.
    - Taille des segments du RAID 50 où se trouve le serveur d'application et de numérisation : 320K. Il y a 12 disques SAS 10K mais utilisés aussi pour d'autres VM.

    2) est ce que les secteurs sont bien alignés ?
    On a fait par défaut la création du stockage et VM donc je ne sais pas. Avez vous un bon lien sur ca ?

    3) Sur quel OS tourne les bases de donnes ?
    Windows 2012 R2 standard. La base est de l'Oracle 11

    4) Est-ce qu'il n'y a pas un antivirus qui multiplie les IOPS ?
    Non on ne l'a pas encore mis car on avait des pb de perf dès le début

    mercredi 16 juillet 2014 10:05
  • J'y perds mon latin ou plutot mon informatique :)

    Donc voici quelques données sur une journée de monitoring d'environ 08h30 à 17h30 :
    - serveur de numérisation : avgiops=52, avglatency=10042, readIOPS=338, writeIOPS=4497, donc en raid50 => 18.326 VM_IOPS soit 147 disques SAS 10 K
    - serveur d'application : avgiops=1, avglatency=893, readIOPS=1537, writeIOPS=3068, donc en raid50 => 13.809 VM_IOPS soit 110 disques SAS 10 K
    - serveur de données : avgiops=3434, avglatency=11942, readIOPS=1292846, writeIOPS=29457, donc en raid10 => 1.351.760 VM_IOPS soit 10.814 disques SAS 10 K

    Bizarrement, sur la totalité des serveurs, j'ai des valeurs assez importantes 
    - mes controleurs de domaine font entre 1000 et 3000 VM_IOPS soit 10 à 30 disques
    - le serveur bureautique fait 4700 VM_IOPS soit 37 disques (pour 100 personnes mais la moitié en congés)
    - les serveurs de la compta (5 personnes) font entre 200.000 et 300.000 VM_IOPS soit 1.738 disques pour celui de pre prod et 2.677 pour la prod
    - le serveur horaire variable fait 45000 VM_iops soit 366 disques
    Bref, au total, cela fait sur la baie 2.159.769 VM_IOPS soit 17.278 disques SAS 10 K

    ---------------------

    En terme de pourcentage, le serveur sgbd de l'application prend 68% du total_iops de la baie et 63% du VM_IOPS de la baie

    ------------------------------------

    Je me repose la question de la durée (faut diviser par le timeduration (qui ne s'affiche pas d'ailleurs)) car quand je regarde le perfmon windows j'ai les valeurs suivantes pour le seveur de données :
    - Lectures disque / sec : 120 à 15h30 et 60 à 16h30
    - Ecritures disque / sec : 250 à 15h30 et 60 à 16h30
    Et si je divise le totalIOPS par 11h*3600s alors j'ai 33.4 ce qui est assez proche du perfmon à un instant t. Et si je divise le VM_IOPS par cette valeur alors j'ai 34.1.

    On aurait alors 0.27 disques (33.4/125) pour le sgbd pour un total de 0.44 disques pour la baie.




    • Modifié stef2014 jeudi 17 juillet 2014 06:53
    mercredi 16 juillet 2014 16:28
  • Hello, Non, on ne passe pas de 52 IOPS logiques à 18000 pour 4 VMs je vous rassure ! Il faut utiliser avgIOPS pour vos calculs et non totalIOPS ou, comme vous l'avez dis à la fin, diviser par la durée pour avoir la bonne valeur. A vue de nez, à votre place j'inverserai les app+num qui écrivent beaucoup avec les DB qui lisent beaucoup. Là il est un peu tard pour détailler, mais je refais le point demain dans la journée. :-) Et non, measure-vm ne remet pas les compteurs à zéro. Il faut faire un reset ou disable pour remettre à zéro (pas sur pour le disable soit dit en passant). Bien cordialement,

    Guillaume http://www.vinfra.ch

    mercredi 16 juillet 2014 23:16
  • Bonjour,

    Pour les applications, le profile est plutôt orienté en écriture (Read/Write: 33%/66%).

    En Raid 10 (Penalty = 2), chaque VM utilise en moyenne 1,6 IOPS, soit environ 7 IOPS pour les 4 serveurs;
    En Raid 50 (Penalty = 4, je crois), chaque VM utilise en moyenne 3 IOPS, soit environ 12 IOPS pour les 4 serveurs;

    Pour les numérisations,le profile est plutôt orienté en écriture (Read/Write: 7%/93%).

    En Raid 10 (Penalty = 2), chaque VM utilise en moyenne 100 IOPS, soit environ 400 IOPS pour les 4 serveurs;
    En Raid 50 (Penalty = 4, je crois), chaque VM utilise en moyenne 197 IOPS, soit environ 788 IOPS pour les 4 serveurs;

    Pour les databases, le profile est plutôt orienté en lecture (Read/Write: 97%/3%).

    En Raid 10 (Penalty = 2), chaque VM utilise en moyenne 3510 IOPS, soit environ 14042 IOPS pour les 4 serveurs;
    En Raid 50 (Penalty = 4, je crois), chaque VM utilise en moyenne 3663 IOPS, soit environ 14653 IOPS pour les 4 serveurs;

    En conclusion, si vous n'êtes pas limité en espace, et sans prendre en considération les éventuelles optimisation du cache de la carte RAID:

    • Les VMs d'application peuvent être migrées sur un volume en raid 10, soit un gain de 5 IOPS au total (pas sûr que le coût en vaut la chandelle vu le gain anecdotique);
    • Les VMs de numérisation peuvent être migrées sur un volume en raid 10, soit un gain de 387 IOPS (soit l'équivalent de 3 disques SAS10K);
    • Les VMs de SGDB peuvent rester sur le RAID 10, tant que l'espace disque ne se fait pas ressentir. Par contre 4 disques ne peuvent accepter que 300 IOPS en lecture.
    • Les bases de données pourraient travailler confortablement sur 113/118 SAS10K, 81/83 SAS15K, ou 3 SSD (la solution sans doute la moins chère).

    En quickwin, qui ne coûte rien, activez le cache CSV comme discuté plus haut (1-2GB), un reboot des hyper-v est nécessaire pour garantir la réservation du cache. Puis monitorez la charge de la baie HP avec les outils HP (au mieux) pour voir si il y a un gain d'IOPS.



    App Num DB
    AvgIOPS 1,0 52,0 3434,0
    Read 1537,0 338,0 1292846,0
    write 3068,0 4497,0 29457,0
    TotalIOPS 4605,0 4835,0 1322303,0
    %Read 0,334 0,070 0,978
    %Write 0,666 0,930 0,22
    VMIOPS RAID10 1,7 100,4 3510,5
    VMIOPS RAID50 3,0 197,1 3663,5
    Total RAID10 (x4) 6,7 401,5 14042,0
    Total RAID50 (x4) 12,0 788,4 14654,0

    Encore une fois, c'est valable pour la période mesurée, plus vous aurez de mesures pour faire votre moyenne, plus vous pourrez affiner ces valeurs. 

    L'autre piste à approfondir est de comprendre d'où viennent ces valeurs de lecture très intensives des serveurs Oracle. Est-ce que c'est un fonctionnement normal et attendu ou un problème de configuration des bases de données ? Combien de documents sont traités/consultés par la GED par seconde ? Quelle est la taille moyenne des documents traités/consultés ? Si un block fait 64KB, cela reviendrait à un volume d'environ 14042*64KB/1MB = 877Mo/s...ou 51Go/min !

    Bien cordialement,


    Guillaume http://www.vinfra.ch



    • Modifié Guigui38 jeudi 17 juillet 2014 14:42
    jeudi 17 juillet 2014 14:39
  • Pour être certain de tout avoir compris, je reprends les éléments que vous m'avez fournis (un grand merci encore) :

    J'étais parti sur la formule avec le "totalIOPS" donc effectivement on a pas la même chose :)
    Donc avec la formulule VM_IOPS = (AggregatedAverageNormalizedIOPS * %Read) + (AggregatedAverageNormalizedIOPS * %Write * RAID_Penalty), j'ai bien
    - VM_IOPS du serveur de numérisation : 3
    - VM_IOPS du serveur d'application : 197
    - VM_IOPS du serveur de données : 3510 donc 28 disques SAS 10K, c'est ca ?
    Mais il n'y a qu'un serveur à chaque fois, avec le serveur de num et celui d'application qui sont sur un RAID50 de 12 disques (utilisé par d'autres VM qui ne font par partie de l'appli) et le serveur de données qui est sur un RAID10 de 4 disques (dédié à cette VM).
    On a pas besoin de multiplier alors ?

    J'ai vu sur Internet (http://workinghardinit.wordpress.com/2014/01/08/how-to-measure-iops-of-a-virtual-machine-with-resource-metering-and-measurevm/) que l'average était pris sur les 20 dernières secondes, donc ca veut dire qu'il faut que je peux prendre plusieurs mesures dans la meme journée sans remettre à zéro les compteurs ?
    Si c'est le cas l'average pris à 17h30 est moins représentatif car moins de personne et pas de numérisation.
    A ce moment là si je reprends les mesures que j'avais faites dans la première journée (cf + haut dans le forum), on a :
    - VM_IOPS du serveur de numérisation : 78 IOPS sur la moyenne des 4 mesures et pic à 153 IOPS, soit 3.1 disques sur le pic
    - VM_IOPS du serveur d'application : 162 IOPS sur la moyenne des 4 mesures et pic à 390 IOPS, soit 1.2 disques sur le pic
    - VM_IOPS du serveur de données : 10.000 IOPS sur la moyenne des 4 mesures et pic à 13.507 IOPS, soit 80 disques en moyenne et 108 sur le pic
    Exemple du pic sgbd : avgIOPS=13.303 (donc à 10h30), ReadIOPS=386621 (de 08h30 à 10h30), WriteIOPS=6024 (de 08h30 à 10h30).

    Pour finir, de que je comprends l'IO réprésente une entrée sortie sans prise en considération de la taille de cette entrée sortie ? Donc si je reprends le chiffre de 3510 IOPS pour le serveur de données on a (3510io/s*64Ko)/1024ko=220 Mo/s, soit 220*60/1024 = 12.9Go/min, mais aussi 1760 kbit/sec sur un lien Iscsi à 1Gbit/sec !
    Et si je prends les 10.000 iops alors je me retrouve avec 625 Mo/sec, soit 5 Gbits/sec (5 fois le lien iscsi) !  
    J'ai bien tout compris ?

    Sur la baie complète sur la journée de 11h avec l'utilisation d'average, j'ai : VM_IOPS=4500, soit 36 disques SAS 10KE et 4.200 Mbits/sec.

    Sinon pour information, la base fait 300 Go. Il y a 2 liens Iscsi 1 Gb/s par hyperv et 2 liens actifs (+1 passif) de 1 Gbit/s en teaming (routage par la source) vers le réseau de prod

    • Modifié stef-VSTT jeudi 17 juillet 2014 21:31 rajout baie complete
    jeudi 17 juillet 2014 20:46
  • Bonsoir, Intéressant ! Étant donné que ces valeurs ne sont pas documentés chez MS (doc pas à jour), j'ai faussement pensé que comme pour avgCPU et avgram, la valeur moyenne était sur l'intervalle meteringduration ! Donc effectivement, il est préférable d'utiliser totalIOPS/MeteringDuration pour avoir une moyenne juste (que je n'ai pas calculé pour vérifier). De la même manière, le bloc de l'IO est-il celui du physical sector du VHDX (ce qui paraît plus juste car à 4K), ou celui du CSV ? Dommage que je n'ai pas le temps de tester, ces questions soulèvent ma curiosité ! Du coup il y a 1 ou 4 serveurs pour chaque fonction ? Bien cordialement,

    Guillaume http://www.vinfra.ch

    jeudi 17 juillet 2014 21:38
  • Il y a 1 serveur par fonction donc 3 serveurs pour cette application.

    Je recalcule demain avec les durées de 11 heures mais j'ai des chiffres bien différents. En même temps l'average à un instant t reflète quand même l'utilisation à un instant t donc par exemple les pics.

    jeudi 17 juillet 2014 21:44
  • Bon alors si on utilise VM_IOPS = (TotalIOPS* %Read) + (TotalIOPS * %Write * RAID_Penalty) qui est une formule qui existe aussi sur Internet (cf yellow-bricks.com) et qu'on divise par le temps total de mesure (les 11 heures) alors on a des chiffres bien différents :
    Elise-app : AggregatedAverageNormalizedIOPS=1, AggregatedAverageLatency=893, AggregatedDiskDataRead=1 537, AggregatedDiskDataWritten=3 068 =>  VM_IOPS sur 11h = 13809 => VM_IOPS divisé par 11*3600s = 0.35 => 0.001 disque :)
    Elise-num-pp: avg=52,avgLatency=10 042, Read=338, Written=4 497 => VM_IOPS sur 11h = 18326, => VM_IOPS divisé par 11*3600s = 0.46 => 0.003 disque :)
    Elise-sgbd: avg=3 434, avgLatency=11 942, Read=1 292 846, Written=29 457 => VM_IOPS sur 11h = 1 351 760 =>  VM_IOPS divisé par 11*3600s = 34.14 => 0.273 disques :)

    Et sur le total de la baie (33 VM) : 2 159 769 "VM_IOPS" sur 11h => 55 iops => 0.436 disques

    Bref, la formule n'a pas l'air cohérente cohérente avec les données collectées. La moyenne semble plus représentative.

    vendredi 18 juillet 2014 07:00
  • Tout a fait ! J'ai trouvé plus de détails sur cette session sur les metrics: http://video.ch9.ms/sessions/teched/na/2013/MDC-B345.pptx La mesure est bien faite sur 20s, et un IOPS jusqu'à 8K compte pour 1 "normalized". A approfondir, mais il semble que le bon vieux perfmon n'a pas encore tiré sa révérence !

    Guillaume http://www.vinfra.ch

    vendredi 18 juillet 2014 07:07
  • Bonjour,

    Du coup j'ai repris les valeurs sur 11h avec les bonnes valeurs de RAID:


    Application Numérisation  SGDB
    Read 1537 338 1292846
    write 3068 4497 29457
    TotalIOPS 4605 4835 1322303
    %Read 0,334 0,07 0,978
    %Write 0,666 0,93 0,22
    AvgIOPS 0,116287879 0,12209596 33,3914899
    VM_IOPS 0,348631061 0,462743687 47,3491327

    Effectivement, cela semble plus réaliste (ouf !). Concernant les pics de charge, il sont normaux et sont -à priori- (je suis loin d'avoir la connaissance absolue dans le sujet !), à la fois pris en charge et "lissés" par la queue et par le cache. 

    Désolé, j'aurais dû le voir dès le départ. Mais on en apprend tous les jours :-)

    Donc retour au point de départ, le problème *ne semble pas* venir du disque, d'autant que la latence est correcte.

    Retour à la case départ !

    - Les options d'économies d'énergie sont elles bien désactivées au niveau du bios ? Maximum performance de rigueur sur de la virtu ! J'ai déjà vu des comportements très étranges quand c'est configuré sur "balanced".

    Bien cordialement,


    Guillaume http://www.vinfra.ch

    vendredi 18 juillet 2014 10:16
  • Merci pour les calculs car je me rends compte que je n'ai pas pris la bonne métrique pour AvgIOPS, j'étais parti sur avgIOPS avec avgIOPS=Average Normalized IOPS mais comme cette valeur est prise sur les derniers 20sec cela n'est pas représentatif d'une mesure sur 11 heures. Donc là je vous suis si on prend comme vous l'avez fait AvgIOPS=TotalIOPS/(11*3600).
    Par contre je suis à VM_IOPS à 34.135 sur le SBGD mais on est pas à ca près :)

    Donc sur toute la baie cela ferait VM_IOPS=54.54 soit 0.44 disques SAS RAID10.
    En fait cela donne les mêmes valeurs qu'avec la formule VM_IOPS = [(TotalIOPS* %Read) + (TotalIOPS * %Write * RAID_Penalty)] / Temps de la mesure en sec
    Ca m'étonne quand même ;) mais c'est plus proche du perfmon (lecture ou ecriture /sec)

    Perfmon   15h30 16h30
    Lectures disque / sec 120 63
    Ecritures disque / sec 250 63
    TotalIOPS   370 126
    %Read   0,324 0,500
    %Write   0,676 0,500
    VM_IOPS   376,757 94,500
    Nb HD   3,014 0,756
    Mo/s   117,736 29,531
    Mbit/s   941,892 236,250

    J'ai escaladé auprès de notre partenaire qui va se rapprocher de constructeur/editeur pour avoir plus d'infos. Je vous tiens au courant.

    Pour les tailles des IO d'après un DBA, il faut les prendre sur l'hyper-v (donc la taille segment windows 2012) car les mesures sont prises sur l'hyper-v. Là j'avais pris la taille des segments des RAID. Je n'ai pas encore regardé quelle est cette taille par défaut sur win2012.

    Non pour l'instant on a pas fait les options d'économies d'énergie encore. Là on a mis ces 3 VM sur le cluster de secours pour isoler le tout mais c'est pas mieux. Ce week end on va faire les mises à jour WSUS et firmeware baie déjà.
    Mais on va le faire déjà dans les VM déjà car pour le bios il faut qu'on trouve un autre créneau d'arret total.

    Encore merci

    vendredi 18 juillet 2014 19:12
  • Si c'est sur un cluster, il suffit de mettre 1 nœud en mode maintenance (ou pose si vous n'utilisez pas vmm) et de migrer toutes les VMs sur le nœud suivant. Ça ne nécessite pas l'arrêt des VMs (l'avantage du cluster). Sinon par défaut, la taille des blocks est celui présenté sur la LUN, qui est en général soit de 512 bytes, soit 4096 bytes. De même, vous pouvez vérifier la taille des secteurs physique et logiques du VHDX avec un get-vhd. Bon courage !!

    Guillaume http://www.vinfra.ch

    vendredi 18 juillet 2014 19:49
  • Bonjour

    Des nouvelles de nos tests.

    Nous avons réussi à très bien bien faire tourner l'application sur le cluster de secours qui a lui 24 disques en RAID50. Les utilisateurs étaient ravis mais retour arrière pour cause de licence pour l'instant.

    Par contre sur le cluster actif c'est toujours pas l'idéal mais on a "que" 12 disques en RAID50 et on partage avec 30 autres VM.
    On a bien activé le mode haute performance sur le bios des hyper-v + sur les hyper-v + sur les VM.
    On a bien activé le cache CSV à 1Go par hyper-v
    Et on a passé toutes les mises à jours WSUS.
    Les résultats des mesures sur la baie montre quand meme des temps de réponse autour de 5ms (avec 12 disques RAID50) au lieu de 10 à 20 ms avant (4 disques RAID10), mais c'est moins visible pour les utilisateurs.

    Côté formule, j'ai laissé de côté car je vois des gens qui disent de ne pas tenir compte du raid-penalty avec les mesures hyper-v :) Et j'ai trop de différence avec le perfmon.

    Bon, bref, comme il nous reste 12 disques dispo, on va déjà en rajouter 6 sur le RAID50 en espérant que cela rajoute des IO à bon escient :)

    A suivre :)

    vendredi 25 juillet 2014 18:32
  • C'est vrai qu'à travers les post, nous nous sommes concentré sur l'infra GED et nous n'avons pas trop regardé la charge des autres VMs, c'est ce qui peut faire la différence.

    Ajouter des disques ne fera pas de mal dans tous les cas.

    Concernant la formule, elle est valable quelque soit le système (hyper-V, vmware, linux, windows, sql, oracle...) mais il faut garder à l'esprit qu'elle donne un ordre de grandeur pour dimensionner une vaie de stockage et ne prend pas en compte:

    • le type de workload (un workload qui a des écritures en séquentiel n'aura pas les mêmes performances qu'un workload avec des écritures aléatoires);
    • Les différentes optimisations du SAN ou des cartes RAID;
    • Du cache en lecture/écriture offert par le SAN;
    • Les différentes optimisations de l'hyperviseur ou de l'operating system;

    Pour un peu plus de détails: http://wintelguy.com/2013/20130406_disk_perf.html

    Et concernant Hyper-V et le RAID penalty, vous parlez certainement de configurations avec du Storage Spaces, qui a un mode de fonctionnement un peu différent du stockage RAID classique, mais le "RAID Penalty" est en vérité toujours existant.

    Pour plus de détails sur les performances de storage spaces: 

    http://social.technet.microsoft.com/wiki/contents/articles/15200.storage-spaces-designing-for-performance.aspx

    http://channel9.msdn.com/events/TechEd/NorthAmerica/2014/DCIM-B311

    http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B346

    Merci de votre retour dans tous les cas !

    Bien cordialement,


    Guillaume http://www.vinfra.ch

    lundi 28 juillet 2014 09:07
  • Bonjour

    Finalement les utilisateurs commencent à retrouver le sourire, c'est mieux.

    Par rapport à ce que vous écriviez juste avant, ci joint des mesures de performances où l'on voit l'activité très importante du serveur de données (sgbd) par rapport aux autres VM, en particulier en lecture : 90% des 30 VM, 10 fois plus que le total des autres VM,  10 fois plus que celui qui consomme le plus en 2° alors qu'il y avait un traitement de masse dessus.

    Côté compteur, vous verrez que j'ai mesuré par hyper-v des IOPS entre 2 heures données et en moyenne sur la journée, en gros j'ai du 70 IOPS. Par contre si je prends les pics AggregatedAverageNormalizedIOPS et que je divise par les 20s (j'espère que c'est ca) alors j'ai environ 750 IOPS. Et si je prends le perfmon alors j'ai les transferts disque par seconde (donc les IOPS en théorie) à 260 sur une journée de 08h-16h et des pointes à 4200. C'est en ce sens que je dis que les mesures sont très différentes en fonction des outils.

    Compteurs Hyper-v perfmon et baieEncore une question :

    Nous avons donc agrandi le RAID50 à 18 disques et mis les disques (vhdx) des 3 serveurs dans des volumes déjà existants du RAID 50.  Y a t il un intérêt en terme de performance à créer un nouveau volume (dans ce RAID50) dédié à ces 3 serveurs ?

    • Modifié stef-VSTT dimanche 3 août 2014 12:38 ajout question
    jeudi 31 juillet 2014 15:47
  • Bonjour

    Je dispose d'un Serveur HP avec 2 proc , 96 Gb de Ram et 3 TB de disque comme Hyper V , sur le quel j'ai créer 3 VM , sur l'un des VM , avec 64 Gb de Ram et 2 Proc virtuel, nous avons constaté que le taux d'occupation du Proc est trop élevé même si c'est un seul user qui est connecté sur ce Serveur.

    Je souhaite ainsi avoir votre support pour la résolution de ce problème de PIC au  niveau processeur.

    Alaska

    alassanek@gmail.com

    lundi 9 février 2015 15:33