Lizenzierung von SQL Server 2012

Transkript

1 Lizenzierung von SQL Server 2012

2 SQL Server 2012 bietet zwei Lizenzoptionen: das Core-basierte Lizenzmodell, dessen Maßeinheit die Anzahl der Prozessorkerne und damit die Rechenleistung der Server-Hardware ist, sowie das Server/CAL-Lizenzmodell, das aus Serverlizenzen sowie Zugriffslizenzen entsprechend der Anzahl der zugreifenden Nutzer beziehungsweise Geräte besteht. Welches Lizenzmodell anwendbar ist, richtet sich nach der Edition von SQL Server 2012: SQL Server 2012 Enterprise beinhaltet sämtliche Features der SQL Server 2012-Lösung und ist damit die beste Wahl für geschäftskritische Anwendungen und Data Warehousing. SQL Server 2012 Enterprise kann ausschließlich im Core-basierten Modell lizenziert werden. SQL Server 2012 Standard ist ideal für grundlegende Datenbank-, Reporting- und Analysefunktionen und kann wahlweise mit Core-Lizenzen oder im Server/CAL-Lizenzmodell lizenziert werden. SQL Server 2012 Business Intelligence ist spezialisiert auf hochwertige unternehmensweite und Self-Service Business Intelligence und kann ausschließlich im Server/CAL-Lizenzmodell lizenziert werden.

3 Beginnen wir zunächst mit den Grundprinzipien des Core-basierten Lizenzmodells, anwendbar auf SQL Server 2012 Enterprise und Standard. Grundsätzlich müssen alle physischen Cores der Prozessoren in einem Server lizenziert werden. Die Anzahl der Cores pro Prozessor ergibt die Anzahl der erforderlichen Core-Lizenzen. Ein physischer Core ist dabei ein Core in einem physischen Prozessor auf einem Server. Lizenzrechtlich gesehen ist ein Server jedes physische Hardwaresystem, das fähig ist, die Serversoftware auszuführen. Ein Blade beziehungsweise eine Hardwarepartition gilt als separater Server und ist daher extra zu lizenzieren. Der Server oben auf dieser Folie hat zwei Prozessoren mit jeweils vier physischen Cores, so genannte Quadcore-Prozessoren. Für jeden Prozessor sind vier Core-Lizenzen erforderlich, insgesamt für diesen Server also acht Core-Lizenzen, entweder für SQL Server 2012 Enterprise oder SQL Server 2012 Standard. Der untere Server auf der Folie hat ebenfalls zwei Prozessoren, allerdings handelt es sich hier um Dual- Core-Prozessoren mit jeweils nur zwei physischen Cores. Auch in diesem Fall sind pro Prozessor vier Core-Lizenzen erforderlich, insgesamt also acht Core-Lizenzen. Warum acht Core-Lizenzen und nicht nur die Summer der existierenden Cores also vier? Der Grund liegt im lizenzrechtlichen Minimum, welches erfordert, dass pro Prozessor mindestens vier Core- Lizenzen zugewiesen werden müssen. Mit anderen Worten: Für jeden Prozessor mit bis zu vier Cores sind immer vier Core-Lizenzen erforderlich. Nach oben gibt es keine Grenze: Ein Hexacore-Prozessor mit sechs Cores erfordert sechs Core- Lizenzen, ein Prozessor mit acht Cores erfordert acht Core-Lizenzen und so weiter. Zusammenfassend kann man also sagen: Die Anzahl der erforderlichen Core-Lizenzen ergibt sich aus der Anzahl der physischen Cores pro Prozessor, mit einer Mindestmenge von vier Core-Lizenzen pro Prozessor. Man kann es aber auch so ausdrücken: Die Anzahl der erforderlichen Core-Lizenzen entspricht der Anzahl der physischen Cores, multipliziert mit dem anwendbaren Core-Faktor.

