WEBVTT

00:00:00.000 --> 00:00:02.745
>> Clusters de big data fornecem

00:00:02.745 --> 00:00:05.640
uma maneira de manter o cluster
de confiança, permitindo

00:00:05.640 --> 00:00:08.460
alta disponibilidade para crítica
componentes e Mihaela é

00:00:08.460 --> 00:00:12.120
aqui para nos contar tudo sobre
hoje em Dados Expostos.

00:00:12.120 --> 00:00:23.400
[MÚSICA]

00:00:23.400 --> 00:00:26.475
>> Oi, e bem-vindo a outro
episódio de Dados Expostos.

00:00:26.475 --> 00:00:30.480
Eu sou seu anfitrião Jeroen e hoje
temos Mihaela conosco para conversar

00:00:30.480 --> 00:00:32.265
sobre clusters de big data e, em seguida,

00:00:32.265 --> 00:00:34.970
especificamente a alta
disponibilidade para eles.

00:00:34.970 --> 00:00:37.655
Então, bem-vindo de volta. Isto é deve
seja a hora que eu penso.

00:00:37.655 --> 00:00:39.560
>> Sim. Obrigado. Agradecer
você por me ter aqui.

00:00:39.560 --> 00:00:40.985
>> Sim. Você está se tornando uma sonda.

00:00:40.985 --> 00:00:43.550
Assim, a maioria dos tópicos que você fala

00:00:43.550 --> 00:00:46.445
sobre os clusters de big data
e hoje não é diferente.

00:00:46.445 --> 00:00:48.345
Mas então alta disponibilidade, certo?

00:00:48.345 --> 00:00:50.780
>> Sim. Então, há
um monte de coisas para

00:00:50.780 --> 00:00:53.360
falar sobre quando se trata
à alta disponibilidade.

00:00:53.360 --> 00:00:54.155
>> Ok.

00:00:54.155 --> 00:00:57.590
>> Nós vamos passar por alguns
desses aspectos neste vídeo.

00:00:57.590 --> 00:00:59.785
>> Ok. Fresco. Agora vamos começar.

00:00:59.785 --> 00:01:05.745
>> Então, quando falamos de dados
especialmente e bancos de dados,

00:01:05.745 --> 00:01:07.800
queremos ter certeza de que
dados é persistência.

00:01:07.800 --> 00:01:09.110
Então, eu só quero começar com

00:01:09.110 --> 00:01:13.430
esta conversa de alta disponibilidade
com a recapitulação do armazenamento.

00:01:13.430 --> 00:01:13.650
>> Ok.

00:01:13.650 --> 00:01:14.850
>> Camadas tão diferentes em

00:01:14.850 --> 00:01:17.840
o cluster de big data tem
diferentes opções de armazenamento.

00:01:17.840 --> 00:01:20.180
Ou você pode fazer um armazenamento local ou

00:01:20.180 --> 00:01:23.150
remoto e nós fizemos isso tão granular como

00:01:23.150 --> 00:01:25.970
você pode optar por local ou remoto

00:01:25.970 --> 00:01:28.895
dependendo se você quiser
armazenar dados, ou os registros.

00:01:28.895 --> 00:01:33.680
Então, logs que você não quer
necessariamente para torná-lo redundante

00:01:33.680 --> 00:01:36.865
porque você pode precisar dele para

00:01:36.865 --> 00:01:40.930
solução de problemas, mas então você
não quero mantê-los para sempre.

00:01:41.090 --> 00:01:42.190
>> [inaudível].

00:01:42.190 --> 00:01:44.840
>> Exatamente. Então, quando
falamos sobre logs é

00:01:44.840 --> 00:01:48.140
principalmente você quer manter
eles em um armazenamento local

00:01:48.140 --> 00:01:52.355
especialmente porque estávamos conversando
no último vídeo que temos

00:01:52.355 --> 00:01:54.590
componentes nos clusters que são

