lindev.fr

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - partition

Fil des billets - Fil des commentaires

18 mai 2015

Amazon Ec2 IO et Raid

J'ai eu quelques soucis récemment avec une instance Amazon qui héberge une base de données Mysql très sollicitée par période.
En effet les données de la base étaient sur la même partition que le système ( déjà c'est mauvais ), celle-ci étant fortement sollicitée en IO, la charge système se met à grimper, les temps d'attente d’accès au disque étant de plus en plus grand, jusqu'au crash complet .

La solution simple et rapide est de déplacer les données vers une partition dédiée, avec des performances en IO plus importantes (tant qu'à faire). C'est dans ce contexte que je vais présenter, dans ce billet, la mise en place d'une partition en Raid0 pour augmenter significativement les IO/s et surtout éviter de surcharger le système.

Ce que l'on va voir

  • Création de système de fichiers XFS
  • Création d'un Raid logiciel
  • Monitoring avec atop
  • Ajout d'un disque au Raid
  • Extension d'une partition XFS

Etat des lieux

Je vais utiliser une instance micro ( gratuite ) sous Debian Jessie en HVM ( virtualisation totale ). je vais y attacher 4 disques.

Capture_d_e_cran_2015-05-17_a__10.28.54.png

  • /dev/xvda pour le système
  • /dev/sdb pour tester les perfs. sur un seul disque
  • /dev/sdc premier disque du Raid
  • /dev/sdb deuxième disque du Raid

Installation des outils

Le système étant vierge nous allons installer les paquets nécessaires pour les manipulations ci-dessous.

sudo apt-get install xfsprogs atop mdadm

Premier test : Disque seul

Pour pouvoir comparer, nous allons commencer avec un test sur un disque "seul" possédant une partition XFS

Voici comment sont perçus les disques à ce moment

Capture_d_e_cran_2015-05-17_a__10.35.40.png

Commençons par créer la partition :

sudo cfdisk /dev/xvdb

Une fois la partition créée, voici comment sont perçus les disques

Capture_d_e_cran_2015-05-17_a__10.37.39.png

Nous allons maintenant créer le système de fichiers sur cette nouvelle partition

mkfs.xfs /dev/xvdb1

Enfin il ne nous reste plus qu'à monter cette partition sur un répertoire que nous allons également créer maintenant

mkdir /home/admin/diskLocal
mount -t xfs /dev/xvdb1 /home/admin/diskLocal/

Dirigeons nous dans ce répertoire et effectuons le premier test basique, grâce à l'outil dd

cd /home/admin/diskLocal
dd if=/dev/zero of=bench.dat bs=1M count=1024 oflag=direct

Pendant le test on voit bien grâce à la commande atop, l'utilisation du disque qui est à son maximum

Capture_d_e_cran_2015-05-17_a__10.45.21.png

Et voici le résultat

Capture_d_e_cran_2015-05-17_a__10.45.39.png

Deuxième test : 2 Disques en Raid0

Commençons par construire notre raid0 "software" ( via la commande mdadm )

mdadm --create --verbose /dev/md0 --level=stripe --raid-devices=2 /dev/xvdc /dev/xvdd

Ce qui nous donne :

Capture_d_e_cran_2015-05-17_a__10.48.43.png

Un petit check :

mdadm -D /dev/md0

Maintenant, créons notre système de fichiers sur md0

mkfs.xfs /dev/md0

Enfin il ne nous reste plus qu'à monter cette partition sur un répertoire que nous allons créer: diskRaid

mkdir /home/admin/diskRaid
mount -t xfs /dev/md0 /home/admin/diskRaid/

Dirigeons nous dans ce répertoire et effectuons le second test sur ce disque Raid0

cd /home/admin/diskRaid
dd if=/dev/zero of=bench.dat bs=1M count=1024 oflag=direct

Regardons ce qui se passe pendant le test

Capture_d_e_cran_2015-05-17_a__10.52.27.png

Les deux disques sont en pleine charge, et quelques secondes plus tard ...

Capture_d_e_cran_2015-05-17_a__10.52.37.png

On passe donc de 30 secondes à 18 sec. pour effectuer ce test et un débit d’écriture de 35.5MB/s à 51MB/s

Conclusion

Il est plus intéressant de mettre en place 2 disques en Raid0 qu'avoir un gros disque pour améliorer les IO/s.

Ajoutons un disque au Raid0

Si nous ajoutons un disque à notre Raid0, nous passerons ainsi à 3 disques

Voici le disque à ajouter

  • /dev/xvde

Capture_d_e_cran_2015-05-17_a__14.21.34.png

Ajoutons le à notre raid md0

sudo mdadm --grow /dev/md0 --raid-devices=3 --level=0 --add /dev/xvde
sudo xfs_growfs /dev/md0

Regardons si tout est ok

lsblk

Capture_d_e_cran_2015-05-17_a__14.59.08.png

Vérifions que la partition fasse bien 15G

df -h

Capture_d_e_cran_2015-05-17_a__15.00.30.png

Bien ça me semble parfait, lançons le troisième test

cd /home/admin/diskRaid
dd if=/dev/zero of=bench.dat bs=1M count=1024 oflag=direct

Capture_d_e_cran_2015-05-17_a__15.02.34.png

Résultat :

Capture_d_e_cran_2015-05-17_a__15.03.51.png

Les performances restent les mêmes, certainement limitées par la virtualisation ou simplement physiquement, cependant la charge étant répartie sur 4 disques, l'occupation ne dépasse pas les 65%, ce qui permet d'avoir d'autres processus en parallèles.

L'ajout de disques reste donc très intéressante pour pouvoir encaisser une forte charge d'IO/s .

Bon tests ,

Ch.

Restez informé

inscrivez vous à la newsletter pour recevoir les nouveaux billets par mail. ( formulaire en haut à droite )

27 mai 2011

LVM exemple de mise en pratique

recuperation-donnees-fichiers-9.jpg Cela fait longtemps que je tourne autour de ce gestionnaire de volumes jamais avoir eu l'occasion d'y mettre les mains . Aujourd'hui c'est chose faite !

LVM / LVM2 utilisation

Il y a quelques jours j'ai eu pour mission la mise en production d'un serveur web linux, hébergé sur une plateforme de virtualisation microsoft Hyper-V. Le contrainte principale était bien entendu la disponibilité de ce serveur , mais aussi la possibilité de restaurer le serveur sans connaissance particulière et surtout en un temps record ..

Première possibilité ,

La mise en place d'un cluster ( soit , deux machines virtuelles en front ou une maitre et l'autre esclave ). La machine hôte ( Hyper-V ) étant déjà bien chargé , la mise en place d'une seconde VM n'était pas envisageable.

Seconde possibilité ,

La machine hôte étant associée à une baie SAN, nous avons donc migré les données variables ( sources et BDD ) sur cette dernière , ce qui rend la restauration de la machine virtuelle aussi simple qu'un "copier coller", à partir du moment ou la vm est sauvegardé.

Pourquoi LVM

J'y viens, mettre les données dynamiques sur la baie SAN est bien beau , mais figer une taille de disque ( aussi virtuel soit-il ) est assez délicat. A moins d'être devint, il est très difficile d'estimer une taille suffisamment grande pour supporter les éventuelles évolutions, et il serait vraiment dommage de gâcher de de l'espace disque en surestimant le besoin .( l'espace disque SAS est à utiliser avec parcimonie, le moindre Go de cette qualité est précieux ).

J'ai donc créé un disque virtuel d'une taille fixe de 5Go ( il est aussi possible de créer un disque à taille variable , mais les performances chutent de 30% selon la doc ... ). 5Go est bien assez pour commencer et être tranquille un bon moment ( plus ou moins long selon l'activité ).

Ce disque virtuel nommé sdb ( que nos pouvons comparer à un disque dur physique ), sera dans un premier temps formaté, et nous allons créer une partition primaire sdb1 .

Création de la partition primaire

cfdisk /dev/sdb

Maintenant, étant donné que je souhaite utiliser ce disque avec LVM, il est nécessaire de déclarer la partition fraichement créée

Déclaration de la partition sdb1 à LVM

pvcreate /dev/sdb1

Maintenant étape importante, créer le groupe de volume(s) GV. Ce groupe de volume peut être représenté comme une unité regroupant un ensemble de volumes , ou plus simplement expliqué , une grosse partition composée de une ou plusieurs partitions de niveau inférieur appartenant ou non au même disque dur . Ce ne sera plus à vous de gérer la répartition de vos données sur entre les différentes partitions , le GV s'en chargera pour vous.

Création du GV ( Groupe de volumes )

vgcreate MONGROUP /dev/sdb1

Nous voilà maintenant avec un superbe groupe de volumes nommé MONGROUP sur lequel nous allons créer nos volumes logiques LV ( pour les utiliser comme des partitions standard )

Création d'une partition LV ( Volume Logique )

lvcreate -n mapartition -L 4,95g MONGROUP

warning.png Attention à mettre une taille valide, elle ne doit en aucun cas être supérieur à l'espace disponible ( risque de pertes ).

La partition maintenant créée, dernière étape avant de l'exploiter, le formatage .

Formatage de la partition mapartition

mkfs -t ext4 /dev/MONGROUP/mapartition

Et voilà notre volume prêt à l'emploi .

Ne reste plus qu'à le monter .. et l'exploiter ..

mount -t ext4 /dev/MONGROUP/mapartition /mnt

Je vous vois déjà venir en me disant .. que jusqu'à maintenant .. il n'y a pas d'avantage à utiliser LVM ... C'est vrai , créer simplement une partition et la formater directement serait tout aussi performant et bien plus rapide à mettre en place ..

Ok, alors le temps passe et tout d'un coup vous recevez mail de votre client indiquant avoir reçu plusieurs alerte concernant l'espace disponible sur le disque .. aïe !

Pas de panique puisque vous avez pris la peine de créer une partition géré par LVM, dans notre cas il suffira d'augmenter la taille de notre disque virtuel ( ou d'en créer un second ) et de l'ajouter à notre groupe de volumes MONGROUP

Augmenter la capacité du volume

Voyons comment faire cette manip en 5 minutes.

Dans un premier temps il faut démonter le volume avec la commande umount

Démonter le volume à modifier

umount /mnt

Puis il nous faut créer une nouvelle partition ( à partir du nouveau disque ou de l'espace disponible sur le disque virtuel sdb 5G de plus )

cfdisk /dev/sdb

info.png La nouvelle partition sera déclarée comme étant sdb2 ( à adapter dans votre cas )

Une fois la partition créée, nous allons la déclarer à LVM

pvcreate /dev/sdb2

Nous allons ensuite étendre notre groupe de volumes ( MONGROUP ) afin qu'il prenne en compte ma nouvelle partition , et de ce fait , offrir autant d'espace en plus.

Extension du groupe de volumes

vgextend MONGROUP /dev/sdb2

Voilà qui est fait. Nous allons vérifier la partition existante avant de la redimensionner

Vérification de la partition existante

e2fsck -f /dev/MONGROUP/mapartition

Une fois terminé, l'étape la plus importante , le redimensionnement de la partition . Pour commencer nous allons redimensionner notre volume logique ( LV ) mapartition

Redimensionnement de mapartition ( LV )

lvresize -L9,95g /dev/MONGROUP/mapartition

warning.png Attention à mettre une taille valide, elle ne doit en aucun cas être supérieur à l'espace disponible ( risque de pertes ).

Enfin, le volume logique redimensionné, reste à redimensionner notre système de fichiers ext4

Redimensionnement du système de fichiers ext4

resize2fs /dev/MONGROUP/mapartition

Et voilà mon espace disque vient d'augmenter de 5Go . Cette opération peut être répété autant de fois que nécessaire .

lvm2.png

Ch.