Upload afetado no Hyper-V do Windows 10

15 julho 2021 msincic Hyper-V, Hardware, Windows 10
Ao habilitar o Hyper-V no Windows 10 poderá ter o problema da performance de upload baixar radicalmente, a ponto de quase zerar! Esse problema aconteceu comigo em 3 diferentes equipamentos (Dell Latitute, Vostro e um T110), cada um com placa diferente. Importante que os 3 são placas wifi 5G. Solução, desabilite o Large Send Offload da placa virtual. O motivo é que este recurso não existe nas placas de rede que utilizei, portanto geram a incompatibilidade. Resultado, vejam abaixo a performance antes de eu habilitar o Hyper-V e compartilhar a placa de rede, depois de habilitado e o mais recente com o LSO desabilitado.

Azure Arc–Gerenciamento integrado Multi-cloud

22 julho 2020 msincic Advisor, Azure, Azure Sentinel, Log Analytics, Microsoft Azure, Hardware, Windows Server 2019, Windows 2012, Virtualizaçao
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.

Integrando Updates de Fabricantes com o System Center Configuration Manager (Endpoint Protection Server)

08 março 2020 msincic Configuration Manager, Hardware, System Center
Uma das necessidades que muitos administradores de TI tem é fazer o update de forma centralizada. Isso se deve a ter um unico ponto de contato, evitar instalar mais softwares de fabricantes, principalmente para drivers de clients e servers com vários fabricantes. Já bem estruturado e desde a versão 2012, o SCCM tem a capacidade que se chama SCUP (System Center Update Service) para isso. Utilizando o SCUP É bem simples de ser usado, vá ao site do fabricante que pode ser de HW ou SW e consiga a URL com o arquivo cab de atualizações. Dentro desse arquivo irá ter as definições em XML dos updates e requisitos. Por exemplo ele contem os updates com a lista de servidores e maquinas compativeis, ou requisitos de software para updates como Adobe e Autodesk. Depois que tiver a URL vá em Software Library –> Software Updates –> Third-Party Software Updates e inclua o catálogo como a imagem abaixo: Dai em diante basta aguardar que ele finalize o processo de sincronização e utilizar o botão Subscribe to Catalog para iniciar os updates: Eles irão aparecer junto com os updates de Windows para serem aprovados, com uma classe a parte para se criar as regras automaticas de Deploy.

Azure File Sync–Otimizando seu File Server e Storage

