WEBVTT

00:00.210 --> 00:01.620
Instrutor: A virtualização está em toda parte

00:01.620 --> 00:02.790
em nossas redes corporativas.

00:02.790 --> 00:04.710
E o que começou com os servidores virtualizados

00:04.710 --> 00:06.480
agora passou para os desktops com

00:06.480 --> 00:09.570
a infraestrutura de desktop virtual ou VDI.

00:09.570 --> 00:12.330
Esses sistemas podem hospedar sistemas operacionais de desktop

00:12.330 --> 00:13.890
em um ambiente virtualizado que será

00:13.890 --> 00:14.723
hospedado por um servidor

00:14.723 --> 00:17.280
centralizado ou por um farm de servidores.

00:17.280 --> 00:19.470
Essa é uma implementação de virtualização

00:19.470 --> 00:21.510
que separa o ambiente de computação pessoal

00:21.510 --> 00:23.520
do computador físico do usuário.

00:23.520 --> 00:25.200
O usuário final pode então acessar o desktop

00:25.200 --> 00:27.060
virtual a partir de um thin client ou por meio

00:27.060 --> 00:28.410
de um navegador da Web.

00:28.410 --> 00:29.760
E então eles podem interagir com

00:29.760 --> 00:31.050
esse desktop virtualizado como

00:31.050 --> 00:32.040
se estivessem sentados

00:32.040 --> 00:34.350
em frente a um computador desktop padrão.

00:34.350 --> 00:36.750
Por exemplo, tenho uma máquina com Windows

00:36.750 --> 00:38.460
10 que posso acessar na nuvem

00:38.460 --> 00:40.320
como parte de uma rede VDI.

00:40.320 --> 00:42.450
Portanto, se eu quiser usá-lo, lanço um software

00:42.450 --> 00:45.090
no meu Mac e ele se conecta à nuvem e eu me conecto a essa

00:45.090 --> 00:46.980
máquina com Windows 10 e tenho acesso

00:46.980 --> 00:49.020
a todos os recursos de que preciso para ser

00:49.020 --> 00:51.060
executado nessa nuvem.

00:51.060 --> 00:52.820
Agora, esses serviços de VDI têm todo

00:52.820 --> 00:54.090
o sistema operacional, os

00:54.090 --> 00:56.250
aplicativos e tudo o mais de que preciso para

00:56.250 --> 00:58.440
operar essa máquina com Windows 10.

00:58.440 --> 01:00.150
Toda vez que tento executar um comando,

01:00.150 --> 01:02.430
ele o processa nesse servidor de nuvem.

01:02.430 --> 01:04.980
Ele não o processa em meu computador local.

01:04.980 --> 01:07.560
Em vez disso, meu computador local é apenas uma caixa fictícia que

01:07.560 --> 01:08.910
é usada para se conectar a ele.

01:08.910 --> 01:10.920
Essa é a ideia da VDI.

01:10.920 --> 01:12.690
Isso permite que você o tenha em um desktop,

01:12.690 --> 01:15.570
um laptop, um telefone, um tablet, qualquer coisa.

01:15.570 --> 01:16.830
Realmente não importa, porque

01:16.830 --> 01:18.720
o dispositivo está lá apenas para se conectar

01:18.720 --> 01:21.120
ao servidor e executar essa imagem virtual, que

01:21.120 --> 01:23.010
fará todo o processamento dos dados para

01:23.010 --> 01:25.980
você nesse servidor remoto na nuvem.

01:25.980 --> 01:27.660
Portanto, como eu disse, esse servidor

01:27.660 --> 01:29.010
agora está realizando todo o processamento

01:29.010 --> 01:31.920
de aplicativos e o armazenamento de dados.

01:31.920 --> 01:33.750
Isso significa que você pode usar um Chromebook,

01:33.750 --> 01:35.400
um MacBook ou uma máquina Windows.

01:35.400 --> 01:37.350
E, mais uma vez, isso realmente não importa

01:37.350 --> 01:39.450
porque, com a VDI, estamos realmente concentrados

01:39.450 --> 01:41.790
em apenas nos conectar ao ambiente de VDI, mas todo

01:41.790 --> 01:43.650
o processamento está sendo feito no aplicativo

01:43.650 --> 01:46.380
e no lado do servidor para você. Por causa disso, muitas

