bluvenit IT-Professionals Blog

Immer wieder gibt es Unklarheiten bei der Konfiguration eines iSCSI Enterprise Target (IET) unter Linux in Verbindung mit der Benutzung als Storage Server für VMware ESX Server.

Welche Parameter werden benötigt? Welche müssen abweichend der Standardeinstellungen angepasst werden?

Wird das IET nicht korrekt konfiguriert kann es sein, dass die bereitgestellten LUN’s anschließend im ESX Server nicht oder nur teilweise zu sehen sind oder im weiteren Verlauf nicht richtig funktionieren. Wird nur eine einzige LUN bereitgestellt treten in der Regel keine Probleme auf. Sobald aber mehrere LUN’s und / oder mehrere Targets eingerichtet werden kommt es zu Problemen wenn man die Konfigurationsparameter in der ietd.conf nicht ausreichend eindeutig spezifiziert. Werden die Parameter nicht ausreichend gesetzt und mehrere LUN’s wurden definiert kommt es dazu, dass die ESX Server die Targets und / oder die LUN’s nicht voneinander unterscheiden können. Das Fatale ist oft, dass die Targets / LUN’s initial im ESX Server eingebunden und auch benutzt werden können. Bei einem späteren Neustart der ESX Server können diese dann die LUN’s plötzlich nicht mehr voneinander unterscheiden. Der Zugriff auf die LUN’s und die darauf befindlichen virtuellen Maschinen bleibt gesperrt. Wenn der ESX Server LUN’s die zuvor schon einmal im Zugriff waren nicht mehr unterscheiden kann, werden diese oftmals vom ESX Server als Snapshot’s LUN’s deklariert.

Werden im schlechtesten Fall die LUN’s vom ESX Server nicht mehr eindeutig erkannt, ist der Zugriff auf die virtuellen Maschinen, welche auf der iSCSI Storage abgelegt wurden, erst einmal nicht mehr möglich. Ein Recovery ist dann zeitaufwendig und alle virtuellen Maschinen müssen unter Umständen im ESX Server bzw. vCenter Server neu registriert werden. Dies hat auch zur Folge, dass alle VM’s eine neue UUID verpasst bekommen.

Ein weiterer Punkt ist, dass bei manchen IET Versionen die speziellen Parameter die für einen funktionierenden Betrieb in Verbindung mit VMware ESX Server zwingend benötigt werden, ignoriert wurden. Daher sollten man bei einem Wechsel der IET Version immer überprüfen ob besagte Parameter bis zum ESX Server durchdringen.

Um welche Parameter handelt es sich nun und wie müssen diese gesetzt werden? Dies wird anhand eines Auszuges einer ietd.conf Datei nachfolgend beschrieben.

Beispiel:

Target iqn.2007-01.de.bluvenit.hostname:iet-target0.2010120800

Lun 0 Type=fileio,Path=/srv/lun-data/VMFS-Disk0,ScsiId=SI2010120800,ScsiSN=SIET2010120800

Alias hostname:iet-target0

Target iqn.2007-01.de.bluvenit.hostname:iet-target1.2010120801

Lun 0 Type=fileio,Path=/srv/lun-data/VMFS-Disk1,ScsiId=SI2010120801,ScsiSN=SIET2010120801

Alias hostname:iet-target1

Targetname:

Der Targetname (iqn.*) muss für jedes Target eindeutig sein. Die Zusammensetzung des Namens ist festgeschrieben in der iSCSI Spezifikation (rfc3720).



iscsi-iqn

Type: Fest. Muss <iqn> lauten

Date: yyyy-mm

Naming Auth: Umgekehrter Domänen Name. Hier empfiehlt es sich den Hostnamen mit aufzunehmen, da der <Naming Auth> am Initiator sichtbar wird und somit das Target besser identifiziert werden kann.

Optionaler String: Freier Wahl einer zusätzlichen Zeichenfolge. Sollte in jedem Fall definiert werden. Wenn mehrere Targets an einem iSCSI Storage Server angelegt werden muss mit dieser Zeichefolge das Target eindeutig „gemacht“ werden.

Die Punkte bzw: Doppelpunkte zur Trennung der „Felder“ bzw. beim Domänen-Namen müssen wie oben angegeben werden.

LUN:

Bei der LUN muss die ScsiSN eindeutig sein. Es hat sich aber gezeigt, dass auch die Angabe einer eindeutigen ScsiId von Vorteil ist. Beide Parameter dürfen maximal mit maximal 16 Zeichen belegt werden.

Um die Eindeutigkeit zu gewährleisten bietet sich die Verwendung aus einer Kombination von umgekehrtem Datum mit angehängter zweistelliger Nummer an. Es wird das Datum verwendet am dem die LUN angelegt wird. Werden später weitere LUN’s angelegt weiß man somit wann die LUN angelegt wurde.

Beispiel:

ScsiId=SI2010120801,ScsiSN=SIET2010120801

ScsiId=SI2010120801: <SI (Scsi Id)><JJJJMMTT><Nummer zweistellig>

