Azure Arc–Gerenciamento integrado Multi-cloud
O Azure Arc é um produto em preview que tem a função de padronizar e permitir utilizar recursos do Azure para gerenciamento de VMs e Clusters Kubernets hospedados em ambientes on-premisse ou outras clouds integrado.
https://azure.microsoft.com/en-us/services/azure-arc/
Habilitando o Serviço por Registrar os Componentes
O primeiro passo é acessar as subscrições onde irá hospedar os serviços do Arc.
Uma vez escolhida a subscrição, deve-se registrar os recursos de Hybrid como abaixo.
Em geral o recurso ADHybridHS já estará habilitado e tem a ver especificamente com a sincronização de AD, mas os recursos de Compute, Data e Network precisam ser habilitados antes de incluir recursos:
Registrando Computadores e Recursos
Ao criar o recurso do Arc, escolha uma subscrição e um Resource Group para servir de base e que futuramente após o Preview irá ter o débito (se existir) dos serviços.
Logo após habilitar clique no botão Adicionar do primeiro print deste artigo e baixe o script para executar nos servidores. Caso queira abrir o script ele é bem simples e basicamente faz o download de um msi e o executa com os dados da subscrição.
A primeira execução do script mostra a obrigatoriedade de ativar os recursos, que foi o primeiro tópico desse artigo, e será um erro recorrente já que ao habilitar o Arc esse processo deveria ser automático.
Note que na execução do script ele gera um código que deverá ser confirmado no site indicado https://microsoft.com/devicelogin
Utilizando Politicas e Iniciativas
Assim que vinculados, já podem ser criadas e habilitadas as diferentes Politicas e iniciativas que serviriam para criar alertas e definir padronização de recursos no que geralmente chamamos de Compliance.
Por default as politicas acima são configuradas, mas é possivel criar novas para gerar reports de compliance. Para isso utilize as regras pré-existentes que irão facilitar diversos tipos diferentes de alertas como backup, antivirus, ASR, etc.
Já para as Iniciativas não estamos apenas verificando, mas implementando alguns tipos de padrões como o nivel de auditoria ou requisitos legais/padrões regulatórios:
Habilitando o Log Analytics
Para que os recursos funcionem corretamente é importante o auxilio do Log Analytics que irá capturar os dados do servidor para gerar alertas e mapas de relacionamento.
Para isso acesse os servidores e clique no aviso na tarja que é exibida e com isso poderá habilitar os recursos para cada servidor ou em Insights. Uma caracteristica interessante é que cada servidor pode utilizar subscrições diferentes ou até workspaces diferentes de Log Analytics.
A partir da integração que irá demorar de 5 a 10 minutos, já é possivel usar os monitores, alertas e até o mapa de relacionamento:
CONCLUSÃO
Em comporações com servidores fisicos, servidores virtuais e maquinas em clous ter a facilidade de integrar as funções de gerenciamento do Azure irá ajudar muito.
Grande parte do trabalho já é possivel no Log Analytics mas de forma passiva. Com a integração simples com as politicas, iniciativas e interface o uso do Azure Arc irá ser uma ferramenta excelente para profissionais de TI com ambientes multiplos de hospedagem.
Vamos Falar do Projeto Microsoft Honolulu?
O projeto Honolulu foi muito comentado a algum tempo atrás e linkado a uma nova interface gráfica do Windows ou funcionalidade.
Agora em 01/Dezembro saiu uma nova versão Preview e documentação do Honolulu e já está bem maduro e com arquitetura final definida.
O que é o projeto Honolulu?
É uma nova interface de GERENCIAMENTO para Windows Server.
Não se trata de uma substituição do Server Manager do Windows 2012/2016 e sim uma interface baseada em novos protocolos para acesso e facilidade de uso, alem da capilaridade no gerenciamento.
Quais as vantagens do Honolulu sobre o Server Manager?
O Server Manager é uma ferramenta muito boa, mas é baseada em protocolos locais (RPC, WinRM e outros) alem de ser baseada em uma GUI que precisa ser instalada.
O Honolulu é 100% baseado em web para acesso aos dados e utiliza WinRM, WMI e PowerShell para administração dos servidores.
Com o Honolulu é possivel fazer coisas que o Server Manager não faz, como executar scripts, Windows Update, administrar e monitorar VMs, etc.
Por outro lado, o Honolulu não administra tantos serviços como o Server Manager, como por exemplo File Server, DHCP, DNS, etc que continuam a ser administrados pelas ferramentas MMC.
Como instalar o Honolulu?
A instalação é muito simples, mas é preciso definir a arquitetura.
Basicamente podemos utilizar instalado em um unico servidor e vincular os outros na administração como nós, ou então instalar um servidor como Gateway para acessar os outros e facilitar o trafego quando temos muitos servidores em um farm:
Em geral para estas ferramentas o ideal é criar um servidor com pouca memoria e poder de processamento (na figura o segundo modelo) para não onerar servidores com outras funções, já que ele cria um serviço para o Honolulu:
Para baixar o Honolulu, como ainda é um Preview é necessário usar a página de avaliaçoes de produtos Windows Server em https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-honolulu
Como administrar um servidor com o Honolulu?
Vamos as telas básicas. Primeiro inserimos um servidor na lista e a partir dai é possivel por qualquer navegador ver os gráficos de uso, configurar itens, fazer conexão remota, executar comandos PowerShell, etc.
Primeiro, vamos adicionar novos servidores, clusters ou até Windows 10 Client:
Na sequencia basta indicar o usuário e escolher o servidor/cluster que deseja visualizar:
O nivel de detalhes aborda desde os itens de HW até gráficos detalhados para cada um dos itens vituais do servidor/cliente que está sendo monitorado:
Mesmo alguns itens como discos fisicos, volumes e Storage Space já podem ser administrados no Honolulu:
Uma feature interessante é poder administrar o Windows Update remotamente:
O gerenciamento de VMs em um Hyper-V tambem é um dos destaques pelo nivel de detalhamento e a interface intuitiva:
Finalizando, segue o link da documentação técnica do Honolulu: https://docs.microsoft.com/en-us/windows-server/manage/honolulu/honolulu
Volume de Storage Space não Remonta no Boot
Um problema recorrente que temos agora que diversos clientes passaram a usar o Storage Space para montar volumes RAID é ele não retornar montado quando a máquina é reiniciada.
SINTOMA
Todas as vezes que um servidor que tem discos configurados a partir do Storage Spaces do Windows 2012, é necessário ir em Volumes e refazer o Attach do disco.
No Server Manager, configuração de volumes do Storage Space abaixo, na coluna de warnings aparece um aviso amarelo, indicando que o disco está ok e com o botão direito acessamos o Attach e ele retorna a aparecer no servidor com a mesma configuração e letra definidos originalmente.
CAUSA
Quando um Storage Space é montado, uma das opções que se pode definir pelo PowerShell (é automático na GUI Server Manager) é o IsManualAttach que deverá estar em True.
Quando o disco é movido de um servidor para outro ou redefinido por adição de disco o Manual Attach retorna ao padrão que é False.
SOLUÇÃO
A solução é muito simples, utilize o PowerShell abaixo para listar os volumes que estão como manual:
get-virtualdisk | where IsManualAttach
Será gerada uma lista como a copiada abaixo, onde pode-se ver que o IsManualAttach está habilitado:
Utilizando o nome do disco, que é o nome que aparece no Windows Explorer, você pode desativar o attach manual:
Set-VirtualDisk –FriendlyName RAID-VMs -IsManualAttach $False
Gartner libera novo quadrante de Hypervisors x86
O Gartner liberou no meio do mês passado o novo quadrante de hypervisors x86.
Em relação ao quadrante anterior se destaca o distanciamento entre o VMWare e Hyper-V em relação aos outros produtos
No caso da suíte Microsoft o Gartner destaca a integração do System Center com o Hyper-V e Azure para nuvens híbridas, alem de reconhecer que o System Center tem funcionalidades superiores em relação a gerenciamento do ambiente de TI como um todo.
Deduplicação do Windows Server 2012 R2 com Hyper-V
Ontem em um cliente usei o meu servidor para as Demos de System Center e ele se interessou quando disse que utilizava o recurso Deduplication (ou Dedup) do Windows Server 2012 R2. Consequentemente, a reunião migrou do System Center para otimização de discos com o Hyper-V.
Afinal de contas, o ganho com Dedup em VHDs é impressionante, chegando no meu caso a quase 80% de espaço adicional:
Importante: Primeiro ponto nessa conversa é deixar claro que a Microsoft não suporta Dedup para Hyper-V em hosts de Hyper-V para VMs em produção. O motivo é explicado no TechNet http://technet.microsoft.com/en-us/library/hh831700.aspx, e basicamente é porque Dedup em ambiente onde os arquivos estão abertos pode gerar diversos erros:
“Deduplication of open files has not been fully validated for general virtualization or other applications, and additional issues may be encountered.”
Porem, surgem sempre duas perguntas neste caso:
Pergunta 1: Mas o Dedup do Windows 2012 R2 pelo PowerShell tem o modo “Files” e o modo “Hyper-V”, como não é suportado?
Resposta: Para Hyper-V só é suportado para ambiente VDI, onde as maquinas são de usuário com SO cliente. Como em geral ambientes de VDI utilizam o modo de pool e uma única VM é duplicada a cada nova seção, se 100 usuário estão online teríamos 100 VHDs sendo criados dinamicamente com dados duplicados.
Neste caso fica evidente que o uso do Dedup será suportado, uma vez que os VHDs são dinamicos e não estão o tempo todo em uso. Alem disso em geral são utilizados discos diferenciais, mantendo o disco parent imutável.
Pergunta 2: Se não é suportado, porque eu estou usando? ;-)
Resposta: Não é suportado, mas no meu caso não é ambiente de produção e utilizo Dedup manual:
Não mantenho meu servidor 24 horas por dia ligado, então quando todas as VMs estão paradas, normalmente faço isso semanalmente, inicio o Job do Dedup com o comando:
Start-DedupJob -Type Optimization -Volume X:
Depois basta monitorar se o Job já terminou com Get-DedupJob:
Assim, meus arquivos VHD não correm o risco de serem manipulados enquanto estão em uso e garanto que periodicamente está sendo atualizado o Dedup.
Porem, é sempre bom lembrar que para não ter problemas o ideal é ter um disco ou volume separado para os VHDs, pois na configuração do Dedup este volume estará configurado como VDI (ou Hyper-V no PowerShell):
