Resolvendo Problemas de Backup com o DPM

Recebo muitas perguntas sobre o funcionando do DPM após ter publicado os videos do produto (http://bit.ly/rh35b6). Muitas questões estão relacionadas ao uso de fitas e robôs, por isso editei os post sobre uso de fitas no mes passado (http://bit.ly/nZY96w) e agora vou abordar outros erros muito comuns e como solucioná-los. Erro com Volume Shadow Services (VSS) O processo do DPM não é realizado diretamente nos dados e sim a partir dos dados de snapshot utilizando o VSS, que é conhecido pelo Shadow Copy. Sendo assim, a maioria dos problemas com backups são relacionados ao VSS que não consegue gerar os dados necessários para o DPM. A primeira e mais facil forma de resolver é criar manualmente um ponto de restauração full, o que cria o snapshot novamente no servidor origem do backup, e em geral resolve o problema quando o VSS está com a base corrompida. A segunda forma de resolver o problema é executar um CHKDSK no disco de origem do backup, pois o VSS grava os dados em um espaço não alocado no disco e o checkdisk faz a verificação de problemas em áreas não alocadas (free space). A terceira forma de resolver o problema é ir nas propriedades do Shadow Copy do disco (abrir o Explorer como administrador e clicar com o botão direito) e verificar se as propriedades estão corretas. Verifique se o Shadow está ocorrendo nos discos pelo tamanho alocado e entre nas propriedades e verifique se há espaço disponivel. Note que o Shadow Copy não precisa estar Enabled, pois trata-se de outra feature. A quarta forma de resolver o problema é utilizando a ferramenta VSADMIN e utilizar os comandos de lista dos recursos. Se alguma das listas ocorrer erro o ideal é deletar todos os shadows com os parametros VSSADMIN DELETE. Com esta ação será reinicializado o VSS em todos os discos no próximo backup. Porem é importante que na primeira tentativa ocorra erro, pois os shadow serão reinicializados. Se isso ocorrer espere alguns minutos e tente novamente. A quinta e ultima forma de resolver os problemas é verificar pelos hotfix e updates disponiveis para o servidor origem dos dados e também do próprio DPM que está no QFE 2 (http://www.microsoft.com/download/en/details.aspx?id=20953). Problemas Especificos com Proteção do Hyper-V Uma das grandes vantagens do DPM é fazer backup de maquinas virtuais (VMs) diretamente do serviço de Hyper-V, o que é muito mais rápido ao copiar e restaurar por incluir o VHD inteiro no backup. Porem, neste caso é necessário tomar várias precauções. A primeira delas tem a ver com DAS (Direct Attach SCSI), seja em um sotrage ou em discos locais se o DPM estiver no host do Hyper-V, o que eu nunca recomendaria por sinal. Neste caso, o DPM irá ocupar toda a banda do storage para realizar o backup e o Hyper-V irá derrubar o serviço por entender que o VHD ficou indisponivel. Se você possuir cluster o serviço de cluster irá cair por indicar acesso simultâneo no mesmo disco. Portanto, não utilize o DPM conectado fisicamente na mesma controladora que está o Hyper-V. Outro problema é o Hyper-V entender que houve acesso simultaneo ao mesmo dado (VHD) e neste caso aplique o KB 2545685 (http://support.microsoft.com/default.aspx?scid=kb;en-US;2545685) que costuma resolver o problema. Se o seu ambiente Hyper-V for baseado em cluster também pode ser necessário caso o KB acima não resolva executar as tarefas descritas no documento http://technet.microsoft.com/en-us/library/ff634192.aspx que serve para influenciar a forma como os snapshots são gerados quando seu hardware não dá suporte a esta operação. Por fim, siga os passos do documento http://technet.microsoft.com/en-us/library/ff634205.aspx desabilitando o protocolo chimney ou ativando a auto montagem dos volumes para o VSS. Conclusão Sistemas de backup são fáceis de serem implementados, mas exigem alto conhecimento do ambiente para serem gerenciados, já que a dependencia de recursos locais como o VSS e CSV no caso do Hyper-V em cluster não são tão simples de serem controlados. Porem, com as dicas acima consegui resolver os problemas que tive em diversos clientes com sucesso!!!

O que é e como calcular IOPS (Exchange, SQL, SharePoint, etc)?

Esta pergunta é frequente, principalmente porque como consultor de soluções da Dell que é um fabricante de hardware temos que saber. O que são IOPS? É o número de operações por segundo que um disco individual consegue chegar. Por exemplo, um disco SAS de 10K consegue em média 140 IOPS. Esta velocidade é padrão na industria com variações entre modelos, mas podemos ter uma base do que é aceitável e o fabricante do disco poderá lhe informar este número. Porem, note que a diferença é muito grande, principalmente levando em conta os novos discos SSD. Por exemplo, o disco X25-E da Intel (Veja o pdf com as caracteristicas em http://download.intel.com/design/flash/nand/extreme/extreme-sata-ssd-datasheet.pdf) chega a números 30 vezes maiores que os discos SAS e SATA. Porque o IOPS é tão importante? Esta pergunta é óbvia, mas a explicação pode não ser tão simples. Acontece que na maioria dos casos temos a tendencia de minimizar a questão dizendo que é “performance” ou “percepção do usuário” mas na verdade pode impactar diretamente no funcionando de um aplicativo, em alguns casos até inviabilizando. Por exemplo, um ambiente Exchange 2003 com 2 mil caixas de correio precisa de 1,5 mil IOPS e este número não é fácil de alcançar. O SQL Server para um banco de dados do SharePoint precisa de 5 mil IOPS para funcionar. Como calcular o IOPS? Multiplique o total de discos pelo tipo de RAID e conseguirá o seu número. Segue alguns exemplos: O RAID 1, RAID 10 ou RAID 0 irá lhe proporcional o maior numero de IOPS possivel, já o RAID 5 o calculo leva em conta 1 disco a menos e no RAID 50 2 discos a menos para as paridades. Como conseguir o maior IOPS possivel com maior capacidade? Temos tres formas de fazer isso: Utilize discos de alta performance, como os SAS de 15K ou o SSD, porem são caros e no caso do SSD de tamanhos de apenas 32/50/64/100GB Utilize o tipo de RAID apropriado para a performance e não visando o tamanho desejado como muitos hoje fazem, o que muitas vezes implica em utilizar RAID 10 para ter a performance total ao invés de RAID 50, perderiamos em capacidade mas ganhamos em performance Compre um storage que trabalha com as LUNs virtuais, ou seja, ele aloca os dados nos discos conforme a necessidade deste dado e não necessita dizer o tipo de RAID O que são as LUNs virtuais? Não vamos entrar no ponto técnico já que este é bem mais complexo, porem podemos entender o que é esta nova tecnologia sem nos tornarmos especialistas em storage. Usando os storages da Dell como exemplo, o MD3200i trabalha com LUNs da forma normal que conhecemos. Você indica que os discos X a Y formam o RAID 0, de Z a W o RAID 5 e assim por diante. Ou seja, mapeamos diretamente os discos e ficamos dependentes da capacidade de IO individual de cada um. Já na série EqualLogic podemos definir o tamanho da LUN sem indicar os discos e o próprio storage irá alocar automaticamente os dados mais acessados nos discos mais rápidos (!!!!!!!!!!). Você deve estar achando que é brincadeira ou algo do tipo “conceito”, mas não é!! Os novos storages vendidos pela Dell, EMC, IBM e outros são inteligentes e permitem misturar os discos. Por exemplo, posso colocar discos SSD na gaveta do storage e mais uma gaveta adicional com 24 discos de 15K SAS e não me preocupar se a LUN que criei está nos discos mais performáticos, quem fará este trabalho é o storage. E, o mais interessante, quando o storage “perceber” que determinado dado (LUN) é mais acessado que outro ele irá realocar para os discos mais rápidos e fazer o shift dos dados sem intervenção e queda de performance, já que trabalha em background e automático !!!! Referencias interessantes Como calcular IOPS para Exchange 2003 http://technet.microsoft.com/en-us/library/bb125019(EXCHG.65).aspx Como calcular IOPS para Exchange 2010 http://technet.microsoft.com/en-us/library/ee832791.aspx Como calcular IOPS para o SQL do SharePoint 2010 http://technet.microsoft.com/en-us/library/cc298801.aspx Utilitário para medir IOPS para o SQL Server (SQLIO) http://www.microsoft.com/download/en/details.aspx?displaylang=br&id=20163 Referencia do EqualLogic S6000 http://www.equallogic.com/products/default.aspx?id=9511

Virtualizar Domain Controllers–Devo ou não?

Esta pergunta já ouvi inúmeras vezes. Em treinamento, palestras, emails e clientes sempre ouço a pergunta “Porque eu não posso virtualizar o Domain Controller?” Esta semana em um grande cliente que atendo como consultor da Dell, alguns sites não permitiam logon, o Office Communicator não funcionava e outros problemas. Portanto, acho que este tema é bem apropriado com o crescimento dos ambientes virtualizados. UPDATE: O Windows Server 2012 introduziu recursos próprios para virtualizar Domain Controllers sem as restrições com o NTP, porem a questão de logar no servidor Hyper-V pode continuar ativa. Vamos começar com o fato concreto: Ninguem disse que não podem ser virtualizados, e sim que existem fatores a considerar. E é sobre isso que irei escrever. Posso virtualizar todos os meus Domain Controllers? Pode, mas terá sérios problemas de segurança e comprometer a réplica se o seu Domain Controller for Windows 2003. Existem alguns pontos a se considerar ao pensar em virtualizar todos os servidores que podem ser consultados em http://support.microsoft.com/kb/888794/en-us quando vc ainda utilizar DCs com Windows 2000 ou Windows 2003. Não é a toa que se recomenda ter os FSMOs em servidor fisico, mas falaremos disso daqui a pouco. Porque virtualizar todos os Domain Controller compromete a segurança? Neste caso temos duas opções, a primeira deixar o Hyper-V utilizando segurança SAM (local) ou ingressar ele no dominio da VM e as duas podem lhe trazer problemas. A primeira opção é um sistema de segurança antigo, não baseado em Kerberos e fácil de se quebrar. A segunda é o risco de ao ter uma queda das VMs ou um desligamento para manutenção ou energia o servidor do Hyper-V não aceitar logon e mostrar a mensagem “No Domain Controllers for Authentication”. Porque não é recomendado virtualizar FSMOs? Porque os FSMOs desempenham papeis importantes na estrutura, normalmente é o Global Catalog e tambem o NTP Server. Caso seja virtualizado as FSMOs o servidor poderá ficar com problemas de sincronização de horários, replicação atrasada, etc. Se ele estiver em uma VM e esta for desligada por um certo tempo o risco de estar com problemas de USN é maior ainda. E o pior momento é se o host Hyper-V perder o relógio e atrasar o horário, gerando inconsistencias sérias no AD. Esta discussão é antiga, desde o inicio do Hyper-V e pode ser acompanhada em http://blogs.technet.com/b/robse/archive/2008/06/16/dc-virtualized-and-external-ntp-servers.aspx Qual o problema com o NTP Server? O NTP Server tem a função de ser o sincronizador de horário nos dominios. A principio é feito pelo PDC Emulator. Maquina fisicas mantem relógio por consultar o RTC (Real Time Clock) na BIOS que é baseado em cristal e após isso o SO passa a usar algoritmos logicos para manter o relógio. O problema em VMs é que este algoritmo pode ficar comprometido por conta da carga, já que ele não é fisico e sofre interferencia conforme o weight definido para as operações, ou seja, irá atrasar ou adiantar. Para evitar isso o Hyper-V faz a sincronização usando as Integrations Features, e ai ocorrem as desincronizações e os usuários não conseguem logar, aplicaçoes dão erro, etc. Ai temos um problema, no documento “Running Domain Controllers in Hyper-V” (http://www.microsoft.com/download/en/details.aspx?id=20164) diz para desligar esta feature dos DCs virtuais. Por outro lado o blog do PM de virtualização (http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/19/time-synchronization-in-hyper-v.aspx) diz para não fazer isso. O problema é muito bem abordado pelo Ben Armstrong e é real. Uma maquina fisica mantem o relógio quando desligada (RTC), mas a virtual não, portanto se todos os DCs forem virtuais e esta opção estiver desabilitada em um desligamento eles irão retornar com o horário em que foram desligados, e quem irá atualizá-los? Minha Recomendação Final Siga as práticas do documento “Running Domain Controllers in Hyper-V”, mas sempre tenha um servidor fisico QUE NÃO SEJA O HOST DO HYPER-V. Configure todas as máquinas, incluindo os hosts do Hyper-V para sincronizar com esta fisica usando Net Time /SetSNTP:<servidor> e assim não terá problema com o relógio, já que o próprio host irá sincronizar com o fisico e consequentemente as VMs com ele.   É isso ai, espero ter ajudado e qualquer acrescimo podem me enviar pelos comentários ou email.

Best Practices para Exchange 2010 no Hyper-V

Este documento disponibilizado no domingo pela Microsoft é útil não só em casos de Exchange mas como em qualquer outro projeto de virtualização com Hyper-V. O documento foca nas melhores práticas de implementação do Exchange 2010 no Hyper-V mas adicionalmente explica as tecnologias envolvidas e o porque da recomendação. Por exemplo, explica cada tipo de disco que o Hyper-V suporta (DAS, iSCSI, eSATA, etc) e considera qual o melhor a ser utilizado e recomendações como termos mais de uma placa de rede no caso de iSCSI, performance de discos virtuais fixos versus dinamicos, etc. Mas como o documento é focado em Exchange, achei algumas recomendações muito interessantes, principalmente o resumo que ele apresenta com os itens: Snapshots, differencing/delta disks Virtual processor/physical processor core ratios greater than 2:1 Applications running on the root virtual machine (excluding antivirus, backup, management software, and so on). Do meio do documento para frente ele passa a descrever um cenário de exemplo e mostrar os cáculos envolvidos pela carga do cliente e como seria o sizing, incluindo DAG e recomendações sobre como usar da melhor forma. Resumindo, leitura imperdível!!!!!! Faça o download em http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8647c69d-6c2c-40ca-977e-18c2379b07ad

Atualizado 26/10/2010: Hyper-V com Windows 2008 R2 Service Pack 1 Beta

Atualizado: Liberado o Release Candidate em 26/10/2010: http://www.microsoft.com/windowsserver2008/en/us/sp1.aspx Hoje consegui instalar o Service Pack Beta 1 do Windows Server 2008 R2 e achei bem interessante as mudanças no Hyper-V (Dynamic Memory), como já estava anunciado (http://technet.microsoft.com/en-us/evalcenter/ff183870.aspx). Como pode ser visto na imagem acima, você pode escolher memória estática (fixa) ou dinâmica. O interessante são as possibilidades de indicar quanto a memória irá ser incrementada baseada na prioridade da máquina em relação a outras máquinas virtuais (VM) no mesmo servidor. No slider Memory Priority você indicará como as máquinas ao ser inicializada poderão alocar memória do Hyper-V. NOTA: É importante frisar que para a memória ser dinâmica EM EXECUÇÃO é necessário que as VMs com Windows 2008 R2 e Windows 7 estejam também com o SP1 Beta. Em outras VMs as maquinas alocarão memória conforme forem sendo iniciadas.

Sequenciando as VMs no Hyper-V

No nosso ambiente instalamos um servidor Dell e as cinco VMs antes distribuidas em 3 maquinas físicas foram consolidadas. Porem, nossos Domain Controllers são duas VMs e notamos o problema da falta de um DC no momento do startup das outras VMs, principalmente a do Exchange, quando o servidor é atualizado pelo WUA, por exemplo ou em caso de pane na host. Como resolver isso? Solução 1 A maquina fisica ser o Domain Controller e hospedar os FSMOs. A desvantagem deste método é que a recomendação padrão é que a maquina do Hyper-V seja dedicada a esta função, e que nem driver de video ela tenha (Problemas com o driver Intel Graphics Media Integrated HD e o Hyper-V). Tanto esta solução quanto a abaixo não eram viáveis porque o cliente mantem uma segunda maquina em outro local fisico com as VMs copiadas para apenas atualizar o BD do SQL em caso de pane do servidor ou do prédio, e sincronizar AD neste caso seria inviável. Solução 2 Colocar um servidor fisico hospedando o AD. Não é víável para este cliente porque sua intenção foi comprar um servidor bi-processado, fontes redundantes e storage dedicado, alem de um poderoso no-break para 1h30m de operação. Colocar mais um servidor seria contra o projeto apresentado, até porque no ambiente também existe um servidor System Center Data Protection Manager (DPM) que não pode ser DC. Com isso, precisamos limitar o ambiente a 3 maquinas físicas (servidor Hyper-V, DPM e TMG). Solução 3 Sequenciar as VMs, fazendo com que a DC que hospeda o FSMO fosse a primeira. Esta se tornou a opção ideal, não incluiria mais uma maquina a ser gerenciada e permitiria fazer o restore de emergencia rapidamente no caso de pane do servidor. Porem, note que este processo é invertido. Não se diz qual máquina irá ligar na frente, mas sim coloca-se um delay nas maquinas que dependem. Isso pode ser feito nas configurações de cada VM que dependa de outra maquina e alterar as configurações “Automatic Start Action”, como mostrado abaixo: NOTA: Esta solução é adequada para casos de reinicio do servidor onde as VMs foram salvas e irão reiniciar automaticamente e não se aplicam ao startup manual, obviamente.

Uma breve estória de virtualização, mesmo em ambiente que parece não apropriado

Atendo a um cliente que utiliza máquinas desktop como servidores e vimos a necessidade de resolver o problema do ponto de falha que estas máquinas antigas representavam. Como não havia máquinas iguais e o hardware já estava ficando obsoleto fizemos uma proposta. O ambiente atual do cliente eram máquinas Core 2 Duo sem suporte a VT, algumas com 4 GB e outras com 2 GB. Haviam 6 servidores: Exchange 2007, DC e serviços de rede, Dynamics CRM com SQL, Servidor de arquivos e TS, DPM e ISA Server. Nossa proposta foi manter os servidores DPM e ISA Server já que esses são fáceis de serem refeitos e não eram os LOBs da empresa podendo ser facilmente substituídos. Os outros quatro servidores seriam consolidados em 2 máquinas Core i3 com 8 GB de RAM com discos de 500 GB. Isso reduziria a quase zero um problema físico no hardware fazer um serviço da rede parar por horas, o que com certeza aconteceria com os hardwares antigos que já estavam travando e lentos. Com a virtualização, mesmo que não haja uma máquina igual a atual, qualquer uma poderá ser utilizada bastando instalar o Windows 2008 R2 com o Hyper-V, mesmo que na proporção de 1-para-1. Fizemos todo o trabalho em uma noite e os resultados foram muito bons, as máquinas novas, apesar de também serem desktops, deram conta do recado e cada uma segura 2 VMs com o Hyper-V 2.0 do Windows 2008 R2. Não tínhamos a necessidade nem hardware suficiente para roda o VMM então optamos pelo Disk2VHD da SysInternals (Ferramenta para converter HD físico (em uso) para VHD) O interessante de uso do Disk2VHD é que os servidores não precisam ser parados, assim como também pode ser feito pelo Hyper-V com o VMM. O utilitário gera os VHDs exatamente do mesmo modo que os discos físicos estão, incluindo partições, espelhamentos e outros recursos, permitindo fazer a imagem já no servidor destino utilizando pasta compartilhada. O processo de criação do VHD é rápido, um disco de 320GB foi convertido em 45 minutos. O passo seguinte foi criar a VM no Hyper-V apontando para o VHD criado pelo Disk2VHD, para melhor performance utilizamos discos fisicos diferentes para cada uma das VMs hospedadas.. Após subir a VM, automaticamente o Windows 2008 reconheceu que foi virtualizado e atualizou os drivers pedindo para ser reiniciado após alguns minutos. Se o servidor fosse um Windows 2003 precisaríamos fazer a instalação dos additions e reiniciar, mas não foi o caso já que todos eram Windows 2008. O ultimo passo foi reativar o Windows já que após os drivers atualizados é necessária ativação, mas sem a necessidade de chaves adicionais ou fazer por telefone.

Problemas com o driver Intel Graphics Media Integrated HD e o Hyper-V

Esta semana tivemos um problema inusitado. Recebemos novos servidores com Intel Core i3, chipset Intel H55. Seguimos o procedimento padrão, instalamos Windows 2008 R2, Inf Update, driver de video e tudo estava indo bem. A resolução de video alcançava 1920 x 1280 como esperado. Nossos problemas começaram quando habilitávamos o Hyper-V e reiniciavamos a maquina. A tela aparecia toda embaralhada e depois de alguns minutos tela azul. Fizemos todas as tentativas possiveis e nada resolveu, baixamos a versão de 5 dias atrás do driver e nada. Ao pesquisar descobrimos que não é recomendado instalar aceleradores de video em maquinas com a função Hyper-V (http://support.microsoft.com/kb/961661) e também que esse mesmo problema de travar quando o acelerador de video e o Hyper-V estão na mesma maquina com outras placas de video, como ATI Radeon e NVidia. A recomendação e resolução do problema é essa, transcrição literal: "Esse comportamento não ocorrerá quando você usa os vgapnp.sys ou VGA.sys genéricos drivers de vídeo que acompanham o Windows Server 2008. Para reverter para o driver de vídeo genérico, você poderá desinstalar qualquer driver de vídeo específicos do fornecedor de alto desempenho." Segue uma thread de suporte com um funcionário da Microsoft indicando que o melhor é realmente esquecer o acelerador: http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2virtualization/thread/155df520-016f-4866-8bb4-1fd526cd6542