SolidFire vs Heartbeat ATS

Nous avons rencontré un cas intéressant sur une nouvelle plateforme VDI qui est hébergée sur des baies SolidFire. Lors de test de démarrage massif de machines virtuelles (boot storm), nous perdions la main sur les serveurs ESX, qui passaient en ‘Not Responding’ sur le vCenter, avec hostd unresponsive dès le moment où nous voulions effectuer des actions locales (console et/ou SSH).

En fouinant sur le net, nous sommes tombé sur une KB IBM qui détaille un comportement similaire : Host Disconnects Using VMware vSphere 5.5.0 Update 2 and vSphere 6.0 et qui met en cause le nouveau comportement du Heartbeat ATS depuis la version vSphere 5.5U2, à savoir l’offload de la partie heartbeat I/O à la baie via la primitive VAAI ATS.

heartbeat

En continuant à chercher sur cette piste, nous sommes retombés sur un très bon article de Cormac qui détaille un peu plus ce mécanisme, et surtout le changement depuis la version 5.5U2 : Heads Up! ATS Miscompare detected between test and set HB images

Aujourd’hui une KB officielle VMware existe pour ce souci : KB2113956, dont voici un extrait qui détaille le changement de comportement du heartbeat ATS avant et après 5.5U2 :

A change in the VMFS heartbeat update method was introduced in VMware vSphere ESXi 5.5, Update 2 to help optimize the VMFS heartbeat process. Whereas the legacy method involves plain SCSI reads and writes with the VMware ESXi kernel handling validation, the new method offloads the validation step to the storage system. This is similar to other VAAI-related offloads.
This optimization results in a significant increase in the volume of ATS commands the ESXi kernel issues to the storage system, and resulting increased load on the storage system. Under certain circumstances VMFS heartbeat using ATS may fail with false ATS miscompare which causes the ESXi kernel to reverify its access to VMFS datastores. This leads to the Lost access to datastore messages.

Le Support Request qui avait été ouvert auprès de SolidFire confirme plus ou moins ce problème, voici un extrait de leur réponse :

SF is a 4K block size array internally but ESX only works with 512-byte blocks. ESX issues single 512-byte block ATS commands, which requires the SF array to perform an internal read-modify-write for every ATS command. If ESX could issue a 4K ATS command (eight 512-byte blocks) our ATS performance should be better. Essentially, every ATS operation is an unaligned I/O.

La recommandation finale a été de désactiver la partie Hearbeat ATS pour rebasculer sur des réservations SCSI-2 classiques (pour la partie Heartbeat uniquement bien entendu).

Cela peut se faire en PowerCLI comme l’indique la KB VMware:

Get-AdvancedSetting -Entity VMHost-Name -Name VMFS3.UseATSForHBOnVMFS5 | Set-AdvancedSetting -Value 0 -Confirm:$false

Nous verrons dans un prochain billet la modification d’un autre paramètre, DelayedAck

Évènement Veeam et SexiLog

Pour ceux qui sont intéressé par SexiLog et/ou par Veeam™, ou ceux qui souhaitent en apprendre un peu plus sur l’intégration entre ces 2 (merveilleux ^^) outils, nous allons participer à un évènement organisé par Veeam™ dans leurs locaux.

Cette session, nommée « Mieux comprendre vos logs et gardez votre infrastructure en bonne santé cet été! » consistera en une session « Veeam Whiteboard » et se déroulera le 23 juillet 2015 à partir de 14H.

banner

L’idée de ce whiteboard sera de présenter la solution SexiLog (un peu dans le même principe qu’au dernier meetup Elastic) et de voir plus en profondeur son intégration avec Veeam Backup™ (les différents dashboards proposés et ce qu’il est possible de faire avec les 2 solutions).

De plus, vu que ce sera en direct, vous pourrez poser toutes questions que vous voudrez, nous essayerons de vous répondre du mieux que nous pourrons 🙂

Challenge-Accepted-Meme

Pour ceux qui voudraient s’inscrire et/ou qui souhaitent avoir plus d’infos sur l’évènement, vous pouvez retrouver tout ce que vous auriez besoin sur la page dédiée à la session: http://www.veeam.com/fr/veeamlive/comment-proteger-efficacement-votre-environnement.html

Pour finir, voici un petit recapitulatif de la session :

Veeam et Sexilog vous présentent : Mieux comprendre vos logs et gardez votre infrastructure en bonne santé cet été !

Jeudi 23 Juillet 14:00 СEST (GMT+2:00)

SexiLog est une appliance VMware de la suite ELK spécialement configurée et optimisée pour les logs d’ESXi. L’importante configuration de Logstash et les nombreux dashboard Kibana embarqués vous permettent de surveiller la santé de votre infrastructure vSphere en temps réel et de prendre le recul nécessaire pour traiter vos incidents. En cas de problèmes, Logstash transfert à Riemann qui vous enverra un résumé des alertes par mail.