4 Was ist der Core-Faktor? Der Core-Faktor ist ein numerischer Wert, der mit einem physischen Prozessor verbunden ist und dazu dient, die Anzahl der Lizenzen zu bestimmen, die zur Lizenzierung aller physischen Cores auf einem Server erforderlich sind. Die SQL Server Core-Faktortabelle ist seit Erscheinen von SQL Server 2012 im April 2012 gültig und kann von der Microsoft Download-Website heruntergeladen werden. Für die überwiegende Mehrheit aller Prozessoren gilt Core-Faktor 1, wie aus der ersten Zeile der Tabelle ersichtlich ist. Für einen Prozessor mit vier Cores bedeutet das vier Core-Lizenzen, für einen Prozessor mit sechs Cores sechs Core-Lizenzen, für einen Prozessor mit acht Cores acht Core-Lizenzen und so weiter. Für bestimmte AMD-Prozessoren ist ein Core-Faktor von 0,75 festgelegt. Ein Beispiel zur Verdeutlichung: Zur Lizenzierung eines Servers mit zwei INTEL-Prozessoren mit jeweils sechs Cores sind zwölf Core- Lizenzen erforderlich: zwei Prozessoren mal sechs Cores multipliziert mit Core-Faktor 1. Zur Lizenzierung eines Servers mit zwei AMD-Prozessoren der Serien 31, 32, 41, 42, 61 oder 62 mit jeweils sechs Cores sind neun Core-Lizenzen erforderlich: zwei Prozessoren mal sechs Cores multipliziert mit Core-Faktor 0,75. Für Prozessoren mit nur einem oder zwei Cores gelten Core-Faktoren, die größer als 1 sind. Um die Mindestmenge von vier Core-Lizenzen pro Prozessor zu erreichen, gilt für Dual-Core-Prozessoren Core-Faktor 2, und bei Single Core-Prozessoren gilt Core-Faktor 4.

5 Nachdem die erforderliche Anzahl Core-Lizenzen bestimmt ist, klären wir im nächsten Schritt, in wie vielen Betriebssystemumgebungen (OSEs) SQL Server ausgeführt werden darf. Dabei muss wiederum zwischen den Editionen unterschieden werden. Bei SQL Server 2012 Enterprise macht es einen Unterschied, ob die Core-Lizenzen mit oder ohne Software Assurance erworben werden. Werden alle physischen Cores eines Servers mit SQL Server 2012 Enterprise Core-Lizenzen OHNE Software Assurance lizenziert, ist die Anzahl der Core-Lizenzen gleich der Anzahl der Betriebssystemumgebungen, in denen SQL Server ausgeführt werden darf. Das zeigt das obere Beispiel auf der Folie: Acht Core-Lizenzen SQL Server 2012 Enterprise ohne Software Assurance berechtigen dazu, SQL Server in bis zu acht virtuellen Betriebssystemumgebungen auszuführen. Werden alle physischen Cores eines Servers mit SQL Server 2012 Enterprise Core-Lizenzen MIT Software Assurance lizenziert, darf SQL Server auf diesem Server in einer beliebigen Anzahl virtueller Betriebssystemumgebungen ausgeführt werden. Diese unbegrenzte Virtualisierung ist nur für SQL Server 2012 Enterprise verfügbar und setzt aktive Software Assurance voraus. In jedem Fall darf in den zulässigen Betriebssystemumgebungen auch eine frühere Version von SQL Server Enterprise ausgeführt werden, also zum Beispiel 2008 R2. Darüber hinaus dürfen auch die niedrigeren Editionen Standard und Business Intelligence in jeder Version sowie SQL Server Datacenter, Workgroup oder Small Business 2008 R2 oder frühere ausgeführt werden.

6 Bei SQL Server 2012 Standard verhält es sich anders. Wird SQL Server 2012 Standard, wie beim oberen Beispiel auf dieser Folie, nach physischen Cores lizenziert, darf SQL Server nur in der physischen Betriebssystemumgebung (OSE) ausgeführt werden. Die Verwendung in virtuellen Betriebssystemumgebungen ist bei dieser Art der Lizenzierung nicht möglich. Dabei spielt es auch keine Rolle, ob die Core-Lizenzen mit oder ohne Software Assurance erworben werden. Soll SQL Server 2012 Standard in virtuellen Betriebssystemumgebungen ausgeführt werden, muss jede virtuelle Betriebssystemumgebung auf dem Server einzeln lizenziert werden. Die Anzahl der erforderlichen Lizenzen entspricht der Anzahl virtueller Cores in jeder virtuellen Betriebssystemumgebung, in der SQL Server ausgeführt wird. Dabei sind für jede virtuelle Betriebssystemumgebung mindestens vier Core-Lizenzen erforderlich. Diese Art der Lizenzierung nach einzelnen virtuellen Betriebssystemumgebungen ist auch für SQL Server 2012 Enterprise möglich und bietet sich an, wenn eine geringe Anzahl virtueller Betriebssystemumgebungen auf einem ressourcenreichen Server mit einer großen Anzahl physischer Cores ausgeführt werden soll.

