Chapitre 12. Stockage

Si un chemin n'est pas fiable, comme lorsqu'une connexion est fréquemment coupée, multipathd tentera continuellement d'utiliser ce chemin. Le délai d'attente avant que multipathd réalise que le chemin n'est plus accessible est réglé sur 300 secondes, ce qui peut donner l'impression que multipathd est tombé en panne.

Pour corriger cela, deux nouvelles options de configuration ont été ajoutées : delay_watch_checks et delay_wait_checks. Paramétrez delay_watch_checks sur le nombre de cycles pendant lesquels multipathd doit observer le chemin après avoir été mis en ligne. Si le chemin échoue avant la valeur assignée, multipathd ne l'utilisera pas. Multipathd se fiera ensuite à l'option delay_wait_checks pour lui faire savoir combien de cycles consécutifs doivent s'écouler avant que le chemin ne redevienne valide. Ceci empêche l'utilisation de chemins non fiables immédiatement après leur remise en ligne.

Les utilisateurs ne pouvaient pas diviser leur configuration entre le fichier /etc/multipath.conf et d'autres fichiers de configuration. Ceci empêchait les utilisateurs de paramétrer un fichier de configuration principal pour leurs ordinateurs et de garder des informations sur la configuration spécifique à l'ordinateur dans des fichiers de configuration séparés pour chaque machine.

Pour répondre à ce problème, une nouvelle option config_dir a été ajoutée au fichier de configuration multipath.config. Les utilisateurs doivent changer l'option config_dir soit sur une chaîne vide ou sur un nom de chemin d'accès de répertoire complet. Lorsque défini sur autre chose qu'une chaîne vide, multipath lira tous les fichiers .conf par ordre alphabétique. Les configurations seront ensuite appliquées exactement comme si elles avaient été ajoutées au fichier /etc/multipath.conf. Si ce changement n'est pas effectué, la valeur pas défaut de config_dir sera /etc/multipath/conf.d.

DM (« Device Mapper ») a été mis à niveau à la version en amont 4.0, qui fournit un certain nombre d'améliorations et de correctifs de bogues comparé à la version précédente, y compris une mise à jour des performances DM crypt et une mise à jour du cœur DM pour prendre en charge le mécanisme « Multi-Queue Block I/O Queueing Mechanism » (blk-mq).

La commande dmstats fournit la prise en charge de l'espace utilisateur pour les statistiques d'E/S device-mapper. Ceci permet à un utilisateur de créer, gérer, et rapporter des compteurs d'E/S, des métriques et des données d'histogrammes de latence pour des régions arbitraires de périphériques device-mapper. Des champs de statistiques sont désormais disponibles dans les rapports dmsetup et la commande dmstats ajoute des modes de rapport spécialisés conçus pour une utilisation avec des informations statistiques. Pour obtenir des informations sur la commande dmstats, veuillez consulter la page man dmstats(8).

SCSI T10 DIX est totalement pris en charge sur Red Hat Enterprise Linux 7.2 uniquement pour les HBA et matrices de stockage suivants, et non sur les LUN utilisés pour démarrer à partir d'un environnement SAN. En outre, T10 DIX est pris en charge sur RHEL 7 uniquement sur le matériel natif, et non lors d'une exécution sur des invités virtualisés.

* EMULEX LPe16000/LPe16002

* QLOGIC QLE2670/QLE2672

* FUJITSU ETERNUS DX100 S3

* FUJITSU ETERNUS DX200 S3

* FUJITSU ETERNUS DX500 S3

* FUJITSU ETERNUS DX600 S3

* FUJITSU ETERNUS DX8100 S3

* FUJITSU ETERNUS DX8700 S3

* FUJITSU ETERNUS DX8900 S3

* FUJITSU ETERNUS DX200F

* FUJITSU ETERNUS DX60 S3

La prise en charge de DIX continue de faire partie des aperçus technologique pour les autres HBA et matrices de stockage.

Remarquez que T10 DIX requiert une base de données ou un autre logiciel permettant de générer et vérifier des checksums sur blocs de disque. Aucun système de fichiers Linux actuellement pris en charge n'offre cette capacité.

Le cache LVM est totalement pris en charge depuis Red Hat Enterprise Linux 7.1. Cette fonctionnalité permet aux utilisateurs de créer des volumes logique (VL) avec un périphérique rapide et de petite taille utilisé en tant que cache pour des périphériques plus lents et de plus grande taille. Veuillez consulter la page de manuel lvmcache(7) pour obtenir des informations sur la création de volumes logiques cache.

Veuillez remarquer les restrictions suivantes lors de l'utilisation de VL de caches :

* Le VL du cache doit être un périphérique du niveau le plus haut niveau. Il ne peut pas être utilisé en tant que VL de pool fin, image de VL RAID, ou comme tout autre type de sous-volume logique.

* Les sous-volumes logiques du VL du cache (le VL d'origine, le VL des métadonnées, et le VL des données) peut être de type linéaire, par bandes, ou RAID.

* Les propriétés du VL du cache ne peuvent pas être modifiées après leur création. Pour modifier les propriétés du cache, supprimez le cache comme décrit dans lvmcache(7) puis recréez-le avec les propriétés souhaitées.

Une nouvelle politique dm-cache smq a été écrite , elle réduit la consommation de mémoire et améliore les performances dans la plupart des cas d'utilisation. Celle-ci est désormais la politique par défaut du cache pour les nouveaux volumes logiques de cache LVM. Les utilisateurs préférant utiliser la politique héritée mq peuvent le faire en fournissant l'argument —cachepolicy lors de la création du volume logique du cache.

Les groupes de volumes LVM peuvent désormais se voir assigner un propriétaire. Le propriétaire du groupe de volumes est l'ID système d'un hôte. Seul l'hôte avec l'ID système donné peut utiliser le groupe de volumes. Ceci est bénéfique aux groupes de volumes existants sur des périphériques partagés, visibles à de multiples hôtes, qui autrement ne seraient pas protégés d'une utilisation en conjonction à partir de multiples hôtes. Les groupes de volumes LVM sur périphériques partagés avec un ID système assigné sont détenus par un hôte et protégés des autres hôtes.