Ajoutez à votre calendrier S’inscrire

Nous tenions vraiment à remercier Samir et Veeam™ pour nous donner cette opportunité de vous présenter SexiLog!

Your VMware logs, supercharged.

La video du whiteboard est disponible ici :

SexiLog

Ceux qui suivent l’actualité twitter sont déjà un peu au courant, mais nous voulions partager à tous nos lecteurs la grande nouvelle de ce lundi 23 Mars, 13h37, à savoir la sortie officielle de SexiLog !

1500x500

Ce billet n’est pas là pour paraphraser le site officiel (nous vous laissons allez voir par vous-mêmes), mais plus pour vous expliquer un peu l’histoire derrière SexiLog et en quoi vous allez adorer l’utiliser 🙂

L’idée de faire une appliance toute prête pour gérer les logs VMware remonte à pas mal de temps. A l’époque, nous avions commencé à travailler avec @hypervisor_fr sur une solution utilisant Graylog2, mais cela n’avait pas abouti pour diverses raisons ^^ Nous avons donc du repenser la chose en cherchant d’autres outils, et nous avons finalement trouvé notre bonheur avec la stack ELK: ElasticsearchLogstashKibana. Nous avons par contre été obligés de recommencer tout à zéro afin de retranscrire le travail fait auparavant pour l’intégrer sur la nouvelle appliance (par exemple la transposition des « streams » de Graylog2 en règles Grok de Logstash), mais le jeu en valait la chandelle!

Après pas mal de boulot, un soupçon de passion et des milliards de logs, nous vous proposons SexiLog pour votre plus grand bonheur!

Pour résumer très rapidement, SexiLog est une appliance ELK préconfigurée pour tout environnement vSphere. Elle est disponible au format OVA ce qui vous permet de la déployer rapidement et de pouvoir en profiter en quelques minutes.

Une image vaut souvent mieux qu’un long discours, donc pour honorer cet adage, SexiLog c’est ça :

features

Et ça vous permet d’avoir ça :

.

Sur le site sexilog.fr vous trouverez toutes les informations nécessaires pour :

  • Déployer l’appliance sur vos plateformes > QuickStart
  • Faire votre propre appliance, aka Build Your Own Sexilog > Cookbook
  • Accéder à la documentation de l’appliance > #RTFM
  • Naviguer dans la galerie de dashboards créés dans l’appliance et disponibles en direct via la page GiST de SexiLog > SexiBoards

Le projet est hébergé sur Github, tous les fichiers de configuration utilisés dans SexiLog sont disponibles dans le repository sexilog. Vous pourrez aussi visiter la page Issues si vous rencontrez un problème, si vous avez une idée ou pour donnez votre avis.

Si vous avez créé vos propres SexiBoards et que vous souhaiteriez les voir intégrer à SexiLog, n’hésitez pas à nous contacter, nous pourrions les rajouter dans les futures versions !

Il reste encore pas mal de choses à finir et à faire (notamment le passage à Kibana 4), nous vous tiendrons informé au fur et à mesure. Sur ce, bonne visite sur sexilog.fr et bonne recherche !

Get it, try it, adopt it and enjoy yourself!

 

~Unknown geek

vExpert 2015

VMware vient de publier la liste des vExpert pour l’année 2015 (disponible ici avec un peu plus de 1000 entrées) et c’est avec honneur que je reçois cette nomination. Nous tenons à vous remercier pour vos commentaires et votre soutien!

Il y aura un autre tirage en milieu d’année (pour ceux qui veulent retenter, ou qui ont oublié de s’inscrire ^^ ) comme indiqué dans l’article:

We will open the second half 2015 applications soon which will only allow for two voting periods this year rather then the three we had last year.

Et pour feter ca, on a « Warholé » le logo 🙂

vExpert

Graylog2 et Powershell: le meilleur des 2 mondes