28 agosto 2019 msincic Azure, Cloud computing, Hardware, Microsoft Azure, Virtualizaçao
Duas aplicações mais consomem storage em ambientes de TI: Banco de dados – Por conterem dados analiticos e indexados podemos utilizar tecnicas de drill down para separar os dados analiticos dos dados resumidos facilitando o acesso e otimizando custos File Server – Ao longo dos anos as empresas acumulam milhares de arquivos, o que custa caro e raramente é agrupado ou tierizado Tierização: Tecnologia onde os dados são separados conforme regras de performance em discos mais caros ou mais baratos. Por exemplo, arquivos pouco usados ficam em discos SATA, arquivos com acesso ocasional em discos SAS e arquivos que são acessados diariamente em discos SSD. Vamos abordar como utilizar o Azure File Sync para criar uma tierização dos dados em um File Server para permitir que arquivos mais acessados fiquem localmente guardados e os mais antigos apenas em nuvem. Cenários Frequentes O primeiro cenário é o de diminuir o tamanho total de espaço ocupado por arquivos antigos. Nesse caso utilizamos as configurações de data do arquivo e espaço livre desejado para diminuir o espaço em disco que o File Server ocupa, liberando para uso com outras necessidades. O segundo cenário é servidor de arquivos distribuidos, onde em cada filial da empresa é necessário ter um servidor para acessar os dados. Nesse exemplo todos os servidores replicam a mesma pasta, o que não cria problemas de saturação local, já que o cache é apenas dos arquivos recentes e controlado pelo percentual desejado de espaço livre a ser mantido. Componentes do Azure File Sync Storage Account – Um storage virtual onde os dados serão armazenados File Share no Storage Account – Pasta dentro do Storage Account para receber os arquivos que serão enviados Azure File Sync Service no Market Place – É o serviço e deve ser habilitado, diferente de outros serviços nativos. Porem, apesar de estar no Market Place o AFS não tem um custo, trata-se apenas da inclusão de um serviço File Sync Service – É o serviço no painel do Azure onde podemos criar os grupos, incluir os servidores e configurar storage Registered Services (servidores) – São os servidores que serão sincronizados, onde os arquivos estão armazenados e servirão de cache Sync Group – Forma a lista de servidores que irá receber a cópia dos arquivos a serem copiados e dar acesso aos arquivos em qualquer localidade Criando um Storage Esse é o primeiro passo e bem conhecido de quem já utiliza o Azure, uma vez que para tudo precisamos de um storage. Para usar o AFS não é necessário qualquer configuração adicional, você poderá escolher qual região, tipo de storage e replicação que melhor se aplique ao seu ambiente. Obviamente algumas coisas precisam ser levadas em conta: O tipo de conta envolve a performance maxima e irá afetar tanto o download quanto upload quando os usuários utilizam os arquivos Replicação é importante se você terá servidores em várias localidades/paises Camada Hot or Cold envolve a performance diretamente e tambem o custo, já que o acesso é bem lento em discos Cold e não recomendaria para uma solução como essa Na sequencia é necessário criar o File Share para onde os arquivos irão quando sincronizados, e o conceito é o mesmo de um servidor comum: Quando sincronizado, os arquivos irão aparecer primeiro na pasta Sincronization e depois na pasta principal como podemos ver abaixo. Lembrando que as duas telas acima se referem a sincronização já finalizada, a primeira para ver os arquivos sendo copiados e a segunda quando a primeira sincronização já finalizou. Habilitando o Azure File Sync Procure no Marketplace pelo Azure File Sync ou Serviço de Sincronização do Azure em portugues: Nesse momento pode-se optar por utilizar um Resource Group existente ou um novo, não importando em qual Resource Group o Storage foi criado, uma vez que ele pode ter varios outros serviços atribuidos. Criando o Serviço de Sincronização A criação do grupo de sincronização é bem simples, bastante indicar a assinatura, storage e a pasta compartilhada definida anteriormente. Registrando Servidores de Arquivos Você poderá indicar servidores: Novos servidores que não tenham arquivos e incluí-los em um grupo já sincronizado para que ele sirva de cache dos arquivos que já estão na pasta compartilhada do Storage no Azure Servidor com dados onde o conteudo será copiado para o Azure e acrescentado O primeiro passo é instalar as bibliotecas PowerShell do Azure (AZ) no servidor, o que pode ser feito seguindo os passos na página https://docs.microsoft.com/pt-br/powershell/azure/install-az-ps?view=azps-2.6.0&wt.mc_id=4029139 Após ter o Azure CLI instalado, baixe e instale o Agente de Sincronização que é muito simples de ser feito. Após isso, já será possivel ver o servidor no painel do Azure: Nesse passo não é necessário configurações nem qualquer definição adicional, já que se trata de uma operação simples de agente. Criando o Endpoint (Servidores Cache) Aqui é onde realmente criamos o serviço e vemos a mágica acontecer! Entrando dentro do grupo de sincronização que criamos anteriormente e usar a opção Adicionar ponto de extremidade ou Add Endpoint para incluir o servidor no grupo que criamos. Vamos ver as opções que estão listadas: Caminho – É o diretório que queremos que fique sincronizado, lembrando que se estiver vazio para um grupo já existente ele irá baixar o conteudo conforme for sendo utilizado. Se for um servidor que já contem arquivos, esses serão carregadso para o Azure. Importante: Não é possivel usar a unidade root (C:) e sim um disca parte por conta dos arquivos de sistema. Percentual livre no volume – Não definimos quanto irá ser usado para cache e sim quanto de espaço no volume deverá ficar livre. Pode parecer um calculo invertido mas não é por conta de outros arquivos que o mesmo disco contenha. Por exemplo, se o volume é de 100GB e contem outros arquivos totalizando 40GB e definirmos que queremos deixar 50% do disco livre, apenas 10GB será usado pelo cache (50% de 100GB=50GB sempre livre) e conforme o uso de outros arquivos aumentar que não sejam sincronizados, menos irá ter espaço para o cache. Dica: Por conta dessa dificuldade, prefira utilizar um volume dedicado para fazer o File Sync Cache apenas de arquivos acessados ou modificados a x dias – Vimos que temos a opção de preservar um percentual do disco. Mas e se arquivos antigos ocupam muito espaço não irá adiantar muito. Nesse caso do meu exemplo qualquer arquivo com mais de 60 dias irá automaticamente para o Azure e será deletado no disco do servidor, ganhando espaço livre mesmo que o percentual de cache ainda esteja disponivel. Ao finalizar essa configuração já é possivel acompanhar a sincronização clicando no servidor: Assim que sincronizado, podemos usar os paineis de metricas abaixo da tela para criar alertas quando ocorrerem erros ou distorções: No meu exemplo posso utilizar uma regra que se o numero de arquivos sincronizados for maior que 100 para upload no intervalo de 15 minutos pode ser uma alteração em massa causada por uma cópia indevida ou mesmo um malware.

Azure Virtual Datacenter (VDC) Parte I- Migração AS IS e TO BE

