WEBVTT

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

00:00:10.560 --> 00:00:11.895
"Ahoj, jmenuji se Ahmed Banerjee.

00:00:11.895 --> 00:00:14.520
Jsem manažer skupinových programů
skupiny produktů SQL Server.

00:00:14.520 --> 00:00:17.970
Jsem zodpovědný za
databázový stroj pro SQL Server.

00:00:17.970 --> 00:00:19.110
Takže v dnešním videu,

00:00:19.110 --> 00:00:21.150
Budeme mluvit o
sql server vysoká

00:00:21.150 --> 00:00:23.250
dostupnost a katastrofa
přínosy pro zotavení

00:00:23.250 --> 00:00:26.055
které byly zavedeny
v listopadu 2019.

00:00:26.055 --> 00:00:29.910
Tak pojďme zjistit, jak jsme
skutečné nasazení serveru SQL Server

00:00:29.910 --> 00:00:31.830
v současné době ve vysoké dostupnosti

00:00:31.830 --> 00:00:33.780
a konfigurace zotavení po havárii.

00:00:33.780 --> 00:00:37.555
Takže řekněme, že máte primární
instance serveru SQL Server.

00:00:37.555 --> 00:00:40.040
Primární instance nyní může mít,

00:00:40.040 --> 00:00:41.900
v závislosti na funkci
které používáte,

00:00:41.900 --> 00:00:45.080
zda je dostupnost
skupiny nebo lodní zásilky,

00:00:45.080 --> 00:00:47.285
může mít více sekundárních.

00:00:47.285 --> 00:00:50.375
Pokud máte vysoké
řešení dostupnosti

00:00:50.375 --> 00:00:52.580
jako instance clusteru převzetí služeb při selhání,

00:00:52.580 --> 00:00:57.560
pak to jsou HA pouze řešení
a nemáte uzel DR,

00:00:57.560 --> 00:01:00.935
musíte použít jiné
technologií k nasazení dr.

00:01:00.935 --> 00:01:06.335
Takže pokud jste měli to to s
SQL Server 2019 nebo nižší,

00:01:06.335 --> 00:01:07.790
a to bylo, řekněme,

00:01:07.790 --> 00:01:10.220
jiný SQL Server 2019 a další,

00:01:10.220 --> 00:01:13.045
a to samé tady.

00:01:13.045 --> 00:01:15.100
Před listopadem

00:01:15.100 --> 00:01:17.660
pokud jste měli Software Assurance a

00:01:17.660 --> 00:01:20.030
vaše podniková smlouva dala

00:01:20.030 --> 00:01:22.205
software Assurance schopnosti,

00:01:22.205 --> 00:01:25.739
budete moci
licence primární,

00:01:25.739 --> 00:01:28.040
první vysokou dostupnost nebo

00:01:28.040 --> 00:01:30.755
Replika DR by
musí být licencován,

00:01:30.755 --> 00:01:36.070
a další replika ZOTAVENÍ k havárii by
nadále licencována.

00:01:36.070 --> 00:01:39.735
Počínaje SQL Serverem 2019,

00:01:39.735 --> 00:01:43.270
a to platí pro všechny starší
verze SQL Serveru,

00:01:43.270 --> 00:01:45.545
pokud máte stejnou architekturu,

00:01:45.545 --> 00:01:47.930
pokud máte primární nyní,

00:01:47.930 --> 00:01:49.550
Jen to nakreslím správně.

00:01:49.550 --> 00:01:52.580
tak, aby se jedná o
trochu srozumitelnější.

00:01:52.580 --> 00:01:54.530
Máte více sekundárních.

00:01:54.530 --> 00:01:56.240
Řekněme, že se to používá pro

00:01:56.240 --> 00:01:59.015
vysoká dostupnost a to
pro zotavení po havárii,

00:01:59.015 --> 00:02:02.960
primární bude odkaz být
licencována v rámci programu Software Assurance.

00:02:02.960 --> 00:02:05.825
Vaše první HA replika,

00:02:05.825 --> 00:02:08.540
což je synchronní
v přírodě a podporuje

00:02:08.540 --> 00:02:11.660
automatické převzetí služeb při selhání
nemusí být licencován,

00:02:11.660 --> 00:02:15.575
a replika katastrofy také
nemusí být licencován.

00:02:15.575 --> 00:02:17.795
Tak pojďme přijít na to, co
to vlastně znamená.

00:02:17.795 --> 00:02:26.720
Řekněme, že to mělo 32
jader a měli jste 32 každý,

00:02:26.720 --> 00:02:28.400
jen aby to bylo jednodušší.

00:02:28.400 --> 00:02:33.845
Takže před listopadem 2019,

00:02:33.845 --> 00:02:36.860
budete muset
licence pro primární,

00:02:36.860 --> 00:02:39.979
žádný pro první sekundární,

00:02:39.979 --> 00:02:46.970
a dalších 32 jader
pro další sekundární.

00:02:46.970 --> 00:02:50.490
Nyní, pokud máte SQL Server nebo

00:02:50.490 --> 00:02:52.385
jakékoli vydání serveru SQL Server, pokud

00:02:52.385 --> 00:02:54.725
jádra jsou pokryta
zajištěním softwaru,

00:02:54.725 --> 00:02:59.690
co opravdu potřebujete k licencování
pro po listopadu první,

