SQL Express 2008 R2 in Virtueller Umgebung

[zahni 554]

Bleibt  die  Frage, wer beim Vcenter in der DB  die Knöpfe drückt. Aus der Sicht von Microsoft machen es die VMs.

[NorbertFe 2.034]

das is doch Unsinn in meinen Augen. (Hat nichts zu sagen) wenn ich Daten von Systemen erfasse und diese Daten in eine Datenbank schreibe, warum brauche ich dann eine cal für die Systeme deren Daten ich erfasse? Mit dem Argument dürften viele Datenbanken falsch lizenziert sein. Um bei deinem Beispiel zu bleiben, du müsstest den Verkäufer der Glühbirne zum knopfdrücken einfliegen lassen.

[lizenzdoc 207]

Jetzt mal ne einfache Frage:

Hat jemand die EULA der SQL-Express downgeloaded?
War die nicht als "Prozessor-Lizenz" mal deklariert?

Bin mir da grad nicht sicher, dementsprechend würden ja keine Zugriffe lizenzrechtlich relevant, oder?

[NorbertFe 2.034]

Es ging um Daniels Aussage in http://www.mcseboard.de/topic/202135-sql-express-2008-r2-in-virtueller-umgebung/?do=findComment&comment=1258770

Wenn die SQL Express Edition nicht mehr ausreicht.

 

Bye

Norbert

[Daniel -MSFT- 129]

Ich glaube, Euer Mißverständnis beruht darauf, dass ihr die Lizenzierung von einer aktiven Komponente der VM abhängig macht. Mal abgesehen davon, dass die VM wohl aktiv mit dem vCenter kommuniziert (zumindest muss eine Firewall zwischen vCenter und Host/VM notwendige Ports für vCenter sowohl eingehend, als auch ausgehend initiierend geöffnet haben und bis zu 10.000 VMs verwalten sich nicht nur durch Pull), lest mal genau den Multiplexing-Absatz, den ich gepostet habe. Auch der Einsatz von Software für die Verwaltung ist lizenzpflichtig. Die Hosts und vCenter arbeiten als Multiplexing-Devices.

[zahni 554]

Die VMs kommunizieren nicht über IP mit dem Vcenter. Die kommunizieren überhaupt nicht mit Vcenter. Dazu dient das VMCI-Interface, das mit dem ESXi-Host kommuniziert. Darüber erhalten die VMWare-Tools in der VM auch entsprechende Befehle "irgendwas" zu machen.  Auf dem ESXI-Host läuft der VPXA-Agent, der die Daten abgreift und zum VCenter schickt. Auch bezieht eine VM keinerlei Informationen aus der SQL-DB um zu funktionieren. Ja, der Cluster läuft sogar ohne Vcenter weiter, wenn man hier mal eine Wartung durchführt.

Kurz gesagt: Der VCenter verwaltet zu 98% die ESXI-Hosts. Der z.B. an Host A den Befehl zum Start der VM B, usw.

Selbst die Performance-Daten stammen zu größten Teil vom VMKernel und nicht von der VM.

 

Bleiben wir beim Beispiel Netzwerkmanagement: Müssen sämtliche verwaltete Geräte eine SQL-Cal bekommen, wenn die Verwaltungssoftware den SQL-Server benutzt?

Wann ist für Microsoft ein "Objekt" ein Gerät, dass zu lizensieren ist?

 

PS: Wenn dieser dumme Update-Manager von Vmware nicht den MS-SQlL-Server bräuchte, (Achtung: Nur für ESXI-Host ;) ) würde das VCenter schon längst DB2 Benutzen. Der Vcenter selbst kann das nämlich. Dank Konzernvertrag unserer Mutter, müssten wir dann keine Erbsen zählen.

bearbeitet 13. Februar 2015 von zahni

[Daniel -MSFT- 129]

Deswegen sag ich ja: vCenter und ESXI-Hosts sind als Multiplexer zu betrachten. Siehe mein Zitat oben.

 

Was das Verwalten von Geräten angeht: Ja, dafür werden Device CALs notwendig. Lest mal http://blogs.technet.com/b/volume-licensing/archive/2014/03/10/licensing-how-to-when-do-i-need-a-client-access-license-cal.aspx

 

