Jump to content

Einige Lizenzfragen bzgl. Servervirtualisierung, Terminalserver und eine spätere Migration


Direkt zur Lösung Gelöst von NilsK,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo allerseits,

 

 

[Vorwort/Einleitung]

im Moment rollt bei uns ein Projekt, in welches ich (Mitarbeiter der internen IT-Abteilung einer Kommunalverwaltung) erst seit kurzem involviert bin (wie so oft, sind wir erst nachträglich/zu spät einbezogen worden). Das Vorgehen im Rahmen dieses Projektes muss ich einerseits inhaltlich und finanziell bewerten und kann ich andererseits in gewissen Grenzen noch in die eine oder andere Richtung steuern. Die Schwierigkeit besteht darin, (sehr) kurzfristige Funktionsanforderungen im Wege einer noch auszugestaltenden Interimslösung mit einer Migrationsplanung für das Jahr 2019 in Einklang bringen zu müssen. Inhaltlich und organisatorisch gibt es je nach gewählter Interimslösung halt Vor- und Nachteile - das ist aber nicht Teil dieses Threads. Mir geht es hier darum, eventuelle Fallstericke des Lizenzrechts zu erkennen und diese in die Entscheidungsfindung einfließen lassen zu können. Oder mit anderen Worten: Ich möchte einerseits sicherstellen, dass es zu keiner Unter- oder Fehllizensierung kommt und andererseits natürlich auch Doppel- oder Überlizensierung vermeiden.

Da ich mich mit dem Lizenzrecht nicht in der Tiefe auskenne, bitte ich Euch um entsprechende Hilfestellung.

 

 

[Fallgestaltung/Sachverhalt]

Es gib einen separaten Betriebsteil der Behörde, der aufgrund seiner Anforderungen hinsichtlich der zeitlichen Verfügbarkeit des IT-Personals nicht von der internen IT-Abteilung, sondern von einem externen Dienstleister betreut wird.

Hier läuft derzeit ein einzelner physischer Host mit VmWare ESXi und darauf mehrere virtuelle Windows-Server - unter anderem ein Fileserver und ein DB-Server (derzeit noch Oracle).

Diese virtuellen Windows-Server sind derzeit per Einzellizenz über den Select-Vertrag der Behörde lizensiert.

 

In 2019 wird dieser physische Host ersetzt. Dann wird eine HA-Lösung mit 2 physischen Nodes und VwWare ESX mit Virtual Center implementiert. Als DB soll dann wohl auch auf MS-SQL umgestellt werden, da Oracle in diesem Umfeld sonst wohl lizenztechnisch zu teuer würde.

 

Bereits in 2018 soll jedoch einer anderen Behörde Zugriff auf das eingesetzte Fachverfahren und die Datenbank gegeben werden. Hierzu wird ein Site-to-Site-VPN aufgebaut und ein MS-Terminalserver bereitgestellt werden, welcher von der anderen Behörde quasi als abgesetzter Client ferngesteuert wird. Der Terminalserver soll (nach jetziger Planung) nicht Teil der internen Domäne des Standortes sein, sondern in einer DMZ (VLAN) isoliert bzw. reglementiert als Einzelserver betrieben werden. Es handelt sich vorerst um bis zu 3 parallele TS-Sessions/Nutzerzugriffe.

 

Der externe Dienstleister hat hierfür folgendes angeboten/vorgeschlagen:

- Aufrüstung des vorhandenen Hosts mit Arbeitsspeicher

- Erweb einer OEM-Lizenz für MS Terminalserver mit 5 Usern

- Installation des TS als VM auf dem vorhandenen ESXi (mit derzeit einem Node)

 

Die Kosten für die Aufrüstung des vorhandenen Hardwareservers sind nicht ganz unerheblich und es wiederstrebt mir, diese für ein System zu investieren, welches nur noch ca. 12 Monaten in Betrieb sein wird. Auch würden wir gerne unnötige Downtime vermeiden.