7 Kommen wir nun zum Server/CAL-Lizenzmodell. Für SQL Server 2012 Business Intelligence ist es die einzige Möglichkeit der Lizenzierung, für SQL Server 2012 Standard eine Alternative zum Core-Lizenzmodell. Die Server/CAL-Option eignet sich für Unternehmensumgebungen mit einer geringeren Anzahl von Nutzern und Geräten, die auf SQL Server zugreifen, während sich die Option mit Core-Lizenzen vor allem für größere Umgebungen und Webanwendungen anbietet. Betrachten wir zunächst die Lizenzierung der Serversoftware. Für jede Betriebssystemumgebung, in der SQL Server 2012 Standard oder SQL Server 2012 Business Intelligence ausgeführt werden soll, ist eine separate Serverlizenz erforderlich. Dabei spielt es keine Rolle, ob es sich um eine physische oder virtuelle Betriebssystemumgebung handelt. Im oberen Beispiel auf der Folie soll SQL Server 2012 Business Intelligence in der physischen Betriebssystemumgebung ausgeführt werden, so dass dem physischen Server eine Serverlizenz von SQL Server 2012 Business Intelligence zugewiesen wird. Soll SQL Server in virtuellen Betriebssystemumgebungen genutzt werden, muss jede virtuelle Betriebssystemumgebung, in der SQL Server ausgeführt wird, mit einer Serverlizenz lizenziert werden. Im unteren Beispiel auf der Folie wurde der ersten virtuellen Betriebssystemumgebung eine Serverlizenz von SQL Server 2012 Business Intelligence zugewiesen. Der zweiten virtuellen Betriebssystemumgebung wurde eine Serverlizenz von SQL Server 2012 Standard zugewiesen.

8 Für den Zugriff auf SQL Server 2012 im Server/CAL-Modell sind SQL Server 2012 CALs pro Nutzer oder pro Gerät erforderlich. SQL Server 2012 CALs berechtigen zum Zugriff auf die Editionen Business Intelligence und Standard von SQL Server Für den Zugriff auf SQL Server 2012 im Core-Lizenzmodell sind keine SQL Server CALs erforderlich. Mit einer Nutzer-CAL kann ein Nutzer von einem beliebigen Gerät auf die Serversoftware zugreifen. Eine Nutzer-CAL ist die beste Wahl, wenn ein Mitarbeiter mehrere Geräte verwendet, beispielsweise neben dem Firmen-PC ein Smartphone, Tablet oder auch seinen Heim-PC, um auf SQL Server zuzugreifen. Die gerätebasierte Lizenzierung der Zugriffe ist immer dann die geeignete Wahl, wenn sich mehrere Mitarbeiter einen Computer teilen, zum Beispiel im Schichtbetrieb. Wenn mehrere Nutzer einen Computer gemeinsam verwenden und nicht von anderen Orten wie ihrem Heim-PC einzeln auf SQL Server zugreifen, können sie mit einer Geräte-CAL lizenziert werden. Ein Wechsel zwischen Nutzer-CAL und Geräte-CAL ist nur zum Zeitpunkt der Verlängerung von Software Assurance möglich. Der Wechsel kann also nicht während eines laufenden Volumenlizenzvertrags erfolgen, sondern nur bei der Verlängerung des bestehenden Vertrags oder bei Abschluss eines Folgevertrags.

9 SQL Server CALs sind erforderlich für Nutzer und Geräte, die direkt auf SQL Server zugreifen, indem sie zum Beispiel Daten eingeben, abfragen oder betrachten. SQL Server CALs sind ebenfalls erforderlich für Nutzer und Geräte, die INDIREKT über eine Anwendung (zum Beispiel SharePoint Server oder Dynamics CRM) auf SQL Server zugreifen, um Daten einzugeben, abzufragen oder zu betrachten. Das gilt auch dann, wenn die Anwendung und SQL Server auf verschiedenen physischen Geräten ausgeführt werden. Ein solcher indirekter Zugriff kann auch über eine webbasierte Anwendung erfolgen. In diesem Fall ist eine Lizenzierung mit Core-Lizenzen sinnvoll.