Zitat: 'Let's say for example, the management software is installed on a Windows Server, and is being used to manage client devices, network equipment, and other servers. Any device that accesses Windows Server as a result of being managed will require a Windows Server device CAL (with the exception of other Windows Server since Windows Server to Windows Server communication does not require a CAL). If you are licensed by user in this scenario however, and all users are covered with a Windows Server CAL, then you’re covered since all users of the managed devices are already covered with user CALs.'

 

Ersetze 'Windows Server' durch 'SQL-Server' und Du hast das Ergebnis. Wobei bei SQL auch noch gilt (SQL Lizenz Guide 2014):

 

"Note: Devices not operated by humans require device CALs, even when connecting to SQL Server indirectly. For human operated devices such as PCs or hand-held terminals, a user CAL or device CAL can be used."

 

Ob jetzt DB2 lizenztechnisch billiger ist, wenn man keinen All you can eat-Vertrag hat, wage ich zu bezweifeln. VMware nutzt aus gutem Grund den SQL-Server Express.

 

Have fun!

Daniel

[Beel 0]

Ob jetzt DB2 lizenztechnisch billiger ist, wenn man keinen All you can eat-Vertrag hat, wage ich zu bezweifeln. VMware nutzt aus gutem Grund den SQL-Server Express.

Die Gratis-Variante der DB2, die Express-C kann 4 GB RAM und 2 Kerne - der SQL Express 2014 dagegen 1 GB RAM und 1 Kern, die Lizenzpflicht fängt also Faktor 8 später an. http://www-01.ibm.com/software/data/db2/express-c/about.html

[lizenzdoc 207]

Moin,

 

sorry, ich hatte es etwas falsch gelesen.

 

Ich würde als Lösung den SQL-STD-in der CORE-Lizenzierung wählen und bei Bedarf der Mobilität dann auch mit SA.

Sicherlich ist es dann auch möglich für die Wissensträger,
dass man dieser SQL-CORE-Lizenz eine feste V-OSE zuweist. Dieser schreibt man 4-COREs max. fest vor zur Nutzung.
Bei Mobilität schreibt man wieder dieser SQL-CORE-Lizenz eine feste Sprung-Ziel-v-OSE vor, wiederum mit festen 4-COREs.

 

Somit hätte man doch mit 2x SQL-STD-(2-COREs= 4-COREs) inkl. SA die v-OSE perfekt legal lizenziert

und die leidige SQL-CAL-Frage komplett weg vom Tisch und Ruhe.

 

Sicherlich eine Preisfrage, aber wenn zukünftige Erweiterungen zum wiederholten Male viel Zeit zum "Erbsen-CAL-Zählen"

benötigen und das immer wiederholend, dann rechnet sich das sehr schnell.

 

Nicht umsonst hat damals MS für das Thema z.B. Sytsemcenter auch die Lizenz angeboten:

Systemcenter-Lizenz inkl SQL-Thechnologie,
wobei diese dann ausschließlich damals eine Prozessor-Lizenzierung darstellte, also ohne SQL-CALs.

 

VG, Franz

bearbeitet 14. Februar 2015 von lizenzdoc

[Daniel -MSFT- 129]

@Beel: Nur mal so am Rande, SQL Server Express erlaubt bis zu vier Kerne, nicht nur einen: https://msdn.microsoft.com/de-de/library/ms143760.aspx

 

Ich bezog mich aber explizit auf die kostenpflichtigen Versionen...

[Dr.Melzer 191]

E ist ganz einfach. Sch

 

Die Ausführende "Person" ist der vCenter-Server. Er holt sich irgendwelche Daten und schreibt sie in die DB. Die VM tritt doch nicht wirklich selber in Kraft. Das hat doch weder mit Pooling noch mit Multiplexing was zu tun?

Na der VCenter Server macht das ja nicht zu Selbstzweck, sondern damit die Clients die Daten bekommen. Wenn der VCenter Server nicht wäre müssten die Client direkt auf den SQL Server zugreifen. Also eindeutig ein fall von Multiplexing, bei dem Anfragen der Clients über den VCenter Server zum SQL Server umgeleitet werden.

[Weingeist 159]

E ist ganz einfach. Sch

 

Na der VCenter Server macht das ja nicht zu Selbstzweck, sondern damit die Clients die Daten bekommen. Wenn der VCenter Server nicht wäre müssten die Client direkt auf den SQL Server zugreifen. Also eindeutig ein fall von Multiplexing, bei dem Anfragen der Clients über den VCenter Server zum SQL Server umgeleitet werden.

 

