Migration !

Bonjour à tous !

Après des années de bons et loyaux services, j’ai décidé de m’affranchir de l’hébergement chez wordpress.com.

Les comptes gratuits chez wordpress.com sont trop bridés (limites d’espace de quelques Go pour les médias, pas de possibilité d’ajouter de plugins ou de toucher au CSS sans devoir mettre la main au porte monnaie) et je trouvais que cela fait plus sens de gérer moi même mon blog sachant que je passe mon temps à bidouiller et que j’administre tout à la maison 😉

Il est donc temps de changer vos bookmarks, les prochains articles ne seront disponibles que sur https://blog.zwindler.fr

See you soon
Zwindler

Publicités
Migration !

Changer le clavier qwerty par défaut de l’appliance vCenter vCSA de 5.0 à 5.5

Merci d’aller voir l’article sur mon nouvel hébergement, l’article y est plus à jour :

http://zwindler.fr/wordpress/2015/04/08/changer-le-clavier-qwerty-par-defaut-de-lappliance-vcenter-vcsa-de-5-0-a-5-5/


 


Depuis vSphere 5.0, il est possible d’installer un vCenter sur une appliance virtuelle Linux et ainsi s’affranchir du cout d’une licence Windows, parfois utilisé exclusivement pour ce besoin.