10 Alle Editionen von SQL Server 2012 beinhalten Features für Hochverfügbarkeit. Zu den so genannten Failover-Funktionen gehören Backup Log-Shipping, Database Mirroring und Failover-Clustering. Damit kann SQL Server so konfiguriert werden, dass die Datenbankoperationen beim Ausfall eines Servers von einem anderen Server vorübergehend übernommen und weitergeführt werden. Bei der Lizenzierung muss unterschieden werden, ob die Failover-Instanzen aktiv-passiv oder aktivaktiv ausgeführt werden. Aktiv-passiv bedeutet, dass alle Datenbankoperationen nur auf dem aktiven Server ausgeführt werden. Grundsätzlich gilt, dass nur die aktiven Instanzen lizenziert werden müssen. Im oberen Beispiel auf der Folie werden auf dem Server links aktive Instanzen und auf dem Server rechts passive Instanzen ausgeführt. Nur die aktiven Instanzen auf dem Server links müssen lizenziert werden, in diesem Beispiel mit acht Core-Lizenzen. Auf dem Server rechts darf dieselbe Anzahl von Instanzen ausgeführt werden, ohne dass weitere Lizenzen erforderlich sind. Im unteren Beispiel auf der Folie werden alle Failover-Instanzen aktiv ausgeführt, so dass die entsprechenden Lizenzen für beide Server erworben werden müssen. Die Nutzung von Failover-Instanzen ist mit Core-Lizenzen und Serverlizenzen möglich. Software Assurance ist hierfür nicht erforderlich.

11 Anders verhält es sich bei der Lizenzmobilität: Jegliche Lizenzmobilität bei SQL Server 2012 bedarf aktiver Software Assurance. Dabei unterscheidet man zwei Arten von Lizenzmobilität: Lizenzmobilität innerhalb der Serverfarm des Unternehmens und Lizenzmobilität zu einem autorisierten Service Provider, um die Software in dessen Rechenzentrum auf gemeinsam genutzten Servern auszuführen. Schauen wir uns zunächst die Lizenzmobilität innerhalb einer Serverfarm an. Eine Serverfarm besteht aus maximal zwei Rechenzentren des Unternehmens, die sich physisch innerhalb der Europäischen Union oder EFTA-Staaten befinden oder in einer Zeitzone, die maximal vier Stunden von der örtlichen Zeitzone des anderen Rechenzentrums entfernt ist. Sind Core-Lizenzen beziehungsweise Serverlizenz von SQL Server 2012 mit aktiver Software Assurance ausgestattet, kann die Lizenz beliebig oft innerhalb der Serverfarm des Unternehmens verschoben werden. Läuft die Software Assurance jedoch ab und wird nicht verlängert, haben die Lizenzen keine Lizenzmobilität mehr und müssen einem physischen Server für mindestens 90 Tage zugewiesen bleiben. Software Assurance berechtigt außerdem zu einer weiteren Form von Lizenzmobilität, um die Serversoftware von den Unternehmens-Servern auf Server eines autorisierten Service Providers zu verschieben, die von mehreren Kunden gemeinsam genutzt werden. Jede Lizenz von SQL Server mit aktiver Software Assurance darf in einer virtuellen Betriebssystemumgebung auf einem so genannten Shared Server ausgeführt werden. Die Lizenzen für SQL Server kommen dabei aus dem Volumenlizenzvertrag des Endkunden, das Windows Server-Betriebssystem hingegen aus dem Services Provider License Agreement, dem SPLA-Vertrag des Partners. Dabei ist zu beachten, dass SQL Server weiterhin ausschließlich für die Verwendung und zugunsten des lizenzierten Endkunden genutzt werden darf, das heißt des Unternehmens, unter dessen Volumenlizenzvertrag die Lizenzen erworben wurden. Alle Rechte zur Ausführung der Serversoftware auf gemeinsam genutzten Servern eines Dritten enden mit Ablauf der Software Assurance.

12