VEEAM B&R v9.5 – Les Appliances de déduplication – Bonnes pratiques

Par défaut

L’idée de cet article n’est pas de rentrer dans le débat du « Oui ou Non » utiliser une baie de déduplication. Nous allons aborder tous les paramètres de configuration spécifique aux 4 modèles supportés par VEEAM B&R V9.5. (Dell EMC Datadomain, HPE StoreOnce, Exagrid, Quantum DXI)

Toutefois si vous êtes en manque de débat philosophique à la machine à café, il y a là un vrai sujet !

Chaque modèle (ou Appliance de déduplication) évolue au fil du temps avec ces avantages et ces inconvénients (qui ne sont pas toujours purement technique), on pourrait également parler de REFS mais je m’égare déjà.

L’instant Wikipédia ! La déduplication

Tout d’abord, il est difficile de démarrer ce sujet sans la définition de cette technologie d’optimisation de l’espace de stockage.

Chaque fichier est découpé en une multitude de tronçons. À chacun de ces tronçons est associé un identifiant unique, ces identifiants étant stockés dans un index. L’objectif de la déduplication est de ne stocker qu’une seule fois un même tronçon. Aussi, une nouvelle occurrence d’un tronçon déjà présent n’est pas à nouveau sauvegardée, mais remplacée par un pointeur vers l’identifiant correspondant. La déduplication (également appelée factorisation ou stockage d’instance unique) est une technique de stockage de données, consistant à factoriser des séquences de données identiques afin d’économiser l’espace utilisé.

Pourquoi utiliser une appliance de déduplication ? 

Les Appliances de déduplication fournissent à la fois des taux de compression et de déduplication élevés, ce qui permet de conserver les données pendant de longues périodes. (Un effet radicale sur le coût au To lorsque vous avez des contraintes de rétentions très longues ou tout simplement un volume de sauvegarde important). 

Voici un bref résumé des avantages / inconvénients de l’utilisation des appliances de déduplication comme présenté dans le webinar « Veeam Backup Repository Best Practice 2017«  

 

Je vous invite, aussi à consulter un très bon article d’Emmanuel Forgues sur la déduplication:

EXIT COST d’une solution utilisant de la déduplication propriétaire

Il est important d’avoir en tête ces principes

Dans un Design « VEEAM » idéal, ce type de baies est un stockage secondaire de sauvegarde. Un stockage primaire avec des performances plus importantes est conseillé (mais évidement avec un coût plus important pour les volumétries importantes). 

 

Avec les appliances de déduplication, les performances en écriture peuvent varier en fonction du modèle, du protocole et de l’architecture de l’infrastructure de sauvegarde.  

Veeam recommande de toujours utiliser une des baies de déduplication intégrée et testée avec leur solution. C’est-à-dire une de ses 4 baies : 

  • Dell EMC Data Domain (DDBoost API) 
  • HPE StoraOnce (Catalyst API) 
  • Exagrid (On-Board Data Mover) 
  • Quantum DXI  (On-Board Data Mover) 

Dans les cas des baies EMC DataDomain et HPE StoreOnce, les licences « DDBoost » et « Catalyst » sont fortement conseillées dans de nombreux « use case ».

Les baies ne disposant pas de Datamover VEEAM Intégré demandent une attention particulière. Dans tous les cas pour atténuer les problématiques liées à ces appliances, suivre les bonnes pratiques « VEEAM » sont une nécessité.  

Attention : Ces bonnes pratiques s’appliquent à la version V9.5 de VEEAM et n’ont pas toujours été identiques dans les anciennes versions (V7,V8). Il est donc possible que certaines de vos politiques actuelles soient encore configurées avec des paramètres qui ne sont plus d’actualité. 

Configuration Globale

Voici la configuration par défaut des baies de déduplication comme « backup Repository ». Nous verrons ensuite des spécificités liées à chaque modèle. 

Pour la configuration des « Jobs » de backup (Edit Job, Storage, Advanced), voici les paramètres à configurer : 

 

Pour la configuration du « Repository » de backup (Edit Repository, Advanced), voici les paramètres à configurer : 

 

Voici la configuration particulière pour chaque constructeur de baies de déduplication, nous allons commencer par les baies qui ne disposent pas de gateway VEEAM intégré. 

Un serveur « Gateway » est un composant de l’infrastructure de sauvegarde VEEAM qui « relie » le serveur de sauvegarde et le « Repository » de sauvegarde. Le serveur de passerelle est requis si vous déployez les types de « Repository » de sauvegarde suivants : 

  • Dossiers partagés 
  • Appliance EMC DataDomain et HPE StoreOnce 

 

Dell EMC Datadomain 

 La Technologie EMC DDBoost permet le support par VEEAM des fonctionnalités suivantes : 

  • Distributed Segment Processing 
  • Advanced Load Balancing and link Failover 
  • Virtual Synthétics 
  • In-Flight Data Encryption 
  • Per Storage Unit Stream 

Attention : La réplication DataDomain n’est pas supportée depuis VEEAM V8. Ce sera visiblement le cas en V10. 

Limitations EMC DataDomain 

  • L’utilisation d’une baie EMC Data Domain avec DD Boost ne garantit pas l’amélioration des performances du travail. Il réduit la charge sur le réseau et améliore le débit du réseau.
  • Data Domain requiert au moins 1 Gbit / s de réseau et 0% de perte de données de paquets entre le serveur « Gateway » et l’appliance Data Domain. Dans le cas contraire, la consistance des données ne peut être garantie. 
  • DataDomain ne supporte pas la méthode de sauvegarde « Reverse Incremental ». Ne pas activer cette méthode.
  • Vous ne pouvez pas utiliser une Appliance DataDomain comme source ou cible pour les « File Copy Job ».
  • Lorsque vous créez un travail de sauvegarde destiné à une appliance Data Domain, Veeam Backup & Replication vous propose de passer à des paramètres « Optimised Job » et d’utiliser le bloc de données de 4 Mo pour le traitement des données de machine virtuelle. Il est recommandé d’utiliser des paramètres « Optimised Job ». Les blocs de données de taille importante produisent une table de métadonnées plus petite qui nécessite moins de ressources de mémoire et de processeur à traiter. 
  • La longueur des chaînes de sauvegarde forward incremental and forever forward incremental (chaînes qui contiennent une sauvegarde complète et un ensemble de sauvegardes incrémentielles ultérieures) ne peut pas dépasser 60 points de restauration. Pour surmonter cette limitation, planifiez des sauvegardes complètes (actives ou synthétiques) afin de diviser la chaîne de sauvegarde en séries plus courtes.
  • Pour les appliances EMC Data Domain fonctionnant avec Fibre Channel, vous devez définir explicitement le serveur « Gateway » qui communiquera avec l’Appliance. En tant que serveur « Gateway », vous devez utiliser un serveur Microsoft Windows ajouté à l’infrastructure de sauvegarde et avoir accès à EMC Data Domain via Fibre Channel. 

DDBoost 

Autant dire que l’utilisation de DDBoost est fortement conseillée, voir obligatoire dans de nombreux cas. 

 

DDBoost permet les fonctionnalités suivantes : 

  • Déduplication côté source entre le serveur « Gateway » Veeam et l’appliance DataDomain. Cela réduira la quantité de données envoyées sur le réseau à l’appliance. 
  • Meilleure parallélisation LAN, puisque DDBoost gère son propre équilibrage de charge réseau (Algorithmes considérés comme plus efficaces que l’agrégation de liens réseau standard) 
  • Transformations de fichiers Veeam transparente comme « synthetic full » ou « forever forward incremental » 
  • DDBoost peut être utilisé via SAN Fibre Channel, fournissant ainsi une sauvegarde s’affranchissant totalement du LAN. (LAN-free backup). 

Limitations : 

  • L’option « Hardware assisted encryption » est disponible via DDBoost et doit être configurée dans les paramètres du « repository ».  Si cette option est activée au niveau du « Job », l’efficacité de réduction sera considérablement dégradée. 
  • Pour les appliances EMC Data Domain fonctionnant avec Fibre Channel, vous devez définir explicitement le serveur « Gateway » qui communiquera avec l’Appliance. En tant que serveur « Gateway », vous devez utiliser un serveur Microsoft Windows ajouté à l’infrastructure de sauvegarde et avoir accès à EMC Data Domain via Fibre Channel. 

Accelerated Restore of Entire VM 

Ce mécanisme est activé par défaut pour la restauration des VM complètes. Mais pensez à vérifier qu’il est bien activé. Plus d’infos sur le fonctionnement de ce mécanisme ici :

https://helpcenter.veeam.com/docs/backup/vsphere/emc_dd_accelerated_restore.html?ver=95 

 

HPE StoreOnce 

Deux modes disponibles : 

  • Souces side Data Deduplication  –> Licences Catalalyst 
  • Target Side Data Deduplication (Catalyst Store ou CIFS Store) –> Licences Catalalyst pour le catalyst store 

