WEBVTT

00:00:00.000 --> 00:00:10.560
[MUSIK].

00:00:10.560 --> 00:00:11.895
>> Hallo, mein Name ist Ahmed Banerjee.

00:00:11.895 --> 00:00:14.520
Ich bin Gruppenprogrammmanager mit
SQL Server-Produktgruppe.

00:00:14.520 --> 00:00:17.970
Ich bin verantwortlich für die
Datenbankmodul für SQL Server.

00:00:17.970 --> 00:00:19.110
Im heutigen Video

00:00:19.110 --> 00:00:21.150
wir werden darüber sprechen
SQL Server hoch

00:00:21.150 --> 00:00:23.250
Verfügbarkeit und Katastrophe
Wiedereinziehungsvorteile

00:00:23.250 --> 00:00:26.055
die eingeführt wurden
im November 2019.

00:00:26.055 --> 00:00:29.910
Also lasst uns herausfinden, wie wir
TatsächlichsqlServer bereitstellen

00:00:29.910 --> 00:00:31.830
heute in der Hochverfügbarkeit

00:00:31.830 --> 00:00:33.780
und Disaster Recovery-Konfiguration.

00:00:33.780 --> 00:00:37.555
Nehmen wir also an, Sie haben eine primäre
Instanz von SQL Server.

00:00:37.555 --> 00:00:40.040
Die primäre Instanz kann jetzt

00:00:40.040 --> 00:00:41.900
abhängig von der Funktion
die Sie verwenden,

00:00:41.900 --> 00:00:45.080
ob es sich um Verfügbarkeit handelt
Gruppen oder Protokollversand,

00:00:45.080 --> 00:00:47.285
es kann mehrere Secondaries haben.

00:00:47.285 --> 00:00:50.375
Wenn Sie hohe
Verfügbarkeitslösungen

00:00:50.375 --> 00:00:52.580
wie Failover-Clusterinstanzen,

00:00:52.580 --> 00:00:57.560
dann sind das nur HA-Lösungen
und Sie haben keinen DR-Knoten,

00:00:57.560 --> 00:01:00.935
Sie müssen andere
Technologien zur Bereitstellung von DR.

00:01:00.935 --> 00:01:06.335
Wenn Sie also dies mit
SQL Server 2019 oder darunter,

00:01:06.335 --> 00:01:07.790
und das war, sagen wir mal,

00:01:07.790 --> 00:01:10.220
sql Server 2019 und darunter,

00:01:10.220 --> 00:01:13.045
und das gleiche hier drüben.

00:01:13.045 --> 00:01:15.100
Vor dem ersten November

00:01:15.100 --> 00:01:17.660
wenn Sie Software Assurance und

00:01:17.660 --> 00:01:20.030
Ihre Unternehmensvereinbarung gab

00:01:20.030 --> 00:01:22.205
Sie Software Assurance-Fähigkeiten,

00:01:22.205 --> 00:01:25.739
Sie könnten
Lizenz der primären,

00:01:25.739 --> 00:01:28.040
die erste Hochverfügbarkeit oder

00:01:28.040 --> 00:01:30.755
DR-Replikat würde nicht
lizenziert werden müssen,

00:01:30.755 --> 00:01:36.070
und das nächste DR-Replikat würde
weiterhin lizenziert werden.

00:01:36.070 --> 00:01:39.735
Ab SQL Server 2019

00:01:39.735 --> 00:01:43.270
und dies gilt für alle älteren
Versionen von SQL Server,

00:01:43.270 --> 00:01:45.545
wenn Sie die gleiche Architektur haben,

00:01:45.545 --> 00:01:47.930
wenn Sie jetzt eine primäre

00:01:47.930 --> 00:01:49.550
Ich werde nur dieses Recht ziehen

00:01:49.550 --> 00:01:52.580
so ausgerichtet, dass es ein
etwas leichter zu verstehen.