00:01:54.590 --> 00:01:57.410
coleta ndo os logs e são
iniciando-os em uma busca elástica.

00:01:57.410 --> 00:02:01.615
Então você já tem alguns
dependência desse aspecto.

00:02:01.615 --> 00:02:04.410
Quando se trata de dados,
vários componentes

00:02:04.410 --> 00:02:08.270
têm requisitos diferentes
dependendo de como

00:02:08.270 --> 00:02:10.730
uma missão crítica são e se há

00:02:10.730 --> 00:02:15.140
quaisquer dados do usuário que são armazenados
em para obter dados, por exemplo,

00:02:15.140 --> 00:02:20.030
Mestre ou armazenamento do servidor SQL
pool como dados HDFS é mantido.

00:02:20.030 --> 00:02:22.955
Você quer manter
redundância para isso.

00:02:22.955 --> 00:02:28.445
Mas a piscina de computação ou faísca,

00:02:28.445 --> 00:02:30.695
não há estado.

00:02:30.695 --> 00:02:33.380
É apenas computação.
Portanto, não há nenhum ponto

00:02:33.380 --> 00:02:36.560
para adicionar adicional
redundância para o armazenamento.

00:02:36.560 --> 00:02:38.225
>> Exatamente. Assim, você pode escolher local.

00:02:38.225 --> 00:02:39.470
>> Então estamos falando sobre

00:02:39.470 --> 00:02:42.260
diferentes opções que
você tem que garantir

00:02:42.260 --> 00:02:44.810
a fiabilidade desses serviços

00:02:44.810 --> 00:02:46.400
quando se trata de persistência de dados.

00:02:46.400 --> 00:02:47.620
>> Ok.

00:02:47.620 --> 00:02:51.575
>> É aí que continuamos
com as opções ha, certo?

00:02:51.575 --> 00:02:55.985
Assim, para o mestre do servidor SQL, se o seu
história em seus dados localmente,

00:02:55.985 --> 00:02:57.725
você deve garantir que você está adicionando

00:02:57.725 --> 00:02:59.675
alguma redundância adicional para isso

00:02:59.675 --> 00:03:01.340
com grupos de disponibilidade
e nós vamos

00:03:01.340 --> 00:03:04.160
ver em breve como isso é permitido.

00:03:04.160 --> 00:03:05.990
Quando se trata de pool de dados,

00:03:05.990 --> 00:03:13.970
você usa PVs em combinadores para
garantir que os dados são persistentes.

00:03:13.970 --> 00:03:15.350
>> Então são apenas PVs, certo?

00:03:15.350 --> 00:03:16.505
Há muitos acrônimos aqui.

00:03:16.505 --> 00:03:17.240
>> Sim.

00:03:17.240 --> 00:03:21.110
>> Eg PV, HA, tudo pv é?

00:03:21.110 --> 00:03:25.175
>> Sugere PVs é
um conceito kubernetes

00:03:25.175 --> 00:03:28.250
que abstrai a camada de armazenamento de

00:03:28.250 --> 00:03:32.090
Kubernetes e garante se você está
usando volumes persistentes.

00:03:32.090 --> 00:03:35.270
Assim, a noção é persistência de dados.

00:03:35.270 --> 00:03:37.010
Então, se você estiver usando
volume persistente é ele

00:03:37.010 --> 00:03:38.840
significa que Kubernetes garante que

00:03:38.840 --> 00:03:42.440
Os dados persistem nesse armazenamento.

00:03:42.440 --> 00:03:43.580
>> Ok. Peguei.

00:03:43.580 --> 00:03:46.655
>> Mais uma vez, isso não é necessidade de garantir

00:03:46.655 --> 00:03:49.435
alta disponibilidade para computação
porque é apátrida.

00:03:49.435 --> 00:03:52.110
Ele tem componentes críticos

00:03:52.110 --> 00:03:53.870
na Pilha de Hadoop
logo no que diz respeito

00:03:53.870 --> 00:03:56.600
HDFS NameNode e alguns Spark compartilhados

00:03:56.600 --> 00:04:00.545
serviços que você precisa para
permitir a alta disponibilidade para

00:04:00.545 --> 00:04:03.020
e muito importante eu
quer destacar aqui

00:04:03.020 --> 00:04:09.000
o Serviço de Controle que você deve
têm não só o volume persistente,

00:04:09.000 --> 00:04:11.490
você precisa adicionar um pouco
redundância para essa história.

00:04:11.490 --> 00:04:14.135
Então tem que ser algum
armazenamento redundante remoto.

00:04:14.135 --> 00:04:16.940
Não mantenha seu controle [inaudível]

00:04:16.940 --> 00:04:21.410
localmente, porque se isso
Nó é o último aqui,

00:04:21.410 --> 00:04:23.960
cluster muito inteiro é
não em um muito restrito.

00:04:23.960 --> 00:04:28.130
>> Ok. Então, o controle tem
PVs em um armazenamento remoto?

00:04:28.130 --> 00:04:29.270
>> Remoto e redundante.

00:04:29.270 --> 00:04:31.100
Então você tem que fazer
certeza de que eles adicionam

00:04:31.100 --> 00:04:33.005
alguma redundância nessa camada.

00:04:33.005 --> 00:04:34.710
>> Ok. Observou.

00:04:34.710 --> 00:04:37.290
>> Então, agora vamos ver
o que isso significa para

00:04:37.290 --> 00:04:41.085
Mestre do servidor SQL e
permitindo a AG para isso.

00:04:41.085 --> 00:04:45.095
Portanto, este é um esquema ou

00:04:45.095 --> 00:04:50.045
como o layout de vários serviços
que formam o servidor SQL,

00:04:50.045 --> 00:04:55.190
camada de alta disponibilidade
para o mestre do servidor SQL.

00:04:55.190 --> 00:04:57.020
Mais uma vez, temos uma primária que

00:04:57.020 --> 00:05:00.785
é pelo menos dois secundários
sincronismo direito,

00:05:00.785 --> 00:05:04.670
e construímos componentes que

00:05:04.670 --> 00:05:08.985
estão garantindo que haja
é o monitoramento automático,

00:05:08.985 --> 00:05:11.370
falha automática
e orquestração.

00:05:11.370 --> 00:05:12.960
Se algo acontecer com uma primária,

00:05:12.960 --> 00:05:17.675
acontece automaticamente, lá
não é preciso fazer nada.

00:05:17.675 --> 00:05:20.330
Uma coisa que eu quero
para destacar aqui é

00:05:20.330 --> 00:05:23.870
que para o cluster de big data
só neste momento,

00:05:23.870 --> 00:05:27.755
permitimos também o que chamamos de
Grupo de disponibilidade contido,

00:05:27.755 --> 00:05:30.920
o que significa que agora objeta isso

00:05:30.920 --> 00:05:33.920
você armazena no mestre, por exemplo, como

00:05:33.920 --> 00:05:40.190
logins também são replicados
para os secundários, certo?

00:05:40.190 --> 00:05:40.380
>> Ok.

00:05:40.380 --> 00:05:43.880
>> Então, até agora isso é
os que estão nos enviando de

00:05:43.880 --> 00:05:45.770
nossos clientes para fazer
certeza de que logins

00:05:45.770 --> 00:05:47.930
também são replicados de outra forma,

00:05:47.930 --> 00:05:49.610
há muita sacusação e

00:05:49.610 --> 00:05:51.935
replicação manual que eles tinham que fazer.

00:05:51.935 --> 00:05:55.290
Agora automaticamente
tudo é cuidado.

00:05:55.290 --> 00:05:57.060
Assim, a partir da implantação, de adicionar

00:05:57.060 --> 00:05:59.130
bancos de dados para os grupos de disponibilidade,

00:05:59.130 --> 00:06:05.330
para adicionar este mestre replicado
grupos de disponibilidade de banco de dados.

00:06:05.330 --> 00:06:08.555
Portanto, há pouco ou nenhum

00:06:08.555 --> 00:06:13.130
entre a gestão operacional de

00:06:13.130 --> 00:06:16.620
o grupo de disponibilidade.
Isso é muito legal.

00:06:16.620 --> 00:06:18.660
>> Sim. Isso é realmente
Incrível. Eu ia dizer.

00:06:18.660 --> 00:06:21.230
Então, mas você mencionou
grupos de disponibilidade agora, certo?

00:06:21.230 --> 00:06:21.390
>> Sim.

00:06:21.390 --> 00:06:24.330
>> É esse o regular?

00:06:24.330 --> 00:06:27.200
>> Sim. É exatamente
a mesma característica que nós

00:06:27.200 --> 00:06:30.050
todos sabem de SQL Server 2012, certo?

00:06:30.050 --> 00:06:30.605
>> Sim.

00:06:30.605 --> 00:06:33.440
>> Uma coisa que
É muito importante.

00:06:33.440 --> 00:06:35.960
Não há outra tecnologia de cluster

00:06:35.960 --> 00:06:39.365
que você vai ter que
implantar ou integrar com.

00:06:39.365 --> 00:06:41.445
É tudo cuidado,

00:06:41.445 --> 00:06:44.590
os serviços que estão implantando
com o supervisor ha,

00:06:44.590 --> 00:06:45.730
o operador e de

00:06:45.730 --> 00:06:49.840
curso de integração rigorosa com
Kubernetes ao escrever este caso.

00:06:49.840 --> 00:06:52.560
Então, estamos aproveitando
destas plataformas.

00:06:52.560 --> 00:06:54.100
>> Então, não há mais tecnologia de cluster.

00:06:54.100 --> 00:06:56.650
Então isso é ótimo para o domínio.

00:06:56.650 --> 00:07:00.510
Então agora eu confio no mestre
casos é bom.

00:07:00.510 --> 00:07:02.250
Mas há mais em BDC, certo?

00:07:02.250 --> 00:07:03.965
Não estamos apenas fazendo um servidor SQL,

00:07:03.965 --> 00:07:05.980
estamos fazendo [inaudível]
coisas relacionadas.

00:07:05.980 --> 00:07:07.510
Então, diga-me.

00:07:07.510 --> 00:07:10.230
>> Então vamos olhar para o que somos
fazendo para Hadoop, para HDFS.

00:07:10.230 --> 00:07:13.690
Assim, HDFS NameNode também deve estar em

00:07:13.690 --> 00:07:16.540
uma configuração altamente disponível
porque isso é crítico

00:07:16.540 --> 00:07:20.035
para a Pilha de Hadoop,

00:07:20.035 --> 00:07:23.205
e o que estamos vendo que o
cliente está nos dizendo: ''Oh,

00:07:23.205 --> 00:07:26.395
Eu quero replicação para NameNode'',

00:07:26.395 --> 00:07:28.640
seria também a implantação Zookeeper que

00:07:28.640 --> 00:07:31.430
é uma tecnologia de cluster de código aberto.

00:07:31.430 --> 00:07:35.750
Esse é o componente que está acontecendo
para cuidar da coordenação

00:07:35.750 --> 00:07:39.800
o monitoramento e a falha se

00:07:39.800 --> 00:07:44.970
necessário do NameNode
a um secundário de espera.

00:07:44.970 --> 00:07:45.070
>> Ok.

00:07:45.070 --> 00:07:47.330
>> Então, implantar uma réplica adicional

00:07:47.330 --> 00:07:49.985
e Zookeeper está tomando cuidado
do aspecto orquestração.

00:07:49.985 --> 00:07:50.675
>> Ok.

00:07:50.675 --> 00:07:55.235
>> Ao mesmo tempo
ele também está envolvido em

