NetApp Metrocluster Switchover FDISC Error mit Cisco MDS Switches

Ich hatte letztens ein kleines Problem… Wir haben in einem Setup einen NetApp MetroCluster mit Cisco MDS SAN Frontend aufgebaut. Eigentlich keine Hexerei, aber der Fehler liegt im Detail.

Im Falle eines Switchovers oder Switchbacks, verloren alle Hosts ihre Pfade und natürlich auch die LUNs, welche auf dem übernommenen Controller terminierten.

Der Fehler war schnell gefunden, die LIFs blieben einfach down.

Wir fanden dann diesen wunderbaren Artikel in der Knowledgebase: https://kb.netapp.com/support/s/article/ka11A0000001UmE/fcp-fcoe-lif-reports-operationally-down

Folgen wir also dem Guide:

network interface show -data-protocol fcp -fields status-admin,status-oper,status-extended



vserver lif status-oper status-extended status-admin
------------------ ---------------------- ----------- --------------- ------------
svm-*******01-mc *******_lif_1 down - up
svm-*******01-mc *******_lif_2 down - up
svm-*******01 *******_lif_1 down FDISC error - ID could not be acquired for this virtual port.
 up
svm-*******01 *******_lif_2 down FDISC error - ID could not be acquired for this virtual port.
 up
4 entries were displayed.

Interessant! Wir probierten herum und fanden schnell einen Workaround: einfach das Interface down und up setzen. Das Funktioniert … Lösung ist das aber keine.

Am MDS wurde auf Version 8.1.1 aktualisiert haben und es dabei offensichtlich ein paar neue Default gibt. Zumindest wird man beim Downgrade darauf hingewiesen:

Checking incompatible configuration(s)
The following configurations on active are incompatible with the system image
1) Service : flogi , Capability : CAP_FEATURE_FLOGI_SCALE_ENABLE
Description : flogi scale enabled on this switch
Capability requirement : STRICT
Enable/Disable command : no flogi scale enable

2) Service : flogi , Capability : CAP_FEATURE_FLOGI_QUIESCE_TIMEOUT
Description : flogi queisce timeout enabled on this switch
Capability requirement : STRICT
Enable/Disable command : flogi quiesce timeout 0



Checking dynamic incompatibilities:
-----------------------------------
No incompatible configurations

Irgendwie springt in diesem Fall diese Option ziemlich ins Auge: CAP_FEATURE_FLOGI_QUIESCE_TIMEOUT

Der Default Wert liegt in diesem Release bei:

show flogi internal info |inc quiesce
 Stats: fs_flogi_quiesce_timerval: 2000

Also schnell einen Versuch starten und mit dem folgenden Befehl auf einer der beiden Fabrics das Timeout wieder auf 0 setzen:

flogi quiesce timeout 0

Anschließend noch einmal einen Switchover/Switchback testen und viola … es funktioniert. 🙂

 

Ich hoffe das hilft jemanden weiter. Wir haben bisher keine Information dazu finden können.

 

 

Liebe Grüße

Falk

 

Howto: Multiprotokoll NAS Server mit einer EMC² Unity

Hallo zusammen,

ich stecke im Moment in einem kleinen Projekt mit einer Unity.

Der Kunde möchte einen NAS Server einrichten worauf er gleichzeitig mit SMB und NFS zugreifen kann.

Die Anforderung ist eigentlich nicht so kompliziert:

  • Mehrere Windows User müssen auf den Share R/W Zugriff haben.
  • Ein Linux Service-User muss ebenfalls Zugriff via NFS erhalten.

Howto: Multiprotokoll NAS Server mit einer EMC² Unity weiterlesen

EMC² Unity – Thick Provisioning

Letzte Woche wurde ich von einem Kunden gefragt, wie man mit der Unity eigentlich eine „Thick“-LUN anlegt. Das GUI lässt schließlich nur „Thin“-Provisioning zu.

Die Antwort findet man nicht im GUI. Ein möglicher Weg führt aber über das Tool uemcli.exe. Und so wird es gemacht.

EMC² Unity – Thick Provisioning weiterlesen

Docker Volume Mappings