00:01:52.580 --> 00:01:54.530
Sie haben mehrere Secondaries.

00:01:54.530 --> 00:01:56.240
Nehmen wir an, dies wird für

00:01:56.240 --> 00:01:59.015
hohe Verfügbarkeit und dies
für Disaster Recovery,

00:01:59.015 --> 00:02:02.960
Ihr Primärlink wird
unter Software Assurance lizenziert.

00:02:02.960 --> 00:02:05.825
Ihr erstes HA-Replikat,

00:02:05.825 --> 00:02:08.540
die synchron ist
in der Natur und unterstützt

00:02:08.540 --> 00:02:11.660
automatisches Failover
müssen nicht lizenziert werden,

00:02:11.660 --> 00:02:15.575
und die Disaster Replica auch
muss nicht lizenziert werden.

00:02:15.575 --> 00:02:17.795
Lassen Sie uns also herausfinden, was
das bedeutet eigentlich.

00:02:17.795 --> 00:02:26.720
Also sagen wir, das hatte 32
Kerne und Sie hatten jeweils 32,

00:02:26.720 --> 00:02:28.400
nur um es einfacher zu machen.

00:02:28.400 --> 00:02:33.845
Vor November 2019

00:02:33.845 --> 00:02:36.860
Sie müssten
Lizenz für die primäre,

00:02:36.860 --> 00:02:39.979
keine für die erste Sekundärstufe,

00:02:39.979 --> 00:02:46.970
und weitere 32 Kerne
für die nächste Sekundärstufe.

00:02:46.970 --> 00:02:50.490
Wenn Sie nun über einen SQL Server oder

00:02:50.490 --> 00:02:52.385
SQL Server-Version so lange, wie

00:02:52.385 --> 00:02:54.725
die Kerne sind abgedeckt
durch Software-Versicherung,

00:02:54.725 --> 00:02:59.690
was Sie wirklich brauchen, um zu lizenzieren
für post November zuerst,

00:02:59.690 --> 00:03:01.880
2019 ist das primäre,

00:03:01.880 --> 00:03:05.305
und bis zu zwei Secondaries,
es wäre kostenlos.

00:03:05.305 --> 00:03:07.605
Nun, was das eigentlich bedeutet, ist,

00:03:07.605 --> 00:03:09.825
Nehmen wir an, Sie haben 32 Kerne,

00:03:09.825 --> 00:03:12.920
Ihre Lizenzierung würde so aussehen.

00:03:12.920 --> 00:03:16.370
Nun, wie kann ich das eigentlich einrichten?

00:03:16.370 --> 00:03:20.615
Ist erste Voraussetzung, sie brauchen
Software Assurance zu haben.

00:03:20.615 --> 00:03:27.900
Zweite Voraussetzung ist, dass Sie
lizenzieren Sie die Kerne auf dem primären.

00:03:27.900 --> 00:03:31.580
Die Anzahl der Kerne auf
der Sekundäre muss

00:03:31.580 --> 00:03:38.430
kleiner oder gleich
die Anzahl der Primärkerne.

00:03:39.890 --> 00:03:44.405
Wenn Sie z. B.
hatte mehr als 32 hier,

00:03:44.405 --> 00:03:46.115
dann würde der Vorteil nicht gelten.

00:03:46.115 --> 00:03:49.520
Im Wesentlichen gilt also für jede
Kern, den Sie lizenzieren

00:03:49.520 --> 00:03:56.330
für SQL Server-Beiträge November
und Sie haben Software-Versicherung,

00:03:56.330 --> 00:04:00.485
Sie erhalten einen HA-Kern,

00:04:00.485 --> 00:04:04.350
die synchron ist, ein DR-Kern.

00:04:04.350 --> 00:04:06.080
Darüber hinaus

00:04:06.080 --> 00:04:13.415
Sie erhalten auch eine weitere DR
Kern, der auf Azure-VMs ausgeführt wird.