La Technologie StoreOnce Catalyst permet le support par VEEAM des fonctionnalités suivantes : 

  • Synthétic Full Backups 
  • VPower-Enabled Operations (Instant VM Recovery, SureBackup and On-Demand Sandbox) 
  • Accelerated Data Recovery (Instant VM Recovery, file-level recovery and application items recovery with Veeam Explorers) 
  • Wan-based Catalyst Store support 

 Attention : La réplication HPE StoreOnce n’est pas supportée. 

Comme pour une baie DataDomain, vous devez, pour les appliances HPE StoreOnce fonctionnant sur Fibre Channel, définir explicitement le serveur « Gateway » pour communiquer avec HPE StoreOnce. En tant que serveur « Gateway », vous devez utiliser un serveur Microsoft Windows ajouté à l’infrastructure de sauvegarde et avoir accès à HPE StoreOnce via Fibre Channel. 

Voici une liste de limitations pour l’HPe StoreOnce, mais pour plus de détails, je vous renvoie vers le site de VEEAM (les liens sont en bas de page).

Limitations pour les Appliances HPE StoreOnce  

  • Les fichiers de sauvegarde sur HPE StoreOnce sont exclusivement verrouillés par un travail ou une tâche. Si vous démarrez plusieurs tâches à la fois, VeeamBackup & Replication effectuera une tâche avec une priorité plus élevée et ignorera ou terminera une tâche avec une priorité inférieure. Dans VeeamBackup & Replication, les tâches ont les niveaux de priorité suivants (en commençant par la priorité la plus élevée) : 1 – restore > 2 – job de sauvegarde > 3 – copie de sauvegarde. Par exemple, si les travaux de copie de sauvegarde et de sauvegarde démarrent simultanément, VeeamBackup & Replication terminera la tâche de copie de sauvegarde. 
  • Lorsque vous créez un travail de sauvegarde destiné à une appliance HPE StoreOnce, VeeamBackup & Replication vous propose de passer à des paramètres « Optimized Job » et d’utiliser le bloc de données de 4 Mo pour le traitement des données de machine virtuelle. Il est recommandé d’utiliser la fonction « Optimized Job ». Les grands blocs de données produisent une table de métadonnées plus petite qui nécessite moins de ressources de mémoire et de processeur à traiter.
  • Le « Repository » HPE StoreOnce fonctionne toujours dans le mode « Use per-VM backup files  »
  • Les appliances HPe StoreOnce ne supportent pas la méthode de sauvegarde « Reverse Incrémental »
  • Le « Repository » HPE StoreOnce ne prend pas en charge l’option Defragment and compact full backup file (pour les travaux de sauvegarde et de copie de sauvegarde).
  • Vous ne pouvez pas procéder à un « Quick Migration » pour les VMs Hyper-V démarrées à l’aide de la fonctionnalité « Instant Recovery » sur une appliance HPe StoreOnce. 
  • Vous ne pouvez pas utiliser les appliances de sauvegarde HPe StoreOnce comme repository de sauvegarde pour les travaux de sauvegarde VEEAM Endpoint (Serveurs Physiques). C’est toutefois possible pour les copies de sauvegarde (Backup Copy Job).
  • Il est possible d’utiliser les appliances StoreOnce pour la fonctionnalité « File Copy Job »
  • Vous ne pouvez pas copier manuellement des fichiers de sauvegarde (VMK, VIB et VRB) sur un « repository » StoreOnce. Pour les copier, il faut utiliser les travaux de copie de sauvegarde.
  • Vous ne pouvez utiliser un « repository » en tant que référentiel Cloud »
  • HPE StoreOnce a une limite sur le nombre de fichiers ouverts simultanément. En raison de cette limite, la longueur maximale des chaînes de sauvegarde sur une appliance est également limitée et dépend du modèle de stockage particulier: 

 Quantum DXI 

Le support des baies Quantum DXI dans les baies supportées par VEEAM est intéressant. Je n’ai pas encore toutes les informations à ce sujet (et pas encore de retours pratiques) mais sur le papier, cela se présente pas mal. La solution est déjà supportée par VEEAM en V9.5 mais apparaîtra dans l’interface VEEAM (lorsque vous souhaitez ajouter une appliance dans les repository) à partir de la V10. 

 

Je n’ai également pas encore les limitations éventuelles des modèles Quantum. Je ferai des modifications de l’article dès que j’aurais validé les informations. 

Exagrid 

VEEAM B&R travaille avec une baie exagrid comme avec un repository « Linux ». VEEAM deploie le composant « Veeam Data Mover » sur l’appliance Exagrid. Le service « Data movers » (transport) établie une connexion avec le service Data Mover du « Backup Proxy » et active le transfert de data optimisé. De plus, l’appliance Exagrid dispose d’une « landing zone » intégré à la solution permettant l’utilisation de l’ensemble des fonctionalités de VEEAM. Certainement un des modèles pouvant le plus facilement se passer d’un stockage de sauvegarde primaire. 

 

Limitations

Les Appliances de déduplication ExaGrid ont une moins bonne déduplication lorsque le traitement multitâche s’effectue dans un seul travail de sauvegarde. Le traitement d’une seule tâche à la fois dans chaque « Job » de sauvegarde génère une meilleure déduplication. Si vous décidez d’utiliser ExaGrid comme « Repository » de sauvegarde, toutes les tâches exécutées dans un « Job » de sauvegarde doivent être traitées séquentiellement, une par une. Vous devez limiter les tâches simultanées maximales à 1 dans les propriétés du « Repository » de sauvegarde utilisées avec les appliances ExaGrid.

Pour activer le « parallel processing » pour les « repository » ExaGrid, vous devez configurer le « repository » et les « jobs » de la manière suivante :

  • Repository

Créez au moins un partage sur chaque appliance ExaGrid. Activez l’option de transport « ExaGrid-Veeam Accelerated Data Mover » pour le partage créé. Laissez les paramètres de compression et de déduplication par défaut pour le partage.
Dans Veeam Backup & Replication, configurez un « repository » de sauvegarde de dossiers partagés et pointez-le sur le partage créé sur l’appliance ExaGrid. Définissez l’option « Limiter les tâches simultanées maximales » sur 10 tâches. Vous pouvez par la suite modifier ce paramètre en fonction des performances observés.

  • Jobs
  1. Nombre de machines virtuelles par jobs : divisez le nombre total de machines virtuelles entre les tâches de sauvegarde en fonction de la capacité de l’appliance ExaGrid.
  2. Paramètres du travail de sauvegarde:
    Utilisez la méthode de sauvegarde « forward incremental backup »
    Activez les sauvegardes full synthétiques et planifiez leur exécution chaque semaine.
    Activez les sauvegardes Active Full et planifiez leur exécution tous les mois.
  3. Cible de sauvegarde: Affectez les jobs aux « repository » de sauvegarde ExaGrid en fonction de la capacité de l’appliance ExaGrid.

 

Documentation VEEAM et Constructeurs : 

Veeam Backup & Replication Best Practices 

https://bp.veeam.expert/ 

Veeam Repository Best Practice : 

https://www.veeam.com/fr/videos/backup-repository-best-practices-2017-10582.html 

EMC Data Domain Storage with Veeam Backup & Replication: 

https://www.veeam.com/kb1956 

EMC DataDomain Accelarated Restore Of Entire VM  

https://helpcenter.veeam.com/docs/backup/vsphere/emc_dd_accelerated_restore.html?ver=95 

Accelerated Restore of Entire VM 

https://helpcenter.veeam.com/docs/backup/vsphere/emc_dd_accelerated_restore.html?ver=95

 HPe StoreOnce : 

https://helpcenter.veeam.com/docs/backup/hyperv/deduplicating_appliance_storeonce.html?ver=95 

Exagrid :

https://helpcenter.veeam.com/docs/backup/vsphere/deduplicating_appliance_exgrid.html?ver=95

http://www.exagrid.com/exagrid-products/supported-data-backup-applications/veeam-backup/

Webinar VEEAM : 

https://www.veeam.com/fr/videos/backup-repository-best-practices-2017-10582.html 

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

Spectre et Meltdown, dommages collateraux pour VMware Update Manager…

Baselines
Par défaut

Comme disait ma Grand-Mère, quand ça ne veut pas, ça ne veut pas… Les failles Spectre et Meltdown ont déja fait couler beaucoup d’encre et ce n’est pas prêt de s’arrêter ! Vous le savez surement déjà (si ce n’est pas le cas, allez lire l’article de Cédric), Intel a sorti dans l’urgence un correctif pour corriger les problèmes rencontrés sur ces processeurs. Manque de chance (ou autre…) l’application du patch peut engendrer des reboots intempestifs ! Les constructeurs / éditeurs, qui avaient suivi le mouvement et commencé à distribuer le patch, ont dû rétropédaler de toute urgence… Et c’est là qu’entre en scène VMware Update Manager

Si vous avez configuré le vénérable VUM pour qu’il télécharge automatiquement la définition des patchs (configuration par défaut), vous devez voir que les correctifs en question sont prêts à être installés alors même qu’ils ne sont plus disponibles au téléchargement.

Liste des patchs

