WEBVTT

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

00:00:10.560 --> 00:00:11.895
>> Ciao, mi chiamo Ahmed Banerjee.

00:00:11.895 --> 00:00:14.520
Sono un Group Program Manager con
gruppo di prodotti SQL Server.

00:00:14.520 --> 00:00:17.970
Sono responsabile
motore di database per SQL Server.

00:00:17.970 --> 00:00:19.110
Quindi nel video di oggi,

00:00:19.110 --> 00:00:21.150
stiamo andando a parlare di
l'alto di SQL Server

00:00:21.150 --> 00:00:23.250
disponibilità e disastri
benefici di recupero

00:00:23.250 --> 00:00:26.055
che sono stati introdotti
novembre 2019.

00:00:26.055 --> 00:00:29.910
Quindi andiamo a capire come
effettivamente distribuire SQL Server

00:00:29.910 --> 00:00:31.830
oggi nell'alta disponibilità

00:00:31.830 --> 00:00:33.780
configurazione del ripristino di emergenza.

00:00:33.780 --> 00:00:37.555
Quindi diciamo che hai un primario
un'istanza di SQL Server.

00:00:37.555 --> 00:00:40.040
L'istanza primaria ora può avere,

00:00:40.040 --> 00:00:41.900
a seconda della funzione
che stai usando,

00:00:41.900 --> 00:00:45.080
se si tratta di disponibilità
gruppi o log shipping,

00:00:45.080 --> 00:00:47.285
può avere più secondari.

00:00:47.285 --> 00:00:50.375
Se si dispone di
soluzioni di disponibilità

00:00:50.375 --> 00:00:52.580
come le istanze del cluster di failover,

00:00:52.580 --> 00:00:57.560
allora quelle sono solo soluzioni HA
e non si dispone di un nodo DR,

00:00:57.560 --> 00:01:00.935
è necessario utilizzare altri
tecnologie per la distribuzione di ripristino di emergenza.

00:01:00.935 --> 00:01:06.335
Quindi, se tu avessi questo con
SQL Server 2019 o versione inferiore,

00:01:06.335 --> 00:01:07.790
e questo era, diciamo,

00:01:07.790 --> 00:01:10.220
un altro SQL Server 2019 e oltre,

00:01:10.220 --> 00:01:13.045
e la stessa cosa qui.

00:01:13.045 --> 00:01:15.100
Prima di novembre,

00:01:15.100 --> 00:01:17.660
se si avesse Software Assurance e

00:01:17.660 --> 00:01:20.030
il vostro contratto aziendale ha dato

00:01:20.030 --> 00:01:22.205
funzionalità Software Assurance,

00:01:22.205 --> 00:01:25.739
si sarebbe in grado di
licenza del primario,

00:01:25.739 --> 00:01:28.040
la prima disponibilità elevata o

00:01:28.040 --> 00:01:30.755
La replica di ripristino di emergenza non
devono essere concessi in licenza,

00:01:30.755 --> 00:01:36.070
e la successiva replica DR
continuare a essere concesso in licenza.

00:01:36.070 --> 00:01:39.735
A partire da SQL Server 2019,

00:01:39.735 --> 00:01:43.270
e questo vale per tutti i più anziani
versioni di SQL Server,

00:01:43.270 --> 00:01:45.545
se si dispone della stessa architettura,

00:01:45.545 --> 00:01:47.930
se ora hai un primario,

00:01:47.930 --> 00:01:49.550
Sto solo andando a disegnare questo diritto

00:01:49.550 --> 00:01:52.580
allineato in modo che si tratta di un
un po 'più facile da capire.

00:01:52.580 --> 00:01:54.530
Si dispone di più secondari.

00:01:54.530 --> 00:01:56.240
Diciamo che questo viene utilizzato per

00:01:56.240 --> 00:01:59.015
elevata disponibilità e questo
per il ripristino di emergenza,

00:01:59.015 --> 00:02:02.960
il vostro primario si collegherà per essere
concesso in licenza nell'ambito di Software Assurance.

00:02:02.960 --> 00:02:05.825
La tua prima replica HA,

00:02:05.825 --> 00:02:08.540
che è sincrono
in natura e sostiene

00:02:08.540 --> 00:02:11.660
failover automatico non
non hanno bisogno di essere concessi in licenza,

00:02:11.660 --> 00:02:15.575
e la replica di disastro anche
non ha bisogno di essere concesso in licenza.

00:02:15.575 --> 00:02:17.795
Quindi cerchiamo di capire che cosa
che in realtà significa.

00:02:17.795 --> 00:02:26.720
Quindi diciamo che questo aveva 32
core e tu avevi 32 ciascuno,

00:02:26.720 --> 00:02:28.400
solo per renderlo più semplice.

00:02:28.400 --> 00:02:33.845
Quindi, prima di novembre 2019,

00:02:33.845 --> 00:02:36.860
si dovrebbe
licenza per il primario,

00:02:36.860 --> 00:02:39.979
nessuno per il primo secondario,

00:02:39.979 --> 00:02:46.970
e altri 32 core
per il secondario successivo.

00:02:46.970 --> 00:02:50.490
Ora, se si dispone di un SQL Server o

00:02:50.490 --> 00:02:52.385
qualsiasi versione di SQL Server, purché

00:02:52.385 --> 00:02:54.725
i nuclei sono coperti
dalla garanzia del software,

00:02:54.725 --> 00:02:59.690
ciò che è realmente necessario per la licenza
per il primo posto di novembre,

00:02:59.690 --> 00:03:01.880
Il 2019 è il primario,

00:03:01.880 --> 00:03:05.305
e fino a due secondari,
sarebbe gratuito.

00:03:05.305 --> 00:03:07.605
Ora, ciò che in realtà significa è,

00:03:07.605 --> 00:03:09.825
supponiamo di avere 32 core,

00:03:09.825 --> 00:03:12.920
licenza sarebbe simile a questo.

00:03:12.920 --> 00:03:16.370
Ora, come faccio a configurare questo?

00:03:16.370 --> 00:03:20.615
È il primo prerequisito, è necessario
per avere Software Assurance.

00:03:20.615 --> 00:03:27.900
In secondo luogo, è possibile
licenza dei core sul database primario.

00:03:27.900 --> 00:03:31.580
Il numero di core
il secondario deve

00:03:31.580 --> 00:03:38.430
essere minore o uguale a
numero di core primari.

00:03:39.890 --> 00:03:44.405
Ad esempio, se si
ne avevano più di 32 qui,

00:03:44.405 --> 00:03:46.115
il beneficio non si applicherebbe.

00:03:46.115 --> 00:03:49.520
Quindi, essenzialmente, per ogni
core che si licenza

00:03:49.520 --> 00:03:56.330
per i post di SQL Server novembre
e si dispone di software assurance,

00:03:56.330 --> 00:04:00.485
si ottiene un nucleo HA,

00:04:00.485 --> 00:04:04.350
che è sincrono, un core DR.

00:04:04.350 --> 00:04:06.080
In aggiunta a ciò,

00:04:06.080 --> 00:04:13.415
si ottiene anche un altro DR
core in esecuzione su macchine virtuali di Azure.

00:04:13.415 --> 00:04:15.110
Quindi, se si sta correndo su

00:04:15.110 --> 00:04:16.865
una macchina virtuale di Azure e si sta

00:04:16.865 --> 00:04:19.160
usando che come un
sito di ripristino di emergenza,

00:04:19.160 --> 00:04:21.215
si ottiene anche che gratuitamente.

00:04:21.215 --> 00:04:23.570
Quindi, in questa architettura,

00:04:23.570 --> 00:04:26.540
diciamo prima di novembre,

00:04:26.540 --> 00:04:27.680
hai aggiunto un secondario,

00:04:27.680 --> 00:04:30.460
ma questo era in una macchina virtuale di Azure.but this was on an Azure VM.

00:04:30.460 --> 00:04:36.220
Pagheresti altri 32 core
a condizione che questo avesse 32 core virtuali.

00:04:36.220 --> 00:04:39.545
In questo caso, aggiungo un altro

00:04:39.545 --> 00:04:43.685
e pago zero core per questo.

00:04:43.685 --> 00:04:46.385
Così la vostra architettura può

00:04:46.385 --> 00:04:49.670
effettivamente sfruttare una migliore
disponibilità elevata e

00:04:49.670 --> 00:04:53.765
ripristino di emergenza con un
minor costo di proprietà

00:04:53.765 --> 00:04:55.730
con i vantaggi di SQL Server che sono stati

00:04:55.730 --> 00:04:58.525
cambiato post e novembre prima.

00:04:58.525 --> 00:05:01.520
Ora, ciò che vi dà diritto a fare è,

00:05:01.520 --> 00:05:05.995
si può effettivamente prendere questo a
qualsiasi versione di SQL Server, 2019,

00:05:05.995 --> 00:05:10.370
2017, 2016, e fino in fondo

00:05:10.370 --> 00:05:12.980
a qualsiasi versione di SQL Server come

00:05:12.980 --> 00:05:16.145
fino a quando questi nuclei sono
coperti da Software Assurance.

00:05:16.145 --> 00:05:19.250
Se si dispone di un'architettura che è,

00:05:19.250 --> 00:05:21.140
diciamo, una macchina fisica.

00:05:21.140 --> 00:05:23.885
Quindi, se siete su
bare-metal, si ottiene che.

00:05:23.885 --> 00:05:26.074
Se si utilizzano macchine virtuali,

00:05:26.074 --> 00:05:27.860
si ottiene anche questo beneficio.

00:05:27.860 --> 00:05:29.270
Se siete in contenitori,

00:05:29.270 --> 00:05:30.770
si ottiene anche questo beneficio.

00:05:30.770 --> 00:05:35.360
Quindi, se si sta utilizzando SQL
server su un data center fisico,

00:05:35.360 --> 00:05:39.125
o si sta utilizzando SQL Server
nelle macchine virtuali,

00:05:39.125 --> 00:05:42.200
o si usa Azure
come centro di ripristino di emergenza

00:05:42.200 --> 00:05:46.745
e si sta effettivamente ospitando
primarie in locale,

00:05:46.745 --> 00:05:49.010
si avrà un beneficio DR

00:05:49.010 --> 00:05:51.620
copertura di SQL Server
repliche in Azure.

00:05:51.620 --> 00:05:53.510
Nei prossimi episodi,

00:05:53.510 --> 00:05:55.010
in realtà parleremo di ciò che sono

00:05:55.010 --> 00:05:56.960
il più ottimale
architetture che sfruttano

00:05:56.960 --> 00:05:59.030
questo vantaggio in modo efficiente.
Grazie per esservi uniti.

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