NAT Nativo no Hyper-V do Windows 10 (Versão 1511)

Olá Pessoal!

Se você esta habituado a trabalhar com máquinas virtuais em plataformas como o Oracle VitualBox ou VMWare Workstation possivelmente já configurou uma ou mais interfaces de rede de suas VMs em modo NAT (Network Address Translation). No modo NAT, a VM atua como um computador real que se conecta à Internet através de um roteador. O roteador, nesse caso, é representado pelo mecanismo de rede do software de virtualização. Por exemplo, o VirtualBox disponibiliza um "roteador virtual" entre cada VM e o host de virtualização, isso garante que cada VM possa acessar a Internet de forma transparente sem que exista comunicação entre as mesmas.

Em versões anteriores do Hyper-V existiam três tipos de switches virtuais:

• Privado (Private): Permite a comunicação entre as VMs em execução no host de virtualização. Até mesmo o sistema operacional de gerenciamento não está autorizado a se comunicar com tais VMs. Essa opção é 100% lógica e não cria nenhum adaptador virtual no sistema;
• Interno (Internal): Esse switch virtual é bem parecido com o privado, exceto pelo fato de que um adaptador de rede virtual é criado no sistema operacional de gerenciamento, permitindo a comunicação entre as VMs e o host de virtualização;
• Externo (External): Esse tipo de switch virtual é sempre conectado a um adaptador de rede físico. Ele permite que as máquinas virtuais possam se conectar a rede física por meio de tal adaptador.

Note que não existe um switch virtual específico a fim de compartilhar a conexão da Internet entre as VMs através de NAT. Logo, soluções alternativas como, por exemplo, o ICS (Internet Connection Sharing) eram adotadas.

A partir da versão 1511 do Windows 10 (atualização liberada no mês de novembro de 2015) é possível criar um switch virtual do tipo NAT. Todo o processo deve ser realizado por meio do Windows PowerShell.

Criando o switch NAT:

O processo para disponibilizar o novo switch do tipo NAT é dividido em duas partes: criar o switch virtual e então configurar o objeto NAT no sistema operacional host. Para criar o switch virtual execute o Windows PowerShell com credenciais administrativas e execute o seguinte comando:

New-VMSwitch -Name "NAT" -SwitchType NAT -NATSubnetAddress 10.0.2.0/24

 

O Parâmetro -Name define um nome qualquer para o novo switch virtual. O parâmetro -SwitchType define o tipo do novo switch e obrigatoriamente deve ser definido como "NAT". O parâmetro -NATSubnetAddress define a sub-rede que será usada pelos clientes quando conectados ao novo switch. Após a execução do comando, um novo adaptador de rede será criado no sistema operacional host.

 

Novo adaptador de rede virtual criado no sistema de gerenciamento.

 O endereço IP do novo adaptador de rede virtual será automaticamente definido como 10.0.2.1 (primeiro endereço disponível dentro da sub-rede 10.0.2.0/24). Observe que esse endereço será o gateway padrão para as VMs operando em modo NAT.

 

Propriedades do protocolo TCP/IPv4 do adaptador de rede NAT.

Agora, execute o seguinte comando do Windows PowerShell para instanciar o objeto NAT no sistema operacional host:

New-NetNat –Name NAT –InternalIPInterfaceAddressPrefix 10.0.2.0/24

 

O parâmetro -Name define o nome do novo objeto a ser instanciado no sistema operacional host. O parâmetro -InternalIPInterfaceAddressPrefix deve possuir o mesmo valor informado no comando anterior.

 

Testando as configurações:

 

Depois de configurar uma máquina virtual para utilizar o novo switch virtual, basta definir manualmente as configurações de rede. Em meu exemplo utilizei o endereço IP: 10.0.2.100/24 e o gateway padrão 10.0.2.1 (endereço IP da interface NAT). Não se esqueça de configurar um servidor DNS público qualquer.

 

Configuração do protocolo TCP/IPv4 da VM.

 

 

 

 

  

Mudanças no Licenciamento do Windows Server 2016

Olá Pessoal!

O Windows Server 2016 será lançado no segundo semestre de 2016 e a Microsoft já adiantou muitas informações quanto ao seu processo de licenciamento, é importante lembrar que tais informações poderão ser alteradas até o lançamento oficial do produto.

Muitos administradores de rede e gestores de TI não entendem que quando você compra uma licença do Windows Server, você está pagando pelo direito de instalar o software em um de seus servidores, ou seja, uma licença não é sinônimo de propriedade absoluta sobre o software. Historicamente, a família Windows Server segue o seguinte modelo de licenciamento:

Conforme proposto na figura acima, é necessário adquirir uma licença para o servidor, uma licença para a estação de trabalho (cliente) e uma CAL de acesso. Esse modelo permanece inalterado para o Windows Server 2016.

Uma Windows Server CAL (licença de acesso do cliente) licencia um usuário ou dispositivo a acessar qualquer edição do Windows Server da mesma versão da CAL comprada ou anterior, por exemplo: Sua rede é composta por 3 servidores executando o Windows Server 2008 R2, 4 servidores executando o Windows Server 2012 R2 e 2 servidores executando o Windows Server 2016. Se você possui 200 usuários será necessário comparar 200 licenças de acesso do cliente (CAL) do Windows Server 2016 a fim garantir que todos os usuários possam acessar recursos em todos os servidores. CAL de dispositivos são mais caras, porém algumas empresas possuem um número superior de usuários se comparado a dispositivos: Imagine uma empresa de telemarketing que possui 100 computadores e 300 usuários, a aquisição de CAL por dispositivo tornará o licenciamento menos custoso.

Vale lembrar que serviços como RDS (Remote Desktop Services) e AD RMS (Active Directory Rights Management Services) exigem CAL adicionais.

 Standard x Datacenter:

O que também se mantém inalterado, são as duas edições primárias do Windows Server (Standard e Datacenter) e as regras relativas a instalação do produto e máquinas virtuais. 

No Windows Server 2012 a Microsoft simplificou bastante o processo de licenciamento, tanto a versão Standard quanto a versão Datacenter disponibilizavam os mesmos recursos. A única diferença estava no número de máquinas virtuais que poderiam ser utilizadas sem a aquisição de licenças adicionais: 2 máquinas virtuais para a versão Standard e máquinas virtuais ilimitadas para a versão Datacenter (mesmo hardware). A partir do Windows Server 2016 as edições Standard e Datacenter voltarão a oferecer recursos distintos. As regras relacionadas ao número de máquinas virtuais sem aquisição de licenças adicionais permanecem inalteradas.

Licenciamento baseado no número de núcleos físicos do processador:

No Windows Server 2008 R2 apenas a edição Datacenter era licenciada a partir do número de processadores físicos existentes no servidor, as edições Standard e Enterprise eram adquiridas sem levar em conta o número de processadores físicos. A partir do Windows Server 2012 a Microsoft retirou a versão Enterprise de comercialização e passou a licenciar as edições Standard e Datacenter por número de processadores físicos (uma licença é necessária para cada dois processadores físicos instalados no servidor). A partir do Windows Server 2016 o licenciamento será baseado no número de núcleos físicos (core) existentes no processador. Vamos aos detalhes:

• Licenças de núcleos físicos serão vendidas em pacotes modulares de duas unidades;
• Minimamente serão exigidas 8 licenças de núcleos (4 x 2 licenças) por processador;
• Minimamente serão exigidas 16 licenças de núcleos (8 x 2 licenças) por servidor.

Você pode estar bem assustado agora, mas a Microsoft garante que o custo das licenças por núcleo físico adicional custará 1/8 do valor da licença adquirida hoje no Windows Server 2012 (1 licença para cada dois processadores físicos). Vale lembrar que núcleos virtuais não entram nessa conta.

Baixe o folheto oficial do licenciamento do Windows Server 2016 aqui. Para um guia de perguntas e respostas frequentes, clique aqui.

 

Servidores DHCP Redundantes no Windows Server 2012 R2

Olá Pessoal.

Atualmente grande parte das empresas contam com ao menos um servidor DHCP a fim de atribuir automaticamente endereços IP aos seus dispositivos. Por ser na maioria das vezes um serviço simples e de fácil implantação, grande parte dos administradores acabam esquecendo que seu funcionamento é crucial para operação da rede, visto que não existe comunicação sem um endereço IP. O modo de operação do DHCP favorece esse "abandono", uma vez que os endereços IP são na verdade "emprestados" aos clientes por um determinado período de tempo (lease), logo a indisponibilidade do servidor DHCP pode ser contornada sem grandes prejuízos ao ambiente.

Uma das maneiras mais simples de garantir a redundância e balanceamento de carga do DHCP é trabalhar com dois servidores ativos distribuindo endereços IP distintos dentro da mesma sub-rede. Essa configuração pode ser realizada de forma manual ou por meio do recurso split scope, presente a partir do Windows Server 2008 R2. É importante notar que nesse modo de operação não existe o conceito de cluster, ou seja, ao atingir o final do empréstimo obtido por meio do servidor momentaneamente indisponível, o cliente perderá conexão com a rede e o processo de atribuição dinâmica se inicializará novamente.