06 março 2019 msincic Azure, Cloud computing, Hardware, Log Analytics, Microsoft Azure, Virtualizaçao
Quando trabalhamos em um projeto de migração para Public Cloud e o desenho é voltado a Azure, é muito comum os cenários de “AS IS”. AS IS Para os não iniciados com este termo, “AS IS” significa levar como está me ingles, ou seja copiar as VMs de um ambiente a outro sem qualquer alteração, utilizando o Azure como um virtualizador. Em geral os modelos de migração AS IS não são eficientes, pois consomem muito recursos em IaaS (VMs) que custam caro, não aproveitando nada de serviços (SaaS ou PaaS) que são mais baratos. Porem, a vantagem é que é mais rápido e não exige mudanças. TO BE (ou LIft and Shift) Já as boas migrações são as “TO BE”, que em tradução livre seria “SERÁ” no sentido de transformação. O modelo de migração TO BE tem como premissa usar os serviços e não apenas migrar VMs. Migrações TO BE são trabalhosas e mais demoradas, uma vez que esse mapeamento envolve entender o que está DENTRO DAS VMs. O custo de execução é muito menor pois SaaS e PaaS tem vantagens financeiras grandes quando comparados ao modelo de IaaS. Por exemplo, no AS IS um servidor IIS e outro de SQL serão simplesmente copiados os discos virtuais e iniciados. Já no modelo TO BE iremos isolar cada uma das aplicaçÕes que o IIS executa e criar Web Plan para isolamento e Web Services para cada site, e no caso do SQL Server usariamos o serviço de Banco de Dados (SaaS ou PaaS). Utilizando o Service MAP O primeiro passo para fazer uma migração é mapear o que cada VMs ou servidor fisico executa no ambiente. Para isso utilizamos o Service MAP: http://www.marcelosincic.com.br/post/Azure-Log-Insigths-Service-Map.aspx Com ele será possivel ver as interligações e serviços que cada servidor utiliza entre no ambiente e mapear qual serviço temos para substituir. Entendendo o Conceito de Datacenter do Azure Para desenhar um datacenter usando VMWare, Hyper-V ou KVM é necessário que o desenho dos hosts, rede e outros detalhes sejam feitos por especialistas no hypervisor. O mesmo vale para Azure, precisamos entender os diferentes componentes para desenhar um datacenter com seus recursos. Para isso, é necessário estudar, e muito.   Tambem é necessário quebrar os paradigmas de datacenter fisico e pensar em serviços. Uma das formas de fazer isso é utilizar o Guide da própria Microsoft disponivel em https://docs.microsoft.com/en-us/azure/architecture/vdc/ Esse guia tem todas as perspectivas de um datacenter virtual, o ajudará a entender a camada de virtualização, rede, segurança, serviços e o lift and shift, ou seja a transformação para um modelo mais eficiente. Para começar baixe a apresentação disponivel em https://aka.ms/VDC/Deck Conclusão Não é fácil fazer uma migração correta, mas é possivel e o resultado será muito melhor. Ao longo do mês iremos explorar os itens que compõe o VDC e verá que é possivel fazer esse tipo de migração com recursos novos, mais eficientes e custos apropriados.

Vamos Falar do Projeto Microsoft Honolulu?

08 janeiro 2018 msincic Green IT, Hardware, Hyper-V, Outros, Windows, windows 2016, Windows 2012, Windows 10
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

Microsoft Virtual Machine Converter (MVMC)–Retirada do Produto

08 junho 2016 msincic Cloud computing, Hardware, Hyper-V, Microsoft Azure, System Center, Virtual Machine Manager, Virtualizaçao
A Microsoft anunciou esta semana a retirada do MVMC como produto já no final deste ano. https://blogs.technet.microsoft.com/scvmm/2016/06/04/important-update-regarding-microsoft-virtual-machine-converter-mvmc/ Para quem não conhece o MVMC ou não lembra sua função, ele é um plugin para converter maquinas fisicas (P2V) ou virtuais de outras plataformas (V2V) para VMs no Hyper-V.   O que usar no lugar do MVMC? A sugestão apresentada é utilizar o Azure Recovery Site, mas ele na verdade é um serviço e não seria útil quando o desejo é subir VMs em ambiente on-premisse. Porem, no caso do cliente que quer transformar o ambiente fisico (P2V) para nuvem (IaaS) o Azure Recovery Site é a melhor opção. E para quem precisa fazer V2V hospedadas no VMWare para o Hyper-V pode utilizar o próprio VMM (System Center Virtual Machine Manager) que processa a conversão nativamente. Por fim, para os casos de conversão de maquinas fisicas para virtuais (P2V) pode-se usar o Disk2VHD como já comentado em outras ocasiões e é um produto muito conhecido para gerar VHDs a partir de discos fisicos, que abordei em 2009: http://www.marcelosincic.com.br/post/Ferramenta-para-converter-HD-fisico-(em-uso)-para-VHD.aspx Link do Disk2VHD: https://technet.microsoft.com/en-us/sysinternals/ee656415.aspx