00:04:13.415 --> 00:04:15.110
Also, wenn Sie auf laufen

00:04:15.110 --> 00:04:16.865
eine virtuelle Azure-Maschine, und Sie sind

00:04:16.865 --> 00:04:19.160
verwendung s.
Disaster Recovery-Site,

00:04:19.160 --> 00:04:21.215
Sie bekommen das auch kostenlos.

00:04:21.215 --> 00:04:23.570
In dieser Architektur

00:04:23.570 --> 00:04:26.540
sagen wir vor November,

00:04:26.540 --> 00:04:27.680
Sie haben eine sekundäre,

00:04:27.680 --> 00:04:30.460
dies wurde jedoch auf einer Azure-VM verwendet.

00:04:30.460 --> 00:04:36.220
Sie würden weitere 32 Kerne bezahlen
vorausgesetzt, dies hatte 32 virtuelle Kerne.

00:04:36.220 --> 00:04:39.545
In diesem Fall füge ich eine weitere sekundäre

00:04:39.545 --> 00:04:43.685
und ich zahle null Kerne dafür.

00:04:43.685 --> 00:04:46.385
So kann Ihre Architektur

00:04:46.385 --> 00:04:49.670
tatsächlich eine bessere
hohe Verfügbarkeit und

00:04:49.670 --> 00:04:53.765
Disaster Recovery mit einem
niedrigere Betriebskosten

00:04:53.765 --> 00:04:55.730
mit SQL Server-Vorteilen, die

00:04:55.730 --> 00:04:58.525
geänderte Post und November zuerst.

00:04:58.525 --> 00:05:01.520
Nun, was Sie dazu berechtigt, ist,

00:05:01.520 --> 00:05:05.995
Sie können dies tatsächlich zu
jede Version von SQL Server, 2019,

00:05:05.995 --> 00:05:10.370
2017, 2016 und den ganzen Weg

00:05:10.370 --> 00:05:12.980
zu jeder Version von SQL Server als

00:05:12.980 --> 00:05:16.145
solange diese Kerne
Software Assurance abgedeckt werden.

00:05:16.145 --> 00:05:19.250
Wenn Sie eine Architektur haben, die

00:05:19.250 --> 00:05:21.140
Sagen wir, eine physische Maschine.

00:05:21.140 --> 00:05:23.885
Also, wenn Sie auf
Bare-Metal, das bekommt man.

00:05:23.885 --> 00:05:26.074
Wenn Sie sich auf virtuellen Maschinen befinden,

00:05:26.074 --> 00:05:27.860
Sie erhalten auch diesen Vorteil.

00:05:27.860 --> 00:05:29.270
Wenn Sie sich in Containern befinden,

00:05:29.270 --> 00:05:30.770
Sie erhalten auch diesen Vorteil.

00:05:30.770 --> 00:05:35.360
Also, ob Sie SQL verwenden
Server in einem physischen Rechenzentrum,

00:05:35.360 --> 00:05:39.125
oder Sie verwenden SQL Server
in virtuellen Maschinen,

00:05:39.125 --> 00:05:42.200
oder Sie verwenden Azure
als Ihr DR-Center

00:05:42.200 --> 00:05:46.745
und Sie sind tatsächlich Hosting
Ihre Vorwahlen vor Ort,

00:05:46.745 --> 00:05:49.010
Sie haben einen DR-Vorteil

00:05:49.010 --> 00:05:51.620
Abdeckung Ihres SQL Servers
Replikate in Azure.

00:05:51.620 --> 00:05:53.510
In den nächsten Folgen

00:05:53.510 --> 00:05:55.010
werden wir tatsächlich darüber sprechen, was

00:05:55.010 --> 00:05:56.960
die optimalste
Architekturen, die

00:05:56.960 --> 00:05:59.030
nutzen sie effizient.
Vielen Dank für Ihren Beitritt.

00:05:59.030 --> 00:06:10.690
[MUSIK]