Windows Server 2016

Prévia do material em texto

Sumário
Créditos
Agradecimentos
Prefácio
Introdução
Capítulo 01 / Instalar e Licenciar Servidores Windows
Edições
Licenciamento
Modelos de Adoção
Opções de Instalação
Nano Server
Migração e Atualização
Ativação Automática de Máquina Virtual
Ativação Baseada no Active Directory
Preparação do Sistema (Sysprep)
Ferramenta de Planejamento e Adoção
Gerenciamento de Imagens
Estado Desejado de Configuração (DSC)
Simulado
Respostas
Capítulo 02 / Implantar Soluções de Armazenamento
Tipos de Discos
Tabela de Partições
Sistemas de Arquivo
Redundância de Discos (RAID)
Sistemas de Armazenamento
Nível de Armazenamento
Gerenciamento Remoto de Discos
Gerenciamento Linha de Comando
Espaços de Armazenamento
Qualidade de Serviço (QoS)
Políticas de Armazenamento
Replicação
Sistema de Arquivos de Criptografia Resiliente (ReFS)
Eliminação da Duplicação de Dados (Dedup)
Serviços de Armazenamento
Simulado
Respostas
Capítulo 03 / Implantar Hyper-V
Instalação do Hyper-V
Gerenciamento Remoto
Delegação Kerberos
Hyper-V no Hyper-V
Hyper-V no VMWare Workstation
Máquinas Virtuais Linux
Serviços de Integração
Gerações de Máquinas Virtuais
Modo de Sessão Aprimorada
Discos Virtuais
Disco de Passagem
Pontos de Restauração
Adaptador Virtual para Rede de Fibra Óptica
Switches Virtuais
Adaptador de Rede Virtual
Endereço MAC Virtual
VLAN
DHCP Guard
Router Guard
Port Mirroring
Connected Standby
Discrete Device Assignment
Medição de Recursos
Proteção de Recursos
Gerenciamento de Adaptador de Rede Virtual
Gerenciamento de Memória
Boot Seguro com UEFI
Disco Virtual Compartilhado
Versões de Configuração
Simulado
Respostas
Capítulo 04 / Implantar Windows Containers
Conceitos
Containers do Windows Server
Containers do Hyper-V
Instalação da Função Containers
Gerenciamento de Container Docker
Instalação do Docker
Configuração do Docker
Imagens Base
Rede de Container
Portabilidade de Imagens
Volumes
DockerFile
Docker Hub
Docker Compose
Integração com Active Directory
Simulado
Respostas
Capítulo 05 / Implantar Alta Disponibilidade
Recuperação de Desastres
Nível de Acordo de Serviço (SLA)
Replicação Síncrona
Replicação Assíncrona
Cluster de Failover
Tipos de Armazenamento
Volumes Compartilhados do Cluster
Cluster Quorum
Quórum Dinâmico
Forçar Quorum
Conscientização do Site
Domínios de Falha
Site Preferido
Resiliência à Falhas
Modo de Manutenção
Dependências do Active Directory
Atualização de Failover Cluster
Prioridade de Máquinas Virtuais
Grupo de Trabalho e Multi-Domínio
Balanceamento de Carga de Rede
Hyper-V Replica
Hyper-V Replica Broker
Live Migration
Migração de Armazenamento
Exportação e Importação
Detecção da Saúde da Rede
Storage Space Direct (S2D)
Simulado
Respostas
Capítulo 06 / Manter e Monitorar Servidores Windows
Gerenciamento de Atualizações (WSUS)
Atualizações do Windows Defender
Backup do Windows Server
Gerenciador de Tarefas
Monitor do Sistema
Visualizador de Eventos
Gerenciador do Servidor
Monitor de Desempenho
Acesso Remoto
PowerShell ISE
PowerShell Direct
Área de Trabalho Remota
Serviços de Área de Trabalho Remota
Windows Admin Center (WAC)
Simulado
Respostas
Capítulo 07 – Implantar Resolução de Nomes (DNS)
Tipos de zonas
Zona GlobalNames
Tipos de Registros
Escopos
Filtros
Controle Recursivo Seletivo
Eventos
DNS Socket Pool
DNS Cache Locking
Recursão
Ordenação da Máscara
Response Rate Limiting (RRL)
DANE
Delegação na Administração
Protocolo PNRP
DNSSec
Simulado
Respostas
Capítulo 08 / Implantar DHCP E IPAM
Introdução
Funcionamento do DHCP
Instalação e Configuração
Escopos
Super Escopos
Exclusão
Reservas
Opções
Políticas
Escopo Multicast
DHCPv6
Manutenção e Resolução de Problemas
Cópia e Restauração
Atualizações Dinâmicas e Proteção de Nomes
Migrar um Servidor DHCP
Alta Disponibilidade
IPAM
Introdução
Provisionamento e Configuração
Simulado
Respostas
Capítulo 09 – Implantar Soluções de Acesso Remoto
Endereços IP Privados
Roteadores
Tradução do Endereço de Rede (NAT)
VPN P2S
Protocolos de Encapsulamento
Protocolos de Autenticação
Perfil de Conexão
VPN S2S
Políticas de Acesso à Rede
Políticas de Solicitação de Conexão
Políticas de Rede
RADIUS
Logs de Auditoria
Modelos
Direct Access
Simulado
Respostas
Capítulo 10 / Implantar Soluções de Rede Distribuída
Windows Distributed File System (DFS)
DFS Autônomo x DFS Domínio
Considerações para Namespace
AD Site
Servidores de Referência
DFS-R
Topologias de Replicação
Resolução de Problemas
BranchCache
Arquitetura do BranchCache
Versão
BranchCache para Arquivos
BranchCache para Conteúdo Web
BranchCache para Conteúdo de Aplicação
Simulado
Respostas
Capítulo 11 / Implantar Infraestrutura de Rede Avançada
NIC Teaming
vNIC Teaming
Switch Embedded Teaming (SET)
SMB Multichannel
Virtual Machine Multi Queue
Receive Side Scaling (RSS)
SR-IOV
Qualidade de Serviço de Rede (QoS)
Datacenter Bridging
SMB Direct & RDMA
Virtualização de Funções de Rede
Rede Definida por Software (SDN)
Controlador de Rede
Tenant Virtual Network
IPSec
Simulado
Respostas
Sobre o Autor
 
Créditos
Criação da capa | Fiverr
Ilustração da capa | Fiverr
Revisão | Sonia Mendes e Silva
Segunda Edição
Agradecimentos
Dedico esta obra à minha querida família, à minha amável esposa Maria
Emilia, e a todos aqueles que contribuem para um mundo mais igualitário,
pacífico e digno.
“Apenas aqueles que se arriscam a ir mais longe podem descobrir o quão
longe são capazes de ir.”
Thomas Stearns Eliot
Prefácio
Gostaria de dar meus parabéns a você, leitor, que adquiriu este livro, escrito
por um grande amigo meu. Você não está adquirindo apenas um bom livro
técnico, mas também, vai usufruir muitas horas de estudo e pesquisa. Além
disso, boa parte deste conteúdo é resultado de uma carreira, a qual sinto
muito orgulho de ter compartilhado.
Começamos, quase que no mesmo período, a trabalhar na Microsoft.
Lançamos produtos, realizamos palestras nos maiores eventos de tecnologia,
treinamos clientes, parceiros, e desenvolvemos conteúdo para blogs, vídeos e
webcasts.
O Windows Server mudou muito desde sua primeira versão e, felizmente,
tive a oportunidade de trabalhar com este sistema operacional desde o início.
Partilho o mesmo sentimento de gratidão por ter trabalhado com algo que
marca a fundação de nossas carreiras.
Ao iniciar sua leitura sobre o tema containers, esteja preparado para abrir sua
mente e descobrir um novo mundo de possibilidades. Entregas ágeis e
infraestrutura como código vão trazer uma nova perspectiva à maneira como
suas aplicações são entregues.
Além de tudo isso, se você está buscando uma certificação Microsoft, este
livro servirá como um guia preparatório para a Microsoft Certified Solution
Associate (MCSA).
Boa leitura e bons estudos!
Fabio Hara
 Product Marketing Manager | Windows Server | Azure Stack
Introdução
Em agosto de 2016, o Windows Server celebrou 20 anos de existência, desde
que o engenheiro de software David Cutler lançou o Windows NT, em1996.
Naquela época, o sistema operacional para servidores foi lançado com a
seguinte mensagem:
“O Windows NT chegou quando grandes sistemas que funcionam no Unix
predominam, mas exigem grandes investimentos em hardware e extensa
experiência. Ao acoplarmos a interface intuitiva do usuário pela primeira vez,
agora as organizações podem configurar, rapidamente, servidores de
arquivos, impressão e aplicativospara toda a empresa usando um hardware
mais conveniente”
Talvez Cutler não imaginasse, mas ele estava praticamente inserindo a
Microsoft ao mundo dos negócios corporativos, e iniciando a competição
com a Novell Inc, cujo software Netware dominava a rede de computadores
em empresas. Durante os anos 80, os negócios da Novell estavam indo muito
bem. A empresa detinha uma posição de monopólio com o seu sistema
operacional, e podia vender seus produtos a um preço alto. Isso mudou nos
anos 90, à medida que o Windows NT (New Technology) e,
consequentemente, o Windows 2000 Server, com o Active Directory,
ganhavam, pouco a pouco, funções de rede e participação de mercado.
Nestes 20 anos, um grande ecossistema foi formado em torno do Windows
Server, incluindo comunidades, centros de treinamento, capacitação,
certificações profissionais e consultorias especializadas.
Bem-vindo, obrigado pelo prestígio, e boa leitura.
Gilson Banin
CAPÍTULO 01 - Instalar e
Licenciar Servidores Windows
Seja bem-vindo!
Neste primeiro capítulo, vamos conhecer um pouco mais sobre o que mudou,
desde o Windows Server 2012 R2, sobre licenciamento, edições, métodos de
atualização, migração baseados em versões anteriores, gestão na criação de
imagens para instalações físicas e virtuais, automatizaçao da entrega de
imagens com o estado desejado de configuração, ferramentas e métodos de
ativação por volume, além das novas características do recém- lançado Build
1709.
Todas as expressões técnicas serão mantidas em inglês, na sua forma original,
e não serão traduzidas para o português. Gostaria de ressaltar a importância
de fazer suas instalações do Window Server na versão em inglês, pois as
atualizações de segurança, melhorias e correção de problemas sempre são
liberadas primeiras neste idioma, que é o padrão universal.
Edições
Existem duas edições principais e várias edições menores. As edições
principais são:
Windows Server 2016 Standard: Uma edição adequada para ambientes de
menor escala, pequenas e médias empresas, onde a maioria dos servidores
são físicos, e não virtuais. É licenciada por núcleo de processador e requer
licenças de acesso para cliente (Client Access Licensing) do Windows
Server. Esta edição permite, no máximo, duas máquinas virtuais e dois
containers por host físico. Licenciada com valor aproximado de US$ 882,00.
Windows Server 2016 Datacenter: Esta edição é adequada para datacenters
que incluem virtualização. Também é licenciado por núcleo de processador e
requer licenças de acesso para cliente (CALS). Esta versão permite um
número ilimitado de máquinas virtuais e containers para cada host físico.
Licenciada com valor aproximado de US$ 6.155,00.
Ambas suportam 64 processadores físicos (sockets) e 512 lógicos (cores), 24
TB de memória e 64 nodes em um cluster de failover, com exceção do
Failover Cluster de Storage Space Direct (S2D), limitado ao máximo de 16
nodes. Outras poucas diferenças entre elas se referem aos serviços de Storage
Space Direct, Network Controller, Shields Virtual Machine, Storage Replica
e Software Defined Networking, que estão disponíveis somente na versão
Datacenter. Todas estas funcionalidades serão abordadas e explicadas, em
detalhes, nos próximos capítulos.
As outras edições menores e mais específicas do Windows Server 2016 são:
Windows Server 2016 Essentials. Esta é a edição para pequenas empresas,
permite até 25 usuários e 50 dispositivos e é licenciada por processador
físico. Esta edição não requer Client Access Licensing por usuário ou
dispositivo.
Windows Server 2016 Multipoint Premium Server. Esta edição foi
desenhada para o mercado de educação e está disponível somente para
organizações educacionais, tais como: escolas públicas, privadas,
profissionalizantes e universidades. Permite o acesso remoto a múltiplos
terminais (um único servidor para múltiplos estudantes) e o licenciamento se
dá por processador físico.
Windows Storage Server 2016. Uma edição especial para soluções de
armazenamento de dados e licenciados somente no modo OEM, ou seja, é
vendida junto com um hardware de armazenamento, obrigatoriamente. O
licenciamento é por processador físico e não requer CAL.
Microsoft Hyper-V Server 2016. Uma edição gratuita do hypervisor Hyper-
V 2016, que pode ser instalada em servidores físicos, independentemente do
número de processadores físicos e virtuais, e não requer CAL. A única
condição para o bom funcionamento das máquinas virtuais neste host, é que
elas precisam ter sua própria licença e devem ser ativadas por serviços como
o KMS. A versão do Hyper-V Server não suporta o serviço Virtual Machine
Activation Services (VMAS), que conheceremos neste capítulo.
Requisitos de hardware. As configurações mínimas de hardware são:
Processador 1.4 GHz x64 com suporte ao DEP
SLAT (Second Address Translation); (EPT ou NPT)
512 MB ou 2 GB ECC Memory
32 GB de espaço em disco livre
 
Licenciamento
Tivemos, também, mudanças significativas no licenciamento do Windows
Server 2016. A principal delas foi a maneira como o servidor é licenciado,
que, por muitos anos, foi “Por Pares de Processador Físico” e, agora, passou a
ser “Por Core”. Essa mudança tem um motivo muito simples: diminuiu o
número de processadores físicos (sockets) em um servidor de baixo e médio
porte, enquanto aumentou o número de processadores lógicos (core) ,
especialmente pela evolução e o aumento da miniaturização dos seus
componentes.
Muitos servidores possuíam 04 sockets, com 04 ou 08 cores. Hoje são muito
mais comuns os servidores com 02 sockets, mas com 10 ou mais cores. Um
exemplo disso são os processadores da Intel Xeon E5-2650, com 10 cores, e
Intel Xeon E7-8890, com 24 cores. Assim, não só a Microsoft, mas outros
grandes fornecedores estão mudando a cobrança do licenciamento de socket
para core, impondo um mínimo de core para cada servidor.
A tabela abaixo ilustra como era o licenciamento no Windows Server 2012
R2, e como está agora com o Windows Server 2016.
OS Sockets Cores Tipo Licença
2012 R2 01 02 Socket 01 de 02 sockets
2012 R2 01 10 Socket 01 de 02 sockets
2012 R2 02 8 Socket 01 de 02 sockets
2012 R2 03 / 04 24/32 Socket 02 de 02 sockets
2016 01 02 Core 08 de 02 cores
2016 01 10 Core 08 de 02 cores
2016 02 08 Core 08 de 02 cores
2016 03 24 Core 12 de 02 cores
2016 04 32 Core 16 de 02 cores
 
Em resumo, todo servidor físico com Windows Server 2016 precisará ser
licenciado com, no mínimo, 16 cores, mesmo que o número de core seja
menor.
Proporcionalmente, as licenças de 02 sockets, pagas até a versão Windows
Server 2012 R2, equivalem a 08 licenças de 02 cores no Windows Server
2016.
Modelos de Adoção
O Windows Server 2016 suporta, agora, dois tipos de adoção e
suportabilidade: Long Term Servicing Branch (LTSB) e Semi-Annual
Channel (SAC)
Long Term Servicing Branch (LTSB) é um modelo já bem conhecido e
estabelecido no mercado, desde seu nascimento, há 20 anos. Uma nova
edição é lançada a cada 2 ou 3 anos, e o suporte é dado por 5 anos, com mais
5 anos de suporte estendido, disponível para todos os clientes, em todos os
canais de licenciamento e distribuição.
Semi-Annual Channel (SAC) é um novo canal de distribuição para clientes
que estão inovando, com a adoção de containers e micro serviços, e clientes
que precisam de novas funcionalidades para Software-Defined Datacenter e
Hybrid Cloud. Este novo canal só estará disponível para clientes com um
contrato de Software Assurance (garantia de atualização do produto), e os
suportes destas versões serão mantidos por 18 meses. Ainda, com o foco nos
cenários de containers e SDDC, a Microsoft decidiu que apenas as edições
Standard e Datacenter fariam parte deste novo modelo, e os Server Core
Build 1709 e Nano Server Build 1709, rodando como um container, seriam as
únicas instalações disponíveis. A versão Desktop Experience não será
suportada no modelo SAC.
Outraobservação importante trata do licenciamento do Windows Server 2016
em Cloud Computing, como o Microsoft Azure. É incrível observar que, na
nuvem nada mais é comprado, mas sim alugado, e parte do valor pago pelo
aluguel equivale ao licenciamento do sistema operacional.
Nota
40% é a porcentagem dos custos de licenciamento do Microsoft
Azure. Por exemplo, se você tem uma máquina virtual com o
Windows Server e seu custo mensal é de US$ 100,00, US$
40,00 equivale ao licenciamento do Windows, e 60%, à
computação (disponibilidade, memória e processador). Você
pode fazer a portabilidade de licença do Windows Server, se
sua empresa já pagou por ela dentro de um contrato por volume
que tenha o benefício do Software Assurance. Neste caso, o
custo mensal desta máquina passaria a ser de US$ 60,00, e não
mais US$ 100,00. Uma economia de US$ 480,00 ao ano. Este
benefício também se aplica a servidores SQL Servers.
 
O benefício da portabilidade de licença é conhecido como HUB (Azure
Hybrid Benefit) e deve ser selecionado como uma opção no momento, ou
depois, da criação da máquina virtual.
Este desconto de 40% é aplicado com base em uma propriedade da máquina
virtual, que no Azure é chamada LicenseType. Se este atributo estiver com o
valor “None” ela é considerada “Pay as you go” e o valor total será cobrado.
Agora, se o valor estiver “Windows_Server”, o desconto será concedido.
Converse com seu gerente de conta Microsoft e, caso sua empresa possa
usufruir deste benefício, converta suas máquinas virtuais de “Pay as you go”
para HUB, através do Azure Power Shell. Agora, também há uma interface
gráfica para aplicar este desconto através do portal do Azure.
$vm = Get-AzureRMVM -ResourceGroup “RGName” -Name
“VMName”
$vm.LicenseType = “Windows_Server”
Update-AzureRMVM -ResourceGroup “RGName” -VM $vm
 
Opções de Instalação
Antes de instalar o sistema operacional, você precisará tomar uma série de
decisões. As escolhas que você fará serão determinadas pela função que o
servidor exercerá na rede. Você terá que decidir qual edição do Windows
Server deseja instalar, e se instalará a versão com Desktop Experience,
também conhecida como GUI (Graphical User Interface), um Server Core ou,
até mesmo, um Nano Server.
FIGURA 01-01. Setup do Windows Server 2016
Ao usar o assistente de instalação para instalar o Windows Server 2016, é
possível escolher entre o Windows Server 2016 e o Windows Server (with
Desktop Experience). A opção com experiência de desktop é equivalente à
opção de instalação completa, disponível no Windows Server 2012 R2 com o
recurso Desktop Experience instalado. Se você não fizer uma escolha no
assistente de instalação, o Windows Server 2016 será instalado. Esta é a
opção de instalação do Server Core.
Windows Server 2016 com Experiência de Desktop
A opção servidor com experiência de desktop instalará a interface do usuário
padrão e todas as ferramentas, incluindo recursos de experiência do cliente,
que exigiam uma instalação separada do Windows Server 2012 R2. As
funções e os recursos do servidor são instalados com o Server Manager, ou
através do PowerShell, ou outros métodos. Comparado à opção Server Core,
o Desktop Experience demanda maior espaço em disco e manutenção mais
frequente, portanto recomendo que você escolha a instalação Server Core, a
menos que tenha uma necessidade específica dos elementos adicionais da
interface do usuário e das ferramentas gráficas de gerenciamento, que estão
incluídas na opção Desktop Experience.
FIGURA 01-02. Windows Server 2016 Full com Experiência de Desktop
 
 
Nota
Ao contrário de algumas versões anteriores do Windows Server,
não é possível fazer a conversão de Server Core para Server
com Desktop Experience após a instalação. Se você instalar o
Server Desktop Experience e, posteriormente, decidir usar o
Server Core, deverá fazer uma nova instalação.
 
Windows Server 2016 Core
Na opção Server Core, a interface padrão do usuário (Desktop Experience)
não é instalada, e o gerenciamento do servidor se faz pela linha de comando,
pelo Windows Power Shell e por outros métodos. O Server Manager não está
disponível localmente e você precisará instalar o RSAT (Remote Server
Administration Tools) em um computador Windows 10 Enterprise para
gerenciá-lo remotamente, de maneira gráfica. Há, também, um utilitário de
linha de comando padrão, que permitirá executar as primeiras tarefas, tais
como alterar o nome, configurar um IP estático e inserir o domínio do Active
Directory. Execute o comando sconfig para entrar no menu de seleção
principal.
FIGURA 01-03. Windows Server 2016 Core
Domain / Workgroup. As configurações de domain/workgroup atuais são
exibidas na tela da ferramenta de configuração do servidor padrão. Você pode
ingressar em um domínio, ou em um grupo de trabalho, acessando a página
de configuração Domain/Workgroup no menu principal, e seguindo as
instruções.
Se um usuário de domínio não tiver sido adicionado ao grupo Local
Administrator, não será possível fazer alterações no sistema, como alterar o
nome do computador, por exemplo, usando o usuário de domínio.
Computer Name. O nome do computador atual é exibido na tela de
configuração inicial. Você pode alterar o nome do computador acessando a
página de configurações “Computer Name” no menu principal.
Add Local Administrator. Para adicionar mais usuários ao grupo Local
Administrators, use a opção adicionar administrador local no menu principal.
Em uma máquina membro de um domínio, insira o usuário no seguinte
formato: DOMAIN\User. Em uma máquina associada à um workgroup,
digite apenas o nome do usuário. As alterações entram em vigor
imediatamente.
Configure Remote Management. Use esta opção para permitir ou negar o
acesso remoto a este servidor através do Server Manager, e para permitir ao
servidor responder por requisições ICMP (Ping).
Windows Update Settings. As configurações atuais do Windows Update são
exibidas na tela de configuração do servidor padrão. Você pode configurar o
servidor para usar as atualizações automáticas ou manuais na opção
Configurações do Windows Update, no meu principal.
Quando atualizações automáticas forem selecionadas, o sistema procurará e
instalará as atualizações todos os dias as 03:00 da manhã. As configurações
entram em vigor imediatamente. Quando atualizações manuais forem
selecionadas, o sistema não verificará as atualizações automaticamente.
A qualquer momento, você poderá baixar e instalar atualizações aplicáveis
usando a opção Download and Install Updates no menu principal. A opção
somente download verificará se há atualizações e baixará qualquer uma que
esteja disponível. Em seguida, enviará uma notificação na central de ações,
quando elas estiverem prontas para instalação. Essa é a opção padrão.
Remote Desktop. O status atual de configurações da área de trabalho remota
é exibido na tela ferramenta de configuração do servidor. Acessando a opção
do menu principal e seguindo as instruções, você poderá definir as seguintes
configurações de área de trabalho remota: 
Habilitar a área de trabalho remota para clientes com autenticação no
nível de rede (mais segura)
Habilitar a área de trabalho remota para clientes (menos segura)
Desativar a área de trabalho remota
 
Quando habilitada, a porta TCP 3389 será exposta. Esta é a porta mais
vulnerável e alvo dos maiores ataques de força bruta no Windows Server.
Nunca exponha diretamente esta porta à Internet.
 
Network Settings Você pode configurar o endereço IP, a ser atribuído
automaticamente por um servidor DHCP, ou pode atribuir um endereço
estático manualmente. Esta opção permite que se definam as configurações
do servidor DNS primário e secundário. Além do sconfig, você poderá usar o
comando New-NetIPAddress para configurar o IP, máscara e gateway e o
comando Set-DnsClientServerAddress para os endereços de Dns primárioe
secundário.
# Configurar o TCP/IP de um Server Core usando Powershell
New-NetIPAddress -InterfaceAlias “Ethernet 1” -IPv4
192.168.0.11 -PrefixLength 24 -DefaultGateway 192.168.0.254
 
# Configurar os servidores de DNS
Set-DnsClientServerAddress -InterfaceAlias “Ethernet 1” -
ServerAddress 192.168.0.1, 192.168.0.2
 
# Para alterar a interface de IP estático para DHCP
Set-NetIPInterface -InterfaceAlias “Ethernet 1” -Dhcp Enabled
 
Date and Time. Você pode acessar e alterar as configurações de data e hora
acessando a opção Data e Hora no menu principal.
Telemetry Settings. Essa opção permite que você configure quais dados
serão enviados à Microsoft.
Windows Activation. Essa opção permite configurar a ativação do Windows
Server Core. Na prática, ela aciona o script Slmgr.vbs localizado na pasta
C:\Windows\system32. Vamos explorar, abaixo, alguns dos parâmetros mais
comuns:
Slmgr.vbs -ipk XXXX-XXXX-XXXX-XXXX. Faz a troca da chave do
Windows Server por uma nova.
Slmgr.vbs -ato. Permite a ativação rápida do produto.
Slmgr.vbs -dli. Exibe informações da licença e status de ativação.
Slmgr.vbs -xpr. Exibe a data de validade da ativação.
Slmgr.vbs -skms. Define as configurações de porta e servidor KMS (Key
Management Service) ativos na rede. Permite apontar as estações de
trabalho, ou servidor, para um servidor membro que detêm os dados de
licenciamento interno da empresa.
Slmgr.vbs -cpky. Limpa os dados de chave de produto do registro,
evitando o ataque de divulgação de chaves.
 
Mantenha suas chaves de ativação sempre muito bem guardadas. A exposição
delas gerará problemas de licenciamento e elas poderão ser alvo de múltiplas
ativações indevidas.
Windows Server 2016 Nano
O Windows Server 2016 oferece uma nova opção de instalação. O Nano
Server é um sistema operacional de servidor administrado remotamente e
otimizado para datacenter e nuvens privadas. É semelhante ao Windows
Server Core, mas significativamente menor, e só oferece suporte a um
conjunto muito pequeno de serviços, além de exigir aplicativos de 64 bits.
Ocupa bem menos espaço em disco, instala e reinicia muito mais rápido, e
exige muito menos atualizações.
O Nano Server é ideal para um conjunto restrito de cinco serviços:
Host do Hyper-V incluindo cluster.
Servidor de arquivos SOFS – Scale Out File Server
Servidor de nomes DNS – Domain Name System
Servidor Web executando o IIS – Internet Information Services
Container host para hospedagem de aplicações em micro serviços
 
Nano Server
Tendo em vista que o Nano Server tanto pode ser considerado um sistema
operacional leve para execução de aplicativos “nativos da nuvem” com base
em containers e micro serviços, como um host de datacenter ágil e
econômico, com uma superfície consideravelmente muito menor, há
importantes diferenças entre as instalações do Nano, Core e Full. Veja,
abaixo, quais são as principais:
O Nano Server é “sem periféricos” e não há interface gráfica do usuário.
O Remote Desktop não é suportado no Nano Server. Você não conseguirá
administrá-lo pelo MSTSC, e sim pelo Remote Powershell ou Server
Manager.
Há suporte apenas para “agentes” pré-embarcados, não para instaladores
MSI.
O Nano Server não pode ser um Domain Controller.
Não há suporte para GPO, e o Desired State Configuration precisa ser
adotado para configuração e padronização em massa.
O Nano Server não dá suporte para acessar a Internet através de um
servidor de Proxy. Você precisará liberá-lo através do firewall, se
necessário.
NIC Teaming não é permitido no Nano Server. Use o SET (Switch
Embedded Teaming) no seu lugar.
Não há suporte para o System Center Configuration Manager (SCCM),
nem para o System Center Data Protection manager (SCDPM)
O Nano Server não dá suporte à Host Bus Adapters (HBA)
O servidor não precisa ser ativado com uma chave de produto (Product
Key) e não é compatível com o AVMA (Automatic Virtual Machine
Activation). Para ativá-lo, é preciso um servidor KMS (Key Management
Server) ou o Active Directory.
A versão do Windows PowerShell do Nano Server é diferente das versões
Core e Full. Esta versão enxuta do PowerShell é conhecida como
Powershell Core.
O Nano Server não está disponível no modelo LTSB, mas somente no
SAC.
Como o Nano Server é novo no Windows Server 2016, não existe um
caminho de upgrade, nem migrações de versões anteriores do sistema
operacional.
 
Nano Server no Hyper-V
Execute as tarefas nesta sessão para iniciar, rapidamente, uma implantação
básica do Nano Server, usando o DHCP para obter um endereço IP. Pode-se
executar um VHD do Nano Server, em uma máquina virtual, ou inicializá-lo
em um servidor físico, mas as etapas serão um pouco diferentes.
Depois de experimentar os conceitos básicos, com estas etapas de início
rápido, você poderá encontrar maiores detalhes sobre a criação de suas
próprias imagens personalizadas, incluindo gerenciamento de pacotes,
inclusão como um membro do domínio do Active Directory, e muito mais.
A implantação do Nano Server é diferente de tudo o que você já estudou
sobre métodos de instalação de um sistema operacional Windows Server. A
instalação do Nano não é realizada como uma opção no boot da imagem .ISO
do Windows Server 2016. É necessário, primeiramente, construir a imagem
através de um script Powershell, ou através de uma ferramenta gráfica,
conhecida como Nano Server Image Builder, cujo download gratuito está
disponível no site da Microsoft.
A primeira coisa a fazer é mapear o arquivo .ISO do Windows Server 2016
no seu computador. Nele, haverá uma pasta chamada NanoServer e, dentro
dela , haverá um arquivo NanoServer.wim e duas pastas: uma, chamada
NanoServerImageGenerator, que contém o módulo do PowerShell a ser
importado para construir nossa primeira imagem Nano, e outra, chamada
Packages, que apresenta arquivos .cab. Copie a pasta NanoServer inteira para
o seu computador.
Abra o PowerShell e importe o módulo NanoServerImageGenerator.psm1,
localizado na pasta NanoServer\NanoServerImageGenerator.
Import-Module
C:\Temp\NanoServer\NanoServerImageGenerator\NanoServerImageGenerator.psm1
-Verbose
 
Agora, crie uma imagem. Este exemplo cria um VHDX, a partir de um ISO
montado como E:\. Ao criar o VHDX. Ele usará uma pasta chamada Base no
mesmo diretório em que você executou o New-NanoServerImage, e, depois,
incluirá o VHDX também na raiz do diretório. O nome do computador será
NANO. O VHDX conterá a edição Datacenter do Windows Server 2016, e
será configurado para implantação como máquina virtual, devido ao
parâmetro -Guest. Você também poderá gerar, diretamente, um arquivo
.WIM, especificando uma extensão .wim para -TargetPath.
New-NanoServerImage -Edition Datacenter -DeploymentType
Guest -MediaPath E:\ -BasePath .\Base -TargetPath
.\NANO.vhdx -ComputerName NANO
 
Nota
Para instalar a função Hyper-V na sua imagem Nano Server use
o parâmetro adicional-Compute. O valor Guest, para o
parâmetro –DeploymentType, significa que se trata de uma
máquina virtual e os drivers do Hyper-V serão embarcados.
Agora, se deseja instalar a imagem em um servidor físico,
substitua o valor Guest pelo valor Host.
 
Ao efetuar o logon no servidor pela console, você não encontrará muitas
opções de configuração, além de alterar o IP de DHCP para um IP fixo,
regras de firewall para conexão Inbound e Outbound, e a opção de habilitar o
WinRM, o que permitirá o Hyper-V Manager conectar e gerenciar as
máquinas virtuais, caso este seja um servidor físico com o pacote do Hyper-V
instalado.
FIGURA 01-04. Windows Server 2016 Nano
Para escolher entre as opções, basta percorrer pelas setas do teclado,
lembrando-se de que o mouse não tem função alguma no Nano. Com a tecla
ESC você realiza um log out, F5 atualiza, Ctrl+F6 reinicia, e Ctrl+F12
desliga o servidor.
Nano Server no VMWare
Caso pretenda criar uma máquina virtual Nano Server para o VMWare
Workstation,ou VMWare ESXi, os drivers do VMWare Tools devem ser
inseridos durante a criação da imagem.
Para mapear os drivers do VMWare Tools, você poderá baixá-los no site da
VMWare, ou através de um Data Store existente. Este exemplo demonstra o
procedimento no VMWare Workstation 12, que roda no Windows 10
Enterprise.
Mapeie o arquivo dos drivers do VMWare Tools no seu computador.
C:\Program Files (x86)\VMWare\VMWare
Workstation\Windows.iso
 
Extraia os arquivos para uma pasta temporária.
D:\Setup64.exe /a /p C:\Temp\Nano\VMTools
 
Use o subdiretório Drivers para localizar os drivers com a extensão .INF
C:\Temp\Nano\VMTools\VMWare\VMWare
Tools\VMWare\Drivers
 
Adicione o driver para Storage chamado pvscsi.inf, que está localizado na
pasta Drivers\pvscsi\win8\amd64
Para imagens que serão implementadas no VMWare ESXi, outros dois
drivers de placas de rede precisam ser incluídos : vmxnet3ndis6.inf e
vmxnet3ndis5.inf
FIGURA 01-05. Windows Server 2016 Nano Recovery Console
Nano Server Image Builder
O Nano Server Image Builder o ajudará na criação de suas imagens Nano, de
uma maneira mais visual e intuitiva. Baixe o software, através do site
microsoft.com/downloads, e instale em seu computador pessoal com
Windows 10 Enterprise ou, até mesmo, Windows Server 2016. Como pré-
requisito instale primeiro o Windows ADK (Windows Assessment and
Deployment Kit), ferramenta que ajudará você customizar imagens do
Windows em larga escala. Escolha as opções “Deployment Tools” e
“Windows Preinstallation Environment (Windows PE)” durante a instalação.
 
Se você deseja criar um pen drive com uma imagem “bootable”, que
permitirá sua rápida instalação em servidores físicos selecione a opção Create
a bootable USB media.
FIGURA 01-06. Nano Server Image Builder
Nota
A ferramenta Nano Server Image Builder gera somente
arquivos no formato .VHD e .VHDX para o Hyper-V. Será
necessária uma ferramenta de terceiros para convertê-los no
formato .VMDK, suportado pelo VMWare.
 
Nano Server Membro de Domínio
Muito provavelmente, ao implementar o Nano Server como Hyper-V, ou em
cluster, você terá de inseri-lo ao domínio do Active Directory. Existem duas
maneiras de fazer isso: a primeira, na criação da imagem, e a segunda,
quando a imagem já está criada.
Para ambos os casos, usa-se um método chamado Domain Offline Join, do
Active Directory Domain Service.
Vá até um dos seus controladores de domínio e execute o comando:
C:\djoin /provision /domain banin.net.br /machine NANO
/savefile C:\nanojoin.djoin
 
Marque a opção Join domain no wizard do Nano Server Image Builder,
selecione a opção Domain blob file e escolha o arquivo .djoin. Substitua o
nome de domínio banin.net.br pelo nome do seu domínio do Active
Directory.
Nota
Caso pretenda inserir o servidor ao domínio do Active
Directory, deixe o campo computer name vazio, utilizando o
método Domain Offline Join, através do Nano Server Image
Builder.
 
Para inserir um servidor Nano existente ao domínio do Active Directory,
copie o arquivo nanojoin.djoin para dentro da máquina virtual e execute o
seguinte comando:
C:\djoin /requestodj /loadfile C:\nanojoin.djoin /windowspath
C:\Windows /loados
 
O servidor Nano deverá ser reiniciado com o comando shutdown /r. Logo
após, poderá efetuar um login com uma conta do domínio.
PowerShell Scripting
O Nano Server Image Builder gera um script final, que pode ser reutilizado
para a criação de futuras imagens. Este é o script completo para a criação de
uma imagem Nano Virtual inserida ao domínio do Active Directory, com o
VMWare Tools instalado, e com o time Zone e IP estático configurados.
New-NanoServerImage -MediaPath 'E:\' -Edition 'Datacenter' -
DeploymentType Guest -TargetPath
'C:\Temp\NANOSERVER.vhd' -MaxSize 8589934592 -
DomainBlobPath 'C:\Users\gbanin\Desktop\nanojoin.djoin' -
EnableRemoteManagementPort -InterfaceNameOrIndex '1' -
Ipv4Address '192.168.194.115' -Ipv4Dns '192.168.194.100' -
Ipv4SubnetMask '255.255.255.0' -Ipv4Gateway '192.168.194.2'
-SetupUI ('NanoServer.DNS', 'NanoServer.Defender') -
DriverPath ('F:\Program Files\VMware\VMware
Tools\Drivers\pvscsi\Win8\amd64\pvscsi.inf') -
SetupCompleteCommand ('tzutil.exe /s "E. South America
Standard Time"') -LogPath 'C:\
Temp\NanoServerImageBuilder\Logs'
 
Em outubro de 2017, a Microsoft lançou o build 1709 do Windows Server
2016, que foi a primeira versão do modelo SAC. A versão 1709 não é uma
atualização, e não está disponível para todos os clientes (somente para
aqueles que possuem contrato por volume). Além disso, devido ao diferente
modelo de distribuição e suporte, o upgrade in-place não é permitido, tudo
isso para evitar que clientes do modelo LTSC o atualizem para uma versão
SAC e entrem, inadvertidamente, em um modelo de suporte de 18 meses,
Esta questão será revisada no futuro, dependendo da aceitação, desta nova
versão SAC, no mercado.
A versão 1709 significa que foi lançada em 2017 (17), no nono mês (09), ou
seja, setembro de 2017, e assim será o padrão para as futuras versões.
Especialmente neste build, o Storage Space Direct foi removido, e a edição
Nano Server passou a ser disponibilizada somente como um container.
Windows Server 2016 – Build 1709
As etapas de instalação do Windows Server versão 1709, são as mesmas das
versões anteriores , a partir de uma imagem .ISO, com as seguintes exceções:
Não há upgrade com suporte em versões anteriores do Windows Server
para a versão 1709. Uma nova instalação se faz necessária. Isso significa
que, quando você executa o setup.exe na área de trabalho, a experiência
de configuração não permite a opção de upgrade (ela estará desativada).
Não há versão de avaliação (trial) para o Windows Server Build 1709.
Não há OEM ou versão de varejo (retail). O Windows Server versão 1709
pode ser licenciado somente por meio do programa Software Assurance
ou de programas de fidelidade, como o Volume Licensing.
 
Windows Server 2016 Nano - Build 1709
O Nano Server passou a ser oferecido somente como um container e, não
mais uma opção de instalação, como máquinas virtuais ou físicas. Além
disso, há outras mudanças que iremos, agora, conhecer.
Caso já esteja executando o Nano Server, este modelo de manutenção soará
familiar, pois já vem sendo executado pelo modelo SAC (Semi-Annual
Channel). O novo canal semestral do Windows Server é, apenas, um novo
nome para o mesmo modelo. Neste modelo, espera-se versões de atualização
de recursos do Nano Server duas a três vezes ao ano.
No entanto, com relação ao novo Build 1709 do Windows Server 2016, o
Nano Server estará disponível somente como uma imagem de sistema
operacional para containers. Ele poderá ser executado como um container em
um host de containers do Server Core, ou em computação em nuvem.
Nessa nova versão 1709, executar um container com base no Nano Server
será diferente das versões anteriores. Veja quais são essas diferenças:
O novo Nano Server foi otimizado para aplicativos .NET Core
O .NET core é ainda menor do que a versão do Windows Server 2016
O Powershell Core e WMI não são mais incluídos por padrão.
Não há mais a pasta NanoServer na imagem ISO padrão. A Microsoft
publica o container atualizado no Docker Hub, e você poderá baixá-lo
diretamente, com o comando docker push.
Para solução de problemas e desenvolvimento de aplicações no Nano, são
utilizados o Docker Engine, o Docker Files e o Docker Compose.
 
Migração e Atualização
Na grande maioria dos casos, as organizações que estão implantando o
Windows Server 2016 implantarão, também, o sistema operacional em um
ambiente Windows Server existente. Embora provas de conceito envolvam
um pequeno número de servidores, em algum momento as organizações vão
querer atualizar ou migrar seus servidores Windows existentes, e as cargas de
trabalho hospedadas nesses servidores, para o Windows Server 2016.Enquanto algumas organizações implementam um novo sistema operacional
servidor ou atualiza os servidores existentes o mais rápido possível, outras
esperam até que seus servidores atuais cheguem ao fim do suporte avançado,
antes de planejar qualquer movimento. Porém, a maioria adota uma
abordagem intermediária.
Uma regra geral sobre os caminhos da atualização e da migração suportadas é
a importância de garantir que o produto a ser atualizado ainda esteja dentro
da janela de suporte estendido da Microsoft, e que já tenham sido aplicados
todos os pacotes e atualizações de software lançados para a carga de trabalho,
antes da tentativa de migração ou atualização. A diferença entre migrar e
atualizar é a seguinte:
Migração
Mais comum do que uma atualização, uma migração envolve mover serviços
e dados de um servidor existente, executando uma versão suportada do
Windows Server, para um servidor recém-implantado, executando o
Windows Server 2016. A migração é a opção preferida da Microsoft e se
encaixa melhor na filosofia da administração de sistemas baseados nos
métodos ágeis, segundo a qual “servidores precisam ser tratados como gado e
não como animais de estimação”. Essa filosofia dita que a instalação e a
configuração sejam tão automatizadas quanto possível. Assim, ao invés de
elaborar cuidadosamente a configuração de um servidor individual, os
administradores podem aplicar configurações complexas rapidamente, para
que a atualização ou substituição do servidor seja considerada uma operação
de rotina simples, e não uma ação que requer atenção minuciosa para
processos arcaicos e não inteiramente compreendidos.
Atualização
Às vezes chamada de upgrade in-place, a atualização geralmente envolve a
execução da rotina de instalação do Windows Server 2016, a partir de uma
instalação existente do Windows Server 2012 ou do Windows Server 2012
R2. Não se pode realizar uma atualização direta para o Windows Server 2016
a partir do Windows Server 2008 ou 2008 R2. Executam-se atualizações
quando se faz necessário o novo sistema operacional para usar o mesmo
hardware que o sistema operacional de origem, e deseja-se manter as funções
e os dados originais. As atualizações só são suportadas para algumas funções,
e são mais adotadas em organizações menores, onde o pequeno número de
servidores implica que o tempo necessário para criar ferramentas e processos
de implantação e configuração automatizados excede àquele necessário para
implantar a infraestrutura manualmente. A tabela abaixo ilustra os caminhos
possíveis de atualizações in-place.
Edição de origem Edição de destino
Windows Server 2012
Standard
Windows Server 2016 Standard
ou Datacenter
Windows Server 2012
Datacenter
Windows Server 2016
Datacenter
Windows Server 2012 R2
Standard
Windows Server 2016 Standard
e Datacenter
Windows Server 2012 R2
Datacenter
Windows Server 2016
Datacenter
Windows Server 2012 R2
Essentials
Windows Server 2016
Essentials
 
Nesta tabela mais completa listo quais funções ( Role) podem ser atualizadas
diretamente, e quais podem ser migradas, além daqueles que foram
descontinuadas.
Função A partir de WS2012
ou WS2012 R2
Migração envolve
alguma parada?
ADCS Sim Sim
ADDS Sim Não
ADFS Não Sim
ADLDS Sim Não
AD RMS Sim Sim
DHCP Sim Não
DNS Sim Não
Clusters Cluster rolling upgrade
é suportado no WS
2012 R2, mas não no
2012
Não para WS 2012 R2,
mas sim para WS 2012
File e
Storage
Sim Não
Hyper-V Quando o WS 2012 R2
é membro de um
Failover Cluster
Não para servidores WS
2012 R2 que são
membros de um clusters
de SOFS
Print
Services
Não Sim
Web
Server
Sim Sim
WSUS Sim Sim
Work
Folders
Sim Não
 
O upgrade in-place ainda tem outras restrições adicionais:
As atualizações de um idioma para outro não são suportadas. Não é
possível atualizar uma edição em português para uma versão em inglês e
vice-versa.
Não se pode atualizar as versões Technical Preview para uma versão
RTM do Windows Server 2016
Não há como atualizar uma instalação Server Core para uma versão Full.
Se o sistema operacional de origem estiver executando o Windows Server
2012 ou 2012 R2, pode-se contornar isso mudando do Serve Core para
Full antes de executar a atualização.
Não é possível atualizar uma instalação Full para uma instalação Server
Core. Se o sistema operacional de origem estiver executando o Windows
Server 2012 ou 2012 R2, pode-se resolver isto convertendo, primeiro, o
sistema operacional para Core antes de executar a atualização.
Não há como atualizar uma versão comercial licenciada de um sistema
operacional Windows Server para uma edição de avaliação. A Microsoft
recomenda que apenas se instalem as edições de avalição como
instalações limpas.
 
Nota
É possível atualizar uma versão Standard para Datacenter, do
Windows Server 2016, sem reinstalar o servidor. Use o
comando DISM. Também, precisará de uma chave de produto
disponível da versão Datacenter para:
 
Ver a versão atual:
Dism /online /Get-CurrentEdition
 
Atualizar para a versão Datacenter:
Dism /online /Set-Edition:ServerDatacenter /ProductKey:
XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula
 
O pacote Microsoft-Windows-ServerStandardEdition será
removido. Pressione Y (Yes) para confirmar. Após o reboot, o
servidor iniciará com as funcionalidades da versão Datacenter.
 
Ativação Automática de Máquina Virtual
A ativação automática de máquina virtual (Automatic Virtual Machine
Activation) atua como um mecanismo de prova de compra, ajudando a
garantir que os produtos do Windows Server sejam usados de acordo com os
direitos de uso do produto e os termos de licença do software Microsoft.
O AVMA permite que se instale máquinas virtuais em um servidor Windows
Server Datacenter ativado, corretamente, sem ter que gerenciar as chaves do
produto individualmente, para cada máquina virtual, mesmo em ambientes
desconectados (sem acesso à Internet ou KMS). O AVMA liga a ativação da
máquina virtual ao servidor de virtualização Hyper-V licenciado, e ativa a
máquina virtual, quando ela é iniciada. Ele também oferece relatórios, em
tempo real, sobre o uso e sobre os dados históricos da licença da máquina
virtual. Os dados de relatório e rastreamento estão disponíveis no servidor de
virtualização.
O AVMA na prática
O AVMA oferece diversos benefícios para os servidores físicos de
virtualização ativados com o licenciamento por volume. Entre esses
benefícios, estão:
Ativar máquinas virtuais em locais remotos, tais como regionais e filiais;
Ativar máquinas virtuais, com ou sem acesso à Internet ou servidor de
KMS;
Rastrear o uso da máquina virtual, e as licenças do servidor de
virtualização, sem exigir direitos de acesso nos sistemas virtualizados;
Não há chaves de produto para gerenciar, nem adesivos nos servidores
para ler. A máquina virtual é ativada e continua a funcionar, mesmo
quando é migrada em uma série de servidores de virtualização (Live
Migration);
Os parceiros do Acordo de Licença do Provedor de Serviços (SPLA), e
outros provedores de hospedagem, não precisam compartilhar chaves de
produtos com seus inquilinos (tenant) para ativá-los;
Quando o AVMA é usado, a ativação da máquina virtual é transparente
para o inquilino;
Os provedores de hospedagem podem usar os logs do servidor para
verificar a conformidade da licença, e para rastrear o histórico de uso do
cliente;
O AVMA requer um servidor físico com a versão do Windows Server 2016
Datacenter ativada, e com a função de Hyper-V habilitada. Um host AVMA
do Windows Server 2016 é capaz de ativar os Guest Windows Server 2016 e
2012 R2 Standard, Datacenter e Essentials.
Uma vez que o servidor físico esteja licenciado, com uma Datacenter Product
Key emitida pela Microsoft, (através de uma chave baseada em volume, ou
VOLUME LICENSING), todo o Guest neste host deverá utilizar uma única
Product Key. Ou seja,para a criação da sua imagem (sysprep), devem-se
utilizar as seguintes chaves de ativação:
Chaves AVMA para Guest Windows Server 2012 R2
Edição Chave AVMA
Datacenter Y4TGP-NPTV9-HTC2H-7MGQ3-
DV4TW
Standard DBGBW-NPF86-BJVTX-K3WKJ-
MTB6V
Essentials K2XGM-NMBT3-2R6Q8-WF2FK-
P36R2
 
Chaves AVMA para Guest Windows Server 2016
Edição Chave AVMA
Datacenter TMJ3Y-NTRTM-FJYXT-T22BY-
CWG3J
Standard C3RCX-M6NRP-6CXC9-TW2F2-
4RHYD
Essentials B4YNW-62DX9-W8V6M-8649-
MHBKQ
 
Ativação Baseada no Active Directory
A ativação baseada no Active Directory é implementada como um serviço
que usa o ADDS para armazenar objetos de ativação. A ativação baseada no
AD exige que o esquema da floresta seja atualizado pelo ADPrep, e precisa
estar no nível funcional do dominio e da floresta, pelo menos, no Windows
Server 2012 R2.
Para permitir que computadores com GVLK (Chave de Licença de Volume
Genérico) se ativem, use o console de ferramentas de ativação por volume,
no Windows Server 2016, para criar um objeto na floresta do ADDS. Você
pode criar esse objeto de ativação enviando uma chave de host KMS para a
Microsoft.
Instale a função Volume Activation Services em um controlador de domínio
que esteja executando o Windows Server 2012 R2 ou 2016, e adicione uma
chave de host KMS usando o assistente. A Microsoft verifica a chave de host
KMS, e um objeto de ativação é criado. Durante a inicialização, os
computadores clientes são ativados pelo objeto de ativação de um controlador
de domínio.
FIGURA 01-07. Volume Activation Tools
Para ambientes em que todos os computadores estejam executando o
Windows 10, o Windows 8.1, o Windows 8, o Windows Server 2012 ou o
Windows Server 2012 R2 e 2016, e fizerem parte de um domínio, a ativação
baseada no Active Directory será a melhor opção para todos os computadores
cliente-servidor. E qualquer host KMS poderá ser removido do seu ambiente.
Se o ambiente continua a conter sistemas operacionais anteriores, e
aplicativos de licenciamento de volume, ou se houver computadores de grupo
de trabalho fora do domínio, será preciso um host KMS para manter o status
de ativação de edições com licenciamento de volume anteriores do Windows
e do Office. Cada vez mais, as empresas adotam o Office 365 como uma
assinatura que usa outro método de ativação.
Os clientes ativados pelo Active Directory manterão seu estado ativado por
até 180 dias, desde o último contato com o domínio, mas eles tentarão se
reativar, periodicamente, durante o período de 180 dias. Por padrão, esse
evento de reativação ocorre a cada sete dias. Quando ocorre um evento de
reativação, o cliente consulta o AD DS para obter o objeto de ativação.
Os computadores cliente examinam o objeto de ativação e o comparam com a
edição local, conforme definido pela GVLK. Se o objeto e a GVLK
corresponderem, ocorrerá a reativação. Se o objeto do ADDS não for
recuperado, os computadores cliente usarão a ativação via KMS. Caso o
computador seja removido do domínio, quando o computador ou o serviço de
Proteção de Software for reiniciado, o sistema operacional mudará o status de
ativado para não ativado, e o computador tentará ativar via KMS.
Preparação do Sistema (Sysprep)
A ferramenta preparação do sistema (system preparation) ordena uma
instalação do Windows Server para duplicação / clonagem. A duplicação,
também chamada de geração de imagens, permite capturar uma imagem
personalizada do Windows, que poderá ser reutilizada em toda uma empresa.
O modo de auditoria permite adicionar aplicativos, ou drivers de dispositivos,
a uma instalação do Windows. O sysprep também permite preparar uma
imagem para ser enviada a um cliente ou para a nuvem. Quando o sistema
operacional é iniciado pela primeira vez, visualiza-se a mensagem de boas-
vindas do Windows Server
Para transferir uma imagem do Windows Server para um computador
diferente, ou para a criação de uma nova máquina virtual, deve-se executar o
comando sysprep /generalize, mesmo que o computador apresente a mesma
configuração de hardware. O comando sysprep /generalize remove as
informações exclusivas da sua instalação do Windows Server. O sysprep só
deverá ser usado para configurar novas instalações do Windows. Execute,
quantas vezes forem necessárias, para criar e configurar a instalação do
Windows. Porém, só será possível redefinir a ativação do Windows até três
vezes.
Crie uma máquina virtual com o Windows Server 2016, a partir de um
arquivo ISO, faça todas as atualizações e instale todos os softwares que
precisam ser disponibilizados nas novas imagens.Em seguida, execute o
comando sysprep.exe /oobe /generalize /shutdown /mode:vm. A opção
/generalize orienta o sysprep a remover, da instalação do Windows, dados
específicos do sistema. Informações específicas do sistema incluem logs de
eventos, identificadores de segurança exclusivos (SID) e outras informações.
Uma vez removidas as informações do sistema, o computador é desligado. A
opção /oobe orienta a instalação do Windows a executar as boas-vindas na
próxima inicialização do sistema.
Todos estes parâmetros podem não ser novos, para administradores de
Windows mais experientes, mas há um, em especial, que pode ser. Observe o
parâmetro /mode:vm. A partir do Windows Server 2012, este novo
parâmetro foi incluído. Ele tem como a finalidade acelerar o deployment de
maáquinas virtuais, que serão criadas no mesmo ambiente de virtualização da
máquina que foi preparada. Como o hardware virtual será o mesmo, este
parâmetro notifica o sysprep para ignorar o processo de Plug and Play, em
busca de novas camadas de abstração de hardware. Esse procedimento
acelera o tempo de provisionamento de máquinas virtuais.
FIGURA 01-08. Boot com imagem preparada pelo sysprep
Este parâmetro é suportado somente para máquinas virtuais que serão
executadas no mesmo ambiente de virtualização VMWare ou Hyper-V, por
exemplo. Não execute este parâmetro para preparação de imagem para
instalação em servidores físicos.
Nota
Use o parâmetro /mode:vm somente para preparar uma imagem
para o próprio hypervisor. Uma imagem preparada no VMWare
poderá ser instalada somente no VMWare, e não no Hyper-V.
Isso vale para o Hyper-V, em relação ao VMWare.
 
Ferramenta de Planejamento e Adoção
O MAP (Microsoft Assessement and Planning Toolkit) é uma ferramenta de
planejamento e avalição de ambientes Microsoft, sem a necessidade de
instalação de agentes nos computadores desktops e servidores. Com ele, é
possível realizar um inventário do ambiente, criar relatórios detalhados de
avaliação, e propostas executivas com informações extensas de hardware e
software. Ainda, faz recomendações adicionais para auxiliar as organizações
a acelerar seu processo de planejamento de infraestrutura de TI e reunir mais
detalhes sobre os ativos que residem no seu ambiente atual. O MAP, também,
fornece dados de utilização de servidores físicos, que podem ser ótimos
candidatos à virtualização com o Hyper-V. O MAP Tool Kit é uma
ferramenta gratuita, que pode ser baixada em
www.microsoft.com/downloads.
FIGURA 01-09. Microsoft Assessment and Planning Toolkit
Gerenciamento de Imagens
Toda mídia de instalação do Windows Server 2016 fornece um arquivo
chamado Install.wim, através do qual você poderá criar suas próprias
imagens, incluindo hotfixes, drivers e funções embarcados, além de remover
algumas opções de instalação, como a versão Standard, por exemplo.
Para listar as opções de instalação do Windows Server, execute:
Get-WindowsImage -ImagePath C:\Install.wim
 
Você obterá uma lista de opções de instalação, incluindo o index de cada
imagem embarcada neste arquivo. Para remover a imagem com index 1
execute:
Remove-WindowsImage -ImagePath C:\Install.wim -Index 1
 
Caso deseje aplicar um hotfix, primeiro baixe as atualizações em uma pasta,
como a C:\hotfixes, por exemplo. Em seguida, monte aimagem em outra
pasta, chamada C:\Mount, por exemplo:
Mount-WindowsImage -Image-Path C:\Install.wim -Index 1 -
Path C:\Mount
 
Agora, adicione os hotfixes com o comando Add-WindowsPackage.
Add-WindowsPackage -Path C:\hotfixes C:\Mount
 
Para adicionar drivers adicionais, use o comando Add-WindowsDriver
Add-WindowsDriver -Path C:\Mount -Driver C:\Drivers -
Recurse
 
Para adicionar uma função, você usará o comando Enable-
WindowsOptionalFeature. Para adicionar a função de Hyper-V, por
exemplo, execute:
Enable-WindowsOptionalFeature -Path C:\Mount -
FeatureName Microsoft-hyper-V -all
 
Finalmente, desmonte o arquivo e salve-o.
Dismount-WindowsImage -Path C:\Mount -Save
 
Estado Desejado de Configuração (DSC)
O estado desejado de configuração (Desired State Configuration) existe para
diminuir a complexidade da criação de scripts no Windows e aumentar a
velocidade de interação.
O conceito de "implantação contínua" está se tornando mais e mais
importante. Implantação contínua significa a capacidade de implantar com
frequência, possivelmente, várias vezes ao dia. A finalidade dessas
implantações não está em corrigir algo, mas sim em publicar conteúdo
rapidamente. Ao lançar novos recursos do desenvolvimento para as
operações, da forma mais tranquila e confiável possível, você aumentará o
rendimento da nova lógica de negócios.
A mudança para computação na nuvem implica uma solução de implantação
que utiliza um modelo "declarativo", no qual um ambiente de estado final é
declarado como texto, e publicado em um mecanismo de implantação. Essa
técnica de implantação permite uma alteração rápida, em grande escala, com
resiliência contra ameaças de falha, pois, a qualquer momento, a implantação
pode ser repetida, consistentemente, a fim de garantir um estado final. A
criação de ferramentas e serviços que oferecem suporte a esse estilo de
operações, por meio da automação, é uma resposta a essas alterações.
DSC é uma plataforma que fornece implantação, configuração e
conformidade declarativas e idempotente (repetível). Na plataforma DSC,
garante-se que os componentes do datacenter tenham a configuração correta,
evitando erros e falhas de implantação dispendiosas. A DSC permite a
implantação contínua, tratando as configurações DSC como parte do código
do aplicativo, o que garante que o conhecimento necessário para implantar
esteja sempre atualizado e pronto para uso.
O exemplo que usarei, a seguir, assegura que o recurso Web-Server (IIS) do
servidor esteja habilitado, e que o conteúdo para um site "Hello World"
simples esteja presente no diretório do inetpub\wwwroot desse servidor.
Primeiro, vamos criar o arquivo HTML, que usaremos como o conteúdo do
site. Na pasta-raiz, crie uma pasta chamada C:\Test. Em um editor de texto,
digite o texto a seguir:
<head></head>
<body>
<title>DSC Demo</title>
<h1>
<p>Hello World!</p>
</body>
Salve-o como index.htm na pasta C:\Test, que você criou anteriormente.
No PowerShell ISE, digite o seguinte:
Configuration WebSiteTest {
 
 # Import Module
 Import-DscResource -ModuleName
PsDesiredStateConfiguration
 
 # Specify server hostname
 Node 'localhost' {
 
 # Specify feature name
 WindowsFeature WebServer {
 Ensure = "Present"
 Name = "Web-Server"
 }
 
 # Copy content to inetpub\wwwroot
 File WebsiteContent {
 Ensure = 'Present'
 SourcePath = 'c:\test\index.htm'
 DestinationPath = 'c:\inetpub\wwwroot'
 }
 }
}
WebSiteTest
Salve este arquivo como WebSiteTest.ps1
Você verá que ele parece uma função do PowerShell, com a adição da
palavra-chave Configuration, usada antes do nome da função.
O bloco node especifica o node de destino a ser configurado, neste caso,
localhost.
A configuração chama dois recursos, Windows Feature e File. Os recursos
fazem o trabalho de garantir que o node de destino esteja no estado definido
pela configuração.
Para que uma configuração DSC seja aplicada a um node, ela deve, primeiro,
ser compilada em um arquivo .MOF. Para isso, deve-se executar a
configuração como uma função. Em um console do PowerShell, navegue até
a pasta em que sua configuração foi salva e execute os comandos a seguir
para compilar a configuração em um arquivo .MOF:
.\WebSiteTest.ps1
A primeira linha torna a função de configuração disponível no console. A
segunda linha executa a configuração. O resultado é que uma nova pasta,
chamada WebSiteTest, é criada como um subpasta da pasta atual. A pasta
WebSiteTest contém um arquivo chamado localhost.mof. Este é o arquivo
que poderá ser aplicado ao node de destino.
Agora que o MOF foi compilado, é possível aplicar a configuração ao node
de destino (neste exemplo, o computador local) chamando o cmdlet Start-
DscConfiguration.
O cmdlet Start-DSCConfiguration indica, ao gerenciador de configuração
local (LCM), qual é o mecanismo de DSC a aplicar a configuração. O LCM
realiza o trabalho de chamar os recursos de DSC para aplicar a configuração.
Em um console do PowerShell, navegue até a pasta em que sua configuração
foi salva e execute:
Start-DscConfiguration -Path .\WebSiteTest -Verbose
Pode-se chamar o cmdlet Get-DscConfigurationStatus para ver se a
configuração foi bem-sucedida.
Também, pode-se testar os resultados diretamente, neste caso, pesquisando o
site http://localhost em um navegador web. A página HTML “Hello World”,
que acabou de ser criada, é a primeira etapa deste exemplo.
 
Simulado
Questão 01
Você está configurando uma instância do Windows Server 2016 instalada
com a opção de instalação core. Agora, deseja usar um menu baseado em
texto no console do servidor para completar a configuração pós-instalação.
Qual comando iniciará este menu?
A. Dism
B. Sconfig
C. Configure-server
D. Server Manager
E. Sysconfig
Questão 02
Você recebeu uma solicitação para reconfigurar a rede de uma instância do
Windows Server 2016 Core para habilitar o cliente DHCP. Qual cmdlet do
Powershell realizará esta tarefa?
A. Set-NetAdapter
B. Set-NetIPInterface
C. Set-NetIPConfiguration
D. New-NetIPAddress
Questão 03
Você precisa configurar uma instância do Windows Server 2016 Core para
permitir que o tráfego de compartilhamento de arquivos e impressoras passe
pelo firewall do Windows. Qual dos seguintes comandos irá realizar esta
tarefa?
A. New-NetFirewallRule -DisplayName “File and Print Sharing”
B. Enable-NetFirewallRule -DisplayGroup “File and Print Sharing”
C. Enable-NetFirewallRule -DisplayName “File and Print Sharing”
D. New-NetFirewallRule -DisplayGroup “File and Print Sharing”
Questão 04
Qual das seguintes configurações de rede não pode ser feita pela console de
recuperação (Recovery Console) do Nano Server?
A. DNS Server
B. IP Address
C. Subnet mask
D. Default gateway address
Questão 05
Você acaba de instalar uma nova instância do Nano Server. Depois de
configurar a rede, você se conecta remotamente à máquina através do
comando Enter-PSSession. Qual comando você deverá executar para instalar
a função de Hyper-V neste servidor?
A. Install-WindowsFeature
B. Install-WindowsOptionalFeature
C. Enable-WindowsOptionalFeature
D. Install-NanoServerPackage
Questão 06
Você iniciou um servidor físico, usando uma unidade USB, com o Windows
PE, mas não tem acesso aos comandos do PowerShell. Qual comando você
poderá usar para instalar uma imagem do Nano Server neste servidor físico?
A. Netsh
B. Dism
C. Diskpart
D. Bcdboot
Questão 07
Qual dos seguintes arquivos de media ISO, do Windows Server 2016, são
usados para criar uma instância do sistema operacional?
A. Install.vhd
B. Boot.vhdx
C. Install.vhdx
D. Install.wim
E. Boot.wim
Questão 08
Você foi solicitado a criar uma imagem do Nano Server, que será instalada
diretamente em um servidorfísico, e escreve o script com o seguinte
comando:
New-NanoServerImage -Edition Standard -DeploymentType Guest -
MediaPath C:\ -BasePath C:\NanoServer\NanoServer1 -TargetPath
C:\NanoServer\NanoServer1\NanoServer1.wim -ComputerName
NanoServer1
Por que este comando não produz o resultado esperado?
A. O valor do parâmetro -Edition deveria ser NanoServer
B. O valor do parâmetro -TargetPath deveria ser um arquivo VHDX
C. O valor do parâmetro -MediaPath deveria ser C:\NanoServer
D. O valor do parâmetro -DeploymentType deveria ser Host
Questão 09
Você está criando uma imagem do Nano Server, usando o cmdlet New-
NanoServerImage, e precisa da imagem que está criando para incluir os
pacotes necessários para o Hyper-V. Qual dos seguintes parâmetros
adicionais deverá ser adicionado ao comando para realizar esta tarefa?
A. -Hyper-V
B. -Package
C. -Compute
D. -Storage
Questão 10
Qual das seguintes features não está disponível na versão Standard do
Windows Server 2016?
A. Hyper-V Containers
B. Host Guardian Service
C. Storage Space Direct
D. Nano Server
Questão 11
Quais os valores mínimos de memória para instalação do Server Core e
Server Full (Desktop Experience) correspondente?
A. 512MB e 4GB
B. 512MB e 1GB
C. 1GB e 2GB
D. 512MB e 2GB
Questão 12
Qual serviço não é suportado no Nano Server?
A. Scale Out File Server
B. Hyper-V
C. IIS
D. ADDS
Questão 13
Você deseja instalar o DNS em uma instância do Nano Server. Qual das
seguintes declarações identifica, corretamente, uma limitação a esta
configuração para a qual você deve estar preparado?
A. DNS em um Nano Server não suporta zonas integradas ao Active
Directory
B. DNS em um Nano Server não suporta a criação de registros do tipo SRV
C. DNS em um Nano Server não suporta reverse lookup zones (zonas
reversas)
D. DNS em um Nano Server não suporta transferência de zona.
Questão 14
Você foi escalado para criar uma imagem do NanoServer, como uma
máquina virtual geração 2, no Hyper-V. Por que o comando não produz o
resultado esperado?
New-NanoServerImage -Edition Standard -DeploymentType
Guest -MediaPath C:\ -BasePath C:\nanoServer\NanoServer1 -
TargetPath C:\NanoServer\NanoServer\NanoServer.vhd -
ComputerName NanoServer1
A. O valor do parâmetro -DeploymentType deveria ser host
B. O valor do parâmetro -MediaPath deveria ser C:\NanoServer
C. O valor do parâmetro -Edition deveria ser Datacenter
D. O valor do parâmetro -TargetPath deveria ser um arquivo com a extensão
VHDX
Questão 15
Você criou um script Powershell que aplica uma configuração DSC em uma
instância do Windows Server 2016. Esse script inclui a seguinte sequência e
código.
WindowsFeature ADDSInstall {
 Ensure = “Present”
 Name = “AD-Domain-Service”
 DependsOn = “[xComputer]NewComputerName”
O que acontecerá se o script contendo este código for executado contra uma
máquina que já tenha o Active Directory instalado?
A. Nada
B. O Active Directory será desinstalado
C. Este script será encerrado com um erro
D. O Active Directory será reinstalado
Questão 16
Você possui uma mídia de instalação personalizada para uma implantação do
Windows Server 2016. Essa mídia inclui várias opções de instalação dentro
de um único arquivo .WIM e você deseja eliminar algumas opções
desnecessárias desse arquivo. Qual comando irá realizar esta tarefa?
A. Remove-WindowsInstall
B. Remove-WindowsWIM
C. Remove-InstallImage
D. Remove-WindowsImage
Questão 17
Você baixou várias atualizações do Windows Update pelo site
http://catalog.update.microsoft.com. Elas estão, atualmente, na pasta
C:\Updates do seu computador local. Agora, deseja adicioná-las a um arquivo
WIM personalizado para o Windows Server 2016, com a opção de instalação
core. Esse arquivo .WIM está atualmente montado localmente na pasta
C:\Offline. Qual comando irá realizar esta tarefa?
A. Add-WindowsUpdate -Path C:\Updates -PackagePath C:\Offline
B. Add-WindowsPackage -Path C:\Offline -PackagePath C:\Updates
C. Add-WindowsUpdate -Path C:\Offline -PackagePath C:\Updates
D. Add-WindowsPackage -Path C:\Updates -PackagePath C:\Offline
Questão 18
Você está personalizando um arquivo .WIM para ser usado na instalação, via
Server Core, do Windows Server 2016, e quer garantir que a função de
Hyper-V esteja instalada em qualquer máquina, durante a instalação do
sistema operacional. Qual cmdlet você deverá usar para realizar esta tarefa?
A. Install-WindowsFeature
B. Install-WindowsOptionalFeature
C. Install-NanoServerPackage
D. Enable-WindowsOptionalFeature
Questão 19
Qual dos seguintes modelos de ativação de licença exige que os sistemas
operacionais estejam no Windows Server 2012 RTM, ou superior?
A. Key Management Service
B. Automatic VM Activation
C. Ativação por telefone
D. Active Directory-based Activation
Questão 20
Uma GPO ________________ ser usada para gerenciar um Nano Server, e o
PowerShell DSC __________________ ser usado para gerenciar as
configurações do Nano Server.
A. Não pode e não pode
B. Não pode e pode
C. Pode e não pode
D. Pode e pode
Questão 21
Você foi encarregado de inserir uma nova chave de licença de varejo (Retail)
em uma instância do Server Core. Qual comando irá realizar esta tarefa?
A. New-License
B. Slmgr -ato
C. Slmgr -ipk
D. New-LicenseKey
Questão 22
Quais, dentre as seguintes opções de instalação do Windows Server 2016,
não poderão ser selecionadas para instalar o sistema operacional usando uma
midia ISO?
A. Nano Server
B. Server Core Datacenter Edition
C. Standard Edition Desktop Experience
D. Server Core Standard Edition
Questão 23
Quais das seguintes instalações devem ser gerenciadas pelo modelo Semi-
Annual Channel (SAC)?
A. Server Core Build 1709
B. Server com Desktop Experience
C. Nano Server Build 1709 rodando como um container
D. Server Core Essentials
Questão 24
Quantos Hyper-V Containers são permitidos para cada licença do Windows
Server 2016 Standard Edition?
A. Ilimitada
B. Quatro
C. Uma
D. Duas
 
Respostas
01-B 02-B 03-B 04-
A
05-
D
06-B 07-
D
08-
D
09-
C
10-
C
11-
D
12-
D
13-
A
14-
D
15-
A
16-
D
17-B 18-
D
19-
D
20-B
21-
C
22-
A
23-
C
24-
D
 
 
 
CAPÍTULO 02 – Implantar
Soluções de Armazenamento
O armazenamento no Windows Server 2016 oferece recursos novos e
aprimorados para clientes SDDC (Datacenter Definido por Software) que
privilegiam cargas de trabalho virtualizada. O Windows Server também
fornece suporte extensivo para clientes corporativos, usando servidores de
arquivo com cargas de trabalho exigentes.
Faremos, agora, uma revisão das principais tecnologias de armazenamento de
dados existentes, e exploraremos as novas funcionalidades do Windows
Server 2016.
Tipos de Discos
Atualmente, fala-se muito em discos virtuais mas eles não existiriam sem o
tradicional disco físico. Os discos virtuais precisam “dormir” em algum lugar
e são nestes discos físicos que eles são armazenados. Nos últimos anos, os
discos físicos sofreram grandes mutações, não só na sua capacidade, como
também no seu desempenho.
Basicamente, podemos dividir os discos físicos em quatro tipos:
SATA Disk. Discos com leitura mecânica e desempenho de 100 IOPS
por disco
SCSI Disk. Discos com leitura mecânica e desempenho de 150 IOPS por
disco
SAS Disk. Discos com leitura mecânica e desempenho de 200 IOPS por
disco
SSD Disk. Discos sólidos com desempenho de até 1.000 IOPS por disco
e sem partes móveis para armazenamento não volátil de dados digitais
(Solid State Drive)
A unidade IOPS, que significa Input Output por Segundo, é a unidade
universal para medir o desempenho de leitura e gravação, e largamente
utilizada em soluções de nuvem privada e pública. 01 IOPS equivale a 08
KBytes de leitura e gravação.
Tabela de Partições
Seus discosfísicos e virtuais precisam ser inicializados e formatados. Essa
tarefa envolve a escolha entre duas opções de partição MBR e GPT. A tabela
abaixo ilustra a diferença entre elas, e te ajudará a tomar a melhor decisão.
Master Boot Record (MBR) GUID Partition Table (GPT)
Partição existente desde os
anos 1980
Sucessor do MBR
Suporta partições de, no
máximo, 2 TB (Terabyte)
Suporta partições de até 18 EB
(Hexabyte)
Permite a criação de até 04
partições primárias por disco
Permite a criação de até 128
partições por disco
 
FIGURA 02-01. Inicialização do disco
Sistemas de Arquivo
Além das partições, você deverá escolher qual o melhor sistema de arquivos
para o Windows Server 2016.
FAT O File Allocation Table, ou Tabela de Alocação de Arquivos, é um
sistema de arquivos antigo, surgido em meados de 1997, mesma época do
surgimento do MS-DOS e, posteriormente, do Windows 95. O FAT
ganhou uma atualização, conhecida como FAT32, e tornou- se o sistema
de arquivos padrão do Windows 95 e 98. Ele trabalha com partições
pequenas de, no máximo, 2 GB, e utiliza 32 bits no endereçamento de
dados. Raramente se usará um sistema FAT em discos de dados para
servidores.
 
ExFAT É o que chamamos de FAT de 64 bits, muito mais veloz que o
FAT32 e ideal para pen-drives ou, até mesmo, HDs com capacidade e
desempenho superiores, além de contar com menos fragmentação. O
ExFAT foi desenvolvido para atender usuários que manipulam arquivos
únicos com mais de 4GB de tamanho.
 
NTFS O New Technology File System foi lançado, junto ao Windows
NT, como sistema operacional para servidores. Trata-se de um sistema de
arquivos robustos que suporta metadados, criptografia, controle de acesso
(ACL), replicação de dados e backup (journaling). Esse tipo de
formatação cria clusters de 4KB em partições que vão de 2GB até 18
Hexabyte.
 
ReFS O Resiliency File System é o mais novo sistema de arquivos da
Microsoft. Ele foi projetado para maximizar a disponibilidade,
dimensionar de forma eficiente grandes conjuntos de dados em diversas
cargas de trabalho e fornecer integridade, por meio da resiliência à
corrupção de dados, além de possuir todas as características e
compatibilidades do NTFS. Falaremos mais sobre este sistema de arquivo
e sobre a importância de adotá-lo em seus projetos de S2D, Hyper-V e
SOFS.
 
 
Nota
Nem todos os serviços suportam ReFS, ainda, então veja aqui
quais sistemas de arquivos devem ser adotados, dependendo do
seu workload:
Para Active Directory Domain Services, File Replication
Service, Volume Shadow Copy Service e Distributed File
System, o NTFS deve ser adotado. Já para os serviços como
Hyper-V, Scale Out File Services e Storage Space Direct, o
ReFS é a melhor opção.
 
FIGURA 02-02. Formatação do disco e escolha do sistema de arquivos
Redundância de Discos (RAID)
Os sistemas de RAID (Redudant Array of Independent Disks) podem ser
implementados por uma controladora de hardware ou de software.
RAID 0 Também conhecido como Disk Striping, os dados são
distribuídos em todos os discos. É a melhor opção para desempenho, mas
não tem tolerância a falha. Se um disco do RAID0 falhar, você perderá
todos os dados. Com dois discos de 8 TB pode-se ter um volume de até 16
TB (o dobro).
 
RAID 1 Também conhecido como Disk Mirroring, ou espelhamento, os
dados são duplicados (uma cópia exata). É bom para redundância, mas
requer o dobro do número de discos, e tem bom desempenho de leitura. Se
você tem dois discos de 8TB, como um disco recebe a cópia você terá, no
máximo, um volume de 8TB.
 
RAID 5 Também conhecido como Disk Striping com paridade, tem alto
desempenho e redundância e exige, no mínimo, 3 discos. Com três discos
de 8 TB, pode-se ter, no máximo, um volume de 16 TB. Há uma
tolerância para perda de qualquer um dos três discos, e os dados
continuarão disponíveis.
Existem, também, outros sistemas de arquivos mais complexos. Por exemplo,
o RAID 6, que exige, no mínimo, 4 discos, e o RAID 10, que é a combinação
de RAID 1 + 0. Em resumo, os principais volumes são: simples, estendido,
distribuído, espelhado e RAID5. É bom lembrar: para adotar um sistema de
RAID no Windows Server 2016 seus discos precisam ser convertidos para
dinâmicos, caso você os gerencie pelo Disk management, algo desnecessário
quando o gerenciamento é feito pelo Storage Space ou Storage Space Direct.
Lembre-se disso no seu exame.
FIGURA 02-03. RAID 1 (espelhamento) com dois dicos de 1 GB cada um
Sistemas de Armazenamento
Direct Attached Storage (DAS)
Tipicamente, DAS é um sistema de armazenamento conectado diretamente a
um computador, e os principais protocolos usados pelo DAS são ATA,
SATA, ESATA, SCSI e SAS. Observe que não há nenhum dispositivo de
rede envolvido, como um Switch Ethernet ou SAN. Todos estes discos
podem fornecer tolerância a falhas, como por exemplo o uso de RAID.
Os dispositivos DAS eram conhecidos como “ilhas da informação” devido a
sua incapacidade de compartilhar dados ou espaços não utilizados com outros
equipamentos de rede. Mas isso acabou com o Storage Space Direct.
Network Attached Storage (NAS)
NAS é um dispositivo de armazenamento conectado a uma rede ethernet, que
possibilita o armazenamento e recuperação de dados em um local
centralizado para usuários e servidores na rede. Estes dispositivos são
flexíveis e de expansão horizontal, ou seja, à medida que se necessita mais
espaço, este pode ser adicionado.
Os dispositivos NAS são mais adequados para pequenas empresas, pois são
simples de operar e dispensam a presença de um profissional de TI
especializado para mantê-lo.
Os protocolos usados pelos dispositivos NAS são o NFS (Network File
System), popular sistema de arquivos do Linux/Unix, e o SMB (Server
Message Block), sistema de arquivos do Windows. Alguns deles podem ter o
sistema de redundância, como o RAID, por exemplo.
Storage Area Network (SAN)
Storage Area Network é uma rede baseada em Fibre Channel (Fibra Óptica),
que armazena dados e conecta servidores e dispositivos de armazenamento.
Os dispositivos de armazenamento não são conectados aos servidores, mas à
própria rede, sendo visíveis a todos os servidores da rede.
Entre os servidores e a SAN existe um Switch SAN e, nos servidores, há uma
controladora chamada HBA (Host Bus Adapter), que é responsável pelo
acesso as Logical Unit Number (LUN),partições criadas para armazenar
dados. Em geral, as LUNS são compartilhadas por mais de um servidor
quando eles estão em uma solução de Failover Cluster.
As controladoras HBA tem um endereço chamado WWN, que é o endereço
físico da interface. É através deste número que o administrador da SAN vai
entregar a Logical Unit Number. Um WWN representa, para uma HBA, o
mesmo que um MAC Address para uma Network Interface Card (NIC).
Compartilhar o armazenamento, normalmente, simplifica a administração e
proporciona flexibilidade, uma vez que cabos e dispositivos de
armazenamento não precisam ser movidos ao transferir o armazenamento de
um servidor para outro.
Nível de Armazenamento
As duas tecnologias de sistema de armazenamento mais populares são:
armazenamento em nível de arquivo e em nível de bloco.
Block Level. Neste armazenamento em nível de bloco, criam-se volumes
brutos de armazenamento, e cada bloco pode ser controlado como um
disco rígido individual. Estes blocos são controlados por sistemas
operacionais baseados no servidor e, cada bloco, pode ser formatado
individualmente com o sistema de arquivo desejado.
Este modelo é mais adotado em redes SAN, e pode ser usado para armazenar
arquivos, além de trabalhar com aplicações especiais, como banco de dados e
máquinas virtuais.
O armazenamento em nível de bloco usa protocolos como ISCSI e FCoE para
transferência de dados, pois os comandos SCSI atuam como interface de
comunicação entre o Target (alvo) e o Initiator (iniciador).
File Level. O sistemade armazenamento em nível de arquivos é mais
visto em sistemas NAS (Network Attached Storage). Neste sistema, o
armazenamento é configurado com um protocolo, como NFS e SMB, e
acessados a partir dele por diversos dispositivos em rede.
Ele armazena arquivos em pastas e a visibilidade é a mesma para clientes que
o acessam e para o sistema que o armazena. Apresenta manutenção barata,
quando comparado com suas soluções em nível de bloco.
Gerenciamento Remoto de Discos
Gerenciar discos remotamente se torna' uma tarefa rotineira se você opta por
implementar as versões core ou Nano Server. Para gerenciar os discos
remotamente, a partir do Windows 10 ou, até mesmo, a partir de outro
servidor Windows Server 2016, deve-se, primeiro, abrir as regras de firewall
no Nano Server e Server Core. Já existem sete regras para esta finalidade,
mas elas estão desabilitadas por padrão. Para habilitá-las, execute o comando
Enable-NetFirewallRule com as setes regras associadas.
Enable-NetFirewallRule -DisplayName 'Remote Event Log
Management (RPC)' 
Enable-NetFirewallRule -DisplayName 'Remote Event Log
Management (NP-In)' 
Enable-NetFirewallRule -DisplayName 'Remote Event Log
Management (RPC-EPMAP)'
Enable-NetFirewallRule -DisplayName 'Remote Volume
Management - Virtual Disk Service (RPC)' 
Enable-NetFirewallRule -DisplayName 'Remote Volume
Management - Virtual Disk Service Loader (RPC)'
Enable-NetFirewallRule -DisplayName 'Remote Volume
Management (RPC-EPMAP)'
 
Gerenciamento Linha de Comando
Diskpart é uma ferramenta de linha de comando do Windows Server para
gerenciamento de discos através de um prompt. Pode haver a necessidade de
utilizá-lo localmente, caso algo impeça o acesso remoto.
Para listar um disco, selecioná-lo, convertê-lo para dinâmico, criar um
volume simples, associar a letra W, e formatá-lo com o sistema de arquivos
NTFS, use a seguinte combinação de comandos do Diskpart:
Diskpart
Select disk 1
Convert dynamic
Create volume simples size=1000000 disk=1
Assign letter=w
Format fs=ntfs label=”data disk” quick
Também, é possível utilizar o PowerShell para automatizar o gerenciamento
de um grupo de discos que foram apresentados para o Windows Server, mas
ainda não foram configurados. Enquanto estes discos não são iniciados, eles
ficam com estilo de partição conhecido como “RAW”. Para automatizar esta
tarefa, use a combinação de comandos PowerShell concatenados pelo
pipeline (|).
Get-Disk |
 Where-Object PartitionStyle -eq 'raw' |
 Initialize-Disk -PassThru |
 New-Partition -UseMaximumSize -AssignDriveLetter |
 Format-Volume -FileSystem ReFS 
Através do PowerShell, pode-se também criar discos virtuais VHD ou VHDX
e anexá-los, tanto a máquinas físicas, como a virtuais. Use a combinação do
comando New-VHD com outros comandos para criá-los, iniciá-los e formatá-
los.
New-VHD -Path C:\mydata.vhdx -Dynamic -SizeBytes 10Gb |
 Mount-VHD -Passthru |
 Initialize-Disk -Passthru |
 New-Partition -AssignDriveLetter -UseMaximumSize |
 Format-Volume -FileSystem NTFS 
 
Espaços de Armazenamento
Storage Spaces não é novo no Windows Server 2016, visto que já existe
desde o Windows Server 2012. Ele permite gerenciar e transformar o
Windows Server em uma solução de armazenamento robusto e altamente
redundante. O Storage Spaces usa discos conectados localmente ao servidor.
Ao criar um Pool de discos, você terá um espaço onde poderá criar seus
discos virtuais com resiliência, sem precisar convertê-los para dinâmicos.
Além disso, é possível aumentar e reduzir o tamanho do disco sem
interrupções. O script abaixo cria um Storage Pool chamado MyStoragePool,
com todos os discos locais disponíveis, e cria um virtual disk, chamado
MyVirtualDisk, de tamanho fixo e replicado com RAID Mirroring. Em
seguida, ele pode ser formatado como NTFS, e atrelado à próxima letra
disponível.
Também, pode-se utilizar o Server Manager para realizar estas tarefas:
$disks = Get-StoragePool -IsPrimordial $true |
 Get-PhysicalDisk | Where-Object CanPool -eq $True
$storageSubsystem = Get-StorageSubSystem
New-StoragePool –FriendlyName MyStoragePool `
–StorageSubsystemFriendlyName
$storageSubsystem.FriendlyName `
–PhysicalDisks $disks
New-VirtualDisk –FriendlyName MyVirtualDisk `
-StoragePoolFriendlyName MyStoragePool `
-ResiliencySettingName Mirror `
-ProvisioningType Fixed `
-NumberOfDataCopies 2 `
-UseMaximumSize
Get-VirtualDisk –FriendlyName MyVirtualDisk |
 Get-Disk | Initialize-Disk –Passthru |
 New-Partition –AssignDriveLetter –UseMaximumSize |
 Format-Volume -FileSystem NTFS
 
Qualidade de Serviço (QoS)
Agora, é possível utilizar QoS (Qualidade de Serviço) de armazenamento
para monitorar, centralmente e de ponta a ponta, o desempenho do
armazenamento, além de criar políticas de gerenciamento usando Clusters de
Hyper-V e CSV no Windows Server 2016.
O desempenho de armazenamento é reajustado, automaticamente, para
atender às políticas agregadas ou dedicadas, à medida que as cargas de
trabalho e de armazenamento flutuam.
Usando o PowerShell, pode-se executar as seguintes tarefas:
Criar políticas em um disco CSV;
Enumerar as políticas disponíveis em um cluster CSV;
Atribuir uma política a um disco rígido virtual de uma VM no Hyper-V;
Monitorar o desempenho de cada workload e seu status;
Se vários discos rígidos compartilham a mesma política, o desempenho é
distribuído uniformemente para atender à demanda, de acordo com as
configurações mínimas e máximas da política. Portanto, uma política pode
ser usada para gerenciar um disco rígido virtual, uma ou várias máquinas
virtuais que compõem um serviço, ou todas as máquinas virtuais pertencentes
a um tenant.
Políticas de Armazenamento
As políticas de QoS são definidas e gerenciadas no cluster de file server e de
Scale Out File Server. Você pode criar até 10.000 políticas por cluster de
armazenamento.
Tipos de políticas
Há dois tipos de políticas: Agregada (anteriormente conhecida como
SingleInstance) e Dedicada (anteriormente conhecida como MultiInstance).
As políticas agregadas aplicam máximos e mínimos para um conjunto
combinado de arquivos VHD/VHDX e para as máquinas virtuais a que elas
se aplicam. Na verdade, elas compartilham um conjunto específico de IOPS e
largura de banda. Quanto às políticas dedicadas, elas aplicam os valores
mínimo e máximo para cada VHD/VHDX, separadamente. Isso facilita a
criação de uma única política, que aplica limites semelhantes para vários
arquivos de uma única vez. Lembre-se que 1 IOPS equivale a 8KB. Se o
número for menor do que 8KB, considera-se 1 IOPS e, se for maior, será
múltiplo de 1. Por exemplo, 4KB equivale a 1 IOPS, 16KB equivale a 2
IOPS, e assim sucessivamente.
Por exemplo, caso se crie uma política agregada com um mínimo de 300
IOPS, e um máximo de 500 IOPS, e aplicá-la a cinco arquivos VHD/VHDX
diferentes, garante-se que os cinco arquivos combinados tenham, ao menos,
300 IOPS - contanto que haja demanda e o sistema de armazenamento possa
fornecer esse desempenho - e não mais do que 500 IOPS. Se os arquivos
VHD/VHDX tiverem demanda alta para IOPS, e o sistema de
armazenamento puder acompanhar, cada arquivo receberá cerca de 100
IOPS.
No entanto, ao criar uma política com os mesmos limites e aplicá-la a 5
máquinas virtuais diferentes, cada máquina virtual receberá, pelo menos, 300
IOPS, e não mais do que 500 IOPS. Portanto, se houver um grupo de
arquivos VHD/VHDX para qual se queira manter as características de
desempenho, sem o trabalho de criar várias políticas semelhantes, pode-se
utilizar uma única política e aplicá-la aos arquivos de cada máquina virtual.
Primeiramente, use o cmdlet New-StorageQoSPolicy para criar uma política
no seu servidor Scale Out File Server (SOFS), conforme demonstrado no
exemplo a seguir:
$desktopVmPolicy= New-StorageQosPolicy -Name Desktop -
PolicyType Dedicated -MinimumIops 100 -MaximumIops 200
Em seguida, obtenha o PolicyID através da propriedade PolicyId da variável
$desktopVmPolicy
$desktopVmPolicy.PolicyId
E finalmente, no seu servidor de Hyper-V, defina a política de QoS usando a
PolicyID:
Get-VM -Name VMName | Get-VMHardDiskDrive | Set-
VMHardDiskDrive -QoSPolicyID cd6e6b87-fb13-492b-9103-
41c6f631f8e0
 
Use o cmdlet Get-StorageQoSFlow do Powershell para confirmar se o
mínimo e o máximo de IOPS foram aplicados apropriadamente:
Get-StorageQoSflow | Sort-Object InitiatorName | FT
InitiatorName, Status, MinimumIOPs, MaximumIOPs,
StorageNodeIOPs, Status
Também se pode utilizar o comando Get-VM combinado com Get-
VMHardDiskDrive para ver qual política deve ser aplicada a um disco
virtual:
Get-VM -Name VMName | Get-VMHardDiskDrive | Format-
List 
Após criar um Failover Cluster e configurar um disco CSV, o Storage QoS
Resource será exibido como um recurso principal do cluster, e estará visível
no console do Failover Cluster Manager.
Replicação
Storage replica é uma nova tecnologia do Windows Server 2016 que permite
a replicação de volumes entre servidores ou clusters para recuperação de
desastres. Ele também permite que se estenda clusters de failover que
abrangem dois sites, com todos os nodes em sincronia.
O storage replica oferece suporte à replicação síncrona e assíncrona:
A replicação síncrona espelha os dados em um site de rede de baixa
latência, com volumes consistentes com falha, para garantir perda zero de
dados durante uma falha no nível do sistema de arquivos.
A replicação assíncrona espelha os dados entre locais, além dos limites
metropolitanos em links de rede com latências maiores, mas sem garantir
que os dois locais tenham cópias idênticas dos dados no momento da
falha.
Sua empresa pode se beneficiar dessa nova funcionalidade e dos diferentes
cenários. O storage replica oferece novos recursos de recuperação de desastre
e preparação no Windows Server 2016 Datacenter Edition. Pela primeira
vez, o Windows Server oferece a tranquilidade da perda zero de dados, com a
capacidade de proteção dos dados de forma síncrona em diferentes racks,
andares, edifícios, campi, municípios e cidades. Após um desastre, todos os
dados existirão em outro lugar, sem possibilidade de perda. O storage replica
oferece a capacidade de alternar as cargas de trabalho para locais seguros.
Ele também permite o uso mais eficiente de vários datacenters. Alongando ou
replicando clusters, as cargas de trabalho podem ser executadas, por usuários
e aplicativos com proximidade local, em vários datacenters para o acesso
mais rápido a dados, além de permitir uma melhor distribuição de carga e uso
dos recursos de computação. Se um desastre coloca um datacenter offline,
pode-se mover, temporariamente., suas cargas de trabalho típicas para outro
local.
O storage replica ainda permite o encerramento de sistemas de replicação de
arquivos existentes, como a replicação do DFS, que costumavam ser as
soluções de recuperação de desastre de baixo custo. Embora a replicação do
DFS funcione bem em redes com largura de banda extremamente baixa, sua
latência é muito alta, sendo geralmente medida em horas ou dias. Isso é
causado pela exigência do fechamento de arquivos, e de seus limites
artificiais, como forma de evitar o congestionamento da rede. Com essas
características de design, os arquivos mais recentes e mais usados em uma
replicação do DFS são os que têm menor probabilidade de replicação. O
storage replica opera abaixo do nível de arquivo e não tem essas restrições.
FIGURA 02-04. Instalação do Storage Replica pelo Server Manager
Ele também dá suporte à replicação assíncrona para redes com latência maior
e intervalos mais longos. Como ele não está baseado em um ponto de
verificação, e replica de forma contínua, o delta de alterações tende a ser
muito menor do que nos produtos baseados em instantâneo (snapshots). Além
disso, o storage replica opera na camada da partição. Portanto, ela replica
todos os instantâneos de VSS criados pelo Windows Server ou pelo software
de backup. Isso permite o uso de instantâneos de dados consistentes com o
aplicativo para recuperação pontual, principalmente dados de usuário não
estruturados replicados de forma assíncrona.
Seguem abaixo possíveis cenários de uso do Storage Replica:
Cluster Estendido
Permite a configuração de computadores e o armazenamento em um único
cluster, em que alguns nodes compartilham um conjunto de armazenamento
assimétrico, e outros compartilham um conjunto diferente . Depois, fazem a
replicação de forma assíncrona com reconhecimento dos sites. Esse cenário
pode utilizar o Storage Pool com discos SAS compartilhados, LUNs
conectadas a SAN e iSCSI. Ele é gerenciado com o Powershell e a ferramenta
gráfica do Failover Cluster Management e permite failover automatizado.
Cluster para Cluster
Permite a replicação entre dois clusters separados, em que um cluster é
replicado de forma síncrona ou assíncrona com outro cluster. Esse cenário
permite utilizar o Storage Space Direct com armazenamento SAS
compartilhado, LUNs conectadas a SAN e iSCSI. Ele é gerenciado com o
PowerShell e requer intervenção manual para failover.
Servidor para Servidor
Permite a replicação síncrona e assíncrona entre dois servidores autônomos,
usando Espaços de Armazenamento com armazenamento SAS
compartilhado, LUNs conectadas a SAN, e iSCSI e unidades locais. Ele é
gerenciado com o PowerShell e o Failover Cluster Manager, e requer
intervenção manual para failover.
Para instalar a função de Storage Replica em múltiplos servidores use o
comando Invoke-Command. No exemplo abaixo, as funções Storage-
Replica e FS-FileServer são instaladas nos servidores Server1 e Server2
Invoke-Command -ScriptBlock {
Install-WindowsFeature -Name Storage-Replica,FS-FileServer -
IncludeManagementTools -Restart
} -ComputerName server1, server2
No cenário cluster para cluster e para Cluster Estendido deve-se usar a
console do Failover Cluster Management para replicar os discos. Agora, no
cenário servidor para servidor, a configuração deve ser feita pelo PowerShell.
Não há interface gráfica.
Primeiro, crie uma parceria de replicação entre os servidores Server1, como
servidor de origem, e Server2, como destino.
New-SRPartnership -SourceComputerName server1 -
SourceRGName RG1 `
-SourceVolumeName D: -SourceLogVolumeName E: `
-DestinationComputerName server2 -DestinationRGName RG2
`
-DestinationVolumeName D: -DestinationLogVolumeName E:
Para monitorar a replicação use o comando (Get-SRGroup).replicas ou Get-
SRPartnership
Para inverter a replicação, definindo o Server2 como origem e o Server1
como destino, execute o comando Set-SRPartnership.
Set-SRPartnership -NewSourceComputerName server2 `
-SourceRGName RG2 -DestinationComputerName server1 -
DestinationRGName RG1
Para desabilitar a replicação, execute o comando abaixo:
Get-SRPartnership | Remove-SRPartnership
Get-SRGroup | Remove-SRGroup
 
Nota
Tanto os discos de origem, quanto os de destino necessitam,
obrigatoriamente, ter o mesmo tamanho, e apresentar um disco de log. E
somente discos particionados, como GPT, são permitidos.
 
Sistema de Arquivos de Criptografia Resiliente (ReFS)
Muito desconhecida, ou quase nunca adotada no Windows Server 2012, o
REFS (Resilient Encryption File System) vem agora com novos recursos e
melhorias. Adote o ReFS, a partir de agora, para seus projetos de
virtualização, e configure o Hyper-V para disco do jeito que deve ser.
Quando o sistema de arquivos do ReFS é usado para Hyper-V, dois
benefícios imediatos de velocidade e eficiência podem ser obtidos. O
primeiro é que os Checkpoints (Snapshots) agora podem ser feitos através de
uma atualização de metadados, também chamados Production Checkpoints, e
são incrivelmenterápidos.
O segundo benefício está no provisionamento de arquivos VHD ou VHDX de
tamanho fixo. Um arquivo VHD de 500GB de tamanho fixo, em um volume
NTFS, pode demorar até 40 minutos para ser provisionado, e apenas 14
segundos em um volume ReFS. Este recurso no Hyper-V 2016 é conhecido
como Instant Fixed Disk Creation.
FIGURA 02-05. Disco formatado com o sistema de arquivo ReFS
A formatação real do volume com o ReFS faz parte do processo de
provisionamento de discos. Agora, isso ficou bastante simples. No entanto, o
ReFS ainda não é a opção padrão quando se trata de formatar um volume.
Visualmente, não há diferenças entre um volume ReFS e NTFS, quando
vistos lado a lado. Basta renomear o Label do disco, colocando um nome que
o identifique como ReFS, por exemplo, “ReFS VM Data Disk”. O ReFS
também é o sistema de arquivos usados no Storage Space Direct.
Para mensurar o tempo gasto no provisionamento de cada volume NTFS e
ReFS, faça um teste criando um arquivo VHDX com um tamanho mínimo de
100GB, através do Powershell de tamanho fixo. O comando Measure-
Command calculará o tempo gasto para executar o comando.
Measure-Command {New-VHD -Fixed -Path
"C:\ClusterStorage\Volume1-
NTFS\LargeSectorBlockSize.vhdx" -BlockSizeBytes 128MB -
LogicalSectorSize 4KB -SizeBytes 100GB}
 
Measure-Command {New-VHD -Fixed -Path
"C:\ClusterStorage\Volume2-
REFS\LargeSectorBlockSize.vhdx" -BlockSizeBytes 128MB -
LogicalSectorSize 4KB -SizeBytes 100GB}
 
Eliminação da Duplicação de Dados (Dedup)
A eliminação da duplicação de dados (Data Dedup) pode minimizar, de
maneira eficaz, os custos de consumo de dados de um aplicativo para
servidores, o que reduz a quantidade de espaço em disco consumida por
dados redundantes e duplicados. Antes de habilitá-la, é importante entender
as características de sua carga de trabalho para garantir a obtenção do
máximo desempenho do seu armazenamento.
FIGURA 02-06. Configuração do Dedup para propósitos gerais, VDI ou
servidor de backup
A eliminação da duplicação de dados apresenta os seguintes aprimoramentos
no Windows Server 2016:
Suporte a grandes volumes
Para obter o melhor desempenho do Data Deduplication no Windows Server
2016, os volumes devem ser dimensionados adequadamente para garantir que
o trabalho de otimização possa acompanhar a taxa de alterações, ou
variações, de dados. Normalmente, isso significa que o Data Deduplication é
eficaz somente em volumes de até 10 TB, dependendo dos padrões de
gravação da carga de trabalho. No Windows Server 2016, o Dedup é
altamente eficaz em volumes de até 64 TB.
Para garantir que os trabalhos de otimização não se atrasem, o que causaria a
diminuição da taxa geral de economia do volume, grandes conjuntos de
dados devem ser divididos em volumes menores. O tamanho do volume
apropriado depende da variação esperada para esse volume. Em média,
considera-se o máximo de, aproximadamente, 6 a 7 TB, para volumes de alta
variação, e 9 a 10 TB, para volumes de baixa variação.
No Windows Server 2016, o Dedup foi projetado para executar vários
processos em paralelo usando várias filas para cada volume. Isso resulta em
um desempenho que, anteriormente, só seria possível por meio da divisão dos
dados em vários volumes menores.
Suporte a arquivos grandes
No Windows Server 2016, a eliminação da duplicação de arquivos de até 1
TB é muito eficaz. Por exemplo, pode-se economizar muito espaço em disco
para arquivos muito grandes, normalmente associados a cargas de trabalho de
backup.
O Dedup usa uma estratégia de pós-processamento para otimizar e manter a
eficiência do espaço de um volume. Há quatro principais tipos de trabalho
envolvidos: Optimization, Scrubbing, Garbage Collection e Unoptimization.
Optimization O trabalho de otimização elimina a duplicação de dados de
volumes fragmentados, de acordo com as configurações de políticas de
volume, compactando estas partes e as armazenando de forma exclusiva
em um repositório.
 
Scrubbing O trabalho conhecido como Scrubbing, ou depuração,
identifica danos ao repositório, que são gerados por falhas de disco ou
setores inválidos. Quando possível, o Dedup utiliza, automaticamente, os
recursos de resiliência, como espelhamento ou paridade, em um volume
do Storage Space, para reconstruir os dados corrompidos. Além disso, este
tipo de trabalho guarda cópias de backup das partes comuns, quando elas
são referenciadas mais de 100 vezes em uma área denominada ponto de
acesso.
 
Garbage Collection O trabalho de coleta de lixo recupera o espaço em
disco, removendo partes desnecessárias, que não estão mais sendo
referenciadas por arquivos modificados ou excluídos recentemente.
 
Unoptimization O trabalho de cancelamento da otimização é um trabalho
especial, que só pode ser executado manualmente. Ele desfaz a otimização
e desabilita a eliminação da duplicação de dados no volume.
Suporte ao Nano Server
O Nano Server é uma nova opção de implantação sem periféricos no
Windows Server 2016, que requer uma superfície de recursos de sistema bem
menor. Sua inicialização é bem mais rápida, e exige menos atualizações e
reinicializações do que a opção de implantação do Windows Server Core. A
eliminação da duplicação de dados tem suporte total no Nano Server.
Para instalar o Data Deduplication no Nano Server, primeiro estabeleça uma
conexão remota Enter-PSSession -ComputerName <NanoServerName> . Em
seguida, use o comando dism:
Dism /online /enable-feature /featurename:dedup-core /all
Suporte a upgrades do sistema operacional de cluster sem interrupção
Em versões anteriores do Windows Server, um Cluster de Failover do
Windows Server exigia que todos os nós do cluster tivessem a mesma versão
do Windows Server. A partir do Windows Server 2016, a funcionalidade de
upgrade sem interrupção permite que um cluster seja executado em modo
misto. O dedup dá suporte a essa nova configuração de cluster para permitir o
acesso a dados completos durante um upgrade de cluster sem interrupção.
Para instalar o serviço Data Deduplication, abra o Server Manager, expanda
File and Storage Services e escolha Data Deduplication. Depois, clique em
Next e, em seguida, em Install.
Install-WindowsFeature FS-Data-Deduplication -IncludeAllSubFeature
 
Para habilitar o Dedup em um volume D:\, execute o seguinte comando:
Enable-DedupVolume -Volume D: -UsageType Default
 
Modifique a política de dedup existente.
 
Set-DedupVolume -Volume D: -MinimumFileAgeDays 0
 
 
Manualmente, inicie o processo de dedup em um volume.
 
Start-DedupJob –Volume D: -Type Optimization -Memory 50
 
Serviços de Armazenamento
iSCSI Target Server
Desde o Windows Server 2012, o sistema operacional passou a ser
transformado em uma storage do tipo NAS (Network Attached Storage), mas
com suporte ao protocolo iSCSI. Desta forma, os espaços em discos locais
poderiam ser entregues de maneira compartilhada para mais de um servidor.
Os clientes podem ser servidores ou estações de trabalho, e a conexão é feita
através do utilitário iSCSI Initiator, nativo no sistema operacional.
 
FIGURA 02-07. Instalação do iSCSI Target pelo Server Manager
 
Existem duas configurações tradicionais que devem ser feitas para a adoção
de uma storage iSCSI. A primeira é o Jumbo Frames e a segunda MPIO.
 
Jumbo Frames
 
Configurar Jumbo frames significa alterar o MTU (Maximum Transmission
Unit) da placa de rede de 1500 bytes para 9000 bytes, isso faz com que os
pacotes de comunicação passem a ter um tamanho máximo de 9000 bytes, 6
vezes o padrão original. o Jumbo Frames deve ser habilitado nas
propriedades das duas placas de rede dedicadas para a rede ISCSI, no seu
Windows Server. Basta ir até as propriedades da interface de rede, selecionar
Jumbo Packet, e alterar para 9014 bytes.
 
FIGURA 02-08. Placa de rede com o Jumbo Packet habilitado para 9014
bytes
Para ter certeza de que aconfiguração de Jumbo Frames foi realizada com
sucesso, pode-se utilizar o comando Ping, passando como parâmetro um
valor maior do que 1500 bytes no envio de MTU.
ping -f -l 9000 [destination ip]
 
MPIO
A Microsoft Multipath I/O (MPIO) é uma estrutura que utiliza componentes
com caminhos físicos redundantes - adaptadores, cabos e comutadores - para
criar caminhos lógicos entre o servidor e o dispositivo de armazenamento. Na
eventualidade de um ou mais destes componentes falhar, provocando a falha
do caminho, a lógica de múltiplos caminhos utiliza um caminho alternativo
para a E/S para que as aplicações continuem a acessar os respectivos dados.
 
FIGURA 02-09. Instalação do Multipath I/O pelo Server Manager
Cada placa de interface de rede (no caso de iSCSI) ou HBA deverá ser ligada
através de infraestruturas de comutação redundantes a fim de possibilitar o
acesso continuado ao armazenamento em caso de falha num componente de
hardware de armazenamento.
 
Pode-se usar o Server Manager ou o Powershell para instalação da Multipath-
IO.
 
Install-WindowsFeature Multipath-IO
 
 
FIGURA 02-10- Conexão pelo iSCSI Initiator em um iSCSI Target
Simulado
Questão 01
Qual é o maior tamanho de volume suportado pelo serviço de Data
Deduplication no Windows Server 2016?
A. 1 TB
B. 16 TB
C. 32 TB
D. 64 TB
Questão 02
Qual o maior tamanho de arquivo suportado pelo serviço de Data
Deduplication no Windows Server 2016?
A. 512 MB
B. 1 GB
C. 1 TB
D. 4 TB
Questão 03
Você precisa implantar manualmente o processo de data deduplication. Qual
cmdlet do PowerShell você usaria para fazer isso?
A. Start-DedupJob
B. Enable-DedupJob
C. Invoke-DedupJob
D. New-DedupJob
Questão 04
Você precisa configurar um RAID por software, em um servidor Windows
Server 2016. Qual é o tipo de RAID que terá o melhor desempenho, sem
redundância?
A. RAID 1
B. RAID 1+0
C. RAID 5
D. RAID 0
Questão 05
Você precisa instalar um novo disco rígido em um servidor Windows Server
2016. Este disco vai armazenar uma aplicação que exigirá uma alta taxa de
I/O. É preciso garantir o mais alto número de IOPS para esta aplicação. Qual
tipo de disco funcionaria melhor?
A. SSD
B. SCSI
C. SATA
D. SAS
Questão 06
Você acabou de instalar um disco de 4 TB em um computador Windows
Server 2016. Qual tabela de partição deverá ser usada para este novo disco?
A. NTFS
B. MBR
C. GPT
D. ReFS
Questão 07
Você precisa promover um novo Domain Controller, e acabou de adicionar
um segundo disco no servidor que será usado para armazenar a base de dados
do Active Directory (NTDS.DIT). Você inicializa o disco como GPT. Qual
sistema de arquivo você deveria usar para este novo volume?
A. ReFS
B. MBR
C. GPT
D. NTFS
Questão 08
Um dos seus aplicativos de missão crítica usa um banco de dados SQL. e é
necessário migrar o servidor para uma máquina Windows Server 2016. Onde
deverá ser armazenado o arquivo de banco de dados para fornecer o melhor
desempenho de leitura e gravação?
A. Em um compartilhamento NFS
B. Em um compartilhamento SMB
C. Em uma storage block-level
D. Em uma storage file-level
Questão 09
Você configurou um servidor Windows Server 2016 como um ISCSI Target.
Vários discos virtuais já foram criados. Onde você configuraria a
conectividade com estes discos?
A. Usando o Server Manager
B. Usando o iSCSI Initiator
C. Usando o iSCSIscsi Target
D. Usando o cmdlet New-VirtualDisk
Questão 10
Você precisa criar um volume que será protegido contra falhas de hardware.
Então, decide executar um RAID 1 (espelhamento) entre dois discos. Qual
tecnologia usar deve ser usada para fazer isso?
A. Criar um RAID com uma controladora física
B. Criar dois volumes espelhados com o Storage Spaces
C. Implementar dois compartilhamentos e replicá-los com o DFSR
D. Criar um RAID 1 através do Disk Management (diskmgmt.msc)
Questão 11
É necessário invocar manualmente o processo de data deduplication. Qual
tipo de trabalho deve-se ativar através do Powershell?
A. Unoptimization
B. Scrubbing
C. Optimization
D. Garbage Collection
Questão 12
Você precisa configurar um backup de volume que mantenha um conjunto de
dados reduzidos. Qual tipo de backup deverá usar?
A. Diferencial
B. Block-level
C. Incremental
D. File-level
Questão 13
Você precisa desabilitar o processo de data deduplication no disco D:\. Qual
comando do Powershell você deveria usar?
A. Start-DedupJob -Volume D: -Type GarbageCollection
B. Disable-Dedup -Volume D: -Force
C. Start-DedupJob -Volume D: -Type Unoptimization
D. Stop-Deduplication -Volume D:
Questão 14
Você precisa configurar o RAID por software em um servidor Windows
Server 2016. O que precisa ser feito primeiro com os discos básicos ?
A. Eles precisam ser particionados
B. Eles precisam ser convertidos para Dynamic
C. Eles precisam ser formatados
D. Eles precisam ser SSDs
Questão 15
Seu time está trabalhando em uma solução automatizada para implantação de
novos servidores em seu ambiente. É preciso automatizar a configuração de
vários discos secundários em cada servidor e você decidiu usar o PowerShell.
Qual cmdlet deve ser usado, pela primeira vez, para configurar uma tabela de
partição em cada disco?
A. Format-Volume
B. Initialize-Volume
C. Initialize-Disk
D. Format-Disk
Questão 16
Sua equipe está trabalhando em uma solução automatizada para a
implantação de novos servidores em seu ambiente. É preciso automatizar a
configuração de vários discos secundários em cada servidor. Qual cmdlet
deveria ser usado para criar volumes nestes novos discos?
A. New-Volume
B. New-Disk
C. Initialize-Disk
D. New-Partition
Questão 17
É necessário automatizar a criação de um Storage Pool com o Storage Space
no Windows Server 2016. Qual cmdlet deveria ser usado?
A. New-VirtualDisk
B. New-StoragePool
C. New-Volume
D. New-StorageSpace
Questão 18
Você tem que preparar um servidor para replicar seus discos de maneira
síncrona para outro servidor secundário, para recuperação de desastre. O que
deve ser feito antes de implementar o Storage Replica?
A. Executar o cmdlet New-SRPartnership
B. Instalar e configurar um Iscsi Target
C. Instalar e configurar um Storage Space
D. Garantir que a latência entre os servidores seja menor do que 5 ms
Questão 19
Sua equipe implantou a replicação do Storage Replica no cenário servidor
para servidor. Um dos membros do time está tendo problemas para acessar e
visualizar os dados replicados no servidor de destino e pediu sua ajuda. O que
você deveria fazer?
A. Desabilitar o Storage Replica
B. Dizer para ele acessar os dados no servidor de origem
C. Desabilitar o Storage Spaces
D. Executar o comando Get-SRGroup
Questão 20
Qual comando deve ser usado para criar uma parceria de replicação com o
Storage Replica?
A. New-VirtualDisk
B. New-StoragePool
C. New-StorageReplica
D. New-SRPartnership
 
Respostas
01-
D
02-
C
03-
A
04-
D
05-
A
06-
C
07-
D
08-
C
09-B 10-B
11-
C
12-B 13-
C
14-B 15-
C
16-
D
17-
A
18-
D
19-B 20-
D
 
 
CAPÍTULO 03 – Implantar Hyper-
V
 
Neste capítulo, apresentarei a virtualização e seus benefícios. Entenderemos
sobre a evolução do Hyper-V, ao longo dos últimos anos, e discutiremos
sobre escalabilidade, melhorias, resolução de problemas.
Para entendermos a evolução do Hyper-V até os dias de hoje, precisamos
voltar no ano de 1988. Naquele ano, Jon Garber fundou, nos Estados Unidos,
uma empresa de software e hardware chamada Connectix , que ficou muito
conhecida por desenvolver e lançar produtos inovadores de virtualização e
emulação, entre eles, um software chamado Connectix Virtual PC 1.0 para
computadores Mac da Apple. Este software permitia que usuários de Mac
pudessem rodar computadores virtuais Windows compartilhando o mesmohardware. Na época, foi considerado um marco na programação, pois
permitia o uso de um mecanismo de tradução de um processador físico
PowerPC, utilizado no Mac, em um processador virtual Intel x86.
Mais tarde, o Connectix Virtual PC 1.0 também passou a rodar em
computadores Windows e OS/2. Em fevereiro de 2003, a Connectix foi
comprada pela Microsoft e o software sofreu uma alteração no nome,
passando a chamar Microsoft Virtual PC 2004. Com a VMWare Corporation
já bem estabelecida no mercado de virtualização de servidores, a Microsoft
desenvolveu e lançou, em 2005, o Microsoft Virtual Server 2005 em duas
versões: Standard e Enterprise Edition. Esta última era um hypervisor Tipo 2,
mas até então limitado a suportar máquinas virtuais 32 bits. Só no ano de
2008, com o lançamento do Windows Server 2008 (Projeto LongHorn), o
Hyper-V foi lançado oficialmente na sua primeira versão, e passou a ser uma
função do sistema operacional. Mais tarde, uma versão Bare Metal do
hypervisor foi lançada e batizada como Microsoft Hyper-V Server.
Muito já se sabe sobre os principais benefícios trazidos pela virtualização.
Usando a tecnologia de virtualização, as empresas podem reduzir seu custo
total de propriedade (TCO) e manter uma infraestrutura enxuta, eficiente e
sustentável. A virtualização permite que as organizações gerenciem a
utilização dos servidores, permitindo uma redução do número de racks e
espaço nos datacenters, além da redução de energia elétrica e ar condicionado
para mantê-los refrigerados.
Outro grande benefício da virtualização é a melhoria da flexibilidade e
disponibilidade dos serviços. Os servidores podem ser implantados
rapidamente e podem permanecer on-line, mesmo quando os servidores
físicos exigem manutenção ou reparos. Devido ao encapsulamento, a
virtualização também permite novos cenários de recuperação de desastres.
O Hyper-V é um hypervisor tipo 1 executado diretamente no hardware, como
um programa de controle. Os sistemas operacionais hospedeiros são
executados acima do hypervisor e dois níveis acima do hardware. O benefício
de um hypervisor tipo 1 é que ele é executado diretamente no hardware do
computador, e não dentro de um sistema operacional. Alguns administradores
podem confundir este conceito, já que o Hyper-V é uma função do sistema
operacional, mas é instalado em um nível baixo, especialmente no Ring -1.
Os hypervisors de tipo 1 geralmente oferecem melhor desempenho,
disponibilidade e segurança. Outros exemplos de hypervisor do mesmo tipo
são o Xen Server, da Citrix, o KVM, da Red Hat, e o ESXi, da VMWare.
O Hyper-V 2016 suporta um número muito grande de recursos, até 320
processadores lógicos e 12 TB de memória no host físico, e máquinas
virtuais com até 64 processadores virtuais e 1 TB de memória. Com um
Cluster de Hyper-V de até 64 nós, será possível sustentar até 8.000 máquinas
virtuais.
Memória e processadores são os maiores avanços do Windows Server 2016,
em resposta às solicitações de clientes para suportar cenários mais recentes,
como Machine Learning e Data Analytics.
No primeiro capítulo, vimos o licenciamento do Windows Server, que dá o
direito de uso do Hyper-V. É bom ressaltar que o Hyper-V não é vendido
separadamente. Para adotá-lo, existem duas maneiras: a primeira, comprando
a versão Standard ou Datacenter para seu host físico, ou baixando e
instalando a versão do Hyper-V Server 2016 gratuitamente.
Instalação do Hyper-V
Uma maneira simples e rápida de instalar a função de Hyper-V
simultaneamente, em vários servidores é utilizar o Powershell. Por exemplo,
o seguinte comando instala o Hyper-V em todos os computadores listados no
arquivo texto HyperVServers.txt e os reinicia, uma vez que a função tenha
sido instalada.
$computers = Get-Content
C:\Users\LocalAdmin\HyperVServers.txt
Invoke-Command -ScriptBlock {Add-WindowsFeature Hyper-V
-Restart} -ComputerName $computers
 
Isso vale para o serviço de Failover Cluster do Windows Server.
Diferentemente do Hyper-V, os servidores não precisam ser reiniciados após
a instalação.
$computers = Get-Content
C:\Users\LocalAdmin\HyperVServers.txt
Invoke-Command -ScriptBlock {Add-WindowsFeature
Failover-Clustering} -ComputerName $computers
 
Procure adotar em seu ambiente de produção a edição Core, do Windows
Server 2016 Datacenter. Essa é a edição recomendada pelo time de suporte da
Microsoft para servidores com Hyper-V. Primeiro, instale a versão Core
Datacenter. Em seguida, use estes comandos para configurar a rede e inserir o
servidor ao domínio do Active Directory.
New-NetIPAddress -interfacealias ethernet0 -IPAddress
192.168.3.200 -Prefixlength 24 -defaultgateway 192.168.3.2
Set-DNSClientServerAddress -interfacealias ethernet0 -
ServerAddress 192.168.3.10
 
Crie regras de firewall permitindo todo o tráfego de saída e de entrada.
 
New-NetFirewallRule -displayname "Allow All Traffic" -
direction outbound -action allow
New-NetFirewallRule -displayname "Allow All Traffic" -
direction inbound -action allow
 
Renomeie, inclua o domínio e reinicie.
 
Add-Computer -newname HYPERV01 -domainname banin.corp
-restart
 
A partir de agora, toda a gestão do host Hyper-V pode ser feita, remotamente,
através de um computador Windows 10 com o RSAT instalado. A
administração remota também pode ser feita através de um servidor membro
do domínio.
 
Todas as versões possuem o Hyper-V e o serviço de Failover Cluster. A
versão Datacenter permitirá um número ilimitado de máquinas virtuais no
host físico, enquanto a versão Standard só permitirá duas. Ambas incluem o
direito de uso da licença do Windows Server nos servidores virtuais. Já a
versão do Hyper-V 2016 Server, apesar de gratuita no host físico, necessita
uma licença válida e paga para cada máquina virtual.
Você também poderá se beneficiar do programa de “downgrade”, ou seja, as
máquinas virtuais podem ser de versões anteriores do Windows Server 2016,
tais como o 2012 R2 e o 2008 R2.
FIGURA 03-01. Console do Hyper-V Manager
Gerenciamento Remoto
Por muito tempo. a administração remota dos servidores Hyper-V foi um
desafio, quando ainda não pertenciam ao mesmo domínio do Active
Directory, pois não era possível informar, explicitamente, qual usuário e
senha tinham permissão de acesso.
Agora, o Hyper-V Manager comunica com seus servidores remotamente,
usando o protocolo WS-MAN, que permite autenticação CredSSP, Kerberos
ou NTLM. Quando se usa CredSSP para conectar em um servidor Hyper-V
remoto, pode-se executar a migração ao vivo sem habilitar a delegação
restrita no Active Directory. O protocolo WS-Man escuta na porta 80, que é
aberta por padrão.
A nova console do Hyper-V 2016 permite a compatibilidade com servidores
Hyper-V 2012 R2, 2012, Hyper-V Client do Windows 10, e Windows 8.1
Hoje, pode-se selecionar um usuário diferente do local admin para gerenciar
o servidor Hyper-V, além de conectar pelo endereço IP, ao invés do
hostname.
Para administrar servidores Hyper-V em outros domínios, ou até mesmo em
Workgroup, algumas ações são necessárias.
FIGURA 03-02. Acesso remoto do Hyper-V Manager
No servidor Hyper-V que será gerenciado, execute o comando C:\Enable-
PSRemoting. Este comando criará as regras necessárias no firewall para a
rede Private Network. Para permitir o acesso pela rede Public Network, será
necessário habilitar as regras para CredSSP e WinRM.
Execute, ainda, os seguintes comandos no servidor Hyper-V que será
gerenciado remotamente:
Set-Item WSMan:\localhost\Client\TrustedHosts -value * -force
Enable-WSManCredSSP -Role client -DelegateComputer *
 
Em ambos os comandos acima, pode-se trocar o valor * (asterisco) pelo nome
FQDN do servidor, ou estação de trabalho cliente, que gerenciará os
servidores.
Delegação Kerberos
Há muitas opções de instalação de um sistema operacional guest em um
Hyper-V host, mas, sem dúvida alguma, o método mais tradicionalé instalá-
lo a partir de um arquivo no formato .ISO. Não faz muito sentido fazer uma
cópia destes arquivos nos discos locais dos servidores, pois, muito
provavelmente, você terá um compartilhamento de rede que servirá como sua
fonte de mídias para a instalação das suas máquinas virtuais. Como exemplo,
vejamos a tarefa de criar uma máquina virtual no servidor Hyper-V, chamado
HVSRV, onde o arquivo .ISO está localizado no servidor de arquivos FSSRV
e no compartilhamento ISO (\\FSSRV\ISO). Ao adicionar um drive de DVD
e anexar a ISO no caminho \\FSSRV\ISO\WS2016.ISO, você receberá o
seguinte erro:
 “Failed to add device Virtual CD/DVD Disk, User Account does not have
permission to open attachment”.
 A mensagem diz que falta permissão, mas ao olharmos as permissões Share
e de NTFS, veremos que a autenticação para o grupo Authentication Users
existe. A restrição aqui não está na permissão, mas sim na autorização
imposta pelo protocolo Kerberos conhecido, como duplo salto. Suponhamos
que estivéssemos tentando gerenciar, remotamente, um servidor Hyper-V no
desktop Windows 10, com o Hyper-V Manager instalado. Porém, este
servidor Hyper-V está tentando acessar um compartilhamento em um terceiro
servidor. Se tentássemos acessar esse servidor em nome de outro usuário, este
procedimento seria negado, por questões de segurança. Este mesmo problema
acontece ao tentarmos realizar uma migração ao vivo de máquinas virtuais,
remotamente, a partir de uma máquina Windows 10 + RSAT.
Para resolver esta questão, é necessário configurar no Active Directory um
processo conhecido como delegação de Kerberos. Abra o ADUC (dsa.msc),
localize a conta de computador do Hyper-V, clique nas propriedades e na aba
Delegation, escolha a opção Trust this computer for Delegation to
specified services Only e, depois, em Use Kerberos Only. Clique no botão
Add, adicione o nome do computador que representa seu servidor de arquivos
(onde está localizado suas mídias) e escolha o protocolo CIFS. Reinicie seu
servidor Hyper-V para que estas alterações tenham efeito. A partir deste
momento, pode-se instalar a VM a partir de um arquivo .ISO que está em um
compartilhamento em outro servidor da rede.
FIGURA 03-03. Kerberos Delegation
Hyper-V no Hyper-V
Esta funcionalidade foi uma das mais aguardadas pelos entusiastas do Hyper-
V. Antes do Windows Server 2016, o servidor Hyper-V só podia ser
executado em máquinas físicas. Isso não foi um problema na produção, mas
quando se queria fazer algumas demonstrações ou treinamento, necessitava-
se de um monte de hardware para mostrar o que é possível fazer com o
Hyper-V. Agora, com o Nested Virtualization, pode-se executar o Hyper-V
dentro de uma máquina virtual e criar, por exemplo, um ambiente de
demonstração e laboratório completos, incluindo clusters de failover.
Isso me permitiu fazer os laboratórios e escrever este livro com tantos
detalhes, mesmo sem ter um servidor para tanto. Esse é um grande negócio
para os que realizam demonstrações ou treinamentos.
A exigência de hardware físico é menor na quantidade mas, na qualidade ,
não se pode dizer o mesmo. No meu laboratório, usei um laptop Dell Latitude
E7270, com 16 GB de memória e 01 disco de 512 GB SSD, e outro de SSD
externo. Mas o mais importante aqui é que o processador Intel i7 vem com
instrução de virtualização habilitado no UEFI, com suporte ao SLAT (Second
Layer Address Translation), mandatório para o funcionamento da Nested
Virtualization.
Além do processador, o sistema operacional host e guest precisam ser
Windows 10 ou Windows Server 2016. Não é possível habilitar o Hyper-V
em uma máquina virtual com o Windows Server 2012 R2 ou 2008 R2.
Crie uma máquina virtual, com o Windows Server 2016 Datacenter, no
Hyper-V e faça três ações antes de ligá-la. A primeira delas é não configurar
a VM com memória dinâmica, afinal a memória não pode ser flutuante em
um host de Hyper-V. A segunda, é passar as instruções de virtualização do
processador físico para a VM, com o seguinte comando:
Set-VMProcessor -VMName Name -
ExposeVirtualizationExtension $true
 
E, finalmente, ajustar a rede, o que pode ser feito de duas maneiras:
Habilitando o MAC address Spoofing ou o NAT (Network Address
Translation).
Para que os pacotes de rede sejam roteados para placa de rede virtual, o MAC
address spoofing precisa ser ligado através do comando abaixo:
Get-VMNetworkAdapter -VMName Name | Set-
VMNetworkAdapter -MacAddressSpoofing On
 
A segunda opção depende da tradução do endereço de rede (NAT). Essa
abordagem é mais adequada para os casos em que habilitar o Mac Address
Spoofing (falsificação de endereços MAC) não seja possível, como em um
ambiente de nuvem pública, por exemplo.
Primeiro, crie um switch virtual como Interna e depois crie a regra de NAT.
Observe que os endereços IPs são apenas um exemplo, e variam entre
ambientes.
New-VMSwitch -Name VmNAT -SwitchType Internal
New-NetNat –Name LocalNAT –
InternalIPInterfaceAddressPrefix “192.168.100.0/24”
 
O próximo passo é associar um endereço IP para a interface de rede.
Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -
IPAddress 192.168.100.1 -AddressFamily IPv4 -PrefixLength 24
 
Cada máquina virtual deve ter um endereço IP e um gateway atribuídos a ela.
Observe que o IP do gateway deve apontar para o adaptador NAT do passo
anterior. Também, pode-se atribuir um servidor DNS
Get-NetAdapter "Ethernet" | New-NetIPAddress -IPAddress
192.168.100.2 -DefaultGateway 192.168.100.1 -AddressFamily
IPv4 -PrefixLength 24
 
Netsh interface ip add dnsserver “Ethernet” address=<DNS
server>
 
Pronto. Sua máquina virtual está pronta para receber a instalação do Hyper-
V.
Hyper-V no VMWare Workstation
Se você já usa o virtualizador VMWare Workstation no seu notebook com o
Windows 10, saiba que já pode utilizar a virtualização aninhada, para
habilitar, como guest. o Hyper-V em uma máquina virtual Windows Server
2016 do seu VMWare Workstation.
Crie uma máquina virtual com o Windows Server 2016, usualmente a partir
de um arquivo .ISO, e desligue-a.
Utilize o editor de texto de sua preferência e abra o arquivo com a extensão
.VMX correspondente na máquina virtual. Na última linha, inclua 3 novos
parâmetros.
hypervisor.cpuid.v0 = “FALSE”
mce.enable = “TRUE”
vhu.enable = “TRUE”
Salve as alterações no arquivo .VMX. Nas propriedades da VM, selecione
Processors, e no campo Virtualization Engine, habilite a caixas de seleção
Virtualize Intel-VT-x/EPT ou AMD-V/RVI e Virtualize CPU performance
counters. No campo Preferred mode, escolha Intel VT-x AMD-V. Salve as
configurações e ligue a máquina virtual.
Máquinas Virtuais Linux
Já há algum tempo, o Hyper-V suporta a instalação e a execução de várias
distribuições do Linux. O suporte como guest do Linux ,no Hyper-V, é
especialmente procurado por provedores de hospedagem que precisam
fornecer aos seus clientes uma ampla gama de opções de plataforma Open
Source para executar seus aplicativos.
O suporte ao Linux no Hyper-V também é importante no espaço empresarial,
onde soluções de TI heterogêneas são geralmente adotadas. Devido às
necessidades desses clientes, a Microsoft prevê a virtualização como
plataforma cruzada, e oferece suporte a uma ampla gama de distribuições.
A Microsoft também inclui recursos robustos do Linux em toda a família de
produtos System Center, e nas ofertas do Microsoft Azure.
O Hyper-V suporta emulação de dispositivos para distribuições específicas de
Linux e FreeBSD. Quando executado com dispositivos emulados, eles não
oferecem alto desempenho e não aproveitam a infraestrutura de
gerenciamento de máquinas virtuais ricas, oferecidas pela tecnologia Hyper-
V.
A coleção de drivers necessários para executá-los é conhecida como Linux
Integration Services (LIS), ou FreeBSD Integration Services (BIS).
O LIS foi adicionado ao kernel do Linux,e continua a ser atualizado para
novos lançamentos, mas as distribuições Linux baseadas em kernels mais
antigos podem não apresentar esses aprimoramentos, ou as correções mais
recentes. A Microsoft fornece um download dos drivers do LIS para algumas
distribuições Linux, com base nesses kernels mais antigos. Como os
fornecedores de distribuição incluem versões do LIS, é melhor instalar a
versão mais recente, contanto que seja aplicável à sua instalação.
Serviços de Integração
O Integration Services permite ao host de virtualização extrair informações e
executar operações em uma máquina virtual. Normalmente, é necessário
instalar os drivers do Integration services a partir do arquivo
C:\Windows\System32\vmguest.iso, embora os Windows Server 2016,
Windows Server 2012 R2, Windows 10 e Windows 8.1 incluam estes
serviços por padrão em sua instalação original. Pode-se habilitar os seguintes
serviços de integração para uma máquina virtual:
Operating system shutdown. Este serviço permite desligar a máquina
virtual a partir do seu servidor host, ao invés de entrar no sistema
operacional e desligá-lo por dentro do Windows.
Time Syncronization. Sincronização do relógio do host com o relógio da
máquina virtual. Ele garante que o relógio da máquina virtual não seja
alterado, quando ela é reiniciada, interrompida ou revertida por um
Checkpoint (Snapshot).
Data Exchange. Permite ao servidor host de virtualização ler e modificar
valores específicos de registro de uma máquina virtual.
Heartbeat. Função que permite ao host de virtualização verificar se o
sistema operacional da máquina virtual está funcionando, e responder às
solicitações.
Backup (volume checkpoint). Pensado para máquinas virtuais que
suportam Volume Shadow Copy, este serviço sincroniza com o host de
virtualização, permitindo backups das máquinas virtuais enquanto elas
estão em operação.
Guest services. Esses serviços permitem a cópia de arquivos do host de
virtualização para a máquina virtual, usando o comando Copy-VMFile do
Windows PowerShell.
Os drivers em vmguest.iso estão disponíveis somente para sistemas
operacionais Windows. Para servidores Linux mais antigos, é necessário a
instalação do Linux Integration Services (LIS).
FIGURA 03-04. Serviços de integração
Para saber qual versão do Integration Services está instalada, abra o prompt
de comando como administrador, dentro da máquina virtual, e execute o
comando:
REG QUERY "HKLM\Software\Microsoft\Virtual
Machine\Auto" /v IntegrationServicesVersion
 
Get-ItemProperty “HKLM:Software\Microsoft\Virtual
machine\Auto”
 
Para ver as propriedades do Integration Services de uma máquina virtual,
também é possível utilizar o comando:
Get-VMIntegrationService -ComputerName HYPERVName -
VMName VM
 
Recentemente, o Integration Services passou a ser distribuído pelo Windows
Update, no Hyper-V 2016, o que permite aos clientes atualizarem suas
máquinas do Windows com todas as atualizações.
Gerações de Máquinas Virtuais
As máquinas virtuais geração 2 são um tipo especial de VM que diferem na
configuração das VMs agora denominadas geração 1. Estas poderiam ser
criadas em hosts de virtualização dos sistemas operacionais Windows Server
2008, R2 e 2012., enquanto as VMs geração 2 são suportadas somente no
Windows Server 2016 e 2012 R2. As máquinas virtuais geração 2 fornecem
as seguintes funcionalidades:
Podem iniciar a partir de discos virtuais, conectados em controladoras
SCSI.
Podem iniciar a partir de unidades de DVD virtuais, conectadas em
controladoras SCSI.
Suportam a firmware UEFI e o boot seguro.
Suportam o boot via PXE, usando um adaptador de rede standard.
Não há adaptadores legados nas VMs geração 2 e a maioria dos dispositivos
legados, como portas COM e unidades de disquete, não está mais presente, e
não foi projetada para simular hardware em computadores que tenham sido
submetidos à conversão física para virtual (P2V).
Configura-se a geração de uma VM durante a sua criação. Uma vez que a
VM esteja criada, o Hyper-V não permite modificá-la. O Windows Server
2016 Hyper-V suporta a execução de VMs geração 1 e 2. A geração 2 é mai
rápida, segura, resiliente a falhas e permite a instalação mais rápida do
sistema operacional.
Finalmente, lembre-se de utilizar a geração 2 somente no sistema operacional
versão x64 do Windows 10, Windows 8.0, Windows 8.1, Windows Server
2012, Windows Server 2012 R2 e Windows Server 2016. Ademais, ela
suporta somente arquivos. VHDX.
FIGURA 03-05. Escolha da geração na criação da máquina virtual
Segue abaixo tabela com as opções de boot para cada uma das gerações de
máquinas virtuais.
Métodos de boot Gen1 Gen2
Boot via PXE através de uma Standard
Network Adapter
Não Sim
Boot via PXE através de uma Legacy
Network Adapter
Sim Não
Boot via arquivo VHDX conectado a uma
controladora SCSI
Não Sim
Boot via arquivo ISO conectado a uma
controladora SCSI
Não Sim
Boot via arquivo VHD conectado a uma
controladora IDE
Sim Não
Boot via arquivo ISO conectado a uma
controladora IDE
Sim Não
Boot via floppy disk VFD Sim Não
 
Modo de Sessão Aprimorada
O modo de sessão aprimorada (Enhanced Session Mode) permite executar
algumas ações, incluindo CTRL+C+V, redirecionamento de áudio, câmeras,
impressoras, discos rígidos, portas USB, volume e mapeamento de
dispositivos, usando a tradicional conexão à VM e a Virtual Machine
Connection. Pode-se, também, fazer login em uma VM com um Smart Card.
Para habilitar o ESM, seleciona-se Allow Enhanced Session Mode, nas
propriedades do servidor Hyper-V.
Disponível somente para VM Gen2, este método só pode ser usado com
VMs que executam os sistemas operacionais clientes Windows 10, 8.1 e
servidores Windows Server 2016 e 2012 R2. Também é necessário ter
permissão para se conectar à VM, usando a Remote Desktop Session, através
da conta usada para iniciar a sessão na VM guest. É possível, ainda, obter
permissão, adicionando-se o usuário ao grupo Remote Desktop Users. Um
usuário que seja membro do local Administrator Group também tem essa
permissão. Obviamente, o serviço Remote Desktop Services deve estar em
execução na máquina virtual.
Discos Virtuais
O Hyper-V suporta dois formatos de discos rígidos virtuais. Os arquivos
.VHD, limitados a 2.040 GB., que podem ser usados em todas as versões
suportadas no Hyper-V. Além da limitação de tamanho, é importante lembrar
que não se pode usar arquivos de formato .vhd em VMs geração 2.
Os arquivos de discos virtuais no formato. vhdx são uma melhoria, em
relação aos discos virtuais no formato .vhd. A principal limitação deste novo
formato é que ele não pode ser usado em máquinas virtuais Windows Server
2008 e R2. Os discos de formato .vhdx apresentam os seguintes benefícios:
Podem ter até 64 TB de tamanho.
Podem apresentar tamanho de bloco maior para discos dinâmicos e
diferenciais.
Fornecem discos virtuais com setor lógico de 4K.
Possuem um log de registro interno que reduz as chances de corrupção.
Suportam o modo TRIM para recuperação do espaço não utilizado.
No modo gráfico, pode-se converter os discos virtuais no formato .vhd para
.vhdx, pelo Hyper-V Manager ou pelo Powershell, através do comando
Convert-VHD.
Os discos virtuais podem ser fixos, dinâmicos e diferenciais. A seguir, vamos
conhecer as diferenças entre eles.
Disco Fixo
Quando se cria um disco de tamanho fixo, todo o espaço usado pelo disco, no
momento da criação, é alocado no volume de armazenamento. Se o
armazenamento físico não suporta a tecnologia ODX (Offload Data
Transfer), um disco de 1 TB ou maior pode levar muito tempo para ser
provisionado. Explore, no capítulo sobre armazenamento, a sessão sobre o
novo sistema de arquivos ReFS, que resolverá este problema.
O espaço alocado ao disco a ser criado deve estar presente no volume do
host. Por exemplo, não se pode criar um disco fixo de 3 TB emum volume
que tenha apenas 2 TB de espaço disponível.
Para criar um disco de tamanho fixo de 40GB execute o comando abaixo.
Lembre-se que, para criá-lo, será necessário um espaço mínimo de 40 GB no
seu disco físico.
New-VHD -ComputerName HVName -Path
C:\VHD\MyFirstDisk.VHDx -SizeBytes 40GB -Fixed
 
Disco Dinâmico
Os discos de expansão dinâmica usam um pequeno arquivo inicial e, depois,
se expandem, à medida que a máquina virtual aloca dados para o disco. Isso
significa que é possivel criar um disco dinâmico de 3 TB em um volume de 2
TB, isso porque nem todos os 3 TB serão alocados na criação do disco. No
entanto, neste cenário é necessário garantir que se estenda o volume de 2 TB
antes que o disco virtual exceda este espaço.
Para criar um disco dinâmico de 100GB, execute o comando New-VHD. No
exemplo abaixo, o disco Disk01.VHDX terá aproximadamente 4.096 KB
iniciais, mas, se ele for anexado a uma máquina virtual, o sistema operacional
entenderá que o espaço em disco é de 100 GB.
New-VHD -Computername HVName -Path
C:\VHD\Disk01.VHDx -SizeBytes 100GB -Dynamic
 
Para adicionar este mesmo disco a uma máquina virtual do Hyper-V, execute:
Add-VMHardDiskDrive -ComputerName HVName -VMname
VM -Path C:\VHD\Disk01.vhdx
 
Os discos de tamanho dinâmicos também podem ser fragmentados. Para
saber qual é a porcentagem de fragmentação do arquivo, basta acessar a
propriedade FragmentationPercentage, do comando Get-VHD.
Disco Diferencial
Os discos diferenciais são tipos especiais que apresentam uma relação pai e
filho. O disco pai pode ser de tamanho fixo ou dinâmico, mas o disco filho
diferencial deverá ser do mesmo tipo que o do disco pai. Por exemplo, pode-
se criar um disco filho diferencial no formato .vhdx vinculado ao disco pai,
no mesmo formato .vhdx. Mas, não se pode criar um arquivo filho diferencial
desse mesmo formato .vhdx vinculado a um disco pai no formato .vhd.
Os discos diferenciais gravam as alterações que, de outra forma, seriam feitas
no disco pai, pela máquina virtual. Eles também são usados para gravar
checkpoints (snapshots) de uma máquina virtual no Hyper-V. Um único disco
pai pode ter vários discos filhos associados a ele.
É possível, por exemplo, criar um disco virtual especialmente preparado com
o Windows Server 2016 e, usando o utilitário sysprep dentro da VM, prepará-
lo para ser o disco pai de outros discos filhos, criados a partir de discos
diferenciais.
Quando se executa esta nova VM, ela irá gravar quaisquer alterações que
faria, normalmente, ao disco virtual fixo, ou dinâmico, para o disco
diferencial. Neste cenário, a implantação de novas VMs do Windows Server
2016 torna-se, simplesmente, uma questão de criar novas VMs que usam um
disco diferencial vinculada a este disco pai. Como o sistema operacional já
está instalado, uma VM é criada em questão de segundos. Mas, cuidado! A
perda ou corrupção do disco pai comprometerá todas as máquinas virtuais
com discos diferenciais vinculadas a ela.
Já deu para notar que há uma economia muito grande de espaço de
armazenamento. Em um modelo tradicional, uma VM com Windows Server
2016, que tenha como base um único VHD de 12 GB de tamanho fixo, cinco
máquinas virtuais consumiriam 60 GB. Usando o disco diferencial, elas
teriam discos diferenciais menores. Mas a recomendação é que não se adote
este modelo para servidores em produção, devido à perda de desempenho
gerado pelo compartilhamento do disco pai. Além disso, é maior o risco de
perder inúmeras máquinas virtuais, caso o disco pai seja comprometido.
Use discos diferenciais para servidores somente em laboratório, ou ambientes
de testes. Entretanto, já foi verificado o uso de discos diferenciais para
projetos de desktops virtuais (VDI) com Windows cliente no Windows 7 e
Windows 10. Nestes casos, os dados do usuário eram móveis e não se
encontravam na VM, permitindo o rápido provisionamento de uma nova VM
para o usuário final.
Alteração em discos virtuais
Para modificar os discos virtuais existentes, pode-se executar as seguintes
tarefas:
Converter um arquivo .vhd para .vhdx
Converter um arquivo .vhdx para .vhd
Alterar um disco fixo para dinâmico
Alterar um disco dinâmico para fixo
Encolher (shrink) ou ampliar (enlarge) um disco virtual
Todas as ações acima podem ser feitas através do assistente de edição de
disco no Hyper-V Manager, ou usando o cmdlet Convert-VHD do Windows
PowerShell. Só é possível realizar conversões de um formato para outro, e de
um tipo para outro, enquanto a máquina virtual está desligada.
O tamanho do disco virtual pode ser redimensionado enquanto a VM está
sendo executada, nas seguintes condições:
O host de Hyper-V deve estar executando o Windows Server 2016 ou
2012 R2.
O disco virtual deve estar no formato .vhdx.
O disco virtual deve estar anexado à uma controladora SCSI.
Uma atenção especial para alguns parâmetros do comando Optimize-VHD:
 
Mode Full. Busca todos os blocos com zero e recupera blocos não
utilizados dentro do VHDX. Importante notar que se trata de um arquivo
VHDX de expansão dinâmica.
 
Mode Quick. Caso não queira passar pelo processo completo, pode-se
utilizar este parâmetro para recuperar os blocos não utilizados, mas sem
buscar blocos com zeros.
 
Mode Retrim. Este parâmetro não redefine os blocos zerados, nem 
reivindica quaisquer blocos não utilizados.
O maior problema desses três primeiros parâmetros é que eles exigem que
o disco rígido virtual seja montado somente como leitura. Caso isto não
seja desejável, temos duas outras opções:
Mode Pretrimmed. Executa as mesmas tarefas do modo Quick,
basicamente recuperando os blocos não utilizados, mas sem rastrear os
blocos zeros.
 
Mode Prezeroed. Também funciona de forma semelhante ao Quick, ,mas
não exige que o VHD seja montado somente como leitura. Porém, como o
Pretrimmed é menos eficaz do que o Modo Full ou Quick, o maior
benefício dessa forma particular de compactação de disco é sua utilidade
para lidar com VHDs que contém sistemas de arquivos diferentes de
NTFS.
Disco de Passagem
Os discos de passagem ( pass through disks ), também conhecidos como
discos diretamente conectados, permitem um acesso direto na VM ao
armazenamento físico, ou a um volume de armazenamento, ao invés de um
disco virtual (VHD ou VHDX) que resida no armazenamento.
Por exemplo, utiliza-se o Hyper-V para conectar uma VM a um disco virtual
no formato .vhd ou . vhdx, hospedado em um volume formatado com NTFS
ou ReFS. Com o disco de passagem, a VM, acessa o disco diretamente e não
há o envolvimento do disco virtual.
Estes discos permitem que as VMs acessem volumes maiores do que os
usuais ao utilizar os discos virtuais. Em versões anteriores do Hyper-V,
como a disponível no Windows Server 2008, os discos de passagem
proporcionavam vantagens de desempenho, quando comparados aos discos
vhd. A necessidade deste tipo de disco diminuiu com a disponibilidade de
discos no formato. VHDX, que permitem a criação de volumes muito
maiores.
Os discos de passagem podem ser diretamente conectados ao host de
virtualização, ou podem ser discos Fibre Channel ou iSCSI. Para criar uma
VM com disco de passagem, é necessário garantir que ele esteja offline no
host. O servidor físico e a VM não podem iniciar o mesmo disco
simultaneamente, para evitar o risco de corrupção.
Caso não haja disponibilidade de disco físico real pode-se criar um disco
virtual, montá-lo no Windows Server e deixá-lo offline,. Isso permitirá a
configuração de uma VM com disco de passagem. Para tanto, execute o
seguinte comando no servidor host:
New-VHD -Path C:\VHD\Passthru.vhdx -Dynamic -SizeBytes
60GB | Mount-VHD -Passthru | Initialize-Disk -Passthru | set-
disk -isoffline $true
 
Para adicionar um disco de passagem usando o Windows PowerShell,
obtenha, primeiro, as propriedades do disco que se deseja adicionar, usando o
cmdlet Get-Disk.Em seguida, canalize (usando o pipeline ) o resultado para
o cmdlet Add-VMHardDiskDrive.
Get-Disk 1 | Add-VMHardDiskDrive -VMName VM
 
FIGURA 03-06. Disco de passagem (Passthru Disk)
Pontos de Restauração
Os pontos de restauração, ou checkpoints, representam o estado de uma
máquina virtual em um determinado momento. Eles podem ser criados
quando a VM está em execução ou quando está desligada. Quando se cria um
checkpoint em uma VM em execução, o estado de memória da VM também é
armazenado neste ponto. Na prática, quando se cria um checkpoint, cria-se
um arquivo .avhd ou .avhdx (dependendo do formato dos discos virtuais
sendo usados na VM)
O Windows Server 2016 Hyper-V suporta dois tipos de checkpoints:
Ponto de restauração padrão. O standard checkpoint funciona da mesma
maneira que o snapshot de versões anteriores do Hyper-V. Ele captura o
estado, os dados e a configuração de hardware de uma máquina virtual e são
projetados para cenários de desenvolvimento e teste. Não são recomendados
ou suportados para cargas de trabalho em produção.
Ponto de restauração em produção. O production checkpoint é novo para o
Hyper-V 2016. Usa tecnologia de backup dentro da máquina virtual, em
oposição à tecnologia de estado salvo, usada no checkpoint standard. Este
checkpoint é totalmente suportado pela Microsoft e pode ser usado com
cargas de trabalho de produção.
FIGURA 03-07. Checkpoint de uma máquina virtual
É possível alternar entre checkpoints padrão e de produção editando as
propriedades de uma VM e criando pontos de restauração pelo PowerShell,
com o cmdlet Checkpoint-VM. Seguem abaixo os cmdlets relacionados ao
checkpoint do Windows Server 2016:
Comandos do
PowerShell
Descrição
Checkpoint-VM Cria um ponto de restauração
Export-VMSnapshot Permite exportar o estado de uma
VM de um host Hyper-V para outro.
Restore-VMSnapshot Reverte um ponto de restauração.
Get-VMSnapshot Lista os checkpoints existentes
Rename-VMSnapshot Permite renomear o checkpoint para
nomes mais amigáveis, de forma a
facilitar a leitura e compreensão sobre
o motivo que levou a criação deste
ponto de restauração
Remove-VMSnapshot Exclui o checkpoint de uma VM. Se
o ponto de restauração for parte de
uma cadeia, mas não a última, as
mudanças são mescladas.
 
Os checkpoints não substituem backups, e são quase sempre armazenados no
mesmo volume que os discos virtuais originais, de modo que uma falha deste
volume resultará em perda de todos os arquivos de armazenamento da VM.
Nota
Se um arquivo da cadeia de checkpoints for excluído ou estiver
corrompido, este ponto de restauração, e todos os outros
subsequentes, serão perdidos. Já os discos anteriores na cadeia
do ponto de restauração permanecerão inalterados. O Hyper-V
suporta um máximo de 50 pontos de restauração por VM.
 
Adaptador Virtual para Rede de Fibra Óptica
O Virtual Fibre Channel permite que se faça conexões diretas entre as
Logical Unit Number (LUNs) criadas na armazenamento e a máquina virtual,
sem necessidade de criar discos virtuais. O VFC é suportado no Hyper-V
2016, contanto que os seguintes critérios sejam atendidos:
O computador host físico do Hyper-V deve ter um adaptador HBA (Host Bus
Adapter) com driver que suporte um VFC. O switch SAN (os mais
conhecidos são Cisco e Brocade) deve ter o NPIV (N_Port ID Virtualization)
habilitado nas portas.
 
A máquina virtual deve executar uma versão suportada.
As LUNs virtuais do VFC não podem ser usadas para iniciar máquinas
virtuais.
As máquinas virtuais no Hyper-V suportam até quatro adaptadores
virtuais de fibra ótica, cada um dos quais pode ser associado a uma rede
de SAN.
Antes de usar um adaptador VFC, deve-se criar, pelo menos, um switch
virtual SAN no host Hyper-V.
FIGURA 03-08. Virtual SAN Manager
Também é possível mover máquinas virtuais com adaptadores VFC entre
hosts de Hyper-V, mas se faz necessária uma configuração especial no
Switch SAN. Para tanto, o administrador da rede SAN deverá entregar os
discos para os dois endereços WWN que o Hyper-V designa para cada
máquina virtual: Address Set A e Address Set B.
Switches Virtuais
Os switches virtuais do Hyper-V, denominadas, em versões anteriores, de
redes virtuais representam a conexão de rede à qual o adaptador de rede de
uma máquina virtual pode se conectar. Existem três tipos de switches
virtuais.
Externo
O switch externo se conecta a um adaptador de rede física ou sem fio. Apenas
um switch virtual pode ser mapeado para um adaptador de rede física ou sem
fio específico, ou para um NIC Team. Por exemplo, se um host físico de
Hyper-V tivesse quatro adaptadores de rede físicos configurados com dois
NIC Teams (duas interfaces em cada NIC Team), poderia se configurar dois
virtual switch externos.
Se um host de Hyper-V apresentar três adaptadores físicos de rede que não
participem de nenhum NIC Team, pode-se configurar três switches externos
virtuais. Quaisquer máquinas virtuais conectadas ao mesmo switch externo
podem se comunicar entre si, da mesma forma como acontece com qualquer
host externo conectado à rede a qual o adaptador mapeado para o switch
físico externo esteja conectado.
Quando se cria um switch externo, um adaptador de rede virtual é criado no
host de virtualização, a menos que se desmarque a opção que permite ao
sistema operacional de gerenciamento compartilhar o adaptador de rede. Ao
desmarcar esta opção, o host de virtualização não poderá se comunicar
através do adaptador de rede associado ao switch externo.
New-VMSwitch -ComputerName HVServer -Name ExternalSwitch -
SwitchType External
 
Interno
Um switch interno permite a comunicação entre a VM e o host de
virtualização que a hospeda. Todas as VMs conectadas ao mesmo switch
podem se comunicar entre si e com o host de virtualização. Por exemplo,
pode-se iniciar, com sucesso, uma conexão RDP do host para uma VM
apropriadamente configurada, ou usar o cmdlet Test-NetConnection do
Windows PowerShell para obter uma resposta de uma VM conectada a uma
conexão de rede interna.
Máquinas virtuais conectadas a um switch interno não conseguem se
comunicar com máquinas físicas, dispositivos ou qualquer outro dispositivo
na rede local.
New-VMSwitch -ComputerName HVServer -Name InternalSwitch -
SwitchType Internal
 
Privado
 
Máquinas virtuais conectadas ao mesmo switch privado, no mesmo host de
virtualização, podem se comunicar entre si, mas não conseguem se
comunicar diretamente com o host. Os switches privados só permitem
comunicação entre VMs no mesmo host. Por exemplo, VM1 e VM2 estão
conectadas ao switch privado p_switch no servidor HOST1, e a VM3 está
conectada ao switch privado de mesmo nome p_switch, mas no servidor
HOST2. Neste caso, a VM1 e a VM2 poderão falar entre si, mas não poderão
falar com o HOST1, o HOST2 e a VM3. Já a VM3 não poderá falar com
nenhuma outra VM ou HOST.
 
New-VMSwitch -ComputerName HVServer -Name
PrivateSwitch -SwitchType Private
 
FIGURA 03-09. Virtual Switch Manager
Adaptador de Rede Virtual
Máquinas virtuais de geração 1 suportam dois tipos de adaptadores de rede
virtuais:
Sintético (Synthetic)
Legado (Legacy)
Um adaptador de rede sintética usa drivers fornecidos pelos serviços de
integração do sistema operacional. Se um sistema operacional não tiver esses
drivers, ou se os serviços de integração não estiverem disponíveis para este
sistema operacional, o adaptador de rede não funcionará.
Os adaptadores de rede sintéticos só estarão disponíveis quando um sistema
operacional suportado esteja em execução. Isso significa que não é possível
executar uma inicialização PXE de um adaptador de rede sintética se uma
VM geração 2 não está configurada.
Os adaptadores legados imitam um adaptador de rede física, semelhante ao
modelo DEC/Intel 21140 10/100TX 100 MB. Muitos sistemas operacionais,
incluindo aqueles que não suportamos serviços de integração, oferecem
suporte a este adaptador de rede. Isso significa que se pode executar um
sistema operacional em uma VM que não tenha suporte a serviços de
integração, como, por exemplo, uma versão antiga do Linux ou BSD, não
oficialmente suportados para o Hyper-V. Para este caso, será necessário
utilizar um adaptador de rede legado, pois ele, provavelmente, será
reconhecido pelo sistema operacional convidado.
Para instalar uma máquina virtual geração 1 a partir de um servidor WDS
(Windows Deployment Server) disponível em sua rede local, deve-se utilizar
o adaptador herdado para que o boot via PXE funcione. Este adaptador foi
removido das máquinas virtuais geração 2.
Endereço MAC Virtual
Por padrão, as máquinas virtuais que funcionam em hosts de Hyper-V usam
endereços MAC dinâmicos dentro das sequências 00-15-5D-XX-YY-00 e 00-
15-5D-ZZ-WW-FF. Explicarei em detalhes como os valores X e Y são
criados, e porque isto pode gerar um problema de endereço MAC duplicado
entre máquinas virtuais do Hyper-V. As propriedades e a sequência de
endereços MAC podem ser configuradas através do Virtual Switch Manager.
FIGURA 03-10. Faixa de endereços MAC
Quando se implantam sistemas operacionais em hardware físico, pode-se
utilizar dois métodos para garantir que o computador tenha sempre a mesma
configuração de endereço IP. O primeiro método, é atribuir um IP estático,
configurado de forma manual. O segundo, é configurar uma reserva no
DHCP associado ao endereço MAC do adaptador de rede físico.
Nota
A sequência de endereço MAC de um servidor Hyper-V é
construída com base no endereço IPv4 do servidor, no momento
da instalação da função Hyper-V. O terceiro e o quarto octetos
do IPv4 são convertidos de decimal para hexadecimal. Os
endereços, 00-15-5D e o final 00 e FF, são fixos, mas os
endereços 0F e 0C são os números 15 e 12, respectivamente,
tendo em vista que o endereço IP do meu servidor era
192.168.15.12. Essa é a razão pela qual não se deve usar sempre
o mesmo IP para o servidor ao instalar seus servidores Hyper-V.
As máquinas virtuais podem ter endereços MAC duplicados.
 
Isso não funcionará com VMs no Hyper-V, em sua configuração padrão, pois
o endereço MAC poderá mudar se a máquina for desligada e, depois,
religada. Ao invés de configurar um endereço de IP estático, usando o
sistema operacional da VM, é possível configurar um endereço MAC
estático. Isso garantirá que o adaptador de rede virtual de uma VM mantenha
o endereço MAC, ainda que a VM seja reiniciada ou migrada para outro host
Hyper-V.
Para configurar um endereço MAC estático em um adaptador de rede, edite
os recursos avançados do adaptador de rede. Ao inserir um endereço MAC
estático, será necessário selecionar um endereço MAC manualmente.
Recomenda-se não utilizar um endereço dentro da sequência do Hyper-V,
mas sim um diferente, pois os hosts de Hyper-V atuais, na mesma subrede,
não conseguem verificar se o endereço MAC a ser atribuído dinamicamente
já tenha sido atribuído de forma estática.
VLAN
O Hyper-V suporta a marcação de rede VLAN (Virtual Local Area Network),
tanto no adaptador de rede, quanto no switch virtual.
As redes VLAN permitem o isolamento do tráfego para hosts conectados à
mesma rede, criando domínios de transmissão separados (broadcasts
domain). Os switches corporativos de hardware também suportam VLANs,
como forma de particionar o tráfego de rede. Para usar VLANs com o Hyper-
V, o adaptador de rede dos hosts de virtualização também deve suportar as
VLANs. Um ID de VLAN tem 12 bits, o que permite a configuração de até
4.094 Ids de VLAN.
As redes VLAN podem ser configuradas no adaptador de rede virtual,
selecionando a caixa “Enable virtual VLAN identification”, nas propriedades
do adaptador de rede virtual. Agora, para configurar a VLAN no switch
virtual selecione “Enable virtual LAN identification for management
operating system” , nas propriedades do vSwitch.
DHCP Guard
DHCP Guard é uma propriedade de segurança que pode ser habilitada na
interface de rede. Ela recusa os pacotes de máquinas virtuais Windows ou
Linux que se promovem como um servidor DHCP de maneira não
autorizada. Caso pretenda implementar o serviço de DHCP como uma
máquina virtual no Hyper-V , desmarque esta opção:
Set-VMNetworkAdapter -VMName Name -DhcpGuard On/Off
 
Router Guard
Outro recurso avançado de segurança de rede. Quando habilitado, o switch
virtual irá descartar os seguintes pacotes de rede:
ICMPv4 Tipo 5 (Redirect Message)
ICMPv4 Tipo 6 (Router Advertisement)
ICMPv6 Tipo 134 (Router Advertisement)
ICMPv6 Tipo 136 (Redirect Message)
Set-VMVMNetworkAdapter -VMName Name -RouterGuard On/Off
 
Port Mirroring
O espelhamento de portas, também chamado SPAN, é um método usado para
monitorar o tráfego de rede. Com o espelhamento de portas habilitado, ou a
porta de switch expandida, o switch enviará uma cópia de todos os pacotes
que atingem uma porta específica, ou de uma VLAN para outra porta, onde o
pacote poderá ser separado e analisado. Comumente, outra máquina física é
conectada à porta espelhada, enquanto um utilitário de monitoramento de
pacotes, como o Network Monitor ou WireShark, está sendo executado para
analisar o tráfego.
Set-VMVMNetworkAdapter -VMName Name -PortMirroring
Source/Destination/None
 
Connected Standby
Esta funcionalidade se relaciona, exclusivamente, ao Hyper-V do Windows
10, quando instalado em notebook / laptops. Até o Windows 8.0 e 8.1, os
usuários reclamavam que os dispositivos deixavam de agir como laptop e
passavam a agir como um PC quando o Hyper-V era instalado. Assim que a
tampa do notebook era fechada, a máquina não dormia e, se pressionado o
botão para ativá-la, ela saía da hibernação, mas reiniciava, ao invés de
acordar, simplesmente e instantaneamente. Não era ruim, mas tampouco era
uma experiência fluída e perfeita que os usuários de um notebook esperam.
Atualmente, o modo de espera não é desativado quando se instala o Hyper-V
Client no Windows 10. Execute o comando powercfg /a, e observe que a
entrada StandBy (S3) permanecerá ativa.
Discrete Device Assignment
Se estiver acompanhando as novidades do Microsoft Azure, especialmente os
tipos e modelos de máquinas virtuais existentes, deve ter lido sobre o
lançamento das instâncias da série NC e NV, em dezembro de 2016. A
nomenclatura N vem de NVIDIA, máquinas virtuais que não tem uma GPU
virtualizada, mas sim um GPU (placa de vídeo), modelo Tesla K80 ou M60,
entregue diretamente para a máquina virtual, sem passar pelo hypervisor.
Com isso, os drivers reais da placa de vídeo precisam ser instalados como se
estivessem em um servidor físico.
O Discrete Device Assignment permite que se forneça, a uma máquina
virtual, o acesso direto e exclusivo a alguns dispositivos de hardware
compatíveis com a conexão PCIe (PCI Express). O uso deste dispositivo
ignora a pilha de virtualização, o que resulta em acesso mais rápido.
A Microsoft usa o Windows Server 2016 Core com o Hyper-V, no
Datacenter do Microsoft Azure, além do Discrete Device Assignment, para
implementar as máquinas virtuais da série N, para os clientes que necessitam
executar aplicações com alto grau de desempenho de vídeo, tais como
renderização de imagem, aplicações 3D e aplicações compatíveis com
computação de alta performance ( HPC).
O Non-Volatile Memory Express (NVMe) está decolando. Os SSDs
anexados via NVMe podem ser , em muitos casos, mais rápidos do que os
SSDs conectados através de SATA ou SAS. A única opção real para
melhorar o desempenho de disco em uma máquina virtual é passar o
dispositivo físico inteiro para ela.
O Windows Server 2016 permite que os dispositivos NVMe sejam atribuídos
às VMs convidadas. Mas recomendo que estas máquinas virtuais sejam
somente as que estão sob controle da mesma equipe de administração que
gerencia o host e o hypervisor.
Outros dispositivospodem funcionar, quando transmitidos para uma VM
Guest. Já testei algumas controladoras USB3 e RAID e diversas outras.
Muitos funcionarão, mas nenhum deles será suportado, oficialmente, pela
Microsoft. Pelo menos, não até o momento. Considere experimentais estes
dispositivos que não estão conectados ao barramento NVMe.
Não há interface de usuário (GUI) para o gerenciamento do DDA. Toda
administração e configuração são feitas pelo Windows Powershell.
Para obter a lista de todos os dispositivos conectados ao seu computador
físico, execute o seguinte comando:
Get-PnpDevice -PresentOnly
 
Uma lista completa será mostrada. Para saber a quantidade de dispositivos,
execute o comando (Get-PnpDevice -PresentOnly).Count
Por exemplo, no meu notebook Dell Latitude E7270 há 174 dispositivos
conectados.
O objetivo desta prática é atribuir a conexão de Internet para uma VM
Windows 10 ,através da interface de rede sem fio do notebook físico. Pelo
comando abaixo, é possível listar apenas os dispositivos de rede. O
dispositivo físico que se pretende entregar para a máquina virtual é a interface
de rede sem fio Intel (R) Dual Band Wireless-AC 7265.
Get-PnpDevice -PresentOnly | Where-Object {$_.Class -eq
"Net"}
OK Net Microsoft Wi-Fi Direct Virtual
Adapter 
OK Net Microsoft Teredo Tunneling
Adapter 
Error Net Hyper-V Virtual Switch Extension
Adapter 
OK Net Hyper-V Virtual Switch Extension Adapter
#2 
OK Net Bluetooth Device (RFCOMM Protocol
TDI) 
OK Net Microsoft Kernel Debug Network
Adapter 
OK Net Intel(R) Dual Band Wireless-AC
7265 
OK Net Bluetooth Device (Personal Area
Network) 
OK Net Hyper-V Virtual Ethernet
Adapter 
OK Net Intel(R) Ethernet Connection (3) I218-
LM 
Com uma condição a mais, pode-se listar somente o dispositivo. Salve-o em
uma variável.
$pnpdevs = Get-PnpDevice -PresentOnly | Where-Object
{$_.Class -eq "Net"} | Where-Object {$_.FriendlyName -eq
"Intel(R) Dual Band Wireless-AC 7265"}
Agora, desabilite e desmonte o dispositivo do computador físico. Para
desabilitá-lo, execute, primeiro, o comando Disable-PnpDevice.
Disable-PnpDevice -InstanceId $pnpdevs.InstanceId -Confirm:$false
 
Depois, com o comando Get-PnpDeviceProperty, localize o caminho onde o
dispositivo está instalado.
 
$locationpath = ($pnpdevs | get-pnpdeviceproperty
DEVPKEY_Device_LocationPaths).data[0]
 
O próximo passo é desmontá-lo, o que fará o dispositivo desaparecer do
Device Manager.
 
Dismount-VMHostAssignableDevice -LocationPath $locationpath -Force
 
Todos os dispositivos desmontados e disponíveis para serem entregues às
máquinas virtuais podem ser listados pelo comando Get-
VMHostAssignableDevice
Get-VMHostAssignableDevice
InstanceID:
PCIP\VEN_8086&DEV_095A&SUBSYS_54108086&REV_59\A402B9FFFF02596300
LocationPath: PCIROOT (0) #PCI(1C03) #PCI (0000)
CimSession: CimSession:
ComputerName: MSFTGB
IsDeleted: False
Antes de atribuir um dispositivo à máquina virtual, é preciso configurar a
opção AutomaticStopAction para Shutdown. Essa ação deve ocorrer na VM
quando o servidor físico for desligado. Como um dispositivo físico real está
sendo entregue para a VM, estas máquinas deixam de ter a opção de
Snapshot e Save State. Desligue a VM e faça essa alteração com o comando
Set-VM
Set-VM -VMName Name -AutomaticStopAction Shutdown
Finalmente, conecte o adaptador de rede Wi-Fi diretamente à máquina virtual
do Windows 10 Enterprise.
Com a máquina virtual desligada, execute o comando Add-
VMAssignableDevice
Add-VMAssignableDevice -LocationPath "$locationpath" -VMName
Name
Ligue-a, abra a opção Network and Sharing Center e certifique-se de que há
uma nova interface de rede sem fio. Conecte-a ao seu Access Point Wi-Fi.
Medição de Recursos
O Hyper-V permite mensurar o consumo de recurso e, no caso de um
provedor de nuvem, cobrar por eles, assim como acontece no Microsoft
Azure, Amazon AWS e Google Cloud, entre outras soluções de nuvem
pública existente. Porém, este não é o melhor método de verificar a utilização
de recursos em uma máquina virtual. De qualquer forma, veremos o que ela
nos oferece. Com o Powershell, é possivel habilitar a medição de recurso e,
em seguida, avaliar alguns valores. Habilite o Resource Metering através do
comando:
 
Enable-VMResourceMetering -ComputerName HVName -VMName Name
 
Aguarde um tempo até que a máquina virtual possa propagar o consumo e a
utilização de seus recursos. Em seguida, colete os valores com o comando:
 
Measure-VM -ComputerName HVName -VMName Name | FL
 
Você terá a média de utilização de CPU em MHZ, a Memória em MB, Total
Disk em MB e a utilização de rede para tráfegos de entrada e saída em MB/s,
além do número de IOPS por disco, o tempo de coleta, entre outros valores.
 
Para obter o detalhamento das métricas de discos, execute o comando:
 
Measure-VM -ComputerName HVName -VMName Name | select -expand
harddiskmetrics
 
Para detalhar todas métricas de tráfego de rede, execute:
 
Measure-VM -ComputerName HVName -VMName Name | select -expand
networkmeteredtrafficreport
 
Proteção de Recursos
O Host Resource Protection (HRP) ajuda a evitar que uma máquina virtual
use recursos além do seu limite, buscando níveis excessivos de atividade. Isso
pode impedir que a atividade excessiva de uma máquina virtual venha a
degradar o desempenho do host ou de outras máquinas virtuais. Quando o
monitoramento detecta uma máquina virtual com atividade excessiva, esta
máquina recebe menos recursos.
Set-VMProcessor -VMName Name -EnableHostResourceProtection $true
 
Gerenciamento de Adaptador de Rede Virtual
Hoje pode-se adicionar ou remover adaptadores de rede na máquina virtual
enquanto ela estiver em execução, sem gerar interrupções. Isto funciona
apenas nas máquinas virtuais de geração 2, para as distribuições mais
recentes dos sistemas operacionais Windows Server e Linux . O máximo de
08 vNICs é permitido.
Nas propriedades da máquina virtual , ou através do PowerShell, adicione
Network Adapter.
Add-VMNetworkAdapter -ComputerName HVServer -VMName Name -
SwitchName Switch -Name Management -DeviceNaming On
 
Gerenciamento de Memória
Também, é possível adicionar ou remover memória enquanto as máquinas
virtuais, tanto as de geração 1 quanto as de geração 2, estão em execução, no
Windows Server 2016 ou Windows 10.
Para listar a quantidade de memória, e confirmar se ela está habilitada, use o
comando Get-VMMemory
Get-VMMemory -ComputerName HVName -VMName Name
Para ver como isto funciona, primeiro abra o performance monitor
(perfmon.msc) ou, através do PowerShell dentro da máquina virtual,
monitore a quantidade de memória disponível. Logo após, aumente a
quantidade de memória e veja o número aumentar imediatamente.
Abra o PowerShell, dentro da máquina virtual no Hyper-V, e execute:
C:\while ($true) {get-counter “\memory\available mbytes”; start-sleep -s
.5}
A cada meio segundo, o comando acima listará na tela a quantidade de
memória disponível. Depois, adicione mais memória pelo comando:
Set-VMMemory -ComputerName HVName -VMName Name -
StartupBytes 4096MB
Veja o valor de mbytes disponíveis aumentar. Reduza a quantidade de
memória e veja o valor diminuir.
Boot Seguro com UEFI
Máquinas virtuais geração 2 com sistemas operacionais Windows Server
2012R2, 2016, Linux Ubuntu 14.04, Suse Linux Enterprise 12, Red Hat
Enterprise 7.0, e CentoOS 7.0 ou superior estão habilitados para Secure Boot
no Hyper-V 2016. A função UEFI é responsável pelo boot seguro e garante
que cada componente será carregado, assinado e validado digitalmente, o que
é feito por um chip TPM UEFI (firmware). O sistema operacional Windows
Server é assinado pela Microsoft, no caminho C:\Windows\boot\EFI. Nesta
pasta, encontram-se arquivos com a extensão. EFI. Vá até as propriedades
destes arquivos e clique na aba Digital Signature, onde se constata que o
“assinador” é a Microsoft, com as especificações técnicas de criptografia,
como SHA256, como algoritmo Digest.
FIGURA 03-11. Boot seguro
Para confirmar se o boot seguro está configurado, use o comando Confirm-
SecureBootUEFI dentro da máquina virtual. Se ele estiver habilitado, o
resultado deve ser True.
Nota
Antes de ligar a máquina virtual pela primeira vez e, claro, antes
mesmo de instalá-la, configure a VM para usar a Microsoft UEFI
Certificate Authority. Isto pode ser feito pela interface gráfica ou
pelo PowerShell.
 
Set-VMFirmware VMName -SecureBootTemplate
MicrosoftUEFICertificateAuthority
 
Disco Virtual Compartilhado
Os discos virtuais compartilhados já existem no Hyper-V 2012 R2. Mas
novas funcionalidades foram adicionadas no Hyper-V 2016. Atualmente,
pode-se redimensionar os discos virtuais compartilhados em um Guest
Failover Cluster (nome dado quando o Failover Cluster é entre máquinas
virtuais), sem tempo de inatividade. Os discos rígidos virtuais podem crescer
ou encolher enquanto a máquina virtual está online.
O Guest Cluster formado por discos VHDX compartilhados, agora também
pode ser replicado pelo Hyper-V Réplica para outros servidores de Hyper-V,
para fins de recuperação de desastres. Hoje, os discos compartilhados têm
uma nova extensão .VHDS
Versões de Configuração
Com a chegada do Hyper-V 2016, um novo método de versionamento de
máquinas virtuais foi introduzido, permitindo o controle e a compatibilidade
de migração de clusters Hyper-V.
Toda máquina virtual criada no Hyper-V 2012 R2 tem a versão 5.0, que
também é compatível com o Hyper-V 2016.
O Hyper-V 2016 trabalha com VM versão 8.0 que, além de permitir
checkpoints de produção, impede que máquinas virtuais com essa versão
possam retornar para versões anteriores.
Quando se atualiza a versão 5.0 da VM para a 8.0, os arquivos da máquina
virtual são convertidos para novos formatos:
.XML para .VMCX
.BIN e .VSV para .VMRS
 
Para atualizar a versão pela console do Hyper-V Manager. ou pelo
PowerShell. a máquina virtual deve estar desligada. Cuidado para não
confundir versão da VM com a geração da VM.
Update-VMVersion -VM VMName
 
Simulado
Questão 01
Você foi solicitado a criar um switch virtual do Hyper-V que conecte várias
máquinas virtuais em um host entre si. O switch virtual também deve permitir
a conectividade entre as VMs e o host. Qual tipo de switch virtual deve-se
criar?
A. Internal
B. External
C. Private
D. NAT
Questão 02
Qual dos seguintes requisitos de hardware para o Hyper-V pode ser
verificado, em um servidor físico, com o comando systeminfo?
A. Data Execution Prevention
B. Instrução de Virtualização no processador (firmware)
C. Second Address Translation
D. VM Monitor Me Extensions
E. Todas as alternativas acima
Questão 03
Você criou um switch virtual com suporte ao NAT e teve que executar um
cmdlet apropriado para especificar um prefixo de endereço de rede interno.
No entanto, as máquinas virtuais que estão conectadas ao switch NAT ainda
não podem acessar recursos externos. Qual dos seguintes cmdlets do
Powershell deve ser executado para completar esta configuração?
A. Set-VMSwitch
B. New-NetIPAddress
C. New-NetNat
D. Add-NetNatStaticMapping
Questão 04
Você está tentando inicializar uma máquina virtual geração 1 via PXE para a
instalação de um sistema operacional. Qual tipo de vNIC deve-se configurar
na VM para este propósito?
A. Standard Network Adapter
B. Legacy Network Adapter
C. Synthetic Network Adapter
D. UEFI Network Adapter
Questão 05
Você está no processo de reconfiguração dos switches virtuais em um host
Hyper-V. Enquanto está aplicando as mudanças, você perde acesso ao host.
Qual das seguintes alterações de configuração é a fonte provável do
problema?
A. Todos os switches tem habilitado “Allow management operating system
to share this network adapter”
B. Todos os switches tem habilitado “Enable virtual LAN identification for
management operating system”
C. Todos os switches tem desabilitado “Allow management operating system
to share this network adapter”
D. Todos os switches tem desabilitado “Enable virtual LAN identification
for management operating system”
Questão 06
Qual das seguintes frases traz uma boa razão para utilizar uma máquina
virtual geração 1?
A. Executar o Windows 8 x86 como guest
B. O VHD da máquina virtual não é compatível com boot UEFI
C. O boot da máquina virtual precisa ser mais rápido
D. A VM não vai ser migrada para o Azure mais tarde
Questão 07
Enquanto cria uma VM usando o Hyper-V Manager, você tenta anexar a
unidade de DVD da VM a um arquivo ISO, hospedado em um
compartilhamento de rede remoto, aparece a seguinte mensagem de erro:
 “Failed to add device Virtual CD/DVD Disk. User Account does not have
permission to open attachement”
Qual é a fonte mais provável dessa mensagem de erro?
A. Falta de configuração de permissão NTFS e SHARE no Hyper-V host
B. Falta de configuração de permissão NTFS e SHARE no File Server
C. Ausência do Kerberos Constrained Delegation na conta de computador do
Hyper-V host no Active Directory
D. Ausência do Kerberos Constrained Delegation na conta de computador do
File Server no Active Directory
Questão 08
Você precisa determinar se o pacote Microsoft-Hyper-V-Common-Drivers
foi instalado na criação de uma imagem, em um host Hyper-V. Qual cmdlet
do Powershell será usado?
A. Get-WindowsRole
B. Get-WindowsFeature
C. Get-WindowsOptionalFeature
D. Get-WindowsPackage
Questão 09
Para as VMs da geração 2, hospedadas no Hyper-V do Windows Server
2016, os checkpoints de produção são ________________ por padrão, e os
checkpoints de verificação _______________ criados, por padrão, se não for
possível criar um checkpoint de produção.
A. Desabilitados; não serão
B. Habilitados; serão
C. Habilitados; não serão
D. Desabilitados; serão
Questão 10
Qual é a extensão do arquivo associado a um VHD compartilhado?
A. XML
B. VHDX
C. VHD
D. VHDS
Questão 11
É preciso criar um switch virtual que restringe a comunicação somente entre
as máquinas virtuais no mesmo host Hyper-V. Qual tipo você cria?
A. External
B. Private
C. Internal
D. NAT
Questão 12
Qual, dentre as seguintes tecnologias de agrupamento de NIC (NIC
Teaming), ficou praticamente inalterada entre o Windows Server 2012 R2 e
2016?
A. Standalone LBFO Teaming
B. Full Microsoft SDN stack
C. Switch Embedded Teaming (SET)
D. 3rd Party Teaming
Questão 13
Após criar um NIC Teaming com duas placas de redes físicas em um host
Hyper-V, você está tentando criar um virtual switch associado a esta nova
NIC Teaming. Qual das interfaces de rede abaixo deve ser selecionada?
A. Intel (R) 82574L Gigabit Network Connection
B. Intel (R) 82574L Gigabit Network Connection #2
C. Intel (R) 82574L Gigabit Network Connection #3
D. Microsoft Network Adapter Multiplexor Driver
Questão 14
Duas placas de rede físicas com suporte ao SR-IOV foram instaladas em um
host Hyper-V. Agora, é necessário usar essas interfaces para oferecer alta
disponibilidade. Para isso, cria-se _____________ switch (es) físico (s) na
mesma subrede e _____________ switch (es) virtual (is) no Hyper-V
Manager.
A. Um; um
B. Um; dois
C. Dois; dois
D. Dois; umQuestão 15
Você recebeu novos requisitos de segurança, que exigem controles granulares
e por ação para cada administrador do Hyper-V. Em seu ambiente, o Hyper-
V está sendo executado no topo do Windows Server 2016. Usando qual
ferramenta, pode-se implementar esses novos requisitos de segurança?
A. PowerShell JEA
B. Hyper-V Manager
C. GPO
D. Authorization Manager (AzMan)
Questão 16
Você quer habilitar o nested virtualization em uma máquina virtual Windows
Server 2016 Datacenter no Hyper-V. Qual o cmdlet do PowerShell servirá
para habilitar essa configuração?
A. Set-VMNestingExtensing
B. Set-VMProcessorExtension
C. Set-VMProcessor
D. Set-VMExtension
Questão 17
Em qual sistema operacional guest o Enhanced Session Mode está habilitado
por padrão?
A. Windows Server 2016
B. Windows 10
C. Windows Server 2012
D. Windows Server 2012 R2
Questão 18
Você está tentando criar uma máquina virtual, com a versão CentOS do
Linux, e conecta a unidade de DVD ao arquivo ISSO, que contém os
arquivos do sistema operacional. Em seguida, inicia a VM, mas ao invés de
carregar a inicialização de instalação, recebe a seguinte mensagem de boot:
“PXE Networking Boot using IPv4 (ESC to cancel), Performing DHCP
Negotiation”
Qual configuração da VM deve ser ajustada para corrigir o problema?
A. Desabilitar o Dynamic Memory
B. Desabilitar o Secure Boot
C. Desabilitar o Integration Services
D. Recriar a VM com um disco de tamanho fixo
Questão 19
Para anexar um disco de passagem ( pass through disk) em uma máquina
virtual, o disco _____________ ser inicializado e ______________ estar em
estado off-line.
A. Não deve; não deve
B. Não deve; deve
C. Deve; deve
D. Deve; não deve
Questão 20
Qual tecnologia associada aos checkpoints de produção do Hyper-V deve ser
usada para garantir a integridade dos dados?
A. Host Resource Protection
B. VM Memory Mapping
C. Volume Shadow Copy
D. Live Migration
Respostas
01-
A
02-E 03-B 04-B 05-
C
06- 07-
C
08-
C
09-B 10-
D
11-B 12-
A
13-
D
14-
C
15-
A
16-
C
17-B 18-B 19-
C
20-
C
 
CAPÍTULO 04 - Implantar
Windows Containers
Estudar e entender os serviços de container (Container Services) pode ser
desafiador, principalmente para administradores de servidores Windows
Server. Falarei tudo sobre container: a origem, os conceitos, as principais
diferenças entre um container e uma máquina virtual, além de dar instruções
quanto a instalação, configuração e os principais comandos para ter seu
primeiro aplicativo rodando em um container.
dotCloud, é o nome da empresa que deu início à revolução na automação de
entrega de código ágil por meio de containers. Fundada por Solomon Hykes,
em 2010, a dotCloud é uma empresa europeia sediada em Berlim, na
Alemanha, que costumava alugar servidores na Amazon Web Services, no
modelo de Infraestrutura como Serviço. E através da criação de um serviço
próprio, que os engenheiros de software chamaram de Docker Engine,
permitiu-se o particionamento destes servidores em pequenos pedaços (micro
serviços), ou “lotes”, vendidos a seus clientes para o armazenamento de
aplicações desenvolvidas especialmente em Java, PHP, Python e Ruby.
Em setembro de 2013, a dotCloud fez uma aliança com a Red Hat e, dois
meses depois, a empresa foi renomeada para Docker Inc. O nome escolhido
era o mesmo da ferramenta que ela havia desenvolvido, e que despertou o
interesse e a atenção dos investidores.
Neste mesmo período, uma empresa chamada Orchard (pomar, em
português), que contava com dois funcionários somente, construiu um serviço
em nuvem chamado FIG (a fruta figo, em português) para executar
aplicativos embalados dentro dos containers da Docker, e que podiam ser
transferidos facilmente de um centro de dados para outro. Os containers
Docker são considerados como uma solução alternativa, ou até mesmo
substitutiva, para as máquinas virtuais que a VMWare popularizou na virada
do século.
Em julho de 2014, a Docker comprou a Orchard e incorporou seus dois
fundadores ao quadro de funcionários. Junto com eles, veio o conhecimento
sobre o desenvolvimento do FIG, escrito em Python. Hoje, a Docker Inc está
sediada em São Francisco, Califórnia, no coração do Vale do Silício, e
mantêm uma conferência anual muito disputada, chamada Docker
Conference (dockercon.com).
No final de 2014, a Microsoft e a Docker Inc anunciaram uma parceria
estratégica, que oferecia suporte ao Docker para as novas tecnologias de
containers que embarcariam nas futuras versões do Windows Server, o que
realmente se concretizou com o Windows Server 2016. Os desenvolvedores e
empresas que desejam criar seus aplicativos em containers usando Docker,
poderão fazê-lo via Windows Server ou Linux.
Para um melhor aproveitamento deste capítulo, recomendo, fortemente, que
você tenha uma máquina virtual com o Windows Server 2016 versão
Datacenter, pois isto te ajudará a fixar o entendimento de cada comando do
Docker Engine. Caso possua uma assinatura do Microsoft Azure, também
poderá usar o novíssimo build 1709, do recém lançado Windows Server
2016, com Containers. Esta imagem já vem com a função do Container e
Docker Engine instaladas.
O build 1709 está disponível somente com o Windows Server Core, exigindo
conhecimento para gerenciá-lo através de linha de comando.
Preferencialmente, use o build 1709, pois, além trazer melhorias, vários
problemas conhecidos foram corrigidos nessa versão.
Se você sempre foi um administrador Windows Server, talvez este assunto
seja um tanto novo. Os containers já estão no Linux há algum tempo,
desenvolvidos pelo Projeto LXC (Linux Container), mas são novos para o
Windows, estando presentes no Windows Server 2016 e Windows 10. Em
agosto de 2008, o projeto Open Source LXC surgiu como uma alternativa a já
consolidada tecnologia chroot. Chroot é uma chamada de sistema
operacional que permite mudar de diretório raiz e entre processos. Usando
este recurso pode-se, por exemplo, manter uma distribuição Linux
secundária, instalada em uma pasta que ocupa o lugar de uma partição
tradicional, e executar programas desse lugar sem perda de desempenho
significativa. O container derivado do projeto LXC é um meio-termo entre
uma máquina virtual e o chroot, o que possibilita a criação de um ambiente
mais próximo de uma instalação Linux ou Windows, sem a necessidade de
um kernel separado. Recomendo a leitura do projeto LXC, em
linuxcontainers.org.
O chroot torna possível encapsular um sistema inteiro dentro de uma
estrutura de diretório, fazendo com que o sistema não acesse nada além do
que esteja definido dentro dessa arquitetura. Isso é muito útil, pois elimina a
sobrecarga de uma máquina virtual inteira para execução de um simples
processo ou serviço.
Mas a principal diferença entre um container e uma máquina virtual, é que o
container compartilha o kernel do seu host hospedeiro. Ou seja, como o
kernel já está iniciado, a criação de um container envolve um processo
iniciado como um serviço. Criar um container é extremamente rápido, tendo
em vista que todo novo container é gerado a partir de uma imagem base.
Devido a estas características, ele está se tornando a tecnologia chave para
desenvolvedores de software que adotam práticas ágeis, como o Scrum e o
DevOps, resultados do alinhamento entre o time de desenvolvimento e
operações para processos, ferramentas e responsabilidades.
A imagem abaixo ilustra as diferenças entre as arquiteturas de máquinas
virtuais e containers. Os containers não exigem um hypervisor (com exceção
dos containers Hyper-V), e podem ser executados em máquinas físicas,
virtuais ou como serviços na nuvem. Ainda, são portáteis e infinitamente
menores do que uma máquina virtual tradicional.
Eles, também, permitem que os desenvolvedores agrupem uma aplicação, e
todas suas dependências, em uma única imagem. Essa imagem pode ser
facilmenteexportada, importada e implantada em diferentes hosts de
containers, desde o Nano Server e Server Core até o Microsoft Azure, no
modelo IaaS ou SaaS.
Como as dependências são agrupadas com um aplicativo dentro de um
container, as operações de TI podem ser implantadas em um container, sem a
preocupação de saber se um pacote de software obrigatório já está instalado,
ou se uma configuração necessária já foi concluída. Uma vez que o container
fornece um ambiente isolado, uma falha ocorrida dentro desse container só
afetará a ele mesmo, e não a outros aplicativos hospedados em diferentes
containers.
Conceitos
Para reforçar a sua base de conhecimento sobre este assunto, veremos, agora,
algumas terminologias envolvendo containers.
Container Image. Uma imagem de container é um modelo, a partir do
qual gera-se um container. Os containers não são gerados a partir de
arquivos de mídia no formato ISO, assim como as máquinas virtuais. Em
geral, há dois tipos de imagem: uma básica, do sistema operacional, e uma
específica, criada para cada aplicação. Abaixo, explicarei os dois tipos em
detalhes.
Container Base OS Image. Esta é uma imagem do sistema operacional
Windows Server, sobre a qual outras imagens de containers serão criadas.
Ela vem somente nas versões Server Core e Nano, por serem menores. A
Microsoft publica online, em um repositório oficial, imagens base para
containers . É possível baixar uma imagem base e criar seu container a
partir dela. A Microsoft ainda atualiza as imagens do SO base, à medida
que as atualizações de software são lançadas.
Application Image. Estes containers armazenam as alterações feitas em
uma imagem de sistema operacional da base de um container, ou outra
imagem de container. Por exemplo, pode-se iniciar um novo container a
partir de uma imagem do Windows Server Core já existente. Também é
possível fazer modificações, como instalar o framework Java, e depois
salvar estas modificações como uma nova imagem de container. Esta nova
imagem armazenará somente as alterações feitas e, portanto, será muito
menor do que a imagem principal.
Sandbox. O Sandbox é o ambiente onde se faz modificações em uma
imagem de container existente, antes de confirmá-la para criar uma
imagem. Se estas alterações não forem confirmadas, elas serão perdidas
quando o container for removido.
Image Dependency. É uma nova imagem de container fora do qual ela
foi criada, como uma dependência. Por exemplo, cria-se uma imagem de
container denominada WebServer-1.0 com a função IIS instalada na
imagem do SO base. Esta imagem do SO base é uma dependência da
imagem WebServer-1.0. Ela só poderá ser iniciada enquanto imagem de
SO base, se uma dependência estiver presente. Um container pode
depender de mais do que uma imagem base, e formar uma cadeia de
dependências.
Container Host. Um container host é um computador, seja ele físico,
virtual, ou mesmo uma plataforma baseada em nuvem, como soluções de
Platform as a Service (PaaS), que executa containers.
Container Registries. Os registros de containers são repositórios onde os
containers ficam armazenados, e de onde podem ser transferidos para
utilização. O exemplo mais conhecido é o Git Hub (www.github.com).
Recomendo, fortemente, que você crie sua conta no GitHub hoje mesmo e
comece a se familiarizar. Na atualidade, a DockerHub (hub.docker.com) é
o principal repositório de containers públicos. Permite-se o uso de um
registro de container privado na rede interna de empresas para sua
distribuição para os hosts de containers, tal como o do Windows Server
2016. Para cada registro, pode haver diferentes repositórios.
 
Nota
Os containers oferecem um ambiente de execução para
aplicações não persistentes e isoladas. Um aplicativo deve ser
executado no container, mas nunca deve armazenar os dados
nele. Os dados do aplicativo devem ser armazenados em um
local separado, como um servidor de banco de dados ou, até
mesmo, um blob storage, no Azure. Os containers são
excelentes para hospedar aplicações sem estado (stateless),
assim como os servidores front-ends balanceados,
especialmente pela possibilidade de iniciar rapidamente novos
containers para lidar com cargas adicionais, quando necessário.
FIGURA 04-01. Diferenças entre uma arquitetura de máquinas virtuais e
containers.
O Windows Server 2016 suporta dois tipos de containers: o Windows Server
Container e o Hyper-V Container. O Windows 10 suporta, somente, o Hyper-
V Container.
Containers do Windows Server
Os containers do Windows Server fornecem um ambiente para execução
isolada de aplicativos. Isso é realizado através do isolamento de processos e
espaço de nomes. Os containers do Windows Server compartilham um kernel
com todos os outros containers sendo executados no mesmo host. É por isso
que não se pode executar containers do Windows Server 2016 diretamente no
Windows 10. Os kernels são diferentes.
Containers do Hyper-V
Um container do Hyper-V é um container especial, altamente otimizado, com
o Hyper-V habilitado, que fornece um ambiente para execução de aplicativos
de maneira isolada. Os containers do Hyper-V não compartilham o kernel
com o host, nem com outros containers no mesmo host. Ainda, esses
containers exigem que a função de Hyper-V seja instalada no host, cuja
definição e métodos de habilitação foram explicados no capítulo sobre
virtualização. Por padrão, um container de Hyper-V será iniciado como um
container do Windows Server tradicional. Para criar um container de Hyper-
V a partir de uma imagem Microsoft Windows Server Core execute o
seguinte comando:
docker run -d --name hvcontainer --isolation=hyperv
microsoft/windowsservercore
A única diferença entre a criação de um container de Windows Server e a de
um de Hyper-V é o parâmetro –isolation=hyperv, que precisa ser declarado.
Para saber se um container é um Windows Server ou um Hyper-V, execute o
comado docker inspect <docker_id>, ou docker inspect <docker_name>, e
busque a propriedade “Isolation”. Se o valor resultante for “process”, trata-se
de um container Windows Server, e este container compartilha o kernel do
seu host.
Porém, se o valor for “hyperv”, o container é um Hyper-V, e tem um kernel
próprio. Mas, cuidado com os conceitos! O container Hyper-V usa a
tecnologia de nested VM para fazer o isolamento, mas não cria uma máquina
virtual como conhecemos. Aliás, se o comando Get-VM for executado, não
haverá nenhum resultado.
Segue uma maneira rápida de obter este valor:
docker inspect -f “{{.HostConfig.Isolation}}” ContainerName
Os containers do Windows Server vêm em duas versões: Server Core e Nano
Server. Como os containers não possuem um elemento gráfico (GUI), todo
seu gerenciamento deve ser feito através da linha de comando. As diferenças
entre estes dois tipos de containers são:
Os containers do Nano Server executam uma versão da opção de
instalação do Nano Server. Os aplicativos que funcionam no Nano Server
devem ser executados em um container criado a partir da imagem do
Nano Server.
As imagens do container Nano possuem uma necessidade menor de
memória e de disco do que a versão do Server Core.
A versão Core permitirá uma maior compatibilidade com aplicações de
mercado, visto que o Nano Server ainda é uma aposta.
FIGURA 04-02. Arquitetura entre Windows Server Containers e Hyper-V
Containers
Instalação da Função Containers
Por padrão, o serviço de container vem desabilitado nos sistemas
operacionais Windows Server 2016 e Windows 10. Para servidores Windows
Server 2016, execute o comando:
Install-WindowsFeature Containers -Restart
No Windows 10, navegue até o Control Panel, escolha Turn Windows
Features on or off, selecione a opção Containers e clique em OK. Lembre-se
que, no Windows 10, somente o Container Hyper-V é suportado, e será
necessário um notebook para suportar a instrução de virtualização do
processador(Intel-VT / SLAT). Use containers no Windows 10 somente para
laboratório, nunca em produção.
FIGURA 04-03. Intalação da função Containers pelo Server Manager
Gerenciamento de Container Docker
Os containers do Windows Server 2016 são gerenciados por ferramentas da
Docker (www.docker.com). A vantagem, neste caso, é que a sintaxe de
comando do Docker, no Windows Server, é quase idêntica às ferramentas de
comando do Docker para Linux. A desvantagem é que, embora exista o
módulo do PowerShell disponível no GitHub, para gerenciamento de
containers no Windows Server 2016, o PowerShell não é a principal
ferramenta para executar essa função no Windows Server.
Nota
Embora seja possível utilizar os mesmos comandos do Docker,
tanto no Windows Server 2016 como no Linux, só serão
executados containers Server Core e Nano Server, do Windows
Server. Não é possível executar containers Linux em
computadores com Windows Server 2016, a não ser
indiretamente, criando uma máquina virtual Linux no Hyper-V.
Neste caso, porém, o host do container ainda será o Linux, e não
o Windows Server. Há uma previsão que isso seja suportado em
uma futura versão do Windows Server, com um subsistema linux
embarcado no Windows Server.
 
Instalação do Docker
O Docker não está incluído na mídia de instalação do Windows Server 2016.
Assim, será necessário fazer sua instalação pela galeria do PowerShell. Desta
maneira, garante-se que sempre se tenha a versão mais recente.
Certifique-se de que seu servidor Windows Server 2016 esteja conectado à
Internet. Em seguida, execute o seguinte comando com prompt elevado do
PowerShell.
Install-Module -Name DockerMsftProvider -Repository
PSGallery -Force
O comando acima instalará o módulo, mas não o Docker. Para finalizar a
instalação, execute Install-Package, e use o mesmo comando para atualizar a
versão do Docker. Para futuras versões, será necessário reiniciar seu
computador.
Install-Package -Name Docker -Providername
DockerMsftProvider -Verbose
 
Em caso de erro, verifique se o módulo foi baixado no seu computador,
através do comando Find-Package:
 
Find-Package -Name Docker -Providername
DockerMsftProvider -Verbose
 
Caso opte por uma máquina virtual no Azure, com o Windows Server 2016
que tenha containers, estes passos não serão necessários. Tudo já está lá,
pronto para começar. Por padrão, os binários do docker ficam em
C:\Program Files\docker. Reinicie o computador antes de começar, usando
o seguinte comando:
 
Restart-Computer -Force
 
A instalação do Docker Engine em um servidor Nano Server pode ser um
pouco mais desafiador, especialmente pelas restrições de acesso e pré-
requisitos. Vamos imaginar que o endereço IP do Nano Server seja
10.10.10.10.
Se o servidor Nano Server estiver em Workgroup, primeiro adiciona-se o
endereço IP em uma lista de hosts confiáveis, pelo comando abaixo:
Set-Item WSMan:\localhost\Client\Trustedosts 10.10.10.10 -
Force
Conecte-se, remotamente, ao Nano Server, pelo Powershell Remoting:
Enter-PSSession -ComputerName 10.10.10.10 -Credential (Get-
Credential)
Em seguida, force um Windows Update, pois isto disponibilizará o download
das últimas atualizações do Nano Server.
$sess = New-CimInstance -NameSpace
root/Microsoft/Windows/WindowsUpdate -ClassName
MSFT_WUOperationsSession
 
Invoke-CimMethod -InputObject $sess -MethodName
ApplyApplicableUpdates
Podem ocorrer muitas atualizações, o que faz com que este comando demore
para finalizar. Remotamente, reinicie o servidor pelo comando Restart-
Computer. Neste momento, o comando será o mesmo do Server Core para
instalação do Docker.
Install-Module -Name DockerMsftProvider -Repository
PSGallery -Force
Install-Package -Name Docker -Providername
DockerMsftProvider -Verbose
Start-Service Docker
 
Os administradores do Windows Server não familiarizados com a sintaxe de
comando do Docker podem contar com um suporte de ajuda. Para saber todos
os comandos do Docker, a qualquer momento digite docker --help e, para
obter a versão atual, digite docker version. Lá você descobrirá que o Docker
foi desenvolvido com a linguagem GoLang do Google (www.golang.org).
Configuração do Docker
Para alterar as configurações padrão do Docker como, por exemplo, criar
uma rede virtual que suporte NAT para traduzir os endereços IP para os
containers, deve-se criar o arquivo Daemon.json na pasta abaixo:
%ProgramData%\Docker\Config\Daemon.json
Este arquivo pode ser baixado no site da Docker. Antes de editar o arquivo
Daemon.json, é preciso parar o serviço do Docker, usando o seguinte
comando:
Stop-Service Docker
 
Depois, adicione as configurações que deseja alterar no arquivo de
configuração. Por exemplo, para configurar o Docker Engine para aceitar
conexões recebidas na porta 2375, adicione as seguintes linhas no arquivo
Daemon.json:
 {
 "hosts": ["tcp: //0.0.0.0:2375"]
 }
A partir de um computador Windows 10, com o Docker Client instalado,
deve-se usar o parâmetro -H para declarar o IP e a porta onde o comando
docker será executado. A porta TCP 2375 é a padrão do Docker.
docker -H 10.10.10.10:2375 version
A versão do Docker para Windows Server ainda não suporta todas as
configurações, ao contrário do Linux. Abaixo, segue a lista completa de
comandos/ configurações.
{
 "authorization-plugins": [],
 "dns": [],
 "dns-opts": [],
 "dns-search": [],
 "exec-opts": [],
 "storage-driver": "",
 "storage-opts": [],
 "labels": [],
 "log-driver": "",
 "mtu": 0,
 "pidfile": "",
 "graph": "",
 "cluster-store": "",
 "cluster-advertise": "",
 "debug”: true,
 "hosts": [],
 "log-level": "",
 "tlsverify": true,
 "tlscacert": "",
 "tlscert": "",
 "tlskey": "",
 "group": "",
 "default-ulimits": {},
 "bridge": "",
 "fixed-cidr": "",
 "raw-logs": false,
 "registry-mirrors": [],
 "insecure-registries": [],
 "disable-legacy-registry": false
}
Assim que todas elas estiverem concluídas, inicie o serviço do Docker:
Start-Service Docker
 
docker pull microsoft/windowsservercore
Imagens Base
Até aqui, o servidor foi simplesmente preparado com os serviços que
sustentarão as funções de Container e Docker. Chegou a hora de começar a
criar seus primeiros containers, e aprender como manipulá-los. Antes de tudo,
será necessário ter uma imagem base com o sistema operacional Windows
Server 2016 Core ou Nano. Para localizar a última versão disponibilizada
pela Microsoft, execute o seguinte comando:
docker pull
Para baixar a última versão da imagem Core e Nano do Docker Hub, utiliza-
se o comando abaixo:
A
imagem
do Nano Server tem aproximadamente 358.4 MB, enquanto a versão Server
Core, 4.2 GB. Certifique-se, portanto, de ter uma conexão de Internet de boa
qualidade, e sem restrições de acesso.
Para baixar uma versão diferente, insira a versão ao final da imagem:
docker pull microsoft/nanoserver:10.0.14393.576
Sem dúvida alguma, o repositório principal, que interessará a maioria dos
administradores de serviços do Windows Server, será o Docker Hub. A
Microsoft publica imagens de containers, não só com sistemas operacionais,
mas também com aplicações de avaliação do SQL Server, ASP.NET e
frameworks de desenvolvimento de terceiros, já embarcados em containers
Windows e Linux.
A lista abaixo está em constante atualização, mas, até meados de dezembro
de 2017, os seguintes containers com aplicações recém-embarcadas já haviam
sido publicados pela Microsoft no Docker Hub.
Nome da Imagem Descrição Host
Microsoft/oms Inclui um agente
OMS para containers
Linux Server
Linux.
Microsoft/dotnet Inclui o .NET Core
para containers Linux
e Windows Server
Core.
Linux Server
Microsoft/vsts-agent Inclui o agente do
Visual Studio Team
Services para
containers Linux.
Linux Server
Microsoft/aspnetInclui IIS 10, .Net
Framework e .Net
Extensibility for IIS,
que permitem a
execução de
aplicações ASP.NET
em containers
Windows Server
Core.
Windows
Server
Microsoft/iis Inclui o servidor IIS. Windows
Server
Microsoft/mssql-server-linux Este container contém
o Microsoft SQL
Server no Linux.
Linux
Microsoft/azure-cli Inclui o Azure CLI. Windows
Server
Microsoft/nanoserver Imagem base com o
Nano Server.
Windows
Server Nano
Microsoft/windowsservercore Imagem base com o
WS Core.
Windows
Server
Microsoft/aspnetcore Inclui ASP.NET Core. Windows
Server
Microsoft/donet-nightly Inclui builds do .NET
Nightly.
Windows
Server
Microsoft/aspnetcore-build Inclui o build usado Windows
para compilar e
publicar aplicações
em ASP.NET Core.
Server
Microsoft/dotnet-samples Inclui exemplos do
.NET Core.
Windows
Server
Microsoft/sample-nginx Inclui o servidor web
e proxy reverso
Nginx.
Windows
Server
Microsoft/applicationinsights Inclui o Application
Insights for Docker.
Windows
Server Core
Microsoft/mssql-server-
windows-express
Inclui a versão
gratuita do SQL
Server versão
Express.
Windows
Server Core
Microsoft/mssql-server-
windows
Inclui uma versão
experimental de 180
dias do SQL Server,
Windows
Server Core
Microsoft/dotnet-framework Inclui o framework
.NET
Windows
Server Core
Microsoft/aspnetcore-build-
nightly
Inclui o Nightly do
ASP.NET Core.
Windows
Server Core
Microsoft/sample-httpd Inclui um servidor
web Apache.
Windows
Server Core
ou Nano
Microsoft/powershell Inclui o PowerShell. Windows
Server Core
Microsoft/cntk Inclui um exemplo do
Microsoft Cognitive
Toolkit para
containers Linux.
Linux Server
Microsoft/powershell-nightly Inclui uma edição do
PowerShell Core
Nightly
Windows
Server Core e
Linux Server
Microsoft/sample-python Inclui o Python. Windows
Server Core e
Nano Server
Microsoft/sample-mysql Inclui o MySQL. Windows
Server Core e
Nano Server
Microsoft/sample-node Inclui o Node.JS. Windows
Server Nano
Microsoft/dotnet-buildtools-
prereqs
Inclui ferramentas
para a criação de
componentes do
.NET.
Windows
Server Core
Microsoft/sample-golang Inclui a linguagem de
desenvolvimento Go,
criada e mantida pelo
Google.
Windows
Server Core e
Nano Server
Microsoft/sample-redis Inclui o Redis
(sistema para cache).
Windows
Server Core e
Nano Server
Microsoft/sqlite Inclui o Sqlite. Windows
Server Core
Microsoft/Sample-ruby Inclui o framework
Ruby.
Windows
Server Nano
Microsoft/mssql-server-
windows-developer
Inclui a versão
Developer Edition do
SQL Server.
Windows
Server Core
Microsoft/sample-rails Inclui o framework
Ruby on Rails.
Windows
Server Core e
Nano
Microsoft/sample-django Inclui o Django,
framework gratuito de
código aberto.
Windows
Server Core
Microsoft/sample-mongodb Inclui o MongoDB. Windows
Server Core
Microsoft/dotnet-framework- Inclui exemplos que Windows
samples demonstram uma
variedade de
configurações Docker
para o
Framework.NET .
Server Core
Microsoft/pbxt Inclui o Power BI
Data Curation.
Windows
Server Core
Microsoft/windowsservercore-
1709
Inclui a nova edição
do Windows Server
2016.
Windows
Server Core e
Nano
Para acessar o repositório completo, digite:
https://hub.docker.com/u/microsoft
Quando uma imagem é baixada do repositório, esta ação também irá baixar
qualquer imagem de dependência que seja necessária.
A exclusão de imagens em desuso pode ser feita, bastando informar a ID da
imagem a ser excluída. Primeiramente, obtenha o ID pelo comando Docker
Images. Em seguida, exclua-o com o comando Docker rmi <id-number>.
Exemplo de exclusão de uma imagem com ID 168f41dd231f:
docker rmi 168f41dd231f
O Docker Engine se protege contra exclusões quando a imagem está
associada a algum container existente. Quando isso acontece, a seguinte
mensagem irá aparecer:
“Unable to delete <id-number> (must be forced) – image is
being used by stopped container <container-id-number>”
 
Nota
O Docker reconhece as iniciais dos Ids das imagens. Como os
Ids são números hexadecimais aleatórios, isso pode complicar,
um pouco, sua digitação. No exemplo acima, poderia digitar
docker rmi 168, o que seria suficiente para o docker reconhecer
o id da image 168f41dd231f.
O comando docker pull também sabe se a imagem que está tentando baixar é
compatível, ou não, com sua plataforma. Lembre-se que o seu host de
containers é um Windows Server, então somente imagens de containers
Windows Server serão compatíveis. Não é possível executar um container
Linux no Windows Server, e vice-versa.
Tente baixar uma versão de exemplo da Docker para um site estático, usando
o NGINX através do comando docker pull dockesamples/static-site. A
seguinte mensagem surgirá:
Image operating system “linux’ cannot be used on this plataform
 
Rede de Container
Cada container possui um adaptador de rede virtual, e esse adaptador se
conecta a um switch virtual, através do qual o tráfego de entrada e de saída é
enviado. Os modos de rede determinam a forma como os adaptadores de rede
funcionam, em termos de endereçamento IP, e se eles usam NAT ou estão
conectados à mesma rede do container host. O container do Windows Server
suporta cinco diferentes modos de redes virtuais. Abaixo, vamos explorá-los
em detalhes:
Modo Descrição
NAT Cada container recebe um endereço IP a partir
do intervalo de endereços privados
172.16.0.0/12. Ao usar o NAT, pode-se
configurar o encaminhamento da porta do
container host para o mesmo container, ou outra
porta é encaminhada para dentro deste
container. Ao criarmos um container sem
especificar a rede, o container usará a rede NAT
por padrão.
Transparente Cada container se conecta a uma rede física. Os
containers podem ter endereços IPs atribuídos
estaticamente, ou através de DHCP, da sua rede
corporativa.
Overlay
 
Use este modo quando o Docker Engine estiver
configurado para executar em modo Cluster
Swarm. O modo de sobreposição permite que os
pontos de extremidade do container sejam
conectados a vários hosts de containers.
L2Bridge Os pontos de extremidade do container estão na
mesma subrede IP usada pelo container host. Os
endereços IPs devem ser atribuídos de forma
estática. Todos os containers hospedados no
container host terão o mesmo endereço MAC.
L2Tunnel Este modo é reservado e só pode ser usado
quando os containers forem instalados no
Microsoft Azure. Não o use em ambiente On-
Premises.
Ao criar uma rede do tipo Transparente, remova a linha “fixed-cidr” e altere o
campo “bridge”, adicionando o valor “none” “bridge”: ”none”, no arquivo
Daemon.json. Também, pode-se criar uma rede de container com o comando
New-ContainerNetwork, pelo PowerShell, mas aqui optamos por criá-la pelo
Docker.
No meu exemplo, criarei uma rede virtual chamada transparent-vnet, do
modo Transparente, e ainda definirei uma sequência de IP e gateway que
meus containers deverão utilizar, quando forem iniciados. A omissão da
sequência de IP e gateway poderão até fazer mais sentido, tendo em vista que
os containers poderão receber IPs dinâmicos do seu DHCP, ou até mesmo um
IP fixo dentro da sua sequência corporativa.
docker network create -d transparent --subnet=192.168.100.0/24
--gateway 192.168.100.1 transparent-vnet
Para listar todas as redes virtuais existentes no seu container host, execute:
docker network ls
Os containers que estiverem, inicialmente, conectados a esta rede virtual
receberão, dinamicamente, IPs entre as sequências 192.168.100.2 e
192.168.100.254. Para criar um container e associá-lo a uma vnet, execute:
docker run -d --network=transparent-vnet microsoft/iis
 
Nota
Há algo muito interessante e que, provavelmente, você deve
estar se perguntado, sobre os nomes geradospelo Docker de
maneira aleatória, e que as vezes soam até engraçados. A razão
pela qual o Docker atribui nomes é que os containers são um tipo
de objeto mais efêmero do que uma máquina virtual tradicional.
E, como eles tem uma vida muito curta, não vale a pena atribuir
um nome que precisará ser lembrado. Outro motivo para os
nomes aleatórios, é que eles são mais fáceis de lembrar do que
os seus respectivos IDs em formato hexadecimal. Mas se você é
daqueles que se incomodam com isso, e precisam dar nomes
mais amigáveis aos containers , use o parâmetro --name no
momento da criação.
Para conectar dentro do container e interagir, através do prompt de comando,
execute o comando docker exec com o parâmetro -it
docker exec -it container_name cmd
Dentro do container é como se estivéssemos dentro de um Windows Server
tradicional. Ele reconhecerá qualquer comando executado. O comando
hostname me retornou o nome 0220fc6666aa, e o ipconfig, retornou o
endereço 192.168.100.213 e gateway 192.168.100.1, respeitando a sequência
de endereço pré-definida.
Também é possível criar um container pré-definindo o endereço IP. Para isso,
use o parâmetro –ip. O exemplo abaixo cria um container com o IP
192.168.10.90
docker run -d --network=transparent-vnet --ip 192.168.100.90
microsoft/iis
Pode-se, ainda, especificar a quantidade de memória e a porcentagem de CPU
a serem alocadas ao container, usando os parâmetros --memory e --cpu-
percent
 
docker run -d --name mycontainer --memory 1g --cpu-percent 20
--network=transparente-vnet --ip 192.168.100.90 microsoft/iis
 
Abra um navegador, em qualquer computador da sua rede, e digite o
endereço IP. Verifique se a página do IIS será exibida. Se conseguiu chegar
até aqui, parabéns!
 
Se executou um container em modo detached (-d) e, depois, quer saber o que
está acontecendo dentro do container ou, até mesmo, qual comando está em
execução, use:
 
docker logs <container_id>
 
Se o container host é uma máquina virtual no Hyper-V e se quer utilizar o
DHCP para atribuir, automaticamente, um endereço IP ao container, é
necessário habilitar o MAC Address Spoofing nas propriedades da placa de
rede da máquina virtual. Ou então, pelo comando abaixo:
Get-VMNetworkAdapter -VMName <VMName> | Set-
VMNetworkAdapter -MacAddressSpoofing On
A menos que se configure esta opção, não será possível se conectar aos
containers pelos seus respectivos endereços IPs.
Pode-se criar várias redes virtuais de modos diferentes nos seus containers
hosts, mas deve-se ter em mente algumas limitações:
Quando se cria múltiplas redes virtuais nos modos Transparente e L2
Bridge, é preciso garantir que cada rede tenha seu próprio adaptador.
Quando se cria múltiplas redes virtuais NAT, em um container host, a
rede 172.24.0.0/20 será fracionada em outras redes menores, por exemplo,
172.16.1.0/21, /22, /23, /24 , e assim sucessivamente.
A sequência de endereço 172.24.0.0 / 255.255.240.0, reservada para
endereços NAT nos containers, pode ser alterada em caso de conflito com sua
rede local. Se esse for o seu caso, ou, simplesmente, se deseja trabalhar em
uma rede diferente dessa, primeiramente pare o serviço do Docker, utilizando
o comando stop-service Docker.
Remova qualquer rede NAT existente:
 
Get-ContainerNetwork | Remove-ContainerNetwork
 
Edite o arquivo daemon. json e configure o novo prefixo no campo “fixed-
cidr”: ”< IP Prefix > / Mask”. Reinicie o Docker. A partir deste momento, os
novos containers obterão os IPs da sua nova sequência.
Recrie a sua nova rede no modo NAT. Por exemplo, para criar uma rede do
tipo NAT com nome NATCustomNetwork, e com o segmento de rede
192.168.100.0/24 e gateway 192.168.100.1, execute:
docker network create -d nat --subnet=192.168.100.0/24 --
gateway=192.168.100.1 <NATCustomNetwork>
Agora, se deseja saber quais containers estão conectados a uma determinada
rede virtual, execute os seus respectivos endereços MAC e IP:
docker network inspect <vnet-name>
 
Se estiver usando uma rede do tipo NAT, o segmento de rede do seu
container host e dos seus containers serão diferentes. Neste caso, será
necessário expor, para a interface do seu container host, a porta para a qual o
seu serviço dentro do container está respondendo. Se sua aplicação responde
à porta 8080 do container, será possível mapeá-la para a porta 80 do seu host,
usando o parâmetro -p na criação do container.
 
Lembre-se: o que está à esquerda do separador: (dois pontos) é a porta do
host e, à direita, está a porta do container.
 
docker run -d -p 80:8080 --name mycontainer
microsoft/windowsservercore
 
 
Nota
Para criar um container e iniciá-lo com uma sessão interativa,
especifique qual é o cmd.exe ou powershell.exe, usando a opção
-it. As sessões interativas permitem interagir diretamente com o
container, através da linha de comando, assim que o container é
iniciado. O modo “Detached”, com o parâmetro –d, inicia um
container, mas não inicia uma sessão interativa. Execute o
comando (get-process). Count em um container host com o
Windows Server Core, e em um container Windows Server
Core. Deve-se obter um valor aproximado de 105 processos no
container host, e 20 no container. Um container é,
aproximadamente, 80% menor em número de serviços do que
um Windows Server Core.
Para iniciar um container em modo interativo com o PowerShell, execute:
docker run -it microsoft/windowsservercore powershell.exe
 
Para iniciar, ou parar, um container, digite:
 
docker start/stop container_id
 
 E, para remover um container, use o comando abaixo:
 
docker rm container_id
 
Portabilidade de Imagens
Um dos principais benefícios de um container é a sua característica de
conviver em qualquer lugar. Sua portabilidade e isolamento permitem que
seus containers sejam migrados entre seus servidores containers locais, ou
para a nuvem, de uma maneira relativamente simples.
 
Na prática, os containers não são diretamente movimentados entre hosts, mas
sim suas imagens, e a partir delas, novos containers são gerados.
 
Como estou utilizando o Windows Server 2016 Core, e não tenho disponível
a versão gráfica do Advanced Firewall do Windows, abriremos a porta 445
(SMB) através da ferramenta NETSH.
 
netsh advfirewall firewall add rule name="Open Port 445" dir=in
action=allow protocol=TCP localport=445
 
Use o comando docker save para transferir uma imagem para um novo
container host. O arquivo deve ser salvo com a extensão .tar.
 
docker save newjavaimage -o
\\newhost\c$\images\new_java_image.tar
 
Agora, no seu container host de destino, use o comando docker load para
importá-lo para o Docker Engine.
docker load -i c:\images\new_java_image.tar
 
Volumes
Além de armazenar dados dentro das imagens de container, também é
possível configurá-lo para acessar dados em discos fora de seu próprio
ambiente. Por exemplo, pode-se montar a pasta D:\WebData do seu container
host dentro de um container, e criar algo chamado de volumes, onde os
containers podem compartilhar dados.
 
A título de exemplo, criei uma pasta D:\ContainerData no container host, e
coloquei alguns arquivos ali dentro. Agora, parra montar esta pasta dentro do
container, usarei o parâmetro –v para mapear a pasta local para outra dentro
do container. No exemplo abaixo, a pasta D:\ContainerData, do container
host, será mapeada na pasta C:\ContainerData, dentro do container criado a
partir da imagem gbanin/my_first_image:
 
docker run -d -v D:\ContainerData:C:\ContainerData
gbanin/my_first_image
 
Para listar os volumes existentes, use o comando:
 
docker volume ls
 
DockerFile
Quando se trata de construir suas próprias imagens de container, há duas
opções diferentes. A primeira, é fazê-lo manualmente, iniciando um
container, personalizando-o e, depois, salvando uma imagem como base. Ou
então, pode construi-la de forma automática, usandoo DockerFile.
FIGURA 04-04. Arquivo de resposta do Dockerfile no Visual Studio Code
 
Basicamente, o Dockerfile lista todas as personalizações realizadas, e é uma
ótima maneira de armazenar suas imagens como um código, além de ser,
provavelmente, a maneira mais comum de fazê-lo.
 
Primeiro, mostrarei o método manual. Criarei um container, usando o
comando abaixo:
 
docker run-it microsoft/windowsservercore powershell
 
 O PowerShell se abrirá. Logo após, usando o comando descrito abaixo,
criarei um arquivo chamado teste.txt, com valor WindowsServer2016 dentro
do container:
 
New-Item -itemType file -Name Teste.txt -Value
WidowsServer2016
 
Vamos imaginar que, ao invés de um arquivo, eu poderia fazer a instalação
do IIS ou de qualquer framework de desenvolvimento e, claro, até mesmo a
sua aplicação PHP/Java/C#. Pressione Control PQ para sair do contexto do
container. Depois, pare o container com o comando docker stop
<container_id>.
 
Acabei de fazer uma customização, e já posso criar uma imagem usando as
personalizações feitas nesse container. Usarei o comando:
 
docker commit <container_name> <new_image_name>
 
Agora que já temos um container em execução, podemos inserir e fazer as
modificações necessárias para garantir que o aplicativo desejado funcione
adequadamente em um container. Isso pode envolver a criação de diretórios
(pastas), usando o comando DISM.EXE para instalar funções, ou usando o
alias wget, do Powershell, para baixar e instalar binários diretamente da
Internet dentro do container.
Agora, darei um exemplo mais avançado. Quando executamos o comando
abaixo dentro de um container, ele baixará e instalará a mais recente versão
do Java. É possível inserir a barra invertida \ ao final de cada linha como uma
quebra, caso o comando seja muito extenso.
wget -Uri http://javadl.sun.com/webapps/download/AutoDL?
BundleId=107944 -outfile javaInstall.exe -UseBasicParsing
REG ADD
HKLM\Software\Policies\Microsoft\Windows\Installer /v
DisableRollback /t REG_DWORD /d 1 | Out-Null
./javaInstall.exe /s INSTALLDIR=C:\Java REBOOT=Disable |
Out-Null
 
Para ver a nova imagem personalizada, utilize o comando:
 
docker images
 
Para saber quais são suas dependências, execute o comando:
 
docker history <your_new_image>
 
Para automatizar este processo, podemos usar um arquivo de resposta,
criando uma pasta C:\WebApp, por exemplo, e um arquivo chamado
Dockerfile (sem extensão). Para tanto, use o editor de texto de sua preferência
e abra o arquivo Dockerfile. No Visual Studio Code, o editor já reconhece o
arquivo com nome Dockerfile como uma propriedade do Docker, e marca
esse arquivo com o símbolo da baleia carregando containers, que é o logo da
Docker. A partir daí, os comandos do Dockerfile, tais como FROM,
MAINTAINER, RUN, COPY, CMD, entre outros, também são
reconhecidos pelo editor. O Dockerfile é uma “receita de bolo” usada para a
construção de novas imagens. Neste exemplo que dei, declarei que a nova
imagem usará a imagem microsoft/windowsservercore como base, e que eu
sou o autor. Estabeleci, ainda, que o IIS será instalado através do comando
Install-WindowsFeature, que o conteúdo da minha web app será copiada da
pasta WebContent para inetpub\wwwroot, e que o comando PowerShell será
executado toda vez que o container for iniciado. Use # para fazer comentários
no código.
 
Com o arquivo Dockerfile declarado, usa-se o comando docker build para
compilar a primeira imagem. Acione o comando docker build –help para ver
todos os parâmetros possíveis. Use, pelo menos, o parâmetro -t (tag) para dar
um nome a nova imagem.
 
docker build -t my_first_image Dockerfile
 
Se já houver uma versão anterior e quiser criar uma nova, execute:
 
docker build -t my_first_image:v2 Dockerfile
 
O propósito deste Dockerfile é automatizar o processo de construção das
imagens personalizadas.
 
Docker Hub
Agora que sabemos como criar imagens de container, estamos prontos para
fazer o upload da imagem. Para isso, é necessário ter uma conta no Docker
Hub. Crie uma em https://hub.docker.com. Depois, crie um repositório
(opcional) e renomeie o seu container para o formato
dockerid/yourimagename: latest
 
docker tag my_first_image:v2 gbanin/my_first_image:latest
 
docker login
(Digite seu usuario e senha do Docker Hub)
 
docker push gbanin/my_first_image: latest
(o upload se iniciará)
 
Docker Compose
O Docker Compose é uma ferramenta que define e executa aplicativos
Docker distribuídos entre múltiplos containers, além de automatizar tarefas
manuais. Com o Compose, usa-se um arquivo YAML para configurar os
serviços do seu aplicativo, tais como: quais portas serão expostas, quais
discos serão mapeados, quantos containers serão criados e quais tarefas serão
executadas. Assim, com um único comando, é possível, criar e iniciar todos
os serviços de uma única vez. As instruções são muito parecidas com as do
DockerFile.
 
Usar o Docker Compose envolve, basicamente, um processo de três etapas:
 
Definir o ambiente do seu aplicativo com um Dockerfile, para que ele
possa ser reproduzido em qualquer lugar.
Definir os serviços que compõem seu aplicativo no arquivo docker-
compose.yml, para que eles possam ser executados juntos em um
ambiente isolado.
Executar o comando docker-compose up, que iniciará e executará o
aplicativo inteiro.
 
FIGURA 04-05. Arquivo docker-compose.yml no Visual Studio Code
O Docker Compose já vem instalado no Linux, mas, no Windows Server, ele
precisa ser baixado e instalado antes de ser utilizado.
 
Invoke-WebRequest
https://github.com/docker/compose/releases/download/1.18.0/docker-
compose-windows-x86_64.exe -UseBasicParsing -OutFile
$env:ProgramFiles\docker\docker-compose.exe
 
O nome do arquivo pode ser diferente de docker-compose.yml, porém, neste
caso, é necessário especificar o nome do arquivo com o parâmetro -f. Para
compor a solução, use o parâmetro UP e, para decompor, use DOWN.
 
docker-compose up -f meucompose.yml
 
docker-compose down -f meucompose.yml
 
Para publicar sua aplicação, use o Git for Windows.
 
Integração com Active Directory
Embora os containers com base nos sistemas operacionais Core e Nano
possuam a maior parte das características de uma máquina virtual, eles não
podem ser adicionados como membro de um domínio do Active Directory.
Isso ocorre porque os containers são, supostamente, temporários, e o domínio
que os uniria, provavelmente, obstruiria o Active Directory com contas
desnecessárias.
Ainda que os containers não possam ser inseridos à um domínio, é possível
usar uma conta de serviço gerenciada (Group Service Managed Account,
gMSA) para fornecer um ou mais containers, com uma identidade de
domínio semelhante à usada por um dispositivo membro de um domínio
tradicional.
A execução desta tarefa requer o download da ferramenta Windows Server
Container Tool. Além disso, o computador que hospeda os containers deve
ser membro do domínio do Active Directory onde se encontra o gMSA. Isso
dá ao container a identidade representada pelo gMSA.
O gMSA é usado para criar uma inspeção de credencial (Credential Spec),
que é feita no container em execução. Todo processo executado no container,
sob o contexto “Local Service”, apresentará as credenciais de domínio do
gMSA a qualquer outro serviço de domínio ao qual ele se conecte. Pode-se,
por exemplo, executar um serviço no Windows Server em um container,
usando uma conta de domínio para acessar um servidor SQL Server.
Primeiro, crie um grupo de segurança global no Active Directory e inclua,
como membros deste grupo, os seus servidores Windows Serve Core com as
funções de Containers e Docker instaladas, ou seja, seus servidores
containers hosts. No meu exemplo, criei um grupo chamado Container Hosts,
e adicionei os computadores CONTAINERH1 e CONTAINERH2 como
membros. Reinicie-os para quea efetivação aconteça.
Vá até um controlador de domínio e crie uma conta gMSA declarando qual
grupo poderá utilizá-la. Neste exemplo, estou criando uma conta gMSA
chamada gMSAContainers
New-ADServiceAccount -Name gMSAContainers -
DNSHostName gMSAcontainers.banin.com -
PrincipalsAllowedToRetrieveManagedPassword "Container
Hosts"
Agora, instale a conta gMSA nos seus containers hosts. Antes, instale o
módulo do PowerShell do Active Directory e importe-o:
Add-WindowsFeature AD-RSAT-Powershell
Import-Module ActiveDirectory
 
Verifique se o host é capaz de localizá-lo através do comando Get-
ADServiceAccount. Posteriormente, instale-o pelo comando install-
adserviceaccount e, finalmente, teste-o com o comando Test-
ADServiceAccount. Este último comando deverá trazer como resultado o
valor $true.
 
Get-ADServiceAcccount -Identity gMSAContainers
Install-ADServiceAccount -Identity gMSAContainers
Test-ADServiceAccount -Identity gMSAContainers
 
Clone as instruções da Microsoft no Github, do projeto Credential Spec:
Invoke-WebRequest
"https://raw.githubusercontent.com/Microsoft/Virtualization-
Documentation/live/windows-server-container-
tools/ServiceAccounts/CredentialSpec.psm1" -UseBasicParsing
-OutFile $env: TEMP\cred.psm1
 
Importe o módulo:
 
Import-Module $env: TEMP\cred.psm1
 
 Crie uma chave com o comando New-CredentialSpec:
 
New-CredentialSpec -Name gMSAContainers -AccountName
gMSAContainers
Este comando criará um arquivo no formato. Json. Para localizá-lo, execute o
comando Get-CredentialSpec.
Com esta chave de credencial em mãos, especifique-o no momento de criar
seu container através do parâmetro –security-opt:
docker run -d microsoft/iis --security-opt=gMSAContainers.json
--network=transparent-vnet
 
Se o objetivo for parar todos os containers, sem removê-los, execute o
seguinte comando:
docker stop -t 0 $(docker ps -q)
O parâmetro -t 0 encerra imediatamente e não espera os 10 segundos, que é o
padrão do Docker. O comando docker ps -q lista somente os Ids dos
containers. Como o comando está dentro de $( ), isso significa que o
comando docker stop vai ser executado para todos os containers listados em
docker ps -q de uma única vez. Por fim, se quiser liberar espaço e recomeçar
tudo, basta remover todos os containers de uma única vez através do
comando abaixo:
 
docker container prune
 
 
Simulado
Questão 01
Qual tipo de isolamento é usado por um Container Hyper-V?
A. Hyper-V isolation
B. Container isolation
C. Process isolation
D. Windows isolation
Questão 02
Qual comando do cliente docker deve ser usado para baixar a imagem do
Nano Server como imagem de container?
A. docker os microsoft/nanoserver
B. docker run microsoft/nanoserver
C. docker images microsoft/nanoserver
D. docker pull microsoft/nanoserver
Questão 03
Qual a diferença principal entre um Windows container e uma máquina
virtual?
A. Containers usam menos CPU do que uma VM
B. Containers compartilham o kernel do sistema operacional hospedeiro
C. Containers usem menos memória do que uma VM
D. Containers usam menos storage do que uma VM
Questão 04
Qual comando é utilizado para remover um container?
A. docker os
B. docker rm
C. docker stop
D. docker delete
Questão 05
Qual é o procedimento usado para implantar um host de container baseado no
Windows Server no Azure?
A. Criar uma VM Linux
B. Criar uma VM Windows Server 2016 com o serviço de container já
instalado
C. Criar uma VM Windows 10 Enterprise
D. Criar uma VM base Windows Server 2016. Instalar a função de
containers e, depois, o docker
Questão 06
Você quer usar o Docker Compose no Azure em uma VM configurada como
um container host, e com os recursos de container e docker já instalados. O
que falta?
A. Baixar e instalar o docker-compose.exe
B. Fazer o windows update
C. Reiniciar o servidor
D. Abrir a porta 80 no firewall
Questão 07
Ao criar uma rede de container para um aplicativo, os containers devem ser
alcançados em sua rede corporativa, e devem receber um endereço IP do seu
servidor DHCP. Qual tipo de rede deve ser criado?
A. L2 Tunnel
B. Transparent
C. L2Bridge
D. Nat
Questão 08
Qual comando é utilizado para criar uma rede virtual de container do tipo
Transparente?
A. New-DockerNetwork
B. Docker network create
C. Docker run network
D. Docker network install
Questão 09
Qual tipo de arquivo deve ser criado para automatizar a compilação dos
containers docker?
A. Dockerfile
B. Daemon.json
C. Docker.ini
D. Dockerd.conf
Questão 10
Qual comando se utiliza para excluir um volume de dados chamado
sqlstorage no docker?
A. docker volume rm sqlstorage
B. docker rmi sqlstorage
C. docker delete sqlstorage
D. docker rm sqlstorage
Questão 11
Qual subcomando do docker cliente poderia ser usado para iniciar um
container?
A. docker run
B. docker -d
C. docker -it
D. docker ps
Questão 12
Qual a diferença principal entre um Windows container e um Hyper-V
container?
A. O container Hyper-V executa no Linux
B. O container Windows usa menos memória
C. O container Hyper-V é mais rápido
D. O container Hyper-V executa dentro de uma máquina virtual
Questão 13
Você precisa criar um arquivo de compilação para múltiplos containers. Qual
é o nome do arquivo padrão que deve ser utilizado para que não seja
necessário defini-lo em tempo de execução?
A. Docker-compose.xml
B. Docker-compose.yml
C. Docker-compose.json
D. Docker-compose
Questão 14
Qual comando do Docker Compose pode ser usado para derrubar uma
aplicação que está em execução em vários containers?
A. docker compose stop
B. docker compose down
C. docker compose delete
D. docker-compose remove
Questão 15
Qual é o procedimento usado para permitir o acesso HTTP a um aplicativo
web, baseado em um container que será executado em uma rede de container
do tipo NAT?
A. Configurar o container para obter o IP automaticamente de um DHCP
B. Usar o parâmetro -p para mapear a porta 80 do host para o container
C. Criar uma transparent network
D. Editar o arquivo daemon.json
Questão 16
Qual comando é utilizado para remover um container network?
A. Remove-ContainerNetwork
B. Delete-ContainerNetwork
C. Docker network delete
D. Delete-dockernetwork
Questão 17
Qual dos seguintes comandos irá construir uma imagem de container
chamada sql, com uma tag mais recente (latest)?
A. docker build -t sql
B. docker build sql: latest
C. docker build sql/latest
D. docker build -d sql
Questão 18
Qual comando deve ser utilizado para baixar uma imagem do Nano Server no
repositório oficial da Microsoft, no Docker Hub?
A. docker pull microsoft-nanoserver
B. docker pull microsoft:nanoserver
C. docker pull microsoft/nanoserver
D. docker pull nanoserver
Questão 19
Qual sistema operacional de container base pode ser executado como
container no Windows, em um host de container Nano Server?
A. Server Core
B. Server Full
C. Linux
D. Nano Server
Questão 20
Qual a primeira ação a ser feita no Windows Server 2016, antes de instalar o
Docker?
A. Instalar a função de Hyper-V
B. Instalar a função de Containers
C. Fazer um windows update
D. Ativar o sistema operacional
 
Respostas
01-
A
02-
D
03-B 04-B 05-B 06-
A
07-B 08-B 09-
A
10-
A
11-
A
12-
D
13-B 14-B 15-B 16-
A
17-
A
18-
C
19-
D
20-
C
 
 
CAPÍTULO 05 – Implantar Alta
Disponibilidade
Os serviços de alta disponibilidade evoluíram muito no Windows Server,
deste o lançamento do Wolf Pack. Em 1997, o Wolf Pack foi criado como
uma atualização do Windows NT 4.0, adicionando ao sistema operacional o
primeiro serviço de failover cluster, batizado como Windows NT Cluster
Service. Naquela época, o Cluster Service usava um disco externo conectado
a um cabo Y em dois servidores físicos. As conexõesaos discos evoluíram,
mas o método de disco compartilhado se manteve por muitos anos, até o
Failover Cluster do Windows Server 2008 R2.
No Windows Server 2012 R2, iniciamos um desacoplamento dos discos
compartilhados, o que só foi concretizado oficialmente no Windows Server
2016, com o Storage Space Direct e, até mesmo, com o SQL Server Always e
o Exchange Server, com o Database Availability Group (DAG). Este último
utiliza uma tecnologia de software para replicar seu banco de dados entre
discos locais, em cada servidor.
Recuperação de Desastres
Refere-se a um plano de contingência para recuperação de desastres, para que
a empresa continue a operar. Esta recuperação de dados envolve várias cópias
dos dados de produção em um local físico separado. Por exemplo, um cluster
estendido, em que metade dos nós está em um site e a outra metade em outro.
A preparação para desastre refere-se a um plano de contingência para mover
cargas de trabalho para um local diferente, em caso desastre iminente, como
um furacão e enchentes por exemplo.
Nível de Acordo de Serviço (SLA)
O SLA é um contrato que define a disponibilidade de aplicativos de uma
empresa, e sua tolerância em relação ao tempo de inatividade e perda de
dados durante interrupções planejadas ou não.
O tempo de recuperação (RTO) define por quanto tempo a empresa poderá
tolerar a total falta de acesso aos seus dados.
O ponto de recuperação (RPO) define a quantidade de dados cuja perda a empresa pode
suportar.
Replicação Síncrona
A replicação síncrona garante que o aplicativo grave dados em dois locais ao
mesmo tempo, antes da conclusão da entrada e saída (I/O). Essa replicação é
mais adequada para dados críticos, pois exige investimentos em
armazenamento e rede, além de envolver o risco de degradação do
desempenho de aplicativos.
Quando as gravações ocorrem nos dados de origem, o armazenamento de
origem não reconhece o I/O imediatamente. Em vez disso, essas alterações de
dados são replicadas para a cópia de destino remoto e retornam uma
confirmação. Somente então, o aplicativo recebe a confirmação de E/S. Isso
garante a sincronização constante do local remoto com o local de origem,
garantindo que o armazenamento de I/O esteja ocorrendo, de fato, na rede.
Em caso de falha no local de origem, os aplicativos podem fazer failover para
o local remoto do site e retomar as operações, sem perda de dados.
Replicação Assíncrona
Diferentemente do que ocorre na síncrona, na replicação assíncrona o
aplicativo replica os dados para o local remoto sem garantias de confirmação
imediata. Essa modalidade permite um tempo de resposta mais rápido para o
aplicativo, e um funcionamento geográfico da solução de recuperação de
desastre.
Quando os dados são gravados, o mecanismo de replicação captura a
gravação e imediatamente informa sua aplicação. Em seguida, os dados
capturados são replicados para o local remoto. O nó remoto processa a cópia
dos dados e os reconhece lentamente para a cópia de origem. Como o
desempenho de replicação não está mais no caminho de I/O do aplicativo, a
capacidade de resposta e a distância do local remoto são fatores menos
importantes. Haverá risco de perda de dados, se a fonte de dados for perdida,
e a cópia de destino dos dados ainda estiver no buffer, sem sair da origem.
Se o RPO for maior que zero, a replicação assíncrona será menos adequada
para soluções de alta disponibilidade, pois elas são projetadas para operação
contínua, com redundância e sem perda de dados, como é o caso do Cluster
de Failover.
Cluster de Failover
Um cluster de failover é um grupo de computadores independentes que
trabalham juntos para aumentar a disponibilidade (recurso anteriormente
conhecido como “clusterizado”). Os servidores em cluster (chamados de nós)
são conectados por cabos físicos e por software. Se um ou mais nós falham,
outros nós começam a fornecer o serviço, processo conhecido como failover).
Além disso, as funções de cluster estão sendo monitoradas proativamente.
FIGURA 05-01. Console do Failover Cluster Manager
O serviço de Failover Cluster do Windows Server 2016 permite agrupar
servidores físicos ou virtuais para aumentar a disponibilidade de serviços, tais
como: servidores de arquivos, máquinas virtuais do Hyper-V, DHCP,
aplicações genéricas, instâncias do SQL Server, base de dados do Exchange
Server e aplicações de terceiros compatíveis. O Failover Cluster suporta até
64 nós.
O serviço de cluster pode ser instalado pelo Server Manager ou pelo
PowerShell.
Install-WindowsFeature -Name FailoverClustering -
IncludeManagementTools
Quando se cria um cluster de failover tradicional, exige-se um disco
compartilhado para que o serviço (uma máquina virtual, por exemplo) possa
ser armazenado. Seguem, abaixo, os tipos de armazenamento compartilhado:
Tipos de Armazenamento
Serial Attached SCSI (SAS)
Adequado para cluster de failover de dois nós, quando estes estão próximos
um do outro.
iSCSI Storage. Adequado para cluster de failover com dois ou mais nós. O
Windows Server inclui o software Iscsi initiator para conectar-se, como
cliente, ao Storage Iscsi e à função iSCSI Target, que transforma o Windows
Server em um servidor NAS (Network Attached Storage)
Fibra Ótica. O Fibre Channel (FC) e o Fibre Channel over Ethernet (FCoE)
requerem adaptadores de rede especiais, uma HBA (Host Bus Adapter) e
FCoE, respectivamente. Embora elas ofereçam melhor desempenho que o
iSCSI, seus componentes tendem a ser mais caros.
SMB 3.1.1. O Server Message Block 3.1.1 é um tipo especial de
compartilhamento de arquivos altamente disponível, com múltiplos nós de
cluster capazes de manter o acesso ao compartilhamento de arquivo. O SMB
3.1.1 é o principal protocolo que sustenta a replicação dos volumes em um
cluster de Storage Space Direct e de Scale Out File Server.
Volumes Compartilhados do Cluster
O Cluster Shared Volume (CSV) foi introduzido, pela primeira vez, no
Windows Server 2008 R2. Ele é um recurso de sistema de arquivo de acesso
distribuído, otimizado para suportar dados de aplicativos. O CSV permite que
vários nós do cluster acessem simultaneamente um único volume
compartilhado.
A instalação do serviço de cluster usou um modelo de armazenamento
compartilhado, e com propriedade, o que significa que cada disco é de
propriedade de um único nó, e somente esse nó poderia executar transações
de entrada e saída nesse disco específico. Este modelo também implica que a
menor unidade de failover para um cluster está no nível do disco lógico, e
não no nível do volume. Isso resulta na necessidade de administradores para a
criação de LUNs individuais para cada aplicativo em um cluster, de forma a
alcançar recursos de failover independentes para cada aplicativo.
Quando convertido em CSV, um disco pode ser usado para armazenamento
de máquinas virtuais em clusters de failover, e para armazenar VHDX
compartilhado em guest clusters (cluster entre máquinas virtuais). Também se
exige um disco CSV para a criação de um File Server no modelo Scale Out
File Server. O disco CSV elimina a necessidade de usar uma letra do alfabeto
para identificá-lo, pois todos os volumes são montados como pasta, em
C:\ClusterStorage\VolumeX , onde X é uma sequência de números.
Cluster Quorum
Quando participamos de um evento onde o número mínimo de pessoas não
comparece, como uma reunião de condomínio, por exemplo, dizemos que a
reunião foi cancelada por falta de quórum. Ou quando vamos jogar uma
partida de futebol e o time adversário não apresenta o número mínimo de
jogadores, o jogo também é cancelado por falta de quórum.
FIGURA 05-02. Cluster de três nós com três votos configurado como Node
Majority onde somente os nós votam.
O quórum para um cluster tem significado parecido. Temos quórum quando
há votos suficientes para manter o serviço do cluster funcionando, ou seja,
50% dos votos mais 1.Em um cluster de dois nós, por exemplo, temos dois votos, (50%+1), então
não temos margem para falha. Se perdemos um dos nós, teremos um único
voto, o que causará a interrupção do serviço de cluster. Isso explica a
necessidade de ter 3 votos para um cluster de dois nós. Mas, afinal contas, de
onde vem este terceiro voto? O que definirá a quantidade de votos de um
cluster de failover é o tipo de quórum que você escolher para o cluster.
Existem 4 tipos de quórum:
Maioria de Nós (Node Majority Set). Somente os nós do cluster votam.
Este modelo é muito usado quando o número de nós de um cluster é
ímpar.
Maioria de Nós e Discos (Node and Disk Majority). Significa que tanto
os nós quanto os discos votam. Este é o caso quando o número de nós do
cluster é par e os nós estão próximos um do outro.
Maioria de compartilhamentos de nós e arquivos (File Share
Witness). Muito similar ao modelo Maioria de Nós e Discos, mas os
votos vêm dos nós do cluster e de um compartilhamento de rede, que pode
estar localizado em outro site.
Cloud Witness. Novo no Windows Server 2016, permite obter um voto
adicional através de uma Conta de Armazenamento na nuvem no
Microsoft Azure. Deve ser usado, preferencialmente, para cluster
geográficos (stretched clusters), clusters sem discos compartilhados, e
guest clusters entre máquinas virtuais no Azure. É necessário ter uma
assinatura do Azure e acesso ao Access Key da Conta de Armazenamento
para configurá-lo.
Na instalação inicial de um cluster de failover, o Windows Server identifica
qual o melhor tipo de quórum para o ambiente, com base no número de nós, e
verifica se há discos compartilhados que podem ser usados como voto
adicional.
FIGURA 05-03. Log da criação de um Failvoer Cluster
Quórum Dinâmico
Pode-se alterar o tipo de quórum manualmente a qualquer momento, mas no
Windows Server 2016 há um mecanismo chamado Dynamic Quorum que o
altera
automaticamente, adicionando ou removendo o tipo de quórum de um
cluster.
Esta técnica permite aumentar a resiliência do cluster, contanto que as quedas
dos votos sejam sequenciais.
FIGURA 05-04. Remoção manual do voto em um dos três nós.
Forçar Quorum
Quando se perde a maioridade dos votos, ou mesmo quando o Quórum
Dinâmico for incapaz de recalcular os votos, os clusters serão interrompidos
e o evento ID 1177 será reportado no visualizador de eventos. É importante
investigar por que o quórum do cluster foi perdido, e é preferível trazer o
voto de um nó ou o quórum de disco para um estado saudável, a iniciar um
cluster em modo forçado.
Se, emergencialmente, houver a necessidade de subir o serviço do cluster em
um nó, mesmo sem a maioridade dos votos, é possível executar o seguinte
comando:
 
net start clussvc /fq
 
Ao iniciar o cluster em um nó, é necessário iniciar os nós restantes no seu
cluster, com uma configuração que não exija quórum. Um nó iniciado com
uma configuração que impeça a exigência de Quorum ao serviço do cluster,
une-se a um cluster em execução, ao invés de formar uma nova instância de
cluster. Isso evita que os nós restantes formem um cluster dividido em duas
instâncias concorrentes. Para iniciar os nós restantes no serviço de cluster,
use o comando abaixo:
net start clussvc /pq
 
Conscientização do Site
Recurso novo no Windows Server 2016, o Site Awareness tem a capacidade
de agrupar os nós de cluster, com base em sua localização física ou site. E
qual é a vantagem disso? Uma vez que o serviço de cluster sabe quais nós
pertencem a um site, pode ser feito um failover de uma carga de trabalho
primeiro nesse site, antes de incorrer no alargamento de banda de rede ou em
uma penalidade no failover desta carga de trabalho para outro site.
No caso de máquinas virtuais, esperamos um minuto antes de fazer qualquer
balanceamento antes de migrar as VMs. Para isso, deve-se configurar no
cluster os Domínios de Falha (Fault Domain).
Domínios de Falha
Não há interface gráfica para configurar os domínios de falha (Fault
domains). Para criá-los, use o PowerShell. Abaixo, o comando New-
ClusterFaultDomain cria dois sites chamados SaoPaulo e Toronto. Usando o
comando Set-ClusterFaultDomain, eu declaro quais são os nós que pertencem
a cada site, e o último comando declara qual site é o preferencial. Neste caso,
o site SaoPaulo.
New-ClusterFaultDomain –Name SaoPaulo –FaultDomainType Site –
Description “Primary” –Location “Sao Paulo Data Center”
 
New-ClusterFaultDomain –Name Toronto –FaultDomainType Site –
Description “Secondary” –Location “Toronto Data Center”
 
Set-ClusterFaultDomain –Name Node01 –Parent SaoPaulo
Set-ClusterFaultDomain –Name Node02 –Parent SaoPaulo
Set-ClusterFaultDomain –Name Node03 –Parent Toronto
 
(Get-Cluster). PreferredSite = “SaoPaulo”
 
FIGURA 05-05. Dois nós em São Paulo e um em Toronto
Site Preferido
É possível configurar um site preferido para todo o cluster ou para o grupo de
cluster. Considere o site preferido como principal, e os demais sites como
secundários. Em um evento de “Cold Start”, iniciaremos as máquinas virtuais
nos servidores do site preferido primeiro.
No caso do Quórum Dinâmico, ele começará a remover os pesos do site
secundário antes do site primário, para garantir a sobrevivência do site
preferido. Durante um Quorum Split, ou seja, a divisão uniforme de dois
datacenters sem testemunha (Witness), o site preferido é o eleito
automaticamente para se salvar.
Os nós do site secundário (DR) abandonam a associação do cluster. Isso
permite que o cluster sobreviva à perda de 50% dos votos. A propriedade
LowerQuorumPriorityNodeID, que controlava esse comportamento nas
versões de failover clusters anteriores, foi descontinuada no Windows Server
2016.
Antes que os site preferidos possam ser configurados, o site escolhido como o
preferido deve ser atribuído a um conjunto de nós do cluster. Para configurá-
lo, execute o seguinte comando do Powershell:
(Get-Cluster). PreferredSite = SaoPaulo
O site preferido também pode ser configurado na granularidade de um grupo
de recurso do cluster, ou seja, um site preferido diferente pode ser
configurado para cada grupo, permitindo que um datacenter seja ativo e
preferido para cada grupo específico. Para configurar um site preferido para
um grupo de recurso, use o comando abaixo do PowerShell:
(Get-ClusterGroup -Name GroupName). PreferredSite = SaoPaulo
 
A prioridade de posicionamento do site preferido é dada para a afinidade de
armazenagem, seguida pelo grupo de recurso e, por último, o cluster.
Resiliência à Falhas
Este recurso foi projetado para aumentar a resiliência das máquinas virtuais à
falha, quando o nó físico do Hyper-V perde conectividade de rede com outros
nós. As VMs continuam em execução, mesmo quando o nó é expulso do
cluster.
No Windows Server 2012 R2, troca-se o heartbeat uma vez por segundo entre
os nós. Se 10 sinais são perdidos, expulsa-se o nó do cluster e as máquinas
virtuais entram em estado de falha. Já no Windows Server 2016, se um nó
exceder o limite de heartbeat (mesmo acima de 10 sinais), permite-se que
esse nó seja excluído da associação do cluster e o serviço de cluster pare. As
máquinas virtuais, porém, continuarão em execução. Por padrão, este
procedimento é configurado para 4 minutos.
ResiliencyLevel é uma opção de configuração que define como as falhas
desconhecidas serão tratadas.
Nível Descrição
1 Permite que o nó esteja em estado isolado, contanto que
o nó tenha sido descartado por motivo conhecido. Caso
contrário, ocorre uma falha imediata.
Exemplos: falha no serviço de cluster ou conectividade
assimétrica entre os nós.
2 O nó fica permanentemente em estado isolado, e leva
um certo tempo para assumir a posse das máquinas
virtuais.
Para alterar este valor, basta usar o comando abaixo do PowerShell.
(Get-Cluster). ResiliencyLevel=2
Como resultado desse comando, temosnovos estados de nós do cluster, e das
máquinas virtuais. O nó do cluster apresenta o modelo isolado.
Também pode-se controlar a quantidade de tempo que as VMs devem se
manter isoladas. O padrão é 4 minutos. Chegamos a este número,
conversando com os clientes sobre o tempo que uma mudança leva para ser
reiniciada. A resposta foi cerca de 3 minutos. Assim, surgiu o padrão de 4
minutos. Mas é possível configurar esse tempo para cima ou para baixo.
(Get-Cluster). ResiliencyDefaultPeriod=240
O mesmo pode ser feito para a VM. Em geral, a maioria usa 4 minutos, mas
para máquinas virtuais críticas, que necessitam monitoramento, pode-se
definir um menor período de resiliência.
(Get-ClusterGroup “VMName”).ResiliencyPeriod=120
As máquinas virtuais executadas neste nó, agora ficarão como não
monitoradas.
Modo de Manutenção
Ao colocar um nó de um cluster de Hyper-V em modo de manutenção (
Drain Mode) executa-se a migração ao vivo de todas as máquinas virtuais
neste nó para outro, dentro do mesmo cluster. Caso pretenda seguir as
melhores práticas, coloque os nós em modo de manutenção, o que também
migrará as VMs para outros nós, e liberará este servidor para manutenção,
instalação de atualizações, e posterior reinicialização.
O principal benefício do modo de manutenção é que, no caso de termos um
dia ruim e nos esquecermos de colocar um nó no modo de manutenção antes
de desligá-lo ou reiniciá-lo, todas as máquinas virtuais em execução serão
migradas, sem exigir nossa intervenção direta.
FIGURA 05-06. Drain Role em um dos nós do cluster
Dependências do Active Directory
No Windows Server 2012, foram tomadas medidas para minimizar as
dependências do Active Directory, permitindo-se que os clusters iniciassem
sem dependência de um controlador de domínio. Com isso, tornou-se
possível virtualizar datacenters inteiros, incluindo controladores de domínio,
trazendo à tona a polêmica questão do ovo e da galinha: como virtualizar um
controlador de domínio que está rodando como máquina virtual, dentro de
um cluster de Hyper-V?
Além disso, embora os CNO (Computer Name Objects) e VCO (
Virtual Names Objects) sejam criados por padrão, temos opções para criar
clusters desacoplados do Active Directory, via PowerShell, que não
dependam dos nomes de computador criados no Active Directory. Neste
caso, o nome virtual do cluster depende somente do nome registrado no DNS,
principalmente para suportar o SQL Server.
FIGURA 05-07. CNO HV01, HV02 e HV03 e VCO HASITEBR no Active
Directory
Uma conta de usuário local chamada CLIUSR é criada, por padrão, em cada
nó do cluster. Esta conta não é administrativa ou de domínio, mas
completamente autogerida pelo serviço de cluster. Ela é lida com a rotação
automática da senha da conta, e sincronizada entre todos os nós. A senha da
conta CLIUSR é alterada na mesma frequência que o CNO, conforme
definido pela sua política de domínio. Por padrão, ela é alterada a cada 30
dias.
FIGURA 05-08. Usuário local de serviço CLIUSR
Como se trata de uma conta local, ela pode autenticar e montar volumes CSV
para que os controladores de domínio virtualizados possam ser iniciados com
sucesso. Virtualize todos os seus controladores de domínio sem medo.
Para configurar o NTLMv2 com segurança, sem restringir o NTLM,
certifique-se de excluir os nós do cluster. Caso contrário, seu cluster deixará
de funcionar.
Atualização de Failover Cluster
A atualização de Failover Cluster 2012 R2 para 2016 agora ficou mais
simples. É possível adicionar novos nós Windows Server 2016 em um cluster
2012 R2 existente. Isso permite que se atualize um cluster sem tempo de
inatividade. O cluster é executado em um nível funcional Windows Server
2012 R2 até a atualização de todos os nós, e do nível funcional do domínio,
através do comando Update-ClusterFunctionalLevel.
Para cluster de Hyper-V que rodam nós Windows Server 2012 R2 e 2016,
atente-se para as seguintes observações:
Gerencie o Failover Cluster e o Hyper-V de uma máquina Windows
Server 2016 (sempre com a versão mais atualizada). 
Mova as máquinas virtuais entre todos os nós do Cluster.
Para instalar todas as novas funcionalidades do Cluster e Hyper-V 2016,
primeiro é preciso elevar o nível funcional.
A versão da configuração da VM criada no Hyper-V 2012 R2 é 5.0 e, no
Hyper-V 2016, é 8.0. O cluster impede a atualização da versão 5.0 para
8.0, quando o nível funcional do cluster ainda estiver em Windows Server
2012 R2.
Depois que todo o cluster estiver rodando no Windows Server 2016, com
nível funcional elevado, pode-se utilizar o comando Update-
VMConfiguration.
Após elevar o nível funcional para Windows Server 2016, não será
possível retornar para o Windows Server 2012 R2.
 
Prioridade de Máquinas Virtuais
Este recurso oferece mais controle sobre quais máquinas virtuais em cluster
serão iniciadas, ou reiniciadas, primeiro. Isso facilita o início de máquinas
virtuais que forneçam serviços, antes das máquinas virtuais que usam estes
serviços. Defina um grupo de máquinas e especifique dependências entre
elas. Para isso, use os cmdlets do PowerShell:
New-ClusterGroupSet
Get-ClusterGroupSet
Add-ClusterGroupSetDependency
 
Grupo de Trabalho e Multi-Domínio
No Windows Server 2016, introduzimos a possibilidade de formar clusters
entre nós que pertencem a diferentes domínios do Active Directory, inclusive
entre servidores em grupo de trabalho, ou seja, aqueles que não pertencem a
um domínio do Active Directory.
Porém, na prática, estas opções de instalação são mais limitadas do que se
imagina, e dificilmente serão adotadas. Existem muitas armadilhas nestes
ambientes, especialmente quanto a políticas de grupo que podem variar entre
domínios e tornar divergentes as configurações dos nós em um cluster. Além
do mais, para clusters de Hyper-V, a migração ao vivo não funcionará em um
cluster entre hosts de Hyper-V em grupo de trabalho, tendo em vista que o
protocolo Kerberos é exigido.
Servidores de arquivos dificilmente serão configurados em um cluster fora de
um domínio, pois as permissões de usuário (Access Control List) seriam
perdidas.
Se deseja testar a criação de um Cluster entre dois servidores em grupo de
trabalho crie uma conta de usuário local com o mesmo nome e senha em
ambas as máquinas. Adicione a conta ao grupo Local Admin, vá até as
propriedades do servidor e adicione um sufixo de DNS ao nome do servidor.
Instale a função Failover Cluster, pelo Server Manager ou PowerShell, e
forme o cluster via Powershell, com o parâmetro -AdministrativeAccessPoint
DNS.
New-Cluster -AdministrativeAccessPoint DNS
 
Balanceamento de Carga de Rede
O recurso de balanceamento de carga de rede (Networking Load Balancing -
NLB), do Windows Server 2016, aprimora a disponibilidade e escalabilidade
de aplicativos, tais como servidores web, ftp, proxys e rdps, entre outros de
missão crítica. Um único computador não consegue atender apropriadamente
um serviço (SLA) elevado de 99,9% de disponibilidade. No entanto, ao
combinarmos os recursos de dois ou mais computadores, o NLB pode
fornecer a confiabilidade e SLA elevado exigidos pelos serviços de missão
crítica.
O NLB trabalha na camada 4 (transporte) do modelo OSI, e não na camada 7
(aplicação), como é o caso da maioria dos serviços de Balanceamento de
Carga baseado em hardware de terceiros, tais como o F5 da fabricante BigIP,
e o appliance NetScaler, da Citrix.
Cada nó executa uma cópia separada dos aplicativos. O NLB distribui
pedidos de clientes recebidos em todos os nós do cluster. O peso da carga a
ser gerenciada por cada nó pode ser configurado, conforme sua necessidade.
Ainda, é possível adicionar nós dinamicamente ao cluster para lidar com o
aumento de carga. Além disso, o NLB pode direcionar todo o tráfego para um
único nó designado, que é chamado de host padrão.
O NLB permite que todos os computadoresdo cluster sejam endereçados no
mesmo conjunto de endereços IPs, e mantém um conjunto de endereço IP
exclusivo para cada nó. Para aplicações com balanceamento de carga, quando
um host falha ou fica offline, a carga é redistribuída automaticamente entre os
computadores que ainda estão operando. No entanto, se o host é derrubado
intencionalmente pode-se usar o comando DRAINSTOP para atender todas
as conexões ativas antes de se desligar o computador.
Os hosts em um cluster NLB trocam mensagens de heartbeat para manter
dados consistentes sobre a associação do cluster. Por padrão, quando um host
para de enviar mensagens de heartbeat a cada 5 minutos, ele é considerado
um nó indisponível ou falho. Quando um host falha, os hosts restantes do
cluster convergem e procedem conforme abaixo:
Estabelecem quais nós ainda são membros ativos do cluster.
Escolhem um nó com maior prioridade como novo nó padrão.
Certificam-se de que todos os novos pedidos de clientes sejam atendidos
pelos nós sobreviventes.
Um cluster NLB pode apresentar até 32 nós, mas esses nós não coexistem
com o serviço de Failover Cluster. Ou eles pertencem a um cluster NLB, ou a
um cluster de Failover Cluster, nunca ambos.
O serviço de NLB não dependem do Active Directory, mas necessitam do
protocolo NTLM, principalmente para autenticação e inclusão de novos nós.
A única condição para seu funcionamento é que o nome de usuário local e
senha sejam iguais em todos os nós.
O NLB pode operar em dois modos: Unicast e Multicast. Entenderemos,
agora, a diferença entre eles para que você saiba qual escolher em diferentes
cenários.
Unicast
É o modo de operação padrão do NLB. No modo Unicast, o NLB altera o
endereço MAC da sua placa de rede em todos os nós para um único endereço
MAC virtual. Desta forma, todos os pacotes enviados para os endereços IP
destes servidores serão, na verdade, enviados para um único endereço MAC.
Todos os nós do cluster usam o mesmo endereço MAC. O tráfego de rede irá
para todos eles e será encaminhado para o controlador de filtro NLB.
O modo Unicast apresenta dois problemas já conhecidos. Primeiro, como os
nós terão o mesmo endereço MAC, eles não poderão se comunicar entre si, o
que nos obriga a adicionar uma segunda placa de rede em cada máquina. O
segundo efeito colateral mais nocivo, e que já gerou diversos chamados de
suporte na Microsoft, é o Switch Flooding. Por não ser capaz de identificar
onde os nós estão, uma vez que as portas estão com o mesmo endereço MAC,
o NLB envia os pacotes para todas as portas do Switch, incluindo aquelas
onde os nós do NLB não estão conectados. O switch de rede pode entrar em
colapso e comprometer a comunicação de toda sua rede.
A boa notícia é que existem duas maneiras de se conter o Switch Flooding. A
primeira, e menos usada, é utilizar um segundo Switch para conectar todos os
nós do NLB, pois assim todos se conectam em uma única porta do Switch
com o mesmo endereço MAC. A segunda, e mais aconselhável, é configurar
uma VLAN para os servidores NLB, de forma a conter o Switch Flooding
apenas nas portas configuradas na VLAN.
Multicast
No modo de Multicast, o NLB adiciona um novo endereço MAC para a placa
de rede de cada nó participante. Assim, esse nó NLB terá dois endereços
MAC: o original e o do NLB. O problema com este modelo é que o endereço
VIP não é acessível por equipamentos que estejam em outra subrede, pois os
roteadores não aceitam levar pacotes ARP para um endereço Unicast que
contêm um MAC Multicast. E como não é possível determinar em qual porta
estão os MACs, o Switch Flooding funciona exatamente como o Unicast.
Para que o modo Multicast funcione sem Switch Flooding é necessário criar
entradas estáticas nos Switches para que os pacotes sejam enviados apenas
para os membros do NLB. Tendo em vista que os endereços MAC originais
não são alterados, as máquinas podem ter um único adaptador de rede cada.
Pesquise Unicast Flooding em Switches Campus Network, no site da
Cisco.com, para saber como configurar os switches da família Catalyst.
IGMP Multicast
O Internet Group Membership Protocol (IGMP) ajuda a eliminar o Switch
Flooding. Para isso, ative a detecção de IGMP no switch e certifique-se de
conectar o adaptador de rede de cada nó do cluster a uma porta exclusiva do
switch. Quando se seleciona a opção IGMP Multicast nas propriedades do
NLB, cada nó do cluster envia periodicamente uma mensagem “IGMP Join”,
que identifica o grupo multicast ao qual o nó pertence. Ao receber essa
mensagem de associação, o switch pode associar as portas que tem um host
de NLB conectado a um grupo multicast. Os pacotes de entrada são
destinados ao endereço de controle de acesso apenas para as portas que
possuem um nó do cluster NLB.
FIGURA 05-09. Modo de operação de um cluster NLB
Caso esteja configurando um cluster NLB entre máquinas virtuais, antes
deve-se permitir o MAC Address Spoofing nas propriedades de cada VM.
Caso ele não esteja habilitado, uma mensagem de erro será enviada ao se
tentar formar o cluster.
Set-VMNetworkAdapter -VMName <Name> -MacAddressSpoofing On
 
Instale o serviço de balanceamento de carga de rede pelo Server Manager ou
PowerShell:
Install-WindowsFeature NLB
 
FIGURA 05-10. Instalação do NLB pelo Server Manager
Crie seu primeiro cluster NLB pela console NLB ou PowerShell. O comando
abaixo cria um cluster chamado ClusterNLB, com um endereço IP virtual
(VIP) 10.10.10.10, e um nó na própria máquina.
New-NLBCluster -InterfaceName Etherner -ClusterPrimaryIP 10.10.10.10 -
Clustername ClusterNLB
 
FIGURA 05-11. Interface do Network Load Balancing Manager
Hyper-V Replica
O Hyper-V Replica fornece uma cópia de uma VM executada em um host
Hyper-V, que pode ser armazenada e atualizada em outro host Hyper-V. Por
exemplo, pode-se configurar uma VM hospedada em um Hyper-V em São
Paulo, incluindo o Hyper-V em Clusters, para ser replicada, através do
Hyper-V Replica, a outro Hyper-V no Rio de Janeiro.
O Hyper-V Replica permite a replicação entre os limites do local e não requer
acesso ao armazenamento compartilhado, como outras soluções exigem. Essa
foi uma das primeiras funcionalidades de Software Defined Storage da
Microsoft, que elimina a necessidade de armazenamentos tradicionais,
incluindo o pagamento de licenciamento para ter acesso a serviços de
replicação. O Hyper-V Replica é gratuito.
A replicação é assíncrona. Embora a réplica seja consistente, trata-se de uma
cópia atrasada, cujas alterações são enviadas a cada 30 segundos. Isso
significa que, ao ativar a réplica, pode-se optar por ativar a cópia mais
atualizada ou uma cópia anterior. A ativação de uma cópia anterior se
justifica, em caso de corrupção ou alteração na cópia atualizada.
O Hyper-V Replica no Windows Server 2012 ocorre a cada 5 minutos, sem
direito de alteração. No Windows Server 2012 R2, os valores ficaram mais
flexíveis com as opções de 30 segundos, 5 ou 15 minutos, e foram mantidos
no Hyper-V 2016. Já a extensão da replicação está restrita a 5 e 15 minutos
de intervalo.
Quando se executa um failover planejado do host principal para a réplica, é
preciso desligar o primário. Isso garante que a réplica seja consistente e
atualizada. Esta é uma desvantagem, quando comparada ao failover ou
migração ao vivo, em que a VM permanece disponível durante o processo.
Uma série de verificações devem ser concluídas antes de se executar o
failover planejado, de forma a garantir que: a VM esteja desligada; uma
replicação reversa seja aplicada ao host primário original; o estado da VM da
réplica atual seja consistente com o estado da VM primária. A realização de
um failover planejado iniciará a VM replicada na réplica original, que agora
se tornará o novo servidor primário.
O Hyper-V Replica também suporta failover não planejado. A execução de
um failover não planejado ocorre quando o host Hyper-V original falha, ouo
local que hospeda a réplica primária torna-se indisponível. Ao executar o
failover não planejado, pode-se escolher o ponto de restauração mais recente
ou um anterior. Assim como no failover planejado, o não planejado iniciará a
VM na réplica original, que agora se tornará o novo servidor primário.
Para verificar se o processo de recuperação é válido e consistente, basta fazer
um teste de failover. Neste caso, a máquina virtual réplica iniciará com a
placa de rede desconectada, para possibilitar a conexão no console e a
validação da integridade dos dados. A mesma VM rodará simultaneamente
em hosts Hyper-V separados. Ao desfazer o teste de failover, a VM réplica é
desligada e a replicação retorna a seu processo normal.
A replicação estendida do Hyper-V também permite a criação de uma
segunda réplica do servidor de réplica existente. Por exemplo, quando se
configura uma replicação de uma VM no Hyper-V em São Paulo para um
Hyper-V no Rio de Janeiro. Instala-se uma réplica estendida em Curitiba,
usando a réplica do Rio de Janeiro.
Mas as versões do Hyper-V Replica apresentam um problema célebre. Os
discos virtuais que eram adicionados após a réplica da VM não entravam na
fila de replicação. Havia o risco de clientes acharem que a máquina virtual, e
todos os seus discos, estivessem sendo replicados. Era necessário parar a
réplica e criá-la novamente. Isso foi resolvido no Hyper-V 2016. Logo após a
inclusão de um novo disco, execute o comando abaixo para incluí–lo no
conjunto de replicação já estabelecido.
Set-VMReplication -VMName Name -ReplicatedDisks (Get-
VMHardDiskDrive VMName)
 
Hyper-V Replica Broker
Se a origem, ou o destino, da réplica for um Hyper-V em Failover Cluster,
primeiro será necessário adicionar um recurso chamado Replica Broker. Vá
até o Failover Cluster Management, clique com o botão direito, selecione
Add new rule e escolha Replica Broker. Um novo nome e IP serão criados no
Cluster. É este nome que deve ser habilitado para receber a réplica, e será o
nome que seu Hyper-V de origem deverá usar para referenciar o servidor
Hyper-V replica. Nunca se deve utilizar o nome real do servidor, mas sim o
nome virtual do cluster representado pelo Replica Broker, que orquestrará a
replicação entre todos os nós.
FIGURA 05-12. Hyper-V Replica Broker
Live Migration
A migração ao vivo (Live Migration) é o processo de mover uma ou mais
máquinas virtuais de um host de Hyper-V para outro, sem interrupção para
clientes ou usuários. A migração ao vivo é suportada entre os nós de um
cluster que compartilham o mesmo armazenamento de dados e entre hosts de
Hyper-V separados, que não participam de um Failover Cluster, mas utilizam
um compartilhamento de arquivo SMB 3.0 como armazenamento.
A migração ao vivo apresenta os seguintes pré-requisitos:
Deve haver dois ou mais servidores Hyper-V utilizando o processador do
mesmo fabricante.
Não é possível mover uma máquina virtual de um host Intel para um
AMD.
Os hosts de Hyper-V precisam ser membros do mesmo domínio, ou
devem ser membros de um domínio que tenham relação de confiança
entre si.
As máquinas virtuais devem ser configuradas para discos rígidos virtuais
ou fibra ótica virtual.
É possivel executar a migração ao vivo com VMs configuradas com
discos de passagem (pass-through), nas seguintes condições:
As VMs devem estar hospedadas em um Failover Cluster de Hyper-V.
A migração ao vivo deve ocorrer dentro de nós que participam do mesmo
cluster de Failover.
Os arquivos de configuração da VM devem estar armazenados em um
volume CSV.
O disco físico usado como disco pass-through é configurado como um
recurso de disco de armazenamento controlado pelo Failover Cluster.
O disco pass-through deve ser configurado como um recurso dependente
da VM para a execução da migração ao vivo.
O compartilhamento do SMB 3.0 precisa ser configurado para que as
contas de computador do host de Hyper-V, tanto de origem quanto de
destino, tenham permissão de leitura e gravação.
Todos os arquivos da VM (discos virtuais, arquivos de configuração e
checkpoints) devem estar localizados no mesmo compartilhamento SMB
3.0. Pode –se utilizar o método Storage Migration primeiro para reunir
todos os arquivos em um só repositório.
É possível configurar os hosts de Hyper-V de origem e de destino para
suportar a migração ao vivo. Esse procedimento permite especificar o
número máximo de migrações simultâneas e as redes que serão utilizadas
para a transferência.
O próximo passo na configuração da migração ao vivo é a escolha do
protocolo de autenticação e das opções de desempenho. Estes itens são
selecionados na área de recursos avançados. O protocolo de autenticação
padrão é o Credential Security Support Providers (CredSSP).
O CredSSP requer o início da sessão local do host de virtualização do Hyper-
V (origem e destino) para executar a migração ao vivo. Isso exigirá que se
esteja conectado ao console do próprio servidor via RDP. Já o Kerberos
permite que se acione a migração remotamente.
Para usar o Kerberos, configura-se as contas de computador para cada host de
Hyper-V com delegação restrita para CIFS e o serviço Microsoft Virtual
System Migration Services, concedendo permissões aos hosts que
participarão da parceria da migração ao vivo. Os hosts podem ser um
computador Windows 10 + RSAT.
As opções de desempenho permitem acelerar a transferência. A compressão
amplia a utilização do processador. O SMB usará o SMB Direct, contanto
que ambos os adaptadores de rede usados para o processo suportem o recurso
RDMA (Remote Direct Memory Access), e estejam habilitados.
Migração de Armazenamento
Diferentemente da migração ao vivo, que transfere uma VM entre hosts
mantendo intactos seus discos virtuais, na técnica de migração de
armazenamento pode-se mover de um local para outro os discos virtuais de
uma VM, checkpoints, Smart paging files e arquivos de configuração. A
migração de armazenamento pode ser executada enquanto a VM está em
execução, ou enquanto estiver desligada. Os dados podem ser movidos para
qualquer local acessível ao host Hyper-V. Ou seja, move-se dados de um
volume para outro, de uma pasta para outra, ou mesmo para um
compartilhamento de arquivos SMB 3.0 em outro computador. Ao executar a
migração de armazenamento, escolha a opção mover a memória virtual.
Exportação e Importação
Uma exportação de máquina virtual cria uma duplicação dela, que pode ser
importada no mesmo host ou em um diferente. Ao executar uma exportação,
é possível optar por exportar a VM incluindo seus pontos de restauração, caso
existam. O Windows Server 2012 R2 e 2016 suportam a exportação da VM
em execução. Em versões anteriores, era necessário desligar a VM antes da
exportação.
Quando se exporta uma VM com todos os seus pontos de restauração, cria-se
vários discos diferenciais. Quando se importa uma VM que tenha sido
exportada com os pontos de restauração, eles também serão importados. Ao
importar uma VM que esteja sendo executada no momento da exportação, a
VM será colocada em um estado salvo. Continua-se a partir deste estado
salvo, ao invés de reiniciar a VM.
Para importar uma VM, pode-se escolher entre as seguintes opções:
Register the virtual machine in-place (use the existing ID). Use esta
opção quando quiser importar a VM, mantendo seus arquivos em sua
localização atual. Como este método usa o ID da VM existente, só é
possível utilizá-lo se a VM original não estiver presente no host para o
qual se deseja importá-la.
Restore the virtual machine (use the existing Unique ID). Use esta
opção quando quiser importar a VM enquanto movimenta os arquivos
para uma nova localização. Por exemplo, se estiver importando uma VM
que tenha sido exportada para um compartilhamento de rede. Com este
método também se usa a ID da VM existente, o que significa que ele só
pode ser empregado se a VM original, a partir da qual a exportação foi
criada,não estiver presente no host para o qual se deseja importá-la.
Copy the virtual machine (create a new unique ID). Use este método
para criar um clone separado da VM exportada. Os arquivos exportados
serão copiados para uma nova localização, deixando inalterados os
arquivos originalmente exportados. Uma nova ID de VM é criada, o que
significa que a VM clonada pode ser executada simultaneamente à VM
original, no mesmo host de virtualização. Ao importar uma VM clonada
para o mesmo host de virtualização original, certifique-se de renomear a
VM recém-importada, caso contrário elas podem ser confundidas.
Detecção da Saúde da Rede
O Network Health Detection é um recurso para máquinas virtuais que são
implantadas em um cluster de Hyper-V. Define-se as configurações de um
adaptador de rede da VM e marca-se certas redes como protegidas. Isto é
feito na sessão de recursos avançados do adaptador de rede.
No caso de uma VM estar em execução em um nó de um cluster onde a rede
marcada como protegida está indisponível, este cluster irá, automaticamente,
migrar a VM para outro nó onde a rede protegida esteja disponível. Por
exemplo, em um cluster de failover de Hyper-V de quatro nós, cada nó possui
vários adaptadores de rede e um switch virtual chamado Corporativo (um
switch externo para um adaptador de rede físico). Uma VM configurada em
alta disponibilidade e hospedada no nó1 está conectada à rede do switch
Corporativo. O adaptador de rede desta VM está configurado com a opção de
rede protegida. Após a VM ser ligada e executada por algum tempo, ocorre
uma falha no adaptador de rede físico do servidor. Quando isso acontece, a
VM será automaticamente migrada para outro nó do cluster, onde o switch
virtual corporativo esteja funcionando.
Storage Space Direct (S2D)
O Storage Space Direct é a evolução do Storage Space. Não mais restrita aos
discos locais do mesmo servidor, essa função habilita a criação de
armazenamento altamente disponível e escalável, usando servidores com
armazenamento local em um Failover Cluster de até 16 nós. Ele simplifica a
implantação e o gerenciamento de sistemas de armazenamento definidos por
software, e desbloqueia o uso de novas classes de dispositivos de disco, como
os SATA SSD e NVMe, que anteriormente não eram compatíveis com o
Storage Pool em um cluster com discos compartilhados.
O Storage Space Direct usa servidores padrão de mercado, com unidades de
discos conectadas localmente para criar um armazenamento definido por
software disponível e escalável, com custo menor do que redes tradicionais
de armazenamento SAN ou NAS. Sua arquitetura convergente, ou hiper
convergente, simplifica a aquisição e a implantação, pois os armazenamentos
compartilhados tradicionais deixam de existir (EMC, NetApp, HPE,
HITACHI, IBM), enquanto os recursos de caching, camadas de
armazenamento, juntamente com as mais recentes inovações em hardware,
como redes RDMA e unidades NVMe, oferecem desempenho e eficiência.
Nesta sessão, descreveremos os requisitos mínimos de hardware do S2D.
Utilizaremos máquinas virtuais para demonstração, mas para ambientes de
produção recomendo a aquisição de uma oferta de hardware homologada pela
Microsoft, com o selo de Software Defined Storage, que inclui
procedimentos e ferramentas de implantação em produção. Estes servidores
são projetados e validados pela Microsoft para ambientes de nuvem privada,
como o Microsoft Azure Stack, o que contribui para a garantia de uma
operação confiável.
Os requisitos adicionais para um cluster de Storage Space Direct são:
Servidores
Mínimo de 02 e máximo de 16 servidores.
Todos os servidores devem ser da mesma marca e modelo.
Memória
04 GB de RAM por terabyte (TB) da capacidade de unidade de cache em
cada servidor, para armazenar metadados do S2D. Observe que os tamanhos
de RAM usam numeração base 2, em que 1 GB = 1024 MB, enquanto as
unidades são anunciadas usando a numeração de base 10 (em que 1 TB =
1000 GB). Então, cuidado! Se cada servidor tem 2 discos de cache de 1,6 TB
(capacidade anunciada no disco), deve-se manter 2 x 1.6 x 4096 MB =
13,107 MB (12,8 GB) de memória disponível para o uso interno do S2D.
Rede
Mínimo de 10 Gbps de interface e rede para comunicação dentro do
cluster.
Recomenda-se duas NICs para redundância e desempenho.
Recomenda-se NICs compatíveis com acesso remoto direto à memória
RDMA, iWARP ou RoCE.
Unidades de Disco.
Unidades SATA, SAS ou NVMe conectadas localmente (iSCSI não é
suportado).
Cada disco deve estar fisicamente conectado a um único servidor.
Todos os servidores do cluster devem ter os mesmos tipos de unidade (se
um servidor tiver NVMe, todos eles exigem o NVMe. Se um tiver HDD,
todos os demais exigem HDD).
Aconselha-se que todos os servidores tenham a mesma configuração de
unidade, incluindo tipo, tamanho e firmware.
Os discos SSD (Solid State Drivers) devem ter proteção contra perda de
energia. Isso quer dizer que os discos precisam ser de níveis empresariais
(profissionais).
Orienta-se que os discos de cache tenham resiliência elevada à gravação:
pelo menos 3 unidades de gravações por dia (DWPD), ou pelo menos 4
TB (TBW) escritos por dia.
É altamente recomendado que os discos de cache sejam SSD ou NVMe.
Os blocos podem ser de 512n, 512e ou 4K nativas, desde que todas
funcionem igualmente bem.
Deve-se usar discos separados para a instalação do sistema operacional.
200 GB é o tamanho mínimo recomendado.
Recomenda-se uma capacidade bruta máxima de 1 peta byte (1024 TB)
por pool de armazenamento.
Se houver discos para cache, o número mínimo deve ser de 02 por
servidor.
São necessários, pelo menos, 04 discos conectados localmente (sem
cache) por servidor.
Sem suporte para dispositivos SAN (Fiber Channel, Iscsi, FCoE)
Os clusters S2Dnão são exclusivos para Cluster de Hyper-V. Mas quando sua
função estiver vinculada à virtualização, ela pode ser implementada nos dois
cenários abaixo:
Hiperconvergido: quando o cluster de Hyper-V está sendo executado no
próprio cluster de S2D, todos os componentes fazem parte da solução.
Desagregado: quando o cluster de Hyper-V e de Discos S2D estão
separados e a conexão entre eles é feita pela rede SMB3.
Observe que, para os ambientes de produção, recomendo adquirir uma oferta
de hardware homologada pela Microsoft, com a solução de Software Defined
Storage, conforme apresentado no início desta sessão. Estas ofertas são
projetadas, montadas e validadas a fim de atender aos requisitos da Microsoft
para ambientes de nuvem privada, ajudando a garantir uma operação
confiável.
FIGURA 05-13. Hyper-V Cluster e modo Hiperconvergido
Para avaliar o S2D sem investir em hardware, use as máquinas virtuais do
Hyper-V como os exemplos que demonstrarei aqui. Será necessário criar, no
mínimo, duas máquinas virtuais com o Windows Server 2016 Datacenter, e
inseri-las ao domínio do Active Directory. Para cada máquina, será
necessário adicionar 02 discos de dados locais, no mínimo.
Crie um Failover Cluster pelo Failover Cluster Manager, ou pelo PowerShell:
Test-Cluster -Node Node1, Node2 -Include “Storage Space Direct”,
“Inventory”, “Network”, “System Configuration”
New-Cluster -Name Clustername -Node Node1, Node2 -NoStorage
Habilite a camada de S2D somente pelo PowerShell:
Enable-ClusterS2D
Ou
Enable-ClusterStorageSpacesDirect -CimSession Clustername
 
# Desabilite o CacheState se você está habilitando o S2S em máquinas
virtuais, caso contrário receberá uma mensagem de erro
Enable-ClusterS2D -CacheState Disabled
Os discos que serão usados pelo S2D devem estar vazios, e sem partições ou
outros dados. Se um disco tiver partição ou outros dados, ele não será
incluído no pool do S2S. Após a conclusão desse comando, o que pode
demorar alguns minutos, o sistema estará pronto para a criação de volumes.
FIGURA 05-14. Servidores do cluster agrupados em Enclosures
Recomendo usar o cmdlet New-Volume, poisele proporciona a experiência
mais rápida e mais direta. Este cmdlet cria automaticamente o disco virtual e
sua partição. Além de formatá-lo, cria o volume com o nome correspondente
e o adiciona à volumes compartilhados do cluster (CSV)
O cmdlet New-Volume apresenta quatro parâmetros que sempre devem ser
fornecidos:
FriendlyName: qualquer cadeira de caracteres que desejar, por exemplo
Volume1.
FileSystem: ou CSVFS_ReFS (recomendado, ou CSVFS_NTFS.
StoragePoolFriendlyName: o nome do seu pool de armazenamento, por
exemplo “S2D em Clustername”.
Size: o tamanho do volume. “5TB”, por exemplo.
Exemplo com 2 ou 3 servidores.
Para maior facilidade, se sua implantação tiver apenas dois servidores, o S2D
usará automaticamente o espelhamento de duas vias para resiliência. Se sua
implantação tiver apenas três servidores, o espelhamento de três vias será
usado automaticamente.
New-Volume -Friendlyname “Volume1” -FileSystem CSVFS_ReFS -
StoragePoolFriendlyname S2D* Size 1TB
Exemplo com 4 ou mais servidores.
Em caso de quatro ou mais servidores, deve-se usar o parâmetro
ResiliencySettingName para escolher o tipo de resiliência.
ResiliencySettingName: Mirror ou Parity
No exemplo a seguir, “Volume2” usa espelhamento de três vias, e o
“Volume3”, usa paridade dupla.
New-Volume -FriendlyName "Volume2" -FileSystem CSVFS_ReFS -
StoragePoolFriendlyName S2D* -Size 1TB -ResiliencySettingName Mirror
New-Volume -FriendlyName "Volume3" -FileSystem CSVFS_ReFS -
StoragePoolFriendlyName S2D* -Size 1TB -ResiliencySettingName Parity
Abaixo, segue um exemplo usando camadas de armazenamento.
Em implantações com três tipos de unidades, um volume pode abranger as
camadas SSD e HDD, para residir parcialmente em cada uma delas. Da
mesma forma, em implantações com quatro ou mais servidores, um volume
pode misturar espelhamento e paridade dual para residir parcialmente em
cada um.
Para ajudá-lo a criar estes volumes, o S2D fornece modelos de camada
padrão chamados Desempenho (Performance) e Capacidade (Capacity). Eles
encapsulam definições para espelhamento de três vias nas unidades mais
rápidas de capacidade (se aplicável), e paridade dual nas unidades mais lentas
de capacidade (se aplicável). É possível visualizá-las pelo comando Get-
StorageTier:
Get-StorageTier | Select FriendlyName, ResiliencySettingName,
PhysicalDiskRedundancy
Para criar volumes em camadas, referencie esses modelos usando os
parâmetros StorageTierFriendlynames e StorageTierSizes do cmdlet New-
Volume. Por exemplo, o cmdlet a seguir cria um volume que combina
espelhamento de três vias e paridade dual em proporções 30:70.
New-Volume -FriendlyName "Volume4" -FileSystem CSVFS_ReFS -
StoragePoolFriendlyName S2D* -StorageTierFriendlyNames Performance,
Capacity -StorageTierSizes 300GB, 700GB
Também pode-se criar volumes usando o assistente New Virtual Disk, pela
console do Failover Cluster Management. Mas esse fluxo de trabalho não é
aconselhado, por envolver muitas etapas manuais.
Simulado
Questão 01
Em um ambiente de Shared Nothing Live Migration, a migração ao vivo
entre dois hosts ________________ incluir uma migração de armazenamento
simultânea.
A. não deve
B. pode
C. deve
D. não pode
Questão 02
Em um modelo tradicional de configuração de Failover Cluster do Windows
Server, qual é o número mínimo de redes distintas que devem ser
configuradas em suporte à comunicação de cluster?
A. Uma
B. Duas
C. Três
D. Quatro
Questão 03
Ao configurar o Hyper-V Replica para replicar máquinas virtuais entre hosts
de Hyper-V, qual será a frequência padrão?
A. Uma hora
B. Duas horas
C. Três horas
D. Quatro horas
Questão 04
Você foi convidado a configurar um cluster estendido (stretched cluster) que
exista em dois locais distintos. Qual das seguintes afirmações é verdadeira,
em relação ao armazenamento compartilhado desse cluster?
A. Será criada uma instância de armazenamento compartilhado e os hosts em
ambos os locais desta instância serão conectados.
B. Serão criadas duas instâncias de armazenamento compartilhado e todos os
hosts serão conectados ao armazenamento no local principal.
C. Serão criadas duas instâncias de armazenamento compartilhado e os hosts
serão conectados ao armazenamento no local.
D. Será criada uma instância de armazenamento compartilhado e os hosts
serão conectados apenas no local principal desse armazenamento.
Questão 05
Qual o cmdlet PowerShell é necessário para informar um Failover Cluster, do
Windows Server, em que os nós estão posicionados em locais separados?
A. Set-Cluster
B. Set-ClusterSite
C. New-ClusterSite
D. New-ClusterFaultDomain
Questão 06
Qual das seguintes configurações de resiliência do Storage Space Direct
oferece a maior eficiência de desempenho?
A. Single parity
B. Three-way mirroring
C. Dual parity
D. Two-way mirroing
Questão 07
Um Failover Cluster do Windows Server será criado e o Storage Space Direct
será usado para hospedar o armazenamento compartilhado. Qual das
seguintes opções contêm a ordem correta dos cmdlets do PowerShell para
criação deste cluster?
A. Test-Cluster, Create-Cluster, Install-WindowsFeature, Set-
ClusterQuorum, Enable-ClusterS2D
B. Install-WindowsFeature, Test-Cluster, Enable-ClusterS2D, Create-
Cluster, Set-ClusterQuorum
C. Install-WindowsFeature, Test-Cluster, Create-Cluster, Set-
ClusterQuorum, Enable-ClusterS2D
D. Install-WindowsFeature, Test-Cluster, Set-ClusterQuorum, Enable-
ClsuterS2D, Create-Cluster
Questão 08
Qual, dentre os seguintes tipos de disco virtual, suporta múltiplos acesso,
juntamente com o backup de dados, replicação de dados, redimensionamento
de volume e migração de disco?
A. .VHDX
B. Shared .VHDX
C. .VHDS
D. .VHD
Questão 09
Qual das seguintes opções não é um serviço do Windows que pode ser
hospedado como um recurso de um Failover Cluster?
A. iSNS
B. DNS
C. DFS-
D. File Server
Questão 10
Qual modo de operação do balanceamento de carga de rede (NLB) exige uma
segunda placa de rede para segregação do tráfego?
A. Multicast
B. Unicast
C. IGMP Multicast
D. Todas as opções acima
Questão 11
Os nós de cluster que são configurados como No Preferred Owners de uma
função______________ hospedar a função. Os nós de cluster que são
configurados como No Possible Owners __________ hospedar está função.
A. podem; nunca irão
B. nunca irão; nunca irão
C. podem; podem
D. nunca irão; podem
Questão 12
Você está implementando o Kerberos Constrained Delegation para autenticar
a transferência de arquivos VHDX entre hosts de Hyper-V e deseja ativar o
uso de arquivos ISO em um compartilhamento de arquivo remoto, por
máquinas virtuais nestes hosts. Qual serviço deve ser configurado para
apresentar as credenciais delegadas?
A. Microsoft Virtual Console Service
B. Microsoft Virtual System Migration Service
C. Cifs
D. Browser
 
Questão 13
Qual dos seguintes cmdlets PowerShell pode ser usado para fazer uma
migração ao vivo (Live Migration) de uma máquina virtual, bem como de seu
disco VHDX para um novo host Hyper-V?
A. Copy-Item
B. Migrate-VM
C. Move-VM
D. Move-VMStorage
Questão 14
Quantos discos são necessários pelo Storage Replica para replicar um volume
entre dois locais?
A. Um
B. Dois
C. Três
D. Quatro
Questão 15
Qual modelo de Failover Cluster requer a instalação de um Scale Out File
Server (SOFS), de forma que os hosts Hyper-V agrupados possam acessar
seus arquivos VHDX?
A. Locally-attached SAS
B. Hyper-converged S2D
C. Disaggregated S2D
D. Traditional
Questão 16
Qual das seguintes configurações de resiliência, de um disco virtual do
Storage Space Direct, podem suportar o menor número de falhas
simultâneas?
A. Single parity
B. Dual parity
C. Three-way mirroing
D. Mixed
Questão 17
Foi criado um Failover Cluster do Windows, que usa o Storage Space Directpara armazenamento compartilhado. Qual sistema deve ser configurado em
um volume com suporte S2D para hospedar máquinas virtuais do Hyper-V
em um volume CSV?
A. FAT
B. ReFS
C. NTFS
D. FAT32
Questão 18
Qual dos seguintes modelos de quórum não é suportado pelo Failover
Cluster, quando os nós são membros de um Workgroup ou estão em vários
domínios?
A. Todos as os modelos são suportados
B. Cloud Witness
C. File Share Witness
D. Disk Witness
Questão 19
Qual, dentre os seguintes recursos do Windows Server 2016, é usado para
equilibrar máquinas virtuais, e o uso de recursos em nós de um Failover
Cluster?
A. Drain on Shutdown
B. Node Fairness
C. Network Health Protection
D. VM Monitoring
Questão 20
Qual o modo de operação de um balanceamento de carga de rede (NLB) é
geralmente utilizado nos ambientes de produção, tendo em vista que não
causa network Flooding?
A. IGMP Multicast
B. Multicast
C. Unicast
D. Todos os modos causam network Flooding
 
Respostas
01-
C
02-B 03-
C
04-
C
05-
C
06-
A
07-
C
08-
C
09-B 10-B
11-
A
12-
C
13-
C
14-
D
15-
C
16-
A
17-B 18-
C
19-B 20-
A
 
 
 
CAPÍTULO 06 – Manter e
Monitorar Servidores Windows
O Windows Server 2016 traz muitas ferramentas e opções para
gerenciamento e manutenção, que poderão ser utilizadas na administração
diária dos servidores físicos ou virtuais.
Vamos começar pelo gerenciamento de atualizações (patches) e de
Antimalware. Você aprenderá como construir sua própria infraestrutura de
WSUS (Windows Server Update Services), e verá como administrar e
automatizar, de forma centralizada, o gerenciamento de patches.
Em seguida, aprenderemos a trabalhar com o Windows Server Backup, para
criação e agendamento das tarefas de backup e restauração de arquivos.
Ainda, exploraremos o backup de servidores comuns no dia a dia, tais como
servidores de arquivos, servidores web e controladores de domínio.
Veremos como monitorar instalações do servidor e usar ferramentas como o
Performance Monitor e Resource Manager para criar linhas de base de
desempenho, e identificar tendências que permitem planejar o crescimento
dos serviços ao longo do tempo.
Ao final vamos conhecer a nova interface web para administração de
servidores Windows, o Windows Admin Center (WAC) e os serviços do
Remote Desktop Services incluindo a nova interface web do Remote Desktop
Web Access baseada agora em HTML 5.0 com suporte para todos
navegadores de mercado.
Gerenciamento de Atualizações (WSUS)
Os servidores Windows podem obter patches da Microsoft automaticamente,
quando há uma conexão direta ou por proxy para a Internet, e onde as
atualizações serão baixadas e instaladas através do Windows Update. Mas
esse procedimento funciona bem para pequenos ambientes, enquanto é
ineficiente para grandes organizações. Para estes casos, precisamos do
WSUS.
Com o Windows Server Update Services, é possível ter um sistema de
gerenciamento de atualizações eficiente para seus servidores e, também, para
seus desktops e notebook. O WSUS é gratuito e apresenta em poucas
configurações de políticas de grupo e regras de acesso à Internet, podendo ser
implementado rapidamente no ambiente.
O termo Patch Tuesday (também conhecido como Update Tuesday, ou
atualizações de terça-feira) já é bem conhecido pelos administradores do
Windows Server. É um termo não oficial, usado para se referir aos
lançamentos regulares de patches de segurança para os produtos Microsoft. O
termo Patch Tuesday é tão amplamente reconhecido pela indústria, que a
Microsoft acabou por adotá-lo como oficial ,em outubro de 2003.
O servidor WSUS vai até o site do Windows Update, baixa as atualizações
localmente e as distribui para seus servidores, assim que aprovadas. O
consumo de banda de rede é reduzido, quando se usa esse procedimento para
baixar as atualizações
É possível agrupar seus computadores e escolher as atualizações realmente
compatíveis com cada sistema operacional envolvido.
Nos Estados Unidos, o Patch Tuesday ocorre na segunda e, às vezes, na
quarta terça-feira de cada mês. As atualizações aparecem no Download
Center antes de serem adicionadas ao Windows Update, e tanto os artigos
KB, quanto o boletim de segurança do TechNet, são liberados mais tarde.
A Microsoft faz, por norma, a liberação de atualizações mais frequentes em
meses pares, e menos frequentes em meses ímpares. Atualizações menores
também são descartadas pelo Patch Tuesday. As atualizações diárias incluem
atualizações de banco de dados de malware do Windows Defender e
Microsoft Security Essentials.
FIGURA 06-01. Console do WSUS
Para instalar um servidor de WSUS, será necessário um mínimo de recurso.
Um servidor físico ou virtual com um processador x64, com no mínimo 2
GB de memória, e um mínimo de 10 GB de espaço em disco, sendo
recomendado 40 GB ou maior. Um único servidor WSUS suporta até
100.000 clientes.
Quando se implementa um servidor WSUS, nota-se que uma das
dependências é o IIS. Isso ocorre porque o WSUS, e os computadores
clientes, se conectam usando HTTP.
Por padrão, o site do IIS do WSUS responde na porta TCP 8530, mas este
tráfego HTTP não é seguro. Há também a opção de instalar um certificado
SSL para garantir o tráfego seguro e, neste modelo, a comunicação com o
WSUS ocorrerá na porta TCP 8531, para estabelecerem uma conexão
HTTPS.
Dois ou mais servidores WSUS podem ser balanceados através do
Balanceamento de Carga de Rede do Windows (NLB), ou até mesmo com
balanceadores de terceiros. Mas como o WSUS tem por norma armazenar
suas configurações em um banco de dados Windows Internal Database, é
preciso ter um SQL Server Standard, ou em Cluster, fora dos servidores
WSUS.
O Windows Internal Database é usado para ambientes de um único servidor e
para servidores WSUS distribuídos em filiais (diferentes regiões). Já a versão
do SQL Server é usada quando se tem mais do que 100.000 computadores, ou
até mesmo quando o número é menor, mas se exige alta disponibilidade em
conjunto com o NLB.
Quando múltiplos servidores WSUS são executados, e se quer ter uma
relação de distribuição entre eles, configura-se os servidores em Upstream e
Downstream.
Quando se configura um WSUS para buscar atualizações no Windows
Update pela Internet, ele é considerado um servidor Upstream. Os demais
servidores também podem ser Upstream, mas se ao invés de selecionar o
Windows Update, optar-se pelo servidor Upstream como fonte de download
das atualizações, este servidor se chamará Downstream.
Os servidores Downstream tem duas opções de configuração:
Modo autônomo. O servidor ainda baixa as atualizações do servidor
Upstream, mas tem seus próprios conjuntos de configuração, dando
autonomia ao administrador local para fazer alguns ajustes, incluindo a
aprovação ou rejeição de atualizações para os computadores do seu
próprio local.
 
Modo réplica. Quando o servidor Downstream é configurado como
réplica, o servidor continua fazendo download das atualizações do
servidor Upstream, mas herda todas as suas configurações.
 
Após a instalação, a configuração inicial e a primeira sincronização com o
Windows Update, expanda Computers e Unassigned Computers. Todos os
computadores que pertencem a um grupo definido entrarão nesta lista. Crie
seus próprios grupos. Depois com botão direito, clique em All Computers e
selecione Add Computer Group.
Agora, basta especificar quais computadores serão associados a estes grupos.
Clique em Options \ Computers, altere a opção You can specify how to
assign computers to groups De: Use the Update Service console Para: Use
Group Policy or registry settings on computers.
Finalmente, crie uma GPO para os computadores que deseja configurar para
buscar as atualizações no WSUS. Na GPO, expanda conforme abaixo:
Computer Configuration \ Policies \ Administrative Templates\ Windows
Components \ Windows Update
 
A primeira Configuração é a opção “Configure Automatic Updates”.
Selecione Enable, escolha a frequência e as ações, entre em notificar para
download e notificar para instalação. Faça o download automático e selecione
notificar para instalação. Em seguida, faça o download automático e agende
para instalação. Por último, permita que o administrador escolha as
configurações.
A segunda política que será necessária habilitar é “Specify intranet Microsoft
updates service location”, nos campos “set the intranet update service for
delecting” e “set the intranet statistics server” .Inclua o nome totalmente
qualificado na sua rede local, com a porta 8530. Exemplo
http://wsus.banin.net.br:8530
A última política necessária é a “Enable cliente-side targeting. Selecione
Enabled e, no campo Target group name for this computer, preencha com o
nome do grupo criado no console do WSUS.
Execute um gpupdate /force no seu servidor e, logo após, gpresult /r, para
certificar que a GPO foi aplicada. Neste momento, já é possível visualizar o
servidor no grupo adequado, no console do WSUS. Antes , não esqueça de
alterar o status para Any, e clicar em Refresh.
Atualizações do Windows Defender
O Windows Defender é o software antivírus e Antimalware incorporado no
Windows 10, e no Windows Server 2016. Os arquivos de definição do
Windows Defender são baixados do Windows Update, o que significa que se
pode , também, configurar o WSUS para baixar e instalar estas atualizações
de antivírus e Antimalware, ao mesmo tempo que são mantidos atualizados
em seus servidores.
Em Options do WSUS selecione Product and Classifications, localize o
Windows Defender e marque-o na guia classification. Escolha Definition
Updates.
Backup do Windows Server
Quando o NT Backup foi aposentado, no lançamento do Windows Server
2008, muitos clientes ficaram insatisfeitos. Por muitos anos, o NT Backup
salvou muitos ambientes de desastres baseados em servidores Windows
Server 2003. Embora o Windows Server Backup não seja a melhor
ferramenta corporativa para políticas de backup e restauração mais
sofisticadas, é melhor tê-lo do que não ter nenhum backup, como já ouvi de
vários clientes. Ele é simples, mas eficiente, no que se propõe a fazer.
Antes de começarmos a executar backups no Windows Server 2016, primeiro
precisamos instalar o serviço do Backup do Windows Server nos servidores.
Existem duas maneiras de fazer isso. Remotamente, via seu computador
Windows 10 bastando adicionar a função “Windows Server Backup” ou
através do PowerShell:
Install-WindowsFeature Windows-Server-Backup
 
A console do Backup do Windows Server não é encontrada no RSAT do
Windows 10. Se o objetivo é administrar o backup remotamente, será
necessário um servidor rodando o Windows Server 2016.
FIGURA 06-02. Console do Windows Server Backup
A opção Bare Metal Recovery é tudo o que você precisa para restaurar o seu
servidor do zero, a partir de uma inicialização com a mídia do Windows
Server 2016. Quando se marca esta opção, o estado do sistema será marcado
automaticamente.
Se o Backup do Windows Server estiver instalado em um servidor Hyper-V,
ainda haverá duas outras opções: Hyper-V, para fazer o backup de máquinas
virtuais. Mas cuidado! O backup pode deixar a VM temporariamente em
estado. Para o backup de controladores de domínio, basta fazer o backup do
estado do sistema.
Para fazer o backup de um servidor de arquivos que, muito provavelmente,
copiará um volume inteiro, recomenda-se otimizar o desempenho, clicando
na opção Optimize Backup Performance para escolher entre as seguintes
opções:
Normal Backup Performance. O tempo para criar o backup é
proporcional ao tamanho dos dados que estão sendo copiados.
Faster Backup Performance. Aumenta a velocidade do backup,
ajustando o rastreamento das mudanças entre o último backup e o atual.
Isso pode reduzir a taxa de transferência do disco em volumes incluídos
no backup. Esta opção não é recomendada para servidores com discos de
operações intensivas.
Custom. Configure cada volume separadamente, em caso de volumes
com operações intensivas. É possível escolher entre um Backup Completo
e Backup Incremental.
Ao escolher a unidade ou pasta, pode-se escolher entre duas opções: VSS full
backup e copy backup
VSS full backup. Escolha esta opção, se não estiver usando outras
soluções de backup para as aplicações em uso nos volumes deste backup.
Esta opção atualiza o histórico do backup em cada arquivo, e limpa os
logs das aplicações.
VSS copy backup. Escolha esta opção, se estiver usando outro produto de
backup para as aplicações em uso nos volumes deste backup. Esta opção
mantem os logs das aplicações.
 
Pode-se escolher como destino de backup: um disco dedicado na própria
máquina (todos os dados que estiverem no disco serão perdidos); um volume
ao qual não se quer dedicar um disco todo para backups; e um
compartilhamento de rede (\\servername\share). O WSB não faz backup em
fita (tape library).
PowerShell Backup
O backup também pode ser executado pelo PowerShell.
$policy = New-WBPolicy
$filespec = New-WBFileSpec -FileSpec C:\Temp\Book.docx
Add-WBFileSpec -Policy $policy -FileSpec $filespec
$backuplocation = New0WBBackupTarget -NetworkPath
“\\server\backup\backups”
Add-WBBackupTarget -Policy $policy -Target $backuplocation
Set-WBVssBackupOptions -Policy $policy -VssCopyBackup
Start-WBBackup -Policy $policy -Async
 
Não se preocupe em memorizar todos estes comandos, mas lembre-se que o
comando para iniciar o backup é Start-WBBackup, e que o parâmetro –
Async é usado para que o backup seja executado em segundo plano. Para
monitorar o progresso do backup, use o comando Get-WBJob.
Fazer um backup de um servidor web IIS significa fazer o backup de dois
componentes. O primeiro, são os arquivos da aplicação, tais como como
HTML, ASPX, PHP, CSS. O segundo, o backup das configurações do IIS,
conhecido como IIS metabase , que é feito pelo cmdlet Backup-
WebConfiguration, e não pelo WBS. Todos os backups do IIS serão salvos
em C:\Windows\System32\inetsrv\backup. Então, lembre-se também de
colocar esta pasta na lista de backup.
Backup-WebConfiguration -Name IISBackup
 
Gerenciador de Tarefas
Certamente, você deve estar familiarizado com o Gerenciador de Tarefa
(Task Manager). É ele que sempre vem a memória quando o servidor não
está desempenhando bem a sua função, e apresentando lentidão. Para acioná-
lo, clique em uma área vazia no Barra de Tarefas e, em seguida, selecione
Task Manager. Além de clicar nas teclas de atalho CTRL+ALT+DELETE e
selecionar Task Manager,
Nota
O atalho mais comum para acionar o gerenciador de tarefas a qualquer
momento é a seguinte combinação de teclas: CTROL + SHIFT + ESC
 
Lembre-se de que o gerenciador de tarefas é usado para fazer o
monitoramento de desempenho em tempo real, particularmente para solução
de problemas de desempenho.
FIGURA 06-03. Task Manager
Na primeira guia, chamada Processes, podemos ver todos os processos em
execução divididos em subcategorias, tais como apps, background process,
windows process. Basicamente, a ideia é ter uma visão geral sobre o
consumo de CPU e memória de cada processo no seu tempo exato de
execução.
A segunda guia, Performance, dá uma visão mais aprofundada? sobre o
status atual da CPU, da memória e da ethernet. A categoria Ethernet nos
mostra quanto de tráfego de rede estamos consumindo. Em CPU, podemos
ver a utilização em %, a velocidade em Ghz, a quantidade de processos,
“threads”, “handles”. Na parte de “Up Time”, sabemos há quanto tempo o
servidor está ligado. Além disso, podemos descobrir a quantidade de
processadores físicos, cores, lógicos, e se a virtualização está habilitada para
este processador, o que é um pré- requisito para instalação do Hyper-V.
Na terceira guia, Users, identificar é possível identificarquais são os usuários
conectados ao sistema operacional e quais processos eles estão executando.
Somente os usuários conectados localmente, ou pelo Remote Desktop, serão
listados. Os usuários conectados por sessões remotas do PowerShell, com o
comando Enter-PSSession, não entram nesta lista. Como administrador, você
pode desconectar usuários, enviar mensagens para eles, ou até mesmo
conectar em suas sessões remotas para um suporte assistido através dessa
interface.
Na quarta guia, Details, encontram-se o nome exato do processo, seu status,
número PID (que é único para cada serviço), o consumo de memória e a
descrição de cada processo. Ao clicar com o botão direito em cada processo
há várias opções, como encerrar tarefa, aumentar prioridade, criar um mini
dump (memory.dmp), e ir até a localização do arquivo.
Na quinta guia, Services, encontram-se todos os serviços do sistema
operacional. É, como se executássemos o atalho services.msc, possibilitando
parar, iniciar ou reiniciar um serviço a qualquer momento.
Monitor do Sistema
Além do o Gerenciador de Tarefas, também se utiliza o Monitor do Sistema
(Resource Monitor) para monitoramento de desempenho em tempo real Este
último é uma ferramenta mais moderna, disponível no Windows Server 2016
e pode ser encontrado no meu iniciar, bastando digitar Resource Monitor. Há,
também, um atalho para ele na guia Performance, do Gerenciador de Tarefas.
Na guia Overview, há um dashboard com o resumo imediato dos quatro
principais pilares de monitoramento: CPU, Memória, Disco e Rede. E uma
guia de detalhes aparece em cada um deles.
FIGURA 06-04. Resource Monitor
Visualizador de Eventos
Uma das ferramentas mais usadas, quando se trata de monitorar servidores e
localizar problemas, é o Visualizador de Eventos (Event Viewer). Ele permite
a visualização dos arquivos de log e a obtenção de informações sobre
aplicativos, eventos de segurança, de sistema, e até mesmo eventos
relacionados a ferramentas e aplicativos específicos relacionadas ao Windows
Server. O Visualizador de Eventos fica localizado em Windows
Administrative Tools, mas basta digitar Event Viewer, no menu iniciar, ou
clicar com o botão direito no logo do Windows (no menu iniciar) e selecionar
Event Viewer.
FIGURA 06-05. Event Viewer
Também é possível utilizar o Powershell para localizar eventos no Event
Viewer:
Get-EventLog -LogName Application -Newest
 
Caso esteja desenvolvendo algum aplicativo, ou até mesmo scripts
PowerShell para automação de alguma tarefa, e deseja registrar os eventos no
Event Viewer, é possível criar o seu próprio log, conforme segue:
Net-EventLog -LogName Application -Source MyCustomApp
Write-EventLog -LogName Application -Source MyCustomApp -EvnetID
911 -EntryType Error -Message ‘Falha na conexão ao servidor entre em
contato com o administrador’
 
Também se pode designar uma tarefa (Task) para um determinado tipo de
evento, caso ele ocorra, bastando clicar em Attach Task to This Event. O
Schedule Task será aberto para a criação de uma tarefa agendada, que será
executada toda vez que este evento ocorrer.
Gerenciador do Servidor
O Gerenciador do Servidor (Server Manager) é muito mais do que a principal
ferramenta de instalação ou exclusão de funções do sistema operacional. Por
meio dele, centraliza-se a administração dos servidores, especialmente o
Server Core e o Nano Server.
Ele pode, ainda, criar grupos que correspondam às funções dos servidores,
executar o BPA (Best Practice Analizer), visualizar os eventos mais críticos,
iniciar ou parar serviços, iniciar uma sessão do Remote Powershell,
configurar NIC Teaming, gerenciar discos, reiniciar servidores e muito mais.
Quando se clica em um servidor remoto com o botão direito, pelo
Gerenciador do Servidor, o menu de ações se adapta aos serviços que estão
sendo executado no servidor. Desta forma, as opções de um controlador de
domínio serão diferentes das de um servidor de arquivos.
Os eventos mais críticos serão visualizados em vermelho, o que ajudará a
identificar os eventos que devem ser resolvidos primeiro.
FIGURA 06-06. Server Manager
Monitor de Desempenho
O Monitor de Desempenho (Performance Monitor) existe no Windows
Server desde o Windows 2000, e evoluiu junto com o sistema operacional
nestes últimos anos.. Por padrão, alguns contadores de desempenho são
adicionados ao sistema, e o primeiro da lista é o %Processor Time, que se
refere, essencialmente, a utilização da CPU.
Os contadores são medidas individuais no sistema que se quer analisar, mas
há milhares deles. Praticamente, existe um contador para cada componente do
sistema operacional e, muito provavelmente, eles só são utilizados quando
necessário. Mas alguns deles são mais comuns, como o Disk Transfer/sec.
Quando se trata de construir algo como uma linha de base de desempenho,
recomenda-se ter registros do monitor de desempenho e de todas as métricas
de interesse, de forma que se para que se possa agendar o contador de
desempenho para executar durante um momento em que se está ausente do
escritório, ou durante um período de pico que poderá perdurar por minutos,
horas ou dias. Para tanto, pode-se usar o Data Collector Set e agendar sua
execução em User Defined.
Durante a criação da coleta de dados, é possível criar alertas com base em
condições, tais como o consumo de mais do que 70% de CPU, por exemplo.
Nas propriedades dos alertas, configura-se a ação gerada por este alerta.
Exemplo: o registro de um log no visualizador de eventos, em Applicaton
Log.
Lembre-se! O Data Collector Set é o método do Windows Server para
capturar as informações de histórico de desempenho, para comparação com o
desempenho em tempo real, mais tarde.
FIGURA 06-07. Performance Monitor
Acesso Remoto
O Windows Server 2016 foi projetado para ser administrado remotamente,
afinal este servidor está em um datacenter, ou na nuvem, e raramente se
estará fisicamente em frente a ele para realização de uma manutenção,
customização ou administração.
O conceito de “Remote First” não é algo novo, ou não deveria ser uma
surpresa, para administradores de Windows Server experientes. A estratégia
da administração do servidor Windows Server 2016 deve basear-se no
pressuposto de que estar fisicamente à frente de um servidor deve ser a
exceção, e não a regra. Essa condição exige que se esteja familiarizado com a
forma de usar essas ferramentas remotamente, em vez de iniciar uma sessão
em cada servidor, individualmente, usando o Remote Desktop.
Nota
Automatize sempre que possível. O papel do administrador do servidor
envolve, cada vez mais, a implantação de soluções automatizadas. Quando
o Windows NT4 foi lançado, em 1996, não era incomum que o
administrador médio do Windows Server fosse responsável por gerenciar
menos de 20 servidores físicos. Hoje, devido à automação e virtualização, o
administrador médio responsabiliza-se pelo gerenciamento de centenas,
senão milhares de servidores. A automatização das tarefas que se executa
com mais frequência faz sentido. A longo prazo, isso reduzirá a quantidade
de tempo gasto em tarefas habituais, para que se gaste mais tempo
descobrindo como executar as tarefas que se desconhece.
 
PowerShell ISE
PowerShell Integrated Scripting Environment (ISE) é uma ferramenta
disponível, originalmente, no Windows 10 e Windows Server 2016 para
criar, gerenciar e executar scripts Powershell de maneira mais organizada e
estruturada. O Powershell ISE inclui as seguintes funcionalidades:
Intelisense: fornece a conclusão de código, exige possíveis cmdlets,
parâmetros, valores de parâmetros, arquivos e pastas. A janela de
conclusão de código se estende até a janela de comando.
Color Coding: o código de powershell é baseado em cores para auxiliar a
legibilidade do código. Esta codificação de cores se estende até a janela de
comando.
Visual Debugging: Permite percorrer o códigoPowerShell e configurar e
gerenciar pontos de interrupção.
Brace Matching: permite localizar chaves para garantir que todas as
chaves abertas sejam combinadas com as que fecham {}
Context sensitive help: permite ver informações sobre cmdlets,
parâmetros e valores.
Run all code or just a selection. Em vez de executar todo o código do
PowerShell no painel de script, pode-se, simplesmente, destacar ou
posicionar o cursor na linha do código que se deseja executar., Ao
pressionar a tecla F8, somente a linha marcada será executada.
 
FIGURA 06-08. PowerShell ISE
Caso esteja começando a se aventurar nos primeiros scripts do PowerShell,
recomendo fortemente utilizá-lo. Não perca seus scripts, simplesmente
salvando-os em formato .PS1.
PowerShell Direct
Hoje, os administradores do Hyper-V contam com duas categorias de
ferramentas para conectar-se a uma máquina virtual no host Hyper-V: o
PowerShell Remoting ou o VMConnect do Hyper-V Manager.
Ambas funcionam bem, mas podem ser difíceis de utilizar, à medida que a
implantação do Hyper-V cresce. O VMConnect é confiável, mas de difícil
automatização, enquanto o PowerShell Remoting é uma ferramenta brilhante
de automação, mas pode ser de difícil manutenção, além de ter seu uso
impedido por alguma restrição de firewall ou bloqueio na rede.
Às vezes, escuto clientes lamentarem sobre as exigências de políticas de
grupo do domínio, as configurações de firewall ou a falta de uma rede
compartilhada que permita a comunicação do host de Hyper-V com as
máquinas virtuais que o executam.
O PowerShell Direct permite a conexão a uma máquina virtual a partir do
hypervisor Hyper-V, mesmo sem a conexão de rede entre o host e os guests.
Para que isso ocorra, exige-se um administrador do Hyper-V e as credenciais
do servidor virtual que se deseja administrar. O PowerShell Direct funciona
somente com o Hyper-V 2016 no host, e com os guests Windows Server
2016 e Windows 10.
Enter-PSSession -VMName -Credential $credential
 
FIGURA 06-09. PowerShell Direct
Área de Trabalho Remota
A Área de Trabalho Remota (Remote Desktop) é a maneira pela qual muitos
administradores executam tarefas de forma remota em servidores Windows.
Embora a melhor prática seja a utilização do PowerShell, às vezes é mais
rápido estabelecer uma área de trabalho remota para executar tarefas no
servidor, de uma maneira que se assemelhe à conexão direta no console e,
sem dúvida, será a principal ferramenta para acessar servidores Windows no
Microsoft Azure. O Remote Desktop está desabilitado, por padrão, no
Windows Server.
No entanto, é possível habilitá-lo através da guia Remote, em System
Properties, ou através do seguinte comando PowerShell:
Set-ItemProperty – Path
“HKLM:\System\CurrentControlSet\Control\Terminal Server” -Name
“fDenyTSConnections” -Value 0
 
Também é possível estabelecer conexões RDP, em servidores Windows
Server 2016 Core, mas não em Servidores Nano Servers.
Quando se habilita a Área de Trabalho Remota pela interface gráfica, abre-se,
automaticamente, uma regra de exceção para a porta TCP 3389 no firewall do
Windows. Porém, quando ela é habilitada pelo PowerShell, será preciso
habilitar, manualmente, uma regra já existente ,chamada RemoteDesktop, que
permite a conexão por meio do seguinte comando:
Enable-NetFirewallRule -DisplayGroup “Remote Desktop”
 
Via de regra, a conexão remota permite somente conexões a partir de
computadores com Autenticação em Nível de Rede (Network Level
Authentication) habilitado. O NLA requer que o usuário seja autenticado
antes que a conexão seja estabelecida. Ele é suportado por todos os clientes
Remote Desktop Connection (MSTSC) disponíveis em todas as versões do
Windows, mas pode não é suportado por aplicativos de terceiros.
Uma maneira simples e eficiente para saber se a porta 3389 foi instanciada no
protocolo TCP/IP é executar o comando NETSTAT com o filtro Find.
C:\netstat -an | find “:3389”
 
Serviços de Área de Trabalho Remota
Os Serviços de Área de Trabalho Remota (Remote Desktop Services)
permitem que um aplicativo seja executado em um computador com saída
gráfica exibida em outro computador. O benefício do RDS inclui a permissão
de clientes relativamente pobres em recurso (Thin Clientes) para executar
aplicativos com uso intensivo de recursos remotos, ou para executar
aplicativos que não podem ser executados em um sistema operacional
acessados por usuários de outro sistema como seria o caso de um usuário
Linux ou Mac executar aplicativos patenteados por ou compatíveis somente
com Windows.
Há várias maneiras de se aproveitar o RDS no Windows Server 2016. A
primeira delas é o uso do Remote Desktop Session Host. Neste método de
instalação, os usuários se conectam às sessões de uma área de trabalho
remota executadas em um servidor de um ambiente especial isolado.
FIGURA 06-10. Serviços do Remote Desktop Services
Uma outra maneira de avançar com o RDS no Windows Server 2016 é
através do Remote Desktop Virtualization Host. Por este método, os usuários
se conectam a máquinas virtuais para usar seu ambiente de desktop na
execução de suas aplicações. O Remote Desktop Virtualization Host é o
principal componente para um arquitetura de como Virtual Desktop
Infrastructure (VDI).
A implantação do RDVH difere de outras instalações de funções. Com todos
os outros serviços, seleciona-se a opção de instalação baseada em função, ou
em recurso, ao executar o assistente. Com o RDVH, a escolha da opção de
instalação deve ser feita explicitamente, na configuração inicial, pelo
Gerenciador de Servidor.
Após selecionar a instalação do RDS, a próxima página do assistente permite
escolher entre as seguintes opções:
Standard Deployment. Escolha esta opção se deseja distribuir os
serviços do RDS entre vários servidores. Normalmente, esta é a opção
usada para ambientes corporativos de produção. Caso escolha esta opção,
ainda será preciso decidir entre seguir com o setup usando a opção Virtual
machine-Based (VDI), ou Session-Based (Application).
Quick Start. Use esta opção se deseja instalar todos os componentes em
um único servidor. usada para provas de conceito.
MultiPoint Services. Use esta opção se estiver criando uma solução de
MultiPoint Server. Esta modalidade permite a execução de múltiplos
terminais conectados em um único servidor e é adotada, comumente, em
salas de aula.
 
FIGURA 06-11. Modo de provisionamento para Desktops Virtuais ou
Sessões
Remote Desktop Connection Broker
Quando o usuário inicia uma conexão através da Conexão da Área de
Trabalho Remota ( Remote Desktop Connection) ou RD Web Access, os
usuários se conectam a uma sessão em um servidor RDSH ou VDI. O RDCB
fornece as seguintes funcionalidades:
Conecta os clientes de desktop remoto aos RDSH ou RDVH apropriados.
Reconecta os clientes RDP desconectados para as sessões existentes, tanto
de host, quanto de áreas de trabalho virtuais.
Equilibra a carga entre as conexões, de acordo com as configurações das
coleções.
Permite que as organizações dimensionem os servidores RDSH ou
RDVH, adicionando novos servidores e permitindo um escalonamento
horizontal.
 
Todas as versões anteriores do RDS possibilitavam a conexão direta ao
servidor de sessão. A partir do WS 2012, R2 e 2016 todas as conexões são
medidas pelo Remote Desktop Connection Broker.
As propriedades permitem que se execute as configurações para o RD
Session Host e RD Virtualization Host. por meio do Collections, pode-se
implantar os seguintes serviços:
Remote Desktop Gateway
Remote Desktop Licensing
Remote Desktop Web Access.
 
Será necessário um certificado, que pode ser gerado como auto assinado, ou
importado a partir de um arquivo .pfx (.pfx é o formato de arquivo exportado
que contém o certificado e sua chave privada).
Remote Desktop Session Host
O RDSH fornece um ambiente de desktop completo para um usuário.Os
usuários se conectam ao servidor RDSH a partir de um Thin Client, ou o
Remote Desktop Connection, que é fornecido em sistemas operacionais
Windows (mstsc). Um RDSH fornece uma tela cheia, ou uma janela, que
reproduz uma área de trabalho do Windows, incluindo a barra de tarefas,
menu iniciar e a área de trabalho (Desktop).
Entre os benefícios de uso do RDSH, estão:
A possibilidade de implantar um aplicativo para muitos usuários,
instalando-o em um pequeno número de servidores. Os usuários podem
executar até aplicativos incompatíveis com seus sistemas operacionais;
A atualização de aplicativos é simplificada. O aplicativo é atualizado uma
única vez em um único ponto, não havendo necessidade de distribuir a
atualização para sistemas operacionais individuais;
O acesso a uma experiência de área de trabalho corporativa padronizada
para usuários que desejam utilizar seu próprio computador pessoal no
trabalho. Esse cenário é conhecido como BYOD (Bring Your Own
Device);
A concessão de acesso, por meio de uma VPN, a uma área de trabalho
corporativa padronizada para usuários em locais remotos, ou para aqueles
que fazem home office;
O acesso a aplicativos para sistemas operacionais que não suportam o RD
Web Access, ou o RD Remote App.
 
Sessões de Coleção
As Sessões de Coleção (Session Colletions) determinam as propriedades dos
servidores de RDSH. Em uma Collection, podem ser instaladas as seguintes
configurações do RDSH:
Usuário de Grupos
O usuário de grupos ( User Group) determina quais grupos de usuários estão
associados a uma Coleção específica. Se um usuário é membro do grupo de
usuários, ele pode se conectar aos servidores da sessão membro da coleção.
Sessões
As sessões (Sessions) determinam a quantidade de tempo após o qual uma
sessão desconectada é automaticamente encerrada. O valor padrão é Nunca.
Esse valor pode ser configurado para ser tão curto quanto um minuto.
Também se pode configurar limites de sessão ativos, o tempo máximo para
que uma sessão ociosa seja desconectada e, depois, a ação que deve ocorrer
após uma desconexão, ou seja, se a sessão deve ser encerrada
automaticamente, ou se a reconexão deve ser permitida. As configurações
contidas nesta área também podem ser utilizadas em pastas temporárias e
determinar se estas devem ser excluídas quando a sessão terminar.
Configurações de Segurança
Elas permitem que se configure a exigência de segurança RDP ou TLS 1.0 
para conexões da área de trabalho. As opções de criptografia incluem: baixa
compatibilidade com o cliente, compatibilidade alta e compatível com FIPS.
Em geral, seleciona-se alta (High), a menos que seja necessário usar o FIPS
Compliant. A desvantagem de selecionar alta compatibilidade, é que alguns
usuários que utilizaram a área de trabalho remota anteriormente, podem não
suportar este nível de criptografia.
Balanceamento de Carga
Esta sessão permite que se faça as configurações de balanceamento de carga
para uma coleção, incluindo o peso a ser atribuído ao servidor, quando vários
servidores de RDSH estão disponíveis para o número de sessões que cada
host hospedar.
Configurações do cliente
Esta sessão permite que se configure quais opções de redirecionamento serão
ativadas. Os seguintes componentes podem ser redirecionados:
Reprodução de áudio e vídeo
Gravação de áudio
Smart Cards
Dispositivos Plug and Play
Drivers (Discos locais)
Clipboard (Copiar e colar entre o cliente e a sessão)
Impressoras
 
Discos de Perfil do Usuário
Os discos de perfil do usuário (User Profile Disks) permitem o
armazenamento de configurações e pastas em uma localização central. Isso é
útil para que os usuários mantenham dados e configurações em diferentes
hosts de sessão, em vários servidores. Abaixo, seguem as opções de
configurações de disco do perfil do usuário:
Localização do disco;
Tamanho máximo;
Armazenamento de todas as configurações e dados do usuário no disco de
perfil. Recomenda-se guardar apenas determinadas pastas no disco de
perfil do usuário e deletar as demais.
 
Personal Session Desktops
As sessões de desktop pessoais são funções novas do Windows Server 2016,
e permitem que se crie um tipo especial de coleção, em que cada usuário
detenha os direitos administrativos e o acesso a sua máquina virtual pessoal.
As sessões pessoais podem ser úteis para desenvolvedores que necessitam
direitos administrativos, mas não tem acesso a eles em um servidor RDSH
específico.
Remote Desktop Virtualization Host
O RDVH possibilita que os clientes se conectem usando os desktops virtuais
de hosts Hyper-V, além da atribuição de usuários para uma VM exclusiva, ou
sua distribuição para um conjunto de máquinas virtuais. O serviço RDVH
precisa ser instalado em um computador com Hyper-V instalado.
Este tipo de virtualização requer maiores recursos do que as sessões remotas,
mas também oferece maior personalização da experiência do usuário. As
máquinas virtuais podem ser tratadas exatamente como máquinas desktops
tradicionais, com usuários que usam um “Thin Client”. Os servidores RDVH
possuem os seguintes requisitos:
Estar disponível remotamente, via Windows PowerShell;
Pertencer a um domínio do Active Directory;
Executar o Hyper-V;
Suportar a virtualização assistida por hardware. Isso significa que não há
como executar um servidor RDVH com o nested Virtualization;
Possuir um adaptador de rede que suporte à criação de um switch virtual
do Hyper-V;
O servidor RD Connection Broker deve ter o direito de unir as áreas de
trabalho virtuais ao domínio do Active Directory.
 
Para que se possa utilizar uma máquina virtual como modelo em uma
implantação do RDVH, deve-se executar as seguintes tarefas:
Instale a máquina virtual e todos os aplicativos disponíveis para usuários.
Esta máquina virtual deve estar hospedada em um servidor Hyper-V com
a função RDVH instalada. Há a possibilidade de construí-la em outro host
e depois importá-la. Embora não seja necessário, é recomendável
configurar esta máquina virtual como Geração, o que trará maior
flexibilidade, em termos de configuração.
Uma vez instalados os aplicativos, execute o sysprep na máquina virtual,
com os parâmetros /oobe /shutdown /generalize.
 
Remote Desktop Web Access
O RDWA viabiliza a conexão dos clientes a uma sessão do RDSH, ou do
RDVH, através de um link de uma página web, ao invés de utilizar o Remote
Desktop Connection. Somente computadores com Windows Server, ou
Windows cliente, são compatíveis. O RDWA também pode ser usado para
publicar aplicativos diretamente no menu iniciar dos computadores que
executam os sistemas operacionais Windows 8.1 e Windows 10.
Em julho de 2018 lançamos uma nova versão do Remote Desktop Web
baseado em HTML 5.0 e com suporte para dispositivos não Windows como
celulares e tablets Android e Mac.
A instalação da nova versão do Web Access se dá através do PowerShell e
coexiste com a versão atual. Execute os comandos PowerShell abaixo no
servidor RDWebAccess para ativá-lo.
Set-ExecutionPolicy -ExecutionPolicy Unrestricted
Install-Module -Name PowerShellget -Force (reinicie o servidor)
Install-Module -Name RDWebClientManagement
Install-RDWebClientPackage
# Exporte o certificado do Connection Broker para um arquivo .cer e
importe-o
Import-RDWebClientBrokerCert C:\RDSCert\RDSCert.cer
Publish-RDWebClientPackage -Type Production -Latest
 
Após a configuração um novo diretório virtual chamado /webclient será
provisionado. Acesse a nova página com a seguinte URL.
https://rdwebservername/rdweb/webclient/index.html
FIGURA 06-12. Nova interface web baseado no HTML5.0
Remote Desktop Licensing
Um tipo especial de licença é exigido para que usuários se conectem a
máquinas virtuais, ou em colletions. Esta licença se chama RDS Client
Access License, e não vem incluída no Windows Server 2016. Ao adquiri-la
com um parceiro de licenciamento Microsoft,será necessário ativá-la via
licenciamento da área de trabalho remota ( Remote Desktop Licensing).
Vários tipos de licença podem ser instaladas em um servidor RDL. Abaixo,
seguem os diferentes tipos de licenças:
Per User. A licença por usuário fornece uma conta específica, com 
capacidade de acessar qualquer servidor RDSH em uma organização, a partir
de qualquer computador ou dispositivo. Esse tipo de licença pode ser uma
boa ideia quando a mesma pessoa acessa a área de trabalho remota de
diferentes dispositivos.
Per Device. As licenças emitidas para dispositivos licenceiam dispositivos
específicos, como estações de trabalho ou “Thin Client”, com capacidade e
direito de se conectar à um servidor RDSH. Elas são reiniciadas
automaticamente pelo servidor de licenças, após um período aleatório entre
52 e 89 dias. Isso significa que, se um computador ou Thin Client estiver
desativado, a licença atribuída a ele é recuperada, e pode ser usada
novamente para outro dispositivo. Caso se queira desativar uma grande
quantidade de computadores, é possível revogar até 20% das licenças por
dispositivo.
RDS External Connector. Use este tipo de licença para permitir que
usuários externos à sua organização acessem um único servidor de área de
trabalho remota. Deve-se adquirir uma licença separada do conector externo
RDS para cada servidor RDS acessível a usuários externos.
Licenciamento SPLA (Service Providers License Agreement). Este é um tipo
especial de contrato de licença para prestadores de serviço, muito útil quando
fornece serviços de RDS para várias organizações. Pode-se mesclar RDS Per
User e Per Device conforme necessário. Para utilizar os serviços de RDVH,
também se exige a compra de um contrato de licenciamento do Virtual
Enterprise Centralized Desktop (VECD) para o sistema operacional.
Existe um assistente, no gerenciamento do console de serviço RDL, que
libera a migração e a reconstrução de licenças de outros servidores.
Para a emissão das licenças, antes ativa-se um servidor de licença. O processo
de ativação é razoavelmente semelhante ao da ativação do sistema
operacional Windows ou Office. O método a ser seguido depende da conexão
do servidor de licença RDL à Internet. Se o servidor estiver conectado à
Internet, executa-se a ativação automática. Caso contrário, realiza-se uma
ligação telefônica ou navega-se até um site, em um computador ou
dispositivo móvel que tenha acesso à Internet. Neste último caso, a ativação é
executada através do preenchimento de um formulário, onde o código de
ativação exibido no seu servidor de licença RDL deverá ser digitado
Virtual Desktop Collections
As coleções de desktops funcionam de forma semelhante a uma coleção de
sessão. Configura-se quem pode se conectar e seleciona-se os recursos aos
quais eles têm acesso por coleção. Para a coleção de desktops virtuais, será
necessário fornecer as seguintes informações:
Collection name. O nome amigável que faz referência à coleção de
desktops.
Collection type. Pode-se escolher entre Pooled VM Collection e Personal
VM Collection.
Virtual Desktop Template. O disco vhdx da máquina virtual que foi
preparado como template, onde foi executado o sysprep.
Virtual Desktop Settings. Especifica um arquivo de resposta do sysprep
ou fornece configurações de instalação autônoma. Essa informação é
usada para inserir a máquina virtual ao domínio do Active Directory. Para
tanto, exige-se que a conta de computador do host tenha permissão de
fazer Domain Join no ADDS.
Unnatended Settings. Para fornecer o fuso horário, o domínio do ADDS
e a unidade organizacional usada na operação de associação de domínio.
User and Groups. É utilizado para especificar quais usuários e grupos
tem acesso à coleção. Permite, ainda, que se configure o número de
desktops virtuais a serem criados na coleção, e o nome do prefixo e sufixo
para as contas de computadores das máquinas virtuais.
Virtual Desktop Allocation. Permite especificar a alocação de máquinas
virtuais VDI na coleção para servidores RDSH. Por exemplo, pode-se
designar 20 máquinas virtuais a um servidor e 30 a outro.
Virtual Desktop Storage. Configura o tipo de armazenamento usado para
os desktops virtuais.
User Profile Disks. Permite configurar e ativar as configurações do disco
do perfil do usuário, e sua localização.
 
Uma vez que a desktop Collection é criada, as configurações do cliente
podem ser atribuídas a essa Collection. Ou seja, funcionalidades como
reprodução de áudio e vídeo, gravação de áudio, Smart Cards, dispositivos
plug and play, unidades, área de transferência e impressoras podem ser
redirecionadas do cliente para a máquina virtual.
Personal Virtual Desktops
Os desktops pessoais possibilitam a atribuição de usuários às máquinas
virtuais persistentes. Isto é, os usuários sempre serão conectados à mesma
máquina virtual, podendo personalizá-la e armazenar dados nessa máquina.
As máquinas virtuais estão associadas ao usuário e são automaticamente
conectadas quando o usuário inicia uma sessão através do Remote Desktop
Connection Broker.
Pooled Virtual Desktops
O grupo, ou conjunto, de desktops virtuais são coleções de máquinas virtuais
configuradas de forma idêntica, às quais os usuários se conectam através de
um host RDVH redirecionados pelos servidores Remote Desktop Session
Broker. Um usuário será conectado à primeira máquina virtual compartilhada
disponível no primeiro registro, e apenas será redirecionado para a mesma
VM se sua conexão não tiver sido encerrada anteriormente. O pool de
máquinas virtuais não mantem as informações de sessão, e elas retornam para
seu estado original assim que o usuário faz log off. Na prática, um ponto de
restauração é aplicado à máquina virtual, de forma que ela retorne ao seu
estado original.
Windows Admin Center (WAC)
O WAC é um conjunto de ferramentas acessadas via uma interface Web, que
permitem aos administradores acessar e gerenciar os servidores Windows
Server 2012 R2 e Windows Server 2016 remotamente. O portal do Honolulu
dá, aos administradores de TI, o controle total sobre todos os aspectos da
infraestrutura do servidor, e é particularmente útil para gerenciamento de
redes privadas que não estão conectadas à Internet.
Quando se instala o Windows 10, pode-se abri-lo no menu iniciar. Em um
navegador web, abre-se a interface do usuário e autentica-se este usuário com
sua conta local para conectá-lo aos servidores Windows Server.
No Windows Server, O WAC pode ser instalado no modo “Gateway”, ele
inicia um serviço de rede que responde na porta especificada pelo usuário
durante a instalação.
O WAC ainda não substitui completamente o Microsoft Management
Console (MMC). Seguem as funções que podem ser gerenciadas:
A visualização de recursos e sua utilização
Gerir os certificados
Acessar o visualizador de eventos
Explorar arquivos
Gerenciar o firewall
Configurar usuários e grupos locais (AD ainda não)
Configurar as redes TCP/IP
Viewing / Editing Process e Creating Process Dumps
Editar o registro do Windows
Gerenciar serviços
Instalar e remover funções
Criar e Gerenciar maquinas virtuais e switches do Hyper-V
Gerenciar os discos
Gerenciar o Storage Space Direct para redes hiperconvergidas
 
Nota
Para gerenciar servidores Windows Server 2012 e Windows
Server 2012 R2, será necessário instalar a versão 5.1 do Windows
Management Framework, que está disponível para download no
site da Microsoft.
 
FIGURA 06-13. Windows Admin Center
Simulado
Questão 01
O que se deve fazer para restaurar uma versão anterior de um arquivo sem
afetar a versão atual?
A. Renomear o arquivo durante o processo de restauração.
B. Excluir o arquivo atual e restaurar a versão anterior.
C. Restaurar o arquivo para um local alternativo.
D. Restaurar o arquivo em um servidor de testes.
Questão 02
Qual tipo de banco de dados deve ser instalado para uma única implantaçãodo servidor WSUS?
A. Oracle Database
B. Windows Internal Database
C. MySQL Server Database
D. SQL Server Database
Questão 03
Um grupo de computadores foi criado no console do WSUS para máquinas
Windows Server 2016. Porém, todos os servidores estão entrando no grupo
de computadores não atribuídos. Como se deve proceder neste caso?
A. Configurar um GPO ou um registro para definir o grupo correto.
B. Reiniciar o serviço do WSUS.
C. Criar uma unidade organizacional no Active Directory exclusivo para
Windows Server 2016.
D. Criar uma aprovação automática no WSUS para o Windows Server 2016.
Questão 04
Para implantar um servidor WSUS em uma filial, este servidor deve buscar as
atualizações da matriz (upstream server), mas os administradores da filial
devem configurar seus próprios grupos de computadores. Qual modo de
implantação deve ser usado para o servidor da filial (downstream)?
A. Stand alone
B. Replica
C. Downstream
D. Autonomous
Questão 05
Para automatizar a instalação do Backup do Windows Server em um conjunto
de máquinas Windows Server 2016, o usuário decide usar o PowerShell.
Qual cmdlet deve ser executado para instalação em massa?
A. Install-WindowsFeature
B. Get-WindowsFeature
C. Deploy-WindowsFeature
D. Set-WindowsFeature
Questão 06
 Qual cmdlet do PowerShell pode ser utilizado para invocar um backup
remoto em uma máquina Windows Server 2016?
A. Invoke-WBBackup
B. Start-WBBackup
C. Set-VBVssBackupOptions
D. Set-WBBackup
Questão 07
Qual deve ser o procedimento para garantir que as tarefas de backup do
Windows Server estejam capturando as metabases do IIS nos servidores
web?
A. Incluir a pasta C:\Inetpub\wwwroot no job de backup
B. Executar Backup-WebConfiguration
C. Selecionar a opção IIS metabase durante o agendamento do backup
D. Incluir a pasta C:\windows\iis\metabase no backup
Questão 08
Qual ferramenta se utiliza para capturar informações de históricos de
desempenho que podem ser revistos a qualquer momento nos servidores?
A. Performance monitor
B. Resource monitor
C. Event logs
D. Task manager
Questão 09
A CPU está chegando a 100% da sua capacidade, em um dos servidores.
Como se identifica, de maneira rápida, o processo que está causando o
problema?
A. Usando o Server Manager
B. Usando o Task Manager
C. Usando o Event Viewer
D. Criando um Data Collector no Perfmon
Questão 10
Um conjunto de coletores de dados está sendo criado para capturar dados
históricos de desempenho para posterior revisão. Ao mesmo tempo, é
necessário controlar a utilização da CPU. Qual contador de desempenho deve
ser adicionado ao Data Collector Set?
A. %Processor Time
B. %CPU Utilization
C. %Privileged Time
D. %Processor Utilization
Questão 11
É necessário configurar os servidores para buscar atualizações no servidor
WSUS usando uma conexão segura. Existe um firewall de rede entre os
servidores e a infraestrutura do WSUS, mas a equipe de rede deve permitir
que os clientes se conectem ao WSUS. Qual porta de rede deve ser aberta
para viabilizar essa conexão?
A. TCP 3581
B. TCP 8530
C. UDP 8531
D. TCP 8531
Questão 12
Ao criar um Balanceamento de Carga de Rede (Network Load Balancing)
para servidores WSUS deseja-se permitir que os clientes se conectem por
HTTP ao WSUS. Qual regra deve ser criada no balanceador de carga para o
tráfego do cliente?
A. Criar uma regra de balanceamento de rede na porta TCP 3580
B. Criar uma regra de balanceamento de rede na porta TCP 8530
C. Criar uma regra de balanceamento de rede na porta TCP 3851
D. Criar uma regra de balanceamento de rede na porta TCP 8531
Questão 13
De qual componente do Windows Server Domain Controller deve ser feito
backup, quando se quer para restaurar a floresta do Active Directory em caso
de um desastre?
A. System state
B. The system drives
C. Bare metal recovery
D. O diretório C:\Windows\NTDS\SYSVOL
Questão 14
Qual cmdlet pode ser usado para revisar os logs de eventos a partir do
PowerShell?
A. Get-EventLogs -LogName Application
B. Get-Event
C. Query-EventLog
D. Get-EventLog
Questão 15
Como se deve proceder para registrar automaticamente um evento, sempre
que a utilização de CPU em seu servidor for superior a 80%?
A. Criar um conjunto de coletores de dados
B. Criar um conjunto de coletores de dados com um alerta de contador de
desempenho
C. Habilitar o performance monitoring no event viewer
D. Criar uma schedule task que analisa o contador %Processor Time
 
Respostas
01-
C
02-B 03-
A
04-
D
05-
A
06-B 07-B 08-
A
09-B 10-
A
11-B 12-
C
13-
A
14-
D
15-B 
 
 
 
 
Os capítulos 07 a 11 contemplam toda a área de conhecimento sobre redes, e
serão preparatórios para o exame 70-741 – Redes com o Windows Server
2016.
Os candidatos a este exame devem realizar tarefas relacionadas aos recursos e
funcionalidades de rede disponíveis no Windows Server 2016. Para tanto,
precisam ter familiaridade com a instalação e o gerenciamento de DNS,
DHCP e IPAM, bem como com a implantação de soluções de acesso remoto,
tais como VPN e RADIUS.
Também é exigida a experiência em gerenciamento de soluções DFS e de
BranchCache, configuração de recursos e funcionalidades de rede de alto
desempenho, além de implementações de SDN (Software Defined
Networking), como é o caso da virtualização de rede Hyper-V (HNV) e do
controlador de rede (NC).
CAPÍTULO 07 – Implantar
Resolução de Nomes (DNS)
Neste capítulo, abordaremos todos os fundamentos e os recursos mais
avançados do serviço de resolução de nomes DNS do Windows Server 2016,
incluindo os seguintes tópicos:
Tipos de zonas;
Replicação, registros e delegação;
Segurança e gerenciamento do tráfego;
Criptografia com o DNSSec e DANE;
Administração baseada em controle de acesso.
Tipos de zonas
As zonas armazenam informações de registro dos recursos. O DNS do
Windows Server 2016 suporta vários tipos de zonas, cada uma apropriada
para um conjunto diferente de necessidades. Os tipos de zonas incluem:
Primária, Secundária, Stub e GlobalNames.
FIGURA 07-01. Tipos de Zona.
Zonas integradas ao Active Directory
É possível integrar uma zona ao Active Directory, contanto que ela deixe de
ser armazenada em arquivos textos, com a extensão nomedazona.dns, e
passe a ser armazenada como objeto no banco de dados do Active Directory.
Existem duas partições especiais para a zona: a ForestDnsZones e
DomainDnsZones.
Para integrar uma zona ao Active Directory, deve-se configurar o escopo de
replicação. Pode-se escolher um escopo em que a zona será disponibilizada
para todos os controladores de domínio da floresta, para um domínio
específico ou, em um escopo customizado, cria-se uma partição
personalizada no Active Directory.
A criação de uma partição customizada permite armazenar a zona para
alguns, mas não para todos os controladores de domínio. Esta opção só
poderá ser escolhida se houver uma partição criada especialmente para esta
finalidade. Use o comando Add-DNSServerDirectoryPartition para criar uma
partição.
Add-DNSServerDirectoryPartition -Name DnsBaninPartition
As zonas integradas usam uma replicação multi-master. Isso significa que,
qualquer controlador de domínio que hospeda a zona, poderá processar uma
atualização em um registro desta zona. Ao criar uma zona, é necessário
especificar se ela suportará atualizações de registro de maneira dinâmica,
permitindo aos computadores clientes e servidores atualizarem seus próprios
registros. Isso é especialmente útil em ambientes em que os computadores
clientes trocam de endereço IP com frequência. Há três opções de
atualizações dinâmicas:
Allow only secure dynamic updates. Esta opção pode ser usada somente
quando a zona é integrada ao Active Directory, e apenas computadores
autenticados podem fazer atualizações dinâmicas em seu próprio registro.Allow both non-secure and secure dynamic updates. Com esta opção,
qualquer computador cliente poderá atualizar um registro. Apesar de
conveniente, é uma opção insegura, afinal qualquer computador na rede
será capaz de atualizar seu registro, esteja ele autenticado ou não. Isso
pode, potencialmente, afastar clientes que confiam na qualidade de
informações enviadas pelo servidor DNS.
Do not Allow dynamic updates. Quando se escolhe esta opção, todas as
tarefas de atualizações de registros precisam ser realizadas manualmente.
É uma opção segura, mas exige esforço intensivo.
Uma zona integrada ao AD pode ser replicada para um controlador de
domínio somente leitura (RODC -Read Only Domain Controller).
Obviamente, a zona replicada para um RODC será somente leitura (Read
Only), e o RODC não poderá fazer qualquer alteração na zona, ou em seus
registros. Neste caso, o RODC encaminha todo pedido de atualização para
um Writable Domain Controller.
Pode-se criar uma zona integrada ao AD usando o cmdlet Add-
DnsServerPrimaryZone, com o parâmetro ReplicaitonScope.
Add-DnsServerPrimaryZone -Name banin.com -ReplicationScope Forest
O processo de instalação do Active Directory garante que a zona associada ao
domínio root seja automaticamente configurada como uma zona integrada e
replicada para todos os controladores de domínio da floresta.
Zonas Primárias e Secundárias
Em uma instalação tradicional de DNS, um único servidor hospeda a zona
primária, que é responsável por processar todas as atualizações. Um conjunto
de dois ou mais servidores são configurados como servidores secundários,
que recebem uma cópia somente leitura da zona primária. Este processo é
conhecido como transferência de zona, e ocorre na porta TCP/53. Se um
servidor primário ficar indisponível, os servidores de DNS secundários
deixam de receber as atualizações. Mas é possível converter uma zona
secundária para primária com apenas alguns cliques. Uma zona secundária
não pode ser integrada ao Active Directory. Para adicionar uma zona
secundária, use o comando Add-DnsServerSecondaryZone.
Add-DnsServerSecondaryZone -Name banin.com -ZoneFile
“banin.com.dns” -MasterServers 10.0.0.1
O serviço de DNS que roda em um controlador de dominio suporta todos os
tipos de zonas. Isso significa que se pode escolher entre: zona primária
integrada ou padrão, zona secundária, zona reversa integrada ou padrão, ou
até mesmo uma zona Stub.
Elas podem ser usadas no método tradicional, em que a zona primária tem
permissão de leitura e gravação; e a secundária, somente leitura. Toda
transferência de zona acontece na porta TCP/53. Todas as consultas são
realizadas na porta UDP/53.
Zona Stub
Uma zona Stub é uma zona especial que armazena os servidores que possuem
autonomia para nomes de uma determinada zona. A zona Stub tem uma
vantagem, se comparada ao tradicional encaminhadores, quando o endereço
de destino é uma zona que tem atualizações regulares. Ela é frequentemente
usada para armazenar os registros de servidores DNS autoritativos em zonas
que são delegadas. Desta maneira, garante-se que as zonas delegadas sempre
estejam atualizadas. Ao criar uma zona Stub em um controlador de domínio,
também é possível integrá-la ao AD e replicá-la para outros controladores de
domínio da sua floresta.
Pode-se adicionar uma zona Stub utilizando o cmdlet Add-
DnsServerSubZone.
Add-DnsServerStubZone -MasterServers 10.0.0.1 -Name banin.com -
ReplicationScope Forest -LoadExisting
 
Zona GlobalNames
A zona chamada GlobalNames, não muito explorada nos servidores
Windows Server, possui nome único, e tem como objetivo substituir o
serviço de WINS que utiliza uma infraestrutura de DNS. Uma empresa
deveria considerar adotar a zona GlobalNames, ao invés de WINS, nas
seguintes condições:
Se a empresa está avaliando adotar o IPV6. O WINS não suporta IPV6 e a
resolução de nomes curtos deve ser suportada.
A resolução de nome único é limitada a um pequeno grupo de hosts que
raramente são alterados. A zona GlobalNames deve ser atualizada
manualmente.
Se houver muitos sufixos, pois há uma complexa convenção de nomes
existentes.
 
Para criar a zona GlobalNames, use o comando abaixo:
Add-DnsServerPrimaryZone -Name GlobalNames -ReplicationScope
Forest
 
Em seguida, ative a zona em cada um dos servidores DNS.
Set-DnsServerGlobalNameZone -ComputerName DNSServerName -
Enable $true
 
FIGURA 07-02. Zona GlobalNames.
Todos os registros de uma zona GlobalNames precisam ser criados e
atualizadas manualmente. Deve-se criar registros do tipo CNAME,
apontando para seus respectivos nomes FQDN.
Tipos de Registros
Os servidores DNS suportam muitos registros. Os mais comuns são: os
registros A, que conectam um nome a um endereço IPv4; AAAA, que liga
um nome ao endereço IPv6; e CNAME, que unem um nome a outro nome.
Este último é popularmente conhecido como alias (apelido). Registros mais
completos e complexos podem fornecer informações sobre a localização de
servidores de e-mail (MX) e dos controladores de domínio (_SRV). Outro
registro muito popular é o PRT, que nomeia um IP para as zonas reversas.
FIGURA 07-03. Tipos de registros.
CNAME. O apelido ( alias) ou registro do tipo CNAME permite configurar
um nome alternativo para outro nome já existente. É possível criar tantos
apelidos quanto se queira. Para criar este registro, abra a console do DNS
Manager, clique na zona e selecione New Alias (CNAME). O botão Browse
pode ser usado para navegar nos registros, ou mesmo para entrar com o nome
manualmente. Também se pode utilizar o comando Add-
DnsServerResourceRecord-CName.
Mail Exchange (MX). Os registros MX são usados para localizar os
servidores de correio eletrônico (Mail Servers). Quando uma empresa envia
um e-mail para alguem@microsoft.com o servidor de correio fará uma
pesquisa no servidor de DNS, em busca do registro MX da zona
microsoft.com, para saber qual servidor de e-mail é o destinatário da
mensagem. Para descobrir, de forma simples e eficiente, quais são os
servidores de e-mail de determinado domínio, basta utilizar o comando
nslookp.
nslookkup
set type=mx
microsoft.com
 
Para adicionar um registro MX através do PowerShell use o comando Add-
DnsServerResourceRecordMX.
Pointer Record (PTR). O registro PTR serve para fazer uma consulta
inversa, ou seja, uma consulta em que um IP obtém um nome como resposta.
Antes disso, deve-se criar uma zona reversa no servidor DNS. Se houver uma
zona reversa apropriada, o registro PTR é automaticamente criado. Use o
cmdlet Add-DnsServerResourceRecordPrt, ou a console do gerenciador de
DNS, para criar um registro PTR.
O Windows Server 2016 suporta registros desconhecidos, ou “unknown
records”, cujo formato RDATA é desconhecido para um servidor de DNS.
Os registros desconhecidos são definidos pela RFC 3597, e podem ser
adicionados às zonas, quando estejam armazenadas em computadores que
executam o Windows Server 2016.
Duração e Eliminação
Duração e eliminação (aging e scavenging) são técnicas para manter as zonas
primárias mais limpas e enxutas, eliminando registros antigos, que não
tenham sido atualizados por um determinado tempo. Quando uma empresa
tem zonas relacionadas a computadores portáteis, como é o caso de usuários
móveis que trabalham remotamente e raramente vão ao escritório, as zonas
podem acumular, desnecessariamente, registros antigos. Isso pode gerar
alguns problemas, entre eles:
A consulta ao DNS pode retornar um valor incorreto;
As zonas grandes podem causar problemas de desempenho;
Há lentidão no logon, quando identificados os controladores de domínio
inexistentes.
 
Para resolver estes problemas, pode-se configurar o serviço de DNS da
seguinte maneira:
Para habilitá-lo, basta clicar com o botão direito no servidor DNS, e então
clicar em Scavenge Stale Resource Records. Ainda é possível configurá-lo
usando ocmdlet Set-DnsServerScavenging. Por exemplo, para habilitar a
hora e a data locais em todos os registros, de todas as zonas de um servidor
DNS, e definir o período de Não-atualização e Atualização (No-Refresh e
Refresh) para 7 dias, executa-se o seguinte comando:
Set-DnsServerScavenging -ApplyOnAllZones -RefreshInterval 07.0:0:0 -
ScavengingInterval 07.0:0.0 -ScavengingState $True
 
Non-Refresh interval: é o período em que o DNS impede ou recusa
qualquer tentativa de alterar a hora e a data do registro. Isso é feito para
evitar problemas de degradação de desempenho e tráfego excessivo na
rede. Imagine 10.000 computadores clientes tentando atualizar seu
timestamp cada vez que um logon é realizado. Esse período é considerado
curto para que um registro seja considerado como antigo.
 
Refresh interval: é o período em que os registros nas zonas de DNS
podem receber atualizações.
 
FIGURA 07-04. Aging/Scavenging.
 
Na prática, quando se insere uma máquina ao domínio do Active Directory,
um registro A com o nome do computador será criado no DNS, apontado
para seu respectivo IP. A data e a hora em que isso ocorreu serão registradas.
Imaginemos que o procedimento tenha ocorrido as 09:00 da manhã do dia
14/02/2018. Qualquer tentativa de atualização do registro até 21/02/2018 será
ignorada pelo DNS, devido ao período de Non-Refresh. Se esse registro não
for atualizado até 28/02/2018, ele será considerado obsoleto e será removido
pelo processo de Scavering que ainda aguarda mais 7 dias para eliminá-lo.
Neste caso, a partir do vigésimo primeiro dia, o registro será excluído da zona
automaticamente.
É aconselhável atentar-se ao tipo de registro, pois somente os criados
dinamicamente serão afetados pelo processo de Aging e Scavenging, ao
contrário dos criados estaticamente. Além disso, os registros estáticos
precisarão ser removidos manualmente, se deixaram de existir.
Escopos
Aqueles que algum dia configuraram servidores ADFS e WAP, certamente já
tiveram a necessidade de configurar Split-Brain DNS. Na prática, isso
significa ter dois servidores de DNS com a mesma zona, mas com respostas
diferentes para seus registros. No caso do ADFS, o nome adfs.banin.com
precisa resolver o endereço IP interno do balanceador de carga (VIP) quando
o usuário está na rede local. Porém, quando este mesmo usuário estiver na
Internet, ele precisará de uma resposta com um IP diferente para o mesmo
nome adfs.banin.com, que deveria ser o IP do balanceador dos servidores
Web Application Proxys.
Com as novas políticas do DNS para Windows Server 2016, pode-se ter duas
versões de uma única zona. Uma para os usuários internos na intranet, e outra
para os usuários externos, que geralmente são usuários da Internet.
Anteriormente, esse cenário exigiria que os administradores de DNS
mantivessem dois servidores diferentes, cada um fornecendo serviços para
cada conjunto de usuários.
Usarei um exemplo clássico, que é a configuração de Split-Brain DNS para a
implantação do ADFS e WAP. O ADFS interno está disponível no endereço
10.10.10.10 e o WAP, no endereço 200.200.200.00.
Na ausência de políticas de DNS, o administrador deverá hospedar estas duas
regiões em servidores DNS separados e gerenciá-los separadamente. Usando
a política de DNS, essas zonas podem agora ser hospedadas no mesmo
servidor DNS.
Scope zone. Um escopo de zona é uma instância exclusiva da zona. Uma
zona DNS pode ter vários escopos, e cada escopo de zona contém seu próprio
conjunto de registros DNS. O mesmo registro pode estar presente em
múltiplos escopos, com os mesmos endereços IPs, ou endereços distintos.
Nota
Por padrão, um escopo de zona já existe nas zonas DNS. O escopo de zona
padrão irá hospedar a sua versão externa.
O comando a seguir pode ser usado para particionar a zona banin.com e criar
um escopo de região interna. O escopo de zona interna será usado para
manter a versão interna da zona banin.com.
Add-DnsServerZoneScope -ZoneName "banin.com" -Name "internal"
A próxima etapa será adicionar os registros que representam o host dos
servidores ADFS e WAP para seus respectivos escopos. O escopo interno
(internal) será usado para o ADFS e o padrão ( default) será usado para o
WAP (para clientes externos).
No escopo interno, o registro adfs.banin.com é adicionado com o endereço
10.10.10.10, que é um IP privado. Já no escopo de zona padrão, o mesmo
registro adfs.banin.com será adicionado com o IP público 200.200.200.200.
Add-DnsServerResourceRecord -ZoneName "banin.com" -A -Name "adfs"
-IPv4Address "10.10.10.10” -ZoneScope "internal"
 
Add-DnsServerResourceRecord -ZoneName "banin.com" -A -Name "adfs"
-IPv4Address "200.200.200.200"
 
O comando é o mesmo. A única diferença está na necessidade de declarar o
parâmetro -ZoneScope “internal” para a zona interna, enquanto não há tal
necessidade na zona padrão.
Nota
No exemplo acima, utiliza-se a interface de rede do servidor DNS
como critério para diferenciar os clientes internos e externos.
Outro método para fazer essa distinção é usando subredes de
origem como critério. Ao identificar as subredes às quais os
clientes internos pertencem, pode-se configurar políticas para
diferenciá-los.
Quando o servidor DNS recebe uma consulta na interface privada, a resposta
da consulta DNS é retornada no escopo da região interna.
No comando a seguir, o IP 10.10.10.5 é o endereço IP da interface interna do
servidor DNS:
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -
Action ALLOW -ServerInterface "eq,10.10.10.5" -ZoneScope "internal,1" -
ZoneName banin.com
 
Filtros
Os filtros de consultas da política de DNS permitem que se configure o
servidor DNS para responder de forma personalizada.
 
Por exemplo, a política de DNS pode ser configurada com um filtro que
bloqueie consultas de domínios ou de outros servidores de DNS mal-
intencionados, impedindo a resposta às consultas destes domínios.
 
Também é possível criar um filtro que limite a resolução de nomes de
domínio a um conjunto específico de clientes.
 
Qualquer combinação lógica (e/ou/não) pode ser utilizada pra criar filtros,
bastando seguir os seguintes critérios:
 
Subrede do cliente. Nome de uma subrede predefinida. Usado para
verificar a subrede pela qual a consulta foi enviada.
Protocolo de transporte. Usado na consulta de protocolo de transporte.
Os valores possíveis são UDP e TCP.
Protocolo de Internet. Protocolo de rede usado na consulta. Os valores
possíveis são IPv4 e IPv6.
Endereço IP da interface do servidor. Endereço IP da interface de rede
do servidor DNS que recebeu a solicitação DNS.
FQDN. Nome totalmente qualificado do domínio de registro na consulta,
com a possiblidade de usar um caractere especial (curinga).
Tipo de consulta. Tipo de registro que está sendo consultado (A, SRV,
TXT, CNAME, etc.).
Hora do dia. Hora do dia em que a consulta é feita.
 
O comando abaixo configura uma política de nível de servidor para bloquear
qualquer consulta que tenha como origem o domínio dominiomalicioso.com.
 
Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicy" -Action
IGNORE -FQDN "EQ,*.dominiomalicioso.com" -PassThru
 
A ação IGNORE faz o servidor DNS enviar consultas sem resposta. Neste
caso, o cliente DNS que solicitou a consulta a partir do domínio mal-
intencionado será descartado.
 
O exemplo a seguir demonstra como usar os critérios de subrede em
combinação com os critérios de FQDN para bloquear consultas a
determinados domínios mal-intencionados de subredes infectadas.
 
Add-DnsServerQueryResolutionPolicy -Name
"BlockListPolicyMalicious06" -Action IGNORE -ClientSubnet
"EQ,MaliciousSubnet06" –FQDN “EQ,*.dominiomalicioso.com” -
PassThru
 
Talvez seja necessário bloquear a resolução de nomes para certos tipos de
consultas nos servidores. Por exemplo, pode-se bloquear a consulta ANY,
que poderia ser usada de maneira mal-intencionada.Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicyQType" -
Action IGNORE -QType "EQ,ANY" -PassThru
 
Igualmente, pode-se criar uma lista de permissões para subredes, de forma
que todas as consultas não originárias dessas subredes sejam ignoradas.
 
Add-DnsServerClientSubnet -Name "AllowedSubnet" -IPv4Subnet
172.0.0.0/16 -PassThru
 
 
Add-DnsServerQueryResolutionPolicy -Name "AllowListPolicySubnet” -
Action IGNORE -ClientSubnet "NE, AllowedSubnet" -PassThru
 
Controle Recursivo Seletivo
Uma pesquisa recursiva é aquela feita por usuários para o servidor DNS que
não detêm autoridade sobre aquela zona. Por exemplo, quando os usuários da
rede local acessam o site da microsoft.com, o servidor de DNS, através dos
servidores Root Hints, enviará uma resposta para o cliente. Mas isso não deve
acontecer quando esse mesmo usuário é externo. Há muitos servidores DNS
expostos no mundo, e se eles estiverem configurados como um servidor DNS
aberto, poderão ficar vulneráveis a esgotamento de recursos, podendo ser
empregados, por clientes mal-intencionados, para criar ataques.
Por isso, os administradores de DNS não podem permitir que o servidor DNS
para banin.com realize a resolução recursiva de nomes de clientes externos.
Há apenas uma necessidade de controle de recursão para clientes internos. Já
para os clientes externos, o controle de recursão pode ser bloqueado.
Se o servidor DNS da Banin Corporation receber uma consulta não
autorizada, como www.google.com, por exemplo, a solicitação de resolução
de nome é avaliada contra as políticas do servidor DNS.
O servidor DNS avalia as políticas de recursão e as consultas que são
recebidas na interface interna. Esta configuração de política aponta para um
escopo de recursão habilitado.
Em seguida, esse servidor executa recursão para obter a resposta para
www.google.com da Internet e armazena localmente a resposta em cache.
Se a consulta for recebida na interface externa, nenhuma política de DNS
correspondente será utilizada, e a configuração de recursão que será aplicada,
neste caso, é a desabilitada.
Criar escopos de recursão
Escopos de recursão são instâncias exclusivas de um grupo de configurações
que controlam recursão em um servidor DNS. Um escopo de recursão
contém uma lista de encaminhadores e especifica se a recursão está
habilitada. Um servidor DNS pode ter vários escopos de recursão.
A configuração de recursão herdada e a lista de encaminhadores são
chamados de escopo de recursão padrão. Não se pode adicionar ou remover o
escopo de recursão padrão, que é identificado pela zona ponto (“.”).
No exemplo abaixo, a configuração de recursão padrão está desabilitada,
enquanto um novo escopo de recursão para clientes internos está sendo
criado, e a recursão está habilitada.
Set-DnsServerRecursionScope -Name . -EnableRecursion $False
Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion
$True
 
Criar políticas de recursão
Se o servidor DNS não for autoritativo para algumas consultas, as políticas de
recursão de servidor DNS permitirão que o usuário controle como resolver as
consultas.
Abaixo, segue o exemplo de um escopo de recursão interno com recursão
habilitado, associado à interface de rede privada. O comando a seguir pode
ser empregado para configurar as políticas de recursão.
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainRecursionPolicy"
-Action ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -
ServerInterfaceIP "EQ,10.0.0.5"
 
Milhares de políticas de DNS podem ser criadas de acordo com tráfego, e
todas as novas políticas são aplicadas dinamicamente, sem necessidade de
reiniciar o serviço, ou o servidor DNS.
Eventos
Todos os eventos do DNS podem ser monitorados através do visualizador de
eventos, em Application and Services Logs. Na guia Event Logging, nas
propriedades do DNS, configura-se os tipos de eventos que se quer visualizar.
Estes eventos podem incluir as alterações no DNS, quando o serviço é
reiniciado devido às ocorrências abaixo:
Transferência de zona;
Modificações nas configurações;
Notificações de avisos e erros.
 
FIGURA 07-05. Dns Event Log com Event Viewer.
Por padrão, o serviço de DNS registra todos estes eventos. Muitos
administradores registram todos os eventos, mesmo quando interessados em
um evento específico.
Se houver a necessidade de depurar (debug) o servidor de DNS, é possível
habilitar a guia Debug Logging nas propriedades do servidor. Este é um
recurso muito exclusivo e só deve ser utilizado se houver um problema muito
específico, ou se deseja identificar o problema. Ainda, o Debug Logging
pode ser configurado para usar um filtro que registre somente o tráfego de
determinado host, ao invés de registrar o tráfego de todos os hosts da rede
que interagem com o servidor de DNS.
Opções DNS
Em ambientes altamente seguros, existem algumas tarefas que devem ser
executadas para proteger o serviço de DNS contra ataques que tentam
enganá-lo (spoof). Um processo spoofing pode permitir que o servidor DNS
encaminhe requisições de computadores clientes para sites maliciosos.
Enquanto o DNSSec inibe este ataque, a maioria do tráfego dos servidores
DNS envolve a recuperação de informações de servidores DNS remotos, e a
transmissão de informações aos clientes.
DNS Socket Pool
DNS socket pool é uma tecnologia que dificulta a manipulação e a
falsificação de cache, ao usar portas aleatórias para enviar consultas DNS aos
servidores DNS remotos. Para falsificar o servidor DNS com um registro
incorreto, o invasor precisa adivinhar qual porta foi usada, bem como o ID da
transação. Um servidor DNS executando o Windows Server 2016 usa um
socket pool de 2.500, por padrão. A ferramenta de linha de comando dnscmd
pode ser usada para alterar o tamanho do pool para um valor entre 0 e 10.000.
Por exemplo, para definir o socket pool para o valor 5000, execute o seguinte
comando:
Dnscmd /config /socketpoolsize 5000
 
Será necessário reiniciar o serviço de DNS para que estas alterações tenham
efeito.
DNS Cache Locking
O cache locking permite controlar o momento em que as informações
armazenadas no cache dos servidores DNS podem ser substituídas. Por
exemplo, quando um servidor DNS recursivo responde para uma pesquisa
com um registro que está armazenado em outro servidor DNS, ele coloca em
cache o resultado da pesquisa. Assim, ele não terá que entrar em contato com
o servidor DNS remoto novamente até que o tempo do registro em cache
(Time to Live (TTL) expire. Por padrão, este tempo é de 20 minutos nos
servidores DNS Microsoft.
O bloqueio do cache evita que os dados de registro no cache de um servidor
DNS sejam substituídos até que uma porcentagem configurada no valor TTL
tenha expirado. Por norma, o valor de bloqueio do cache é definido em
100%, mas ele pode ser redefinido pelo cmdlet Set-DnsServerCache, com a
opção LockingPercent. Por exemplo, para definir o bloqueio de cache para
um valor de 80%, executa-se o seguinte comando:
Set-DnsServerCache -LockingPercent 80
 
Logo após, reinicie o serviço de DNS.
Recursão
Via de regra, os servidores DNS no Windows Server 2016 executam
consultas recursivas em nome de computadores clientes. Ou seja, quando o
cliente solicita ao servidor DNS que encontre um registro não armazenado
em uma zona do próprio servidor DNS, este servidor sai em busca dos
resultados dessa consulta, retornando-os para o cliente.
No entanto, pode ocorrer de terceiros utilizarem a recursão como um vetor de
ataque de negação de serviço, podendo retardar o servidor DNS até o ponto
de não resposta. Essa recursão pode ser desativada na guia avançada de
propriedades do servidor DNS, ou pode ser configurada pelo cmdlet Set-
DnsServerRecursion. Para configurar o intervalo de repetição de recursão
para 4 segundos, use o seguinte comando:
Set-DNSServerRecursion – RetryInterval 4 -PassThruOrdenação da Máscara
A ordenação da máscara de subrede garante que o servidor DNS retorne o
registro do host na subrede do cliente solicitante, caso esse registro exista.
Suponhamos que existam três servidores WSUS localizados em três sites
diferentes, com uma máscara de subrede de 24 bits (/24):
192.168.0.10 wsus.banin.com
192.168.1.10 wsus.banin.com
192.168.1.10 wsus.banin.com
 
Se a ordenação de máscara estiver habilitada, e o computador cliente com o
IP 192.168.1.50 realizar uma consulta para o nome wsus.banin.com, ele terá
como resposta o IP 192.168.1.10. Isso ocorrerá porque o registro está na
mesma subrede do computador que solicitou a pesquisa. Ele identifica que
eles estão na mesma rede local, e mais próximos um do outro. Se a ordenação
da máscara de subrede estiver desabilitada, entretanto, o servidor DNS
retornará um registro aleatório, usando o Round Robin.
Por norma, esta função vem habilitada no DNS do Windows Server 2016.
Nas propriedades avançadas do servidor DNS, é possível verificar se esta
configuração está habilitada.
Response Rate Limiting (RRL)
Os ataques distribuídos de negação de serviço contra servidores DNS estão se
tornando cada vez mais comuns. Um método para ampliar a proteção contra
estes ataques é limitar a taxa de respostas, uma funcionalidade nova no
Windows Server 2016. Ela também determina como um servidor DNS deverá
responder aos clientes que enviam um número elevado de consultas.
Podem-se configurar as seguintes limitações nas respostas:
Respostas por segundo. Determina o número máximo de vezes que uma
resposta identificada pode ser retornada para um cliente, por segundo.
Erros por segundo. Determina o número máximo de erros retornado para
um cliente, por segundo.
Janela. O período limite para qualquer cliente que exceda o limite
máximo de solicitação.
Taxa de vazamento. Determina a frequência com que o servidor DNS
responderá às consultas, se um cliente estiver na janela de suspensão. A
taxa de vazamento é o número de consultas necessárias para que uma
resposta seja enviada. Uma taxa 40 significa que o servidor DNS
responderá apenas a uma, entre 40 consultas, de um cliente em período de
suspensão.
Taxa de TC. Indica ao cliente que tente se conectar através de TCP,
quando ele estiver na janela de suspensão. A taxa TC deve estar abaixo da
taxa de vazamento, para que o cliente possa tentar uma conexão TCP
antes que uma resposta de vazamento seja enviada.
Respostas máximas. O número máximo de respostas que um servidor
DNS emite para um cliente durante o período limite.
Lista branca de domínios. Domínios que são excluídos das
configurações de limitação da taxa de resposta.
Lista branca de subredes. Subredes que são excluídas das configurações
de limitação da taxa de resposta.
Lista branca de interfaces de rede. As interfaces do servidor DNS que
são excluídas das configurações de limitação da taxa de resposta.
 
Por padrão, o RRL é desabilitado no DNS. Para habilitá-lo, use o seguinte
comando:
Set-DNSServerRRL
 
 O RRL pode ser configurado com o cmdlet Set-
DnsServerResponseRateLimiting. No exemplo abaixo, criei uma lista branca
chamada WhiteList, que não aplica qualquer restrição para o domínio
banin.com.
Add-DnsServerResponseRateLimitingExceptionList -name “WriteList” -
Fqdn “EQ, *.banin.com”
 
DANE
O DANE (DNS Authentication of Name Entities) bloqueia ataques a um
certificado emitido a partir de uma CA (Certificate Authority), e é usado para
fornecer validação para um site. Quando o DANE é instalado, um cliente que
solicita uma conexão TLS para um registro como, por exemplo,
www.microsoft.com, sabe que só deverá aceitar um certificado TLS de uma
CA. Se o certificado TLS do site www.microsoft.com for de uma CA
diferente, o cliente saberá que este site pode ter sido comprometido, ou que o
cliente pode ter sido redirecionado por um invasor que pretendia corromper
um cache de DNS.
Delegação na Administração
Em alguns ambientes maiores, concedem-se privilégios administrativos a
pessoas responsáveis pelo gerenciamento do serviço de DNS da empresa,
mas que não tenham outra permissão, como a capacidade de criar contas de
usuário ou redefinir senhas. Via de regra, os membros do grupo Domain
Admins podem executar todas as tarefas de administração do servidor DNS
dentro de um domínio. Já os usuários membros do grupo Enterprise Admins
podem executar todas as tarefas de administração em qualquer servidor DNS,
de toda uma floresta do Active Directory.
O grupo local chamado DNS Admins concede aos usuários a capacidade de
visualizar e modificar configurações do DNS. Adicione usuários a este grupo
quando quiser permitir que eles executem tarefas de administração no serviço
de DNS, sem dar permissão adicional. Ainda, é possível atribuir permissão a
usuários ou grupos de segurança que gerenciem um servidor DNS específico
na guia de segurança, nas propriedades do servidor. Esse procedimento
também pode ser executado no nível da zona.
FIGURA 07-06. Grupo DnsAdmins.
Protocolo PNRP
O protocolo PNRP( Peer Name Resolution Protocol) fornece IPv6 para uma
resolução de nomes do tipo Peer-To-Peer. Os dispositivos conectados à
Internet que estão associados a endereços IPv6 podem publicar sua
combinação de endereços e nomes e fornecê-los aos pares. Estas
combinações de nomes incluem o FQDN e o nome único. Outros dispositivos
consultam peers (colegas) para aprender informações de endereçamento
IPV6.
Imaginemos, por exemplo, que existam computadores nomeados em Rio
Grande do Sul, Santa Catarina, Paraná, São Paulo, Rio de Janeiro, Bahia. Os
computadores do Rio Grande do Sul precisam saber o endereço IPv6 de
dispositivos que estão na Bahia. Os computadores do Rio Grande do Sul
estão mais próximos dos computadores de Santa Catarina, Paraná e São
Paulo, e fazem consulta nestes servidores, e nos demais, para determinar
quais deles sabem os endereços IPv6 dos servidores da Bahia. Ao invés de
usar um servidor central, como o DNS, o PNRP usa informações de cada
computador, individualmente, até chegar ao seu objetivo. Seguem, abaixo, as
propriedades do protocolo Peer Name Resolution:
Não requer infraestrutura centralizada. Os servidores só precisam suportar
bootstraping.
Pode escalar até bilhões de nomes, e é tolerante a falha. Múltiplos
computadores podem hospedar cópias dos mesmos registros PNRP.
Os nomes são atualizados em tempo real, e o PNRP é programado para
não retornar endereços desatualizados.
Pode ser usado para resolver nomes de serviços e, não só, de
computadores.
Os nomes podem ser publicados em um ambiente seguro ou inseguro.
Quando publicado de maneira segura, o PNRP usa uma criptografia de
chave pública para validar os registros.
É instalado como uma função.
 
DNSSec
A extensão DNSSEC (Domain Name System Security Extension) adiciona
mecanismos de segurança ao DNS, permitindo que seus servidores validem
as respostas fornecidas por outros servidores DNS. A DNSSEC permite que
as assinaturas digitais sejam usadas com as zonas de DNS.
Quando um dispositivo, serviço ou usuário emite uma consulta para um
registro em uma zona assinada, o servidor de DNS autorizado fornece tanto o
registro, quanto a assinatura digital, permitindo a validação desse registro. A
figura a seguir mostra os registros de recursos DNS na zona contoso.com,
antes e depois da assinatura da zona.
Para configurar uma zona assinatura com a DNSSEC, execute as seguintes
etapas:
Para assinar sua zona digitalmente, clique com o botão direito em Forward
lookup zones. Depois, clique em DNSSEC e em Sign the zone (assinar a
zona).
Na página Signing Options (opções de assinatura), selecione Use Default
Settings para assinar a zona.
FIGURA 07-07. Assinatura de uma zona com DNSSec.
Quando se configura a DNSSEC, três novos registros ficam disponíveis.
Seguem, abaixo, suas propriedades:
Registro RRSIG. Este registroé armazenado dentro da zona, e cada um está
associado a um registro de zona diferente. Quando o servidor DNS é
consultado para um registro, ele retorna o registro e o registro RRSIG
associado.
DNSKEY. Este é um registro de chave pública que permite a validação de
registros RRSIG.
Next Secure (NSEC / NSEC3). Este registro é usado como prova de que um
registro não existe. Por exemplo, imaginemos que a zona banin.com esteja
configurada com a DNSSEC e um cliente emite uma consulta para um
registro host webprod.banin.com.Se não houver o registro para
webprod.banin.com, o registro NSEC retornará com a informação de que
nenhum registro existe.
Além dos registros especiais, uma implementação de DNSSEC possui os
seguintes componentes:
Trust Anchor. Está é a chave pública especial associada a uma zona. O Trust
Anchor permite que um servidor DNS valide os registros de recursos
DNSKEY. Ao implantar a DNSSEC em um servidor DNS hospedado em um
controlador de domínio, o Trust Anchor pode ser armazenado na partição de
diretório da floresta (ForestDnsZones). Assim, o Trust Anchor será replicado
em todos os controladores de domínio que também sejam servidores DNS em
toda a floresta. Em servidores DNS autônomos, o Trust Anchor é armazenado
em um arquivo chamado TrustAnchors.dns. Pode-se, também, utilizar o
Powershell para exigir os trust anchors.
Get-DnsServerTrustAnchor -Name banin.com
DNSSEC Key Master. Este é um servidor DNS especial para gerar e
gerenciar chaves de assinatura para uma zona protegida com a DNSSEC.
Qualquer computador com o Windows Server 2012, ou versão posterior, que
hospede uma zona primária, seja padrão ou integrada, pode funcionar como
um mestre de chaves DNSSEC. Um único computador pode funcionar como
DNSSEC Key Master para múltiplas zonas. A função DNSSEC Key Master
também pode ser transferida para outro servidor DNS que hospeda a zona
principal.
Key Signing Key (KSK). O KSK é empregado para assinar todos os
registros DNSKEY na raiz da zona. Para criá-lo, usa-se o DNSSEC Key
Master.
FIGURA 07-08. Key Signing Key (KSK).
Zone Signing Key (ZSK). O ZSK serve para assinar dados de zona, como os
registros individuais hospedados na zona. Para criar o ZSK utiliza-se o
DNSSEC Key master.
FIGURA 07-09. Zone Signing Key (ZSK).
Uma GPO pode ser configurada, de forma a garantir que os clientes aceitem
registros de um servidor DNS para uma zona específica, apenas se esses
registros tiverem sido assinados usando a DNSSEC. Isso pode ser feito
ajustando o Name Resolution Policy Table, localizado em: Computer
Configuration \ Policies \ Windows Settings \ Name Resolution Policy. Cria-
se uma entrada em uma tabela, por exemplo, definindo que todas as consultas
contra uma zona exijam validação DNSSEC.
A tabela a seguir mostra o processo de consulta DNS recursivo:
Etapa Consulta-resposta Dados de
DNSSec
opcionais
1 Um cliente DNS envia
uma consulta para um
servidor DNS recursivo.
O cliente DNS
pode indicar que
tem suporte a
DNSSec (DO=1).
2 O servidor DNS
recursivo envia uma
consulta DNS para
servidores DNS TLD
(domínio de nível
superior) e raiz.
O servidor DNS
recursivo pode
indicar que tem
suporte a
DNSSEC
(DO=1).
3 Os servidores TLD e
raiz retornam uma
resposta DNS para o
servidor DNS recursivo
fornecendo o endereço
IP do servidor DNS
autoritativo para a zona
Os servidores
autoritativos para
a zona pai podem
indicar que a zona
filha é assinada
usando DNSSEC,
e incluem uma
delegação segura
(registro DS).
4 O servidor DNS
recursivo envia uma
consulta para o servidor
DNS autoritativo da
zona.
O servidor DNS
autoritativo
responde a
consulta para a
zona.
O servidor DNS
recursivo pode
indicar que tem
suporte a
DNSSEC (DO=
1) e é capaz de
validar os
registros de
recursos
assinados (CD =
1) a serem
enviados na
resposta.
5 O servidor DNS
autoritativo retorna uma
resposta para o servidor
O servidor DNS
autoritativo pode
incluir assinaturas
DNS recursivo,
fornecendo os dados de
registro de recurso.
DNSSEC, na
forma de registros
RRSIG, na
resposta DNS,
para fins de
validação.
6 O servidor DNS
recursivo retorna uma
resposta para o cliente
DNS, fornecendo os
dados de registro de
recurso.
O servidor DNS
recursivo pode
indicar se a
resposta foi
validada (AD = 1)
ou não, usando a
DNSSEC.
Exemplo 01. Uma consulta é enviada a um servidor DNS para um registro de
endereço (A) na zona assinada secure.banin.com com DO=0.
ResolveDNSName www.secure.banin.com -type A -Server
adds01.banin.com
Neste exemplo, o bit DO não foi recebido, pois o parâmetro dnssecok não foi
incluído.
Exemplo 02. O sinalizador DO=1 é definido adicionando-se o parâmetro
dnssecok.
Resolve-DnsName www.secure.banin.com -type A -server
adds01.banin.com -dnssecok
Quando DO=0, o servidor DNS não enviará dados de DNSSec. Quando
DO=1, o cliente indica que é capaz de receber dados de DNSSec. Como a
zona secure.banin.com é assinada, um registro de recurso RRSIG será
incluído como resposta DNS.
Nos dois exemplos acima, a validação não é necessária para a zona
secure.banin.com, porque a NRPT (Tabela de Políticas de Resolução de
Nomes) não está configurada para exigir validação. O cmdlet Get-
DnsClientNrptPolicy pode ser empregado para exigir as regras atuais. Se o
valor de DnsSecValidationRequired for falso ( False), isso significa que a
validação de DNSSec não será necessária.
FIGURA 07-10. Zona banin.com assinada e protegida com DNSSec.
A DNSSEC é apropriada para ambientes de alta segurança, como aqueles em
que o IPSec e os switches de autenticação estão em uso. Ela protege contra
ataques, quando os clientes são alimentados com informações falsas de DNS.
Em muitos ambientes de pequeno e médio porte, a probabilidade de tal
ataque é mínima. No entanto, em ambientes de alta segurança, habilitá-la é
uma precaução sensata.
Simulado
Questão 01
Você está gerenciando o servidor DNS da sua empresa. Uma auditoria de
segurança interna determina que todas as respostas enviadas pelos servidores
DNS devem ser digitalmente assinadas por uma autoridade confiável.
Será necessário configurar os servidores DNS para atender esta necessidade.
Qual o procedimento a seguir?
A. Ativar a extensão DNSSEC (Domain Name System Security Extensions)
B. Ativar BIND secondaries
C. Ativar o round robin
D. Ativar auditoria
Questão 02
Uma organização está preocupada com a possibilidade de ataques mal-
intencionados contra os servidores DNS no domínio, particularmente no que
se refere ao uso da porta de comunicação padrão do DNS.
O que deve ser feito para garantir que a porta padrão de configuração do
DNS não seja usada?
A. Ativar o Response Rate Limiting (RRL)
B. Configurar o cache Locking
C. Configurar o DNS-based Authentication of Named Entities (DANE)
D. Ativar o uso do DNS socket pool
Questão 03
O comando abaixo é executado para criação de uma máquina virtual Nano
Server que será um servidor de DNS em um host Hyper-V 2016:
New-NanoServerImage -MediaPath G:\ -BasePath .\Base -TargetPath
.\NanoDNS.vhd -ComputerName NanoDNS -GuestDrivers -Packages
Microsoft-NanoServer-DNS-Package.
Logo após, inicia-se a máquina virtual e habilita-se o PowerShell Remoting.
Qual comando deve ser usado para instalar a função de DNS e as ferramentas
de gestão?
A. Add-DNSServer
B. Install-DNSServer
C. Add-WindowsFeature
D. Enable-WindowsOptionalFeature
Questão 04
Um servidor DNS é promovido como controlador de domínio (ADDS).
Agora, será necessário ativar uma funcionalidade para protegê-lo contra
ataques do tipo DDoS (Negação de serviço).
Qual funcionalidade deve ser ativada ?
A. Cache Locking
B. Stub zone
C. Response Rate Limiting
D. Socket Pool
 
Questão 05
Um servidor chamado SRV01, que está executando o Windows Server 2016,
também está configurado como servidor DNS.Como se configura a segurança deste servidor para evitar ataques de
envenenamento de cache?
A. Dnscmd
B. Set-DnsServerRRL
C. Set-DnsServerDsSetting
D. Set-DnsCache
Questão 06
Em uma empresa, todas as zonas de DNS são integradas ao Active Directory,
do qual você é o administrador. Esta empresa abre uma filial com uma nova
subrede como parte do mesmo domínio, e você decide configurar um
Windows Nano Server como um servidor de DNS nesta filial, de forma a
minimizar o tráfego gerado por ela referente as requisições de resolução de
nomes. O serviço de DNS também é instalado no Nano Server.
Qual procedimento deverá ser realizado a seguir?
A. Configurar o Nano Server como um controlador de domínio.
B. Configurar uma zona secundária no Nano Server.
C. Criar uma zona primária com mesmo nome.
D. Configurar uma zona Stub.
Questão 07
O dominio banin.com. está integrado à floresta do Active Directory. Os
Encaminhadores estão desabilitados e os servidores Root Hints são usados
para nomes públicos.
Qual comando deve ser executado para garantir que um servidor Root Hint
com o endereço IP 192.168.100.100 seja verificado, quando o DNS não
puder resolver localmente para ns1.gilsonbanin.com? Sua solução não deve
afetar os outros servidores Root Hints.
A. Dnscmd -NameServer “ns1.gilsonbanin.com” -IPAddress
172.168.100.100
B. Add-DnsServerRootHint -NameServer “ns1.gilsonbanin.com” -IPAddress
192.168.100.100
C. Set-DnsServerRootHint -NameServer “ns1.gilsonbanin.com” -IPAddress
192.168.100.100
D. Enable-DNSForwarding -NameServer “ns1.gilsonbanin.com” -IPAddress
192.168.100.100
Questão 08
Você é o administrador da floresta do Active Directory banin.com. Todas as
zonas nos servidores DNS são integradas ao Active Directory.
Ao identificar quatro usuários do domínio que deveriam ser capazes de
visualizar, mas não modificar os encaminhadores e zonas reversas (reverse
lookup zones), você cria um grupo chamado DNS Operators, e adiciona os
quatro usuários como membros.
Agora, será necessário configurar a permissão administrativa mínima
necessária para estes usuários, usando o mínimo esforço. Como isso deve ser
feito?
A. Usar o comando Dnscmd
B. Usar o Active Directory Users and Computers
C. Usar a console DNS Manager
D. Usar o comando Set-DnsServerGlobalNameZone
Questão 09
Uma empresa adquire outra e será necessário criar uma relação de confiança
entre duas florestas do Active Directory. O nome da floresta da empresa
adquirida é pfelab.com. Este domínio tem um único servidor DNS, que
responde pelo nome ds.labpfe.com, com o IP 172.16.100.100.
Qual comando deve ser executado para garantir que as requisições de nomes
enviadas do servidor DNS para a zona labpfe.com sejam enviadas somente
para ds.labpfe.com?
A. Add-DnsServerForwarder -Name “labpfe.com” -MasterServers
172.16.100.100
B. Add-DnsServerForwarder -Name “ds.labpfe.com” -MasterServers
172.16.100.100
C. Add-DnsServerConditionalForwarderZone -Name “labpfe.com” -
MasterServers 172.16.100.100
D. Add-DnsServerConditionalForwarderZone -Name “ds.labpfe.com” -
MasterServers 172.16.100.100
Questão 10
O DNS está sendo configurado em um servidor membro do domínio do
Windows Server 2016 Standard. A empresa tem três datacenters em
diferentes continentes, e todos os três datacenters fornecem os mesmos
serviços internos, incluindo servidores web, servidores de arquivos e de
aplicação.
Como se deve configurar o DNS para resolver o IP dos serviços do datacenter
mais próximo ao usuário, com base em sua localização?
A. Criar uma política de geo. localização baseada em tráfego de rede
B. Configurar o DHCP para alocar o IP do servidor DNS local de cada site
C. Configurar no servidor DNS o round-robin
D. Configurar no servidor DNS o Netmask Ordering Resolution
Questão 11
Uma empresa está usando um servidor de arquivos que, em breve, será
substituído por outro mais novo.
Qual registro deve ser criado para garantir que os usuários não sofram
impacto com a mudança do servidor FileSever01 para FileServer02?
A. SRV
B. PTR
C. A
D. CNAME
Questão 12
Qual comando do PowerShell se utiliza para listar todos os cmdlets
disponíveis no módulo PowerShell do servidor DNS?
A. Get-DnsServer -cmdlets
B. Get-Dnsserver -NounCommand
C. Get-Command -Noun DnsServer
D. Get-Command – Module DNSServer
Questão 13
Qual cmdlet do PowerShell é empregado para modificar uma política
existente de resolução de consulta no servidor DNS?
A. Add-DnsServerQueryResolutionPolicy
B. Get-DnsServerQueryResolutionPolicy
C. Set-DnsServerQueryResolutionPolicy
D. Change-DnsServerQueryResolutionPolicy
Questão 14
Qual tipo de registro DNSSEC é usado para proteger e criar uma cadeia de
autenticação?
A. DNSKEY
B. DS
C. RRSIG
D. AAAA
Questão 15
Qual cmdlet do PowerShell pode ser utilizado para excluir um endereço de
um servidor raiz comprometido na lista de dicas raiz, em um servidor de
DNS?
A. Change-DNSServerRootHint
B. Remove-DnsServerRootHint
C. Set-DnsServerRootHing
D. Erase-DnsServerRootHing
Questão 16
Qual dos seguintes itens deve ser criado antes das políticas de
redirecionamento DNS geográfico?
A. Interface do servidor e subredes
B. Escopo de zonas e subredes
C. Encaminhador condicional e subredes
D. Auditoria e subredes
Questão 17
Qual comando do PowerShell serve para visualizar as estatísticas de um
servidor DNS?
A. Get-DnsServerStatistics
B. Query-DnsServerStatistics
C. Select-DnsServerStatistics
D. List-DnsServerStatistics
Questão 18
Qual cmdlet PowerShell usar deve ser usado para adicionar um apelido
(alias) em uma zona de DNS?
A. Add-DnsServerResourceRecordCName
B. Add-DnsServerResourceRecordA
C. Add-DnsServerResourceRecordTXT
D. Add-DnsServerResourceRecordSRV
Questão 19
Qual cmdlet do PowerShell é usado para resolver consultas DNS?
A. Lookup-DNSName
B. Get-DnsName
C. NSLookup-DNSName
D. Resolve-DnsName
Questão 20
Qual cmdlet do PowerShell pode habilitar a taxa de resposta (response rate
limiting) do servidor DNS?
A. Add-DnsServerResponseRateLimiting
B. Include-DnsServerResponseRateLimiting
C. Set-DnsServerReponseRateLimiting
D. Enable-DnsServerResponseRateLimiting
Respostas
01-A 02-D 03-D 04-C 05-A 06-B 07-B 08-C 09-C 10-A
11-D 12-D 13-C 14-B 15-B 16-B 17-A 18-A 19-D 20-C
 
CAPÍTULO 08 – Implantar DHCP
e IPAM
Sem o DHCP (Dynamic Host Configuration Protocol), a vida de um
profissional de TI seria muito mais difícil, pois ele facilita a conexão de uma
rede e permite ao usuário ir embora para casa mais cedo. Nesta sessão,
abordaremos todos os tópicos relacionados a instalação de um servidor
DHCP no Windows Server 2016.
Seguem abaixo alguns desses tópicos:
Funcionamento do DHCP ;
Instalação e configuração;
Automação e alocação de endereços IPv4 e IPv6;
Manutenção de um servidor DHCP;
Implementação de alta disponibilidade ;
No final desta sessão, você será capaz de instalar, com sucesso, o serviço de
alocação dinâmica de endereços IPs em sua empresa.
Para que qualquer dispositivo se comunique em uma rede TCP/IP, será
necessário um protocolo de internet, ou endereço IP. A maneira mais fácil de
resolver este endereço automaticamente é pela instalação do Dynamic Host
Configuration Protocol (DHCP). E o servidor Windows é ótimo para
gerenciá-lo.
Introdução
O DHCP é um protocolo padrão da indústria, usado por quase todos os
dispositivos de informática do planeta. É muito provável que o Windows,
Linux, Mac, e qualquer outro sistema operacional, empreguem o DHCP para
atribuir um endereço IP e outros itens de configuração, tais como endereços
de gateway, roteadores e servidores de nomes, pois ele é absolutamente
crítico para a maioria dos ambientes. O DHCP está aqui para facilitar a vida
de todos nós, visto que ele dispensa a configuração manual de cada
computador cliente ou dispositivo deuma rede.
Para que os clientes possam se comunicar nessas redes, eles precisam desse
endereço IP que vem em dois formatos: IPv4 e IPv6. Falaremos sobre esses
dois tipos de endereços que utilizam o DHCP, mas não nos aprofundaremos
em suas características, pois espera-se que o leitor tenha um conhecimento
prévio sobre eles.
Em resumo, os endereços IPv4 são formados por 32 bits, representados por
uma notação decimal separada por ponto (.), e divididos por quatro grupos
decimais que variam de 0 a 255 (octetos). Os endereços IPv6 são valores de
128 bits, divididos em oito grupos de quatro dígitos hexadecimais, separados
por dois pontos (:).
Representação de endereços IPv4 e IPv6:
IPv4 IPv6
192.168.190.50 Fe80::f04b:97aa:d8d5:b1cf
192.168.190.60 Fe80::f04b:97aa:d8d5:b1cg
Funcionamento do DHCP
Digamos que um novo computador Windows 10 Enterprise é adicionado à
rede. Durante o processo de inicialização, o cliente faz um pedido para um
endereço IP, através de uma mensagem de transmissão (broadcast). Lembre-
se que as mensagens de transmissão não são roteáveis (não podem atravessar
um gateway), então os computadores clientes e o servidor DHCP precisam
estar no mesmo segmento de rede (na mesma subrede).
Se um servidor DHCP não estiver disponível para atender o pedido do
cliente, deve haver um agente de retransmissão (DHCP Relay Agent), que
seja responsável por transmitir todas as comunicações entre um cliente e um
servidor durante o processo de solicitação de informações DHCP. Em geral, o
DHCP Relay Agent é configurado no roteador, mas o Windows Server 2016
também pode exercer essa função, usando o roteamento e o acesso remoto
(RRAS), embora isso raramente aconteça. No mundo real, recomenda-se que
se entre em contato com o administrador de rede para configurar novos
escopos de DHCP. Ele saberá o que precisa ser feito nos roteadores, contanto
que ele tenha o endereço IP do servidor DHCP em questão. Quando o DHCP
recebe o pedido de outro segmento de rede, ele analisa o banco de dados para
determinar se há um escopo que represente o mesmo segmento de rede e se
há algum endereço disponível. Uma vez que o cliente receba o endereço de
IP, ele já poderá se comunicar na rede.
Como mencionado anteriormente, o DHCP usa mensagens de transmissão
(broadcast) para solicitação de um endereço IP. Essas mensagens são
divididas em quatro fases:
DHCP Discover;
DHCP Offer;
DHCP Request;
DHCP Ack.
Primeiro, o cliente DHCP envia uma mensagem de descoberta de DHCP
(DHCP Discover) para pedir um endereço IP e as informações de
configuração do host. Quando o servidor recebe este pedido, usa a
informação recebida para determinar o endereço IP que vai oferecer ao
cliente, além de verificar se há uma reserva, e então envia de volta a
informação que o cliente precisa para configurar o IP. Este processo é
conhecido como oferta DHCP (DHCP Offer). Uma vez que vários
servidores DHCP podem oferecer configurações de IP para um cliente, é
necessário que o cliente escolha qual oferta aceitar. Uma vez que ele aceite a
oferta do servidor, a mensagem de solicitação DHCP (DHCP Request) é
enviada de volta. Ela informa aos servidores DHCP qual endereço o cliente
aceitou, como se fosse uma aceitação oficial desse endereço. Em seguida, o
servidor reconhece o pedido e o cliente pode começar, oficialmente, a usar
esse endereço (DHCP Ack). É assim que funciona o processo de aquisição.
Suponhamos, agora, que um cliente precisa ser renovado. Uma vez que o
cliente possui um endereço IP, ele mantém esse endereço por um período
padrão. O administrador é quem determina tanto o tempo de locação, quanto
as necessidades dos usuários e dos dispositivos que utilizam os endereços IP.
No Windows, o período de locação padrão para uma conexão com fio (cabo)
é de oito (8) dias. Para clientes que estão na rede por um período mais longo,
como os que ficam constantemente conectados à rede em seus escritórios, o
DHCP usa um processo de renovação para estender esse período, além de
atualizar as opções que podem ter mudado desde a última concessão
adquirida.
Por padrão, os clientes tentarão uma renovação usando uma mensagem de
renovação (DHCP Renew), quando atingirem 50% do período de concessão.
Se o servidor DHCP aceitar essa renovação, ele estenderá a concessão. Caso
contrário, o cliente continuará usando a concessão anterior até sua expiração.
Após a expiração, o cliente retornará ao processo de descoberta novamente
(DHCP Discover).
Instalação e Configuração
Primeiramente, instala-se a função de DHCP em um servidor que seja
membro do domínio do Active Directory, através do PowerShell ou pelo
Server Manager. Uma vez instalado, é feita a pós-configuração, de acordo
com as instruções do assistente de configuração.
A primeira fase de configuração criará dois grupos: DHCP Administrators e
DHCP Users. Estes grupos serão criados localmente, caso se trate de um
servidor membro do domínio, ou no Active Directory, caso o servidor seja
um controlador de domínio. Além disso, o servidor será autorizado no Active
Directory sempre que o computador pertença a um domínio.
FIGURA 08-01. Provisionamento dos grupos DHCP Administrators e DHCP
Users.
Para instalá-lo através do Power Shell, caso não se tenha optado pela versão
Core, basta instalar as ferramentas administrativas no servidor com a função
RSAT-DHCP. O servidor não precisará ser reiniciado ao final do processo.
Install-WindowsFeature -Name DHCP -Computername
<DHCPServerName>
O DHCP Server deve ser autorizado no Active Directory:
Add-DHCPServerInDC -DnsName <DHCPServerName> -IP <IP Address>
Get-DHCPServerInDC
 Logo após, o serviço de DHCP estará instalado no servidor. Adicione o
usuário que será o administrador do DHCP como membro do grupo DHCP
Administrators.
Agora, já será possível gerenciar o servidor DHCP a partir de um computador
remoto com o Windows 10 Enterprise e o RSAT instalados.
Nota
Se o servidor DHCP tiver mais do que uma interface de rede, deve-se
escolher em qual interface o serviço deverá responder as requisições dos
clientes. Para isso, clique com o botão direito nas propriedades do servidor
e selecione Add / Remove Binding. Desmarque as interfaces de serviços
como Backup, Monitoramento, Clusters, se existirem. Se a lista de
interfaces estiver vazia, significa que a interface de rede não está
configurada com um IP estático.
A base de dados do DHCP fica armazenada, por padrão, em
C:\Windows\System32\Dhcp, e a pasta de backup, em
C:\Windows\System32\Dhcp\Backup.
Escopos
Por meio da criação de escopos em um servidor DHCP, os clientes obtêm
endereços IP e outras informações de configuração automaticamente.
Primeiramente, discutiremos os escopos para IPv4 e aprenderemos sobre seus
diferentes tipos: regular, super e multicast. Ao longo do caminho,
ensinaremos a criar esses escopos usando a interface gráfica (GUI) e o
PowerShell. Só então, apresentaremos as opções DHCP. Elas permitem
fornecer aos clientes informações de configuração adicionais, como é o caso
dos servidores DNS, servidores de tempo (NTP), o nome do domínio e o
endereço do roteador como gateway padrão. Por fim, falaremos sobre
reservas e políticas.
.É altamente recomendado iniciar o nome de um escopo com o segmento de
rede que representa a subrede real. Isso facilitará a identificação imediata da
rede a qual pertence cada escopo. Por exemplo, o nome “10.10.0.0 Subnet”.
Nota
A faixa de endereço de um escopo pode ser alterada a qualquer momento,
mas a máscara de subrede não. Por exemplo, pode-se aumentar a faixa de
10.10.0.41-10.10.0.200, com máscara /24, para 10.10.0.10-10.10.0.250,
com máscara /24, mas não se pode mudar para uma máscara de subrede
diferente de /24. Para isso, será necessário excluir o escopo e recriá-lo.
Uma vez que o serviço DHCP esteja instalado, será possível iniciar a
alocação dos endereços IP, criando e configurando um escopo