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

Es ist ein Irrglaube, dass virtuelles Zusammenarbeiten und das virtuelle Büros gänzlich die Zukunft sind. Der Mensch als soziales Wesen ist einfach nicht dafür gemacht. Zumindest noch nicht. Der Mensch benötigt physikalische soziale Kontakte die er „anfassen“ kann. Die körperliche Nähe ist, auch wenn das dem einen oder anderen vielleicht nicht bewusst ist, enorm wichtig. Ganz unbewusst passieren dabei Dinge die von entscheidender Bedeutung sind. Wir haben es selbst an uns bemerkt und tun gut daran es zu befolgen.

Ein Artikel unserer Fernsehzeitung den ich unlängst gelesen habe basiert auf der gleichen Tatsache. Menschen, deren Gehirne, deren Verhalten „interagieren“ miteinander sobald diese in direkter Reichweite / Sichtreichweite sind. Das ist dann wie bei Musikinstrumenten die nur zusammen ein schönes Lied ergeben. Es gibt Mächte in unserem Universum von denen wir nicht mal zu träumen wagen. Nur weil wir etwas nicht sehen können, heißt das nicht dass es das nicht gibt.

Man sieht nur mit dem Herzen gut.
Das Wesentliche ist für die Augen unsichtbar.
- Antoine de Saint-Exupêry

thausmann Allgemeines soziales Wesen, virtuelle Büro

Was soll ich sagen, es ist manchmal bestimmt frustrierend aber so ist die IT halt nun mal. Wir alle können nichts dafür was die Hard- und Software Hersteller mit ihren Produkten machen. Wir wollen / müssen sie benutzen. Das ist ja aber schon immer so gewesen, dass es mit den IT Produkten mehr oder minder Schwierigkeiten gibt. Bei der Komplexität ist es einem manchmal nicht übel zu nehmen wenn man sich wundert, dass die IT  überhaupt so gut funktioniert wie sie funktioniert.

Automatische Update Funktionen an Kernsystemen sind immer sehr kritisch zu sehen. Wer möchte schon morgens ins Büro kommen und vor einer nicht mehr funktionierenden IT stehen? Daher ist ja zum Beispiel auch der automatische Update mancher Scan Engine abgeschaltet. Und das übrigens schon von der Hersteller Default Einstellung her! Die Hersteller wissen ganz genau dass es damit zu Problemen kommen kann. Es war in der Vergangenheit immer wieder der Fall, dass sogar ein Virenpattern-Update erhebliche Probleme verursacht hat. Und das wird in diesem sehr dynamischen Umfeld vorerst auch so bleiben befürchte ich.

In unserer langjährigen Berufserfahrung haben wir es uns daher stoisch antrainiert auf Alles immer ein Auge zu haben. Es ist nach wie vor so, dass die meisten Fehler in der IT  immer noch dadurch gefunden werden, weil sich ein Mensch (keine Software und keine Hardware!) über die Zusammenhänge, Aktivitäten und Vorkommnisse Gedanken macht. Hier ist nach wie vor der Mensch gefordert. Die Maschine ist nur Hilfsmittel. Derzeit zumindest noch und es wird vermutlich auch noch eine Weile so bleiben.

Die eigentlichen Systemlogs helfen da nur in sofern weiter, dass man bedingt nachvollziehen kann was sich an den Systemen so tut. IT Systeme können sich im Einzelnen innerhalb der definierten Parameter bewegen und dennoch ist das Gesamtergebnis nicht zufriedenstellend. Viel viel wichtiger sind daher übergreifende Protokolle der Aktivitäten die an Systemen vorgenommen werden. Ab einer mittel komplexen IT Infrastruktur sind solche Protokolle lebenswichtig. Man benötigt jemanden der die Zusammenhänge einer Unternehmens IT so genau wie möglich kennt, der die Aktivitäten protokolliert und eventuell auftretende Vorkommnisse dann bewertet und analysieren kann. Das ist bei weitem keine einfache Aufgabe aber eben wie gesagt immer noch unumgänglich.

thausmann Allgemeines Management, Mensch

Hier ein Update zu meinem Artikel über den XenDesktop 4 von gestern Nacht. Mit der Version 4 werden natürlich auch einige Probleme der Version 3.x beseitigt. Unter der Artikel ID CTX122744 hat Citrix die komplette Liste bereitgestellt.

