RHEL 6 on Zwindler's Reflection

Réinitialisation à eth0 l’indice de la carte Ethernet après clone CentOS / RHEL 6

Sat, 20 Feb 2016 19:00:58 +0000

Après clone, la carte Ethernet s’appelle eth1 (ou plus) et pas eth0

Si vous avez essayé de faire de clones de machines virtuelles ou des déploiement de templates sous CentOS/RHEL 6, vous avez probablement remarqué qu’après déploiement, la carte réseau nouvellement créée ne s’appelle pas eth0 mais eth1.

Et le problème s’amplifie au fil des déploiements, car si vous clonez ou faites un modèle avec une machine dont la carte est devenue eth1, les suivantes auront pour indice eth2 et ainsi de suite.

Essayer de renommer à la main l’interface dans Network Manager fonctionne mal. Tenter de feinter le système avec l’UUID ou l’HWADDR de la « vraie » carte réseau via les scripts dans /etc/system/network-scripts ne donnera pas plus de résultats.

En réalité, le système garde en mémoire des traces de l’interfaces eth0 d’avant clonage. Ce comportement n’existait pas dans RedHat 5 et est corrigé dans RedHat 7.

Solution manuelle

On peut quand même renommer l’interface via l’interface graphique mais il est nécessaire de réaliser quelques opérations complémentaires pour que cela fonctionne.

Dans le gestionnaire réseau, supprimer l’interface System eth0 (qui n’existe plus) et renommer l’autre interface Auto eth1 en eth0 (juste eth0).

Enfin, exécuter les commandes suivantes

cd /etc/udev/rules.d
rm 70-persistent-net.rules
sed -i '/HWADDR*/d' /etc/sysconfig/network-scripts/ifcfg-eth0
sed -i '/UUID*/d' /etc/sysconfig/network-scripts/ifcfg-eth0

Si vous souhaitez juste résoudre le problème et pas refaire un template, vous pouvez rebooter la machine qui retrouvera un eth0 fonctionnel.

Pour éviter que le problème ne se reproduise, je conseille de toujours exécuter ces commandes puis d’éteindre la machine virtuelle avant transformation en template. Le problème n’apparaitra pas au déploiement des VMs provenant de ce template.

Autre solution sur le même principe

Dans la VM qui va devenir un template, commenter les lignes dans /etc/udev/rules.d/70-persistent-net.rules et ajouter l’attribut immutable au fichier. Après extinction (ou reboot), le problème sera résolu.

chattr +i /etc/udev/rules.d/70-persistent-net.rules

3ème solution basée sur un script

La solution que je préfère car c’est celle qui est selon moi la plus « stable » dans le sens où on ne peut pas se tromper lors de l’exécution des opérations.

# Annoying bug in vmware guest centos6
# eth0 doesn't exist
ifconfig eth0 2>/dev/null >/dev/null
if [ $? -ne 0 ] ; then
# Rename eth1 with eth0
echo "UDEV Config..."
rm /etc/udev/rules.d/70-persistent-net.rules
# Change ifcfg-eth0 with hostname address (in /etc/hosts)
echo "Changing eth0 address..."
mac=`ifconfig eth1 | grep eth1 | awk '{ print $5}'`
hostname=`hostname`
ip=`grep $hostname /etc/hosts|cut -s -f 1`
rm -f /etc/sysconfig/network-scripts/ifcfg-eth1
cfg=`grep -v IPADDR /etc/sysconfig/network-scripts/ifcfg-eth0 |grep -v HWADDR`
echo "$cfg" > /etc/sysconfig/network-scripts/ifcfg-eth0
echo "HWADDR=\"$mac\"" >> /etc/sysconfig/network-scripts/ifcfg-eth0
echo "IPADDR=\"$ip\"" >> /etc/sysconfig/network-scripts/ifcfg-eth0
# Apply changes
echo "Applying changes..."
service network stop
service NetworkManager stop
ifconfig eth1 down
udevadm trigger
udevadm control --reload-rules
service network start
service NetworkManager start

Procédure tirée du Cyberciti.biz

Tuning de l’IO Scheduler sous RHEL 4, 5, 6 ou 7 : CFQ, NOOP, Deadline

Sat, 23 Jan 2016 11:30:02 +0000

Options d’IO Scheduler introduites depuis RHEL 4

