SQL Server für Enterprise-Workloads

Benötigte Core-Lizenzen vor der Auswahl der Paketanzahl berechnen

Gehen Sie vom Umfang der Bereitstellung aus, nicht von der Datenbankgröße oder der Mitarbeiterzahl. Bei einer physischen SQL Server Enterprise-Bereitstellung mit Lizenzierung nach physischen Kernen zählen alle physischen Kerne des Servers. Dabei gilt Microsofts Mindestanforderung von vier Core-Lizenzen pro physischem Prozessor. Ein 2-Core-Pack enthält zwei Core-Lizenzen; es lizenziert keinen vollständigen Prozessor oder Server. Hyper-Threading verdoppelt bei diesem Modell nicht die Anzahl der physischen Kerne. Auch ungenutzte physische Kerne müssen mitgezählt werden.

Unterscheiden Sie zwischen der Softwareaktivierung und dem rechtlichen Nutzungsrecht für die geplante Konfiguration. Ein funktionierender Produktschlüssel allein belegt weder die Nutzungsrechte für eine Edition noch die Anzahl der Core-Lizenzen, eine Software Assurance-Abdeckung oder die Berechtigung zur Lizenzübertragung. Fordern Sie vor dem Kauf Unterlagen an, aus denen Version, Edition, Lizenzierungskanal und Anzahl der enthaltenen Core-Lizenzen hervorgehen. Bei einer Core-basierten Lizenzierung von SQL Server sind keine SQL Server CALs erforderlich. Die Lizenzierung von Windows Server und gegebenenfalls erforderliche Windows Server-Zugriffslizenzen bleiben jedoch separate Anforderungen.

• Erfassen Sie die physischen Prozessoren und die Anzahl der Kerne pro Prozessor.
• Wenden Sie die Mindestanforderung von vier Core-Lizenzen auf jeden Prozessor einzeln an.
• Teilen Sie die benötigte Anzahl der Core-Lizenzen durch zwei, um die Anzahl der 2-Core-Packs zu berechnen.
• Prüfen Sie die Lizenznachweise, statt sich allein auf die Aktivierung zu verlassen.
• Planen Sie die Kosten für das zugrunde liegende Betriebssystem separat ein.

Ein Virtualisierungsmodell passend zu Hosts und Migrationsplänen wählen

Nach den aktuellen SQL Server-Lizenzbestimmungen erfordert die Lizenzierung einzelner virtueller Maschinen Abonnementlizenzen oder Lizenzen mit aktiver Software Assurance. Bei diesem Modell zählen die virtuellen Kerne, die jeder SQL Server-VM zugewiesen sind. Pro VM sind mindestens vier Core-Lizenzen erforderlich. Auch eine kleine Datenbank-VM mit zwei vCPUs senkt den Bedarf daher nicht unter vier Core-Lizenzen. Prüfen Sie die für Ihren Vertrag und Ihre Version geltenden Microsoft-Produktbestimmungen, insbesondere bei der Bewertung älterer unbefristeter Lizenzen oder der Planung eines Upgrades.

Eine Alternative bei hoher VM-Dichte ist die unbegrenzte Virtualisierung mit Enterprise: Lizenzieren Sie alle physischen Kerne eines Hosts mit Enterprise-Core-Lizenzen und aktiver Software Assurance. Dabei müssen die Mindestanforderungen pro physischem Prozessor erfüllt sein. Dies erlaubt eine beliebige Anzahl von SQL Server-Instanzen in beliebig vielen virtuellen Betriebssystemumgebungen auf diesem lizenzierten Server. Benachbarte Hosts sind dadurch nicht automatisch abgedeckt. Erfassen Sie vor der Aktivierung automatischer VM-Migrationen alle möglichen Zielhosts und prüfen Sie deren Lizenzabdeckung oder die geltenden Rechte zur Lizenzmobilität.

• Erfassen Sie für jede SQL Server-VM die zugewiesenen virtuellen Kerne.
• Gehen Sie nicht davon aus, dass ein Produktschlüssel für eine unbefristete Lizenz auch Rechte zur Lizenzierung einzelner VMs umfasst.
• Vergleichen Sie die Lizenzierung pro VM mit der vollständigen Lizenzierung jedes vorgesehenen Hosts.
• Berücksichtigen Sie Hosts für Wartung und Failover bei der Planung der VM-Platzierung.
• Prüfen Sie die Einschränkungen zur Neuzuweisung, bevor Sie Lizenzen zwischen Servern verschieben.

Jedes Verfügbarkeitsreplikat als passiv oder separat zu lizenzieren einstufen