Ça vous oblige à trancher par défaut la question du vCenter physique ou virtuel (voir http://zwindler.fr/wordpress/2010/06/01/vcenter-ou-quand-comment/) et à vous accommoder de certaines limitations assez agaçantes (pas compatible avec les modules vCenter tiers + vSphere Update Manager doit quand même être installé sur Windows ? « Allo quoi! » comme dirait l’autre), mais s’affranchir de Windows, ça n’a pas de prix 😉

Plus sérieusement, la vMA (vSphere Management Assistant) a pas mal évolué depuis la version vMA 4 pour arriver jusqu’à un vMA 5.5 en Suse Entreprise Linux Server (1 licence SLES incluse avec votre licence vCenter !!! Youhou!), mais tout n’est pas encore parfait.

Un des gros problèmes est que, encore aujourd’hui, la console sur le vCenter est en qwerty.

AAAAAAAAAH !

Si vous avez une IP à changer ou un fichier de conf à modifier (par exemple http://zwindler.fr/wordpress/2013/05/07/reduire-la-ram-consommee-par-la-vmware-vcenter-appliance-5-1/), vous allez devoir connaitre votre correspondance azerty/qwerty par cœur.

C’est un bon exercice cela dit, mais je suis sympa, je vais vous donner un coup de main 😉

Lire la suite « Changer le clavier qwerty par défaut de l’appliance vCenter vCSA de 5.0 à 5.5 »

Changer le clavier qwerty par défaut de l’appliance vCenter vCSA de 5.0 à 5.5

Echec déploiement package OVF: Cette tâche a été annulée par un utilisateur

Merci d’aller voir l’article sur mon nouvel hébergement, l’article y est plus à jour :

http://zwindler.fr/wordpress/2015/03/30/echec-deploiement-package-ovf-cette-tache-a-ete-annulee-par-un-utilisateur/


 


 
Depuis vSphere 5.X, il est possible d’installer un vCenter sur une appliance virtuelle Linux et ainsi s’affranchir du cout d’une licence Windows, parfois utilisé exclusivement pour ce besoin.

Ça vous oblige à trancher par défaut la question du vCenter physique ou virtuel (voir http://zwindler.fr/wordpress/2010/06/01/vcenter-ou-quand-comment/) et à vous accommoder de certaines limitations assez agaçantes (pas compatible avec les modules vCenter tiers + vSphere Update Manager doit quand même être installé sur Windows ? « Allo quoi! » comme dirait l’autre), mais s’affranchir de Windows, ça n’a pas de prix 😉

Plus sérieusement, la vCSA (vCenter server Appliance) a pas mal évolué depuis la version 5.0 pour arriver jusqu’à un 5.5 en Suse Entreprise Linux Server (1 licence SLES incluse avec votre licence vCenter !!! Youhou!), mais tout n’est pas encore parfait.

Un des gros problèmes est que, encore aujourd’hui, la console sur le vCenter est en qwerty.

AAAAAAAAAH !

Si vous avez une IP à changer ou un fichier de conf à modifier (par exemple http://zwindler.fr/wordpress/2013/05/07/reduire-la-ram-consommee-par-la-vmware-vcenter-appliance-5-1/), vous allez devoir connaitre votre correspondance azerty/qwerty par cœur.

C’est un bon exercice cela dit, mais je suis sympa, je vais vous donner un coup de main 😉

Lire la suite « Echec déploiement package OVF: Cette tâche a été annulée par un utilisateur »

Echec déploiement package OVF: Cette tâche a été annulée par un utilisateur

Accélérer le rebuild/resync d’un volume RAID mdadm

Ça fait plusieurs fois que je tombe sur des articles de blogs qui détaillent que la reconstruction de leur miroir MDADM (RAID1) est trèèèès lente à cause d’un paramètre système dans /proc :
/proc/sys/dev/raid/speed_limit_min

Par défaut sous Linux (ou au moins la plupart des distribs que je côtoie), ce paramètre « min » est fixé à 1000, soit grossièrement 1Mo par seconde, ce qui est effectivement très lent, à l’heure des disques grand public de 6 To (ou 8? ou 10, je ne suis pas sûr d’être à jour).

Personnellement, je n’ai jamais été bloqué par ce paramètre comme ces personnes, au moins sur les distributions récentes (tout est relatif, en 2015 je parle de 2012 et +). Il s’agissait peut être d’un bug fixé depuis, qui sait?

Par contre, là où j’ai été effectivement bloqué, c’est plutôt par la variable /proc/sys/dev/raid/speed_limit_max.

cat /proc/mdstat
   md1 : active raid1 sdc[0] sdd[1]
   336592832 blocks [2/2] [UU]
   [===========>.........] resync = 59.4% (199958272/336592832) finish=11.3min speed=200006K/sec

Quoi, mes disques resync à 200006K/sec? Comment dire ? C’est louche !

En effet, cette valeur est fixée par défaut à 200000, soit 200 Mo/s. Ça peut paraitre assez haut pour du RAID à la maison, mais sur du matériel d’entreprise, je n’ai pas eu de mal à atteindre cette limite.

cat /proc/sys/dev/raid/speed_limit_min
   1000
cat /proc/sys/dev/raid/speed_limit_max
   200000
echo 500000 > /proc/sys/dev/raid/speed_limit_max

cat /proc/mdstat
   md1 : active raid1 sdc[0] sdd[1]
   336592832 blocks [2/2] [UU]
   [===============>.....] resync = 76.4% (257424960/336592832) finish=2.6min speed=505767K/sec

« And voila »

Accélérer le rebuild/resync d’un volume RAID mdadm

IRL : RedHat virtualisé et haute dispo, RHCS+VMDK partagés vs vSphere Replication

Contexte

Dans un contexte professionnel, il arrive que des décisions soient prises et qu’il faille s’y tenir coute que coute. Même si on se rend compte plus tard que ce n’était pas forcément le chemin le plus facile. La facilité, c’est le côté obscur, on le sait bien ;-).

Pour un client, on m’a donc demandé de concevoir une plateforme RedHat 5.X virtualisée hautement disponible, avec une durée d’interruption de service maximale de 30 minutes en toute circonstance (jusque là tout va bien), ET la possibilité de restaurer les disques des OS virtuels avec plusieurs points de restaurations par palliers de 30 minutes (RPO/RTO). Aie!

Tel le Mac Giver des temps modernes, je dispose des outils suivants pour y parvenir :

  • 1 licence vSphere Essential Plus
  • 2 serveurs physiques, installés en ESXi 5.5 et reliés en SAN
  • 2 baies de disques EMC² VNX5200
  • 2 souscriptions RedHat Datacenter – pour disposer d’autant de VMs RHEL qu’on le souhaite sur nos deux nœuds physiques
  • 2 souscriptions RedHat High Availability (anciennement RedHat Cluster Suite) en mode Datacenter – pour disposer d’autant de clusters RedHat qu’on le souhaite sur nos deux nœuds physiques

Lire la suite « IRL : RedHat virtualisé et haute dispo, RHCS+VMDK partagés vs vSphere Replication »

IRL : RedHat virtualisé et haute dispo, RHCS+VMDK partagés vs vSphere Replication

Partage de VMDK entre plusieurs VMs

Si vous déjà voulu faire un POC de cluster Linux sur des machines virtuelles VMware, vous vous êtes déjà demandé comment vous alliez faire pour partager entre deux serveurs un espace de stockage commun à ces deux machines.

Une façon de faire consiste à rajouter une couche d’abstraction du stockage au dessus de l’OS (via GlusterFS ou DRBD par exemple), mais dans le cas d’un POC pour valider un cluster connecté au SAN, ce n’est pas forcément la première solution qui vient à l’esprit. Personnellement, la plupart des clusters que je construis sont encore dans un schéma plus simple à base de LUNs  iSCSI ou FC partagés sur un SAN en actif/actif ou actif/passif.

Cependant, pour simuler ce fonctionnement sur vos VMs, il va falloir bidouiller un peu.

En effet, pour éviter toute erreur malencontreuse (et même désastreuse), VMware interdit par défaut le démarrage de toute machine virtuelle qui aurait un disque en cours d’utilisation par une autre machine virtuelle. Aïe…

Voici un petit mode opératoire pour s’en sortir 😉

Lire la suite « Partage de VMDK entre plusieurs VMs »

Partage de VMDK entre plusieurs VMs

Vulture 2.0.8 : problème d’ordre dans la directive ProxyPass dans le cas de plusieurs applis pour un même FQDN

Depuis la version 2.0.4 de Vulture, il est possible de présenter plusieurs « applications » (comprennez application web) sur un même FQDN, en les différenciant via leur URL complète. C’est notamment utile dans le cas de l’utilisation de PNP intégré à shinken. Vous présentez la webui sur le WAN via https://shinken/, et les graphiques PNP sur https://shinken/pnp4nagios. Vous avez ainsi tout qui fonctionne comme en local dans un seul et même FQDN. Cette mise en place a fait l’objet d’un précédent article : http://zwindler.fr/wordpress/2012/11/17/maj-publier-sur-le-wan-la-webui-de-shinken-via-vulture-2-0-4/ Cependant, en plus d’apporter des fonctionnalités très appréciables, la mise à jour en 2.0.8 a apporté son lots de petits tracas supplémentaires sur mon installation, notament pour Shinken (voir http://zwindler.fr/wordpress/2014/07/25/vulture-2-0-8-des-nouveautes-et-des-impacts-sur-la-webui-de-shinken/) Je n’avais pas encore remarqué immédiatement, mais il y a eu également une regression de Vulture au niveau de la fonctionnalité dont je parle au début. Je ne pouvais plus accéder à mes graphes PNP4nagios dans Shinken. En fait, après avoir analysé les logs, je me suis rendu compte que toutes les requêtes, et en particulier celles pour PNP, était redirigées vers Shinken, provoquant inévitablement un code retour 404 ([Edit]403 en fait[/Edit]). Lire la suite « Vulture 2.0.8 : problème d’ordre dans la directive ProxyPass dans le cas de plusieurs applis pour un même FQDN »

Vulture 2.0.8 : problème d’ordre dans la directive ProxyPass dans le cas de plusieurs applis pour un même FQDN