«
»

storageRM level 1

Posted by NiTRo | Filed under Kb, Performance, Tips & Tricks, VMware

Instruit par la kb Troubleshooting Storage I/O Control (1022091), nous nous sommes rendu compte qu’en fixant le log level à 1, le service storageRM crachait les informations de latency, qdepth et iops des datastores concernés dans les logs d’ESXi (et donc vers le(s) serveur(s) syslog) toutes les 4 secondes. Sur une grosse infra ça peut faire beaucoup mais ça offre de belles perspective de monitoring/troubleshooting :

Et voici le oneliner PowerCLI pour le faire vite et bien :

Get-View -ViewType HostSystem|?{$_.Runtime.ConnectionState -eq "connected" -and $_.config.product.ProductLineId -eq "embeddedEsx" -and ($_.Config.Option|?{$_.Key -eq "Misc.SIOControlLogLevel"}).Value -ne "1"}|%{(Get-View $_.ConfigManager.AdvancedOption).UpdateOptions((New-Object VMware.Vim.OptionValue -Property @{Key="Misc.SIOControlLogLevel";Value=[Int64]1}))}

Tags: , , , , ,

Comments (9) | August 8th, 2014

9 Responses to “storageRM level 1”

  1. Vincent T Says:
    August 26th, 2014 at 15:02

    En effet très sympa. J’ai du coup trouvé quelques problèmes de config NFS, le root squash ayant été mal configuré. Ca commence à prendre forme. Je coince sur les regexp des extracteurs de graylog2. Un lien quelque-part sur des extracteurs syslog vmware pertinents quelquepart ?

    Merci !

  2. NiTRo Says:
    August 26th, 2014 at 15:32

    Oui, très bientôt sur http://www.graylog2.org/extractors

  3. Stephane G Says:
    June 15th, 2016 at 8:19

    Bonjour,
    Est-ce que vous confirmez qu’il faut bien la version Entreprise Plus pour activer le Storage I/O et donc avoir les logs ?
    Merci bien.

  4. NiTRo Says:
    June 17th, 2016 at 8:55

    Je vous confirme que non : http://www.virtuallyghetto.com/2010/10/does-sioc-actually-require-enterprise.html
    Et en ce qui concerne les logs, je vais vérifier car je pense que c’est l’I/O Injector qui les génèrent donc il se peut que cela ne soit pas soumis à licence http://frankdenneman.nl/2012/02/09/storage-drs-io-load-balancing-and-array-based-auto-tiering/

  5. Stephane G Says:
    June 17th, 2016 at 13:21

    Bonjour,

    Merci pour votre réponse.
    Je viens de passer la commande suivante sur les ESXi et les logs commencent à se remplir :
    esxcfg-advcfg -s 1 /Misc/SIOControlLogLevel

    Dans le dashboard sexilog je les vois en “storageRM”.
    Mais par contre je ne les vois pas dans la partie IOPS/IORM.

    Les trames ressemblent à ça :
    2016-06-17T12:18:57.397Z: 4:ESX1 myavglat= 1.00, mycount= 2 myoio= 0.00 myws= 256 mycounter 392394 mybeta= 4.00 totalAvgLat = 0.65
    2016-06-17T12:19:01.399Z: Sleep delta = 4002.542973, Sleep Time = 4000
    2016-06-17T12:19:01.400Z: 4:ESX1 myavglat= 0.00, mycount= 1 myoio= 0.00 myws= 256 mycounter 392395 mybeta= 4.00 totalAvgLat = 0.65

    Ce qui est étrange aussi c’est que je n’ai qu’un volume (mais bon si ce n’est que ça je pourrai ouvrir un ticket chez VMware) :
    2016-06-17T12:19:17.405Z: getting state for NFS volume VOL_SAS_FILES (10G)
    2016-06-17T12:19:17.410Z: Found device VOL_SAS_FILES (10G)
    2016-06-17T12:19:17.410Z: getting state for NFS volume VOL_SSD (10G)
    2016-06-17T12:19:17.410Z: getting state for NFS volume VOL_SAS_DATA3 (10G)
    2016-06-17T12:19:17.410Z: getting state for NFS volume VOL_SAS_DATA2 (10G)
    2016-06-17T12:19:17.410Z: getting state for NFS volume VOL_SAS_DATA1 (10G)
    2016-06-17T12:19:17.410Z: getting state for NFS volume VOL_PROFILS
    2016-06-17T12:19:17.410Z: getting state for NFS volume VOL_DATA

    Merci encore.

  6. NiTRo Says:
    June 17th, 2016 at 15:22

    Bonjour, bonne nouvelle. Les dashboards IOPS et IORM sont à configurer avec les noms (ou regex) de vos datastores.

  7. Stephane G Says:
    June 17th, 2016 at 16:12

    Merci ça marche impec.
    Il me reste plus qu’à trouver pourquoi un seul datastore remonte et ce sera parfait.

  8. NiTRo Says:
    June 20th, 2016 at 10:43

    Tu peux utiliser la commande de ce post pour activer la collecte seulement : http://www.hypervisor.fr/?p=4264
    FYI, il me semble que la collecte est activée par défaut depuis vSphere 6.0

  9. Stephane G Says:
    June 20th, 2016 at 17:58

    J’ai compris pourquoi les logs de certains datastore ne remontaient pas. Il faut décocher une case dans les propriétés de la banque de données au niveau de SIOC mais uniquement depuis le vsphere web client (pas depuis le client C#).

    Pour répondre à ta question ça m’a fait réfléchir et je comprends pourquoi sur mon nouveau volume les logs étaient activés. C’est parce que les autres volumes (qui ne fonctionnaient pas) étaient créés avec un VCSA 5.
    Le dernier volume (qui fonctionnait) était créé avec un VCSA 6.

    Merci pour tout.

Leave a Reply