Upload afetado no Hyper-V do 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.

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):

Utilizando o MBCA para Analisar Serviços e Servidores

A Microsoft disponibiliza diversas ferramentas de análise da implementação de um produto. Alguns são nativos e outros opcionais: Produto Disponibilidade Download e Instalação Microsoft Baseline Configuration Analyser (MBCA) Extensivel, forma a base para análise de diversos produtos como SQL Server 2012, System Center 2012, Dynamics e outros MBCA - http://www.microsoft.com/en-us/download/details.aspx?id=16475 SQL 2012 - http://www.microsoft.com/en-us/download/details.aspx?id=29302 Dynamics AX 2012 - http://www.microsoft.com/en-us/download/details.aspx?id=28749 SC 2012 - http://www.microsoft.com/en-us/download/details.aspx?id=36796 Prereq RSAT W8 - http://www.microsoft.com/en-us/download/details.aspx?id=28972 Microsoft Baseline Security Analyser Ferramenta que analise a segurança do Windows, até o Windows 2008 R2. Foi descontinuada após o Windows Server 2012 http://www.microsoft.com/en-us/download/details.aspx?id=7558 Best Practices Analyser São ferramentas nativas do Windows 2008 R2 e Windows 2012 Podem ser instalados pelo Server Manager http://technet.microsoft.com/en-us/library/dd759260.aspx Failover Cluster Validation Nativo da feature Failover Cluster Executado pelo MMC do Failover Cluster Vários artigos abordam o uso do BPA e do validador do Cluster são nativos e o MBSA foi descontinuado para o Windows Server 2012, então neste artigo trataremos apenas do MBCA e seu uso exemplo com o System Center 2012. Instalação do MBCA e Pacotes A instalação deste produto é muito simples, bastando executar o instalador. Após instalar o MBCA passamos a instalar as ferramentas, ou pacotes de análise, permitindo que ao abrir o MBCA vejamos uma lista dos pacotes de análise disponiveis: Executando o System Center 2012 Configuration Analyzer Note que ao abrir o menu não terá uma opção para o SCCA, uma vez que ele é um plugin do MBCA, como pode ser visto abaixo: O passo seguinte é selecionar os computadores que serão validados. Porem, para validar alguns servidores remotos pode ser necessário fazer o registro de segurança com Setspn. Se você não sabe como utilizar, pode usar as instruções do próprio SCCA, como mostrado nos tópicos a frente: Os resultados são mostrados em duas abas, sendo possivel ver um resumo ou detalhamento dos dados analisados. No exemplo abaixo executei em um SCSM 2012 SP1 e o resultado inicial é que não há pendencias e permitindo exportar o relatório que pode ser revisado posteriormente depois de salvo com a opção “Open Report” no primeiro pront. Utilizando a opção Collected Data é possivel ver os dados utilizados pelo SCCA para validar o SCSM: Servidores Remotos Instalar o MBCA e o SCCA em um único servidor é útil para evitar a instalação em uma farm de servidores ou mesmo para maquinas com acesso limitado. Porem, em alguns casos nao é possivel executar o SCCA remotamente tendo como resultado a mensagem abaixo: A função Credssp permite que o servidor onde o SCCA está instalado tenha acesso ao servidor que está sendo analisado, sendo simples de ser executado e necessário para análises remotas.   Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/

Windows Server 2012: NIC Team (Time de Placas)

