none
LUN-Verwaltung mit Speicher-Manager für SAN und iSCSI-Target 3.3 RRS feed

  • Frage

  • Hallo,

    folgende Konfiguration unter Hyper-V:

    1 Server mit 1 NIC im privaten Netz für iSCSI, darauf iSCSI-Target installiert

    2 Server mit 2 NICs in zwei privaten Netzwerken, eins für iSCSI, ein anderes für die Kommunikation mit Clients, darauf iSCSI-Target-Client installiert

    mit iSCSI-Initiator Verbindung zum Target möglich

    in der Datenträgerverwaltung auch Zugriff auf LUN, wenn dieses im iSCSI-Target erstellt wird

    Start des Speicher-Managers für SAN: einige Sekunden "Dienst für virtuelle Datenträger (VDS) und VDS-Hardwareanbieter werden geladen ...", danach leere Tabelle bei LUN-Verwaltung, Subsysteme und Laufwerke. Unter LUN-Verwaltung sind alle Aktionen ausgegraut.

    Die gleiche Konfiguration unter VirtualBox -> alles ist aus dem Speicher-Manager für SAN verwaltbar.

    Alle Server sind mit Server 2008 R2 SP1 installiert. Es wurde das iSCSI-Target vom April 2011 und vom März 2012 getestet, keine Unterschiede.

    Welche Voraussetzungen sind nötig, damit sich unter Hyper-V mit dem Speicher-Manager für SAN LUNs auf dem iSCSI-Target erstellen und verwalten lassen?

    Samstag, 21. Juli 2012 16:06

Antworten

  • Hallo mslux

    Nicht nur das Diskmanagement verwendet diese Exception sonder auch der Storage Manager for SANs. Die Notwendigkeit diese Exception zu setzen steht in der Hilfe des Storage Manager for SANs.

    Hilfe des Storage Managers vor SANs


    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    • Als Antwort markiert mslux Mittwoch, 5. September 2012 09:07
    Mittwoch, 5. September 2012 07:27
    Moderator