00:07:55.235 --> 00:07:58.580
manter a alta disponibilidade para

00:07:58.580 --> 00:08:03.679
alguns componentes de compartilhamento da Spark
como o Gerente de Recursos de Fios,

00:08:03.679 --> 00:08:07.520
e nesse sentido para
Faísca também implantamos

00:08:07.520 --> 00:08:12.200
várias réplicas de serviços
como Spark History, Job History.

00:08:12.200 --> 00:08:15.515
Então, para ter certeza de que se algo é

00:08:15.515 --> 00:08:19.900
acontecendo em OneNote que
estes serviços são hospedados,

00:08:19.900 --> 00:08:23.495
O [inaudível] seria escolhido
réplicas para cima ou adicionais.

00:08:23.495 --> 00:08:24.790
>> Legal.

00:08:24.790 --> 00:08:28.490
>> Então vamos ver como é fácil para

00:08:28.490 --> 00:08:32.570
configurar a alta disponibilidade
para os vários componentes.

00:08:32.570 --> 00:08:33.530
>> Diga-me que é fácil.

00:08:33.530 --> 00:08:35.510
>> É super fácil.

00:08:35.510 --> 00:08:38.280
>> Legal. Eu gosto fácil.

00:08:38.470 --> 00:08:42.740
>> Falamos da última vez sobre como
para configurar suas implantações.

00:08:42.740 --> 00:08:43.820
>> Sim. Lembro-me disso.

00:08:43.820 --> 00:08:47.270
>> Há o cluster
arquivos de configuração

00:08:47.270 --> 00:08:49.675
ou modelos de implantação
que você tem,

00:08:49.675 --> 00:08:52.280
e lembre-se que estamos
falando mais cedo sobre

00:08:52.280 --> 00:08:55.700
os componentes de compartilhamento spark.

00:08:55.700 --> 00:08:56.210
>> Sim.

00:08:56.210 --> 00:08:59.975
>> Eu só digo que só quero dois
réplicas deles e é isso.

00:08:59.975 --> 00:09:02.060
Nós cuidamos
Pegando de lá.

00:09:02.060 --> 00:09:03.020
>> É só isso?

00:09:03.020 --> 00:09:04.610
>> O Tratador. Então, de novo,

00:09:04.610 --> 00:09:08.450
temos que passar por todos os
componentes que passamos.

00:09:08.450 --> 00:09:12.980
Zookeeper vamos precisar
três réplicas para garantir quórum.

00:09:12.980 --> 00:09:16.145
Então também mencionamos mestre,

00:09:16.145 --> 00:09:19.465
Instância mestre do servidor SQL
e o que eu faço aqui?

00:09:19.465 --> 00:09:22.755
Eu diria que eu
quer três réplicas,

00:09:22.755 --> 00:09:26.930
e porque o servidor SQL
grupos de disponibilidade

00:09:26.930 --> 00:09:28.985
também permite secundários legíveis,

00:09:28.985 --> 00:09:31.640
lhe dará a opção de

00:09:31.640 --> 00:09:36.440
implantar um serviço que
está expondo um ponto final

00:09:36.440 --> 00:09:39.920
para o dever remotamente carga de trabalho

00:09:39.920 --> 00:09:41.780
do secundário
e você só tem que

00:09:41.780 --> 00:09:44.015
especifique o porto aqui neste caso.

00:09:44.015 --> 00:09:47.900
>> Certo. Então você faz uma alta
disponibilidade e como parte disso,

00:09:47.900 --> 00:09:49.980
você também pode fazer o
ler-somente, [inaudível]

00:09:49.980 --> 00:09:51.365
>> Exatamente. Sim.

00:09:51.365 --> 00:09:54.290
>> Legal. É assim que você lê isso
Assim como uma linha [inaudível]?

00:09:54.290 --> 00:09:57.470
>> Sim. Basta especificar
quantas réplicas você