thausmann Virtualisierung, XenDesktop XEN, XenDesktop, XenServer

Auf twitter war heute Abend die Hölle los. Nahezu alle CTPs haben von einem “CTP Only” Webinar über den kommenden XenDesktop 4 berichtet. Als offizielles RTM Datum wurde der 28. Oktober genannt, das Final Release soll dann am 18. November verfügbar sein. Die Ankündigung durch eine entsprechende Pressemitteilung und entsprechende Infomails sollen wohl morgen erfolgen.

Auf der Citrix HDX Seite wurden bereits vor einigen Wochen einige der neuen Features angekündigt. Aus den verschiedenen Infoquellen (twitter, blogs, …) habe ich mal versucht die neuen Funktionen und Änderungen zusammenzustellen.

Lizenzierung und Editionen:

• Lizenzierung pro User. Entgegen den bisherigen Versionen soll die künftige Version 4 des XenDesktop auf eine pro Benutzer Lizenzierung abgeändert werden.
• Deutlich reduzierte Kosten pro User.
• So genanntes “Trade-Up” Programm für bestehende XenApp Kunden.
• Anwendungen von XenApp Servern (die im XenDesktop Paket enthaltene Lizenz) sind nicht mehr auf den XenDesktop begrenzt. Bisher war es nur erlaubt mit dem beim XenDesktop enthaltenen XenApp Anwendungen auf die XenDesktops zu publishen. Diese Einschränkung ist gefallen und die Anwendungen können somit auch auf “nicht” XenDesktops verteilt werden.
• Drei Editionen. Standard, Enterprise und Platinum. Bereits in der Enterprise Edition soll der XenApp Server ohne Einschränkungen enthalten sein.

Neue Funktionen:

