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 reproduit 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

Le blog myvmworld.fr évolue et devient collaboratif !

Par défaut

Myvmworld

La rentrée de Myvmworld affiche un nouveau tournant… Mon blog personnel devient désormais une plateforme collaborative plus riche où vous aurez la possibilité de découvrir plus de contributions avec des articles sur des thèmes élargis.

Myvmworld prend en effet une nouvelle dimension. Nous serons désormais trois contributeurs et plus encore dans quelques semaines à vous décortiquer l’actualité, animer et enrichir l’écosystème des infrastructures virtuelles, Cloud, automatisation, vous parler technique, process, vision, … 
 
Sur ce blog, nous partagerons avec vous sur nos spécialités respectives afin de mieux répondre à vos besoins croissants d’informations.
 

Nous sommes donc trois blogueurs avec chacun notre univers ! Retrouvez désormais Damien, Erwan, et Eric, spécialistes virtualisation, stockage, automatisation, et network.

Retrouvez-nous aussi dans quelques jours pour des feedback en direct du vmworld.

Bonne découverte !
Présentation des auteurs du blog Myvmworld sur la page About Us

Eric MAILLE, Eric est Consultant avant-vente chez DELL EMC. Il intervient en phase amont des projets d’infrastructure et conseille les entreprises sur les choix et les orientations technologiques.
Eric travaille en collaboration étroite avec les équipes service/consulting chez DELL EMC pour aider les entreprises à accélérer leur transformation Digitale. Eric Maillé a co-écrit 2 livre sur VMware vSphere 4 et vSphere 5 , il est certifié VMware VCP, EMC Cloud Architect et a été récompensé du titre de vExpert 2011 et 2012.

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

Voir mon profil LinkedIn Eric Maille Voir le profil d’Eric Maille

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

Damien Rivière est depuis près de 9 ans consultant chez Axians Cloud Builder. Spécialisé dans la virtualisation autour des produits VMware et dans le stockage autour des solutions Dell EMC, Damien est certifié VMware Certified Professional – Datacenter virtualization 4, 5 et 6 ainsi que EMC Implementation Engineer – VNX et Unity. Damien est également certifié VCP6-NV (Network Virtualization), DCIE Datacore, AWS Technical Professional, CCNA Cisco, Netapp, Simplivity…

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

Voir mon profil LinkedIn Damien Rivière Voir le profil de Damien

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

VMworld 2017 – Once again!

Par défaut

vmworld 2017 EU – Barcelona

vmworld 2017 se profile… Cet event bien huilé d’un point de vue organisationnel, technique & marketing demeure un incontournable pour qui souhaite s’enrichir en amont des évolutions techniques et technologies à venir dans notre monde très en vogue de la virtualisation et du Cloud.

Pour cette 6ème participation, me voici à nouveau invité en tant que Blogger par la communauté vExpert !

Un remerciement appuyé à Elsa & Corey qui m’ont attribué ce pass blogger !

Les 10 bonnes raisons de venir au VMworld 2017 à Barcelone :

Avant une immersion sous peu dans les antres du Fira, un retour sur les éditions passées et les publications antérieures ayant rythmé ce blog sur ce sujet. Un bon moyen d’appréhender les contenus qui vous seront fraîchement proposés.

Be_TOMORROW Starts Now – VMworld Day 1

VMworld 2015 Barcelona- Ready For Any

VMworld 2014 Day 2

VMworld 2013 – Day 1

Hashtags à utiliser et à suivre lors du VMworld:

  • #vmworld – VMworld 2017 conference
  • #vmworldHOL – VMware Hands-On Labs at VMworld
  • #vmworld3word – 3-word creative tweets
  • #vmworldselfie – selfie or group photos
  • #VMwarePEX – Partner Exchange

Inscription au VMworld 2017:

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