iSCSI + MPIO + Festplatten-Klonen

[romkus]

Unsere Infrastruktur ist folgendermaßen aufgebaut: WUDSS 2003 R2
stellt iSCSI Targets zu Verfügung, diese werden von Server 2008 R2
konsumiert und als pass-through Disks an Hyper-V weitergegeben. Wir
benutzen also keine VHDs für Hyper-V. Bis vor kurzem haben wir auch
kein MPIO eingesetzt.

Für OS-Deployment haben wir folgendes Szenario gewählt: wir haben
vorkonfigurierte "Master"-Images für die Guest OS, die in Form
virtuelle Disks (im Sinne von WinTraget, nicht VHDs) auf WUDSS liegen.
Nach bedarf werden diese kopiert, in WinTarget importiert und als neue
Targets für neue virtuelle Maschinen zur Verfügung gestellt. Vor
Deployment wird noch Sysprep ausgeführt.

Bisher hat das wunderbar funktioniert: die Bereitstellungszeit für
einen neuen virtuellen Server beträgt in diesem Verfahren weniger
Minuten.

Nun haben wir MPIO auf Hyper-V Servers installiert und es funktioniert
wunderbar wie beschrieben.

Als es zum Deployment nach beschriebenen Szenario kam, waren mit
folgendem Problem konfrontiert: sobald zwei oder mehr solche
"geklonter" Images per iSCSI Initiator angeschlossen werden, führt
MPIO diese geklonnte Fesplatten zusammen – das heisst die erste
Festplatte wird normal angebunden, bekommt 1 oder mehr MPIO-Pfade,
weitere Festplatten aber, die auch eigene LUNs besitzen und auf
anderen Targets liegen werden nicht angebunden, sondern es werden MPIO-
Pfade an den ersten Image angebunden. Weitere Platten erscheinen also
nicht in Disk-Manager, und es stehen "falsche" Pfade in MPIO-Bereich
beim Initiator.

Wir haben mittlerweile auch andere Wege für Deployment untersucht, und
keine von den kommt Zeitlich nah an von uns gewählten Weg.

MPIO wird nun für uns sehr wichtig, aber Deployment sollte darunter
auch nicht leiden – handelt es sich um einen Bug? Wir haben uns schon
alle Köpfe zerbrochen.

[Bernd Pfann [MS]]

"romkus" <rom...@gmail.com> wrote in message
news:82e0249e-d308-46cb...@k41g2000yqm.googlegroups.com...
> Unsere Infrastruktur ist folgenderma�en aufgebaut: WUDSS 2003 R2
> stellt iSCSI Targets zu Verf�gung, diese werden von Server 2008 R2

> konsumiert und als pass-through Disks an Hyper-V weitergegeben. Wir

> benutzen also keine VHDs f�r Hyper-V. Bis vor kurzem haben wir auch
> kein MPIO eingesetzt.
>
> F�r OS-Deployment haben wir folgendes Szenario gew�hlt: wir haben
> vorkonfigurierte "Master"-Images f�r die Guest OS, die in Form

> virtuelle Disks (im Sinne von WinTraget, nicht VHDs) auf WUDSS liegen.
> Nach bedarf werden diese kopiert, in WinTarget importiert und als neue

> Targets f�r neue virtuelle Maschinen zur Verf�gung gestellt. Vor
> Deployment wird noch Sysprep ausgef�hrt.
>
> Bisher hat das wunderbar funktioniert: die Bereitstellungszeit f�r
> einen neuen virtuellen Server betr�gt in diesem Verfahren weniger

> Minuten.
>
> Nun haben wir MPIO auf Hyper-V Servers installiert und es funktioniert
> wunderbar wie beschrieben.
>
> Als es zum Deployment nach beschriebenen Szenario kam, waren mit
> folgendem Problem konfrontiert: sobald zwei oder mehr solche

> "geklonter" Images per iSCSI Initiator angeschlossen werden, f�hrt
> MPIO diese geklonnte Fesplatten zusammen � das heisst die erste

> Festplatte wird normal angebunden, bekommt 1 oder mehr MPIO-Pfade,
> weitere Festplatten aber, die auch eigene LUNs besitzen und auf
> anderen Targets liegen werden nicht angebunden, sondern es werden MPIO-
> Pfade an den ersten Image angebunden. Weitere Platten erscheinen also
> nicht in Disk-Manager, und es stehen "falsche" Pfade in MPIO-Bereich
> beim Initiator.
>

> Wir haben mittlerweile auch andere Wege f�r Deployment untersucht, und
> keine von den kommt Zeitlich nah an von uns gew�hlten Weg.
>
> MPIO wird nun f�r uns sehr wichtig, aber Deployment sollte darunter
> auch nicht leiden � handelt es sich um einen Bug? Wir haben uns schon
> alle K�pfe zerbrochen.

Ich vermute das Problem liegt darin, dass alle Disks eine identische
Signatur haben! Leg mal eine neue Disk auf dem Target an - die sollte dann
korrekt erscheinen.

--
Mit freundlichen Gr��en / Kind regards - Bernd Pfann (Microsoft)

This posting is provided "AS IS" with no warranties, and confers no
rights.