none
Windows Server 2016 Standard - Lizenzierung HyperV RRS feed

  • Frage

  • Hallo,

    ich werde leider aus den verfügbaren Informationen zum Lizenzrecht nicht schlau.

    Meine Ausgangslage:

    Wir betreiben einen Windows Server 2016 Standard. Dieser arbeitet als Domänencontroller. Aufgrund der offiziellen Empfehlung, Microsoft SQL Server nicht auf einem Domänencontroller zu betreiben, möchten wir mittels HyperV innerhalb des Servers 2016 Standard einen weiteren Server in virtueller Form installieren.

    Meine Frage:

    Reicht die Windows Server 2016 Standard Lizenz aus, um dieses Betriebssystem parallel auch innerhalb HyperV als virtuelle Maschine zu betreiben (also eine physische Installation und eine virutelle) oder benötige ich dan eine weitere Lizenz?

    Bei drei Anrufen bei verschiedenen Microsoft Hotlines (Microsoft Store --> Produkt Aktivierungshotline --> technische Hotline ) hieß es leider nur, man könne/dürfe/wolle mir hierzu keine Auskunft erteilen und verwies wie oben dargestellt auf die andere Instanz. Erstaunlich, zumal sich diese Frage ja einfach mit Ja/Nein beantworten ließe. Die technische Hotline riet mir dann, hier diese Frage zu stellen.

    Über Infos wäre ich sehr dankbar.

    Grüße

    Montag, 6. April 2020 12:33

Antworten

  • Moin,

    in einer Umgebung so klein, dass sie in Sachen Reliability mit einem einzigen physischen Server und einem einzigen Domain Controller auskommen, spielen Security und Performance in der Regel nicht die Rolle. Es gibt also nicht den einen großen zwingenden Grund, sondern ganz viele kleine.

    Die Gründe teilen sich in drei Kategorien auf:

    1. warum sollte ich auf dem Hyper-V-Host nichts fahren außer Hyper-V?
    2. warum sollte ein DC nichts ausführen außer DC und DNS?
    3. warum sollte ich, wenn ich schon virtualisiere, Produktive Workloads möglich gar nicht physisch fahren?

    Die dritte Frage ist schnell beantwortet: Blech stirbt manchmal, und eine VM ist immer schneller und konsistenter aus dem Backup wiederhergestellt als das Abbild eines physischen Servers. Und wenn irgendwann dann doch ein zweiter Host daneben steht, ist die VM schnell hochverfügbar gemacht, eine physisch installierte Rolle aber nicht.

    Warum sollte Hyper-V nur Hyper-V sein?

    Microsoft aus dem Best Practices Analyzer: https://docs.microsoft.com/de-de/windows-server/virtualization/hyper-v/best-practices-analyzer/hyper-v-should-be-the-only-enabled-role

    Aus einem alten ALTARO-Blog: https://www.altaro.com/hyper-v/4-reasons-your-hyper-v-host-should-only-run-the-hyper-v-role/

    Warum sollte DC nur DC sein?

    Ein DC kann im Active Directory beliebig lesen und schreiben. Jeder Prozess, der im Systemkontext eines DC ausgeführt wird, hat eine Hand an den Kronjuwelen ;-) Das ist auch der Grund, warum man niemals DHCP oder Print Server auf DC fahren sollte (und ja, ich weiß, Essentials ist auch ein Microsoft-Produkt. Siehe ersten Satz meiner Antwort.)


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 7. April 2020 06:37
  • Moin,

    warum auch immer man Dir nicht helfen wollte / konnte, Server-Lizenzierung ist eigentlich sehr einfach:

    1. Du lizenzierst immer Blech, d.h. ab 2016 musst Du genug Lizenzen der gewählten Stufe gedanklich an das Blech "kleben", dass alle Kerne (ohne HyperThreading) in allen Sockeln abgedeckt sind. Das OEM- oder Retail-Paket beinhaltet i.d.R 16 Kerne in max 2 Sockeln.
    2. Ist das Blech lizenziert, kannst Du auf diesem Blech mit der Standard Edition 2x Server Standard ausführen und mit der Datacenter beliebig oft Server Standard oder Datacenter. Dabei zählt bei der Standard die physische Installation mit rein, sobald sie irgendetwas anderes macht als Hyper-V und Backup für Hyper-V.

    In Deinem Fall gilt übrigens neben der dringenden Empfehlung, kein SQL mit DC koexistieren zu lassen, die ebenso dringende Empfehlung, nichts auf Hyper-V zu installieren außer Hyper, Backup-Agent, USV-Agent und Monitoring-Agent. Insofern hast Du zwei Varianten:

    1. Auf Blech: Hyper-V + DC (nicht empfohlen), dann hast Du eine VM frei für SQL
    2. Auf Blech: Nur Hyper-V, und dann DC und SQL jeweils als VM.

    Übrigens: Du kannst mit der Standard Edition auch mehr als zwei VMs auf dem gleichen Blech betreiben. Dafür musst Du es halt einfach nochmal komplett lizenzieren.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 6. April 2020 12:48