@Dr. Melzer: Meiner Meinung nach ist das nicht so eindeutig, da nicht wirklich der Client anfragt, sondern doch das vCenter/ESXi (Zumindest nach meinem Wissensstand). Der Client liefert nur die Informationen. Also wie wenn ich den Telefonhörer abnehme, Daten von nem Kunden aufnehmen und in die Datenbank einpflege. Für den Kunden brauche ich auch keine CAL. Also warum für die VM's?

 

Des weiteren: Jetzt unabhängig davon ob das obig nun so stimmt, warum sollte man für eine VM eine CAL brauchen? Es müsste für den Host ausreichen.

[monstermania 53]

@Weingeist

Ist eben absolut nicht einleuchtend!

zahni hatte ja schon das Beispiel mit einer Monitoring-Software gebracht. Monitoring-Lösung hat im Backend einen MS-SQL. Braucht jetzt jeder Client eine SQL-CAL?

 

Klar kann man eben so argumentieren, dass der Monitoring-Server die Clients aktiv abfragt. Ähnlich, wie ein realen Menschen, der z.B. seine Kunden anruft und die Daten seiner Kunden manuell einpflegt. Aber ist das lizenztechnisch das Selbe? Braucht das dann also keine SQL-CAL für jeden Client (Kunden)? Wo beginnt die Lizenzpflicht?

Was machst Du dann aber, wenn der Agent auf den Clients aktive Warnmeldungen verschickt (z.B. SNMP-Traps)? Dann greift der Client ja sozusagen aktiv auf den MS-SQL zu (über die Monitoring-Lösung)! Brauchst Du dann auf einmal eine SQL-CAL?

Im Prinzip ist es mit dem VCenter ja das Gleiche...

Andererseits läuft die Umgebung prinzipiell auch ohne VCenter. Oder auch ohne Monitorung-Lösung. Aber ob das Auswirkungen auf eine evtl. Lizenzpflicht?

 

Ich bin nur froh, dass ich mich damit nicht Auseinendersetzen muss, da SQL-Express.

Ich kann aber beide Argumentationen nachvollziehen.

bearbeitet 16. Februar 2015 von monstermania

[Dr.Melzer 191]

@Dr. Melzer: Meiner Meinung nach ist das nicht so eindeutig, da nicht wirklich der Client anfragt, sondern doch das vCenter/ESXi (Zumindest nach meinem Wissensstand). Der Client liefert nur die Informationen.

Wie gesagt, wenn du den polenden Server abschaltest muss der Client direkt auf die Datenbank zugreifen. Also ist es pooling/Multiplexing.

 

Hier der dafür relevante Auszug aus den Produktnutztungsrechten:

 

Multiplexing

Hardware oder Software, die Sie für das Zusammenfassen von Verbindungen, das Umleiten von Informationen, das Verringern der Anzahl der Geräte oder Nutzer, die direkt auf das Produkt zugreifen oder es verwenden, oder das Verringern der Anzahl der Betriebssystemumgebungen (oder OSEs), Geräte oder Nutzer, die das Produkt direkt verwaltet, (manchmal als „Multiplexing“ oder „Pooling“ bezeichnet) einsetzen, verringert nicht die Anzahl der erforderlichen Lizenzen irgendeines Typs.

 

 

 

 

 

Des weiteren: Jetzt unabhängig davon ob das obig nun so stimmt, warum sollte man für eine VM eine CAL brauchen? Es müsste für den Host ausreichen.

Die virtuelle Instanz ist im Sinne der Produktnutzungsrechten auch ein CAL pflichtiges Gerät.

 

Hier der dafür relevante Auszug aus den Produktnutzungsrechten:

 

Lizenziertes Gerät ist das jeweilige physische Hardwaresystem, dem eine Lizenz zugewiesen wird. Im Sinne dieser Definition wird eine Hardwarepartition oder ein Blade als separates Gerät betrachtet.

[Weingeist 159]

@Dr. Melzer: Der Client muss doch nicht direkt zugreifen solange der vCenter sich daten holt. SNMP traps können sich auch nicht selbst in eine DB schreiben. Es könnte sein, dass der Datenbankserver mit vCenter direkt auf den Client zugreifen muss, aber nicht anders rum.

 

Streng genommen dürften Geräte die SNMP Traps versenden ebensowenig Lizenzpflichtig sein. Weil ein Log-Server nimmt einfach Daten auf, die im LAN herumgeistern.