Unter Oracle Linux ist man gewöhnt, dass man Änderungen an der Multipath Konfiguration einfach direkt im File /etc/multipath.conf vornimmt. Wenn man das bei OLVM Servern macht, kommt die böse Überraschung spätestens beim nächsten Reboot – die Konfiguration wird überschrieben!
Schauen wir es uns einmal genauer an!
Wie man bei OLVM Multipath korrekt konfiguriert
Also: Die Multipath Konfiguration darf bei OLVM eben nicht in der multipath.conf gemacht werden, da diese vom VDSM verwaltet und im Zweifel beim nächsten Start des VDSM Processes wieder auf den Default geändert wird.
Details dazu sind in folgender Oracle Note zu finden: OLVM: Recommended Settings for Multipath.conf (Doc ID 2812563.1).
Check der aktuellen Konfiguration
Hat man schon etwas an der Konfiguration geändert, bzw. möchte man verifizieren, wie die Konfiguration aktuell aussieht, geht das mittels:
multipath -TVorbereitung für Änderungen an der Multipath Konfiguration
Bevor man Änderungen beim mutlipath macht ist es wichtig, dass auf dem Host keine VMs mehr laufen und sich diese im Maintenance Mode befindet.
Zusätzlich empfehlen wir ein Wartungsfenster im Monitoring (Reboottest des Hosts) zu definieren und sofern es aktiviert ist auf dem Admin Host die Notification für den Zeitraum zu deaktivieren.
systemctl status ovirt-engine-notifierBesonderheiten, die man berücksichtigen muss
Folgende Parameter müssen für OLVM (ovirt) zwingend auf diesen Wert gesetzt werden:
- user_friendly_names no
Device names must be consistent across all hypervisors. For example, /dev/mapper/{WWID}. The default value prevents the assignment of inconsistent device names such as /dev/mapper/mpath{N} on the hypervisors, which can lead to unpredictable system behavior. - find_multipaths no
This setting controls whether the hypervisor tries to access devices through multipath only if more than one path is available. The current value, no, allows the hypervisor to access devices through multipath even if only one path is available.
Folgende Parameter sollten wenn möglich auf diesen Wert gesetzt werden:
- no_path_retry 16
This setting controls the number of polling attempts to retry when no paths are available. With the default 5-second polling interval, checking the paths takes 80 seconds. If no path is up, multipathd tells the kernel to stop queuing and fails all outstanding and future I/O until a path is restored. When a path is restored, the 80-second delay is reset for the next time all paths fail. - polling_interval 5
This setting determines the number of seconds between polling attempts to detect whether a path is open or has failed. Unless the vendor provides a clear reason for increasing the value, keep the VDSM-generated default so the system responds to path failures sooner.
Wenn man einen dieser Werte auf Grund von Herstellervorgaben dennoch ändern möchte, geht das mit Hilfe eines Overwrite Konfigurationsfiles – hier ein Beispiel.
# cat /etc/multipath/conf.d/override.conf
overrides {
no_path_retry 8
}Multipath Anpassung
Um die multipath Konfiguration richtig anzupassen, muss unter
/etc/multipath/conf.dein File mit den entsprechenden Parametern erstellt werden.
Am besten startet man nach den Änderungen den Host durch, damit es mit Sicherheit zu keinen Konflikten mit alten Settings kommen kann.
Beispiel für Pure Storage
[root@olvms1 conf.d]# ll
total 8
-rw-------. 1 root root 799 Oct 28 15:36 pure_dbm.conf
-rw-r--r--. 1 root root 201 Sep 4 12:43 vdsm_blacklist.conf
[root@olvms1 conf.d]# cat pure_dbm.conf
# Remove devices entries when overrides section is available.
devices {
device {
vendor "PURE"
product "FlashArray"
path_selector "queue-length 0"
path_grouping_policy group_by_prio
path_checker tur
fast_io_fail_tmo 10
dev_loss_tmo 60
no_path_retry 16
hardware_handler "1 alua"
prio alua
failback immediate
}
}
overrides {
no_path_retry 16
}Nach einem Reboot oder Restart vom VDSM gibt es jetzt kein böses Erwachen mehr.