Alle Antworten

  • Moin,

    warum auch immer man Dir nicht helfen wollte / konnte, Server-Lizenzierung ist eigentlich sehr einfach:

    1. Du lizenzierst immer Blech, d.h. ab 2016 musst Du genug Lizenzen der gewählten Stufe gedanklich an das Blech "kleben", dass alle Kerne (ohne HyperThreading) in allen Sockeln abgedeckt sind. Das OEM- oder Retail-Paket beinhaltet i.d.R 16 Kerne in max 2 Sockeln.
    2. Ist das Blech lizenziert, kannst Du auf diesem Blech mit der Standard Edition 2x Server Standard ausführen und mit der Datacenter beliebig oft Server Standard oder Datacenter. Dabei zählt bei der Standard die physische Installation mit rein, sobald sie irgendetwas anderes macht als Hyper-V und Backup für Hyper-V.

    In Deinem Fall gilt übrigens neben der dringenden Empfehlung, kein SQL mit DC koexistieren zu lassen, die ebenso dringende Empfehlung, nichts auf Hyper-V zu installieren außer Hyper, Backup-Agent, USV-Agent und Monitoring-Agent. Insofern hast Du zwei Varianten:

    1. Auf Blech: Hyper-V + DC (nicht empfohlen), dann hast Du eine VM frei für SQL
    2. Auf Blech: Nur Hyper-V, und dann DC und SQL jeweils als VM.

    Übrigens: Du kannst mit der Standard Edition auch mehr als zwei VMs auf dem gleichen Blech betreiben. Dafür musst Du es halt einfach nochmal komplett lizenzieren.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 6. April 2020 12:48
  • Hallo Herr Smirnov,

    danke für die Top-Erklärung.

    Ein Tool zur Migration des derzeitig phyischen Servers in den virtuellen hätte ich auch schon gefunden (https://www.iperiusbackup.net/de/disk2vhd-konvertieren-einer-physischen-maschine-in-eine-virtuelle-maschine-hyper-v-p2v/).

    Könnten Sie mir die Nachteile nennen, die sich ergeben, wenn ich den Domänencontroller physisch belasse und den SQL-Server mittels HyperV virtualisiere?

    Sind es Performanceprobleme? Oder Sicherheitsprobleme?

    Ich konnte hier leider nichts herausfinden.

    Danke!

    Montag, 6. April 2020 23:22
  • Moin,

    in einer Umgebung so klein, dass sie in Sachen Reliability mit einem einzigen physischen Server und einem einzigen Domain Controller auskommen, spielen Security und Performance in der Regel nicht die Rolle. Es gibt also nicht den einen großen zwingenden Grund, sondern ganz viele kleine.

    Die Gründe teilen sich in drei Kategorien auf:

    1. warum sollte ich auf dem Hyper-V-Host nichts fahren außer Hyper-V?
    2. warum sollte ein DC nichts ausführen außer DC und DNS?
    3. warum sollte ich, wenn ich schon virtualisiere, Produktive Workloads möglich gar nicht physisch fahren?

    Die dritte Frage ist schnell beantwortet: Blech stirbt manchmal, und eine VM ist immer schneller und konsistenter aus dem Backup wiederhergestellt als das Abbild eines physischen Servers. Und wenn irgendwann dann doch ein zweiter Host daneben steht, ist die VM schnell hochverfügbar gemacht, eine physisch installierte Rolle aber nicht.

    Warum sollte Hyper-V nur Hyper-V sein?

    Microsoft aus dem Best Practices Analyzer: https://docs.microsoft.com/de-de/windows-server/virtualization/hyper-v/best-practices-analyzer/hyper-v-should-be-the-only-enabled-role

    Aus einem alten ALTARO-Blog: https://www.altaro.com/hyper-v/4-reasons-your-hyper-v-host-should-only-run-the-hyper-v-role/

    Warum sollte DC nur DC sein?

    Ein DC kann im Active Directory beliebig lesen und schreiben. Jeder Prozess, der im Systemkontext eines DC ausgeführt wird, hat eine Hand an den Kronjuwelen ;-) Das ist auch der Grund, warum man niemals DHCP oder Print Server auf DC fahren sollte (und ja, ich weiß, Essentials ist auch ein Microsoft-Produkt. Siehe ersten Satz meiner Antwort.)


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 7. April 2020 06:37
  • Hallo Herr Smirnov,

    vielen, vielen Dank für Ihre Hilfe.

    Sie haben mir sehr geholfen!

    Schöne Ostern!

    Freitag, 10. April 2020 07:56