Als Vorbereitung auf einen Beitrag zum Thema Persistent Storage mit dem entsprechenden Netapp-Plugin möchte ich noch kurz darauf eingehen, wie man mit Bordmitteln ein persistentes Storage für einen Container bereitstellen kann.

Braucht man ein persistentes Storage oder nur ein Shared Storage für eine Applikation, welche in einem Docker Container läuft, kommt man fast nicht an Volume Mappings vorbei.

Mit Vollume Mappings kann man auf einem einfache Wege lokale Filesystem-Ressourcen in einem Container verfügbar machen.

Das Volume Mapping ist ähnlich anzuwenden wie das Device Mapping aus meinem letzten Artikel. Man muss lediglich beim startendes Containers die folgende Option mitgeben.

-v /lokales/verzeichnis/:/container/verzeichnis

Wie der Name Volume-Mapping schon verrät, mappt diese Option einfach das Verzeichnis vom Docker-Host in das Zielverzeichnis im Container.

Ein komplettes Kommando könnte so aussehen:

docker run -d -v /mnt/data01/www:/www nginx

„/mnt/data01/www“ könnte zB. eine gemountete LUN oder so sein. Der Ordner „www“ wird direkt als „/www“ im Container präsentiert, wo die Applikation dann entsprechend zugreifen kann.

Sichern sollte man das Verzeichnis am Docker-Host selbst.

Bis demnächst.

 

Liebe Grüße

Falk

Netapp ONTAP9 ist da

Bei all dem Gerede über HyperConverged Storages, darf man traditionelle Storages nicht aus den Augen verlieren. 🙂

Heute landete eine Mail in meiner Inbox, dass ONTAP 9 verfügbar sein. Man munkelt ja schon seit einiger Zeit, dass dieses Release ein großer Wurf wird. Grund genug mal einen Blick auf die neuen Features zu werfen.

Netapp ONTAP9 ist da weiterlesen

VM Provisionierung im VSAN-Datastore

Im vorherigen Artikel haben wir den Aufbau und die Konfiguration eines VSANs durchleuchtet (mehr dazu hier). Jetzt soll es darum gehen, wie wir VMs in unseren VSAN Cluster provisionieren können.

Jetzt stellt sich die folgende Frage: Warum muss man jetzt darüber hier etwas schreiben? Wir erstellen schon seit Jahren VMs. Was ist daran so interessant?

VM Provisionierung im VSAN-Datastore weiterlesen

2-Node VSAN Cluster aufbauen

Meinem letzten Artikel über Hyperconverged Storages kann man ja durchaus entnehmen, dass ich doch ein kleiner Fan solcher Technologien bin. (Jürgen würde jetzt wahrscheinlich wieder sagen, ich sei generell leicht zu begeistern 😀 )). Egal.

Ich möchte in diesem Artikel die 2-Node Cluster Thematik etwas beleuchten.

2-Node VSAN Cluster aufbauen weiterlesen

Hyperconverged Storages

Hat man bisher stets eine dedizierte Box benötigt, um ein Shared Storage zur Verfügung zu stellen, kommen vermehrt Rack-Server mit lokalen Disks ins Spiel. Genau diese Rackserver bilden untereinander ein „Distributed Storage“ und das ist die Idee hinter Hyperconverged Storages.

Aktuell ist der Markt überschaubar aber trotzdem breit gefächert. Es ist so, dass sich irgendwie je Anwendungsfall eine andere Lösung anbietet. Das liegt daran, dass sich die Lösungen in meinen Augen aktuell in verschiedene Richtungen entwickeln. Irgendwann werden sicher alle die gleichen Features bieten. Zumindest hat man das am traditionellen Storage-Markt beobachten können – inzwischen liefern ja sämtliche Hersteller ein ähnliches Featureset.

Hyperconverged Storages weiterlesen

„Wir haben ein Problem“ – Wenn der Platz ausgeht …

Hin und wieder kommt es vor, dass Storage-Systeme „einfach“ volllaufen. Die Folgen laufen fast immer auf einen Systemstillstand hinaus. Nicht selten zu 100%.

Schuld ist meist einer dieser Punkte:

  • Hängengebliebene Snapshots
  • Überprovisionierte Storages – „Thin Provisioning“
  • Software

„Wir haben ein Problem“ – Wenn der Platz ausgeht … weiterlesen