Deshalb ist die Überlegung, den Terminalserver übergangsweise auf dem VM-Ware-Cluster der Kommune zu hosten, bis dieser 2019 auf das neue System des betreffenden Betriebsteiles umziehen kann. Technisch wäre dies problemlos machbar.

Der VmWare-Cluster der Kommune besteht aus 8 Hardwarenodes und ist hinsichtlich der MS-Server per Selectvertrag über entsprechende Datacenter-Lizenzen ablizensiert.

 

 

[Zusammenfassung der Handlungsalternativen]

Variante 1)

- Aufrüstung des Speichers des 1-Node-ESXi in 2018

- hierauf Installation eines MS-TS; lizensiert als OEM-Version für 5 User

- 2019 Umzug der TS-VM auf ein neuen 2-Node-ESX

 

Variante 2)

- Installation des MS-TS auf dem vorhandenen 8-Node-ESX der Kommune

- Lizensierung des TS entsprechend den Erfordernissen

- 2019 Umzug der TS-VM auf ein neuen 2-Node-ESX

 

 

[Fragen]

Für mich ergeben sich folgende lizenzrechtliche Fragen, deren Beantwortung ich mir hier erhoffe...

 

1) Beeinhaltet die OEM-Lizenz des TS auch den "Basis-Server" oder muss der zusätzlich lizensiert sein/werden? Gleiches gilt für die Cals.

2) Ist die OEM-Lizenz des TS ausreichend in der 1-Node-Umgebung?

3) Ist die OEM-Lizenz des TS ausreichend in einer Mehrfach-Node-Umgebung? Stichwort: Lizenzmobilität zwischen den Nodes?

4) Ergibt sich beim Umzug der vorhandenen virtuellen Windows-Server von der jetzigen Single-Host-Plattform hin zur 2-Node-HA-Plattform im Jahr 2019 in dieser Hinsicht ein veränderten Lizenzbedarf?

5) Wie ist 2019 der MS-SQL-Server zu lizensieren?

 

Dann doch noch zwei technische Fragen:

6) Ist es möglich, den TS als Einzelserver (ohne Domäne) zu betreiben?

7) Kann der Lizenzserver in diesem Fall direkt auf TS direkt sein? Wenn nein:  könnte er auf einem anderen Server sein, der Mitglied einer Domäne ist, die der TS selbst nicht angehört?

 

Sollte ich weitere sich daraus ergebende Fragestellungen bisher nicht identifiziert haben, bitte ich ebenfalls um entsprechenden Hinweis.

 

 

Danke und Gruß

sk

Link zu diesem Kommentar
  • Beste Lösung

Moin,

 

eiserner Grundsatz: Egal, mit welchem Hypervisor die Hosts laufen, werden niemals Windows-VMs lizenziert, sondern immer nur der Host. Auf diesem muss die eingesetzte Lizenz alle VMs mit umfassen.

Die Standard Edition umfasst zwei VMs (bei Mehrbedarf weist man mehrere Lizenzen dem Host zu), die Datacenter Edition beliebig viele.

 

Sofern der Satz

Zitat

Diese virtuellen Windows-Server sind derzeit per Einzellizenz über den Select-Vertrag der Behörde lizensiert.

also bedeutet, dass einzelne Windows-Lizenzen für die VMs vorliegen, so ist das falsch lizenziert.

 

Eine "OEM-Lizenz" ist hinsichtlich ihrer Einsetzbarkeit i.d.R. eingeschränkt. Solche Lizenzen dürfen auch nur mit einer neuen Hardware vertrieben werden, also dürfte schon hier ein Lizenzverstoß in dem gegenwärtigen Vorschlag vorliegen. Ob diese OEM-Lizenz (die ja wie alle Lizenzen der Hardware zugewiesen ist) auch laufende VMs abdeckt, müsste man dann ggf. in deren Lizenzvertrag nachlesen (vermutlich ja).

 

