Seite 1 von 21 1 2 3 4 5 11 ... LetzteLetzte
Ergebnis 1 bis 25 von 523
  1. #1
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard Microsoft Hyper-V Stammtisch

    ALLGEMEINE EINLEITUNG

    Da es zu den vielen anderen Hypervisoren hier schon diverse Sammler gibt und von den "verbreiteteren" Hyper-V noch fehlt, fände ich einen Sammler/Stammtisch zu Hyper-V ziemlich super - auch weil es für einen Anfänger echt mühsam sein kann, bei Null anzufangen.

    Ich selbst habe bisher nur Erfahrungen mit Technical Preview Server 2016 (von der TP1 bis zur aktuellen TP5 hatte ich alle am Laufen) gesammelt - im Homelab und ohne Hintergrundwissen. Deshalb will und kann ich keine echten Empfehlungen geben, ob bestimmte von mir gegangene, funktionierende und von mir deshalb hier beschriebene Wege/Vorgehensweisen die "richtigen" sind. Ganz im Gegenteil: häufig dürften hier zukünftig beschriebene Dinge (nur mal zum Beispiel: "HowTo: ESXI nested Hyper-V" oder "HowTo: non-domain-joined-cluster") eher ausdrücklich NICHT zu den Standards, empfohlenen Infrastrukturen gehören oder auch nur in irgendeiner Weise "supported" sein.

    NACHTRAG 28. Oktober 2016: Jetzt wo die finalen Server 2016er Versionen verfügbar sind, wäre es natürlich hilfreich zu wissen, ob sich noch etwas für die How Tos geändert hat. Ich werde daher nach Möglichkeit für die einzelnen HOWTOs mit der Zeit updaten und jeweils vermerken.



    SERVER 2016 (HYPER-V) HOWTOs

    HowTo 1: Der einfachste Weg: Windows Server 2016 (GUI)

    HowTo 2: Der ressourcen-schonenste Weg: Microsoft Hyper-V Server 2016 (kein GUI, keine Domäne)(getestet mit final Hyper-V Server 2016)

    HowTo 3: Hyper-V bootable von USB-Stick (vergleichbar der gängigen ESXi-Installationen)

    HowTo 4: Hyper-V virtualisiert auf ESXi

    HowTo 5: Hyper-V Failover Clustering (ohne Domäne)

    HowTo 6: Remote Failover-Cluster Management mit Desktop-OS

    HowTo 7: Hyper-V Cluster mit Nano-Servern
    Bin ich zufällig bei einer Fehlersuche für mein HowTo 5 drüber gestolpert und der Kerl scheint mal echt zu wissen, was er tut...

    HowTo 8: ActiveDomain Erst-Setup (um Hyper-V in einer Domäne aufzusetzen)

    HowTo 9: Discrete Device Assignment mit Dell HBA (Proof of Concept mit Dell T130)

    HowTo 10: Brute-Force Server 2016 Installation mit UEFI-BIOS (wenn der Installer einfach nicht will.)


    Lizenzfragen
    Der Hyper-V Server 2016 wird wie auch bisher kostenlos sein. Details dazu gibt es hier (und hier als PDF).

    Lizenzen fallen eben dann nur für die jeweiligen laufenden Windows-VMs an.

    Bitte nicht vergessen: es wird hier um "Home-use" gehen. Die offiziellen Anforderungen zum Beispiel für ein Failovercluster wird auch der ambitionierte Power-User kaum zu Hause erfüllen. Über Anmerkungen oder Ergänzungen, einschließlich konstruktive Kritik, freue ich mich natürlich immer.

    Und dann hätte ich da noch:

    Linksammlung
    Verzeichnis oben verwendeter Links
    [to come]

    Zusätzliche Infos:
    PCIe Passthrough mit Hyper-V
    Allgemeine nützliche PowerShell-Kommandos


    Aber genug der Einleitung. Los geht's...
    Angehängte Grafiken Angehängte Grafiken
    Geändert von besterino (27.01.18 um 18:08 Uhr)
    Spoiler: Anzeigen

  2. Die folgenden 6 User sagten Danke an besterino für diesen nützlichen Post:

    HTag (12.08.17), LichtiF (31.03.16), NUMA (10.05.19), Patric_ (05.05.17), porto007 (29.04.16), Turboschnecke (31.03.16)

  3. Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.

  4. #2
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    HOWTO 1: HYPER-V MIT GUI IM SCHNELLVERFAHREN

    0. Microsoft Account

    Falls noch nicht vorhanden: kostenlosen Account bei Microsoft erstellen

    1. Download Server 2016 TP ISO

    Download der Windows Server 2016 Technical Preview 4 von der Microsoft Seite (Registrierung erforderlich)

    2. ISO booten.

    3. Installation mit GUI

    Die Installation gleicht der klassischen Windows-Installation. Hinweis: Zwar gibt es es die Preview auch auf Deutsch, aber die meisten Dokumente im Netz (HowTos, insb. mit Befehlen & Co.) sind auf Englisch. Da gerade die Powershell-Kommandos - netterweise - aber von der Sprachversion abhängig sind, verwende ich noch immer die englische Fassung mit eben deutschen Regional- und Keyboard Einstellungen. Es ist nach meiner Erfahrung zumindest für den Anfänger (wie mich) ein Monster-Krampf, die richtigen englischen powershell Befehle für die deutsche Fassung zusammenzufummeln. Daher sieht meine Standardinstallation so aus:



    Bei der weiteren Installation muss man nur aufpassen, dass man abweichend von der Standardauswahl eben die GUI-Variante (Desktop Experience, yeah baby) auswählt:



    4. Erster Start nach Reboot

    Nachdem wir das Passwort festgelegt und uns angemeldet haben, wir ggf. die Netzwerkerkennung für unser primäres LAN akzeptiert oder abgeleht haben, begrüßt uns bald der Server Manager:



    5. Hyper-V Rolle installieren

    Dort clicken wir bevor wir uns an die weitere Einrichtung machen direkt beherzt auf "Add roles and features" und immer einfach auf "next" bis wir bei "Server Roles" angekommen sind und setzten den Haken bei "Hyper-V":



    In dem aufklappenden Fenster lassen wir auch den Haken bei "Include Management Tools":



    ...und clicken dann auf "Add Features" und auf "next" bis wir bei den virtuellen Switches angekommen sind.

    6. Aufpassen: (keinen) virtuellen Switch erstellen

    Wenn ihr über nur eine Netzwerkkarte verfügt (wie bei mir hier), solltet ihr vorsichtshalber hier KEINEN Haken setzen. Wir konfigurieren den virtuellen Switch sogleich manuell.



    7. Speicherort für die VM

    OPTIONAL: Ggf. nach Bedarf den Speicherplatz für die VMs ändern. Achtung bei Speicherplätzen im Netz: das klappt nach meiner Erfahrung wenn überhaupt nur mit SMB3 (und natürlich iSCSI - dazu kommen wir dann spätestens unten beim Failover Cluster noch einmal). Um mögliche Fehlerquellen auszuschließen würde ich daher für's erste einen Speicherort auf einer lokalen Platte im Host auswählen bzw. die Standardeinstellungen unverändert lassen.

    8. Rolle Installieren

    Next clicken, ggf. den Haken für automatische Restarts setzen (mach ich gerne) und auf "Install" clicken.



    9. Reboot / Finalisierung

    Nach dem Reboot und erfolgreicher Anmeldung finalisiert der Wizard noch die Installation, wir clicken auf close und "Heureka", da ist unser Hyper-V Host.



    Dem aufmerksamen Beobachter ist im Screen Shot oben vielleicht aufgefallen, dass sich der Server-Manager links nun um einen Bereich "Hyper-V" erweitert hat.

    10. Administration Hyper-V Host

    Die weitere Administration des Hyper-V Hosts erfolgt im Wesentlichen über den Hyper-V manager, zu erreichen z.B. über Tools und darin Hyper-V (ja, es gibt auch andere Wege). Es öffnet sich also der Hyper-V Manager, in dem wir auch direkt unseren (lokalen) Hyper-V Host sehen.



    11. Grund-Konfiguration Server

    Bei der weiteren Konfiguration des Servers selbst beschränke ich mich hier auf das absolute Minimum und unterstelle, dass die Kiste über DHCP die IP-Adresse, DNS und Co. bekommt. Und das Minimum ist quasi: RDP aktivieren. Über den Servermanager denkbar simpel, nämlich auf das "Disabled" bei Remote Desktop clicken, "allow remote connections to this computer" auswählen und das firewall-popup mit OK bestätigen. Fertig.



    Mein Tipp fürs Heimnetz: feste IP und anderen Computernamen vergeben, IP aber am besten eben erst nach Erstellung des virtuellen Switches.

    Kommen wir nun also zum Eingemachten, zu den eigentlichen Hyper-V Funktionen:

    12. Weitere Konfiguration "Hyper-V": virtueller Switch

    Als erstes konfigurieren wir den virtuellen Switch. Hier unterstelle ich wieder, dass es nur eine Netzwerkkarte gibt. Wer ihn geschlosen hat, öffnet also wieder den Hyper-V Manager (oben Schritt 10) und clickt nun rechts im Menü auf den Virtual Switch Manager. Darin "external auswählen" und auf "Create virtual switch" clicken.



    Dem Switch geben wir noch einen Namen, erlauben insbesondere, dass das management operating system den Switch mitbenutzen darf und bestätigen die Warnmeldung mit OK.



    Damit haben wir die letzten "Infrastrukturmaßnahmen" abgeschlossen, die unser Host als "minimum" braucht, um sinnvoll VMs mit Kontakt zur Außenwelt einzurichten.

    13. Virtuelle Maschine erstellen

    Jetzt wird's spannend: die Erste VM. Ich hab' hier jetzt einfach mal eine Ubuntu-VM genommen. Warum? Linux Server braucht wenige ressourcen, ist schnell installiert und wird voll als Gen2-VM unterstützt. Wir clicken also rechts auf new und wählen "Virtual Machine".



    Ein (wie ich finde hilfreicher) Wizard öffnet sich.

    14. ...mit dem Wizard

    Der Wizard führt uns brav durch die einzelnen Schritte. Wir wählen also Namen...



    ...die Generation der VM (hier Generation 2, weil Ubuntu eben unterstützt ist, und hier die MS Entscheidungshilfe ob Gen1 oder Gen2)...



    ...RAM-Größe (und gerne dynamisch bei Gen2)...



    ...unseren oben unter 12. erstellten virtuellen Switch...



    ...eine virtuelle Festplatte (mit den Standard-Einstellungen)...



    ...wählen Idealerweise eine ISO-Datei für die Erst-Installation des OS in der VM... Hinweis: auch hier gibt's es ggf. Zickereien mit ISOs auf SMB-Freigaben...(diesen Schritt kann man natürlich auch später nachholen)



    ...und bestätigen am Ende mit "Finish", worauf dann die neue VM im Hyper-V Manager erscheint.

    15. Besonderheit: Linux-VM

    OPTIONAL (abhängig vom GastOS): da der Ubuntu-Installer so nicht ohne Weiteres bootet, müssen wir hier noch SecureBoot (Gen2 Feature) manuell ausschalten: VM Auswählen, auf Settings clicken, im neuen Fenster "Security" auswählen und den Haken bei "Secure Boot" entfernen:



    Natürlich bitte mit OK bestätigen.

    [WEITER GEHT ES IM NÄCHSTEN POSTING]
    Angehängte Grafiken Angehängte Grafiken
    Geändert von besterino (17.07.16 um 00:28 Uhr)
    Spoiler: Anzeigen

  5. #3
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    [FORTSETZUNG 1]

    16. Mit VM verbinden und VM starten

    Wir clicken nun auf die neue VM (1.), dann - weil wir ja mit dem Ding was machen wollen, hier ein OS installieren - auf connect (2.), starten schließlich das Ganze in dem sich öffnenden Fenster über den Startknopf (3.)



    und es folgt...

    17. ...die Stunde der Wahrheit:



    Herzlichen Glückwunsch: Willkommen in Eurer ersten Hyper-V Hosted VM. =)

    Hinweis: Als Proof of Concept (und weil Screenshots so einfacher zu machen und hochzuladen sind), habe ich den Hyper-V oben als Virtuelle Maschine auf einem ESXi6U1-Host aufgesetzt...

    Hier also das "Teaser-/Beweisbild" mit Ubuntu-VM auf Hpyer-V-VM auf ESXi6:

    Angehängte Grafiken Angehängte Grafiken
    Geändert von besterino (17.07.16 um 00:27 Uhr)
    Spoiler: Anzeigen

  6. #4
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    Kommen wir nun zum Fortgeschrittenen-Programm. Ich habe jetzt das Ganze einmal komplett durchgetestet mit jeweils einer frischen Hyper-V und Win10ProDesktop Installation. Auch hier gilt, die nachfolgenden Schritte sind das Minimum.

    Die Installation und Einrichtung des Hosts an sich ist eigentlich kein Problem. Etwas fummelig und "die Kunst" ist einfach nur, den Host und einen (separaten Windows)Client (nachfolgend nur kurz Client genannt) dazu zu bekommen, dass man die Hyper-V Funktionen wie im HowTo 1 schließlich über GUI in Form des Hyper-V Managers administrieren kann.

    HOWTO 2: MICROSOFT HYPER-V SERVER 2016 TECHNICAL PREVIEW 4 (KEIN GUI, KEINE DOMÄNE)

    TEIL 1: DER HOST

    1. Installation

    Für die Installation des Hosts verweise ich auf das HowTo 1 oben im 1. Posting, nur dass man bitte das ISO Microsoft Hyper-V Server 2016 Technical Preview 4 zum Download auswählt (und nicht den Server 2016).

    2. Nach dem Reboot

    Nach der Installation begrüßt uns eine sehr spartanische Oberfläche in Form von 2 Fenstern: eine cmd-shell in einem schwarzen Fenster und die "Server Configuration" in einem blauen Fenster.



    Im blauen Fenster können wir insbesondere die Grundeinstellungen des Hosts festlegen, also den Computer Namen (hier im Beispiel HYPVCORE) und insbesondere die feste IP-Adresse (hier im Beispiel: 192.168.178.106).

    3. Administrator Passwort setzen ist seit der TP5 und auch in der finalen Hyper-V Server 2016 Version nicht mehr erforderlich - hier nur noch als "Legacy-Info" enthalten oder für den Fall, dass man das Passwort einmal ändern möchte.

    Code:
    C:\Users\Administrator>net user Administrator *
    Das Passwort brauchen wir übrigens später.

    4. (Basis) Remote Management erlauben

    In der schwarzen Shell geben wir nun ein (alle Abfragen ggf. mit "J" bzw. "Y" bestätigen):

    Code:
    C:\Users\Administrator>powershell \\wechselt in die Powershell
    PS C:\Users\Administrator>enable-PSremoting \\setzt die nötigen Variablen und öffnet die Firewall soweit nötig
    PS C:\Users\Administrator> enable-wsmancredssp -role server \\erlaubt alternative Anmeldungsverfahren zu Kerberos
    TEIL 2: DER CLIENT:

    Vorwort: Im Gegensatz zu 2012R2 oder auch vorherigen 2016er TPs ist die Konfiguration des Clients deutlich einfacher geworden. Auf einer frisch installierten Windows 10 Maschine waren im Wesentlichen nur drei Schritte nötig: Eine Gruppenrichtlinie überarbeiten, ein Powershell Kommando (für das ein Dienst kurz ein- und dann wieder ausgeschaltet wird) und eben den Hyper-V Manager installieren:

    5. Hyper-V Verwaltungstools / RSAT installieren

    Auf unserem Windows 10 PC (ein 2016er Server lässt sich nur mit Windows 10 administrieren) für die Verwaltung des Hosts (mit GUI, zur Erinnerung: Client) installieren wir die Hyper-V Management Tools (Systemsteuerung-->Programme und Features-->rechts auf "Windows-Features aktivieren oder deaktivieren" und navigieren zu Hyper-V und wählen nur die Hyper-V-Verwaltungstools:



    ...oder wo wir gerade dabei sind auch gleich die kompletten RSAT (Remote Server Administration Tools) (LINK).

    Nun finden wir in der Systemsteuerung unter "Verwaltung" auch unseren so wichtigen Hyper-V Manager. Bevor wir damit richtig loslegen können, müssen wir allerdings erst einige Vorkehrungen treffen.

    6. Anmeldung auf (Fremd-)Servern erlauben

    Da die übliche Anmeldung über die AD in diesem Fall nicht funktioniert, müssen wir eine alternative Anmeldung erlauben. Wir öffnen also auch auf dem Client eine Powershell als Administrator (s.o.):

    Code:
    PS C:\Users\Administrator>start-service winrm
    PS C:\Users\Administrator>Enable-WSManCredSSP -Role client -DelegateComputer * \\erlaubt eine Anmeldung auf ALLEN Rechnern
    PS C:\Users\Administrator>stop-service winrm
    7. NTLM-Serverauthentifizierung erlauben

    Dann führen wir im gleichen Fenster mit der Administrator-Powershell gleich auch "gpedit.msc" aus, da wir jetzt noch auf dem Client den Wechsel in ein anderes Nutzerprofil (nämlich den Admin auf dem Server) erlauben müssen.

    In dem sich öffnenden Fester des Group-Policy-Editors wechseln wir zu: Computerkonfiguration-->Administrative Vorlagen-->System-->Delegierung von Anmeldeinformationen und machen darin einen Doppelclick auf "Delegierung von aktuellen Anmeldeinformationen mit reiner NTLM-Serverauthentifizierung zulassen"



    Dort wählen wir "Aktiviert" und clicken auf "Anzeigen". Dann geben wir dort in dem Fenster "WSMAN/*" ein, bestätigen 2x mit "OK" und schließen das Fenster mit dem GP-Editor wieder.



    Am besten sicherheitshalber einmal Ab- und Anmelden oder gleich den Client einmal neu starten.

    8. Hyper-V Manager starten

    Nun öffnen wir auf dem Client den Hyper-V Manager: (windowstaste-->"hyper-V" eingeben-->obersten Eintrag anclicken).

    9. Client mit Server verbinden

    Im Hyper-V Manager müssen wir uns nun mit dem Host verbinden, indem wir rechts auf "Verbindung mit dem Server herstellen..." clicken (1.), in der sich öffnenden Maske "anderer Computer" auswählen und die IP unseres Hyper-V Hosts eingeben (2.), den Haken bei "Verbindung als andere Benutzer herstellen" setzen (3.), auf Benutzer einstellen clicken (4.) und schließlich unseren Account auf dem Host mit "IP\Administrator" sowie dem ganz oben unter 3. gesetzten Passwort eingeben (5.):



    Dann 2x mit OK bestätigen und...

    10. Done!

    ...voilá, unser Server taucht im Hyper-V Manager auf und lässt sich nun wie im HowTo 1 beschrieben administrieren.





    Randbemerkungen für fortgeschrittenere Admins:

    Seitdem ich das zuletzt mal eingerichtet habe (muss mit der TP2 oder TP3 gewesen sein), hat sich hier wohl etwas getan. Alle HowTos - die ich im Netz gefunden habe - bilden das so noch nicht ab (yay, ich biete hier quasi echten Mehr-/Erkenntniswert ), da diese meistens zu 2008R2/2012/2012R2 geschrieben wurden und die Informationslage zur 2016er Version noch lückenhaft (und - leider - ja auch noch nicht endgültig ist).

    Zum CLIENT

    1. Man muss auf dem Client kein DCOM mehr zulassen, das vorher notwendige Bearbeiten des Remotezugriffs für den Anonymous Account mit dcomcnfg kann entfallen.

    2. Man muss auf dem Client keine Firewall-Regeln mehr setzen.

    3. Ist der Client nicht in einer Domäne, ist eine Zuordnung der IP zu einem Hostnamen (über die Host-Datei) nicht mehr nötig, man kann im Hyper-V Manager direkt mit der IP-Adresse arbeiten. Ist der Client aber in einer Domäne, ist das immer noch zwingend erforderlich (habe ich mit einer frischen Windows 10 Installation reproduziert)! ACHTUNG: selbst wenn der Client nur irgendwann einmal in einer Domäne WAR und aktuell "nur" in einer Arbeitsgruppe ist, muss man trotzdem die IP dem Hostnamen in der hosts-Datei zuordnen. Keine Ahnung was dahinter steckt, werd's vielleicht mal im TechNet posten.

    4. Das Anlegen identischer Admin-Accounts (Name/Passwort) auf Client/Server ist nicht mehr nötig: man kann sich jetzt mit fremden Credentials anmelden.

    5. Der Server muss auf dem Client nicht mehr als TrustedHost angegeben werden. (Komischerweise egal ob in einer Domäne oder nicht.)

    Zum SERVER

    1. Die Einrichtung auf dem Server geht ebenfalls deutlich einfacher vonstatten als noch bei vorherigen TPs oder offenbar unter Windows 2012R2. Im Ergebnis müssen nur zwei Powershell-Befehle eingegeben werden, die ihrerseits die nötigen Einstellungen (insbesondere an der Firewall sowie einen Registry-Key) setzen.

    2. Es müssen darüber hinaus keine Dienste mehr manuell gestartet/konfiguriert werden.
    Angehängte Grafiken Angehängte Grafiken
    Geändert von besterino (07.12.16 um 11:20 Uhr)

  7. #5
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    Kommen wir nun zum nächsten Schritt:

    HOWTO 5: HYPER-V FAILOVER CLUSTER (OHNE GEMEINSAME DOMÄNE)

    TEIL 1: EINE EINFÜHRUNG

    Damit die ganze Sache überhaupt in der Praxis Sinn macht, brauchen wir mindestens zwei physische Maschinen, auf denen jeweils (zumindest auch) ein Hyper-V Host läuft. Mehr Hosts ist natürlich immer nett, aber nicht nötig und @home sowieso schwierig. Daher wird in der Folge hier immer unterstellt, dass (nur) zwei Hyper-V Hosts existieren.

    Im Gegensatz zu unseren bisherigen Gehversuchen mit Hyper-V - "Stand-alone" per HowTo 1 oder "Remote Managed" per HowTo 2 - müssen wir uns jetzt bei einem Failover Cluster aber um eine weitere Komponente einmal nähere Gedanken machen, die wir bisher grundsätzlich ausklammern konnten: STORAGE. Konkret: wo sollen die VMs und ihre (virtuellen) Festplatten jetzt eigentlich hin?

    Warum?

    Unser Failover-Cluster hat ja den Sinn, dass eine darin laufende HAVM (high availability virtual machine - also hochverfügbare virtuelle Maschine) grundsätzlich auch dann weiter laufen soll, wenn der physische Host - auf dem sie bis gerade munter lief - plötzlich oder geplant ausfällt, aus welchen Gründen auch immer. Das funktioniert allerdings nur, wenn die Festplatte(n) bzw. VHD(x)s der HAVM auch für alle (anderen) physischen am Cluster teilnehmenden Rechner (sogenannte "Nodes") zur Verfügung steht.

    Ist das nicht der Fall und sollte nun eine der Nodes Schluckauf haben und ausfallen, und liegt ausgerechnet auf einer lokalen Platte dieses Nodes die HAVM, hätten wir leider Pech gehabt. In einem Zwei-Node-Cluster dürfte also nur "die andere Node" ausfallen - das bringt uns nicht so richtig weiter.

    Ich kann hier leider auch (noch) keine perfekte Lösung aufzeigen. Eine solche ginge wahrscheinlich in die Richtung zwei weiterer (virtueller) Windows File-Server, die ihrerseits einen separaten Storage-Cluster neben dem Hyper-V Cluster aus lokalen Platten/VMs bilden. Theoretisch könnte man diese Fileserver wahrscheinlich auch virtualisieren. Alternativ habe ich auch mal an einen Fileserver als HAVM gedacht, der einen Raid1-Verbund aus (mindestens) 2 Festplatten in Form von iSCSI-Freigaben von eben (mindestens) zwei physischen Hosts als Storage bekommt und dann zurück als VM-Speicherplatz bereitstellt. Dann könnte theoretisch auch eine Seite komplett ausfallen und die HAVM stünde noch auf einem Raid1-Bein zur Verfügung. Damit habe ich mich allerdings noch gar nicht beschäftigt und hat bei mir gerade weder Priorität noch "haben-wollen-Faktor". Das darf gerne ein anderer mal ausprobieren/niederschreiben. Außerdem ist dann da noch das Lizenzthema für die Fileserver (keine Ahnung ob das zukünftig ein Essentials- oder Core-Edition kostenlos mitbringt).

    Als praktischer und praktikabler Kompromiss bieten sich meiner Meinung nach zwei Möglichkeiten an:

    1. Ein drittes Maschinchen, das seinerseits mindestens "iSCSI-Freigaben" bereitstellen kann (vielleicht geht's auch mit SMB3, habe ich aber nicht selbst ausprobiert). Das kann z.B. ein ohnehin bereits vorhandenes (Fertig-)NAS sein. Jedenfalls sollte diese Box möglichst zuverlässig laufen, iSCSI darauf leicht zu konfigurieren sein und das Ding auch weitgehend wartungsfrei sein (wenn man daran was machen will, muss man ja im Zweifel den ganzen Cluster, also alle VMs und besser auch beide physischen Hosts runterfahren).
    • Vorteil: einer von beiden Hyper-V Hosts kann jeweils vollständig abrauchen, der andere kann einspringen.
    • Nachteil 1: Will das dritte Maschinchen nicht mehr, bringen auch zwei an sich laufende Hyper-Vs nichts mehr.
    • Nachteil 2: Raucht (nur) die Storage-Maschine ab, geht auch nichts mehr. (Wenn einem die Konfiguration des Clusters, die VMs oder Zeit auch nur irgend etwas bedeutet, ist also RAID/Backup bei dieser Kiste Pflicht).


    2. Eine Storage-VM auf einem der beiden Hosts, die "neben" (also nicht IN) dem jeweiligen Hyper-V läuft. Daher war/ist es für mich so faszinierend, dass man einen Hyper-V Host als VM in einem ESXi-Host (sogenannt "nested") laufen lassen kann (s.o. HowTo 4)!
    • Vorteil 1: ich brauche keine 3. physische Maschine (spart vielleicht sogar Strom) und kann trotzdem jeweils zur Not auf einen Hyper-V Host verzichten (Wartung/Reboot/Spielerei).
    • Vorteil 2: Ich bin mit ESXi fast gar nicht bei der Auswahl eingeschränkt, welche (Software)Basis ich für mein Storage haben will (alles ist denkbar, wie Solaris/ZFS, OMV, XPEnology und und und...).
    • Vorteil 3: Über einen internen virtuellen ESXi-vSwitch laufen Datentransfers innerhalb des ESXi-Hosts zwischen der Hyper-V-VM und der Storage-VM näher am physischen Storage-Limit - und eben nicht am Netzwerklimit (SSD anyone?).
    • Vorteil 4: Raucht die ESXi-Hyper-V-Host-VM ab, steht die Storage-VM grundsätzlich noch für die 2. Node auf der anderen Box zur Verfügung (wenn das Problem nicht auf den ESXi-Host durchschlägt und der sich mit verabschiedet).
    • Vorteil 5: Ausreichende Hardware-Ressourcen voraussgesetzt, sind alle Napp-it All In One Nutzer bereits bestens aufgestellt.
    • Nachteil 1: Die Performance von einem "virtualisierten" Hyper-V Host ist schlechter als "bare metal".
    • Nachteil 2: Höhere Komplexität birgt höheres Fehlerpotenzial (auf allen Ebenen, u.a. bei Hyper-V oder auch bei der Storage-VM). Nachteil 3: Stirbt die Storage-VM, sterben alle HAVMs (und ggf. je nach Konfiguration / Pech die Hyper-V Hosts gleich mit). Nachteil 4: Ggf. höhere Hardwareanforderungen / Anschaffungskosten für die "All-in-one" Box.


    Ich habe mich für eine Kombination aus Variante 1 und Variante 2 entschieden: Mein Hauptfiler mit den iSCSI-Freigaben läuft als ESXi-VM (Variante 2) und ich benutze eine 3. Box (Variante 1) als Backup der Storage VM.

    Für das Failover-Cluster HowTo selbst werde ich zunächst unterstellen, dass irgendwo im Netz mindestens ein iSCSI-Share zur Verfügung steht.

    Exkurs "nested Hyper-V": Hyper-V 2016 soll breits/zukünftig auch "nested" Hyper-V (und vielleicht auch andere Hypervisoren?) ermöglichen. Theoretisch können das vielleicht jetzt auch schon noch andere Hypervisoren wie Proxmox, Oracle & Co. Ich habe bisher nur ESXi6 ausprobiert und für mich als absolut stabil (genug) kennen gelernt.
    TEIL 2: VORBEREITUNGEN (NUTZER UND CO...)

    0. OPTIONAL: Management VM/Maschine

    Um die Verwirrung und die Komplexität des HowTos in Grenzen zu halten, trenne ich mal den Cluster-Aufbau von der Verwaltung des Ganzen. Der Einfachheit halber nehme ich eine GUI-Serverversion und eine Core (mit dem GUI-Server verwalten wir in diesem Beispiel den non-GUI Hyper-V). Im Prinzip solltet Ihr damit aber auch in der Lage sein, einen Cluster nur aus non-GUI Servern zu bauen (alle PS-Befehle sind ja angegeben).

    1. Feste IPs

    Ihr solltet für alles weitere am besten Euren Servern feste IP-Adressen geben. Ich habe für dieses HowTo meinen beiden oben über die HowTos eingerichteten Servern die folgenden festen Adressen gegeben:

    192.168.178.240=HYPVCORE
    192.168.178.241=HYPVGUI

    HYPVCORE ist der Hyper-V Host, den wir in HowTo 1 erstellt haben.
    HYPVGUI ist der Hyper-V Host, den wir in HowTo 2 erstellt haben.

    2. Primäres DNS Suffix

    Ich kenne mich mit DNS nicht wirklich gut aus. Nach meinem Verständnis geht es hier darum, eben eine "Domäne" vorzugaukeln und ich habe mich an der klassischen Internet-Domain-Nomenklatur orientiert. Soll heißen: Schema NAME.TOPLEVEL - in meinem Beispiel "howtofailo.priv".
    Laut meiner Quelle müssen alle Cluster-Mitglieder ein solches DNS-Suffix haben. Keine Ahnung ob das immer der gleiche sein muss, hab bei beiden Hyper-V-Hosts vorsichtshalber den gleichen genommen (howtofailo.priv). Ich hab's nicht getestet, ob/wie es auch ohne geht. Also machen wir's halt (auf allen Hyper-V Hosts für's Cluster! Connecten dafür bitte per RDP zu unseren remote-Server(n)):

    In der GUI-Version ist's recht einfach: Links auf Local Server", auf den Computer-Namen clicken, "Change" clicken, "More" clicken, bei "Primary DNS suffix of this computer" den Namen eingeben:



    In der CORE-Version müssen wir die Registry direkt manipulieren und wechseln wieder in die Powershell für:
    Code:
    PS C:\User\Administrator> Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\" -Name Domain -Value "howtofailo.priv"
    (Funktioniert natürlich auch in der GUI-Version - geht vielleicht schneller)

    Machen wir's über die Powershell, vorsichtshalber rebooten!

    3. "hosts" Datei anpassen

    Im GUI-Server, da wir mit diesem den Cluster bauen werden, editieren wir die "hosts" Datei und weisen der IP-Adresse des non-GUI Server den entsprechenden Hostnamen (HYPVCORE) zu.

    Also Editor (Notepad) als Administrator ausführen, auf Datei-->Öffnen clicken, alle Dateien auswählen und navigieren zu c:\Windows\System32\drivers\etc-->Datei "hosts" öffnen:



    (Alternativ, schneller und eleganter in Administrator-command- oder powershell eingeben: "notepad c:\Windows\System32\drivers\etc\hosts").

    In meinem Beispiel mit den 2 Hyper-V-Hosts sieht die Hosts-Datei des GUI-Servers (HYPVGUI) dann also wie folgt aus:

    Code:
    # Copyright (c) 1993-2009 Microsoft Corp.
    #
    # This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
    #
    # This file contains the mappings of IP addresses to host names. Each
    # entry should be kept on an individual line. The IP address should
    # be placed in the first column followed by the corresponding host name.
    # The IP address and the host name should be separated by at least one
    # space.
    #
    # Additionally, comments (such as these) may be inserted on individual
    # lines or following the machine name denoted by a '#' symbol.
    #
    # For example:
    #
    #      102.54.94.97     rhino.acme.com          # source server
    #       38.25.63.10     x.acme.com              # x client host
    
    # localhost name resolution is handled within DNS itself.
    #    127.0.0.1       localhost
    #    ::1             localhost
    192.168.178.240        HYPVCORE.howtofailo.priv
    WICHTIG: ihr müsst unbedingt den primären DNS-Suffix (hier im Beispiel : howtofailo.priv) mit eintragen, sonst funktioniert die Erstellung des Clusters nicht! (Die Fehlersuche hat mich STUNDEN gekostet...)

    4. Einheitliche Benutzer

    Für die Einrichtung eines "Arbeitsgruppen"-Clusters (also ohne einheitliche Domäne) brauchen wir auf allen Maschinen - die Teil des Clusters werden sollen! - einen einheitlichen Benutzer-Account mit Administrator-Rechten. Einheitlich heißt: gleicher Name, gleiches Passwort. Falls Ihr nur mit den Hyper-V Servern arbeitet, könnt Ihr natürlich den eingebauten Administrator-Account benutzen und müsst nur das gleiche Passwort setzen (admin-cmd: "net user Administrator *"). Das habe ich hier gemacht.

    TEIL 3: REMOTE-STEUERUNG ÜBER SERVER-MANAGER

    Ganz so einfach wie die Einrichtung des Hyper-V Managers für die Remotesteuerung (HowTo 2 oben) geht es leider hier nicht. Wir müssen nun zunächst unserem Management-PC (VM, Client oder eben ein GUI-Hyper-V Server) beibringen, dass er den zu verwaltenden Servern vertrauen kann.

    1. Vertrauen schaffen...

    Als erstes bringen wir unserem Management-Client bei, dass er den Servern hinreichend vertraut (und ihnen u.a. seine Anmeldedaten übermittelt). Dazu öffnen wir eine Administrator-Powershell und geben Folgendes ein:

    Code:
    PS C:\windows\system32>set-item WSMan:\localhost\Client\TrustedHosts -value "HYPVGUI.howtofailo.priv,HYPVCORE.howtofailo.priv" -concatenate
    Falls der WinRM-Dienst noch nicht läuft, werdet Ihr gebeten, den Start zu bestätigen ("JA"). Dann gibt es eine zweite Warnung, ob Ihr die TrustedHosts-Liste ändern wollt (ebenfalls "JA").

    WICHTIG: Auch hier das primäre DNS-Suffix mit eintragen!

    2. Remote-Server im Server Manager hinzufügen

    Jetzt können wir als nächstes den Server im Server-Manager des Management-Client hinzufügen. Dazu machen wir links im Server Manager auf "Alle Server" einen rechtsclick und wählen "Server hinzufügen" (1.). In der sich öffnenden Maske wählen wir DNS (2.) und geben den/die Hostnamen unserer Hyper-V Host(s) in das Suchfeld ein und clicken auf die Lupe (3.). Dann wählen wir den Server in der Liste aus und clicken auf den kleinen Pfeil daneben (4.), worauf der Server dann in dem mit "ausgewählt" überschriebenen Feld erscheint. Am Ende bestätigen wir mit "OK" (5.).



    3. Server mit anderen Anmeldedaten managen

    Die Server tauchen immerhin jetzt in der Liste auf, aber leider begrüßt uns auch eine Fehlermeldung (pro hinzugefügtem Server, also hier 2):



    DON'T PANIC!

    Wir machen nun einen Rechtsclick auf den Server, wählen dann "Verwalten als" und geben in der sich öffnenden Maske die Admin-Accountdaten des jeweiligen Servers ein nachdem Muster "HOSTNAME\Account", in meinem Beispiel also "HYPVGUI\Administrator" mit dem entsprechenden Passwort. Am besten gleich den Haken bei "Anmeldedaten speichern" setzen.



    Etwas Geduld und dann ändert sich der Stand bei der Verwaltbarkeit in "Online - Leistungsindikatoren wurden nicht gestartet". Oleole, die Leistungsindikatoren sind uns an dieser Stelle schnuppe (wer mag kann sie anwerfen über einen rechtsclick auf den Server-->"Leistungsindikatoren starten").

    Damit sind die Server GRUNDSÄTZLICH verwaltbar, insbesondere lassen sich remote direkt aus dem Server Manager Rollen und Features hinzufügen...

    TEIL 4: FAILOVER-CLUSTER EINRICHTEN

    1. Failover-Features installieren

    Und genau das machen wir jetzt (endlich). Dank unserer Vorarbeiten gibt es zwei Möglichkeiten:

    • Über GUI: Wir gehen im Server Manager zum Dashboard und wählen "Rollen und Features hinzufügen". In dem sich öffnenden Wizard clicken wir munter auf weiter, bis wir zur Serverauswahl kommen. Dort wählen wir nun unseren remote zu steuernden Server.

      Zur Erinnerung: in meinem Bespiel sind ja beide Server remote, so dass wir diesen Schritt für beide Server durchführen müssen. Dann clicken wieder wieder fröhlich weiter bis zum Feld "Features" und setzen den Haken bei Failover Clustering (einschließlich Management Tools) und clicken weiter bis einschließlich installieren.
    • ODER (m.E. schneller) mit Powershell: RPD zu (je)dem remote-Server, in der cmd schnell zur powershell wechseln und dort eingeben:
      Code:
      Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools
    • Reboot nicht zwingend erforderlich.


    2. Hyper-V Switches überprüfen/vorbereiten

    Damit unser Failover funktioniert, müssen wir auf beiden Hyper-V Servern die richtigen Rahmenbedingungen schaffen. Konkret heisst das, die identischen virtuellen Switches auf beiden Hosts erstellen. Identisch heisst hier, gleicher Name (reicht).

    3. Cluster bauen

    Jetzt wird's ernst. Wir gehen also wieder an einen unserer Server (z.B. per RDP) und dort in eine Admin-Shell mit dem Admin-Account, der auf allen hyper-V Hosts mit identischem Name/Passwort vorhanden ist:

    Code:
    PS: C:\Users\Administrator>new-cluster -name HowToFailO -node HYPVCORE.howtofailo.priv,HYPVGUI.howtofailo.priv -AdministrativeAccessPoint DNS -staticaddress 192.168.178.245/24
    Hinweis:: der Parameter -staticaddress gefolgt von der IP-Adresse/Subnetzmaske ist nicht erforderlich, wenn ihr DHCP verwendet. Da ich aber (beiden) Servern feste Adressen gegeben habe, erwartet der Cluster-Befehl auch für den Cluster eine feste IP, die Ihr eben mit diesem Parameter setzt.
    Solltet ihre keine weiteren Festplatten zusätzlich zu den Systemplatten (C in Euren Hyper-V Servern haben, werdet Ihr voraussichtlich mit einer Fehlermeldung beglückt:



    Konkret geht es darum, dass dem Cluster noch ein (gemeinsamer) Speicherplatz fehlt, sowohl zum Ablegen der HAVMs, als auch betreffend die sogenannte "Witness Disk", wie sich aus dem automatisch generierten Report erkennen lässt:



    Dazu kommen wir aber gleich noch.

    4. Failover Cluster Manager

    Nach dem Microsoft Blog zum Thema ist es (angeblich) nicht möglich, ein non-domain/workgroup-Cluster über das GUI zu administrieren:

    Management operations may only be performed using Microsoft PowerShell©. The Failover Cluster Manager snap-in tool is not supported in these configurations.
    Das galt vielleicht noch für die TP3, bei der TP4 habe ich festgestellt, dass das (inzwischen) so nicht mehr ganz richtig ist. Insbesondere Rollen und Ressourcen lassen sich dem Cluster zuordnen, auch Nodes entfernen oder auch der Cluster zerstören. Nur bis zur bzw. einschließlich der erstmaligen Erstellung muss man die Powershell bemühen.

    Wir öffnen also den Failover Cluster Manager, indem wir im Server Manager oben rechts auf "Tools" clicken und darin auf "Failover Cluster Manager". Dann clicken wir darin rechts auf "Connect to cluster..." und geben darin entweder die IP unseres Clusters ein oder wir lassen - wenn wir uns auf einem Server befinden, der Mitglied des Clusters ist - einfach "<Cluster on this server...>" stehen.

    Hinweis: Unser Cluster erscheint über (mindestens) eine eigene IP im Netzwerk, die wir im Befehl oben mit "-staticaddress" angegeben haben.
    Nach erfolgreicher Verbindung begrüßt uns dann der Failover Cluster Manager mit der Übersichtsseite zu den wichtigen Informationen. Im nachfolgenden Screenshot habe ich links die Reiter mal ausgeklappt:



    TEIL 5: GEMEINSAMEN STORAGE EINRICHTEN

    0. iSCSI Share

    Wie oben in der Einführung bereits schon etwas detaillierter ausgeführt, brauchen wir für unsere HAVMs irgendwo einen gemeinsamen Speicherplatz , auf den sämtliche Cluster-Mitglieder zugreifen können. Wie gesagt setze ich hierzu ein irgendwo in Eurem Netzwerk bereits eingerichtetes "iSCSI-Share" voraus. Das sollten auch die verschiedenen Fertig-NAS-Lösungen hinbekommen, hier ein Beispiel mit QNAP:



    1. iSCSI-Share für Server 1 (Beispiel mit GUI) verfügbar machen

    Um unsere iSCSI-Share nutzbar zu machen, starten wir auf dem ersten Hyper-V Server (mit GUI) den iscsi-Initiator (Start-->iscsi eintippen und obersten Eintrag in der Liste wählen; Alternativ über den Server Manager-->Tools-->iSCSI Initiator oder in der Powershell: iscsicpl.exe - brauchen wir spätestens für den non-GUI-Server). Darin bestätigen wir, dass der iSCSI-Dienst jetzt und standardmäßig gestartet werden soll und geben im Idealfall nur die IP-Adresse des Servers ein, auf dem Ihr die iSCSI-Freigabe eingerichtet habt.

    Nun wechseln wir in die Datenträgerverwaltung (z.B. rechtsclick auf start-->"Disk Management"), stellen die dort auftauchende Disk "online" (rechtsclick), erstellen eine neue Partition und formatieren sie mit NTFS. Laufwerksbuchstaben merken! In meinem Beispiel habe ich mein 200GB-iSCSI-Share als Laufwerk E: eingebunden und mit NTFS formatiert:



    Wer hierzu konkretere Hilfestellung wünscht, findet zum Thema iSCSI in Windows zahlreiche Guides, zum Beispiel hier (englisch).

    Das Wichtige folgt nun: wir nehmen diese Disk nun im ersten Server wieder offline und fügen sie auf die gleiche Weise im zweiten Node hinzu. Falls dort ein anderer Laufwerksbuchstabe vergeben wird, müsst Ihr diesen auf den gleichen Laufwerksbuchstaben wie im ersten Server ändern!

    2. iSCSI-Share für Server 2 (Beispiel ohne GUI) verfügbar machen

    Also wechseln wir zu unserem zweiten Hyper-V Server (hier: der non-GUI-Server), geben dort in der cmd-/Powershell iscsicpl.exe ein und lassen auch dort den Service starten. Dummerweise haben wir für die Datenträgerverwaltung hier kein GUI. Da die Einrichtung der GUI-Remoteverwaltung ein eigenes Kapital füllen kann (und hoffentlich bald auch wird), bemühen wir für diese Zwecke das gute alte "DISKPART":

    a) in cmd "diskpart" eingeben
    b) "list disk" eingeben und die richtige Ziffer für die Freigabe herausfinden (erkennbar z.B. an der Größe) und am Status "offline"
    c) "select disk 1" (bzw. richtige Ziffer bei Euch - WICHTIG, sonst macht ihr ggf. die Installation/Daten unbrauchbar)
    d) "online disk"
    e) "list volume" --> Laufwerksbuchstaben eurer iSCSI-Share prüfen!

    Falls Schritt e) einen abweichenden Laufwerksbuchstaben zeigt:

    e.1) "select volume 3"
    e.2) "assign letter=e" (bzw. den Buchstaben von eurem ersten Server)
    e.3) "list volume" (zur Kontrolle )

    f) "offline disk"
    g) "exit"

    Das sieht dann in der shell etwa so aus (eingaben fett+unterstrichen):

    Code:
    C:\Users\Administrator>diskpart
    
    Microsoft DiskPart version 10.0.10586
    
    Copyright (C) 1999-2013 Microsoft Corporation.
    On computer: HYPVCORE
    
    DISKPART> list disk
    
      Disk ###  Status         Size     Free     Dyn  Gpt
      --------  -------------  -------  -------  ---  ---
      Disk 0    Online           20 GB      0 B
      Disk 1    Offline         200 GB      0 B        *
    
    DISKPART> select disk 1
    
    Disk 1 is now the selected disk.
    
    DISKPART> online disk
    
    DiskPart successfully onlined the selected disk.
    
    DISKPART> list volume
    
      Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
      ----------  ---  -----------  -----  ----------  -------  ---------  --------
      Volume 0     D                       DVD-ROM         0 B  No Media
      Volume 1         System Rese  NTFS   Partition    500 MB  Healthy    System
      Volume 2     C                NTFS   Partition     19 GB  Healthy    Boot
      Volume 3     F   iSCSI        NTFS   Partition    199 GB  Healthy
    
    DISKPART> select volume 3
    
    Volume 3 is the selected volume.
    
    DISKPART> assign letter=e
    
    DiskPart successfully assigned the drive letter or mount point.
    
    DISKPART> list volume
    
      Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
      ----------  ---  -----------  -----  ----------  -------  ---------  --------
      Volume 0     D                       DVD-ROM         0 B  No Media
      Volume 1         System Rese  NTFS   Partition    500 MB  Healthy    System
      Volume 2     C                NTFS   Partition     19 GB  Healthy    Boot
    * Volume 3     E   iSCSI        NTFS   Partition    199 GB  Healthy
    
    DISKPART> offline disk
    
    DiskPart successfully offlined the selected disk.
    
    DISKPART> exit
    
    Leaving DiskPart...
    
    C:\Users\Administrator>
    (Eine englische Schritt-für-Schritt Anleitung, allerdings nur für GUI, findet sich zum Beispiel hier.)

    3. iSCSI-Share dem Cluster zur Verfügung stellen

    Bis jetzt haben wir nur ein iSCSI-Share, das "zufällig" auf zwei Servern eingebunden ist. Eigentlich soll man sowas ja anscheinend eher nicht machen, aber im Cluster gelten diesbezüglich andere Regeln, denn ohne geht es nicht...

    Damit wir nun also echte HAVMs erstellen können, die auch den "Tod" eines kompletten physischen Hyper-V Servers überleben, brauchen wir nun den gemeinsamen Speicherplatz, der allen Servern im Cluster zur Verfügung steht. Microsoft nennt das dann "Cluster Shared Volumes" und beschreibt das - wie ich finde recht eingängig - so:

    Quelle 1:

    CSV can enhance the availability and manageability of virtual machines by enabling multiple nodes to concurrently access a single shared storage volume. For example, on a failover cluster that uses CSV, multiple clustered virtual machines that are distributed across multiple cluster nodes can all access their virtual hard disk files at the same time, even if the files are on a single disk (LUN) in the storage. This means that the clustered virtual machines can fail over independently of one another, even if they use only a single LUN. CSV also support live migration of a Hyper-V virtual machine between nodes in a failover cluster.
    Quelle 2:

    Cluster Shared Volumes (CSV) enable multiple nodes in a failover cluster to simultaneously have read-write access to the same LUN (disk) that is provisioned as an NTFS volume. (In Windows Server 2012 R2, the disk can be provisioned as NTFS or Resilient File System (ReFS).) With CSV, clustered roles can fail over quickly from one node to another node without requiring a change in drive ownership, or dismounting and remounting a volume. CSV also help simplify the management of a potentially large number of LUNs in a failover cluster.
    Immerhin können wir jetzt zurück in die GUI-Version und zwar wieder in den Failover Cluster Manager. Dort machen wir einen rechtsclick auf "Disk", wählen "add Disk" und bekommen netterweise direkt unsere neue "DISK" (in Form der iSCSI-Freigabe) präsentiert:



    4. iSCSI-Share als Cluster Shared Volume definieren

    Nun noch schnell auf der Disk ein Cluster Shared Volume einrichten, also rechtsclick auf die neue Disk, darin "Add to Cluster Shared Volumes":



    ...und wir haben unseren "gemeinsamen Speicherplatz" erfolgreich eingerichtet.

    Hinweis: Obwohl wir die "DISK" offline genommen haben, ist diese jetzt übrigens auf beiden Servern lokal verfügbar unter "c:\clusterstorage\volume1\":



    Wenn wir nun auf Server 1 eine Datei dorthin kopieren, sieht auch sofort Server 2 - genau das was wir wollen, falls eben ein Server ausfällt.
    TEIL 6: HAVM

    Im Prinzip funktioniert das Anlegen einer hoch verfügbaren virtuellen Maschine hier genauso wie im HowTo1 für den Hyper-V Manager beschrieben. Es gibt nur drei Besonderheiten am Beispiel einer "frischen" VM:

    1. Wizard im Failover Cluster Manager starten

    Wir starten das Ganze am besten über den Failover Cluster Manager (nicht im Hyper-V Manager) durch einen rechtsclick auf "Roles", wählen "Virtual Maschine" und "New Virtual Maschine" und wählen einen Server für die Erstellung aus (ist m.W. eigentlich egal welchen).



    2. Cluster-Storage als Speicherplatz für die VM

    Beim Speicherplatz für die VM dürfen wir nicht die Standardeinstellungen verwenden, sondern müssen die VM in unserem Cluster-Speicherplatz ablegen und den Platz manuell auswählen ("Browse"):



    3. Cluster-Storage als Speicherplatz auch für die VHD

    Das gleiche gilt natürlich auch für die dazugehörige VHD, allerdings ist der Wizard so schlau, hier jetzt gleich das richtige Plätzchen vorzuschlagen:



    4. Success!

    Am Ende werden wir dann begrüßt von der begehrten Meldung, dass wir erfolgreich eine "HIGH AVAILABILITY" VM erstellt haben:



    5. HAVM managen

    HAVMs verwaltet Ihr am besten über den Failover-Cluster Manager. Wenn Ihr unter "role" auf Eure VM clickt, seht Ihr rechts unten das aus dem Hyper-V Manager bekannte Menü, allerdings inbs. ergänzt um den spannenden Eintrag "Move":



    Im Prinzip ist m.E. alles Weitere selbsterklärend, bis auf:

    Hinweis: in einem "workgroup" cluster funktioniert Live Migration NICHT. Ihr könnt also die VM nur in Form der Quick Migration hin-und-her schubsen. Der wesentliche Unterscheid besteht darin, dass die VM vom Cluster während dieses Vorgangs automatisch quasi auf Node 1 in den Ruhezustand geschickt, und auf Node 2 dann wieder aufgeweckt wird.
    Viel Spaß mit Eurem Cluster!
    Geändert von besterino (17.07.16 um 00:25 Uhr)
    Spoiler: Anzeigen

  8. #6
    Hauptgefreiter Avatar von Ghroul
    Registriert seit
    30.07.2013
    Ort
    \\DE\NRW\Bocholt
    Beiträge
    143


    • Systeminfo
      • Motherboard:
      • MSI X299 M7
      • CPU:
      • Intel 7820X@4,5GHz
      • Kühlung:
      • watercooled
      • Gehäuse:
      • Tt Core X5 Riing Edition
      • RAM:
      • 16GB Corsair LPX 3733
      • Grafik:
      • EVGA 1070 FTW
      • Storage:
      • 500GB Samsung 970
      • Monitor:
      • LG 27UK850-W 4k
      • Notebook:
      • Fujitsu U748
      • Handy:
      • OnePlus 5

    Standard

    Moin moin,

    beruflich bin ich Herr über mehrere Hyper-V Failover Cluster und Citrix Cluster mit zusammen ca. 400 virtuellen Clients.

    Ein paar kleine Tipps am Rande:
    • RAM: für mehr Performance und gerade bei Failover-Cluster-Betrieb Speicher fest zuweisen
    • VM Speicherort 1: der Speicherort für die virtuelle Platte, Konfiguration und Snapshots von C.\... auf eine eigene HDD (bestenfalls SSD) legen
    • VM Speicherort 2: beim Erstellen einer neuen VM das Häkchen bei „Virtuellen Computer an einem anderen Speicherort erstellen“ setzen, dadurch legt Hyper-V einen eigenen Ordner für alle VM-Daten an --> bessere Übersicht
    • Überprovisionierung: es ist möglich unter Hyper-V mehr virtuelle Ressourcen (CPU Kerne / RAM) zur Verfügung zu stellen wie Hardware vorhanden ist.
      RAM sollte nicht mehr als vorhanden vergeben werden sogar abzüglich Host-Verbrauch
      CPU-Kerne können großzügig überprovisioniert werden, als kleine Faustregel dient hier 12:1 bei normalen Anwendungen in den Clients, laufen natürlich viele CPU-intensive Prozesse verringert sich das natürlich.
    • Netzwerk: „highly recommended“ eine extra Netzwerkkarte für den V-Switch. In einem Failover Cluster eine Netzwerkkarte für Management, eine für Live Migration und am besten zwei weitere für die Storageanbindung
    • CPU Kompatibilität: solltet ihr auf die Idee kommen einen Failover Cluster mit unterschiedlichen CPUs aufzubauen, solltet ihr daran denke bei allen VMs den haken bei „Prozessor\Kompatibilität“ „Zu einem physischen Computer mit einer anderen Prozessor Version migrieren“ zu setzen, sonst läuft die VM nicht auf dem jeweils anderen Node.


    Mehr fällt mir gerade auf die Schnelle nicht ein.

    edit:
    wo ich gerade sehe Linux
    • Linux 1: bei Linux VMs immer den sichern Start deaktivieren sobald Gen2 unterstützt wird.
    • Linux 2: bei Linux VMs immer eine feste MAC vergeben
    Geändert von Ghroul (01.04.16 um 11:56 Uhr)
    Gaming-PC: Win10 | i7 7820k@4,5GHz WaKü | 16GB LPX 3733 | 500GB Samsung 970
    24/7-Server: Win2016 Datacenter | Xeon E3 1230 V5 | ASRockRack E3C236DU4 | 32GB DDR4 ECC | 3x4TB 24/7 + 128GB SSD System + 512GB SSD Hyper-V
    Unterwegs: OnePlus 5 | Huawei M3 | Fujitsu U748

    Verkaufe: Verkaufsthread

  9. #7
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    Cool, merci!

    In der Tat wird's beim Failover-Cluster mehr ans Eingemachte gehen. Da graut mit noch etwas vor dem Szenario "Ohne Domäne" als HowTo. Ich habe mir ja schon einen Zacken aus der Krone gebrochen, für die aktuelle TP4 mal herauszufinden, was für das Remote-Management - und nur speziell für den Hyper-V Manager - an Einstellungen nötig ist, wenn man eben keine Domäne betreibt. Die ganzen alten HowTos sind größtenteils obsolet (siehe Hinweise am Ende von HowTo 2).

    Im professionellen Umfeld wird's das ja wohl nie geben, zu Hause würde ich gerne auf den ADDS-Server verzichten können. (Ich hab zurzeit extra zu Hause eine Domäne laufen, nur weil das Management dann echt viel einfacher ist).
    Spoiler: Anzeigen

  10. #8
    Leutnant zur See Avatar von teqqy
    Registriert seit
    30.07.2012
    Ort
    Rheinhessen
    Beiträge
    1.157


    • Systeminfo
      • Notebook:
      • MacBook Air
      • Handy:
      • iPhone 5 16 GB

    Standard

    Noch eine kleine Ergänzung:
    In Hyper-V werden im Gegensatz zu ESXi oder Proxmox keine wirklichen Kerne an die VM vergeben sondern Arbeitsprozesse (Threads). Aus diesem Grund kann eine so starke Überprovisionierung stattfinden.

    Festen RAM hat sich aus meinen Kundenerfahrungen nur dann als Vorteilhaft erwiesen wenn es wirklich um high performance geht. SQL Cluster etc. Im Homebereich wird sicherlich die allerwenigstens in diesen Bereich kommen. Daher kann man daheim ohne Probleme mit dynamischen RAM arbeiten.
    Ganz wichtig ist noch, dass man alle neuen Windows Systeme als Gen 2 VM anlegen sollte! Der Performanceunterschied ist nicht nur mess- sondern auch spürbar! Derzeit können keine Linux Maschinen out of the Box Gen 2. Nur mittels Abstellung des Secure Boots. Soll sich mit 2016 ändern.

    Highly recommendet von MS (im Geschäftsumfeld sogar ein Supportkriterium): KEINE weiteren Rollen auf dem HV laufen lassen. Ein Backup Programm wird noch Geduldet. Aber kein Domain Controller, DNS oder sonst irgendwas.

    Da du auch viel auf 2016 eingehst und viele hier aus irgendwelchen Quellen immer eine Datacenter Lizenz haben: Mit dieser ist es möglich über Storage Spaces Direct (nicht mit den normalen SS verwechseln!!!) ein Cluster ohne zentralen Storage aufzubauen. MS empfiehlt hier aber klar mind 10 GBe als Replikationsnetzwerk.
    Virtualisierung: SuperMicro X11SSL-cF | E3-1220v5 | 32 GB DDR ECC | 2 x 80 GB Intel S3500 | 1 x Samsung Evo 860 NVMe 500 GB | Proxmox 5.3
    Firewall: Ubiquiti USG
    Storage: Synology DS916+ (2 GB) | 2 x 4 TB + 2 x 2 TB SHR (für Bewegdaten) || Synology DS1513+ | 5 x 3 TB SHR (für Backups)
    USV: APC 900 VA
    Netzwerk: Ubiquiti US‑16‑150W | Ubiquiti US-8-50W | 2 x Ubiquiti UAP‑AC‑LITE
    Social: Blog | YouTube Kanal rund um Homelabs

  11. #9
    Oberleutnant zur See
    Registriert seit
    09.02.2012
    Ort
    Kleinniedesheim
    Beiträge
    1.364


    • Systeminfo
      • Motherboard:
      • Asrock Fatal1ty H97 Performance
      • CPU:
      • Xeon E3-1231v3
      • Systemname:
      • Gondor
      • Kühlung:
      • HR-02 Macho
      • Gehäuse:
      • Nanoxia Deep Silence 1
      • RAM:
      • 16 GB Hyper-X
      • Grafik:
      • ASUS Radeon R9 290
      • Storage:
      • Samsung 830 120 GB, Samsung 860 EVO 1 TB
      • Monitor:
      • Dell U2312HM
      • Netzwerk:
      • HP 1920-24G
      • Sound:
      • Onboard
      • Netzteil:
      • be quiet! SP 10-CM 500W
      • Betriebssystem:
      • Windows 10 Pro
      • Notebook:
      • Dell Latitude E5520 i3 4GB | Win 10 Pro
      • Handy:
      • Honor 7

    Standard

    Naja Storage Spaces Direct ist sicher nichts für Zuhause da benötigt man 3-4 Datacenter Lizenzen
    Homelab: ESXi 6.5 / Hyper-V 2016
    Server:
    HP ML310e Gen8|32GB ECC|2x500GB,2x2TB|
    SM A1SRM-2558F|16GB ECC|6x2TB|
    HP DL320e Gen8|16GB ECC|4x500GB
    Backup: HP N40L4GB ECC|2x2TB,2x1TB
    Mobil: DELL E5520 i3| Win 10 Pro

  12. #10
    Leutnant zur See Avatar von teqqy
    Registriert seit
    30.07.2012
    Ort
    Rheinhessen
    Beiträge
    1.157


    • Systeminfo
      • Notebook:
      • MacBook Air
      • Handy:
      • iPhone 5 16 GB

    Standard

    Wer sich für daheim schon eine leisten kann, kann sich auch 3 - 4 leisten. Via MSDN oder MSDNAA (Dreamspark) wäre es ja auch egal.
    Virtualisierung: SuperMicro X11SSL-cF | E3-1220v5 | 32 GB DDR ECC | 2 x 80 GB Intel S3500 | 1 x Samsung Evo 860 NVMe 500 GB | Proxmox 5.3
    Firewall: Ubiquiti USG
    Storage: Synology DS916+ (2 GB) | 2 x 4 TB + 2 x 2 TB SHR (für Bewegdaten) || Synology DS1513+ | 5 x 3 TB SHR (für Backups)
    USV: APC 900 VA
    Netzwerk: Ubiquiti US‑16‑150W | Ubiquiti US-8-50W | 2 x Ubiquiti UAP‑AC‑LITE
    Social: Blog | YouTube Kanal rund um Homelabs

  13. #11
    Hauptgefreiter Avatar von Ghroul
    Registriert seit
    30.07.2013
    Ort
    \\DE\NRW\Bocholt
    Beiträge
    143


    • Systeminfo
      • Motherboard:
      • MSI X299 M7
      • CPU:
      • Intel 7820X@4,5GHz
      • Kühlung:
      • watercooled
      • Gehäuse:
      • Tt Core X5 Riing Edition
      • RAM:
      • 16GB Corsair LPX 3733
      • Grafik:
      • EVGA 1070 FTW
      • Storage:
      • 500GB Samsung 970
      • Monitor:
      • LG 27UK850-W 4k
      • Notebook:
      • Fujitsu U748
      • Handy:
      • OnePlus 5

    Standard

    Zitat Zitat von teqqy Beitrag anzeigen
    Wer sich für daheim schon eine leisten kann, kann sich auch 3 - 4 leisten. Via MSDN oder MSDNAA (Dreamspark) wäre es ja auch egal.
    nur dei passende Hardware ...
    Gaming-PC: Win10 | i7 7820k@4,5GHz WaKü | 16GB LPX 3733 | 500GB Samsung 970
    24/7-Server: Win2016 Datacenter | Xeon E3 1230 V5 | ASRockRack E3C236DU4 | 32GB DDR4 ECC | 3x4TB 24/7 + 128GB SSD System + 512GB SSD Hyper-V
    Unterwegs: OnePlus 5 | Huawei M3 | Fujitsu U748

    Verkaufe: Verkaufsthread

  14. #12
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    Mein iSCSI Hyper-V Cluster-Storage liegt auf einem Solaris ZFS-System....

    Für @home reichen zwei Kisten als "private Datacenter", eine Dritte dann nach Belieben (Beispiel unten):

    1. "bare metal" ESXi-Hypervisor, mit Solaris Storage VM, nested Hyper-V als "failover"-maschine und wer mag noch Management Windows Desktop VM

    2. "bare metal" Hyper-V-Hypervisor als Main-Hyper-V Box.

    3. (OPTIONAL) "bare metal" Solaris als Storage-Backup/Replikation der StorageVM auf Box 1.

    Damit kann man dann "kritische" kleine VMs, ziemlich ausfallsicher gestalten, und das kostenlos (bis halt auf mindestens eine Win Desktop-Lizenz).

    Ich nutz' das so primär für meinen VPN-Server. Feste IP, lässt sich problemlos manuell hin-und-her schubsen.
    Spoiler: Anzeigen

  15. #13
    Oberleutnant zur See
    Registriert seit
    09.02.2012
    Ort
    Kleinniedesheim
    Beiträge
    1.364


    • Systeminfo
      • Motherboard:
      • Asrock Fatal1ty H97 Performance
      • CPU:
      • Xeon E3-1231v3
      • Systemname:
      • Gondor
      • Kühlung:
      • HR-02 Macho
      • Gehäuse:
      • Nanoxia Deep Silence 1
      • RAM:
      • 16 GB Hyper-X
      • Grafik:
      • ASUS Radeon R9 290
      • Storage:
      • Samsung 830 120 GB, Samsung 860 EVO 1 TB
      • Monitor:
      • Dell U2312HM
      • Netzwerk:
      • HP 1920-24G
      • Sound:
      • Onboard
      • Netzteil:
      • be quiet! SP 10-CM 500W
      • Betriebssystem:
      • Windows 10 Pro
      • Notebook:
      • Dell Latitude E5520 i3 4GB | Win 10 Pro
      • Handy:
      • Honor 7

    Standard

    Hier mal eine Artikel auf Deutsch zu dem Thema Discrete Device Assignment (Passtrough in Hyper-V 2016)

    Hyper-V 2016: Discrete Device Assignment | faq-o-matic.net

    Ja dein Konstrukt habe ich auch schon bewundert Aber ich werde in meiner Umgebung mal Refs v2 testen soll ja deutlich schneller sein als NTFS mit VHDX Dateien.
    Geändert von LichtiF (01.04.16 um 15:33 Uhr)
    Homelab: ESXi 6.5 / Hyper-V 2016
    Server:
    HP ML310e Gen8|32GB ECC|2x500GB,2x2TB|
    SM A1SRM-2558F|16GB ECC|6x2TB|
    HP DL320e Gen8|16GB ECC|4x500GB
    Backup: HP N40L4GB ECC|2x2TB,2x1TB
    Mobil: DELL E5520 i3| Win 10 Pro

  16. #14
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    Zitat Zitat von Ghroul Beitrag anzeigen
    nur dei passende Hardware ...
    Ich bekomm' trotz 10GBe nichtmal die "highly recommended" Netzwerk-Hardware für einen pupsigen Failover Cluster in den Hosts zusammen und muss auch wegen unterschiedlicher CPU-Versionen die Prozessor-Kompatibilität in den HA-VMs anwerfen. Home-use eben. =)
    Spoiler: Anzeigen

  17. #15
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    @LichtIF: in einer der MS-Blog-Quellen von Deinem Link ist ein schöner, wie ich finde zitierwürdiger Satz zum Thema GPU-Passthrough:

    ...So the GPU will tend to work if the machine’s BIOS has already set up the GPU optimally, and this limits the machines that are likely to work well with GPUs. Basically, these are servers which were built for hosting GPUs. They’ll be the sorts of things that the salesman wants to push on you when you use words like “desktop virtualization” and “rendering.” When I look at a server, I can tell whether it was designed for GPU work instantly, because it has lots of long (x16) PCI Express slots, really big power supplies and fans that make a spooky howling sound.
    Genau das was wir zu Hause haben.
    Spoiler: Anzeigen

  18. #16
    Hauptgefreiter
    Registriert seit
    20.04.2012
    Beiträge
    151


    Standard

    Bei Thema GPU habe ich mir schon zweimal eingebildet, mit Hobby Hardware Spaß zu haben - war aber rausgeschmissenes Geld.

    Unter Server 2012 mit einer GTX680 und Windows 7 Clients kam so einigermassen Desktop Experience auf, allerdings mit gewissen Beschränkungen.
    Letztes JAhr habe ich dann mal auf GTX970 und R2 umgestellt: leider läuft das schlechter als vorher. Mit RemoteFX unter RDP ist die Ergebniss ruckeliger als ohne, ausserdem treten ständig Bildstörungen auf, die ich noch nicht wegbekommen habe.

    Kennt jemand dieses Geflimmer, wenn immer man sich etwas auf dem Desktop bewegt, z.B. scrollt....?

  19. #17
    Leutnant zur See Avatar von teqqy
    Registriert seit
    30.07.2012
    Ort
    Rheinhessen
    Beiträge
    1.157


    • Systeminfo
      • Notebook:
      • MacBook Air
      • Handy:
      • iPhone 5 16 GB

    Standard

    Werden die Karten denn überhaupt korrekt unterstützt? Ich meine mal gelesen zu haben, dass von NVidia nur die Quadro Karten (wg. Treiber) unterstützt werden.

    Geflimmer hat sonst oft was mit der Netzwerkanbindung zu tun. Ich gehe aber mal davon aus, dass du es via GBit LAN getestet hast?
    Virtualisierung: SuperMicro X11SSL-cF | E3-1220v5 | 32 GB DDR ECC | 2 x 80 GB Intel S3500 | 1 x Samsung Evo 860 NVMe 500 GB | Proxmox 5.3
    Firewall: Ubiquiti USG
    Storage: Synology DS916+ (2 GB) | 2 x 4 TB + 2 x 2 TB SHR (für Bewegdaten) || Synology DS1513+ | 5 x 3 TB SHR (für Backups)
    USV: APC 900 VA
    Netzwerk: Ubiquiti US‑16‑150W | Ubiquiti US-8-50W | 2 x Ubiquiti UAP‑AC‑LITE
    Social: Blog | YouTube Kanal rund um Homelabs

  20. #18
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    Ich hab es vorhin nicht einmal auf die Schnelle hinzubekommen, dass Script für den Passthrough-Kompatibilitätstest zu starten...

  21. #19
    Hauptgefreiter Avatar von Ghroul
    Registriert seit
    30.07.2013
    Ort
    \\DE\NRW\Bocholt
    Beiträge
    143


    • Systeminfo
      • Motherboard:
      • MSI X299 M7
      • CPU:
      • Intel 7820X@4,5GHz
      • Kühlung:
      • watercooled
      • Gehäuse:
      • Tt Core X5 Riing Edition
      • RAM:
      • 16GB Corsair LPX 3733
      • Grafik:
      • EVGA 1070 FTW
      • Storage:
      • 500GB Samsung 970
      • Monitor:
      • LG 27UK850-W 4k
      • Notebook:
      • Fujitsu U748
      • Handy:
      • OnePlus 5

    Standard

    Zitat Zitat von besterino Beitrag anzeigen
    @LichtIF: in einer der MS-Blog-Quellen von Deinem Link ist ein schöner, wie ich finde zitierwürdiger Satz zum Thema GPU-Passthrough:

    Genau das was wir zu Hause haben.
    Hihi, jo, wenn ich so bei uns durch die Rechenzentren gehe frage ich mich auch immer, ob die Berufsgenossenschaft nicht irgendwann auf den Trichter kommt man muss Ohrschützer tragen wenn man sich länger als 10 Minuten dort aufhält. Wir haben noch ein paar ältere, vollbestückte IBM Bladecenter im Einsatz, das ist echt ein startender Hubschrauber
    Gaming-PC: Win10 | i7 7820k@4,5GHz WaKü | 16GB LPX 3733 | 500GB Samsung 970
    24/7-Server: Win2016 Datacenter | Xeon E3 1230 V5 | ASRockRack E3C236DU4 | 32GB DDR4 ECC | 3x4TB 24/7 + 128GB SSD System + 512GB SSD Hyper-V
    Unterwegs: OnePlus 5 | Huawei M3 | Fujitsu U748

    Verkaufe: Verkaufsthread

  22. #20
    Hauptgefreiter
    Registriert seit
    20.04.2012
    Beiträge
    151


    Standard

    Zitat Zitat von teqqy Beitrag anzeigen
    Werden die Karten denn überhaupt korrekt unterstützt? Ich meine mal gelesen zu haben, dass von NVidia nur die Quadro Karten (wg. Treiber) unterstützt werden.

    Geflimmer hat sonst oft was mit der Netzwerkanbindung zu tun. Ich gehe aber mal davon aus, dass du es via GBit LAN getestet hast?
    Mit Geflimmer meine ich, dass der der Bildschirminhalt flackernd flächig durch unregelmäßige Muster / Pixelsuppe - in Komplementärfarben überlagert wird.

  23. #21
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    Ich baue gerade am HowTo 5 - Failover Cluster ohne Domäne. Da das doch was länger wird, hab' ich mal den ersten Teil schon einmal "online" gestellt (oben, 4. Posting). Hoffe es ist ok, wenn das noch "in Bearbeitung / Work In Progress" ist...

    Der größte Kack ist echt, dass man (bisher) nirgends ein HowTo findet, das einen von Anfang (also von der frischen Installation) bis Ende (laufende HAVM im Cluster) führt. Man muss sich das total zusammenstückeln und immer fehlt irgendwas.

    Wahrscheinlich muss ich das auch noch etwas besser durchgliedern und Einrichtung des Clusters von der Verwaltung durch Desktop/Management-VM trennen. Dann wird es vielleicht noch etwas übersichtlicher. Naja, erstmal die Infos zusammentragen/-stellen, dann kann man immer noch Finetuning betreiben.
    Spoiler: Anzeigen

  24. #22
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    So, hab das HowTo mal etwas entschlackt. Erst einmal "Cluster bauen", Verwaltung von einer Management-Box/VM mach' ich später mal.
    Spoiler: Anzeigen

  25. #23
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    HowTo 5: Failover-Cluster (ohne gemeinsame Domäne) ist KOMPLETT.

    Damit sollte ein Interessierter jedenfalls die Grundlagen zusammen haben, um sich sein Cluster auf Basis der 2016er TP4 zu bauen.

    Nur zur Klarstellung: das hier Beschriebene ist null supportet von Microsoft und schlägt sämtliche Empfehlungen (zugunsten der schnellsten/praktikabelsten Zielerreichung) in den Wind!
    Um einen Cluster nur mit "Core" Servern zu bauen, sollten eigentlich nur einige DISKPART Befehle (für die erste Einrichtung des iSCSI-Share) fehlen. Die "Krönung" ist dann noch, die beiden Server von einer 3. Box (Desktop/VM) aus mit den RSAT-Tools steuern zu können.

    Fragen / Anmerkungen (Kritik, aber noch lieber Verbesserungsvorschläge) bitte gerne!
    Geändert von besterino (06.04.16 um 20:57 Uhr)
    Spoiler: Anzeigen

  26. #24
    Hauptgefreiter Avatar von Ghroul
    Registriert seit
    30.07.2013
    Ort
    \\DE\NRW\Bocholt
    Beiträge
    143


    • Systeminfo
      • Motherboard:
      • MSI X299 M7
      • CPU:
      • Intel 7820X@4,5GHz
      • Kühlung:
      • watercooled
      • Gehäuse:
      • Tt Core X5 Riing Edition
      • RAM:
      • 16GB Corsair LPX 3733
      • Grafik:
      • EVGA 1070 FTW
      • Storage:
      • 500GB Samsung 970
      • Monitor:
      • LG 27UK850-W 4k
      • Notebook:
      • Fujitsu U748
      • Handy:
      • OnePlus 5

    Standard

    Ich würde SMB3 dem iSCSI vorziehen, ist einfacher einzurichten unter Windows, wenn man Windows Server 2k12R2 oder 2k16 verwendet und bietet einige Vorteile wenn man in der Windowswelt bleibt.
    Gaming-PC: Win10 | i7 7820k@4,5GHz WaKü | 16GB LPX 3733 | 500GB Samsung 970
    24/7-Server: Win2016 Datacenter | Xeon E3 1230 V5 | ASRockRack E3C236DU4 | 32GB DDR4 ECC | 3x4TB 24/7 + 128GB SSD System + 512GB SSD Hyper-V
    Unterwegs: OnePlus 5 | Huawei M3 | Fujitsu U748

    Verkaufe: Verkaufsthread

  27. #25
    Flottillenadmiral
    Registriert seit
    31.05.2010
    Ort
    Wo mein Daddel-PC steht
    Beiträge
    4.368
    Themenstarter


    • Systeminfo
      • Motherboard:
      • AsrockRack X399D8A-2T
      • CPU:
      • 1920X
      • Systemname:
      • 1920X
      • Kühlung:
      • 2xMoRa3 + Watercool GPU/CPU
      • Gehäuse:
      • Thermaltake Core P7 TG
      • RAM:
      • 64GB DDR4
      • Grafik:
      • Nvidia RTX 2080Ti FE
      • Storage:
      • SM961 1TB, 840 EVO 1TB, 2x 860 EVO 1TB, 660p 2TB
      • Monitor:
      • AW5520QF OLED
      • Netzwerk:
      • 10Gbit, 100Gbit (Connectx-4)
      • Sound:
      • Chord Mojo / AKG K812 Pro
      • Netzteil:
      • Seasonic Prime Ultra Titanium
      • Betriebssystem:
      • ESXI 6.7U3 mit Windows10-VM
      • Sonstiges:
      • Gaming in VM! :D
      • Notebook:
      • Zu viele
      • Photoequipment:
      • Unbenutzt
      • Handy:
      • Zu viel benutzt

    Standard

    Das Problem ist halt, dass man dann dafür eine dritte Windowsbox braucht mit den entsprechenden Lizenzen. Weiß jemand zufällig, welche Features mit CORE bzw. HYPER-V Version "lizenzkostenfrei" aktiviert werden dürfen?

    Bilde mir ein, mal irgendwo gelesen zu haben, dass Fileserverdienste gingen, bin aber nicht mehr sicher. Hinzu kommt, dass sich ja des Lizenzmodell mit 2016 auch wieder ändert...

Seite 1 von 21 1 2 3 4 5 11 ... LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •