WEBVTT

00:00:00.000 --> 00:00:10.560
[MÚSICA].

00:00:10.560 --> 00:00:11.895
>> Oi, meu nome é Ahmed Banerjee.

00:00:11.895 --> 00:00:14.520
Eu sou um gerente de programa de grupo com
o grupo de produtos SQL Server.

00:00:14.520 --> 00:00:17.970
Eu sou responsável pelo
motor de banco de dados para SQL Server.

00:00:17.970 --> 00:00:19.110
Então, no vídeo de hoje,

00:00:19.110 --> 00:00:21.150
vamos falar sobre
o Servidor SQL alto

00:00:21.150 --> 00:00:23.250
disponibilidade e desastre
benefícios de recuperação

00:00:23.250 --> 00:00:26.055
que foram introduzidos
em novembro de 2019.

00:00:26.055 --> 00:00:29.910
Então vamos descobrir como nós
realmente implantar o SQL Server

00:00:29.910 --> 00:00:31.830
hoje na alta disponibilidade

00:00:31.830 --> 00:00:33.780
e configuração de recuperação de desastres.

00:00:33.780 --> 00:00:37.555
Então vamos dizer que você tem uma primária
exemplo de SQL Server.

00:00:37.555 --> 00:00:40.040
A instância primária agora pode ter,

00:00:40.040 --> 00:00:41.900
dependendo do recurso
que você está usando,

00:00:41.900 --> 00:00:45.080
se é disponibilidade
grupos ou envio de registros,

00:00:45.080 --> 00:00:47.285
ele pode ter vários secundários.

00:00:47.285 --> 00:00:50.375
Se você tem alta
soluções de disponibilidade

00:00:50.375 --> 00:00:52.580
como as instâncias do Cluster Fail-over,

00:00:52.580 --> 00:00:57.560
então essas são apenas soluções HA
e você não tem um nó DR,

00:00:57.560 --> 00:01:00.935
você tem que usar outro
tecnologias para implantar DR.

00:01:00.935 --> 00:01:06.335
Então, se você tinha isso com
SQL Server 2019 ou abaixo,

00:01:06.335 --> 00:01:07.790
e isso foi, digamos,

00:01:07.790 --> 00:01:10.220
outro SQL Server 2019 e abaixo,

00:01:10.220 --> 00:01:13.045
e a mesma coisa aqui.

00:01:13.045 --> 00:01:15.100
Antes de novembro primeiro,

00:01:15.100 --> 00:01:17.660
se você tivesse Garantia de Software e

00:01:17.660 --> 00:01:20.030
seu acordo empresarial deu

00:01:20.030 --> 00:01:22.205
você recursos de Garantia de Software,

00:01:22.205 --> 00:01:25.739
você seria capaz de
licenciar o primário,

00:01:25.739 --> 00:01:28.040
a primeira alta disponibilidade ou

00:01:28.040 --> 00:01:30.755
Réplica DR não seria
precisa ser licenciado,

00:01:30.755 --> 00:01:36.070
e a próxima réplica DR seria
continuar a ser licenciado.

00:01:36.070 --> 00:01:39.735
Começando com o SQL Server 2019,

00:01:39.735 --> 00:01:43.270
e isso se aplica a todos os mais velhos
versões do SQL Server também,

00:01:43.270 --> 00:01:45.545
se você tem a mesma arquitetura,

00:01:45.545 --> 00:01:47.930
se você tem uma primária agora,

00:01:47.930 --> 00:01:49.550
Eu só vou desenhar este direito

00:01:49.550 --> 00:01:52.580
alinhado para que seja um
um pouco mais fácil de entender.

00:01:52.580 --> 00:01:54.530
Você tem vários secundários.

00:01:54.530 --> 00:01:56.240
Digamos que isso é usado para

00:01:56.240 --> 00:01:59.015
alta disponibilidade e isso
para recuperação de desastres,

00:01:59.015 --> 00:02:02.960
sua ligação principal será
licenciado Garantia de Software.

00:02:02.960 --> 00:02:05.825
Sua primeira réplica ha,

00:02:05.825 --> 00:02:08.540
que é síncrono
na natureza e apoia

00:02:08.540 --> 00:02:11.660
falha automática faz
não precisa ser licenciado,

00:02:11.660 --> 00:02:15.575
e a réplica do desastre também
não precisa ser licenciado.

00:02:15.575 --> 00:02:17.795
Então vamos descobrir o que
isso realmente significa.

00:02:17.795 --> 00:02:26.720
Então vamos dizer que isso tinha 32
núcleos e você tinha 32 cada,

00:02:26.720 --> 00:02:28.400
só para torná-lo mais simples.

00:02:28.400 --> 00:02:33.845
Então, antes de novembro de 2019,

00:02:33.845 --> 00:02:36.860
você teria que
licença para as primárias,

00:02:36.860 --> 00:02:39.979
nenhum para o primeiro secundário,

00:02:39.979 --> 00:02:46.970
e outros 32 núcleos
para o próximo secundário.

00:02:46.970 --> 00:02:50.490
Agora, se você tem um servidor SQL ou

00:02:50.490 --> 00:02:52.385
qualquer versão do SQL Server, desde que

00:02:52.385 --> 00:02:54.725
os núcleos são cobertos
por garantia de software,