Apparement, VUM ne sait pas correctement gérer cette situation car si vous essayez d’appliquer les patchs sur vos serveurs ESXi via une baseline dynamique, la tâche va se terminer en générant l’erreur Impossible de télécharger des progiciels depuis la source du correctif

 

Erreur VUM

La solution ? Créer une nouvelle baseline dynamique en excluant explicitement les patchs concernés (à ma connaissance, il n’est pas possible de modifier celles par défaut).

Exclusion patchs

Après cela vous n’aurez plus qu’à détacher la baseline d’origine – Correctifs d’hôtes non critiques (prédéfinie) – et attacher la nouvelle, et tout devrait rentrer dans l’ordre !

Ajout baseline

Erwan Quélin est depuis 6 ans Ingénieur Systèmes chez Cheops Technology. Ses interventions sont multiples et auprès de clients très diversifiés dans la région Ouest. Spécialisé dans la virtualisation autour des produits VMware et dans le stockage autour des gammes VNX, Unity et VPLEX de Dell EMC, Erwan est certifié VMware Certified Professional – Datacenter virtualization 4, 5 et 6 ainsi que EMC Implementation Engineer – VNX et Unity et vient d’intégrer les programmes VMware vExpert et Dell EMC Elect pour l’année 2017.

Lorsqu’il lui reste un peu de temps libre, Erwan développe des projets open sources ayant pour sujet principal l’automatisation d’infrastructures.

Pour suivre Erwan et pour plus d’informations sur son parcours et ses compétences :

Voir mon profil LinkedIn Erwan Quelin Voir le profil Linkedin d’Erwan

Voir mon profil GitHub Erwan Quelin Voir le profil GitHub d’Erwan

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

Déplacer des données gérées par LVM avec pvmove

Par défaut

Note d’Erwan: Cet article a été publié initialement sur mon ancien blog, le site étant amené à disparaitre et le contenue me semblant toujours pertinent, je le reproduis ici.

Je vous propose de détailler le fonctionnement de la commande pvmove qui permet, comme son nom l’indique, de déplacer des données d’un volume physique (PV) à un autre. Cette méthode a le grand avantage de pouvoir s’exécuter à chaud. Les cas d’usages possibles sont par exemple de faciliter le remplacement d’un disque ou bien déplacer les données d’une baie SAN à une autre.

Avant de commencer à jouer avec des données de production je vous conseille fortement de réaliser des tests pour être complètement à l’aise avec les commandes LVM. Faire une sauvegarde pourrait être aussi une bonne idée !

Vous aurez deviné que la commande pvmove n’est utilisable que si votre stockage est géré par LVM. Si vous n’êtes pas famillier avec ces notions, il existe une multitude d’articles sur le sujet.

Configuration du serveur de test

Pour les besoins de la démonstration j’utilise une machine virtuelle sur laquelle j’ai installé une CentOS 7.1. Les données sont stockées sur le device /dev/sdb qui fait partie du VG vgtest. Le but de l’opération est de tout déplacer vers un nouveau device /dev/sdc puis de supprimer /dev/sdb.

Méthodologie

Un (bon) schéma étant souvent plus parlant qu’un long texte, j’ai résumé les différentes étapes dans l’image ci-dessous:

 

Migrer-Donnees-LVM-01

Liste des commandes

Découverte du nouveau device cible:
# for x in `ls /sys/class/scsi_host/`; do echo "- - -" > /sys/class/scsi_host/$x/scan ; done
Création d’un PV sur le nouveau device (/dev/sdc):
# pvcreate /dev/sdc
  Physical volume "/dev/sdc" successfully created
Ajout du nouveau device dans le VG:
# vgextend vgtest /dev/sdc
  Volume group "vgtest" successfully extended
Déplacement des données de /dev/sdb vers /dev/sdc:

L’argument -b permet d’exécuter la commande en tâche de fond.

# pvmove -b /dev/sdb /dev/sdc
Suivi de l’évolution de la copie des données:

La colonne Cpy%Sync indique le pourcentage des données déjà déplacées.

# watch lvs -a -o+devices
LV        VG     Attr       LSize  Pool Origin Data%  Meta%  Move     Log Cpy%Sync Convert Devices
root      centos -wi-ao---- 13.91g                                                         /dev/sda2(410)
swap      centos -wi-ao----  1.60g                                                         /dev/sda2(0)
lvtest    vgtest -wI-ao---- 10.00g                                                         pvmove0(0)
[pvmove0] vgtest p-C-aom--- 10.00g                           /dev/sdb     7.89             /dev/sdb(0),/dev/sdc(0)
Suppression de l’ancien device /dev/sdb du VG:
# vgreduce vgtest /dev/sdb
  Removed "/dev/sdb" from volume group "vgtest"
Suppression du PV du device /dev/sdb:
# pvremove /dev/sdb
  Labels on physical volume "/dev/sdb" successfully wiped
Suppression du device /dev/sdb:
# echo 1 > /sys/block/sdb/device/delete
Erwan Quélin est depuis 6 ans Ingénieur Systèmes chez Cheops Technology. Ses interventions sont multiples et auprès de clients très diversifiés dans la région Ouest. Spécialisé dans la virtualisation autour des produits VMware et dans le stockage autour des gammes VNX, Unity et VPLEX de Dell EMC, Erwan est certifié VMware Certified Professional – Datacenter virtualization 4, 5 et 6 ainsi que EMC Implementation Engineer – VNX et Unity et vient d’intégrer les programmes VMware vExpert et Dell EMC Elect pour l’année 2017.

Lorsqu’il lui reste un peu de temps libre, Erwan développe des projets open sources ayant pour sujet principal l’automatisation d’infrastructures.

Pour suivre Erwan et pour plus d’informations sur son parcours et ses compétences :

Voir mon profil LinkedIn Erwan Quelin Voir le profil Linkedin d’Erwan

Voir mon profil GitHub Erwan Quelin Voir le profil GitHub d’Erwan

 

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

« Dump Collector » – Configuration dans un environnement vSphere 6.5 & VSAN

Par défaut

Nous avons l’habitude de configurer régulièrement le « persistent scratch location » de nos serveurs ESXi qui boot sur une carte SD/USB sur un datastore mais il n’est pas supporté de le configurer sur un volume vSAN.

Si votre espace est limité sur le volume SD/USB (Conseillé dans tous les cas d’avoir un management centralisé), il est plus que nécessaire d’effectuer les actions suivantes :

  • Désactiver l’espace de Swap (Manage > Settings > System Swap) (Supporté mais non conseillé)
  • Configurer le Dump Collector du votre VCSA (récupération des Dumps lors d’un PSOD)
  • Configurer l’envoi des logs vers un serveur Syslog

Si vous en êtes à lire cet article, c’est que vous avez certainement un problème de RAM Disk space sur votre serveur ESXi. Je vous conseille la commande « vdf -h » qui peut être utilisée pour examiner les RAMdisks sur un hôte ESXi.

Cet article traite de la configuration du Dump Collector. Vous trouverez ci-dessous la procédure de configuration en ligne de commande mais je vous conseille d’effectuer les paramétrages avec PowerCli. C’est une très bon « Use Case » pour débuter dans l’automatisation de la configuration d’une infrastructure VMware vSphere (si vous n’utilisez pas Auto Deploy).

Voir KB1033696 : Chapitre – Configuring a persistent scratch location using PowerCLI 5.1 or later

La configuration s’effectue en deux étapes. Tout d’abord le service sur le VCSA et ensuite la configuration des esxi.

Configurer le service Dump Collector Service de l’appliance VCSA :

Dans le vCenter, démarrer le service :

  • Administration, System ConfigurationServices, et  VMware vSphere ESXi Dump Collector.
  • “Start” service
  • Edit Startup Type : “Automatique”
  • Faire un refresh pour vérifier si le service est bien démarré.

Configurer un host ESXi

Tout d’abord se connecter en SSH sur le host et executer la commande suivante :

esxcli system coredump network get

 

Puis configurer la cible:

esxcli system coredump network set -v vmk0 -i 192.168.X.X -o 6500

 

Attention : Bien vérifier que la patte de management de votre serveur ESXi est bien « vmk0 »

Faire un “Enable” de la config:

esxcli system coredump network set -e true

Verifier les parametres :

esxcli system coredump network get

 

 Vérifier la configuration sur le serveur ESXi et le VCSA

 esxcli system coredump network check

Enfin, connectez-vous en SSH sur l’appliance VCSA et vérifier que l’adresse ip du host est bien là lors du check reply :

cat /var/log/vmware/netdumper/netdumper.log

Vous devez voir l’adresse ip de votre serveur esxi dans le « check status ».

Sources & Plus : 

Creating a persistent scratch location for ESXi 4.x/5.x/6.x : https://kb.vmware.com/s/article/1033696
Besoin de débuter l’automatisation : https://myvmworld.fr/ladmin-de-demain-introduction/
Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

Centraliser les métriques d’un serveur Windows grace à Telegraf, InfluxDB et Grafana

Par défaut