Par hasard, en cherchant des informations sur des paramètres OS qu’on ne change pour ainsi dire jamais car ceux par défauts font très bien le job dans 99+% des cas, je suis tombé sur un article qui explique les différents modes offerts par RHEL sur le tuning de l’IO Scheduler et les différents impacts que cela peut avoir, notamment dans le cas de machines virtuelles.

J’insiste sur le fait que je ne pense pas que ce soit un sujet qui mérite un changement urgent et radical de votre infrastructure car comme le dit la devise :

If it ain’t broke, don’t fix it.

Pour autant, j’ai trouvé les différents articles que j’ai lus sur le sujet extrêmement intéressants et j’ai voulu partager cette réflexion en Français.

Le problème

D’abord, de quoi on parle ?

Comme je le disais en introduction, en cherchant des informations sur des paramètres kernel exotiques (tcp_rmem/tcp_wmem, tcp_window_scaling) dans le cadre d’un tuning fin pour une instance Oracle, je suis tombé sur cet article dans le RedHat Magazine de juin 2008.

Il est question, à l’époque, d’une fonctionnalité amenée par le kernel linux 2.6, alors nouveau dans RHEL 4 : la possibilité de modifier l’algorithme de traitement des files d’entrée/sortie disques.

On y apprend que dans certains workloads I/O bien spécifiques, l’algorithme de scheduling n’est pas forcément optimal et que pour donner plus de liberté à l’administrateur, des profils distincts ont été ajoutés :

Completely Fair Queuing—elevator=cfq (default)
Deadline—elevator=deadline
NOOP—elevator=noop
Anticipatory—elevator=as

L’article explique dans les grandes lignes ce que font ces différents algorithmes, ainsi que les avantages et les inconvénients de chaque, notamment en terme de performance grâce à un bench.

CFQ

Complete Fair Queuing : comportement par défaut jusqu’à RHEL 6.

Le CPU gère les E/S par processus et les réparties équitablement. Ce mode a longtemps été considéré comme le meilleur compromis entre performances et latence des E/S.

Deadline

Impose une limite maximale en temps de latence pour chaque E/S. Les E/S sont réordonnées parmi 5 files de traitement et celles dont la deadline va bientôt expirer sont traitées en priorité, même s’il faut l’intercaler au milieu d’un grosse écriture séquentielle. On obtient ainsi un ressenti de quasi temps réel pour toutes les E/S.

Ce mode est à privilégier dans le cas de bases de données où les écritures sont intensives. Deadline est aussi moins complexe que CFQ et donc moins consommateur en cycles CPU que CFQ (+ latence).

NOOP

Simplifie le traitement des E/S par le CPU en n’utilisant qu’une simple file de type « first in first out ». On améliore la charge CPU induite par les E/S tout en perdant le gain qu’apporte l’agencement intelligent de ces E/S (et on impacte donc les performances).

A priori, ce mode est également intéressant dans le cadre d’utilisation de SSD, car les secteurs à lire/modifier peuvent être accédés quasi instantanément, contrairement aux disques durs classiques qui subissent eux des latences à cause de la rotation des plateaux (le temps que le bras arrive sur le secteur). Cette absence de latence supprime la nécessité d’optimiser l’ordonnancement des E/S vers le disque, permet d’économiser quelques cycles CPU et donc des latences inutiles.

Bonus : AS - Anticipatory

Impose un petit délai d’attente pour toutes les E/S avec pour objectif de les agréger et/ou de réordonner les E/S en fonction de la « localité » des E/S sur les disques (en tenant compte de la rotation). A priori plus efficace sur les systèmes où les disques sont lents mais peut réduire le nombre E/S par secondes.

Afficher/modifier le scheduler actuel

Le site officiel de RedHat donne les commandes pour modifier ce scheduler dans un chapitre d’une documentation dédiée au tuning des serveurs RHEL 4 et plus qui font fonctionner des instances Oracle 9 et 10. Ce qui est dommage dans cette page c’est qu’on n’en sait pas plus sur ces différents modes… mais cette page traite du sujet (et ici pour RHEL 7 - Performance tuning Guide). Bref j’ai trouvé l’information à plusieurs endroits.

Ce qu’il faut savoir, c’est qu’on peut afficher par disque le scheduler actuel de la façon suivante (selon l’OS).

RedHat 4

Sur RedHat 4, on ne peut pas changer ce mode dynamiquement (disponible uniquement à partir de RHEL 5). La consultation/modification se fait au niveau du fichier /etc/grub.conf.

Exemple « par défaut » (CFQ implicitement)

