32
MSSQL Lizensierung
Moin.
Ich stehe vor einer schwierigen Entscheidung bei der Beschaffung von Lizenzen. Wir haben diverse MS SQL Server in Verwendung, vornehmlich SQL Express und zwei Instanzen mit Runtime Lizenzen durch den jeweiligen Software-Hersteller, alles auf virtuellen Maschinen. Einem dieser Hersteller wurde der Vertrag seitens Microsoft gekündigt, ich bekomme da keine neue Versionen drüber. Eigentlich habe ich mich schon gefreut endlich eine "vollwertige" Lizenz zu beschaffen um mehrere Anwendungen auf den selben DB Server zu bringen.
Weil der SQL 2022 Release vor der Tür stand habe ich abgewartet aber hatte mich im Vorfeld schon auf SQL Standard 2022 4 Core Lizenz als OEM-Kauf eingeschossen. CAL Lizensierung ist eher unattraktiv aber nicht völlig ausgeschlossen - teurer ist sie auf jeden Fall. Da ich davon ausgehe das wir die SQL Version dann bestimmt 8 Jahre nicht anheben müssen habe ich auch wenig Verwendung für ein Model wie Software Assurance.
Jetzt hat Microsoft in die Lizenzbedingungen für SQL 2022 sinngemäß rein geschrieben das OEM nicht virtualisiert werden darf, nur CSP mit aktiver Subscription oder Open Value mit SA. Ich habe dazu bisher leider keine Quelle gefunden, ich habe das nur von Dritten als Information. In SQL 2019 gab es keine solche Einschränkung, 4 Core OEM durfte als VM mit 4 vCore betrieben werden.
Wenn ich jetzt Anschaffungskosten OEM von "ganz ganz Grob" 7.600 Euro bei einer Laufzeit von einfach mal 9 Jahren gegen eine CSP mit Subscription 29.000 Euro bzw. eine Open Value mit SA 26.400 Euro setze dann reden wir locker über 20T Euro bzw. 350% Kosten für diese eine Einschränkung. "Ganz ganz grob" bei OEM bedeutet eigentlich kann es sogar noch viel günstiger sein, das ist hier der teuerste von drei Händlern die OEM angeboten haben. Real komme ich bei einem anderen seriösen Händler sogar bei unter 4.000 Euro raus, alle Kosten habe ich jetzt aber bei einem Händler verglichen der alle drei Lizenzarten führt.
Jetzt will ich das Ding natürlich legal betreiben und bin auch bereit gutes Geld für ein gutes Produkt zu bezahlen. Das Produkt als OEM bietet aber alles was ich brauche und der Unterschied ist nicht nur einfach beachtlich sondern stellt die ganze Anschaffung in Frage. Unter der Voraussetzung, das es bei Microsoft SQL bleibt, sehe ich fünf realistische Möglichkeiten das umzusetzen:
1) Ich kaufe eine SQL 2019 OEM (noch mal günstiger) und nutze erstmal die bis ca. 2030 wo der Support ausläuft und vermutlich auch die wichtigste Anwendung auf ein Upgrade bestehen wird.
2) Ich kaufe eine SQL 2022 OEM und nutze ein Downgrade auf 2019, laut Händler möglich.
3) Ich betreibe den SQL Server nicht als VM sondern auf eigener Hardware. Ich sehe hier noch diverse Folgekosten und viele Nachteile aber auch kleinere Vorteile. Es müsste zunächst mal ein 1 pCPU Server sein mit 6 pCore, also mehr Lizenzkosten und eine Desktop CPU wie z.B. Ryzen 5 7600 mit ECC RAM und redudantem Netzteil, vermutlich bleibt nur ein Eigenbau. Ich habe das noch gar nicht durch gerechnet, eigentlich sollte man das meiner Meinung nach auch nicht favorisieren aber Bock hätte ich schon zu sowas. Wenn ich Option #2 wähle und 6 Kerne lizensiere ist Option #3 auch später möglich.
4) Ich lizensiere doch mit User CALs als OEM und kaufe gleich mal 45 CALs mit um Ruhe zu haben. Nach meinem Verständnis darf ich dann auch mit OEM virtualisieren und unbegrenzt Kerne für die VM einsetzen. Korrigiert mich wenn ich mich irre. Es kostet dann grob 10.000 Euro aber könnte auch 8 oder 9 Jahre reichen.
5) Ich schlucke und mache eine SA aber ganz ehrlich, ich sehe das nicht so recht ein.
Ich habe noch ein paar Rückfragen bei Händlern laufen. Jetzt hätte ich folgende Anliegen:
- Bitte korrigiert Details wenn ich etwas falsches schreibe.
- Wenn einer die genaue Lizenzbestimmung irgendwo als Quelle bei Microsoft kennt würde ich das gerne mal im Wortlaut lesen...
- Hat jemand kürzlich SQL lizensiert und wie? Was bevorzugt Ihr, Core oder User CALs?
- Wozu würdet ihr in meiner Situation tendieren und warum?
- Kann mir jemand genau den Unterschied zwischen CSP und Open Value erklären? Ich verstehe es so das ein CSP mit und ohne Subscription gekauft werden kann und nach Ende einer Subscription normalerweise unbegrenzt weiter genutzt werden kann. Aber kann eine Subscription verlängert werden oder ist das dann faktisch ein Neukauf nach maximal 3 Jahren? (So habe ich oben gerechnet.) Beinhaltet CSP mit Subscription automatisch neue Versionen wie Open Value mit SA?
Danke
Ich stehe vor einer schwierigen Entscheidung bei der Beschaffung von Lizenzen. Wir haben diverse MS SQL Server in Verwendung, vornehmlich SQL Express und zwei Instanzen mit Runtime Lizenzen durch den jeweiligen Software-Hersteller, alles auf virtuellen Maschinen. Einem dieser Hersteller wurde der Vertrag seitens Microsoft gekündigt, ich bekomme da keine neue Versionen drüber. Eigentlich habe ich mich schon gefreut endlich eine "vollwertige" Lizenz zu beschaffen um mehrere Anwendungen auf den selben DB Server zu bringen.
Weil der SQL 2022 Release vor der Tür stand habe ich abgewartet aber hatte mich im Vorfeld schon auf SQL Standard 2022 4 Core Lizenz als OEM-Kauf eingeschossen. CAL Lizensierung ist eher unattraktiv aber nicht völlig ausgeschlossen - teurer ist sie auf jeden Fall. Da ich davon ausgehe das wir die SQL Version dann bestimmt 8 Jahre nicht anheben müssen habe ich auch wenig Verwendung für ein Model wie Software Assurance.
Jetzt hat Microsoft in die Lizenzbedingungen für SQL 2022 sinngemäß rein geschrieben das OEM nicht virtualisiert werden darf, nur CSP mit aktiver Subscription oder Open Value mit SA. Ich habe dazu bisher leider keine Quelle gefunden, ich habe das nur von Dritten als Information. In SQL 2019 gab es keine solche Einschränkung, 4 Core OEM durfte als VM mit 4 vCore betrieben werden.
Wenn ich jetzt Anschaffungskosten OEM von "ganz ganz Grob" 7.600 Euro bei einer Laufzeit von einfach mal 9 Jahren gegen eine CSP mit Subscription 29.000 Euro bzw. eine Open Value mit SA 26.400 Euro setze dann reden wir locker über 20T Euro bzw. 350% Kosten für diese eine Einschränkung. "Ganz ganz grob" bei OEM bedeutet eigentlich kann es sogar noch viel günstiger sein, das ist hier der teuerste von drei Händlern die OEM angeboten haben. Real komme ich bei einem anderen seriösen Händler sogar bei unter 4.000 Euro raus, alle Kosten habe ich jetzt aber bei einem Händler verglichen der alle drei Lizenzarten führt.
Jetzt will ich das Ding natürlich legal betreiben und bin auch bereit gutes Geld für ein gutes Produkt zu bezahlen. Das Produkt als OEM bietet aber alles was ich brauche und der Unterschied ist nicht nur einfach beachtlich sondern stellt die ganze Anschaffung in Frage. Unter der Voraussetzung, das es bei Microsoft SQL bleibt, sehe ich fünf realistische Möglichkeiten das umzusetzen:
1) Ich kaufe eine SQL 2019 OEM (noch mal günstiger) und nutze erstmal die bis ca. 2030 wo der Support ausläuft und vermutlich auch die wichtigste Anwendung auf ein Upgrade bestehen wird.
2) Ich kaufe eine SQL 2022 OEM und nutze ein Downgrade auf 2019, laut Händler möglich.
3) Ich betreibe den SQL Server nicht als VM sondern auf eigener Hardware. Ich sehe hier noch diverse Folgekosten und viele Nachteile aber auch kleinere Vorteile. Es müsste zunächst mal ein 1 pCPU Server sein mit 6 pCore, also mehr Lizenzkosten und eine Desktop CPU wie z.B. Ryzen 5 7600 mit ECC RAM und redudantem Netzteil, vermutlich bleibt nur ein Eigenbau. Ich habe das noch gar nicht durch gerechnet, eigentlich sollte man das meiner Meinung nach auch nicht favorisieren aber Bock hätte ich schon zu sowas. Wenn ich Option #2 wähle und 6 Kerne lizensiere ist Option #3 auch später möglich.
4) Ich lizensiere doch mit User CALs als OEM und kaufe gleich mal 45 CALs mit um Ruhe zu haben. Nach meinem Verständnis darf ich dann auch mit OEM virtualisieren und unbegrenzt Kerne für die VM einsetzen. Korrigiert mich wenn ich mich irre. Es kostet dann grob 10.000 Euro aber könnte auch 8 oder 9 Jahre reichen.
5) Ich schlucke und mache eine SA aber ganz ehrlich, ich sehe das nicht so recht ein.
Ich habe noch ein paar Rückfragen bei Händlern laufen. Jetzt hätte ich folgende Anliegen:
- Bitte korrigiert Details wenn ich etwas falsches schreibe.
- Wenn einer die genaue Lizenzbestimmung irgendwo als Quelle bei Microsoft kennt würde ich das gerne mal im Wortlaut lesen...
- Hat jemand kürzlich SQL lizensiert und wie? Was bevorzugt Ihr, Core oder User CALs?
- Wozu würdet ihr in meiner Situation tendieren und warum?
- Kann mir jemand genau den Unterschied zwischen CSP und Open Value erklären? Ich verstehe es so das ein CSP mit und ohne Subscription gekauft werden kann und nach Ende einer Subscription normalerweise unbegrenzt weiter genutzt werden kann. Aber kann eine Subscription verlängert werden oder ist das dann faktisch ein Neukauf nach maximal 3 Jahren? (So habe ich oben gerechnet.) Beinhaltet CSP mit Subscription automatisch neue Versionen wie Open Value mit SA?
Danke
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6569397142
Url: https://administrator.de/contentid/6569397142
Printed on: April 20, 2024 at 00:04 o'clock
32 Comments
Latest comment
SQL Standard 2022 vs. 2019 ist nur minimal teurer. Würde gleich 2022 nehmen, es sei denn du bekommst 2019er für "kleines" Geld. Ob du Server/CAL oder Core-Lizenzen nimmst, ist abhängig davon wie viele SQL-Server Instanzen und User/Devices du hast.
Wenn du z.B. 3 SQL Server hast und 50 User, dann ist 3x SQL Server Standard + 50 User CAL günstiger, da hier die Anzahl der Cores nicht berücksichtigt wird (~€15k). Hast du nun aber Core-Lizenzen und pro VM/HW-Server 4 Cores, dann ist das wesentlich teurer (~€23k).
Hast du aber nur eine SQL Server Instanz, dann ist zu kalkulieren wie viele User/Devices darauf zugreifen sollen und wie viele Cores du mindestens einsetzen musst. Beispiel: 50 User/Devices, 8 Cores => Core-Lizenz ~€15k und mit Server + CALs ~€13k.
Möchtest du skalierbar bleiben mit deinen CPUs, dann nimm die Server+CAL Variante. Wenn du mehr User hast aber die Cores reichen, dann die Core-Variante.
Bez. Open und CSP, soweit ich weiß, werden Open Lizenzen nicht mehr verkauft. Das ist alles nun ins CSP gewandert. Eine SA kannst du jeder Zeit verlängern oder auch pausieren und dann verlängern. Aber die Pause darf, denke ich, nur eine Version unterschiedlich sein. Wie bei uns z.B. SQL Server Standard 2016 mit abgelaufener SA, können wir die SA nicht neu abschließen. Wir müssten SQL 2019/2022 mit SA neu kaufen.
Wenn du z.B. 3 SQL Server hast und 50 User, dann ist 3x SQL Server Standard + 50 User CAL günstiger, da hier die Anzahl der Cores nicht berücksichtigt wird (~€15k). Hast du nun aber Core-Lizenzen und pro VM/HW-Server 4 Cores, dann ist das wesentlich teurer (~€23k).
Hast du aber nur eine SQL Server Instanz, dann ist zu kalkulieren wie viele User/Devices darauf zugreifen sollen und wie viele Cores du mindestens einsetzen musst. Beispiel: 50 User/Devices, 8 Cores => Core-Lizenz ~€15k und mit Server + CALs ~€13k.
Möchtest du skalierbar bleiben mit deinen CPUs, dann nimm die Server+CAL Variante. Wenn du mehr User hast aber die Cores reichen, dann die Core-Variante.
Bez. Open und CSP, soweit ich weiß, werden Open Lizenzen nicht mehr verkauft. Das ist alles nun ins CSP gewandert. Eine SA kannst du jeder Zeit verlängern oder auch pausieren und dann verlängern. Aber die Pause darf, denke ich, nur eine Version unterschiedlich sein. Wie bei uns z.B. SQL Server Standard 2016 mit abgelaufener SA, können wir die SA nicht neu abschließen. Wir müssten SQL 2019/2022 mit SA neu kaufen.
Zitat von @DerMaddin:
SQL Standard 2022 vs. 2019 ist nur minimal teurer. Würde gleich 2022 nehmen, es sei denn du bekommst 2019er für "kleines" Geld. Ob du Server/CAL oder Core-Lizenzen nimmst, ist abhängig davon wie viele SQL-Server Instanzen und User/Devices du hast.
Das ist auf jeden Fall für sich genommen recht logisch und das habe ich natürlich kalkuliert. Es sind derzeit 36 User, bald 37, aber relativ konstant. Ich kann aber natürlich Sprünge nicht ausschließen und bin daher eher von der User-Flexibilität der Core Lizenzen angetan. Günstiger ist es auch, einzig die Anzahl der vCores ist dann fix.SQL Standard 2022 vs. 2019 ist nur minimal teurer. Würde gleich 2022 nehmen, es sei denn du bekommst 2019er für "kleines" Geld. Ob du Server/CAL oder Core-Lizenzen nimmst, ist abhängig davon wie viele SQL-Server Instanzen und User/Devices du hast.
Es geht um einen Server, weitere sind nicht geplant. Es sollen mehrere Anwendungen auf diesen Server zugreifen und jeweils ihre eigene Instanz haben, wenn ich das richtig sehe geht das aber mit einer Standard Lizenz oder irre ich?
Bez. Open und CSP, soweit ich weiß, werden Open Lizenzen nicht mehr verkauft. Das ist alles nun ins CSP gewandert.
Ich habe das so verstanden das Open Licence nicht mehr existiert sondern durch Open Value ersetzt wurde. Für Open Value gibt es auch noch Preise, nicht nur für SA, daher wäre ich jetzt davon ausgegangen das es das noch neu zu kaufen gibt.Eine SA kannst du jeder Zeit verlängern oder auch pausieren und dann verlängern. Aber die Pause darf, denke ich, nur eine Version unterschiedlich sein. Wie bei uns z.B. SQL Server Standard 2016 mit abgelaufener SA, können wir die SA nicht neu abschließen. Wir müssten SQL 2019/2022 mit SA neu kaufen.
Das mit der Pause kannte ich noch nicht. In eurem Fall hättet ihr die SA erneuern können wenn es noch keinen SQL 2022 gäbe, richtig?
Ich hatte ja kürzlich auch eine Frage zur SQL-Lizenzierung.
Das glückliche war, dass der Anbieter eine Runtime License geboten hat. Und der hat da auch auf SQL 2019 gesetzt.
Und auch mit bei den 2016er RDSH gabs Fragen zum bisher genutzten Outlook 2016. Da habe ich mich dann entschieden, nicht auf W2k22 zu setzen, sondern auf W2k16 zu bleiben. Und da schauen wir mal, was dann in 2025 Microsoft gerade für ein Lizenzmodell hat.
Ich an deiner Stelle würde wohl auf SQL 2019 OEM setzen. Und dann eben 2030 schauen, was gerade anliegt.
Weil das ist schon heftig, was Microsoft da aktuell für Preise aufruft. Obs besser wird würde ich bezweifeln. Aber wenn mans noch aussitzen kann dann spart man sich da halt einiges an Geld.
So wie ich das rausgelesen habe bietet CSP Subscriptions das gleiche wie Open Value. Plus eben ein paar Vorteile, weil nicht so starr wie die Open Value. Z.B. monatliche Zahlweise (wenns wer will; Preisschutz) aber auch mit nur einem Jahr Laufzeit (oder sogar nur ein Monat). Ich weiß gar nicht, ob die jetzt schon die 3 Jahre anbieten, die sie mal angekündigt haben. Ich denke, CSP haben sie gebastelt, um da auch die Perpetual-Licenses anhängen zu können. Und halt, wiel sie preise erhöhen können.
Die tatsächlichen Lizenzbestimmungen von Microsoft habe ich leider auch noch nirgends gefunden.
Das glückliche war, dass der Anbieter eine Runtime License geboten hat. Und der hat da auch auf SQL 2019 gesetzt.
Und auch mit bei den 2016er RDSH gabs Fragen zum bisher genutzten Outlook 2016. Da habe ich mich dann entschieden, nicht auf W2k22 zu setzen, sondern auf W2k16 zu bleiben. Und da schauen wir mal, was dann in 2025 Microsoft gerade für ein Lizenzmodell hat.
Ich an deiner Stelle würde wohl auf SQL 2019 OEM setzen. Und dann eben 2030 schauen, was gerade anliegt.
Weil das ist schon heftig, was Microsoft da aktuell für Preise aufruft. Obs besser wird würde ich bezweifeln. Aber wenn mans noch aussitzen kann dann spart man sich da halt einiges an Geld.
So wie ich das rausgelesen habe bietet CSP Subscriptions das gleiche wie Open Value. Plus eben ein paar Vorteile, weil nicht so starr wie die Open Value. Z.B. monatliche Zahlweise (wenns wer will; Preisschutz) aber auch mit nur einem Jahr Laufzeit (oder sogar nur ein Monat). Ich weiß gar nicht, ob die jetzt schon die 3 Jahre anbieten, die sie mal angekündigt haben. Ich denke, CSP haben sie gebastelt, um da auch die Perpetual-Licenses anhängen zu können. Und halt, wiel sie preise erhöhen können.
Die tatsächlichen Lizenzbestimmungen von Microsoft habe ich leider auch noch nirgends gefunden.
Für uns lohnt sich aktuell auch nicht der Wechsel von SQL 2016 zu 2019/2022 da hier eine Änderung in der Lizenzierung erfolgte. Wir haben 4x SQL Server 2016 Standard 2 Core mit 2 Jahren SA vor 4 Jahren für €22k gekauft. Damals war die Core-Lizenzierung nicht unterscheidbar zw. pCPU und vCPU. Aus heutiger Sicht muss für den Betrieb von SQL auf einer VM zwingend SA bzw. CSP Abo dabei sein.
Wir warten also auch im Grunde ab wie unser Bedarf in 2026 aussehen wird und werden dann entsprechend handeln.
Wir warten also auch im Grunde ab wie unser Bedarf in 2026 aussehen wird und werden dann entsprechend handeln.
Zitat von @kpunkt:
So wie ich das rausgelesen habe bietet CSP Subscriptions das gleiche wie Open Value. Plus eben ein paar Vorteile, weil nicht so starr wie die Open Value. Z.B. monatliche Zahlweise (wenns wer will; Preisschutz) aber auch mit nur einem Jahr Laufzeit (oder sogar nur ein Monat). Ich weiß gar nicht, ob die jetzt schon die 3 Jahre anbieten, die sie mal angekündigt haben. Ich denke, CSP haben sie gebastelt, um da auch die Perpetual-Licenses anhängen zu können. Und halt, wiel sie preise erhöhen können.
Bei CSP wird von Kauflizenz geschrieben, das mit dem monatlich lese ich aber auch immer wieder. Wir haben jetzt grade Exchange 2019 "gekauft" und das wurde ins Microsoft 365 Portal eingestellt als "Kauflizenz", somit gehe ich mal davon aus das es bei SQL grundsätzlich auch so ist. Nur das ich das wohl nur virtualisieren darf wenn ich eine Subscription habe.So wie ich das rausgelesen habe bietet CSP Subscriptions das gleiche wie Open Value. Plus eben ein paar Vorteile, weil nicht so starr wie die Open Value. Z.B. monatliche Zahlweise (wenns wer will; Preisschutz) aber auch mit nur einem Jahr Laufzeit (oder sogar nur ein Monat). Ich weiß gar nicht, ob die jetzt schon die 3 Jahre anbieten, die sie mal angekündigt haben. Ich denke, CSP haben sie gebastelt, um da auch die Perpetual-Licenses anhängen zu können. Und halt, wiel sie preise erhöhen können.
Bei CSP wird immer von "Subscription" gesprochen, bei Open Value von "Software Assurance". Ist das jetzt das gleiche, also bekomme ich mit beidem auch neue Versionen gestellt?
Ich verlinke hier jetzt einfach mal die Preisliste eines Händlers weil die noch halbwegs Übersicht auf ihrer Seite bieten und das meine kalkulatorische Basis ist (das soll keine Werbung sein sondern dient nur dem Vergleich von Kosten):
https://www.software-express.de/hersteller/microsoft/sql-server/standard ...
@DerMaddin noch eine Frage zu SQL CALs: Werden die wirklich technisch geprüft? Ein Händler meinte ja, kann ich mir aber kaum vorstellen ist ja bei Windows oder Exchange CALs auch nicht so.
Und wie ist das mit euren 4x 2 Core, könnt ihr die nach Belieben zusammen führen oder zerlegen? Also z.B. einen Server mit 8 Core betreiben oder 2x 4 Core? Auch der Lizenzschlüssel soll bei OEM im Setup ausgeliefert werden, sagte man mir. Auch hier kenne ich das so das man sich die Dinger (bei Windows) einfach in den Schrank legt und halt hat.
Und wie ist das mit euren 4x 2 Core, könnt ihr die nach Belieben zusammen führen oder zerlegen? Also z.B. einen Server mit 8 Core betreiben oder 2x 4 Core? Auch der Lizenzschlüssel soll bei OEM im Setup ausgeliefert werden, sagte man mir. Auch hier kenne ich das so das man sich die Dinger (bei Windows) einfach in den Schrank legt und halt hat.
CSP gibts mit und ohne Subscription. Ohne nennt sch das dann Perpetual Licensing Programm.
Steht auch irgendwie bei https://www.software-express.de/hersteller/microsoft/csp/
Ist also der Nachfolger vom Open License Modell nur mit ohne Mindestmenge.
Aber besser liest mans bei https://www.softwareone.com/de-de/partner-blog/artikel/2021/10/01/micros ...
Scheinbar gibts da nur wenige Partner, die das anbieten dürfen.
CSP Subscription ist quasi ein Open Value mit SA. Nur halt bissi flexibler. Beim ersten Link von Software Express ist unten eine Vergleichstabelle. Ich finde übrigens auch, dass die die einzigen sind, die das mehr oder weniger gut erklären.
Steht auch irgendwie bei https://www.software-express.de/hersteller/microsoft/csp/
Ist also der Nachfolger vom Open License Modell nur mit ohne Mindestmenge.
Aber besser liest mans bei https://www.softwareone.com/de-de/partner-blog/artikel/2021/10/01/micros ...
Scheinbar gibts da nur wenige Partner, die das anbieten dürfen.
CSP Subscription ist quasi ein Open Value mit SA. Nur halt bissi flexibler. Beim ersten Link von Software Express ist unten eine Vergleichstabelle. Ich finde übrigens auch, dass die die einzigen sind, die das mehr oder weniger gut erklären.
Also ist Open Value keine Option für mich weil quasi tot und CSP Perpetual Licensing (Kauflizenz nur unaussprechbar) und CSP Abo sind beide möglich.
SA gibt es bei CSP nicht sondern Subscription aber dann vermutlich nur im Abo und nicht mit der Perpetual Licnece? Also Abo = Subscription?
2x 2 Core ~= 8.160 Euro
(keine Virtualisierung, unbegrenzt nutzbar)
2x 2 Core a 3 Jahre Laufzeit = 9.680 Euro
und das dann alle 3 Jahre...
SA gibt es bei CSP nicht sondern Subscription aber dann vermutlich nur im Abo und nicht mit der Perpetual Licnece? Also Abo = Subscription?
CSP Kauflizenz (2 Cores)
Netto: 4.080,60 €(keine Virtualisierung, unbegrenzt nutzbar)
CSP Subscription (2 Cores) – 1 Jahr Laufzeit
Netto: 1.926,76 €
CSP Subscription (2 Cores) – 3 Jahre Laufzeit
Netto: 4.840,09 €und das dann alle 3 Jahre...
Unsere "alten" 2016er Lizenzen könnten wir theoretisch auch aufteilen auf VMs/HW Server. Aber auch hier galt schon pro Server 4 Cores. Wir könnten also maximal 2 VMs betreiben. Ab 2019/2022 ist dies nicht mehr möglich mit einer OEM oder CSP Kauflizenz, zumindest nicht in einer virtuellen Umgebung. Hier ist SA erforderlich.
Das wird ein fetter Kostenfaktor ab 2026 für uns werden.
Das wird ein fetter Kostenfaktor ab 2026 für uns werden.
Jupp.
Und ja, das englische Wort für Abonnement ist Subscription.
Und ist im CSP nix anderes als das bekannte SA.
Perpetual ist halt fire and forget.
Der Knackpunkt ist, dass die bei SQL das Du-darfst-nicht-virtualisieren eingebaut haben.
Wenn du virtualisieren willst brauchst du SA oder CSP Subscription.
Und man muss da zwangsläufig das längste Modell wählen, da man fast davon ausgehen kann, dass die Preise steigen werden.
MS will halt auf Teufel komm raus von den Kauflizenzen weg.
Und ja, das englische Wort für Abonnement ist Subscription.
Und ist im CSP nix anderes als das bekannte SA.
Perpetual ist halt fire and forget.
Der Knackpunkt ist, dass die bei SQL das Du-darfst-nicht-virtualisieren eingebaut haben.
Wenn du virtualisieren willst brauchst du SA oder CSP Subscription.
Und man muss da zwangsläufig das längste Modell wählen, da man fast davon ausgehen kann, dass die Preise steigen werden.
MS will halt auf Teufel komm raus von den Kauflizenzen weg.
War für einen von euch ein nicht virtueller Datenbankserver je ein Thema, unabhängig vom Grund? Ich weiß noch man früher hier und dort gehört hat das die Virtualisierung hier schon ordentlich Performance weg frisst.
Ehrlich gesagt, kann ich mich nicht mehr erinnern, dass ich einen SQL-Server auf "Bare Metal" gesehen habe. Zumindest nicht vor 2010, seitdem ich in der IT-Infra tätig bin. Überwiegend hatte ich mit VMware ESXi zu tun (ab v5) und da wurden dann entsprechend der Workloads unter Umständen ein ganzer Host für SQL-VM Instanzen genutzt. Dies war aber eher der CPU/RAM Limitierung geschuldet. Dunkel erinnere ich mich noch an 2012 als wir vier neue Hosts gekauft haben. Je zwei Sockel mit je einer Xeon E5 ~3.2GHz 8 Core CPU und 128GB RAM.
Bei älteren Datenbanken wie Firebird ist das aber immer noch der Fall, dass HW deutlich performanter ist als VM-Umgebungen. Haben eine Applikation mit FB 2.5 im Einsatz. Erst nach ausgiebigen Tests (Mem, CPU, IOPS etc.) haben wir eine P2V-Migration durchgeführt, auch wenn die Performance im Benchmark um rund 30% gesunken ist. Für die Handvoll User war das kein Nachteil.
Bei älteren Datenbanken wie Firebird ist das aber immer noch der Fall, dass HW deutlich performanter ist als VM-Umgebungen. Haben eine Applikation mit FB 2.5 im Einsatz. Erst nach ausgiebigen Tests (Mem, CPU, IOPS etc.) haben wir eine P2V-Migration durchgeführt, auch wenn die Performance im Benchmark um rund 30% gesunken ist. Für die Handvoll User war das kein Nachteil.
Zitat von @ukulele-7:
Moin.
Einem dieser Hersteller wurde der Vertrag seitens Microsoft gekündigt, ich bekomme da keine neue Versionen drüber.
Danke
Moin.
Einem dieser Hersteller wurde der Vertrag seitens Microsoft gekündigt, ich bekomme da keine neue Versionen drüber.
Danke
Kannst du dazu mehr erzählen?
Moin,
Gruß,
Dani
Ehrlich gesagt, kann ich mich nicht mehr erinnern, dass ich einen SQL-Server auf "Bare Metal" gesehen habe.
immer dann, wenn es große Datenmengen sind, hohe I/O gefordert ist oder die Lizenzierung ein Bein stellt. Wir haben einige Cluster noch auf Hardware laufen.War für einen von euch ein nicht virtueller Datenbankserver je ein Thema, unabhängig vom Grund
Ja, wir haben das Thema jedes Mal wenn Hardware Refresh ansteht.Wenn einer die genaue Lizenzbestimmung irgendwo als Quelle bei Microsoft kennt würde ich das gerne mal im Wortlaut lesen...
In dem Microsoft Product Use Rights (PUR) für SQL-Server. Kannst du problemlos zum Einschlafen lesen. Hat jemand kürzlich SQL lizensiert und wie? Was bevorzugt Ihr, Core oder User CALs?
Ja, per Core. CALs würde uns teuer zu stehen kommen.Jetzt hat Microsoft in die Lizenzbedingungen für SQL 2022 sinngemäß rein geschrieben das OEM nicht virtualisiert werden darf, nur CSP mit aktiver Subscription oder Open Value mit SA.
siehe PUR.Wenn du virtualisieren willst brauchst du SA oder CSP Subscription.
Spätestens wenn du- Lizenz Mobilität nutzen möchtest (sprich VM wechselt innerhalb von 90 Tagen mehrfach den Virtualisierungshost)
- Failover Szenario mit Hilfe von Funktion des Hypervisors.
Gruß,
Dani
Zitat von @2423392070:
Kannst du dazu mehr erzählen?
Zitat von @ukulele-7:
Moin.
Einem dieser Hersteller wurde der Vertrag seitens Microsoft gekündigt, ich bekomme da keine neue Versionen drüber.
Danke
Moin.
Einem dieser Hersteller wurde der Vertrag seitens Microsoft gekündigt, ich bekomme da keine neue Versionen drüber.
Danke
Kannst du dazu mehr erzählen?
Der Systempartner vom Hersteller hat mir im Voraus gesagt das das seitens Microsoft gekündigt wurde. Ich habe das dann später auch per Mail bekommen, etwas verklausuliert:
aufgrund geänderter Bezugsmodalitäten und Einkaufskonditionen bei Microsoft müssen wir die bestehenden SQL-Maintenance-Verträge zum 31.12.2014 mit Wirkung zum 01.01.2015 umstellen.
Zukünftig werden die Microsoft-SQL-Maintenance für bezogene Microsoft SQL-Lizenzen lediglich mit einer befristeten Laufzeit für jeweils ein Jahr ausgestellt und berechnet. Um diese Umstellung möglichst unproblematisch abwickeln zu können, unterbreiten wir Ihnen für Ihren aktuellen SQL-Vertragsbestand laut beigefügter Vertragsbestandsliste eine Änderungskündigung für Altverträge mit Wirkung ab 01.01.2015.
Die Konditionen der neuen einjährigen Microsoft-SQL-Maintenance-Gebühren finden Sie im angehängten Bestellformular.
Auch wenn keine Umstellung der Maintenance-Verträge auf jährliche Laufzeit erfolgt und somit auf die Fortführung der Maintenance verzichtet wird, besteht bis zum Vertragsende (31.12.2014) das Recht, die aktuellen SQL-Versionen zu beziehen. Diese können Sie direkt über uns mit beigefügten Bestellformular beziehen.
Zukünftig werden die Microsoft-SQL-Maintenance für bezogene Microsoft SQL-Lizenzen lediglich mit einer befristeten Laufzeit für jeweils ein Jahr ausgestellt und berechnet. Um diese Umstellung möglichst unproblematisch abwickeln zu können, unterbreiten wir Ihnen für Ihren aktuellen SQL-Vertragsbestand laut beigefügter Vertragsbestandsliste eine Änderungskündigung für Altverträge mit Wirkung ab 01.01.2015.
Die Konditionen der neuen einjährigen Microsoft-SQL-Maintenance-Gebühren finden Sie im angehängten Bestellformular.
Auch wenn keine Umstellung der Maintenance-Verträge auf jährliche Laufzeit erfolgt und somit auf die Fortführung der Maintenance verzichtet wird, besteht bis zum Vertragsende (31.12.2014) das Recht, die aktuellen SQL-Versionen zu beziehen. Diese können Sie direkt über uns mit beigefügten Bestellformular beziehen.
Danke @Dani
Ja das mit Failover ist mir natürlich klar, bei 2 Hosts in meiner kleinen Butze kommt das quasi nicht vor, schon gar nicht automatisch.
Ich habe nicht die Anforderungen an Performance aber würde natürlich mehr Performance als Nebeneffekt einer Bare Metal Installation begrüßen. Der einzige ausschlaggebende Grund das zu machen wäre in meinem Fall die Lizensierung. Alles andere wäre mir den "Systembruch" weg von VM nicht wert, Die Lizenzkosten lassen mich aber schon grübeln.
Ja das mit Failover ist mir natürlich klar, bei 2 Hosts in meiner kleinen Butze kommt das quasi nicht vor, schon gar nicht automatisch.
Ich habe nicht die Anforderungen an Performance aber würde natürlich mehr Performance als Nebeneffekt einer Bare Metal Installation begrüßen. Der einzige ausschlaggebende Grund das zu machen wäre in meinem Fall die Lizensierung. Alles andere wäre mir den "Systembruch" weg von VM nicht wert, Die Lizenzkosten lassen mich aber schon grübeln.
Die PUR sind wirklich unbenutzbar, toll Microsoft.
Ich habe über Google verschiedene Dokumente aufgetan und mir angesehen:
Microsoft SQL Server 2022 Licensing guide
https://download.microsoft.com/download/9/3/d/93d32de6-f268-45ed-ba25-2f ...
SQL SERVER 2019 LICENSING DATASHEET
https://download.microsoft.com/download/f/0/d/f0d7004e-9e39-4991-853b-2a ...
SQL SERVER 2022 LICENSING DATASHEET
https://download.microsoft.com/download/0/f/4/0f4c1b3c-cbc4-4495-97e4-20 ...
Damit scheint es tatsächlich so zu sein das unter 2019 einfach die Kerne der VM lizensiert werden dürfen, unter 2022 SA oder Subscription vorhanden sein müssen. Ob OEM oder Volumen Lizenz ist dabei eigentlich völlig egal wobei das unter OEM natürlich nicht möglich ist. Das wollte ich hier nur nochmal exakt ausführen.
Ich schwanke jetzt zwischen einer OEM 2019 4-core (~ 3.440 Euro), einer OEM 2022 6-core (~7.320) Euro und dann Downgrade oder OEM 2022 Server + 40x CAL (~5.700 Euro*). Eigentlich reicht dann auch die 2019er, das mit der Hardware werde ich vermutlich nicht machen. Die OEM nach CALs hat diese Einschränkung mit gültiger SA oder Subscription nicht, nur die Core! Hier ginge also auch SQL 2022.
Ich habe über Google verschiedene Dokumente aufgetan und mir angesehen:
Microsoft SQL Server 2022 Licensing guide
https://download.microsoft.com/download/9/3/d/93d32de6-f268-45ed-ba25-2f ...
Overview
This licensing guide is for people who want to gain a basic understanding of how Microsoft® SQL Server® 2022 database software is licensed through Microsoft Volume Licensing programs. This guide does not supersede or replace any of the legal documentation covering SQL Server 2022 use rights. Specific product license terms are defined in the product Software License Terms—or in the case of Microsoft Volume Licensing—in the Microsoft Volume Licensing agreement under which the software was acquired and/or the Microsoft Volume Licensing Product Terms. This licensing guide is not a legal use rights document. Program specifications and business rules are subject to change.
Ich hab dann gar nicht weiter gelesen weil es sich bei OEM um kein Volumenlizenzprogram handelt.This licensing guide is for people who want to gain a basic understanding of how Microsoft® SQL Server® 2022 database software is licensed through Microsoft Volume Licensing programs. This guide does not supersede or replace any of the legal documentation covering SQL Server 2022 use rights. Specific product license terms are defined in the product Software License Terms—or in the case of Microsoft Volume Licensing—in the Microsoft Volume Licensing agreement under which the software was acquired and/or the Microsoft Volume Licensing Product Terms. This licensing guide is not a legal use rights document. Program specifications and business rules are subject to change.
SQL SERVER 2019 LICENSING DATASHEET
https://download.microsoft.com/download/f/0/d/f0d7004e-9e39-4991-853b-2a ...
Licensing for virtualization and containers
INDIVIDUAL VIRTUAL MACHINES OR CONTAINERS
[...] When deploying databases on Virtual Machines (VMs) or containers that use just a fraction of a physical server, savings can be achieved by licensing individual VMs or containers.
To license a VM or container with core licenses, purchase a core license for each virtual core (virtual thread) allocated to the VM or the number of cores configured for access by the container (with a minimum of 4 core licenses per VM or container).
(Seite 3/4)INDIVIDUAL VIRTUAL MACHINES OR CONTAINERS
[...] When deploying databases on Virtual Machines (VMs) or containers that use just a fraction of a physical server, savings can be achieved by licensing individual VMs or containers.
To license a VM or container with core licenses, purchase a core license for each virtual core (virtual thread) allocated to the VM or the number of cores configured for access by the container (with a minimum of 4 core licenses per VM or container).
SQL SERVER 2022 LICENSING DATASHEET
https://download.microsoft.com/download/0/f/4/0f4c1b3c-cbc4-4495-97e4-20 ...
Licensing for virtualization and containers
INDIVIDUAL VIRTUAL MACHINES OR CONTAINERS
[...] When deploying databases on Virtual Machines (VMs) or containers that use just a fraction of a physical server, savings can be achieved by licensing individual VMs or containers. Licensing SQL Server 2022 by VM or container is an option under core subscription licenses or licenses with SA only.
Note: When licensing VMs or containers under the Server + CAL model, the number of virtual or physical cores does not affect the number of server licenses required.
To license a VM or container with core licenses, purchase a core subscription license or license with SA for each virtual core (virtual thread) allocated to the VM or the number of cores configured for access by the container (with a minimum of 4 licenses per VM or container).
(Seite 2/3)INDIVIDUAL VIRTUAL MACHINES OR CONTAINERS
[...] When deploying databases on Virtual Machines (VMs) or containers that use just a fraction of a physical server, savings can be achieved by licensing individual VMs or containers. Licensing SQL Server 2022 by VM or container is an option under core subscription licenses or licenses with SA only.
Note: When licensing VMs or containers under the Server + CAL model, the number of virtual or physical cores does not affect the number of server licenses required.
To license a VM or container with core licenses, purchase a core subscription license or license with SA for each virtual core (virtual thread) allocated to the VM or the number of cores configured for access by the container (with a minimum of 4 licenses per VM or container).
Damit scheint es tatsächlich so zu sein das unter 2019 einfach die Kerne der VM lizensiert werden dürfen, unter 2022 SA oder Subscription vorhanden sein müssen. Ob OEM oder Volumen Lizenz ist dabei eigentlich völlig egal wobei das unter OEM natürlich nicht möglich ist. Das wollte ich hier nur nochmal exakt ausführen.
Ich schwanke jetzt zwischen einer OEM 2019 4-core (~ 3.440 Euro), einer OEM 2022 6-core (~7.320) Euro und dann Downgrade oder OEM 2022 Server + 40x CAL (~5.700 Euro*). Eigentlich reicht dann auch die 2019er, das mit der Hardware werde ich vermutlich nicht machen. Die OEM nach CALs hat diese Einschränkung mit gültiger SA oder Subscription nicht, nur die Core! Hier ginge also auch SQL 2022.
- Edit am 03.04.2023 5.700 Euro statt 5.100 Euro.
1
So ich habe mittlerweile mit einem Händler gesprochen der sich deutlich sicherer im MS Lizenzgeschäft auskennt.
Ein paar wichtige Dinge muss ich korrigieren:
In dem Gespräch hat sich dann auch gezeigt das mein Lizenzhändler (siehe meine o.g. Vergleichspreise) dem Graumarkt angehört. Zum einen habe ich dort OEM Lizenzen angefragt und angeboten hat man mir (auch wenn es im Angebot nicht klar kenntlich gemacht wurde) Open Value Lizenzen. Vermutlich werden hier Open Value Lizenzen eingekauft und dann zerlegt weiter veräußert, wie das genau legal ablaufen soll das ist nicht klar, wer Lizenznehmer gegenüber Microsoft ist, ist nicht klar. Das ganze zu einem Preis der unter dem Deutschen EK für Microsoft Gold Partner liegt...
Eine OEM kommt mit physischem Echtheitszertifikat daher, das habe ich mir jetzt anbieten lassen. Wegen der Lizenzbeschränkung muss es Server + CAL sein, kostet aber immer noch weniger als eine Core Lizenz im CSP mit Subscription oder eine Open Value mit SA und muss eben nicht nach 3 Jahren "erneuert" werden.
Ein paar wichtige Dinge muss ich korrigieren:
- Es gibt nach wie vor Open Value, auch für Neukunden, nur Open Licence gibt es nicht mehr.
- Bei der CSP Subscription entspricht die Subscription umgerechnet dem Kaufpreis, eine Verlängerung der Subsccrition entspricht also quasi ein Neukauf. (Bei meiner Kalkulation hat sich gezeigt das Open Value erstmal etwas teurer ist aber durch SA Verlängerungen bei mehr als 6 Jahren Laufzeit günstiger wird. Natürlich ist das kaum zu kalkulieren weil Microsoft die Preise durchaus unterschiedlich anheben kann.)
- CSP inkl. Subscription vs. Open Value inkl. SA: CSP verhält sich wie ein Mietmodel (obwohl es Kauflizenz heißt?!?), wohingegen Open Value auch nach Ende Eigentum bleibt. So ganz verstehe ich das nicht, Exchange habe ich auch im CSP erworben und darf es weiter nutzen, da läuft meiner Meinung nach nichts aus aber verstehe das wer will...
- Kauf einer SQL 2022 Core-Lizenz und Downgrade durch Nutzung einer SQL 2019 ändert nichts an den Einschränkungen für Virtualisierung. Es gelten die Lizenzbedingungen der Version zum Kaufdatum, also die von SQL 2022. Direkt eine SQL 2019 Core-Lizenz erwerben und virtualisieren hingegen ist völlig Lizenzkonform, die problematische Einschränkung ist nach wie vor kein Bestandteil von SQL 2019.
In dem Gespräch hat sich dann auch gezeigt das mein Lizenzhändler (siehe meine o.g. Vergleichspreise) dem Graumarkt angehört. Zum einen habe ich dort OEM Lizenzen angefragt und angeboten hat man mir (auch wenn es im Angebot nicht klar kenntlich gemacht wurde) Open Value Lizenzen. Vermutlich werden hier Open Value Lizenzen eingekauft und dann zerlegt weiter veräußert, wie das genau legal ablaufen soll das ist nicht klar, wer Lizenznehmer gegenüber Microsoft ist, ist nicht klar. Das ganze zu einem Preis der unter dem Deutschen EK für Microsoft Gold Partner liegt...
Eine OEM kommt mit physischem Echtheitszertifikat daher, das habe ich mir jetzt anbieten lassen. Wegen der Lizenzbeschränkung muss es Server + CAL sein, kostet aber immer noch weniger als eine Core Lizenz im CSP mit Subscription oder eine Open Value mit SA und muss eben nicht nach 3 Jahren "erneuert" werden.
1
Geht das bei euch als Lösung durch?
Unser Dev-Lead will ernsthaft auf MSSQL in Zukunft verzichten. MS kommt Ende April und wird sicherlich versuchen über den Preis das zu regeln. Wir sind aber wirklich etwas angepisst.
Keine Ahnung wie lange wir das noch mitmachen wollen. Zumal ein normaler IT Pro das fortlaufend auch nicht ohne weiteres überblicken kann.
Unser Dev-Lead will ernsthaft auf MSSQL in Zukunft verzichten. MS kommt Ende April und wird sicherlich versuchen über den Preis das zu regeln. Wir sind aber wirklich etwas angepisst.
Keine Ahnung wie lange wir das noch mitmachen wollen. Zumal ein normaler IT Pro das fortlaufend auch nicht ohne weiteres überblicken kann.
Ich kaufe meine Lizenzen (bisher aber immer nur OS und Office) als OEM oder gebraucht von einem Händler, der da immer ein Zertifikat oder aber die Lizenzübertragung mit beilegt. Letztere hat man dann auch immer schriftlich zu bestätigen. Teurer als bei Amazon, aber immer noch günstig und rechtssicher.
Obwohl ich gerade sehe, dass der gar keine OEM mehr anbietet. Nur noch gebraucht.
Alle Server-Lizenzen und CALs kommen vom Systemhaus.
Microsoft hat mit dem CSP im Grunde nur ein Re-Branding durchgeführt und die Open License sterben lassen. Ich hab mal ein wenig verglichen und da ist meistens die CSP Subscription günstiger als die OV SA.
Der Vorteil bei der OV SA war bisher immer die 3jährige Laufzeit und somit längere Preisgarantie. CSP Subscription gabs ja anfangs noch nicht für 3 Jahre, sollte jetzt aber auch möglich sein (habe ich zumindest gehört).
Der Hammer bei SQL ist ja das Entfernen der Virtualisierungsmöglichkeit. Hat man jetzt "nur" 40 User, dann rechnet man da schon nach und überlegt. Hat man aber mehr, sodass die Core-Lizenzierung immer günstiger ist als die Server-Cal-Lizenzierung, dann dürften viele nicht mehr so genau drauf schauen. Hauptsache günstiger als mit CAL und damit gut. Egal, wie teuer die Core-Packs sind.
Ich habe die Befürchtung, da kommt noch mehr Übles auf uns zu. Zukünftig wirds wohl nur noch CSP geben, wobei Perpetual eher totgeschwiegen werden wird.
Obwohl ich gerade sehe, dass der gar keine OEM mehr anbietet. Nur noch gebraucht.
Alle Server-Lizenzen und CALs kommen vom Systemhaus.
Microsoft hat mit dem CSP im Grunde nur ein Re-Branding durchgeführt und die Open License sterben lassen. Ich hab mal ein wenig verglichen und da ist meistens die CSP Subscription günstiger als die OV SA.
Der Vorteil bei der OV SA war bisher immer die 3jährige Laufzeit und somit längere Preisgarantie. CSP Subscription gabs ja anfangs noch nicht für 3 Jahre, sollte jetzt aber auch möglich sein (habe ich zumindest gehört).
Der Hammer bei SQL ist ja das Entfernen der Virtualisierungsmöglichkeit. Hat man jetzt "nur" 40 User, dann rechnet man da schon nach und überlegt. Hat man aber mehr, sodass die Core-Lizenzierung immer günstiger ist als die Server-Cal-Lizenzierung, dann dürften viele nicht mehr so genau drauf schauen. Hauptsache günstiger als mit CAL und damit gut. Egal, wie teuer die Core-Packs sind.
Ich habe die Befürchtung, da kommt noch mehr Übles auf uns zu. Zukünftig wirds wohl nur noch CSP geben, wobei Perpetual eher totgeschwiegen werden wird.
Zitat von @2423392070:
Geht das bei euch als Lösung durch?
Das wird jetzt so gekauft falls du das meinst.Geht das bei euch als Lösung durch?
MSSQL hat einige Vorteile für mich weil ich damit sehr vertraut bin und viele Anwendungen das bei uns auch voraussetzen oder zumindest damit ursprünglich installiert wurden. Bei unserem DMS habe ich mal angefragt ob man nicht auf PostgreSQL wechseln könnte aber das wird mit hohen Migrationskosten verbunden sein - ich will das nicht ausschließen aber mit dem SQL 2022 fahre ich jetzt vermutlich erstmal wieder 10 Jahre damit. Eventuell finde ich eine andere, weniger kritische Anwendung mit der ich mehr Postgres etablieren kann. Ich hab damit auch schon getestet aber noch nichts produktiv am laufen und ich bin auch nicht der Crack der sich eben mal alles neu beibringt.
Über die Zukunft mache ich mir auch so meine Gedanken, das größere Problem sehe ich aber mit Terminal Servern und Office und dem 365 Zwang. Mit unter 40 Usern sind wir jetzt aber einfach nicht relevant und mein Chef findet die MS Cloud eher toll.
@kpunkt
CSP Subscription gibt's glaube ich nicht für alle Produkte mit 3 Jahre, wie bei SQL. Grundsätzlich kaufe ich auch lieber physische Lizenzträger und das anonym gegenüber Microsoft. Bei Exchange musste ich aber jetzt auch im CSP kaufen.
Interessant ist das OEM bei SQL tatsächlich zwischendurch nicht verfügbar war und mit 2019 wieder eingeführt wurde. Und das obwohl MS ja scheinbar sowohl bei ISV als auch bei anderen Core Lizenzen die Dauemenschrauben anzieht, das ist schon ein verrückter Haufen.
Wir würden auch nur neue Dienste umstellen. Der Bestand würde eingefroren auf MSSQL bleiben.
Wir würden im Mai oder Juni die neuen Mx760c mit bis zu 8 TB RAM für die beiden SQL Cluster in Betrieb nehmen, also auf Hardwarebasis und dann muss eine Lösung ran in den Support-Jahren. Wir haben fünf vereinbart.
Wie wir in fünf Jahren da stehen, weiß der liebe Gott.
Durch Container, Mikro-Segmentierung usw explodiert unser Bedarf an SQL und unsere Gutgläubigkeit in MS wird gerade Mal wieder bestraft.
Saftladen.
Wir würden im Mai oder Juni die neuen Mx760c mit bis zu 8 TB RAM für die beiden SQL Cluster in Betrieb nehmen, also auf Hardwarebasis und dann muss eine Lösung ran in den Support-Jahren. Wir haben fünf vereinbart.
Wie wir in fünf Jahren da stehen, weiß der liebe Gott.
Durch Container, Mikro-Segmentierung usw explodiert unser Bedarf an SQL und unsere Gutgläubigkeit in MS wird gerade Mal wieder bestraft.
Saftladen.
Was den Umfang angeht ist das halt ne ganz andere Nummer aber grundsätzlich glaube ich das man mit Postgres sowieso besser fährt. MSSQL ist ein technisch gutes Produkt mit furchtbaren Lizenzbedingungen und bedroht durch den Wahn alles nach Azure verlagern zu wollen.
PG ist einfach anders wenn man mal vom gewöhnlichen SQL absieht. Ich hab hier in einigen Projekten diverse Scripte und SPs die auf die CMD zugreifen und Dateien vom Dateisystem importieren und dann Informationen aus dem HTML auslesen und in Tabellen schreiben. Ich habe mal versucht das auf PG um zu schreiben, das war sehr frustrierend und hat nicht geklappt.
PG ist einfach anders wenn man mal vom gewöhnlichen SQL absieht. Ich hab hier in einigen Projekten diverse Scripte und SPs die auf die CMD zugreifen und Dateien vom Dateisystem importieren und dann Informationen aus dem HTML auslesen und in Tabellen schreiben. Ich habe mal versucht das auf PG um zu schreiben, das war sehr frustrierend und hat nicht geklappt.
Die Masse unseres In- und Outputs geht über WCF. Direkt mit der Datenbank arbeitet nur das Cluster, Backup und ein paar ausgesuchte Devs.
Ich für meinen Teil störe mich an der erschwerten Planung der Zyklen für z. B. Hardware und Konfigurationen. Wir wollen gerne auf sieben Jahre.
Mein Dev-Lead stört sich mittlerweile an der Gier und macht was persönliches draus.
Wir haben noch unzählige kleine MSSQL Baustellen über die Virtualisierungen verteilt und jetzt richtig Arbeit vor uns.
Nach Ostern ist Beratung dazu. Ende April kommt MS und wird direkt auf dem Parkplatz angepasst und in den Kofferraum verladen.
Ich für meinen Teil störe mich an der erschwerten Planung der Zyklen für z. B. Hardware und Konfigurationen. Wir wollen gerne auf sieben Jahre.
Mein Dev-Lead stört sich mittlerweile an der Gier und macht was persönliches draus.
Wir haben noch unzählige kleine MSSQL Baustellen über die Virtualisierungen verteilt und jetzt richtig Arbeit vor uns.
Nach Ostern ist Beratung dazu. Ende April kommt MS und wird direkt auf dem Parkplatz angepasst und in den Kofferraum verladen.
Na da bin ich auf das Resultat gespannt.
Moin @ukulele-7,
ja, das ist ab SQL 2022 tatsächlich so! 😔🤢🤮
Und in den aktuellen SQL Server 2022 Lizenbedingungen ...
https://www.microsoft.com/en-us/sql-server/sql-server-2022-pricing
https://go.microsoft.com/fwlink/p/?linkid=2215573&clcid=0x409&cu ...
... steht das auch genau so geschrieben.
Seite 17:
Seite 18:
und
und auch das ist nicht unwichtig.
Sprich, ja, Microsoft möchte uns beim SQL Server 2022 tatsächlich vorschreiben, dass man eine Core Lizenzierung auf einer VM nur noch über "subscription license or license with Software Assurance" machen darf und das auch nur mit der Standard Edition.
Ganz ehrlich, damit ist MS meiner Meinung nach nun vollends über das Ziel hinausgeschossen und ich halte das rechtlich auch nicht wirklich für haltbar, da eine VM niemals einem Baremetale-System überlegen ist und daher bei der Lizenzierung auch nicht anders, zumindest nicht nachteiliger behandelt werden darf.
Sprich, wenn ich mir 4 SQL Server Cores kaufe, dann ist es meiner Ansicht nach meine Entscheidung ob ich diese für physikalische oder virtuelle CPU's nutze und nicht die des Herstellers!
Solcher Unfug wie ihn mittlerweile viele Softwarehersteller mittlerweile treiben muss schleunigst gesetzlich geregelt/eingedämmt werden!
Das Lustige ist, dieser ganze "must purchase a core subscription license or license with Software Assurance" Schwachsinn gilt nur für die Core Lizenzierung.
Denn bei der CAL Lizenzierung ...
Seite 18:
Seite 19:
... kann man weiterhin ohne "subscription license or license with Software Assurance" lizenzieren. 😖
Oh jäh, ich fürchte ich muss diesbezüglich gleich mal am Jahresanfang einen kleinen Haufen in den MS-Vertriebsforen bei LinkedIn hiterlassen. 😎🤪
Gruss Alex
Jetzt hat Microsoft in die Lizenzbedingungen für SQL 2022 sinngemäß rein geschrieben das OEM nicht virtualisiert werden darf, nur CSP mit aktiver Subscription oder Open Value mit SA.
ja, das ist ab SQL 2022 tatsächlich so! 😔🤢🤮
Ich habe dazu bisher leider keine Quelle gefunden, ich habe das nur von Dritten als Information. In SQL 2019 gab es keine solche Einschränkung, 4 Core OEM durfte als VM mit 4 vCore betrieben werden.
Und in den aktuellen SQL Server 2022 Lizenbedingungen ...
https://www.microsoft.com/en-us/sql-server/sql-server-2022-pricing
https://go.microsoft.com/fwlink/p/?linkid=2215573&clcid=0x409&cu ...
... steht das auch genau so geschrieben.
Seite 17:
"Beginning with SQL Server 2022, licensing by virtual machine is an option under subscription licenses or licenses with Software Assurance only."
Seite 18:
"To license individual VMs using the Per Core model, customers must purchase a core subscription license or license with Software Assurance for each v-core (or virtual processor, virtual CPU, virtual thread) allocated to the VM, subject to a four-core license minimum per VM. For licensing purposes, a v-core maps to a hardware thread."
und
"Licensing individual VMs is the only licensing option available for SQL Server Standard Edition customers who are running the software in a virtualized environment under the Per Core model."
und auch das ist nicht unwichtig.
"There is a minimum of four core subscription licenses or licenses with Software Assurance required for each virtual machine"
Sprich, ja, Microsoft möchte uns beim SQL Server 2022 tatsächlich vorschreiben, dass man eine Core Lizenzierung auf einer VM nur noch über "subscription license or license with Software Assurance" machen darf und das auch nur mit der Standard Edition.
Ganz ehrlich, damit ist MS meiner Meinung nach nun vollends über das Ziel hinausgeschossen und ich halte das rechtlich auch nicht wirklich für haltbar, da eine VM niemals einem Baremetale-System überlegen ist und daher bei der Lizenzierung auch nicht anders, zumindest nicht nachteiliger behandelt werden darf.
Sprich, wenn ich mir 4 SQL Server Cores kaufe, dann ist es meiner Ansicht nach meine Entscheidung ob ich diese für physikalische oder virtuelle CPU's nutze und nicht die des Herstellers!
Solcher Unfug wie ihn mittlerweile viele Softwarehersteller mittlerweile treiben muss schleunigst gesetzlich geregelt/eingedämmt werden!
Das Lustige ist, dieser ganze "must purchase a core subscription license or license with Software Assurance" Schwachsinn gilt nur für die Core Lizenzierung.
Denn bei der CAL Lizenzierung ...
Seite 18:
"To license individual VMs using the Server+CAL model, customers simply purchase one server license for each VM running SQL Server software, regardless of the number of virtual processors allocated to the VM."
Seite 19:
"For example, a customer who wants to deploy Standard Edition running in six VMs, each allocated with four v-cores, would need to assign six SQL Server Standard server licenses to that server."
... kann man weiterhin ohne "subscription license or license with Software Assurance" lizenzieren. 😖
Oh jäh, ich fürchte ich muss diesbezüglich gleich mal am Jahresanfang einen kleinen Haufen in den MS-Vertriebsforen bei LinkedIn hiterlassen. 😎🤪
Gruss Alex
Ob das rechtlich so haltbar ist habe ich jetzt nicht hinterfragt, ich könnte mir aber vorstellen das das zulässig ist. Ich wüsste auch nicht wie man das sinnvoll gesetzlich eindämmen könnte.
Technisch wird Microsoft wohl kaum prüfen, ob es sich um eine VM handelt. Wer OEM kauft hat vielleicht auch keine anderen Open Licence oder sonstige Verträge, dann ist mit Lizenz-Audit erstmal nichts Mir war das dann aber doch zu hakelig und ich habe für die CAL Lizensierung im enteffekt jetzt auch weniger bezahlt.
Alternativ kann man vermutlich OEM unter Linux auf Bare Metal betreiben, hat auch einen gewissen Reiz. Aber der Mehraufwand ist natürlich nicht zu unterschätzen (Hardware-Verfügbarkeit, Datensicherung, etc.).
Technisch wird Microsoft wohl kaum prüfen, ob es sich um eine VM handelt. Wer OEM kauft hat vielleicht auch keine anderen Open Licence oder sonstige Verträge, dann ist mit Lizenz-Audit erstmal nichts
Mir war das dann aber doch zu hakelig und ich habe für die CAL Lizensierung im enteffekt jetzt auch weniger bezahlt.Alternativ kann man vermutlich OEM unter Linux auf Bare Metal betreiben, hat auch einen gewissen Reiz. Aber der Mehraufwand ist natürlich nicht zu unterschätzen (Hardware-Verfügbarkeit, Datensicherung, etc.).
Kleines Update.
So, das erste Häufchen ...
https://www.linkedin.com/feed/update/urn:li:activity:7147888722896646145
... ist schon platziert. 😁
Oh jäh, ich fürchte ich muss diesbezüglich gleich mal am Jahresanfang einen kleinen Haufen in den MS-Vertriebsforen bei LinkedIn hiterlassen. 😎🤪
So, das erste Häufchen ...
https://www.linkedin.com/feed/update/urn:li:activity:7147888722896646145
... ist schon platziert. 😁
Moin @ukulele-7,
Ich halte das rechtlich überhaupt nicht für haltbar, weil es dafür, sprich einen vCore anders als einen pCore zu behandeln, rein technisch überhaupt keinen Grund gibt.
Denke einfach mal an die Anfänge der Mobilfunkprovider, die haben bevor es hier eine gesetzliche Regelungen gab,
den Kunden auch sehr gerne sehr tief in die Taschen gegriffen.
Vorsicht mit solchen Anspielungen, manche Kollegen hier sehen in sowas bereits schon eine Anstiftung zu einer Steuerhinterziehung. 🙃
Gruss Alex
Ob das rechtlich so haltbar ist habe ich jetzt nicht hinterfragt, ich könnte mir aber vorstellen das das zulässig ist.
Ich halte das rechtlich überhaupt nicht für haltbar, weil es dafür, sprich einen vCore anders als einen pCore zu behandeln, rein technisch überhaupt keinen Grund gibt.
Ich wüsste auch nicht wie man das sinnvoll gesetzlich eindämmen könnte.
Denke einfach mal an die Anfänge der Mobilfunkprovider, die haben bevor es hier eine gesetzliche Regelungen gab,
den Kunden auch sehr gerne sehr tief in die Taschen gegriffen.
Technisch wird Microsoft wohl kaum prüfen, ob es sich um eine VM handelt. Wer OEM kauft hat vielleicht auch keine anderen Open Licence oder sonstige Verträge, dann ist mit Lizenz-Audit erstmal nichts
Vorsicht mit solchen Anspielungen, manche Kollegen hier sehen in sowas bereits schon eine Anstiftung zu einer Steuerhinterziehung. 🙃
Gruss Alex
Moin,
Kann man aus meiner Sicht nicht vergleichen. Alleine schon die Lobby ist eine ganz andere und die Macht von Microsoft ist damit nicht ansatzweise mit unseren Mobilfunkanbietern vergleichbar. Zudem gibt es meines Wissens nach bis dato kein Gerichtsurteil für PURs, Lizenzen, etc. Das was ich bis dato kenne, wurde immer mit einem Vergleich abgeschlossen.
Gruß,
Dani
Technisch wird Microsoft wohl kaum prüfen, ob es sich um eine VM handelt.
such dir was aus - Geräte Treiber, CPU Typ, MAC-Adresse, etc. Es gibt genug Anhaltspunkte, um das technisch zu prüfen.Denke einfach mal an die Anfänge der Mobilfunkprovider, die haben bevor es hier eine gesetzliche Regelungen gab,
den Kunden auch sehr gerne sehr tief in die Taschen gegriffen.Kann man aus meiner Sicht nicht vergleichen. Alleine schon die Lobby ist eine ganz andere und die Macht von Microsoft ist damit nicht ansatzweise mit unseren Mobilfunkanbietern vergleichbar. Zudem gibt es meines Wissens nach bis dato kein Gerichtsurteil für PURs, Lizenzen, etc. Das was ich bis dato kenne, wurde immer mit einem Vergleich abgeschlossen.
Vorsicht mit solchen Anspielungen, manche Kollegen hier sehen in sowas bereits schon eine Anstiftung zu einer Steuerhinterziehung. 🙃
Die Verantwortung hat jeder selbst. Man muss eben abwägen welche Konsequenzen es für sich und sein Arbeitgeber hat. Das kann je nach Umfang (wie lange, um wie viel, etc.) kostspielig werden. Daher abwiegen, dokumentieren und absichern. Gefährlicher sind aus Erfahrung ehemalige Mitarbeiter, die wirklich böses wollen. Da sind mir persönlich leider 2-3 Fälle bekannt, wo Microsoft und dann auch der Staat das volle Programm aufgefahren hat. Alternativ kann man vermutlich OEM unter Linux auf Bare Metal betreiben, hat auch einen gewissen Reiz. Aber der Mehraufwand ist natürlich nicht zu unterschätzen (Hardware-Verfügbarkeit, Datensicherung, etc.).
Das muss man sich - leider - wieder ernsthaft überlegen. Alternativ wenn es genug SQL-Server sind eben dedizierte Hypervisors bereitstellen, auf denen eben nur diese VMs laufen können. Wird sich aber vermutlich für die wenigsten hier im Forum wirtschaftlich rechnen.Gruß,
Dani
Zitat von @Dani:
Ich sage nicht das das nicht theoretisch geht, ich sage nur das Microsoft das nicht macht. Wenn ich mir CAL Lizenzen im allgemeinen bei Microsoft angucke wird hier nur bei RDS geprüft, nicht aber bei Windows oder Exchange. Viele Microsoft Lizenzen werden technisch nicht durch gesetzt, eben weil es viele Probleme verursachen kann. Das gleiche gilt eigentlich auch für Server. Ja, bei der Aktivierung kann man ja mal gucken ob es eine VM ist. Aber im laufenden Betrieb will man das sicher nicht ständig abfragen. Und soll die Aktivierung dann zwischen Core und CAL und zwischen OEM und SA Keys unterscheiden? Vermutlich kann sie das gar nicht. Würde mich jedenfalls sehr wundern wenn Microsoft hier die Energie aufbringt so einen Lizensierungs-Schluck-auf auch technisch abzubilden.Technisch wird Microsoft wohl kaum prüfen, ob es sich um eine VM handelt.
such dir was aus - Geräte Treiber, CPU Typ, MAC-Adresse, etc. Es gibt genug Anhaltspunkte, um das technisch zu prüfen.Alternativ kann man vermutlich OEM unter Linux auf Bare Metal betreiben, hat auch einen gewissen Reiz. Aber der Mehraufwand ist natürlich nicht zu unterschätzen (Hardware-Verfügbarkeit, Datensicherung, etc.).
Das muss man sich - leider - wieder ernsthaft überlegen. Alternativ wenn es genug SQL-Server sind eben dedizierte Hypervisors bereitstellen, auf denen eben nur diese VMs laufen können. Wird sich aber vermutlich für die wenigsten hier im Forum wirtschaftlich rechnen.
Moin,
Gruß,
Dani
Ich sage nicht das das nicht theoretisch geht, ich sage nur das Microsoft das nicht macht.
dann habe ich deine Aussage falsch aufgefasst. Ich habe nichts gesagt.Und soll die Aktivierung dann zwischen Core und CAL und zwischen OEM und SA Keys unterscheiden? Vermutlich kann sie das gar nicht
Die Unterscheidung, um welche Art von Lizenztyp des Produkt/Key es sich handelt, ist jetzt schon möglich. Wenn auch nur manuell. Von daher denke ich ist die Umsetzung auch für CALs problemlos möglich. Vermutlich wurde in dieser Hinsicht abgesehen mit einer Führung der Cloud und deren Lizenz Modell. Damit könnte man hoffen langfristig das Problem aus dem Weg zu gehen.Ein dedizierter Hypervisor bleibt doch aber auch ein Hypervisor, sollte auch nicht unter OEM Core Lizenz laufen.
Danke für deine explizite Ergänzung. Für mich war die Einschränkung klar und bedurfte keine Wiederholung.Gruß,
Dani
