WEBVTT

00:00:00.000 --> 00:00:10.560
[MUSIQUE].

00:00:10.560 --> 00:00:11.895
Bonjour, je m’appelle Ahmed Banerjee.

00:00:11.895 --> 00:00:14.520
Je suis gestionnaire de programme de groupe avec
groupe produit SQL Server.

00:00:14.520 --> 00:00:17.970
Je suis responsable de la
moteur de base de données pour SQL Server.

00:00:17.970 --> 00:00:19.110
Donc, dans la vidé o d’aujourd’hui,

00:00:19.110 --> 00:00:21.150
nous allons parler
le serveur SQL élevé

00:00:21.150 --> 00:00:23.250
disponibilité et catastrophe
avantages de récupération

00:00:23.250 --> 00:00:26.055
qui ont été introduits
novembre 2019.

00:00:26.055 --> 00:00:29.910
Donc, nous allons aller comprendre comment nous
réellement déployer SQL Server

00:00:29.910 --> 00:00:31.830
aujourd’hui dans la haute disponibilité

00:00:31.830 --> 00:00:33.780
et la configuration de récupération en cas de catastrophe.

00:00:33.780 --> 00:00:37.555
Donc, disons que vous avez une primaire
cas de SQL Server.

00:00:37.555 --> 00:00:40.040
L’instance principale peut maintenant avoir,

00:00:40.040 --> 00:00:41.900
en fonction de la fonctionnalité
que vous utilisez,

00:00:41.900 --> 00:00:45.080
s’il s’agit de disponibilité
groupes ou l’expédition de grumes,

00:00:45.080 --> 00:00:47.285
il peut avoir plusieurs secondaires.

00:00:47.285 --> 00:00:50.375
Si vous avez des
solutions de disponibilité

00:00:50.375 --> 00:00:52.580
comme les instances De cluster Fail-over,

00:00:52.580 --> 00:00:57.560
alors ce sont ha que des solutions
et vous n’avez pas de nœud DR,

00:00:57.560 --> 00:01:00.935
vous devez utiliser d’autres
technologies de déploiement DR.

00:01:00.935 --> 00:01:06.335
Donc, si vous aviez cela avec
SQL Server 2019 ou moins,

00:01:06.335 --> 00:01:07.790
et c’était, disons,

00:01:07.790 --> 00:01:10.220
un autre serveur SQL 2019 et ci-dessous,

00:01:10.220 --> 00:01:13.045
et la même chose ici.

00:01:13.045 --> 00:01:15.100
Avant le 1er novembre,

00:01:15.100 --> 00:01:17.660
si vous aviez l’assurance logicielle et

00:01:17.660 --> 00:01:20.030
votre accord d’entreprise a donné

00:01:20.030 --> 00:01:22.205
vous capacités d’assurance logicielle,

00:01:22.205 --> 00:01:25.739
vous seriez en mesure de
licence primaire,

00:01:25.739 --> 00:01:28.040
la première haute disponibilité ou

00:01:28.040 --> 00:01:30.755
DR réplique ne serait pas
doivent être autorisés,

00:01:30.755 --> 00:01:36.070
et la prochaine réplique DR serait
continuent d’être titulaires d’un permis.

00:01:36.070 --> 00:01:39.735
En commençant par SQL Server 2019,

00:01:39.735 --> 00:01:43.270
et cela s’applique à tous les plus âgés
versions de SQL Server ainsi,

00:01:43.270 --> 00:01:45.545
si vous avez la même architecture,

00:01:45.545 --> 00:01:47.930
si vous avez une primaire maintenant,

00:01:47.930 --> 00:01:49.550
Je vais juste dessiner ce droit

00:01:49.550 --> 00:01:52.580
alignés de sorte que c’est un
un peu plus facile à comprendre.

00:01:52.580 --> 00:01:54.530
Vous avez plusieurs secondaires.

00:01:54.530 --> 00:01:56.240
Disons que c’est utilisé pour

00:01:56.240 --> 00:01:59.015
haute disponibilité et ce
pour le relèvement après sinistre,

00:01:59.015 --> 00:02:02.960
votre principal sera lien pour être
sous licence sous l’assurance logicielle.

00:02:02.960 --> 00:02:05.825
Votre première réplique HA,

00:02:05.825 --> 00:02:08.540
qui est synchrone
dans la nature et les soutiens

00:02:08.540 --> 00:02:11.660
échec automatique ne
pas besoin d’être autorisé,

00:02:11.660 --> 00:02:15.575
et la réplique de la catastrophe aussi
n’a pas besoin d’être autorisé.

00:02:15.575 --> 00:02:17.795
Donc, nous allons comprendre ce que
cela signifie en fait.

00:02:17.795 --> 00:02:26.720
Donc, disons que cela avait 32
cœurs et vous aviez 32 chacun,

00:02:26.720 --> 00:02:28.400
juste pour le rendre plus simple.

00:02:28.400 --> 00:02:33.845
Donc, avant novembre 2019,

00:02:33.845 --> 00:02:36.860
vous auriez à
licence pour le primaire,

00:02:36.860 --> 00:02:39.979
aucun pour le premier secondaire,

00:02:39.979 --> 00:02:46.970
et 32 autres noyaux
pour le prochain secondaire.

00:02:46.970 --> 00:02:50.490
Maintenant, si vous avez un serveur SQL ou

00:02:50.490 --> 00:02:52.385
toute version SQL Server tant que

00:02:52.385 --> 00:02:54.725
les noyaux sont couverts
par l’assurance logicielle,

00:02:54.725 --> 00:02:59.690
ce que vous avez vraiment besoin de licence
pour l’après Novembre d’abord,