00:09:57.470 --> 00:10:02.480
não se preocupe em orquestrar,

00:10:02.480 --> 00:10:05.900
implantação adicional
componentes como quando você diz

00:10:05.900 --> 00:10:09.545
nós que eu quero três réplicas
para o mestre do servidor SQL,

00:10:09.545 --> 00:10:10.820
nós implantamos o operador,

00:10:10.820 --> 00:10:12.260
nós implantamos o supervisor que é

00:10:12.260 --> 00:10:14.030
fazendo o monitoramento
e tudo mais.

00:10:14.030 --> 00:10:17.180
Então, tudo está por trás
as cenas e que

00:10:17.180 --> 00:10:21.380
é orquestração mínima
para configurar as coisas.

00:10:21.380 --> 00:10:23.840
Para as pessoas que são
muito familiarizado com a forma como

00:10:23.840 --> 00:10:27.905
para configurar uma disponibilidade
grupos que eu acho que é

00:10:27.905 --> 00:10:32.090
pelo menos quatro ou cinco
Declarações da T-SQL

00:10:32.090 --> 00:10:34.970
além de preparar pontos finais
e coisas assim.

00:10:34.970 --> 00:10:37.355
Então, isso é espinhoso perguntou.

00:10:37.355 --> 00:10:39.830
É tomar essa carga do YouTube para

00:10:39.830 --> 00:10:42.415
foco na corrida
o que está no big data.

00:10:42.415 --> 00:10:44.940
>> Certo. Não fica mais.
simples do que isso, certo?

00:10:44.940 --> 00:10:45.420
>> É.

00:10:45.420 --> 00:10:48.350
>> Uma linha e, em seguida, é claro, se
a instância principal, se você quiser

00:10:48.350 --> 00:10:52.430
mais linhas para ler apenas, mas
Sim, isso é realmente impressionante.

00:10:52.430 --> 00:10:54.740
Fresco. Então, onde posso eu
saber mais sobre isso?

00:10:54.740 --> 00:10:56.385
Como começo?

00:10:56.385 --> 00:11:00.920
>> Então, definitivamente eu vou te mostrar

00:11:00.920 --> 00:11:03.915
exatamente alguns links
que você pode alavancar

00:11:03.915 --> 00:11:07.140
para a implantação,
para a configuração.

00:11:07.140 --> 00:11:11.749
Assim, você pode encontrar ouvir mais sobre
ele em nossa plataforma de documentação

00:11:11.749 --> 00:11:14.000
mas também temos muito
de amostras lá fora

00:11:14.000 --> 00:11:16.460
sobre como configurar as coisas.

00:11:16.460 --> 00:11:18.500
Como executar cargas de trabalho,

00:11:18.500 --> 00:11:21.380
e tudo o que você
pode ir em frente para usar

00:11:21.380 --> 00:11:24.350
estes links e aproveitá-los para
o que fazer o que quiser fazer.

00:11:24.350 --> 00:11:25.490
Vocês serão nossos grupos.

00:11:25.490 --> 00:11:28.550
>> Legal. Bem, obrigado novamente por
compartilhar e falar embora isso.

00:11:28.550 --> 00:11:30.260
Isto é muito impressionante.

00:11:30.260 --> 00:11:32.555
Eu gosto da facilidade de criar isso.

00:11:32.555 --> 00:11:32.760
>> Sim.

00:11:32.760 --> 00:11:34.700
>> Este é claramente um monte de trabalho.

00:11:34.700 --> 00:11:36.695
>> Muito impressionante. Sim. Obrigado.

00:11:36.695 --> 00:11:39.410
>> Bem, obrigado. Agradecer
você para assistir.

00:11:39.410 --> 00:11:41.525
Por favor, assine, inscrevam-se,
deixe um comentário,

00:11:41.525 --> 00:11:43.830
e espero vê-lo
da próxima vez. Thansk.

00:11:43.830 --> 00:11:55.690
[MÚSICA]