Si vous utilisez déjà Graylog2 ou si vous voulez l’utiliser (si ce n’est pas encore le cas, n’hésitez pas une seule seconde > Go go go #GetGraylog2) et que vous êtes un aficionado de Powershell, ces 3000 lignes de codes sont pour vous !

Cela fait un moment maintenant que nous bossons avec Graylog2 (meme si nous avons migré vers ELK ces derniers temps, nous en reparlerons dans un futur billet) au quotidien (ce qui nous apporte un réel avantage pour toute la partie troubleshooting et des capacités d’analytics énormes!), mais il nous manquait encore une partie automatisation. Non pas la partie API qui est déjà existante et très bien fournie (d’ailleurs l’interface web de Graylog2 s’appuie essentiellement sur ces API), mais plutôt un accès simple pour automatiser des tâches sur le(s) serveur(s) Graylog2 (créations de stream, rules, alerts, …) afin de faciliter le quotidien et surtout de pouvoir faciliter le déploiement d’un nouveau serveur Graylog2.

Pour les curieux, l’API-browser est disponible par défaut à l’adresse http://<IP-du-serveur-graylog2>:12900/api-browser, interface qui est basée sur le bien connu Swagger.

Afin de palier à ce manque, nous avons développé ce module Powershell qui permet de faire quasiment tout ce qui faisable sur Graylog2 via des cmdlets Powershell. « Quasiment » parce que certains call API ne nous semblaient pas forcement utiles à rendre accessible depuis Powershell (par exemple la possibilité de faire des recherches directement via API, …), le but n’étant pas de se substituer complètement à l’interface web Graylog2 mais plutôt de faciliter son administration.

Pour la partie technique, l’API de Graylog2 est disponible en RESTful ce qui rend son intégration avec Powershell très aisée depuis la v3 (prérequis pour utiliser ce module, ce qui est vérifié a la première ligne du module via le code #Requires -Version 3) notamment avec le cmdlet Invoke-RestMethod.

Par contre nous avons été confrontés à un souci avec Powershell sur la gestion des connexions TCP lors de l’utilisation du cmdlet Invoke-RestMethod avec les méthodes PUT ou DELETE (étonnement les méthodes GET et POST n’ont pas ce problème, plus d’informations disponible sur  le site connect.microsoft.com). Cela nous a obligé dans certains cas à plutôt utiliser le cmdlet Invoke-WebRequest.

Il n’y a pas pour l’instant de « documentation » externe pour le module, mais sachant que nous avons formaté les fonctions afin que le cmdlet Get-Help vous aide à en savoir plus, libre à vous de l’utiliser pour trouver ce que le cmdlet fait (sachant aussi que le nom des cmdlet est assez explicite la majeure partie du temps, l’aide étant plus utile pour les arguments) :

Afin de pouvoir utiliser les cmdlets de ce module, il faut nécessairement commencer par une connexion à une instance Graylog2 (un peu comme Connect-VIServer avec PowerCLI). Pour se faire, vous devez utiliser le cmdlet Connect-Graylog2Server :

Import-Module C:\_Perso\GitRepo\powershell\Graylog2\Graylog2.psm1 -force
Connect-Graylog2Server -restIp 10.0.0.1 -restUsername "admin" -restPassword "graylog2rocks"

L’utilisation du switch –force sur le cmdlet Import-Module permet de forcer la prise en compte des nouvelles définitions de fonctions même si elles existaient déjà (très pratique pour gagner du temps lors des tests et mise à jour)

L’authentification au serveur Graylog2 peut se faire en direct via l’utilisation des paramètres –restUsername et –restPassword ou bien en interactif si ces paramètres ne sont pas précisés (une fenêtre d’authentification Get-Credential sera alors instanciée).

Une fois connecté, le serveur vous donnera quelques informations primaires et vous pourrez à ce moment utiliser les cmdlets du module :

Pour donner des exemples de ce que vous pouvez faire avec ce module (faites-vous plaisir), hypervisor l’a utilisé pour faire des One-Liner (« Hey, what did you expect » ^^) pour créer automatiquement des objets dans Graylog2, en voici certains exemples :

Création en masse de streams en se basant sur les events possibles (esx.problem.* esx.audit.* et esx.clear.*) de l’EventManager du vCenter

(Get-View EventManager).Description.EventInfo|select @{n="event";e={if ($_.key -match "^EventEx$|^ExtendedEvent$") {$_.FullFormat.split("|")[0]} else {$_.key}}}|?{$_.event -match "esx\.problem|esx\.audit|esx\.clear"}|%{New-Graylog2Stream -title $_.event -enabled}

Création de StreamRules pour chaque stream

Get-Graylog2Streams|?{$_.title -match "esx\.problem|esx\.audit|esx\.clear|vob\."}|%{New-Graylog2StreamRule -stream_id $_.id -field "full_message" -value $_.title -type "match regular expression"}

Création en masse des conditions d’alertes pour chaque streamrules

Get-Graylog2Streams|%{New-Graylog2StreamAlertConditions -streamId $_.id -conditionType "message_count" -thresholdType "more" -grace 1 -threshold 0 -time 1}

Ajout d’un receiver pour chaque alerte

Get-Graylog2Streams|%{New-Graylog2StreamAlertReceivers -streamId $_.id -type "users" -entity "alert"}

De nouveaux cmdlets seront surement ajoutes au fil des versions (d’autant plus que tout n’est pas fini), et n’hésitez pas à faire des remarques, nous sommes preneur ^^

Vous pouvez télécharger ce module directement sur GitHub (comme indiqué dans notre précédent billet.

git clone git@github.com:v-team/powershell-graylog2.git

Page 2 sur 29123451020Dernière page »