title Red Hat Enterprise Linux AS (2.6.9-67.ELsmp)
root (hd0,0)
kernel /vmlinuz-2.6.9-67.ELsmp ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.9-67.ELsmp.img

Exemple avec le scheduler « Deadline » (explicitement)

title Red Hat Enterprise Linux Server (2.6.18-8.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-8.el5 ro root=/dev/sda2 elevator=deadline
initrd /initrd-2.6.18-8.el5.img

RedHat 5 et 6

cat /sys/block/sda/queue/scheduler #pour afficher sur /dev/sda
noop anticipatory deadline [cfq]
echo sched_name > /sys/block/sdx/queue/scheduler #pour modifier, remplacer sched_name par le nom du scheduler

RedHat 7 (machine virtuelle)

Petite surprise lorsque j’ai lancé la commande, sur mes VMs RHEL 7, le scheduler est « deadline » par défaut et non plus CFQ.

cat /sys/block/sda/queue/scheduler #pour afficher sur /dev/sda
noop [deadline] cfq
echo sched_name > /sys/block/sdx/queue/scheduler #pour modifier, remplacer sched_name par le nom du scheduler```

En fait, depuis RHEL 7, le scheduler par défaut est toujours CFQ mais seulement lorsque l’OS détecte un disque SATA. Pour tous les autres types de disques, c’est deadline.

Les systèmes de stockage ont beaucoup évolués depuis RHEL 4 et il y a fort à parier que deadline fournit de meilleures performances des infrastructures récentes à base de SAS/RAID/Cache/SSD. CFQ ne se justifie donc plus que dans les cas où les disques sont des disques SATA simples.

Et pour les VMs ?

En creusant un peu le sujet, je suis assez vite tombé sur cet article de lonesysadmin qui traite un point intéressant : l’application de ce tuning au contexte des machines virtuelles. Cet article fais partie d’une séries d’articles dédiés au tuning pour les machines virtuelles linux qui sont plutôt bien faits.

Le but de l’article de lonesysadmin est de rappeler le fonctionnement des IO Scheduler puis de soulever le problème que pose le comportement par défaut dans le cadre d’un système virtualisé.

In the physical world, with operating systems on bare metal, we would choose an algorithm that is best suited to our workload. In the virtual world there is a hypervisor between the OS and the disks, and the hypervisor has its own disk queues. So what happens is:

The VM has disk I/O occur.

The guest OS uses some CPU time to sort that I/O into an order it thinks is ideal, based on the disk algorithm that’s active.

The guest OS makes the requests to the underlying virtual hardware in that new order.

The hypervisor takes those requests and re-sorts them based on its own algorithms.

The hypervisor makes the requests to the actual hardware based on its own order.

Since the hypervisor is going to do its own sorting, into its own disk queues, there’s very little point in a guest OS attempting the same work. At the very least, the guest OS is introducing some latency and wasting some CPU cycles. At the worst it’s making things more difficult for the hypervisor and the back-end storage (see “I/O blender (lien mort)“). If we switch to the NOOP scheduler the guest OS will do as little as possible to the I/O before it passes it along, which sounds perfect for a virtual environment.

En Français :

la VM génère une E/S disque
l’OS de la VM consomme quelques cycles CPU pour décider dans quel ordre réaliser les E/S pour que l’écriture sur disque soit la plus efficace possible
l’OS de la VM traite les E/S dans l’ordre qui lui parait le plus efficace
l’hyperviseur récupère les E/S de toutes les VMs et les réorganisent lui même en fonction de ses propres algorithmes
l’hyperviseur traite les E/S

Dans ce schéma de figure, lonesysadmin pose le problème suivant : à quoi bon perdre des cycles CPU pour réorganiser des E/S qui seront de toute façon réorganisées par l’hyperviseur juste après pour écriture sur disques ? Son point de vue consiste à dire qu’au mieux des cycles CPU seront gaspillés pour rien et qu’au pire, la réorganisation de chaque VM de ses propres E/S sera contreproductive et dégradera les performances du stockage.

La solution qu’il propose consiste donc à dire qu’il vaut donc mieux supprimer ce travail inutile et positionner les machines virtuelles avec le scheduler IO NOOP (simple FIFO). Au delà de l’aspect intuitif du raisonnement, lonesysadmin ne donne pas de tests de performance ou de source pour étayer ses arguments.

Cependant, parmi les commentaires dans l’article et les différentes informations que je trouve sur Internet, l’information se confirme (même si on conseille généralement deadline), notamment grâce au KB 2011861 de VMware (lien mort, comme tout chez VMware) qui conseille clairement noop ou deadline.

Bonus

Recommandation de RedHat pour les bases de données : changez pour deadline !
Dans ses Best Practices pour machines virtuelles Linux sur KVM (lien mort), IBM conseille : deadline encore !
Un article du Linux Journal sur les I/O Schedulers qui montre avec des exemples un peu théoriques des différences énormes entre elevators.
Un article sur NUODB qui conseille NOOP (blog tué par dassault, suite à un rachat probablement) dans le cas de l’utilisation de SSDs. Retrouvé sur dzone dzone.com/articles/tuning-linux-io-scheduler-ssds
L’article wikipedia de NOOP

RHEL & CentOS 5 & 6 : « mount: type inconnu de système de fichiers ‘ntfs' »

Wed, 06 May 2015 17:57:28 +0000

[Edit]La procédure étant similaire pour CentOS 5, les spécificités ont été ajoutés en fin d’article[/Edit]

RHEL 6 / CentOS 6

Si vous avez déjà tenté de brancher un disque dur externe à un serveur fraîchement installé en RedHat 6 (ou CentOS 6), vous vous êtes peut être rendu compte que même en installation de type « Desktop » (je ne parle même pas de la « Minimal »), vous ne pouviez pas monter les partitions NTFS.

[root@monserveur appli]# mount /dev/sdb1 /mnt
mount: type inconnu de système de fichiers 'ntfs'

Si votre serveur a accès au net, il vous suffit d’ajouter le repository « EPEL release » (configurable rapidement via le RPM associé (lien mort, pas trouvé sur Internet Archive)

Mais dans le cas d’un réseau d’entreprise où vous en êtes coupés, pas de paniques. Voici les deux packages à récupérer et installer pour pouvoir monter votre partition NFTS.

ntfs-3g (lien mort)
ntfsprogs (lien mort)

Dans le cas où vous n’avez qu’un disque dur sur le serveur /dev/sda, le disque dur externe est souvent le suivant, et il n’y a en général qu’une seule partition, donc /dev/sdb1

yum install ntfs-3g-2014.2.15-8.el6.x86_64.rpm ntfsprogs-2014.2.15-8.el6.x86_64.rpm
mount /dev/sdb1 /mnt

RHEL 5 / CentOS 5

Récupérer le package fuse-ntfs-3g-1.1004-1.el5.rf.x86_64.rpm sur repoforge (lien mort).

Installer le package et utiliser la commande suivante pour monter le disque dur

yum install fuse-ntfs-3g-1.1004-1.el5.rf.x86_64.rpm #récupérer éventuellement fuse et fuse-libs qui sont disponible dans les dépôts classiques
mount.ntfs-3g /dev/sdb1 /mnt

Versions anciennes (<5.2)

Pour les versions RHEL/CentOS inférieures à 5.2, il faut également ajouter les packages dkms et dkms-fuse sinon le module kernel fuse ne s’activera pas (voir fin de NTFS Tips and Tricks (lien mort, j’utilise Internet archive))

yum install fuse-ntfs-3g-1.1004-1.el5.rf.x86_64.rpm fuse fuse-libs dkms dkms-fuse
modprobe fuse

Erreur de signature

Ajoutez --nogpgcheck si vous n’avez pas envie d’ajouter la signature de repoforge dans la liste de vos signatures autorisées

Limitation de la version 5

Pour information, il est possible que le disque ne soit pas montable du tout s’il dépasse les 2 To. En fait, le kernel de la RHEL/CentOS 5 est trop ancien pour gérer correctement les disques de grande taille. C’était mon cas, avec l’erreur suivante

mount.ntfs-3g /dev/sdc1 /mnt
Failed to read last sector (732564991): Argument invalide
Perhaps the volume is a RAID/LDM but it wasn't setup yet, or the
wrong device was used, or the partition table is incorrect.
Failed to mount '/dev/sdc1': Argument invalide
The device '/dev/sdc1' doesn't have a valid NTFS.
Maybe you selected the wrong device? Or the whole disk instead of a
partition (e.g. /dev/hda, not /dev/hda1)? Or the other way around?

Un autre post qui traite du sujet sur www.linuxquestions.org/questions/linux-general-1/mounting-usb-hard-drive-with-4kb-sectors-in-centos-5-8-a-4175477057/