Alle Antworten

  • Damit der iSCSI Target verwendet werden kann ist prinzipiell ein Windows Server mit dem Target notwendig welcher eine IP-Verbindung mit den Servern hat welche den iSCSI Initiator ausführen.

    Das ist die einfachste Konfiguration!

    Empfehlen tun wir zwei iSCSI Verbindungen über zwei Subnetze zum Target hin und die Verwendung von MPIO auf den Server welche den Initiator Service ausführen (damit ist sicher gestellt, dass wenn eine Verbindung ausfällt - NIC, etc. die LUN dennoch vorhanden ist).


    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    Montag, 23. Juli 2012 08:04
    Moderator
  • Sorry, Herr Pfann, aber haben Sie überhaupt meine Frage gelesen?
    Montag, 23. Juli 2012 19:16
  • Für den Betrieb des Storage Manager for SANs gibt es zum einen eine kleine Anleitung von uns:

    http://www.microsoft.com/de-de/download/details.aspx?id=4626

    Und zum anderen ist für die Kommunikation zwischen diesem und dem iSCSI Target ein sog. VDS hardware provider notwendig. Dieser sollte für den iSCSI Target in den iSCSI Tools enthalten sein: iSCSITargetClient_public.msi

    http://www.microsoft.com/en-us/download/details.aspx?id=19867


    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    Dienstag, 24. Juli 2012 07:52
    Moderator
  • Wenn Sie meine Frage nicht lesen wollen, brauchen Sie auch nicht zu antworten. Ich brauche Hilfe, keine Textbausteine. Und auch keine Anleitungen für Windows Server 2003 R2 aus dem jahre 2005. Oder wollen Sie nur ihr Punktekonto erhöhen? Wie Sie meiner Frage entnehmen können, ist die Konfiguration unter VirtualBox funktionsfähig. Also weiß ich offenbar, wie es eingerichtet werden muss. Nur unter Hyper-V funktioniert es nicht!

    Solche Antworten hätte ich von einem Moderator, der zudem noch direkt von Microsoft kommt, nicht erwartet. :-(

    Dienstag, 24. Juli 2012 15:19
  • Ihre Frage war:

    "Welche Voraussetzungen sind nötig, damit sich unter Hyper-V mit dem Speicher-Manager für SAN LUNs auf dem iSCSI-Target erstellen und verwalten lassen?"

    Meine Antwort ist:

    "... für die Kommunikation zwischen diesem und dem iSCSI Target ein sog. VDS hardware provider notwendig ist. Dieser sollte für den iSCSI Target in den iSCSI Tools enthalten sein: iSCSITargetClient_public.msi"

    Ob das unter VMware, VirtualIrgendwas oder Hyper-V gemacht wird spielt keine Rolle. Wenn ich Ihre einleitenden Worte richtig interpretiere, haben sie mehrere VMs unter Hyper-V laufen in denen eine Target/Initiator-Konfiguration verwendet werden soll. Falls dem so ist, muss zwischen den VMs eine IP-Verbindung (Ping sollte durchgehen) vorhanden sein, daß habe ich in meinem 1ten Posting geschrieben.

    Darüber hinaus möchte ich Sie darauf hinweisen, dass Microsoft im Rahmen der TechNet-Foren nicht zu einer Lösung oder auch Antwort verpflichtet ist sonder wir lediglich unterstützen. Das Forum lebt prinzipiell durch den Austausch aller Teilnehmer.

    Es besteht auch die Möglichkeit auch eine Skizze als Bild hier hoch zu laden, damit ist allen welche den Beitrag lesen ein besseres Verständnis möglich. Vielleicht erhalten Sie dadurch die von Ihnen gewünschte Informationen.


    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    Dienstag, 24. Juli 2012 15:40
    Moderator
  • Hier noch ein paar Ergänzungen:

    • Es wurde eine neue Testumgebung unter Hyper-V aufgebaut, um Fehler durch andere Rollen und Features auszuschließen.
    • Das iSCSI-Target ist kein Domänenmitglied. Testweise wurde es in die Domäne aufgenommen, aber erwartungsgemäß hat das keinen Einfluss auf die iSCSI-Verwaltbarkeit. Es sind keine Rollen und Features installiert, lediglich das iSCSI-Target.
    • Auf den Knoten N1 und N2 wurden nur die Clientkomponente des iSCSI-Targets und das Feature Speicher-Manager für SANs installiert.
    • Auf allen Servern am iSCSI-Netz wurde zunächst die iSCSI-Target-Version 3.3.16549 vom April 2011 installiert und danach getestet:  keine Verwaltung im Speicher-Manager für SANs möglich.
    • Danach wurde auf allen betroffenenen Servern auf die iSCSI-Target-Version 3.3.16563 QFE4 vom März 2012 installiert: keine Verwaltung im Speicher-Manager für SANs möglich.
    • Nach der Installation wurde jeweils der Dienst VDS beendet und neu gestartet. Auch ein Neustart führt zu keiner Veränderung.
    • Auf allen Computer sind die aktuellsten Windows-Updates installiert.
    • Alle virtuellen Maschinen sind mit dynamischem RAM und vier logischen Prozessoren konfiguriert.
    • Ein Test mit nur einem Netzwerk führt zum selben negativen Ergebnis.

    So sieht meine Konfiguration aus:

    Was kann ich noch tun, um die Verwaltung im Speicher-Manager für SANs zu ermöglichen?

    Montag, 3. September 2012 14:55
  • Hallo mslux

    Die Installation des iSCSI Target ist nur auf dem eigentlichen iSCSI-Target Server notwendig. Damit eine Verwaltung des iSCSI-Targets von den Servern N1 und N2 über den Storage Manager for SANs erfolgen kann muss neben diesem Feature auf den Server N1 und N2 das Remote Volume Management in der Firewall enabled werden, das ist darüber hinaus auch auf dem iSCSI Target notwendig. Danach kann vom Storage Manager for SANs eine Verbindung zum iSCSI Target geöffnet werden und dessen LUNs und Targets werden sichtbar. In meiner Umgebung ist allerdings - im Gegensatz zu der oben, der Target ebenfalls ein Mitglied der Windows Domain. Auf dem iSCSI Target selbst ist bei mir außerdem der iSCSITargetClient_Public.msi installiert welchen ich ebenfalls auf allen Servern installiert haben welche LUNs über iSCSI verwenden.

    Ein lokaler Betrieb des Storage Manager fpr SANs hat auf meinem iSCSI-Target auf Anhieb funktioniert.

    Falls noch Fragen bestehen einfach melden.


    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    Dienstag, 4. September 2012 12:36
    Moderator
  • Hallo Bernd,

    vielen Dank für die Antwort. Allerdings kann die Aussage bezüglich der Firewallregeln nicht stimmen. Die von dir angegebenen Regeln sind, wie der Name schon sagt, für die Remotevolumeverwaltung. Das bedeutet, dass mit dem Snap-In Datenträgerverwaltung eine Remoteverwaltung erlaubt wird. Hier geht es aber um iSCSI-Targets. Dafür werden durch die Installation auf dem Server (iSCSI-Target) fünf Regeln in der Firewall erzeugt und alle aktiviert. Auf einem Client (iSCSI-Initiator) werden zwei Regeln erzeugt und aktiviert. Ihre Namen beginnen alle mit Microsoft iSCSI Software Target.

    Ich habe die Kommunikation unter VirtualBox mit Wireshark untersucht. Es findet tatsächlich eine RPC-Kommunikation zwischen WTVdsProv.exe und WinTarget.exe statt.

    Untersuche ich dagegen die Kommunikation in Hyper-V, dann ist auf dem iSCSI-Target überhaupt kein eingehender Datenverkehr bezüglich der Kommunikation des Speicher-Managers für SANs feststellbar. Genauso ist es auf dem iSCSI-Initiator. Es ist bei Starten des Snap-Ins nicht einmal ein Three-Way-Handshake auszumachen. Ein Wechsel zwischen synthtischer und emulierter Netzwerkkarte brachte keine Veränderungen. Die Prozesse vds.exe und WTVdsProv.exe werden zwar beim Start des Speicher-Managers für SANs ebenfalls gestartet, jedoch beginnt WTVdsProv.exe keine Netzwerkkommunikation. Warum nicht?

    Natürlich können sich die beiden Rechner gegenseitig anpingen, die Kommunikation ist also grundsätzlich möglich. Das beweisen auch die anderen Protokolle, wie ARP, NbtNs, Kerberos, DNS, ICMPv6 und ICMP, die ich alle in Wireshark sowie im Netzwerkmonitor beobachten kann.

    Wenn ich  iSCSITargetClient_Public.msi zusätzlich zu  iSCSITarget_Public.msi auf dem iSCSI-Target installiere, ist die Verwaltung mit dem Speicher-Manager für SANs auf diesem Rechner möglich. (Danke für den Tipp!)

    Dienstag, 4. September 2012 20:19
  • Hallo mslux

    Nicht nur das Diskmanagement verwendet diese Exception sonder auch der Storage Manager for SANs. Die Notwendigkeit diese Exception zu setzen steht in der Hilfe des Storage Manager for SANs.

    Hilfe des Storage Managers vor SANs


    Viele Grüße, Bernd Pfann [Microsoft] - This posting is provided "AS IS" with no warranties, and confers no rights.

    • Als Antwort markiert mslux Mittwoch, 5. September 2012 09:07
    Mittwoch, 5. September 2012 07:27
    Moderator
  • Super! Nun haben wir endlich die Lösung!

    Ich hätte nicht gedacht, dass diese Firewallregeln auch in diesem Szenario nötig sind. Aus der Hilfe hatte ich herausgelesen, dass man von einem Computer (zum Beispiel Windows 7) einen anderen Computer, auf dem der VDS-Hardwareanbieter installiert ist (also dort, wo der Prozess WTVdsProv.exe läuft), fern verwalten will.

    Dazu kommt, dass ich durch VirtualBox verwirrt wurde. Wenn ich dort den Speicher-Manager für SANs gestartet habe, waren alle Aktionen unter LUN-Verwaltung sofort verfügbar, während sie in der Hyper-V-Umgebung ausgegraut waren. Deshalb nahm ich an, dass unter VirtualBox im Gegensatz zu Hyper-V die Funktionalität gegeben sei.

    Nun habe ich einmal versucht, mit deaktivierten Remotevolumeverwaltungsregeln unter VirtualBox ein LUN zu erstellen. Der Assistent läuft prima durch, nur im letzten Schritt kommt es zur Fehlermeldung, dass der VDS oder der VDS-Hardwareanbieter nicht mehr erreichbar wären. Es bleibt zwar unklar, warum die Aktionen unter VitualBox nicht auch ausgegraut sind, aber das interessiert mich jetzt nicht mehr.

    Es lag also eindeutig an den nicht aktivierten Regeln für die Remotevolumeverwaltung.

    Herzlichen Dank für die Hilfe!

    ---

    Zu früh gefreut!

    Plötzlich ist es von N2 möglich, die LUNs remote zu verwalten, ohne die Firewallregeln zu Remoteverwaltung zu aktivieren. Nun verstehe es ich wieder nicht mehr.


    • Bearbeitet mslux Mittwoch, 5. September 2012 09:40 Ergänzung
    Mittwoch, 5. September 2012 09:07