ScsiSN=SIET2010120801: <SIET><JJJJMMTT><Nummer zweistellig>

Nummer zweistellig: Fortlaufende Nummer beginnend mit 00

Alias:

Die Aliasangabe ist ein andere Name für den Targetnamen und sollte daher auch eindeutig sein.

Die verwendeten Namen bei Target und LUN tauchen später beim ESX Server in hexadezimaler Schreibweise am Storage Adapter auf. Somit kann am ESX Server das korrekte Auftauchen der iSCSI LUN’s überprüft werden.

Eine weitergehende Beschreibung zu allen IET iSCSI Parametern findet man beim Aufruf der Man-Page: man ietd.conf

thausmann Storage, VMware, Virtualisierung ESX, IET, iSCSI, SAN, Storage

Speicherplatz für Daten ist nach wie vor gefragt. Die Verfügbarkeit von Informationen ist eine wichtige Basis für das Handeln von Unternehmen. Der Mensch ist ein Sammler und Jäger seit jeher. Und diese Eigenart ist auch einer der Schlüssel warum der Mensch in der Evolution weitergekommen ist. Dies hat ihm dazu verholfen sich auf Situationen vorbereiten zu können in dem er alles was ihm wichtig erschien gesammelt hatte. Früher oder später wird es von Nutzen sein. Dies übertragen in die heutige Zeit bedeutet je mehr Informationen vorliegen desto passender kam man agieren. Das ist auch der Zweck unseres Unterbewusstseins. Unser bekanntes Bauchgefühl ist das Ergebnis der Auswertung aller vorhandenen Informationen unseres Unterbewusstseins zu einem Ereignis einer Frage oder Entscheidung.

Daher sollte ein Unternehmen seinen Mitarbeitern genügend Speicherplatz für die Speicherung wichtiger Informationen zur Verfügung stellen. Die Mitarbeiter sind dabei diejenigen welche beurteilen können was für ihre Aufgabe wichtig ist und was nicht. Denn diese Mitarbeiter machen letztendlich die Arbeit / das Geschäft.

Daten sind also eines der wichtigsten Dinge was ein Unternehmen besitzt. Also sollte genügend Speicherplatz zu Verfügung gestellt werden, der aus verständlichem Grunde, zudem geschützt und auch ausfallsicher sein sollte. Des Weiteren sollte der Speicherplatz allen Systemen zur Verfügung stehen damit dieser so effizient wie möglich genutzt werden kann.

Nun existiert vielfach die irrige Meinung, dass gemeinsam nutzbarer Speicherplatz im Serverbereich sehr kostenintensiv ist. Wenn dieser zudem auch noch ausfallsicher sein sollte wird es nochmal teurer. Vielfach wird auch auf der Performance Argumentation herumgeritten. Aber weit gefehlt! Es muss nicht immer die teure High End Storage Lösung sein, was man uns auch gerne Glauben machen möchte. In den meisten Standard Umfeldern wird das bei weitem gar nicht benötigt. Es macht sich fast niemand die Mühe hinterher zu untersuchen ob die gekaufte Performance tatsächlich ausgenutzt wird. In den meissten Fällen dürfte das nicht der Fall sein. In einem VMWare ESX Server Umfeld mit drei ESX Servern, 20 virtuellen Maschinen und einem Datenvolumen von ca. 2 Terrabyte an Daten ist es so dass eine maximale Datenübertragungsrate von kanpp 20 MB pro Sekunde auftritt. Der Durchschnitt dabei bei 1,8 MB pro Sekunde liegt. Diese Anforderung kann bequem von einer iSCSI Storage Lösung bewältigt werden. Dazu bedarf es keiner teuren FC-SAN Lösung. Mit Gigabit Ethernet können maximal 125 MB pro Sekunde je Port übertragen werden. Werden mehrere Ports geschickt eingesetzt kann man die Performance sehr einfach steigern. Es ist immer noch so, dass der eigentliche Flaschenhals die Festplattenmechanik an sich ist. Die Schnittstellen der Festplatten können zwar weit mehr aber was nützt das. Es ist immer das schwächste Glied in der Kette zu berücksichtigen.

Mit der iSCSI Technologie lassen sich extrem leistungsfähige und zugleich skalierbare Storage Umgebungen aufbauen. Man kann preiswerte, und ich meine wirklich wörtlich preiswerte, Storageumgebungen aufbauen die bei Bedarf ausgebaut werden können. Man muss nicht im Vorfeld in Funktionen investieren die man später vielleicht mal benötigt aber im nachhinein schwer, gar nicht oder nur mit vergleichbar höheren Kosten implementieren kann. Schon für relativ wenige tausend Euro kann man eine shared Storage Lösung für eine VMware ESX oder XEN Server Umgebung bekommen. Diese kann dann zu einem späteren Zeitpunkt zu einer voll redundanten Lösung ausgebaut werden.

thausmann Storage Daten, iSCSI, Netzwerk, SAN, Speicherplatz, Storage, VMware, XEN