O NIC Team é um recurso já existente hoje para servidores com placas Broadcom por meio do software BACS (http://bit.ly/N8B8Ql) e Intel pelo software PROSET (http://intel.ly/N6JqId, selecione o modelo da placa) mas com algumas restrições, por exemplo, as placas tem que ser do mesmo fabricante e de preferência do mesmo modelo. A grande vantagem do NIC Team é a possibilidade de agrupar placas de rede para trabalharem como uma única interface de rede, como mostrado abaixo no BACS. Note que duas placas de rede de 1 GB foram agrupadas para criar uma única interface (“Rede”) que no Windows será detectado como uma interface de 2 GB: Alem disso, uma prática comum é criar o time e colocar os cabos de rede em switches alternados, assim quando um switch não estiver funcionando ou fornecendo conexão a comunicação do servidor não terá perda de pacotes. Ou seja, estaríamos criando uma redundância para conexão a rede no servidor.   A Novidade O que foi acrescentado no Windows 2012 é o recurso de time de placas diretamente pelo sistema operacional, o que permitirá trabalhar com placas de múltiplos fabricantes, modelos e velocidades como uma única interface lógica para o Windows. Uma importante observação é que não é necessário usar Hyper-V ou outro software para utilizar e tirar proveito de times de placas, por exemplo, um banco de dados ou um servidor de arquivos tiraria grande proveito deste recurso.   Configurando NIC Team Para configurar um time de placas de rede, vá ao Server Manager e ao clicar no servidor terá a opção Configure NIC Team como mostrado na imagem abaixo: Na sequencia podemos ver as placas de rede, times já existentes e nas tarefas a opção de criar novos times: A criação de um time é simples, bastando indicar as placas e o modo de comunicação. Porem, é importante conhecer configurações do switch desejado, pois ele deve ser configurado para LACP (agregação) ou Trunking para “entender” que duas placas do servidor estarão em portas diferentes com o mesmo endereço MAC e endereçamento IP. Caso esteja utilizando um switch que não tem gerenciamento para criação da agregação (LACP) ou o trunking, escolha o modo “Switch Independent” onde não é necessário fazer configurações especificas no switch core de sua rede. Neste caso o Windows irá direcionar o fluxo a uma das placas e automaticamente fará a troca de placas quando a principal estiver indisponível. Para isso escolha o modo apropriado na tela abaixo após configurar os switches: Um documento detalhado de planejamento e configuração está disponível pela Microsoft em http://www.microsoft.com/en-us/download/details.aspx?id=30160 e o ajudará muito a entender melhor e utilizar este recurso apropriadamente.   Utilizando o NIC Team no Hyper-V Para utilizar o NIC Team no Hyper-V basta escolher a placa “Microsoft Network Adapter Multiplexor Driver”: Referencias: Windows 2012 – NIC Team http://technet.microsoft.com/en-us/library/hh831648     Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/

Windows Server 2012: Novidades do Failover Cluster Services (MSCS)

Novidades do Microsoft Cluster Services (MSCS) Muitas funcionalidades são de gerenciamento e configuração, mas algumas se destacam: Live Migration com multiplicas placas de rede – Hoje designamos uma placa para dar suporte ao Live Migration e somos limitados a uma VM por vez. O Windows 2012 utilizará todas as placas que estejam disponiveis para o processo, o que permitirá maior desempenho e multiplas operações. O processo será alterado de uma placa dedicada como é hoje para utilizar a banda livre em toda as placas. Priorização e Afinidade de VMs – Estes eram dois tópicos delicados quando vendíamos soluções MSCS, pois não temos como indicar a sequencia com que as VMs deverão iniciar e, muito menos, a dependência entre elas. Isso causava problemas com aplicações como SharePoint, System Center ou IIS que dependiam do SQL Server estar iniciado para funcionarem. Como não podíamos indicar esta ordem os servidores IIS subiam antes do SQL, causando queda ou instabilidade nos serviços. Novos limites de 64 nós e até 8000 VMs – Hoje o limite é 16 nós de cluster com até 1000 VMs ou 384 por host. Com o novo limite de 64 nós, aumentou correspondentemente para 8000 VMs. Um aumento de 4 e 8 vezes respectivamente no número de host e VMs suportadas. Transferência de File Server transparente – Este é um dos itens muito importantes que para muitos passava despercebido em projetos e que na administração do dia-a-dia se davam conta. Quando se move um share de um File Server virtual de um nó para outro o SMB (protocolo de comunicação) derrubava a sessão e o usuário recebia uma mensagem de erro de I/O. No SMB 3.0 no Windows 2012 será possivel fazer a migração sem a perda da sessão, resolvendo este problema. Adicionalmente isso também acontecerá se o File Server foi movido para um site remoto, porém neste caso entra o Hyper-V Replica que já é outro recurso novo no Hyper-V e não do MSCS. Configurando o Failover Clustering no Windows 2012 Como qualquer nova funcionalidade desejada no Windows 2012, iniciamos por instalar e habilitar as features desejadas pelo Server Manager. Para isso utilizamos o menu Manage à Add Roles and Features e selecionamos a Failover Clustering, que automaticamente irá incluir as ferramentas de gerenciamento e outros itens que sejam necessários para o funcionamento, sendo possível escolher ou não a instalação, por exemplo, se for remoto não precisaremos do console local: O passo seguinte é definir o nome e o IP que o cluster utilizará, uma vez que o acesso dos clientes não será pelo nome e IP dos servidores e sim pelo nome e IP configurado posteriormente. Neste exemplo foi escolhido o nome MSCS-Lab e o IP 192.168.0.230 que manualmente foram acrescentados ao DNS: Já na console do Cluster utilizamos a opção Create Cluster... para iniciar o assistente do cluster. Note que no menu lateral acima da opção de criação temos a opção Validate Configuration que funciona como um BPA (Best Practices Analyzer) e é recomendado que se execute primeiro. Voltando ao assistente, o primeiro passo é selecionar quais servidores estarão no grupo: O passo seguinte é indicar o nome e o IP criados para esta finalidade: Ao finalizar temos uma importante opção antes de simplesmente clicar no Next que é indicar se discos de storage serão automaticamente acrescentados no cluster. Isso é interessante para evitar que após a configuração do cluster seja necessário incluir os discos, mas deve ser usado com cuidado caso existam LUNs no storage dedicada a discos de acesso direto (Pass-Throught): Na sequencia são definidos os serviços que estarão contemplados pela alta disponibilidade, como maquinas virtuais, DHCP, DNS, etc. Cada serviço tem um assistente próprio e configurações próprias, portanto não teríamos como abordar cada um neste momento. Alguns dos recursos disponíveis pode ser visto a imagem logo abaixo (tópico Hyper-V Replica Broker). Hyper-V Replica Broker Um dos novos recursos do Hyper-V 3.0 é a réplica de VMs que permite criarmos ambientes de alta disponibilidade com Datacenters remotos. Porem, este mesmo recurso pode ser configurado pelo Failover Cluster, habilitando o recurso de alta disponibilidade em Datacenter remoto automaticamente, diferente do Hyper-V que apenas faz a réplica exigindo a inicialização da VM remota em caso da parada do Datacenter principal. Este recurso é criado por meio do assistente de papeis (New Role...) como a imagem abaixo: Após acrescentar o serviço, será habilitado um novo nome e IP virtual específico para este cluster trabalhar as réplicas: Após adicionar este serviço, acesse as máquinas virtuais e com o botão direito será possível ver a opção Replication à Enable Replication e seguir o assistente mostrado no artigo de Hyper-V, indicando o nome do servidor habilitado para réplica, seja ele um cluster ou standalone. Para maiores detalhes sobre Hyper-V Replica Broker consulte o link abaixo onde poderá entender porque é necessário para os casos de cluster criar um novo nome e IP virtual: http://blogs.technet.com/b/virtualization/archive/2012/03/27/why-is-the-quot-hyper-v-replica-broker-quot-required.aspx Trabalhando com VMs no Failover Cluster Para que uma maquina virtual esteja sendo protegida e controlada pelo Cluster ela precisa ser criada nele e não pelo Hyper-V Manager (é possível mover pelo System Center Virtual Machine Manager ou VMM) e para isso utilize o menu lateral Create Role como no caso mostrado no tópico anterior para acrescentar o Replica Broker ou a opção Virtual Machines à New Virtual Machine. Na sequencia irá ter acesso a criação de uma VM normalmente como acontece com o Hyper-V, e após a criação está irá aparecer na lista de Roles do Cluster. Alguns recursos interessantes já existentes no Windows 2008 R2 continuam a funcionar, como Live Migration e Quick Migration, onde o Live migra as maquinas em funcionamento e o Quick ao fazer um Save State. Algumas mudanças ocorrem nesta nova versão, pois é possível agora fazer a migração entre máquinas que não estejam em um cluster, mas não é o tópico em questão. Storage File Share Um recurso interessante é poder agora armazenar maquinas virtuais em um cluster utilizando um File Share, ou seja, utilizar um terceiro servidor como Storage ao invés de um storage físico. Para utilizar este recurso acesse uma das VMs e utilize a opção Virtual Machine Storage: Na sequencia define o File Share onde deseja que a VM fique hospedada: Este recurso é excelente por permitir que utilizemos clusters de alta disponibilidade sem ter um storage físico dedicado. Prioridades Outro interessante recurso do Failover Cluster do Windows 2012 é indicar a prioridade de cada VM, assim garantindo que um servidor de banco de dados inicialize antes de um servidor com SharePoint ou IIS estejam solicitando a este os dados para funcionamento. Este é um recurso importante para impedir os problemas comuns que temos quando utilizamos várias VMs, uma para cada função, sendo elas dependentes entre si. Para configurar este recurso utilize as propriedades da maquina virtual: No exemplo citado, o servidor de banco de dados estaria com prioridade Alta, o servidor com IIS ou SharePoint com prioridade média ou mesmo baixa dependendo do tempo total de inicialização do banco de dados. Importante: Não existe um relacionamento entre as VMs, portanto todas que estiverem selecionadas como High serão iniciadas, depois as Medium e por ultimo as Low. Referencias: Windows 2012 – Failover Clustering http://technet.microsoft.com/en-us/library/hh831579   Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/

Ferramenta de Sizing Gratuita e Online da Dell

Um de meus colegas de trabalho ontem enviou um email comentando sobre esta ferramenta online da Dell para sizing de Virtualização (Hyper-V, VMWare e Xen), SQL Server, Exchange, Oracle e HPC em http://content.dell.com/us/en/enterprise/large-enterprise-solutions.aspx É claro que estas ferramentas não são o unico recurso que deve ser utilizado em um sizing, mas dão uma idéia muito boa de tecnologias e as diferentes configurações possiveis. Paticularmente gostei da ferramenta de virtualização onde após escolher o numero de servidores que estarão no ambiente, suas funções, o tipo de storage e a previsão de uso dos hosts ele dá não só uma lista de dados mas também diagramas do ambiente recomendado. Divirta-se com essas ferramentas e entenda como as soluçoes que envolvem ambientes precisam ser muito bem planejadas com as dicas que o “Consultor Virtual” da Dell pode lhe dar.

Adição de nós em Cluster-Problema com “Owner” da unidade CSV

SINTOMA Ao acrescentar um novo nó em um cluster já existente enfrentei um problema no HA (High Avaliability) quando ao mover o storage ocorreu o erro “This node is not a possible owner for this resource”. CAUSA Em geral este erro não acontece, pois ao se acrescentar um novo nó ao cluster este já adiciona o novo host como “Possible Owner”, porem neste caso em especial o problema foi a configuração do iSCSI que estava incorreta e o novo host não conseguia acessar uma das unidades do CSV, ocasionando “Redirect Access”. Após resolver o problema dos endereçamentos do iSCSI os discos ficaram visiveis, porem ele não era migrado para o novo host e acusa o erro indicando que o novo host não era um dos possiveis owners. No caso de uma VM ou o Quorum basta clicar com o botão direito para acessar a lista de Possible Owners, mas isso não existe em unidades de storage. Solução Utilizando o PowerShell Modules execute o cmdlet abaixo e veja que uma das unidades do storage não tem o novo servidor na lista de nós: Get-ClusterSharedVolume | Get-ClusterOwnerNode ClusterObject                                            OwnerNodes -------------                                               ---------- Unidade_G                                               {ServerA} Unidade_H                                              {ServerA, ServerB} Na sequencia utilize o comlet abaixo para definir os Owners da unidade que está incorreta: Set-ClusterOwnerNode –Owners ServerA,ServerB -Resource "Unidade_G" Por fim, execute o comando inicial novamente e veja que agora os Owners estão corretos: Get-ClusterSharedVolume | Get-ClusterOwnerNode ClusterObject                                            OwnerNodes -------------                                               ---------- Unidade_G                                               {ServerA, ServerB} Unidade_H                                               {ServerA, ServerB} Nota Antes de conseguir resolver o problema tentava utilizar o cmdlet Get-ClusterResource  | Get-ClusterOwnerNode porém unidades CSV não listados, com excessão do Quorum.

Dynamic e Power Optimization do VMM 2012-Hyper-V + XenServer + VMWare

No post anterior sobre VMM 2012 abordei a capacidade de utilizar as 3 tecnologias de migração das VMs entre os host XenServer, VMWare e Hyper-V. Todos podem estar no mesmo grupo e utilizando o PRO Tips. Detalhes em http://bit.ly/pf0v9M Mas agora vamos falar de duas novas features e como funcionam: Dynamic Optimization – Gerencia a agressividade com que as VMs são movidas entre os nós no modo “quente” Power Optimization – Desliga e religa nós do cluster conforme a utilização dos recursos Dynamic Optimization Esta feature irá gerenciar com qual nível de agressividade iremos fazer o balanceamento de carga nos hosts. É compativel com XenServer e VMWare desde que o BMC esteja instalado nos hosts. Note porem que o processo de migração das VMs ocorrerá entre os hosts do mesmo SO. Note na tela abaixo que é possivel definir manualmente a frequencia em que este processo será executado. Tempos muito altos ocasionaram moves excessivos de VMs entre os hosts, tempos longos podem gerar lentidão em um host até que as VMs sejam movidas. O ideal é de 10 a 30 minutos para detecção e solução. Abaixo vemos a configuração considerada ideal para que o VMM detecte a necessidade de move de VMs. No exemplo temos 30% de CPU, 512 MB de memória livre e não levamos em conta IOPS e Network pois esses dois itens comulmente são compartilhados entre os nós de um cluster e não são otimizados com moves entre os nós. NOTA: Lembrando mais uma vez que esta configuração é feita nos grupos que podem contem Hyper-V, Xen Server e VMWare e que os moves irão acontecer entre estes servidores com o mesmo SO e não entre os diferentes SOs. Alem disso é necessário no caso do VMWare e do Xen Server que estejam em cluster. Power Optimization Este novo recurso é muito interessante, levando em conta que muitos cluster tem o dobro da necessidade média levando em conta os picos. O Dynamic Optimization ajuda no momento em que o pico ocorre a distribuir as VMs, mas e quando há sobra de recursos? O Power Optimization irá desligar os nós que não sejam necessários quando a utilização dos hosts reduzindo nós terá umca determinada capacidade e no horário escolhido. No exemplo abaixo iremos desligar o host desde que a utilização dos outros nós com os moves de VM não fiquem acima de 40% e 1GB de RAM, e desde que esteja em horário noturno ou final de semana. O processo de desligamento é um shutdown  sendo que o religamento é realizado por pacotes WOL (Wake On Lan) que precisa estar habilitado na BIOS do host. Alem disso nos hosts ESX e Xen Server é necessário ter o BMC, assim como no Dynamic Optimization. Alem disso, existe uma proporção para esse recurso: Cluster de 4 ou 5 nós – 1 nó será desligado Cluster de 6 ou 8 nós – 2 nós serão desligados Cluster de 9 ou 10 nós – 3 nós serão desligados Acima de 10 nós – 1 nó adicional pode ser desligado a cada 2 NOTA: O recurso Power Optimization só funcionar entre nós do cluster e não host-to-host. Referencia: http://technet.microsoft.com/en-us/library/gg675109.aspx

Live Migration + vMotion + XenMotion–System Center Virtual Machine Manager 2012

É isso mesmo, o VMM 2012 irá contar com as três tecnologias de migração “a quente”. O VMM 2008 R2 já conta com o vMotion, mas ele gerencia de forma isolada do Live Migration do Hyper-V. Já o recurso do Xen, o XenMotion, não era suportado. Aliás, o Xen não era suportado no VMM 2008 R2. O que a Microsoft fez agora é compatibilizar as três tecnologias de migração. Porem não apenas isso, mas permite juntar no mesmo grupo de servidores (managed pool) Hyper-V, ESX e XenServer !!!!! Agora podemos colocar em um grupo, por exemplo, 3 servidores Hyper-V + 2 servidores VMWare ESX + 2 servidores XenMotion e o VMM 2012 irá conseguir migrar as VMs entre as 3 plataformas. Sensacional !!!!! Porem, note que entre os host Xen será usado o XenMotion, entre ESX o vMotion e entre o Hyper-V o Livre Migration. Entre eles o processo é de V2V, ou seja, com um restart. A grande mudança é usar o PRO Tips entre hosts mesmo que não Hyper-V e utilizar a tecnologia de move entre os hosts. Figura 1: Servidores ESX junto com servidores Hyper-V Figura 2: Nova arquitetura integrada Se quiser conhecer mais sobre isso poderá baixar os ppts da palestra que fizemos no TechEd 2011 em http://bit.ly/nTwJcZ Também acesse os portais do TechNet: Integração do VMM 2012 com XenServer: Managing Citrix XenServer Overview Integração do VMM 2012 com VMWare ESX: Managing VMware ESX Hosts Overview Alem disso, recente post do VP do Gartner comenta as novidades do VMM 2012 e do Hyper-V 3.0 colocando a Microsoft como a nova lider em recursos: http://blogs.gartner.com/chris-wolf/2011/09/20/hyper-v-3-a-windows-server-2003-remix