01:46.380 --> 01:49.740
redes corporativas estão passando por uma evolução para a VDI, com

01:49.740 --> 01:52.080
muitas empresas descarregando completamente

01:52.080 --> 01:54.960
toda a sua infraestrutura de TI usando serviços de terceiros

01:54.960 --> 01:57.720
que usam VDI.

01:57.720 --> 02:00.030
É muito tentador para um CIO fazer isso porque agora

02:00.030 --> 02:01.620
ele não precisa mais executar os sistemas

02:01.620 --> 02:03.000
operacionais.

02:03.000 --> 02:04.560
Eles não precisam se preocupar em aplicar

02:04.560 --> 02:05.760
patches, pois o provedor terceirizado

02:05.760 --> 02:07.440
pode fazer tudo isso por eles.

02:07.440 --> 02:09.690
Esse é um dos grandes benefícios da VDI e um dos principais

02:09.690 --> 02:11.220
recursos de venda.

02:11.220 --> 02:13.380
Mas nem tudo são boas notícias.

02:13.380 --> 02:15.180
Um dos aspectos negativos da VDI é que os usuários

02:15.180 --> 02:16.560
têm uma capacidade de processamento

02:16.560 --> 02:18.150
local muito limitada.

02:18.150 --> 02:21.360
Portanto, se o servidor estiver inativo ou a rede estiver inativa ou

02:21.360 --> 02:22.860
a conectividade estiver inativa,

02:22.860 --> 02:24.990
seus usuários não poderão trabalhar.

02:24.990 --> 02:26.730
Portanto, se houver uma interrupção nesse servidor,

02:26.730 --> 02:28.020
todos ficarão inoperantes.

02:28.020 --> 02:30.420
No entanto, agora estou sentado em meu laptop e, se minha

02:30.420 --> 02:31.920
conexão com a Internet cair, ainda

02:31.920 --> 02:33.570
poderei fazer meu trabalho.

02:33.570 --> 02:35.790
Mas na VDI, eu não poderia fazer isso porque,

02:35.790 --> 02:37.560
se minha conexão de rede cair, não poderei

02:37.560 --> 02:38.940
acessar o servidor.

02:38.940 --> 02:40.800
Portanto, eu não teria sorte.

02:40.800 --> 02:41.910
Portanto, esses são alguns

02:41.910 --> 02:43.830
dos aspectos que devem ser considerados quando

02:43.830 --> 02:44.670
se fala em migrar para

02:44.670 --> 02:47.310
uma solução de virtualização baseada em VDI.

02:47.310 --> 02:48.780
Atualmente, existem três modelos

02:48.780 --> 02:51.060
para implementar infraestruturas de desktop virtual

02:51.060 --> 02:52.290
em nossa rede.

02:52.290 --> 02:54.090
O primeiro é um modelo centralizado.

02:54.090 --> 02:55.980
E isso hospeda todas as instâncias de desktop

02:55.980 --> 02:58.200
em um único servidor ou farm de servidores.

02:58.200 --> 02:59.970
O segundo é um modelo hospedado.

02:59.970 --> 03:02.250
Nesse modelo, os desktops são mantidos por um provedor

03:02.250 --> 03:03.840
de serviços e fornecidos ao usuário

03:03.840 --> 03:05.640
final como um serviço.

03:05.640 --> 03:08.700
Chamamos isso de DAAS ou desktop como serviço.

03:08.700 --> 03:10.740
Serviços como Amazon Workspaces, VMware

03:10.740 --> 03:13.560
Horizon Air e Citrix Xen desktop são apenas alguns

03:13.560 --> 03:15.000
dos provedores mais populares

03:15.000 --> 03:16.500
desse serviço.

03:16.500 --> 03:19.260
O terceiro modelo é um modelo de desktop virtual remoto,

03:19.260 --> 03:21.030
que envolve a cópia da imagem do desktop

03:21.030 --> 03:24.420
para uma máquina local antes de ser usada por um usuário final.

03:24.420 --> 03:25.680
Esse modelo elimina a necessidade

03:25.680 --> 03:27.060
de conexões de rede constantes e tem

03:27.060 --> 03:28.410
muito menos requisitos de largura

03:28.410 --> 03:30.410
de banda do que os outros dois modelos.
