Necron

Eine SCVMM Migration ist immer eine Deinstallation mit Beibehaltung der Datenbank und Neuinstallation des SCVMM mit Verwendung der beibehaltenen Datenbank. Da erledigt die Setup Routine nichts. Nacharbeiten fallen bei den Templates zum Beispiel an. Der SC2012 SP1 VMM bietet aber eine ganze Menge mehr, als das was man vom SCVMM 2008 R2 gewohnt ist und da beginnen dann die Nacharbeiten bzw. Einarbeitung/Konfiguration. Das nur mal als Beispiel.

Du kommst um eine kurze Downtime nicht herum. Wenn beide Cluster stehen: 1. Task: Cluster Migration Wizard ausführen und die VM "Hüllen" auf den neuen Cluster migrieren. 2. Task: LUNs vom alten auf den neuen Cluster umhängen. => Kurze Downtime 3. Task: VMs auf dem neuen Cluster starten So die Kurzfassung.

Hi, ein bisschen was zum Lesen. ;) -> http://www.server-talk.eu/2013/02/13/hyper-v-networking-grundlagen-in-system-center-2012-sp1-virtual-machine-manager/ -> http://www.server-talk.eu/2013/02/15/der-logical-switch-in-system-center-2012-sp1-virtual-machine-manager/ -> http://www.server-talk.eu/2013/05/02/konfiguration-von-hyper-v-converged-fabric/ Damit dürften deine Fragen alle beantwortet sein und du erhältst eine Anleitung, wie die Konfiguration erfolgen sollte.

Da sind die Nacharbeiten auch nötig.

Hi, schau dir mal die Anleitung von Marc Grote an: http://www.it-training-grote.de/blog/?p=5783

Die Datenmigration ist schon möglich, aber es haben sich zum Beispiel beim SCVMM so viele Sachen geändert, dass man abwägen muss ob sich das lohnt. Stichwort Nacharbeiten!

Hi, die technische Migration wird eine komplette Neuinstallation der Komponenten sein.

Derzeit und wahrscheinlich auch in Zukunft auch nicht anders möglich, als das was Dukel schon aufgelistet hat. Eventuell mal schaun, ob RedHat so eine Möglichkeit hat.

Hi, daraus werde ich noch nicht ganz schlau. Meinst du eine Workstation für Verwaltungsaufgaben, die per Failover Cluster Manager zum Beispiel erledigt werden sollen?

Stimmt nun wieder auch. ;) Noch kurz zum Scale-Out File Server und Spiegelung mit zwei JBODs: http://www.hyper-v-server.de/videos/scale-out-filerserver-erklrt-teil-2-storage-einrichten-2/ Es geht, aber die Konfiguration muss dann per PowerShell erfolgen. :) Um es abschließend mal festzuhalten, welche Alternativen übrig bleiben, wenn nur Local Storage verwendet werden soll: -> Hyper-V Replica zwischen Hyper-V Standalone Hosts -> Nachteil kein automatischer Failover -> Hyper-V Failover Cluster mit Starwind Native SAN for Hyper-V oder anderen 3rd Party Anbietern

Okay dann habe ich mit dem Begriff Enclosure im Zusammenhang mit dem JBODs etwas falsch verstanden und durcheinander gebracht. Sry. Da hat sich das Thema, aber dann generell erledigt dies kostengünstig hinzubekommen, wenn Hochverfügbarkeit gefordert ist.

Es geht doch Dukel. ;) -> http://social.technet.microsoft.com/wiki/contents/articles/11382.storage-spaces-frequently-asked-questions-faq.aspx#What_are_the_best_uses_of_simple_mirror_and_parity_spaces

Genau! Das ist eines der Prinzipien welches hinter den Storage Pools und Storage Spaces steckt. Wie aber oben schon geschrieben, habe ich eine derartige Konfiguration noch nicht im Betrieb gesehen, um die Funktionalität zu 100% bestätigen zu können. Alleine anhand der Logik, die dahinter steckt, sollte es aber möglich sein.

Habe ich doch oben beschrieben!? Ich habe es in der Kombination leider noch nicht im Betrieb gesehen. Nach der Logik, die dahinter steckt, sollten dann aber immer die gleiche Anzahl von Disks aus beiden JBODs dem Storage Pool zugeordnet sein, damit es funktioniert

Scale-Out File Server funktionieren auch mit SAS JBODs, die jeweils an die File Server per SAS angeschlossen sind. Mittels der File Server wird ein Failover Cluster gebildet und per Storage Pools und Mirrored Disks gewährleistet, dass die Daten auf beiden SAS JBODs liegen. Die Mirrored Disks, nichts anderes als eine virtuelle Festplatte, werden dann als CSV im Cluster eingebunden. Das kurz und knapp dazu sowie Hyper-V supported.

Wenn an dem Scale-Out File Server zwei SAS JBODs angeschlossen sind und darüber dann ein Storage Pool mit Mirrored Disks gefahren wird, hätte man zwar nicht eine Replizierung, aber die Daten lägen auf beiden SAS JBODs. Lohnt sich denn bei kleinen Umgebungen überhaupt ein redundanten Storage? Brauchen kleine Umgebungen eine solche Hochverfügbarkeit? Hier würde ich entweder auf einen Hyper-V Failover Cluster ohne redundanten Storage setzen oder zwei Hyper-V Standalone Hosts mit Hyper-V Replica, wenn das Budget für einen redundanten Storage nicht ausreicht.

Hi, Mir ist derzeit nur das Starwind Native SAN for Hyper-V bekannt, welches solch eine Funktionalität bietet. Wobei ich bei einem Hyper-V Failover Cluster zu einem richtigen Shared Storage (iSCSI SAN, FC SAN oder SMB 3.0 Scale-Out File Server) greifen würde.

Wie schon gesagt, funktioniert es direkt mit dem Setup! Forest Function Level und Domain Function Level waren schon immer zwei unterschiedliche Einstellungen und Umstellvorgänge. Außer man erhöht direkt den Forest Function Level, dann wird auch der Domain Function Level angehoben.

Hi, ISCSI Filer? Sind das Windows Server mit iSCSI Target?

In der MMC AD Domänen und Vertrauensstellungen wird der Forest Function Level angehoben.

Bitte direkt an Microsoft wenden! Wir können da nichts machen!

Hi, habe es schon durchgeführt! Funktioniert einwandfrei!

Hi, wenn der VMM mit dem SCOM integriert ist, dann bietet der SCOM mit dem VMM MP einen einfachen Chargeback Report an. Für richtige Abrechnungen der Service Leistungen auf Basis von SLAs kommst du um den Service Manager mit dem Cloud Process Pack nicht herum. Das heißt einfacher Chargeback ist mit VMM und SCOM möglich. Ein komplexerer Chargeback benötigt VMM, SCOM, SCSM und Orchestrator.

Dito! Aber sollte auch anders herum funktionieren: VMM als VM installieren, Cluster mittels VMM erstellen, per Shared Nothing Live Migration oder Live Storage Migration die VMM VM auf das Cluster Shared Volume migrieren und abschließend die VMM VM per Failover Cluster Manager hochverfügbar machen.

Hi, die Erfahrung kann ich jetzt nicht bestätigen, aber gut zu wissen! :)