Damit sind deine Fragen 1 bis 3 eigentlich obsolet. Die VMs selbst haben keine Lizenzen, sondern der Host muss diese haben. Im Falle eines Clusters müssen auf jedem Host so viele "inkludierte" VM-Lizenzen vorliegen, dass alle (Windows-Server-) VMs zu jeder Zeit auf allen Hosts vollständig lizenziert sind (was auch Frage 4 betrifft).

 

Wie 2019 die dann aktuelle SQL-Server-Lizenzierung aussieht, weiß selbst Microsoft noch nicht. Aktuell ist es so, dass die Lizenzmobilität für SQL Server (und Exchange) nur mit aktiver SA für die Applikationslizenz gegeben ist.

 

Mehr dazu:

https://www.youtube.com/watch?v=6tH3QGSRP00

 

Frage 6: Ja, geht, ist aber umständlich.

Frage 7: Kann ich aus dem Kopf leider nicht sagen. Aber ihr wollt ohnehin über das Konstrukt noch mal nachdenken. (Wenn dir der Hinweis zu abstrakt ist, ist das ein Kennzeichen dafür, dass ihr externe Beratung braucht. Ist nicht arrogant gemeint, sondern ernst.)

 

Gruß, Nils

 

Link zu diesem Kommentar

Hallo Nils,

Hallo Jan,

 

besten Dank für Eure schnellen und kompetenten Antworten!

Das hat mir sehr geholfen, einen schnellen EInstieg zu finden. Seit ca. 2006 bin ich eigentlich nur noch in der Netzwerkschiene unterwegs gewesen und hatte seither kaum noch Updates in Sachen MS - weder technisch noch lizenzrechtlich. Bei beidem hat sich die Welt aber offenkundig erheblich weitergedreht. EIn guter Anlass, mich mal wieder auch in diesem Bereich etwas näher an den aktuellen Stand zu bringen.

Habe zwischenzeitlich auch Zugriff auf unser VLSC und werde unsere Vorhaben und Anforderungen mit dem zuständigen LAR/LSP besprechen. Da wird dann alles ordnungsgemäß lizensiert.

Nach heutiger Abstimmung mit zwei Carriern sieht es übrigens ohnehin so aus, als ob wir auf den TS verzichten und Fatclients einsetzen könnten, weil wir voraussichtlich für vergleichsweise schmales Geld (sogar wegeredundante) Dark-Fiber bekommen können. Das löst dann auch ein paar andere Probleme gleich mit. :-D

 

Danke und Gruß

Steffen

bearbeitet von s.k.
Typo
Link zu diesem Kommentar

Hi Steffen,

noch Inputs meinerseits zur Lizenzierung:

Bei SQL würde ich diese DB in einer VM mit 4x virtuellen COREs betreiben.
Da ist sichergestellt, dass die Zugriffe von intern unde extern unlimitiert und abgesichert lizenziert sind.

Beim WIN-SVR wird das nicht ganz so einfach.
z.B. Ihr nutzt real WS2016 für das SVR-Blech oder in irgendeiner VM,

dann darf ein Zugriff auch nur mit mind. einer 2016er WIN-SVR-CAL erfolgen.
Kannst Du sicherstellen, dass andere Behörden schon auf 2016er WIN-CALs lizenziert sind?
Wenn nicht, muss der Betreiber des 2016er SVRs(also Ihr!) Sorge tragen, dass der Zugreifende eine 2016er CAL erhält (Gast-CAL)
Wenn dass dann ev. in unbekannte Stückzahlen ausartet, muss Du ersatzweise den WIN-SVR (aber bur das physische Blech himself)
mit dem sogn, "External Connector für WS-2016" lizenzieren, dann sind alle "Externen" clean.
Aber man muss auch bedenken, welche WIN-SVR auch weiter innerhalb Eures Netzwerkes dabei "betascht" werden!
Dann muss auch jeder dieser WIN-SVR so einen "ex.Connect" erhalten ....

 

Ja, leider nicht ganz einfach.

 

VG, Franz

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...