A partir do Windows Server 2012 a Microsoft adicionou ao serviço DHCP um recurso interno de failover, agora as concessões (lease) e todas as outras configurações são replicadas a um servidor parceiro, garantindo que o mesmo possa renovar os empréstimos de endereços IP inicialmente atribuídos por outro servidor, ou seja, não existe perda momentânea de conexão.

Pré-requisitos para implantação:

• Dois servidores executando o Windows Server 2012 ou superior;
• Serviço DHCP instalado em ambos os servidores;
• Ao menos um escopo devidamente configurado em qualquer um dos servidores.

Nota: A função de failover não é configurada diretamente para o servidor DHCP. As configurações de failover são definidas por escopo, ou seja, um único servidor DHCP pode hospedar réplicas primárias e secundárias de múltiplos escopos.

Cenário:

Nesse exemplo existem dois servidores DHCP: WS2012R2-01 e WS2012R2-02. O servidor WS2012R2-01 possui um único escopo configurado ([192.168.100.0] - Escopo 01). O servidor WS2012R2-02 apenas possui o serviço DHCP instalado (Figura 1).

Figura 1. Servidores DHCP.

Ao clicar com o botão direito em "Escopo 01" e selecionar a opção "Configurar Failover" o assistente abaixo é iniciado. Note que é possível ativar o failover para todos os escopos existentes no servidor ou apenas para escopos específicos (Figura 2).

Figura 2. Assistente de Configuração Failover DHCP (Seleção de Escopos).

  

Após clicar em "Avançar" digite o nome do servidor parceiro (Figura 3).

Figura 3. Nome do servidor parceiro.

Na próxima etapa do assistente de configuração a modalidade de failover é efetivamente definida (Figura 4).

Figura 4. Configuração do failover

Definição de cada uma das configurações realizadas na Figura 4:

Nome da Relação: Um nome qualquer que identifique a relação criada entre os servidores DHCP;

Prazo de Entrega Máximo do Cliente (MCLT): Talvez esse seja o parâmetro mais complexo de todo o processo de configuração. O MCLT define um tempo de empréstimo especial que será oferecido aos clientes em caso de falha em um dos servidores. Nos servidores DHCP Windows o valor definido no campo MCLT também é o primeiro tempo de empréstimo oferecido a novos clientes. Esse comportamento garante que não exista a possibilidade de distribuição de endereços IP duplicados em caso de falha do servidor primário antes de atualizar as informações sobre empréstimos ao servidor secundário. Exemplo: O cliente COMPUTADOR-01 obtive sua concessão a partir do servidor WS2012R2-01. O servidor WS2012R2-01 (primário) falha antes de enviar as informações sobre o empréstimo ao servidor WS2012R2-02 (secundário). Quando o cliente tentar renovar seu empréstimo por meio do servidor secundário, esse servidor desconhecerá qualquer informação sobre o cliente (fato que poderia causar a distribuição de endereços IP duplicados) porém detecta que o cliente utiliza um tempo de empréstimo igual ao MCLT e renova sua concessão mesmo não possuindo essa informação em seu banco de dados;

Modo: O modo de operação padrão do failover é de balanceamento de carga. Cada servidor é responsável por distribuir 50% do total de endereços IP disponíveis dentro do escopo. Também é possível optar pelo modo espera ativa (apenas um servidor distribui endereços IP, o servidor secundário é só utilizado em caso de falha no servidor primário). No modo espera ativa é necessário definir uma porcentagem de endereços IP que serão reservados ao o servidor secundário a fim de atender novos clientes em caso de falha no servidor primário (Figura 5);

Figura 5. Modo Espera ativa.

Intervalo de Alternância de Estado: Tempo que o servidor secundário tentará retomar a comunicação com o servidor primário antes de assumir o controle de todo escopo (100% dos endereços). Essa é outra configuração que costuma causar duvidas, na verdade o servidor secundário só assume o controle de todo escopo após o tempo definido no parâmetro "intervalo de alternância de estado" + MCLT. No exemplo apresentado na Figura 4 o servidor WS2012R2-02 iria assumir o controle total do escopo após duas horas;

Habilitar autenticação de Mensagem: Senha para garantir a relação de parceria somente entre os servidores autorizados.

Para informações sobre como configurar esse serviço no Linux clique Aqui!

Até a próxima!