• Support für VoIP und Webcams.
• 3D Grafik Support. Diese Funktion erfordert aber entsprechende Hardware (z.B. Blade PCs die CUDA Unterstützung bieten. Der Einsatz mit VMs ist nicht möglich.
• Erweiterter Multi Monitor Support.
• Erweitertes Plug-and-Play
• Media Foundation Support für Windows Media Player und Windows 7
• Unterstützung von Windows7 (32 und 64 bit). Vista und XP werden nun auch in der 64 bit Version unterstützt.
• RDP Support. Neben ICA kann nun auch RDP als Verbindungsprotokoll genutzt werden. Dies ermöglicht es das auch Desktops auf denen der ICA Client bisher nicht installiert werden konnte / durfte über die XenDesktop Umgebung bereitzustellen.

Citrix liefert im Moment ein Feuerwerk an neuen Features für bestehende Produkte. VMware wird es schwer habe mit dem immer noch nicht verfügbaren View 4 mitzuhalten. Ein direkter Vergleich der beiden Produkte wird bestimmt spannend.

thausmann Virtualisierung, XenDesktop Client Virtualisierung, Virtualisierung, XEN, XenDesktop

Bereits am 09. September hat Citrix den Hotfix 3 für den XenServer 5.5 freigegeben. Im Artikel CTX122589 sind die dadurch beseitigten Probleme beschrieben.

Weiterhing wurde am 17. September der Hotfix 4 für den Citrix XenServer 5.5 veröffentlicht. Unter der Knowledgebase ID CTX122705 stehen alle Informationen bereit.

thausmann Virtualisierung, XenServer Hotfix, Virtualisierung, XenServer

So ganz heimlich träume ich ja von einem Apple MacBook Pro. Bisher hab ich mich aber noch nicht dazu durchringen können es als Arbeitsgerät zu wagen. Ich war mir einfach nicht so ganz sicher ob ich wirklich auf alle Windows Anwendungen verzichten kann und will.

Aber vielleicht ändert es sich und ich kann beides habe. Auf der CitrixTV Seite ist ein Video bereitgestellt in dem der kommende XenClient auf einem MacBook gezeigt wird. Auf diesem MacBook läuft neben dem MacOS X ein Windows in einer zweiten virtuellen Maschine.

Irgendwie cool !

thausmann Virtualisierung, XenServer Apple, Mac, Management, XEN

Am 16.09. hat Citrix in einer offiziellen Mitteilung das Erscheinungsdatum des seit einiger Zeit angekündigten Feature Pack 2 für XenApp 5 bekannt gegeben. Am 29.09. kann es über die MyCitrix Seite heruntergeladen werden. Kunden mit zu diesem Zeitpunkt gültiger Subscription können dann das Feature Pack 2 installieren und die neuen Funktionen nutzen.
Gab es beim Feature Pack 1 (da noch ohne 1) keine neuen Funktionen sondern nur bereits vorhandene Funktionen in den entsprechenden Editionen hinzu, ist für das Feature Pack 2 eine sehr interessante Reihe von neuen Funktionen angekündigt worden:

• VM Hosted Apps – Etwas verwirrender Name, denn die Applikationen müssen nicht zwingend in einer VM (Virtual Machine) laufen, es kann auch ein Blade PC oder “normaler” Desktop PC sein.
  Aber was verbirgt sich überhaupt dahinter. Eigentlich ganz einfach. Published Applications in “umgekehrter” Richtung. Im RZ läuft eine virtuelle Maschine (z.B. Windows XP, Vista oder Windows 7) mit einer Anwendung die entweder nicht Terminal Server tauglich ist, extrem viel Ressourcen benötigt oder für die der Softwarehersteller die Installation auf einem Terminal Server nicht gestattet (Lizenzpolitik). Diese Anwendung wird nun als Published Application in der XenApp Farm bereitgestellt und exakt ein Anwender kann jeweils auf diese Anwendung zugreifen. Wird die Anwendung als mehrmals benötigt muss eine entsprechende Anzahl an Workstations im RZ bereitgestellt werden.
  Der Vorteil liegt natürlich darin dass der Anwender weiterhin wie gewohnt seine Umgebung behalten kann (z.B. Thin Client mit Published Desktop) und die benötigte App wie alle anderen auch in seinem Application Set bereitgestellt bekommt.
• Windows 7 und Mobile Support – Vollständiger Support für Windows 7 als Client Device. Dies bedeutet Support von Online Apps (Published Applications und VM Hosted Apps) sowie Offline Apps (Streaming Applications). Der Streaming Profiler wurde um eine Windows 7 Option erweitert und natürlich kann Windows 7 auch als Host für eine VM Hosted App dienen. Ein aktueller XenApp Client für Windows Mobile soll bald folgen.
• Streaming Application Performance – Beim Streaming kommen zwar keine neuen Funktionen hinzu – das Virtualisieren von Diensten im Streaming Paket geht immer noch nicht – dafür soll es aber deutliche Geschwindigkeitsverbesserungen geben. Es ist von ca. 25% schnellerem Start beim ersten Aufruf der Anwendung und bis zu 65% bei weiteren Starts die Rede.
• Power and Capacitiy Management – Diese Komponente gab es schon eine Weile als Tech Preview und ist, so finde ich, eine ziemlich coole Sache. Mit der entsprechenden Serverhardware im RZ können somit Server zu bestimmten Zeiten (Nachts / Wochenende) abgeschaltet werden und somit natürlich deutlich die Energiekosten gesenkt werden.
• Provisioning Services – In der Ankündigung kann ich keine technischen Veränderungen finden noch sind mir welche bekannt. Einzig von der Unterstützung der so genannten VM Hosted Apps wird gesprochen. Dies dürfte aber eher eine lizenztechnische Angelegenheit sein.
• Service Monitoring – Für XenApp Server die auf einer XenServer Umgebung laufen gibt es nun einige Performance Metrics die den Hypervisor überwachen. Somit kann eine besser Planung der Serverauslastung erfolgen.
• HDX Media Stream for Flash – Verbesserungen in der Flash Multimedia Unterstützung
• HDX Plug and Play für USB Storage Devices – USB Storage Devices (USB Sticks, externe Festplatten, usw.) werden nun wirklich als Plug and Play Devices unterstützt. Bisher musste das Gerät vor dem Start der Session angesteckt werden damit das entsprechende Laufwerk verbunden wurde. In der Feature Pack 2 Version soll ein dynamisches Erkennen des USB Devices (nur Storage) während der Sitzung möglich sein.
• Profile Management – das Profile Management trägt nun die Versionsnummer 2.1 und soll vor allen Dingen einige Bugfixes und Performanceverbesserungen enthalten.
• Workflow Studio 2.0 – Version 2.0 des “Orchestrierungstools” für Rechenzentren.

Einige der genannten Features sind ziemlich interessant. Vor allem die VM Hosted Apps sind ein weiterer Schritt in die Zentralisierung von Anwendungen.

thausmann XenApp Feature Pack, XenApp

Eben entdeckt beim “Basic Thinking Blog”. Der Windows Standard Editor Notepad hat eine ziemlich praktische “Logbuch” Funktion.

Wenn man das Notepad öffnet und dann .LOG in die erste Zeile schreibt, die Datei dann als TXT Datei abspeichert und diese wieder öffnet schreibt Notepad einen Zeit / Datumstempel ind die Datei.

Als einfaches Serverlogbuch eine ganz nette Sache.

thausmann Tipps & Tricks Management, Tools

Jeder Windows Administrator kennt das Problem – sobald man in Windows Umgebungen große Datenmengen kopieren muss, ist der Windows Explorer langsam, fehleranfällig und schlicht weg überfordert.
Die Kommandozeilenwerkzeuge COPY und XCOPY sind schon besser geeignet aber nicht wirklich komfortabel. Für einfache Dateistrukturen mag es noch ausreichen, sobald aber z.B. Dateien beim Kopiervorgang ausgeschlossen oder nur bestimmte Dateitypen kopiert werden sollen wir es schwierig. Mit dem korrekten kopieren von Berechtigungen und Besitzerstrukturen ganz zu schweigen.

Daher sollte jeder Windows Administrator das Microsoft Tool RoboCopy (Robust File Copy) kennen. Eigentlich ein “alter Hut” sollte man meinen, denn immerhin ist es bereits seit den Windows Server 2003 Resource Kits verfügbar. Doch in meinen Projekten treffe ich immer wieder auf den einen oder anderen IT Mitarbeiter der dieses Tool nicht kennt.

Wie bereits geschrieben war es bisher als Tool in den Windows Server Resource Kits enthalten, seit Vista und Windows 2008 ist es Bestandteil des Betriebssystems. Es ist bei einer Standardinstallation im Ordner “C:\Windows\system32″ enthalten und kann über die Kommandozeile aufgerufen werden.

Ein Aufruf von robocopy /? zeigt eine ca. 150 Zeilen lange Hilfe und ich glaube genau da steckt der Grund warum viele, durch Windows “verwöhnte” Mausschubser Administratoren , vor diesem Tool zurückschrecken.
Robocopy hat Kommandozeilenparameter ohne Ende und man kann diese fröhlich miteinander kombinieren. Gerade darin liegt die Mächtigkeit dieser “Anwendung”. Mit Robocopy lassen sich herrliche Skripte zur Synchronisation von Verzeichnissen bauen. Verschieben ganzer Verzeichnisstrukturen von einem Server auf den anderen, unter Beibehaltung der Berechtigungsstrukturen, alles ist möglich. Das Beste an Robocopy aber ist dass es nicht blind einfach nur kopiert, sondern mit den entsprechenden Schaltern nur geänderte Dateien kopiert und ggf. an der Quelle gelöschte Dateien auch am Ziel entfernt. Man kann mit verminderter Bandbreite kopieren – ideal für WAN Verbindungen, oder auch den Job zu einer bestimmten Zeit beenden. Das ermöglicht es Datenmigrationen nur in den Nachtstunden durchzuführen.

Aber zugegeben, manchmal ist es wirklich nicht einfach sich mit den vielen Parametern und Optionen zurecht zu finden.
Aus diesem Grund hat schon vor längerer Zeit ein Microsoft Mitarbeiter ein GUI für Robocopy geschrieben. Über eine Windows Oberfläche können alle Optionen und Parameter ausgewählt und eingestellt werden und am Ende entsteht dann daraus eine Skriptdatei mit der entsprechenden Kommandozeile.
In einem Technetartikel zu Robocopy wird die GUI beschrieben und dort findest sich auch eine Möglichkeit zum Download der Robocopy GUI 3.1.2.

Mittlerweile gibt es verschiedene Versionen von Robocopy.

XP010 – Version von Windows 2003 Ressource Kit

XP026 – Version zusammen mit Robocopy GUI

XP027 – Version von Windows Vista (32 / 64) und Windows Server 2008

Es soll auch eine Version XP028 geben, aber selbst in Windows 7 ist “nur” die Version XP027 enthalten.

thausmann Tipps & Tricks Tools