Tout commença lors d’une pause café avec mes chers collègues. L’un d’eux voulait connaître les outils existants pour collecter et analyser les métriques de serveurs Windows. Je ne sais pas s’il s’est rendu compte de mon embarras car, après un instant de réflexion, je n’ai pu citer que Perfmon… Quoi qu’il en soit, cela m’a permis de constater à quel point j’étais ignorant dans ce domaine et qu’il était largement temps d’y remédier !

Quelques recherches Google plus tard, j’ai fait le constat qu’il existait plusieurs solutions bien plus évoluées ! L’une d’elle a particulièrement attiré  mon attention, enfin, plutôt qu’un produit unique, il s’agit du triptyque Telegraf, InfluxDB et Grafana.

Ces applications ne sont pas les seules qui existent sur ce marché. Je les ai choisies parce qu’elles ont la bonne idée d’être Open Source et suffisamment répandues pour que l’on trouve de la documentation un peu partout sur internet. De plus, elles ne se limitent absolument pas au monitoring d’environnements Microsoft. Je vous laisse consulter la liste des plugins Telegraf disponibles pour juger par vous même…

Dans la suite de l’article je vais vous présenter ces 3 applications, détailler comment les installer puis enfin vous montrer comment importer un dashboard dans Grafana afin de pouvoir visualiser de manière centralisée, la performance de vos serveurs.

Présentation des joueurs

 

Logo telegraf

 

Telegraf est l’agent que vous devrez installer sur les serveurs à monitorer. C’est lui qui va collecter les métriques tels que l’utilisation du CPU ou de la RAM pour ensuite les envoyer vers InfluxDB.

 

Logo Influxdb

 

InfluxDB est une base de données temporelles, autrement dit c’est une base dédiée au stockage et à l’exploitation de séries de données. C’est dans InfluxDB que l’on va centraliser toutes les informations envoyées par les agents Telegraf. InfluxDB s’installe sur un serveur Linux et se configure en ligne de commandes (grace à l’utilitaire influx) ou bien via une API.

Logo Grafana

Grafana va nous permettre de mettre en forme les données présentes dans InfluxDB. Dans notre cas on va pouvoir créer des graphiques pour visualiser facilement dans quel état de forme se trouvent nos serveurs Windows ! Ces graphes seront regroupés sur différents dashboards. On peut imaginer avoir un affichage dédié à vos environnements Windows ou Linux, voire même une application particulière. Grafana s’installe sur un serveur Linux et se configure via une interface web ou bien via une API.

Prérequis

Vous n’y échapperez pas, voici les traditionnels prérequis nécessaires à la mise en place de la solution :

  • Un serveur Linux pour accueillir le couple InfluxDB et Grafana. Dans le cadre de l’article nous utiliserons une Ubuntu 16.04, je vous laisse vérifier par vous-même si votre distribution préférée est compatible…
  • Un serveur Windows. C’est lui que l’on va monitorer en y installant un agent Telegraf.

Installation d’InfluxDB

Commençons par nous connecter en SSH à notre serveur Linux pour y installer InfluxDB.

On va s’assurer que l’OS est à jour, ajouter le repo d’InfluxDB puis enfin installer et démarrer le service :

# Maj OS
sudo apt-get update && sudo apt-get upgrade -y

# Ajout repo
curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

# Installation et démarrage service
sudo apt-get update && sudo apt-get install influxdb
sudo systemctl enable influxdb.service
sudo systemctl start influxdb

Maintenant que l’installation est terminée, on va créer une base de données que l’on nommera TelegrafDB (notez ici l’originalité de ce choix !). On va pour cela utiliser l’outil influx qui a été installé en même temps qu’InfluxDB et qui fait office de CLI pour intéragir avec l’application :

influx -execute "create database TelegrafDB"

Vérifions que tout s’est bien passé :

$ influx -execute "show databases"
name: databases
name
----
_internal
TelegrafDB

On vient de configurer le minimum syndical pour qu’InfluxDB soit utilisable. Bien sûr, si vous deviez le mettre en production, je vous conseillerais fortement de mettre en place une authentification, des certificats ainsi que définir une politique de rétention des données.

Installation de Grafana

Si vous avez réussi à installer InfluxDB, vous devriez pouvoir faire de même pour Grafana. La procédure est à peu de chose près la même !

On va installer d’abord les prérequis, ajouter le repo puis installer Grafana :

#Installation prerequis
sudo apt-get install -y adduser libfontconfig

#Ajout repo
sudo sh -c 'echo "deb https://packagecloud.io/grafana/stable/debian/ jessie main" >> /etc/apt/sources.list'
curl https://packagecloud.io/gpg.key | sudo apt-key add -

# Installation et démarrage service
sudo apt-get update && sudo apt-get install -y grafana
sudo systemctl daemon-reload
sudo systemctl enable grafana-server.service
sudo systemctl start grafana-server

Vous devriez pouvoir vous connecter à l’interface web en vous rendant à l’adresse http://monserveur.exemple.com:3000. Par défaut le compte de connexion est admin et le mot de passe admin.

Page accueil Grafana

Il ne nous reste plus qu’à configurer Grafana pour lui indiquer comment se connecter à InfluxDB. On va pour cela créer une Data Source. On pourrait le faire graphiquement en se rendant dans le menu Grafana > Data Sources > Add data source mais étant donné que j’aime bien les API Rest, on va plutôt utiliser un bon vieux curl:

curl -s -H "Content-Type: application/json" \
    -XPOST http://admin:admin@localhost:3000/api/datasources \
    -d @- <<EOF
    {
        "name":"TelegrafDB",
        "type":"influxdb",
        "url":"http://localhost:8086",
        "access":"proxy",
        "basicAuth":false,
        "database":"TelegrafDB",
        "isDefault":true,
        "jsonData": {
            "timeInterval":"10s"
        }
    }
EOF

Et voici ce que vous obtenez une fois la data source créée :

Grafana data source

Installation de Telegraf

Ok, les bases de la solution sont en places, il va falloir maintenant fournir des données ! On va donc installer l’agent Telegraf sur notre serveur Windows et le configurer pour qu’il récupère les métriques de performance afin qu’il les envoie vers InfluxDB.

Vous pouvez soit télécharger Telegraf sur le site de l’éditeur et l’installer de manière classique, soit utiliser Chocolatey (NDA: J’adore Chocolatey ! Faites-moi penser à vous écrire un article à ce sujet).

choco install telegraf -y

Dans les 2 cas, vous devriez voir apparaitre un nouveau service :

Get-Service telegraf

Status Name DisplayName
------ ---- -----------
Running telegraf Telegraf Data Collector Service