00:02:54.725 --> 00:02:59.690
o que você realmente precisa para licenciar
para o primeiro pós novembro,

00:02:59.690 --> 00:03:01.880
2019 é a primária,

00:03:01.880 --> 00:03:05.305
e até dois secundários,
seria livre.

00:03:05.305 --> 00:03:07.605
Agora, o que isso realmente significa é,

00:03:07.605 --> 00:03:09.825
vamos supor que você tem 32 núcleos,

00:03:09.825 --> 00:03:12.920
seu licenciamento seria assim.

00:03:12.920 --> 00:03:16.370
Agora, como eu realmente configurar isso?

00:03:16.370 --> 00:03:20.615
É o primeiro pré-requisito, você precisa
ter Garantia de Software.

00:03:20.615 --> 00:03:27.900
Segundo pré-requisito, você pode
licenciar os núcleos nas primárias.

00:03:27.900 --> 00:03:31.580
O número de núcleos em
o secundário tem que

00:03:31.580 --> 00:03:38.430
ser menor ou igual a
o número de núcleos primários.

00:03:39.890 --> 00:03:44.405
Por exemplo, se você
tinha mais de 32 aqui,

00:03:44.405 --> 00:03:46.115
então o benefício não se aplicaria.

00:03:46.115 --> 00:03:49.520
Então, essencialmente, para cada
núcleo que você licencia

00:03:49.520 --> 00:03:56.330
para postagens do Servidor SQL em novembro
e você tem garantia de software,

00:03:56.330 --> 00:04:00.485
você tem um núcleo HA,

00:04:00.485 --> 00:04:04.350
que é síncrono, um núcleo DR.

00:04:04.350 --> 00:04:06.080
Além disso,

00:04:06.080 --> 00:04:13.415
você também tem outro DR
núcleo correndo em VMs Azure.

00:04:13.415 --> 00:04:15.110
Então, se você está correndo em

00:04:15.110 --> 00:04:16.865
uma máquina virtual Azure e você está

00:04:16.865 --> 00:04:19.160
usando isso como um
local de recuperação de desastres,

00:04:19.160 --> 00:04:21.215
você também recebe isso de graça.

00:04:21.215 --> 00:04:23.570
Então, nesta arquitetura,

00:04:23.570 --> 00:04:26.540
digamos que antes de novembro,

00:04:26.540 --> 00:04:27.680
você adicionou um secundário,

00:04:27.680 --> 00:04:30.460
mas isso estava em um VM Azure.

00:04:30.460 --> 00:04:36.220
Você pagaria mais 32 núcleos
desde que este tinha 32 núcleos virtuais.

00:04:36.220 --> 00:04:39.545
Neste caso, eu adiciono outro secundário

00:04:39.545 --> 00:04:43.685
e eu pago zero núcleos por isso.

00:04:43.685 --> 00:04:46.385
Assim, sua arquitetura pode

00:04:46.385 --> 00:04:49.670
realmente alavancar um melhor
alta disponibilidade e

00:04:49.670 --> 00:04:53.765
recuperação de desastres com um
menor custo de propriedade

00:04:53.765 --> 00:04:55.730
com benefícios sQL Server que foram

00:04:55.730 --> 00:04:58.525
mudou de post e novembro primeiro.

00:04:58.525 --> 00:05:01.520
Agora, o que isso lhe dá direito a fazer é,

00:05:01.520 --> 00:05:05.995
você pode realmente levar isso para
qualquer liberação do SQL Server, 2019,

00:05:05.995 --> 00:05:10.370
2017, 2016, e todo o caminho

00:05:10.370 --> 00:05:12.980
a qualquer liberação do SQL Server como

00:05:12.980 --> 00:05:16.145
enquanto esses núcleos são
coberto pela Garantia de Software.

00:05:16.145 --> 00:05:19.250
Se você tem uma arquitetura que é,

00:05:19.250 --> 00:05:21.140
Digamos, uma máquina física.

00:05:21.140 --> 00:05:23.885
Então, se você está em
bare-metal, você entende isso.

00:05:23.885 --> 00:05:26.074
Se você está em máquinas virtuais,

00:05:26.074 --> 00:05:27.860
você também recebe esse benefício.

00:05:27.860 --> 00:05:29.270
Se você está em contêineres,

00:05:29.270 --> 00:05:30.770
você também recebe esse benefício.

00:05:30.770 --> 00:05:35.360
Então, se você está usando SQL
Servidor em um data center físico,

00:05:35.360 --> 00:05:39.125
ou você está usando o SQL Server
em máquinas virtuais,

00:05:39.125 --> 00:05:42.200
ou você está usando Azure
como seu Centro DR

00:05:42.200 --> 00:05:46.745
e você está realmente hospedando
suas primárias no local,

00:05:46.745 --> 00:05:49.010
você terá um benefício DR

00:05:49.010 --> 00:05:51.620
cobrindo seu Servidor SQL
réplicas em Azure.

00:05:51.620 --> 00:05:53.510
Nos próximos episódios,

00:05:53.510 --> 00:05:55.010
vamos realmente falar sobre o que são

00:05:55.010 --> 00:05:56.960
o mais ideal
arquiteturas que alavancam

00:05:56.960 --> 00:05:59.030
esse benefício eficientemente.
Obrigado por se juntar.

00:05:59.030 --> 00:06:10.690
[MÚSICA]