00:02:59.690 --> 00:03:01.880
Rok 2019 je primárním

00:03:01.880 --> 00:03:05.305
a až dvě sekundární,
bylo by to zdarma.

00:03:05.305 --> 00:03:07.605
To vlastně znamená,

00:03:07.605 --> 00:03:09.825
Předpokládejme, že máte 32 jader,

00:03:09.825 --> 00:03:12.920
vaše licence bude vypadat takto.

00:03:12.920 --> 00:03:16.370
Jak to mám vlastně nastavit?

00:03:16.370 --> 00:03:20.615
Je prvním předpokladem, potřebujete
software Assurance.

00:03:20.615 --> 00:03:27.900
Druhý předpoklad, můžete
licencovat jádra na primární.

00:03:27.900 --> 00:03:31.580
Počet jader na
sekundární musí

00:03:31.580 --> 00:03:38.430
být menší nebo rovna
počtu primárních jader.

00:03:39.890 --> 00:03:44.405
Pokud například
měl více než 32 zde,

00:03:44.405 --> 00:03:46.115
pak by se výhoda nevztahovala.

00:03:46.115 --> 00:03:49.520
Takže v podstatě, pro každý
jádro, které licencujete

00:03:49.520 --> 00:03:56.330
pro sql server příspěvky listopad
a máte záruku softwaru,

00:03:56.330 --> 00:04:00.485
získáte jedno jádro HA,

00:04:00.485 --> 00:04:04.350
který je synchronní, jedno jádro zotavení po havárii.

00:04:04.350 --> 00:04:06.080
Kromě toho

00:04:06.080 --> 00:04:13.415
získáte také další DR
jádro běžící na virtuálních počítačích Azure.

00:04:13.415 --> 00:04:15.110
Takže pokud běžíte na

00:04:15.110 --> 00:04:16.865
virtuální počítač Azure a jste

00:04:16.865 --> 00:04:19.160
používat, že jako
místo zotavení po havárii,

00:04:19.160 --> 00:04:21.215
získáte také zdarma.

00:04:21.215 --> 00:04:23.570
Takže v této architektuře,

00:04:23.570 --> 00:04:26.540
Řekněme před listopadem,

00:04:26.540 --> 00:04:27.680
přidali jste sekundární,

00:04:27.680 --> 00:04:30.460
ale to bylo na virtuálním počítači Azure.

00:04:30.460 --> 00:04:36.220
Zaplatili byste dalších 32 jader
za předpokladu, že to mělo 32 virtuálních jader.

00:04:36.220 --> 00:04:39.545
V tomto případě přidám další sekundární

00:04:39.545 --> 00:04:43.685
a já za to platím nulová jádra.

00:04:43.685 --> 00:04:46.385
Takže vaše architektura může

00:04:46.385 --> 00:04:49.670
ve skutečnosti využít lepší
vysoká dostupnost a

00:04:49.670 --> 00:04:53.765
zotavení po havárii
nižší náklady na vlastnictví

00:04:53.765 --> 00:04:55.730
s výhodami serveru SQL Server, které byly

00:04:55.730 --> 00:04:58.525
změněna pošta a listopad u prvního.

00:04:58.525 --> 00:05:01.520
To, co tě opravňuje udělat, je:

00:05:01.520 --> 00:05:05.995
můžete skutečně vzít to to
jakékoli vydání SQL Serveru, 2019,

00:05:05.995 --> 00:05:10.370
2017, 2016 a celou cestu

00:05:10.370 --> 00:05:12.980
na libovolnou verzi SQL Serveru jako

00:05:12.980 --> 00:05:16.145
pokud jsou tato jádra
na něž se vztahuje program Software Assurance.

00:05:16.145 --> 00:05:19.250
Pokud máte architekturu, která je,

00:05:19.250 --> 00:05:21.140
Řekněme, fyzický stroj.

00:05:21.140 --> 00:05:23.885
Takže pokud jste na
holý kov, to dostaneš.

00:05:23.885 --> 00:05:26.074
Pokud jste na virtuálních počítačích,

00:05:26.074 --> 00:05:27.860
získáte také tuto výhodu.

00:05:27.860 --> 00:05:29.270
Pokud jste v kontejnerech,

00:05:29.270 --> 00:05:30.770
získáte také tuto výhodu.

00:05:30.770 --> 00:05:35.360
Takže ať už používáte SQL
Server na fyzickém datovém centru,

00:05:35.360 --> 00:05:39.125
nebo používáte SQL Server
ve virtuálních strojích,

00:05:39.125 --> 00:05:42.200
Nebo používáte Azure
jako centrum DR

00:05:42.200 --> 00:05:46.745
a vy jste vlastně hosting
vaše primárky V místním prostředí,

00:05:46.745 --> 00:05:49.010
budete mít přínos pro zotavení po havárii

00:05:49.010 --> 00:05:51.620
pokrývající sql server
repliky v Azure.

00:05:51.620 --> 00:05:53.510
V příštích několika epizodách,

00:05:53.510 --> 00:05:55.010
budeme skutečně hovořit o tom, co jsou

00:05:55.010 --> 00:05:56.960
nejoptimálnější
architektury, které využívají

00:05:56.960 --> 00:05:59.030
tohoto prospěchu efektivně.
Děkuji, že jste se přidali.

00:05:59.030 --> 00:06:10.690
To je v pořádku.