ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
HPE ist in letzter Zeit nicht mehr so verfügbar wie „früher“. Seit der grossen „Greenlake“ Direktive nimmt die Qualität und vor allem die Verfügbarkeit der Software und Services spürbar ab – aber zumindest für Infosight (SCM) gibt es einen brauchbaren Workaround.
Es gibt einen direkten Download für den SCM. Am einfachsten geht das direkt an der Konsole:
esxcli software component apply -d https://update.nimblestorage.com/esx8.0/ncmDas Alletra Multipath-IO (MPIO) braucht den „Nimble Connection Manager“ (NCM) für vSphere. Das ist ein kleines VIB auf dem ESXi Host.
⚠️ Die Installation des selbigen erfordert zwei (!) reboots des Host.
Das VIB kann man aber zum Glück auch ohne offline-Zauberei, Download aus dem Infosight-Support-Center und so weiter installieren. Noch nicht alle Teile von HPE wurden vom Greenlake-Virus zerstört 🙂
Den NCM an der Konsole installieren oder aktualisieren:
esxcli software component apply -d https://update.nimblestorage.com/esx8.0/ncmDazu muss der ESXi Hosts selbstverständlich (temporär) ins Internet dürfen. Obwohl die Installation nach dem Abschluss behauptet Reboot Required: false ist dieser notwendig, sonst greifen die MPIO-Policies nicht.
ReFS ab v3.1 unterstützt bekanntlich zwei verschiedene Clustergrößen: 4 KB und 64 KB. Welches nimmt man für ein B&R Repository?
tl;dr: 64KB für ReFS als Veeam-Repository
Unter anderem Microsoft hat 2019 in einem Technet-Artikel einige Empfehlungen zur Clustergröße für ReFS und NTFS veröffentlicht. Die Standard-Clustergröße beider Dateisysteme ist 4K, was bis heute die Vorgabe ist, wenn man ein neues Volume formatiert. Der Artikel enthält aber auch eine detaillierte Erklärung, warum man eine bessere Performance mit 64K großen Zuordnungseinheiten erhält, wenn man große Dateien ließt oder schreibt.
64-KB-Cluster sind grundsätzlich immer dann sinnvoll, wenn man mit großen, sequentiellen E/A-Vorgängen (auf HDDs) arbeitet. Viel weniger Verwaltungsaufwand bei der Adressierung, mehr Payload und damit höherer Durchsatz bei deutlich weniger Last (etwa ein sechzehntel). Sicherungen und Wiederherstellungen erfolgen naturgemäß in aller Regel sequentiell, daher sind Veeam-Blöcke schon immer größer gewesen, nämlich 1Mbyte.
Insbesondere die „brutto“ Read/Write-Leistung unterscheidet sich erheblich, wenn dasselbe Volume auf derselben Hardware mit einer Clustergröße von 64 KB statt mit 4 KB formatiert wird. Eine bis zu vierfachen Steigerung der Netto-Geschwindigkeit von Merge-Vorgängen (Inkremental-Forever, Synthetic-Fulls …) ist üblich. Beide Vorgänge sind dank der Block-Cloning-API (ReFS-only!) immer noch erheblich schneller als „normales“ i/o, aber der Unterschied ist gewaltig. Die reine Backup-Schreibleistung hängt meist von der Quelle ab, daher fällt der gefühlte Unterschied hier ncht so groß aus.
Ein Nachteil ist der zusätzliche Speicherplatzverbrauch. Dier beträgt, aus Erfahrung, etwa 5–10% der Dateigröße (nicht Volumengröße). Der Grund dafür ist, dass von Veeam erstellte Blöcke zunächst eine feste Größe von 1MB haben. In den allermeisten Veeam-Jobs ist aber standardmäßig die Komprimierung aktiv, die „im Durchschnitt“ die Größe nachträglich um etwa etwa 50% reduziert. Je nach Quelldaten fällt das natürlich leicht unterschiedlich aus, was in variabler „Verwendung“ von Cluster-„Rändern“ mündet.
Wir halten den Preis von <10% Speicherplatz für die Geschwindigkeits-Vervielfachung für hinnehmbar und empfehlen daher ebenfalls die 64KB Blockgröße.
Manchmal schlagen Firmware-Updates auf Alletra 5000 Storages (früher Nimble AF und HF) fehl. Die Fehlermeldung dazu lautet im GUI und an der Shell wenig hilfreich:
One of the HPE Nimble Storage services has become unreachable. If this occurred during a failover or planned outage, wait a minute and then refresh the GUI. This may also occur during security certificate update for group or array name changes or management ip and discovery ip changes. Wait a minute and then refresh the GUI. In some cases, you may also need to clear browser cache. If the service does not become reachable in a few minutes, contact HPE Nimble Storage Support.Es sieht so aus, als ob die Boot-Devices auf den aktiven (!) Controllern manchmal eine Zeitüberschreitung veraursachen. Das verursachte dann den Dienstfehler „Storage services has become unreachable“.
Dies kann man in den allermeisten Fällen durch einen Neustart des Controllers beheben – also durch einen einfachen Failover. Normalerweise kann man das im Web-GUI mit dem Button „Make active“ tun, was in diesem Fall aber ebenfalls nicht funktioniert.
Es hilft aber den Failover auf den anderen Controller an der SSH-Shell zu erzwingen:
failover --array <ARRAYNAME> --forceUnd nach wenigen Minuten ist der Failover fertig, der Controller frisch neu gebootet und das Update läuft ohne Probleme durch.
Man hat frisch eine Storage Policy konfiguriert und auf eine VM angewendet. Es wurden allerdings nicht alle Einstellungen sofort übernommen (z.B. die NimbleStorage AppSync Konfiguration).
Nach dem Korrigieren dieser, möchte man die Richtlinie neu anwenden. VMware zeigt einem jedoch den Fehler:
Ungültige Konfiguration der virtuellen Maschine.
Die VM hat vermutlich noch einen Snapshot. Nach dem entfernen klappt das erneute Anwenden der Richtlinien sofort.