Eine Verfügbarkeitsgruppe dient der Ausfallsicherheit und befreit ihre sekundären Server nicht pauschal von der Lizenzpflicht. Im Rahmen entsprechender Software Assurance- oder Abonnementvorteile von Microsoft dürfen bestimmte passive Failover-Instanzen ohne separate SQL Server-Lizenzen betrieben werden. Maßgeblich sind die geltenden Produktbestimmungen. Ein sekundäres Replikat, das Berichtsabfragen oder andere aktive SQL Server-Workloads verarbeitet, benötigt in der Regel eine eigene Lizenzabdeckung. Stufen Sie Replikate nach ihrer tatsächlichen Nutzung ein, nicht nach ihrer Bezeichnung als primär oder sekundär im Architekturdiagramm.

Dokumentieren Sie vor dem Lizenzkauf Standort, Zweck und zulässige Vorgänge jedes Replikats. Die Failover-Rechte von Microsoft unterscheiden zwischen Hochverfügbarkeit und Notfallwiederherstellung und enthalten Bedingungen für passive Instanzen, Kapazität und gleichzeitigen Betrieb. Bestimmte Wartungsvorgänge sind auf berechtigten passiven Instanzen zulässig. Daraus darf jedoch keine uneingeschränkte produktive Nutzung abgeleitet werden. Soll ein Replikat Business-Intelligence-Abfragen, Test-Workloads oder Anwendungszugriffe verarbeiten, bewerten Sie es als aktive Bereitstellung, statt von einem Nutzungsrecht als passive Instanz auszugehen.

• Listen Sie die Berichts- und Anwendungsverbindungen zu jedem sekundären Replikat auf.
• Prüfen Sie genau, welche Rechte für passive Instanzen mit Ihren Lizenzen verbunden sind.
• Gleichen Sie zulässige Sicherungs- und Wartungsaktivitäten mit den Microsoft-Bestimmungen ab.
• Dokumentieren Sie die Auswirkungen geplanter Failover-Tests auf die Lizenzierung.
• Prüfen Sie die Lizenzabdeckung erneut, wenn Sie Replikatrollen ändern oder schreibgeschütztes Routing hinzufügen.

Verschlüsselung und Wiederherstellung als getrennte Schutzmaßnahmen für den Produktivbetrieb prüfen

Betrachten Sie die Verschlüsselung gespeicherter Daten, die Verbindungsverschlüsselung und den Schutz vor privilegierten Datenbankzugriffen als unterschiedliche Anforderungen. Transparent Data Encryption schützt gespeicherte Datenbank- und Protokolldateien, verhindert aber nicht, dass autorisierte SQL-Abfragen Daten im Klartext lesen. TLS schützt Netzwerkverbindungen bei korrekter Konfiguration. Always Encrypted schützt ausgewählte Spaltenwerte über unterstützte Clienttreiber. Die Schlüssel werden dabei außerhalb der Datenbank-Engine verwaltet. Die Sicherheitseigenschaften und Abfragemöglichkeiten hängen von der Konfiguration ab, unter anderem davon, ob sichere Enklaven eingesetzt werden.

Erstellen Sie einen Wiederherstellungsleitfaden, bevor Sie Daten, die regulatorischen Anforderungen unterliegen, in den Produktivbetrieb übernehmen. Sichern Sie bei zertifikatbasierter TDE das Zertifikat, das den Datenbankverschlüsselungsschlüssel schützt, zusammen mit seinem privaten Schlüssel. Bewahren Sie die zur Wiederherstellung benötigten Daten sicher außerhalb des Datenbankservers auf. Die Wiederherstellung einer verschlüsselten Datenbank auf einem anderen System erfordert Zugriff auf das zugehörige Schutzmittel für den Datenbankverschlüsselungsschlüssel. Testen Sie die Wiederherstellung auf einem isolierten Zielsystem und prüfen Sie anschließend Anwendungsverbindungen, Anmeldungen, Aufträge und externe Abhängigkeiten. Replikation oder eine Verfügbarkeitsgruppe ersetzen keine unabhängigen Backups zum Schutz vor Löschung, Datenbeschädigung oder Ransomware.

• Legen Sie getrennt fest, welche Daten eine Verschlüsselung im Ruhezustand, beim Transport oder auf Spaltenebene benötigen.
• Prüfen Sie die Treiberkompatibilität vor der Einführung von Always Encrypted.
• Schreiben Sie bei der Konfiguration verschlüsselter Clientverbindungen eine Zertifikatsprüfung vor.
• Beziehen Sie die Wiederherstellung der Verschlüsselungsschlüssel in jeden Wiederherstellungstest ein.
• Ermitteln Sie durch Tests die Wiederherstellungszeit und den tolerierbaren Datenverlust.

Beispiele für SQL Server Enterprise 2-Core-Packs. Die physischen Beispiele lizenzieren jeweils den gesamten Server. Die Beispiele für einzelne VMs setzen berechtigte Abonnementlizenzen oder aktive Software Assurance voraus. Betriebssystemlizenzen und zusätzliche Server sind nicht enthalten.