Il ne nous reste plus qu’à modifier le fichier de configuration de Telegraf que vous trouverez à l’emplacement C:\Program Files\telegraf\telegraf.conf. Recherchez la section [[outputs.influxdb]] et à indiquer l’url de votre serveur InfluxDB (http://monserveur.exemple.com:8089) ainsi que le nom de la base de donnée (TelegrafDB).

###############################################################################
# OUTPUTS #
###############################################################################

# Configuration for influxdb server to send metrics to
[[outputs.influxdb]]
# The full HTTP or UDP endpoint URL for your InfluxDB instance.
# Multiple urls can be specified but it is assumed that they are part of the same
# cluster, this means that only ONE of the urls will be written to each interval.
# urls = ["udp://localhost:8089"] # UDP endpoint example
urls = [ "http://monserveur.exemple.com:8089" ] # required
# The target database for metrics (telegraf will create it if not exists)
database = "TelegrafDB" # required

Les modifications apportées ci-dessus sont suffisantes pour nos besoins, si vous le souhaitez, vous pouvez modifier la liste des métriques que Telegraf va envoyer, en éditant la section [[inputs.win_perf_counters]].

Pour finir, on redémarre le service pour prendre en compte les modifications :

Get-Service telegraf | Restart-Service

Visualiser les métriques

Bravo, vous êtes pratiquement arrivé à la fin de l’article ! Les différents composants sont installés et fonctionnels, il ne reste qu’une dernière étape : configurer Grafana pour qu’il affiche de jolis graphiques. Ce sujet méritant un article à part entière, je vous propose que l’on s’appuie sur un dashboard que j’ai créé et qui est disponible sur le site de Grafana.

N’hésitez pas à regarder les différents dashboards mis à disposition par la communauté. C’est une source d’inspiration fantastique si vous souhaitez vous lancer dans la réalisation de vos propres dashboards.

Rendez-vous sur la page du dashboard en question et cliquez sur Copy ID to clipboard. Connectez-vous ensuite à votre serveur Grafana et allez sur le menu Grafana > Dashboards > Import. Dans le champ Grafana.com Dashboard collez l’ID (cela devrait-être l’ID 3900…) puis cliquez sur Load. Donnez un nom au dashboard et sélectionnez la Data Source(si vous avez suivi la procédure, elle devrait se nommer TelegrafDB) puis enfin cliquez sur Import.

Vous avez maintenant accès à un nouveau dashboard nommé Windows - Top qui regroupe quelques métriques de base (CPu, RAM, SWAP, IO..). Pas mal non ?

Vers l’infini et au delà !

Nous avons vu comment mettre en place une solution nous permettant de centraliser et visualuer les métriques d’un serveur Windows. J’espère que cet article vous aura donné envie d’aller plus loin et de vous lancer dans l’exploration du monde merveilleux du monitoring de nos chers serveurs !

Si jamais vous avez des questions, n’hésitez pas à laisser un commentaire ou bien contactez-moi sur twitter (@erwanquelin).

Le titre auquel vous avez échappé (et heureusement…)

  • Grafana, le youporn du geek

 

Erwan Quélin est depuis 6 ans Ingénieur Systèmes chez Cheops Technology. Ses interventions sont multiples et auprès de clients très diversifiés dans la région Ouest. Spécialisé dans la virtualisation autour des produits VMware et dans le stockage autour des gammes VNX, Unity et VPLEX de Dell EMC, Erwan est certifié VMware Certified Professional – Datacenter virtualization 4, 5 et 6 ainsi que EMC Implementation Engineer – VNX et Unity et vient d’intégrer les programmes VMware vExpert et Dell EMC Elect pour l’année 2017.

Lorsqu’il lui reste un peu de temps libre, Erwan développe des projets open sources ayant pour sujet principal l’automatisation d’infrastructures.

Pour suivre Erwan et pour plus d’informations sur son parcours et ses compétences :

Voir mon profil LinkedIn Erwan Quelin Voir le profil Linkedin d’Erwan

Voir mon profil GitHub Erwan Quelin Voir le profil GitHub d’Erwan

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

Sauvegarde et restauration d’un vCenter 6.5

Par défaut

Je voudrais vous présenter une « nouvelle » fonctionnalité disponible dans les appliances VMware vCenter VCSA 6.5. Il est maintenant possible de sauvegarder votre vCenter ou PSC et d’exporter ces données vers un stockage externe, et tout ça directement depuis l’interface de management (VAMI).

Alors, sauvegarder c’est bien, mais pouvoir restaurer, c’est encore mieux ! La procédure de restauration nécessitera de déployer un nouveau vCenter « vide » puis de restaurer les données. Rassurez-vous, VMware a fait l’effort de simplifier cette opération en l’intégrant directement dans l’interface de déploiement d’un vCenter.

Prérequis

Les prérequis sont plutôt réduits. Vous devez disposer de :

  • Un compte utilisateur pour accéder à l’interface VAMI
  • Un stockage externe accessible via les protocoles FTP, FTPS, HTTP, HTTPS ou bien SCP
  • Un compte utilisateur ayant des droits en lecture / écriture sur ce stockage
  • L’image ISO qui a servi à installer le vCenter / PSC (nécessaire pour restaurer)

Sauvegarde manuelle

  1. Connectez-vous à l’interface de management de votre vCenter ou PSC

Cette interface est accessible avec un navigateur web en précisant l’IP ou le FQDN et le port 5480 (ex: https//monvcenter.example.com:5480)

  1. Sur la page d’accueil, cliquez sur Backup
  2. Sélectionnez un protocol de transfert et renseignez les informations nécessaires (user, mot de passe etc…), puis cliquez sur Next

 

Vous pouvez si vous le souhaitez chiffrer vos sauvegardes. Dans ce cas, pensez à conserver le mot de passe sans quoi la restauration sera impossible…

  1. Choisissez si vous voulez sauvegarder en plus des données de base, les statistiques, événements, alarmes et tâches. Cliquez sur Next

5. Vérifiez que les informations sont correctes puis cliquez sur Next

Si tout se passe normalement, la sauvegarde va se terminer au bout de quelque temps, et les fichiers de sauvegarde seront disponibles à l’emplacement spécifié.

Sauvegarde automatisée

Vous aurez peut-être remarqué que l’interface web ne propose pas de moyen de planifier les sauvegardes, c’est regrettable mais comme moyen de contournement on peut utiliser les API qui permettent avec quelques lignes de code de compenser ce manque. Brian Graf (@vBrianGraf) nous a mâché le travail en développant un module Powershell et en rédigeant un article détaillant son fonctionnement. Il ne vous reste plus qu’à configurer une tache planifié pour exécuter ce script et le tour est joué !

Restauration

Maintenant que nous avons réussi à sauvegarder notre vCenter, voyant comment le restaurer. Rien de bien compliqué… Comme indiqué dans l’introduction, nous allons utiliser l’outil de déploiement d’un vCenter (présent sur l’image ISO d’installation) et suivre pas à pas les instructions. Il est à noter que certains paramètres peuvent-êtres modifiés lors de la restauration, vous pouvez par exemple sélectionner une taille d’appliance plus grande (mais pas plus petite), vous pouvez aussi changer l’IP (n’oubliez pas de mettre à jour votre DNS dans ce cas).

  1. Exécutez l’outil d’installation et sélectionner Restore

2. Dans la fenêtre Enter Backup Details, fournissez les informations nécessaires pour accéder aux données sauvegardées

3. Dans les fenêtres suivantes, fournir les informations nécessaires à la création d’un nouveau vCenter

4. Allez prendre un café le temps que dure la restauration…

A la fin de la procédure, vous pourrez de nouveau accéder à votre vCenter / PSC.

L’outil parfait pour sauvegarder mon vCenter ?

Est-ce que cette nouvelle fonctionnalité va remplacer les outils classiques pour sauvegarder votre vCenter ? Clairement non, l’impossibilité de planifier simplement les jobs et le fait de devoir posséder une image ISO d’installation d’un vCenter pour restaurer sont des limitations qui peuvent rebuter.

Par contre je me souviens d’un temps pas si lointain ou des bugs CBT faisaient que la restauration des VM n’était pas garantie, dans ce contexte, posséder un deuxième moyen de sauvegarde prend plus de sens… A vous de voir !

Erwan Quélin est depuis 6 ans Ingénieur Systèmes chez Cheops Technology. Ses interventions sont multiples et auprès de clients très diversifiés dans la région Ouest. Spécialisé dans la virtualisation autour des produits VMware et dans le stockage autour des gammes VNX, Unity et VPLEX de Dell EMC, Erwan est certifié VMware Certified Professional – Datacenter virtualization 4, 5 et 6 ainsi que EMC Implementation Engineer – VNX et Unity et vient d’intégrer les programmes VMware vExpert et Dell EMC Elect pour l’année 2017.

Lorsqu’il lui reste un peu de temps libre, Erwan développe des projets open sources ayant pour sujet principal l’automatisation d’infrastructures.

Pour suivre Erwan et pour plus d’informations sur son parcours et ses compétences :

Voir mon profil LinkedIn Erwan Quelin Voir le profil Linkedin d’Erwan

Voir mon profil GitHub Erwan Quelin Voir le profil GitHub d’Erwan

 

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

Packer, automatiser la création d’images systèmes

Par défaut

Logo HashiCorp Packer

Il y a, dans le monde surpeuplé des outils DevOps, une société qui aujourd’hui tire son épingle du jeu en proposant des produits open source novateurs et devenus des références sur le marché. HashiCorp est une start-up fondée en 2012 par Mitchell Hashimoto et Armon Dadgar, ils se sont donnés pour but d’offrir un panel d’outils complet pour l’automatisation du datacenter. Cela se traduit par des outils « Infrastructure as a Code » permettant de créer et manager des environnements complexes (Terraform), gérer de manière sécurisée et distribuée les « secrets » liés aux applications (Vault) ou bien faciliter la mise à disposition d’environnement de développement (Vagrant). Dans cet article, je vous propose de nous attarder sur un autre produit, Packer.

Packer a été développé pour faciliter la création d’images de système d’exploitations, que ce soit des machines virtuels ou bien des containers. A partir d’un simple fichier de configuration, Packer est capable de préparer en parallèle ces images sur différents environnements cloud (AWS, Azure, GCE), on-premises (vSphere, Hyper-V,etc…) ou bien même sur son propre ordinateur (VirtualBox, Fusion, Workstation…). Packer est une réponse concrète aux problèmes de gestion des images, que ce soit sur une infra « simple » (qui n’a jamais rêvé d’avoir à disposition des images de VM toujours à jour ?) ou bien sur des environnements plus complexes (une application développée sur des laptops, testée sur une infra locale et mise en production sur un cloud public).

Prérequis techniques

On en a terminé avec la présentation marketing, voyons maintenant comment Packer fonctionne et si oui ou non il est bien l’outil qui réconciliera à jamais les devs et les ops ! Commençons par les habituels prérequis. Il va vous falloir créer un répertoire de travail (pour stocker le fichier de conf ainsi que les différents scripts), un éditeur de texte et… installer Packer… Que vous soyez sous Linux, Windows ou MacOS, pas de problème HashiCorp a pensé à vous. Il vous suffit juste de télécharger l’exécutable (liens vers site) et de le placer dans un répertoire qui est disponible dans le PATH. Maintenant sortez votre plus beau shell et exécutez la commande packer:

En avant pour une première image !

Vous voilà fin prêt à construire votre première image! Je sens d’ici votre excitation ! Mais avant que vous ne vous lanciez à corps perdu dans l’aventure, je vous propose que nous passions du temps à détailler le contenu d’un fichier de configuration qui nous permettra de créer une image Windows Server 2016 sur AWS.

Le reste de l’article va faire appel à des notions liées à AWS ou bien les OS Microsoft. Ce n’est pas grave si cela vous est complètement étranger, cela ne vous empêchera pas de comprendre comment fonctionne Packer.

Vous pouvez retrouver le fichier de configuration Packer ainsi que les différents scripts sur Github.

Le fichier de configuration (appelé template dans la documentation officielle) est au format JSON, il va contenir la trame des différentes étapes qui auraient été nécessaires à un déploiement manuel, à savoir:

  • Créer une « machine virtuelle » (VM VMware vSphere, Instance AWS EC2, container Docker, etc…)
  • Provisionner un système d’exploitation (ce n’est pas forcément nécessaire dans les clouds publics)
  • Personnaliser l’OS à l’aide de scripts (exécutés par exemple via SSH ou WinRM) ou bien d’outils tiers tels que Chef ou Ansible
  • Et enfin, créer une image que vous pourrez utiliser par la suite pour déployer d’autres environnements identiques.

Les Builders, spécialistes du gros œuvre

On va commencer par définir un Builder qui aura la tâche de créer la machine virtuelle avec les caractéristiques qu’on lui aura indiquées. Il existe plusieurs types de Builder en fonction de l’environnement sur lequel vous voulez déployer votre machine. Etant donné que la cible est AWS, nous allons utiliser un Builder du type amazon-ebs

Je ne vais pas rentrer dans les détails car les différents paramètres sont spécifiques à AWS et Windows. Pour résumer, ce Builder va se connecter à AWS en utilisant la clé spécifiée (access_key, secret_key), créer une instance EC2 à partir d’une image fournie par AWS (source_ami) et essayer de se connecter au serveur Windows via le protocole WinRM. Une fois qu’il aura réussi à établir une connexion, il laissera la main pour la suite des opérations.

Les Provisionners, détails et finitions

Maintenant que nous disposons d’un OS « de base » nous allons pouvoir le configurer suivant nos besoins. C’est là qu’entre en scène les provisionners. Comme leur nom l’indique, ils vont nous permettre d’interagir avec l’OS via différents moyens de communication (Scripts, Chef, Ansible…) pour pouvoir le personnaliser.

Dans l’exemple ci-dessus, nous avons défini trois provisionners différents. Ils seront exécutés séquentiellement par Packer. Le premier va exécuter plusieurs scripts Powershell qui sont stockés dans le sous-répertoire scripts de notre répertoire de travail. Étant donné qu’un des scripts va effectuer les mises à jour Microsoft Update, le deuxième provisionner va redémarrer Windows et attendre qu’il soit de nouveau disponible. Enfin, le dernier va exécuter des scripts stockés sur l’OS et qui font partis des outils qu’inclus AWS dans ses images. Ils ont pour but de préparer l’OS à être transformé en template.

Si tout se passe comme prévu lors de l’exécution des différentes opérations de personnalisation, Packer va faire tout le travail restant à savoir:

  • Éteindre l’instance EC2
  • La transformer en un template (AMI) qui sera disponible dans votre console AWS.

Maintenant que nous avons créé notre fichier de configuration, nous allons pouvoir valider qu’il ne contient pas d’erreurs de syntaxe avec la commande packer validate monfichier.json

> packer validate .\aws-windows-dsc.json Template validated successfully.

Si la commande ne retourne pas d’erreur alors nous pouvons lancer la création du template avec la commande packer build monfichier.json

Attention, la création d’un template peut prendre beaucoup de temps notamment si, comme dans cette exemple, vous mettez à jour votre serveur Windows…

Il n’y a plus qu’à attendre que Packer finalise la création du template et vous devriez avoir à votre disposition un AMI flambant neuf dans votre interface EC2.

J’espère que cet article vous aura donné envie de tester plus en profondeur Packer. A mon avis le potentiel de l’outil est énorme et devrait faire partie des indispensables de votre trousse à outils, que vous soyez Ops ou Dev.

N’hésitez pas à laisser un commentaire ou bien contactez moi sur twitter (@erwanquelin) pour toutes questions.

Pour aller plus loin

Les sites ou articles ci-dessous ont été une source d’inspiration non négligeable !:

Le titre auquel vous avez échappé

  • Packer Lewis ne perd jamais
Erwan Quélin est depuis 6 ans Ingénieur Systèmes chez Cheops Technology. Ses interventions sont multiples et auprès de clients très diversifiés dans la région Ouest. Spécialisé dans la virtualisation autour des produits VMware et dans le stockage autour des gammes VNX, Unity et VPLEX de Dell EMC, Erwan est certifié VMware Certified Professional – Datacenter virtualization 4, 5 et 6 ainsi que EMC Implementation Engineer – VNX et Unity et vient d’intégrer les programmes VMware vExpert et Dell EMC Elect pour l’année 2017.

Lorsqu’il lui reste un peu de temps libre, Erwan développe des projets open sources ayant pour sujet principal l’automatisation d’infrastructures.

Pour suivre Erwan et pour plus d’informations sur son parcours et ses compétences :

Voir mon profil LinkedIn Erwan Quelin Voir le profil Linkedin d’Erwan

Voir mon profil GitHub Erwan Quelin Voir le profil GitHub d’Erwan

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

L’admin de demain ! [ Introduction ]

Par défaut

Cela n’aura échappé à personne mais nous vivons une époque de profonds changements dans notre métier. De nombreuses nouvelles technologies venant bousculer nos habitudes d’Administrateur Datacenter ou étant sur le point de le faire. J’avais envie de partager avec vous ma réflexion sur le sujet.

Je me rappelle régulièrement cette phrase lorsque que j’effectue une étude technique : « Nous faisons partie du système considéré ». Il est donc aussi évident de se poser la question des impacts de ce nouveau système sur les hommes et les femmes qui le design, l’administrent et l’exploitent.

Je vais dans ce premier article introduire les différents sujets que je traiterais dans le détail sur ce blog dans les mois à venir. Evidemment, certains d’entre vous sont déjà familiarisés avec ces sujets et penserons que nous enfonçons gaiement des portes ouvertes, et c’est tant mieux ! N’hésitez pas à participer aux discussions, décrire vos retours d’expériences car nous allons ensemble prendre des risques !

Les années « Stabilité » et « Résilience »

Depuis une dizaine d’années, je vais forcer le trait en disant que nous avons pensé essentiellement à la résilience de nos plateformes. Des crashs importants intervenus dans les années 2000 ont poussé le marché à développer des solutions de continuité d’activité. Bienvenue au PRA et au PCA qui ont occupé ma vie d’intégrateur pendant pas mal de temps.

D’un autre côté, les entreprises et organismes publics ont pris conscience de leur dépendance au « Système d’Information », et ont essayé de prendre toutes les précautions pour que celui-ci dispose d’une qualité de service très importante.

J’y reviendrai plus tard mais cette période, quoique féconde en révolution, comme la virtualisation. (Quoi ? Qu’entends-je au loin ? Un admin IBM courroucé par mes propos pensant que la virtualisation existe depuis des décennies ? NDLR : Il a raison ;o) ou le stockage partagé me laisse un peu sur ma faim, voir en demi-teinte. Ces nouvelles technologies ont effectivement permis de maitriser son « SI » qui était en pleine croissance, l’émergence de nouveaux produits dans le monde de la protection des données par exemple. Toutefois, la couche supérieure n’a pas franchement évolué (Serveur d’applis + BDD, Annuaire AD, messagerie, serveur de fichier, un firewall périmétrique).

Je vais être honnête, je me suis éloigné d’une certaine forme d’expertise pendant cette période. Pour prendre un exemple concret, là où je passais plusieurs semaines à préparer une Master Windows 2003 Server fin des années 2000, ½ journée était consacrée à la même action quelques années plus tard.  J’ai déplacé mon activité vers l’infrastructure matérielle au détriment des services applicatifs. Pour résumer, je pense que la simplification des outils du SI a entrainé une diminution de mes compétences d’informaticien (scripting, language de dev, SQL…etc). « Mode Introspection = OFF ».

Une simplification et une diminution du maintien en condition opérationnel des infrastructures.

Il faut reconnaitre que les constructeurs et éditeurs font de gros efforts pour simplifier l’administration des infrastructures et son maintien en condition opérationnel. La plupart des produits ont largement réduit la complexité des mises à jour (voir effectuer directement les mises à jour à notre place), créer de nouvelles interfaces beaucoup plus accessibles, des assistants… ; Finalement sont apparus des environnements de plus en plus « User Friendly », nous permettant d’administrer une bien plus grande capacité de ressources avec des moyens humains constants, voir dans de nombreux cas, en baisse.

Après tout, à cette époque, l’informatique n’est pas le cœur de métier des entreprises et des organismes publics.

2010/2015 : « l’explosion »

Après le raz de marée des années 2005/2010 sur Internet, les smartphones, les réseaux sociaux…débute une période d’effervescence. Je ne vais pas m’étendre sur l’ensemble mais je pense que cette liste démontrera simplement à quelle vague nous avons à faire : Disque Flash, Powershell, HTML5, Cloud Public-Privé-Hybrid, Du IaaS au XaaS, Bid Data, Hyper-convergé, Containers, micro-services, NVME, IoT, Blockchain, Intelligence Artificielle, A Réalité Augmenté…Etc. Bodhi, dans Point Break, aurait parlé de la vague des 50 ans. Mais finalement, le résultat de toutes ces innovations, c’est que l’IT ne représente plus un cout mais un vecteur d’innovation et de développement pour les entreprises privées et organismes publics. Le SI intègre le cœur de métier de leurs activités. Et ça, cela change tout !

Et les administrateurs dans tout ça.

Mais revenons à nos moutons. Quel va être notre place dans les années à venir. Nous allons devoir déporter notre activité quotidienne de maintien en condition opérationnel de l’infrastructure vers des actions à plus forte valeur ajouté. C’est le cas pour les administrateurs mais également pour les intégrateurs. Les sujets ne manquent pas. Je vais vous présenter certains aspects de l’évolution de notre métier qui me semblent essentiel d’appréhender. Chaque sujet fera l’objet d’un article dédié par nécessité mais également par plaisir d’aller plus loin sur ces sujets.

Administrateur « Datacenter » – Système « ET » Réseau

C’est une réalité que l’on vit au quotidien mais il devient difficile voire impossible d’appréhender seulement une partie du Datacenter tant les dépendances deviennent importantes. Ce mouvement s’observe depuis déjà quelques années. Evidemment, l’avènement du SDN avec des produits comme VMware NSX vont accélérer cet état de fait mais pas seulement.

Pour maitriser les thématiques de troubleshooting, d’analyse des performances et de tuning, des designs multi-site, il faut comprendre et maitriser le transport des flux. Pas besoins toutefois d’être un « mutant » sur l’ensemble des technologies mais une bonne compréhension des basics me semble nécessaire. Dans un sens comme dans l’autre. Je n’aborde délibérément pas la sécurité que je traiterai à part. Rappelons-nous que notre formation initiale nous avait préparé à ça. Mais plus les structures ou nous exercions étaient importantes et plus les équipes se sont segmentées par expertise.

L’automatisation du Datacenter

1 étape de notre démarche, l’automatisation du Datacenter. Les matériels et logiciels sont aujourd’hui entièrement pilotables grâce à des langages de script beaucoup plus performants comme PowerShell (qui entraine des suites comme PowerCli sur les environnements VMware). Les API (Application Programming Interface) « REST » sont également de la partie. Pourquoi automatiser son Datacenter ? Je pourrais dérouler tous les arguments du marché sur le sujet mais je vais me permettre une rapide synthèse : Faire plus et mieux avec des moyens (financier et humain) identiques ou en baisse. L’automatisation des actions récurrentes d’une faible valeur ajoutée permet de basculer sur des actions plus pertinentes que nous aborderons plus tard. Je prendrais le temps de développer ce point dans un autre article mais avec les outils à notre disposition aujourd’hui dans les secteurs du IaaS et du SaaS, j’ai tendance à dire qu’il suffit d’être imaginatif pour comprendre les enjeux de l’automatisation. Il est également important de noter que chaque action industrialisée permet de diminuer le risque d’erreur et augmente la sécurisation des processus de son IT. Je reviens également sur mon premier point : peu probable d’avancer sur ce sujet sans avoir une bonne connaissance de son réseau et d’avoir mis un pied dans le SDN. Nous allons devoir creuser certains sujets !

Supervision / Monitoring & recherche de la performance

Ce n’est plus nécessaire d’expliquer la nécessité d’avoir un système de supervision à la hauteur des nouveaux enjeux et je ne parle pas seulement de « pinger » des ressources, mais d’effectuer de la supervision applicative, d’automatiser des rapports sur la qualité de service de son SI. De nombreux outils gravitent sur ce marché même si, avec une partialité assumée, je vous conseille EyeOfNetwork (Communauté dans laquelle pas mal d’amis gravitent). Coté Monitoring, nous devons reprendre du temps à analyser notre production, comprendre les points de contention, s’efforcer de mettre les quelques coups de tournevis qui peuvent énormément augmenter les capacités du Datacenter. Encore une fois, je pense que nous avons mis de côté pendant pas mal d’année cette activité pour de nombreuses raisons évidentes : On ne touche pas une « prod » qui marche, on manque de temps, le besoin n’est pas exprimé par l’utilisateur final…Etc. Cependant, quoi de plus intéressant que de comprendre les informations remontées par les bons outils du marché (Sexygraf, DC Scope, VMware vRops…), de les analyser, et d’appliquer des correctifs sur sa production avec des impacts directs et positifs sur l’expérience utilisateur !

La sécurité

Comment aborder ce sujet ? Evidemment la sécurité de son SI devient primordiale. Les données deviennent vitales pour l’entreprise ou pour tout établissement public, les données ont une valeur avec le développement du Big Data. Les sécuriser devient stratégique. Les outils du marché se développent et de nouveaux sujets apparaissent comme la micro-segmentation, les security maps, la gestion de la mobilité…etc. Il y a un boulot énorme sur ces sujets et même si je ne suis pas dans mon domaine d’expertise, je tenterai de balayer l’état des offres actuelles et des différentes méthodologies à connaitre pour augmenter la sécurisation de son SI.

DevOps : Aller au-devant des métiers

Tous les sujets que j’ai évoqués plus haut convergent vers un seul but: offrir un service de meilleure qualité à ces services métiers et aux utilisateurs du SI. La méthode DevOps nous pousse à amener de la valeur, à améliorer la production des équipes métiers. C’est une démarche qui permet aux équipes de développement et d’infrastructure de collaborer plus efficacement face aux nouvelles exigences de la digitalisation.

Quand on a dit ça, on fait quoi ? Finalement, on tente t’intégrer les démarches de sécurité, d’audit, et d’automatisation tout au long du processus de développement de ses offres de service jusqu’à la production par les utilisateurs, en restant agile. Facile, non ?

La protection des données

Tous les modifications de process et d’infrastructure que j’ai évoqué ci dessous nous oblige à repenser nos plateforme de protections des données (sauvegarde/restauration, Archivage, Copie..etc). Le type et l’emplacement des données, les volumétries changement mais le plus important, les données générées ont maintenant un coût et peuvent servir la stratégie de l’entreprise ou de l’établissement public ! Le « Data Management » prends finalement tout son sens aujourd’hui. Apprendre à correctement protéger nos données et le prouver devient essentiel.

Conclusion

A l’heure du développement du cloud public, il serait naïf de penser que les performances et la qualité de service de notre infrastructure ne seront pas comparées avec des ressources du cloud public. La cohabitation est nécessaire, toutefois le datacenter « On Premise/hybrid » n’a pas encore dit son dernier mot !

 

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

Le SDS en infographie

Par défaut

Le SDS de A à Z   

Le logiciel est partout. Serveur, stockage ou réseau, il n’existe plus un pan de l’infrastructure qui ne soit passé par la case « software-defined », au point que l’on parle aujourd’hui de « software-defined datacenter », voire même de « software-designed everything ». Mais toutes les couches du centre de données défini par logiciel n’en sont pas au même point. Alors que la virtualisation serveur est la norme depuis maintenant des années, la virtualisation du réseau prend plus de temps à se développer, notamment en raison d’une mise en œuvre plus complexe. Entre les deux, la virtualisation du stockage, ou software-defined storage (SDS) est en pleine explosion. En 2016, seules 10 % des entreprises affirmaient n’avoir aucun projet dans ce domaine. Utilisation, avantages, fonctionnalités, freins, on vous dit tout sur le SDS en infographie:

 

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook

Mise en place d’un certificat signé par une autorité de certification sur une baie Dell EMC Unity

Logo Dell EMC Unity
Par défaut

A peu près tout le monde s’accorde à dire que la sécurisation des communications est un enjeu majeur pour les entreprises. Malheureusement le problème est trop rarement pris en compte en ce qui concerne les interfaces d’administration des différents éléments qui composent le SI. La mise en place de certificats valides en remplacement des autosignés serait un grand pas en avant. Alors pourquoi ce principe de sécurité de base est-il trop peu souvent appliqué ? Une explication possible est que souvent les éditeurs/constructeurs ne facilitent pas la tâche aux intégrateurs/administrateurs en ne documentant pas (ou trop succinctement) les opérations à réaliser pour atteindre ce but.

Dans cet article je vous propose de remédier partiellement à ce problème en détaillant la procédure pour installer un certificat signé par une autorité de certification Microsoft Active Directory sur une baie Dell EMC Unity. Ce certificat servira à:

  • Garantir que vous êtes bien connecté à la baie souhaité, on peut ainsi dire qu’il fait office de carte d’identité de l’équipement,
  • Chiffrer les communications entre votre navigateur et la baie.
  • Ne plus avoir à cliquer 36 fois pour certifier que oui, on veut vraiment se connecter à cette baie même si les communications ne sont pas sécurisées…

Bien que spécifiquement rédigée pour les Unity, cette procédure devrait vous donner de bonnes bases pour répéter l’opération sur d’autres équipements.

Workflow

L’opération peut se résumer en 4 étapes:

  1. La validation des prérequis
  2. La génération d’une demande de certificat ainsi que d’une clé privée associée
  3. L’obtention d’un certificat signé par une autorité de certification AD
  4. L’importation de ce certificat et de la clé privée dans la baie Unity.

Prérequis

Pensez à valider les prérequis suivants avant de dérouler la procédure !

  • OpenSSL doit être installé sur votre poste de travail

Pour cet article, la version 1.1.0.5 a été utilisée.

  • Vous devez disposer d’un accès à une autorité de certification Microsoft AD

Il vous faudra les identifiants d’un compte ayant les droits nécessaires pour effectuer une demande de certificat. Les instructions que vous trouverez dans cet article correspondent à une autorité de certification hébergée sur un serveur Windows 2012 R2.

  • Un accès en SSH à la baie Unity (via le compte Service)

L’accès SSH doit avoir été activé préalablement sur la baie. Le mot de passe du compte service est généralement le même que celui du compte admin.

  • Un outil pour transférer le certificat et sa clé privée sur la baie Unity.

Si vous vous servez d’un système d’exploitation de Microsoft, un utilitaire comme WinSCP fera parfaitement l’affaire.

Procédure

Générer une demande de certificat et une clé privée avec OpenSSL

La première étape va consister à générer une demande de certificat ainsi qu’une clé privée associée. Nous allons utiliser OpenSSL pour cela. Pour nous faciliter la tâche et éviter d’avoir une longue liste de questions auxquelles répondre pendant la génération de la demande, nous allons créer un fichier de réponse nommé openssl.txt et contenant les informations suivantes (à modifier suivant vos besoins…):

Le champ CN doit correspondre exactement au FQDN utilisé pour se connecter à l’interface de management de la baie. Les champs DNS.1 et DNS.2 correspondent respectivement au nom long et au nom cours de la baie. Le champ IP.1 représente l’IP d’administration.

Une fois ce fichier créé nous pouvons l’utiliser pour générer la demande:

PS C:\Unity> openssl req -new -nodes -out unity.csr -newkey rsa:2048 -keyout unity.pk -config .\openssl.txt

Si tout se passe bien, vous devriez voir les informations suivantes apparaitre:

Generating a 2048 bit RSA private key
....+++
.........................................+++
writing new private key to 'unity.pk'
-----

Vous devez maintenant disposer de deux nouveaux fichiers. Dans notre exemple le fichier unity.csr correspond à la demande de certificat qui sera soumise à l’autorité de certification. Le fichier unity.pk contient la clé privée qui a permis de signer cette demande.

Pensez à conserver la clé privée, elle sera par la suite copiée sur la baie Unity.

Pour valider que la demande de certificat a correctement été générée, utilisez la commande ci-dessous:

PS C:\Unity> openssl req -in .\unity.csr -noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=FR, ST=Loire-Atlantique, L=Nantes, O=
Myvmworld, OU=Lab/emailAddress=administrator@exemple.com, CN=srv-unity-01.exemple.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c5:b0:a1:d4:98:9b:c8:25:04:71:cd:36:e6:ce:
f6:83:aa:5d:77:e4:fa:58:4e:b2:81:0f:23:5c:59:
d0:c5:0c:3f:37:88:32:b2:a4:a2:03:c0:c5:00:00:
b8:a3:96:17:52:a6:cc:ef:36:2a:e7:f9:5c:26:46:
50:55:65:44:7f:fd:f8:03:3e:39:d1:fc:97:e1:37:
7f:5c:1b:20:36:fc:d5:ae:31:f6:49:58:fb:5d:4a:
....
d0:73:fa:97:12:f0:bb:ac:cb:c3:a0:8e:f1:1c:eb:
66:3c:f0:50:85:f3:be:21:53:82:98:73:af:b9:12:
7d:68:9c:dd:fa:3a:c3:b9:5c:8b:8e:40:60:f9:35:
97:eb:e5:34:0b:97:d7:43:a3:1e:f2:a4:bf:a7:03:
e8:db:c2:5b:7d:e1:c1:a8:33:61:6b:30:b3:16:79:
10:12:cf:67:f2:fd:ad:68:7c:0d:dc:8b:37:c6:55:
19:49
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
DNS:srv-unity-01.exemple.com, DNS:srv-unity-01, IP Address:192.168.0.1
Signature Algorithm: sha256WithRSAEncryption
18:45:de:02:16:a1:e3:d4:9e:d6:74:87:61:74:a9:bf:a0:5f:
2c:09:1c:b5:2b:0f:42:26:0e:f2:40:29:ea:51:73:54:3d:4e:
53:f7:73:ef:16:98:ac:20:1a:c8:15:7c:b9:df:de:39:ec:c0:
fa:4b:f2:06:99:47:c7:8a:a3:f3:6f:28:2b:07:a2:be:84:f6:
....
b4:6b:09:fa:cb:79:7f:83:95:43:32:2e:14:94:f4:eb:b9:88:
27:62:cf:24:bb:54:9c:d6:69:2e:eb:ae:0e:cb:4d:fc:09:12:
19:b8:2e:c4:ac:06:a0:9d:a7:09:48:e7:54:9a:aa:f7:df:27:
6b:17:5d:79:43:88:0a:4f:be:f9:ae:c4:3f:a4:0c:2c:47:2a:
25:dd:3c:10:44:b5:10:35:ef:d0:d1:2e:25:19:b1:33:9c:99:
9a:2b:28:62

Vous devriez retrouver les informations fournis dans le fichier de réponse.
Nous avons maintenant en notre possession les informations nécessaires pour effectuer une demande de certificat auprès d’une autorité de certification.

Générer un certificat signé par une autorité de certification Microsoft AD

Dans l’étape précédente nous avons généré une demande de certificat ainsi que sa clé privée. Nous allons nous en servir pour obtenir un certificat, il sera signé par l’autorité de certification afin d’en valider la provenance.

Pour réaliser cette opération, connectez-vous au service web de votre autorité de certification. Il s’agit d’une page web généralement accessible à l’adresse http://<FQDN autorité de certification>/certsrv. Une fois authentifié, vous devrez:

  1. Cliquer sur la tâche Demander un certificat
  2. Cliquer sur demande de certificat avancé
  3. Cliquer sur Soumettez une demande de certificat en utilisant un fichier CMC ou PKCS #10 codé en base 64, ou soumettez une demande en utilisant un fichier PKCS #7 codé en base 64
  4. Dans le champ Demande enregistrée copié le contenu du fichier de demande de certificat (ici unity.csr)

Copier l’intégralité du contenu du fichier, penser à y inclure la première et dernière ligne -----BEGIN CERTIFICATE REQUEST----- et -----END CERTIFICATE REQUEST-----

  1. Dans le champ Modèle de certificat sélectionner Serveur Web

  1. Cliquer sur Envoyer
  2. Sur la page Certificat émis sélectionner Codé en base 64 et cliquer sur Télécharger le certificat
  3. Enregistrer le certificat sur votre poste et le renommer en unity.crt

Par défaut le certificat généré se nomme certnew.cer

Importer le certificat et la clé privée sur la baie Unity

Maintenant que nous disposons d’un certificat signé par l’autorité de certification et de sa clé privée. Nous allons l’importer sur la baie. Au préalable il va vous falloir copier les 2 fichiers concernés sur la baie. Un utilitaire comme WinSCP fera parfaitement l’affaire.

Dans l’exemple ci-dessous les fichiers ont été copiés dans le répertoire ~/cert.

Le certificat et la clé privée doivent être nommés de la même manière à l’exception bien sûr de l’extension…

14:10:39 service@VIRT1710RZW84B-spa spa:~/cert> ll
total 8
-rw-r--r-- 1 service service 1764 Jun  6 14:21 unity.crt
-rw-r--r-- 1 service service 1704 Jun  6 14:16 unity.pk

L’importation du certificat se fait avec la commande svc_custom_cert. Il faudra préciser le nom de base des fichiers. Dans notre cas, en indiquant que le nom de base est unity la commande va chercher à importer les fichiers unity.crt (certificat) et unity.pk (clé privée).

14:19:00 service@VIRT1710RZW84B-spa spa:~/cert> svc_custom_cert unity

Si tout se passe bien, vous devriez voir le message suivant indiquant que l’import c’est correctement déroulé.

Successfully installed custom certificate files.
Restarting web server ...
Tue Jun  10 14:19:53 2017:633e\0x7fcf2c3a97c0:32:Module CIC/1.1.10.6 loaded

A partir de maintenant, lorsque vous vous connecterez à Unisphere, vous aurez le plaisir de voir apparaitre le fameux cadenas dans la barre d’adresse !

J’espère que cet article vous aura été utile et que vous aurez pu facilement le suivre pour installer un nouveau certificat sur votre baie Unity.

N’hésitez pas à laisser un commentaire ou bien contactez moi sur twitter (@erwanquelin) pour toutes questions.

Share This...Buffer this pageShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePin on PinterestShare on Facebook