00:02:59.690 --> 00:03:01.880
2019 est le principal,

00:03:01.880 --> 00:03:05.305
et jusqu’à deux secondaires,
ce serait gratuit.

00:03:05.305 --> 00:03:07.605
Maintenant, ce que cela signifie réellement, c’est,

00:03:07.605 --> 00:03:09.825
Supposons que vous avez 32 noyaux,

00:03:09.825 --> 00:03:12.920
votre licence ressemblerait à ceci.

00:03:12.920 --> 00:03:16.370
Maintenant, comment puis-je réellement mettre cela en place?

00:03:16.370 --> 00:03:20.615
Est la première condition préalable, vous avez besoin
d’avoir l’assurance logicielle.

00:03:20.615 --> 00:03:27.900
Deuxième condition préalable, vous pouvez
licence des noyaux sur le primaire.

00:03:27.900 --> 00:03:31.580
Le nombre de noyaux sur
le secondaire doit

00:03:31.580 --> 00:03:38.430
être inférieur ou égal à
le nombre de noyaux primaires.

00:03:39.890 --> 00:03:44.405
Par exemple, si vous
avait plus de 32 ici,

00:03:44.405 --> 00:03:46.115
alors l’avantage ne s’appliquerait pas.

00:03:46.115 --> 00:03:49.520
Donc, essentiellement, pour chaque
noyau que vous licence

00:03:49.520 --> 00:03:56.330
pour les messages SQL Server Novembre
et vous avez l’assurance logicielle,

00:03:56.330 --> 00:04:00.485
vous obtenez un noyau HA,

00:04:00.485 --> 00:04:04.350
qui est synchrone, un noyau DR.

00:04:04.350 --> 00:04:06.080
En outre,

00:04:06.080 --> 00:04:13.415
vous obtenez également un autre DR
d’exploitation sur Azure VMs.

00:04:13.415 --> 00:04:15.110
Donc, si vous êtes en cours d’exécution sur

00:04:15.110 --> 00:04:16.865
une machine virtuelle Azure et vous êtes

00:04:16.865 --> 00:04:19.160
l’utilisation de cela comme un
site de récupération des sinistrés,

00:04:19.160 --> 00:04:21.215
vous obtenez aussi que gratuitement.

00:04:21.215 --> 00:04:23.570
Donc, dans cette architecture,

00:04:23.570 --> 00:04:26.540
Disons avant novembre,

00:04:26.540 --> 00:04:27.680
vous avez ajouté un secondaire,

00:04:27.680 --> 00:04:30.460
mais c’était sur une VM Azure.

00:04:30.460 --> 00:04:36.220
Vous paieriez 32 autres cœurs
à condition qu’il y ait 32 noyaux virtuels.

00:04:36.220 --> 00:04:39.545
Dans ce cas, j’ajoute un autre

00:04:39.545 --> 00:04:43.685
et je paie zéro noyau pour cela.

00:04:43.685 --> 00:04:46.385
Ainsi, votre architecture peut

00:04:46.385 --> 00:04:49.670
en fait tirer parti d’une meilleure
haute disponibilité et

00:04:49.670 --> 00:04:53.765
reprise après sinistre avec un
réduction du coût de possession

00:04:53.765 --> 00:04:55.730
avec les avantages SQL Server qui ont été

00:04:55.730 --> 00:04:58.525
a changé de poste et novembre d’abord.

00:04:58.525 --> 00:05:01.520
Maintenant, ce qui vous donne le droit de faire, c’est,

00:05:01.520 --> 00:05:05.995
vous pouvez réellement prendre ce à
toute version de SQL Server, 2019,

00:05:05.995 --> 00:05:10.370
2017, 2016, et tout le chemin

00:05:10.370 --> 00:05:12.980
à toute version de SQL Server comme

00:05:12.980 --> 00:05:16.145
tant que ces noyaux sont
couvert par Software Assurance.

00:05:16.145 --> 00:05:19.250
Si vous avez une architecture qui est,

00:05:19.250 --> 00:05:21.140
Disons, une machine physique.

00:05:21.140 --> 00:05:23.885
Donc, si vous êtes sur
nu-métal, vous obtenez que.

00:05:23.885 --> 00:05:26.074
Si vous êtes sur des machines virtuelles,

00:05:26.074 --> 00:05:27.860
vous obtenez également cet avantage.

00:05:27.860 --> 00:05:29.270
Si vous êtes dans des conteneurs,

00:05:29.270 --> 00:05:30.770
vous obtenez également cet avantage.

00:05:30.770 --> 00:05:35.360
Donc, si vous utilisez SQL
Serveur sur un centre de données physique,

00:05:35.360 --> 00:05:39.125
ou vous utilisez SQL Server
dans les machines virtuelles,

00:05:39.125 --> 00:05:42.200
ou vous utilisez Azure
comme votre centre DR

00:05:42.200 --> 00:05:46.745
et vous êtes en train d’héberger
vos primaires sur place,

00:05:46.745 --> 00:05:49.010
vous aurez un avantage DR

00:05:49.010 --> 00:05:51.620
couvrant votre serveur SQL
répliques sur Azure.

00:05:51.620 --> 00:05:53.510
Dans les prochains épisodes,

00:05:53.510 --> 00:05:55.010
nous allons effectivement parler de ce qui sont

00:05:55.010 --> 00:05:56.960
le plus optimal
architectures qui tirent parti

00:05:56.960 --> 00:05:59.030
cet avantage efficacement.
Merci de vous joindre à nous.

00:05:59.030 --> 00:06:10.690
[MUSIQUE]

