Kapitel 12. Storage

Ist ein Pfad nicht zuverlässig und die Verbindung fällt oft aus, so versucht multipathd trotzdem weiterhin, diesen Pfad zu verwenden. Die Zeitüberschreitung bei welcher multipathd erkennt, dass der Pfad nicht mehr zugänglich ist, beträgt 300 Sekunden, wodurch der Eindruck entstehen kann, dass multipathd festhängt.

Um dies zu beheben, wurden zwei neue Konfigurationsoptionen hinzugefügt: delay_watch_checks und delay_wait_checks. Stellen Sie delay_watch_checks darauf ein, für wieviele Zyklen multipathd den Pfad beobachten soll, wenn dieser online kommt. Sollte der Pfad mit dem zugewiesenen Wert fehlschlagen, so verwendet multipathd ihn nicht. multipathd verlässt sich in diesem Fall nur auf die delay_wait_checks-Option für die Information, wieviele aufeinanderfolgende Zyklen durchlaufen werden müssen, ehe der Pfad seine Gültigkeit wiedererlangt. Dies verhindert, dass unzuverlässige Pfade sofort wiederverwendet werden, wenn sie wieder online sind.

Benutzer waren nicht dazu in der Lage, ihre Konfiguration auf /etc/multipath.conf und andere Konfigurationsdateien aufzuteilen. Dies hinderte Benutzer daran, eine einzige Hauptkonfigurationsdatei für alle ihre Rechner anzulegen und die rechnerspezifischen Konfigurationsinformationen in separate Konfigurationsdateien für jeden Rechner auszulagern.

Zu diesem Zweck wurde die neue Option config_dir in der Datei multipath.config hinzugefügt. Benutzer müssen die Option config_dir auf entweder einen leeren String oder einen vollständigen Verzeichnispfad ändern. Wenn die Option nicht leer ist, wird Multipath alle .conf-Dateien in alphabetischer Reihenfolge lesen. Die Konfigurationen werden dann genauso angewendet, als seien diese in /etc/multipath.conf enthalten. Falls diese Änderung nicht vorgenommen wird, lautet config_dir standardmäßig /etc/multipath/conf.d.

Device Mapper (DM) wurde auf Upstream-Version 4.0 aktualisiert, was eine Reihe von Fehlerbehebungen und Verbesserungen gegenüber der vorherigen Version bietet. Diese Verbesserungen umfassen unter anderem eine DM Crypt-Performance sowie eine DM-Core-Aktualisierung für den Support des Multi-Queue Block I/O Warteschlangen-Mechanismus (blk-mq).

Der dmstats-Befehl liefert Benutzerbereich-Support für device-mapper I/O-Statistiken. Dies erlaubt Benutzern das Erstellen, Verwalten und Erstellen von Berichten zu I/O-Zählern, Metriken und Latenzhistogramm-Daten für arbiträre Bereiche von device-mapper-Geräten. Statistikfelder sind jetzt in dmsetup-Berichten verfügbar und der dmstats-Befehl fügt neue, spezialisierte Berichtsmodi hinzu, die zur Verwendung mit statistischen Information entworfen wurden. Informationen zum dmstats-Befehl finden Sie auf der dmstats(8) man-Seite.

SCSI T10 DIX wird in Red Hat Enterprise Linux 7.2 nur für die folgenden HBAs und Speicher-Arrays voll unterstützt, nicht an LUNs, die für das Booten von einer SAN-Umgebung verwendet werden. Außerdem wird T10 DIX in RHEL 7 nur an nativer Hardware unterstützt, nicht beim Ausführen an virtualisierten Gästen.

* 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

Support für DIX verbleibt für HBAs und Storage-Arrays in Technologievorschau.

Beachten Sie, dass T10 DIX Database oder eine andere Software erfordert, die die Generierung und Verifizierung von Prüfsummen auf Disk-Blöcken bereitstellt. Keine derzeit unterstützten Linux-Dateisysteme besitzen diese Fähigkeit.

Das LVM-Cache wird seit Red Hat Enterprise Linux 7.1 voll unterstützt. Dieses Feature gestattet Benutzern das Erstellen logischer Volumes (LVs) mit einem kleinen, schnellen Gerät als Cache für größere, langsamere Geräte zu fungieren. Auf der lvmcache(7) man-Seite finden Sie Informationen zur Erstellung von logischen Cache-Volumes.

Beachten Sie bitte die folgenden Einschränkungen bei der Verwendung von Cache-LVs:

* Das Cache-LV muss ein Gerät der obersten Ebene sein. Es kann nicht als Thin-Pool-LV, als Image eines RAID LV oder als ein anderer Sub-LV-Typ verwendet werden.

* Die Cache LV Sub-LVs (das Ursprungs-LV, Metadata-LV und Daten-LV) können nur vom Typ linear, Stripe oder RAID sein.

* Die Properties des Cache-LV können nach dem Erstellen nicht geändert werden. Um die Cache-Eigenschaften zu ändern, entfernen Sie das Cache wie in lvmcache(7) beschrieben und erstellen Sie es mit den gewünschten Eigenschaften neu.

Es wurde eine neue smq dm-cache Richtlinie geschrieben, die den Speicherverbrauch senkt und in den meisten Anwendungsfällen die Performance verbessert. Dies ist jetzt die standardmäßige Cache-Richtlinie für neue logische Volumes des LVM-Cache. Benutzer, die lieber die alte mq-Cache-Richtlinie verwenden möchten, können dies tun, indem sie das —cachepolicy-Argument beim Erstellen des logischen Cache-Volumes eingeben.

LVM-Volume-Gruppen können jetzt einem Besitzer zugewiesen werden. Der Besitzer der Volume-Gruppe ist die System-ID eines Host. Nur der Host mit der gegebenen System-ID kann die VG verwenden. Dies kann für Volume-Gruppen von Nutzen sein, die auf gemeinsam genutzten Geräten existieren, für mehrere Hosts sichtbar sind, die andernfalls nicht vor der gleichzeitigen Verwendung durch mehrere Hosts geschützt wären. LVM-Volume-Gruppen auf gemeinsam genutzten Geräten mit einer zugewiesenen System-ID gehören einem Host und sind von anderen Hosts geschützt.