ADM de Redes

Um Blog sobre o dia a dia do Administrator de Redes e Servidores Microsoft

By

MVP Virtual Conference

image

Olá Pessoal,

Começa amanhã o MVP Virtual Conference. Serão uma série de webcasts sobre diversos assuntos. Recomendo fortemente que você acesse o site do evento para saber mais informações e se cadastrar. O site do evento é: http://mvpvirtualconference.azurewebsites.net/.

Na quinta-feira, eu farei uma sessão sobre Nuvem Hibrida com System Center 2012 SP1. Não perca a oportunicade de conhecer essas tecnologias e engajar com profissionais de primeira linha.

Até mais!

By

Geo Cluster ou Hyper-V Replica?

Olá Pessoal,

Recentemente, me deparei com uma situação onde era necessário escolher a melhor opção de Disponibilidade e Recuperação de Desastre em um projeto. O parceiro que estava no projeto com o cliente levantou as necessidades e minha parte foi basicamente explicar as diferentes soluções que poderiam atender este caso. Gostaria de compartilhar com vocês as soluções e quais os benefícios de cada uma das opções.

Desde o Windows Server 2008, a Microsoft facilitou muito a configuração de um Cluster Geográfico. A opção de se ter um File Share Witness é um dos exemplos disso. Antes de mais nada, vamos entender o que é um Geo Cluster:

Um Cluster Geográfico é um cluster onde os nós deste cluster estão em sites diferentes da empresa. Imagine que você tem um Cluster chamado Cluster 01 e este cluster tem 2 nós. Um dos nós poderia estar em uma localidade e o outro nó estaria em outra. Não vou entrar em detalhes de links, mas é importante que os nós estejam sempre se comunicando. Por ser o mesmo cluster, os recursos que são criados no Cluster, como VMs, poderão iniciar em qualquer um dos nós. É aí que vem a primeira vantagem de um cluster geográfico. Caso um dos nós pare de funcionar, a VM que estava neste local, poderá iniciar em uma outa localidade. E o mais importante, este processo de HA será operado pelo cluster automaticamente. Este processo automatico é o que muitos entendem como grande benefício. Porém, alguns pontos devem ser observados e muitas vezes, estes pontos impossibilitam um projeto como este. Vamos lá:

Para que um cluster funcione, um armazenamento compartilhado é necessário. No caso de um Geo Cluster, isso também é verdade, mas em cada localidade os Hosts irão ter seu storages, logo, estamos falando de 2 Storages. Além disso, os storages devem estar atualizados em relaão um ao outro. O Windows Server não irá fazer este processo. Isso é um serviço que deve ser adquirido com o fabricante do storage (ou uma consultoria que faz este trabalho). Além disso, o File Share Witness é um ponto importante no processo. Isso por que é ele quem irá garantir que apenas seja feito HA caso o Nó de um dos sites realmente esteja off-line. Para que o caso de uma queda de links não impacte o processo de HA, o File Share Witness deve estar em uma terceira localidade. Então além dos 2 sites onde os nós do cluster estão, o File Share Witness devem estar em uma terceira localidade, terceiro site.

Enfim, a não ser que o processo automatico de HA seja extremamente importante, um Geo Cluster é algo que nem todas as empresas poderão contar. Mas o Windows Server 2012 trouxe uma novidade que muitas empresas poderão adotar que é extremamente mais acessível. Trata-se do Hyper-V Replica.

O Hyper-V Replica é um recurso do Hyper-V 3 que está disponível nas 2 versões do Windows Server 2012 (Standard e Datacenter) e também no Hyper-V Server 2012, ou seja, é um recurso gratuíto.

O Hyper-V Replica, consiste em ter um host de virtualização em uma localidade e outro Host em uma segunda localidade.O Replica é aplicado por VM, logo, para as VMs que você quer replicar, você irá configurar a replicação tendo uma máquina virtual de origem ligada e funcionando, e outra máquina virtual de destino desligada. No caso de uma falha, você deverá manualmente fazer o failover desta VM para que a VM de destino seja ligada. Neste caso, você poderá escolher entre os Pontos de Recuperação disponíveis, caso você tanha habilitado esta configuração, ou então, a última replicação conhecida, lembrando que a replicação do Hyper-V Replica é assincrona. Os pontos fortes do Hyper-V Replica é que este não precisa de replicação de storage. De fato, você poderia utilizar até mesmo os discos locais dos servidores Hosts para hospedar as VMs. Nenhum tipo de storage compartilhado é necessário neste caso.

Veja que com o Hyper-V Replica também é possível automatizar o processo. Para isso você poderá utilizar vários “gatilhos”, como um script Powershell, System Center Orchestrator, Operations Manager, Service Manager ou qualquer outra solução que consiga iniciar o processo. A questão aqui é a mesma que o que foi dito acima sobre o File Share Witness. Este componente que automatiza o processo precisa estar isolado dos sites onde estão os hosts.

Resumindo: Se você precisa de um processo de Recuperação Automatizado e o serviço ou aplicação que você quer proteger não puder ficar parado por muito tempo (tempo para um processo de failover manual) o ideal é ter um cluster Geográfico. Mas lembre-se que você precisará de recursos extras para isso. Agora, se a aplicação pode ter um tempo de inatividade aceitável, o Hyper-V Replica é uma excelente solução pois é simples de se configurar, não tem nenhum custo nem necessita de serviço de terceiro.

Espero que tenham gostado da expliação!
Até mais!

By

Virtualização de Domain Controllers – Parte 04

Olá Pessoal,

Mais uma parte de nossa série de posts sobre Domain Controllers Virtualizados, hoje abordando um cenário que pode causar muitos problemas. Trata-se da dependencia do Serviço de Cluster no Windows Server sobre o Active Directory.

A essa altura do campeonato, você já deve ter percebido que ter os Domain Controllers virtualizados não é impossível nem algo de outro mundo. Requer alguns cuidados a mais, sim, mas é plausível. Porém, há uma configuração de DC virtualizado que pode ser um problema. Este problema é quando você virtualiza todos os Domain Controllers em cima, não de um Host de Virtualização, mas de um Cluster.

Até o Windows Server 2008 R2, o serviço de cluster só irá iniciar se o contato com um Domain Controller for estabelecido. Se você colocar todos os seus Domain Controllers virtualizados em um Cluster, você terá problemas se por algum motivo como falta de energia, os hosts do seu cluster desligarem. Para resolver essa situação, temos duas alternativas:

A primeira é colocar o nó do cluster como Domain Controller, apenar de ser fortemente desencorajado, essa situação é relativamente comum, mesmo para quem não tem o DC virtualizado e não teria o problema acima, mas quer garantir que o acesso ao AD esteja sempre disponível. Essa solução não é mais suportada no Windows Server 2012, e já explicarei por que…

A segunda alternativa é criar 2 clusters e colocar DCs virtualizados em ambos. Esse cenário é interessante quando você pensa que os dois clusters não irão parar de funcionar ao mesmo tempo. Sendo assim, se um cluster cair, haverá um DC virtualizado no outro cluster que estará disponível para o cluster que está iniciando. Mesmo assim, se os dois cluesters pararem ao mesmo tempo, você terá problemas.

Já no Windows Server 2012, uma das diversas novidades sobre cluster é justamente essa dependencia do Active Directory para que o serviço inicie. No WS2012 o serviço do Cluster poderá iniciar com uma conta de serviço local, o que fará com que o serviço inicie e as funções do cluster possam iniciar. No caso de qualquer VM, como um DC virtualizado, isso permitirá que a VM inicie e o AD esteja disponível. Vale ressaltar que o fato do serviço do cluster iniciar, não garante que todas as funções iniciem. Por exemplo: O serviço do Excahnge precisa do AD de qualquer forma.

Essa novidade do WS2012 para serviço de Cluster resolve o cenário onde todos os Domain Controllers estão virtualizados e em cluster. Neste cenário, se você tiver um cluster com DCs virtualizados e este cluster for desligado, no momento que se iniciar o cluster, o serviço irá subir, permitindo que as VMs que rodam neste cluster iniciem, pois a inicialização de VMs não é um serviço que depende do AD. Com as VMs ligadas e consequentemente, o AD de volta no ar, todos os serviços do cluester ficam dispoíveis. Para verificar as demais novidades sobre cluster no WS2012, acesse o link: http://technet.microsoft.com/en-us/library/hh831414.aspx. Sobre as novidades de cluster com AD, vá até http://technet.microsoft.com/en-us/library/hh831414.aspx#BKMK_AD.

Espero que esta dica tenha ajudado!
Até mais!

By

Virtualização de Domain Controllers – Parte 03

Olá Pessoal,

Mais um post da série que pretende dismistificar a virtualização de Domain Controllers. Nesse post vamos falar sobre a utilização de Snapshots em VMs que são Domain Controllers.

No último post comentei um pouco sobre a replicação entre Domain Controllers. A replicação é uma das atividades mais importantes do Active Directory, pois garante que todos os Domain Controllers tenham a mesma informação na base de dados.

Se você tem mais um Domain Controller (E você deveria ter!) a replicação deve ser monitorada para que não haja nenhum problrema dentro do seu ambiente. A replicação é feita por diversos componentes que garantem que todos os itens necessários estarão atualizados em todos os Domain Controllers. Sendo muito simplista, existem dois componentes que são importantes na resplicação e que precisam ser entendidos para que possamos continuar.

O primeiro é a informação de que um item é autoritativo naquele servidor. Imagine que um usuário trocou sua senha. Esse processo é feito na máquina do usuário que envia a informação de troca de senha do usuário para o Domain Controller mais próximo onde este usuário se autenticou. O DC com esta informação mais recente, marca esse item como autoritativo para que ele possa enviar esta informação aos outros DCs. Logo, tudas as novas informações são autoritativas no DC ao qual a modificação foi feita, seja troca de senha, criação de usuário, deleção de usuário e todo mais que altera-se na base do AD. Uma vez que este Domain Controller passou isso aos demais, a informação se torna autoritativa em todos.

Para que isso não vire uma bagunça, existem diversos outros componentes que garantem que a última informação sempre seja a que vale. E para que todos os DCs possam se entender, há um outro componente chamado USN ou Update Sequence Number (Número de Sequencia de Atualização). O USN garante que todos os Domain Controllers estão com a informação mais atual possível.

Logo, a utilização de todos estes componentes garantem que todos os DCs estejam atualizados. Porém, se você está com um Domain Controller virtualizado, há uma variável aqui que pode atrapalhar este processo. Trata-se do Snapshot.

Quando você tira o snapshot de uma VM, basicamente, você cria uma imagem desta VM em um momento no tempo. Para testes, desenvolvimento e qualquer coisa fora de produção, não há muito problema com isso. Especificamente para o AD o Snapshot pode ser um grande problema. Na verdade para qualquer tipo de banco de dados onde você precisa replicar as informações, isso será um problema.

Vamos supor que você tem 4 Domain Controllers e resolve tirar um snapshot deles em uma terça-feira as 12:00. Na quarta-feira as 12:00 você percebe que um dos DCs apresenta uma falha. Para resolver o problema rapidamente, você resolve aplicar o snapshot que tinha do DC. Isso, porém, fará com que o DC que teve o snapshot aplicado ache que a informação de USN, digamos 90, é a mais atual pois isso é autoritativo para ele. Os outros DCs estão, digamos, com o USN em 120, ou seja, outras alterações ocorreram entre teça-feira as 12:00 e quarta-feira as 12:00.

Neste momento, este DC irá interromper a replicação pois estes DCs estão divergindo na informação mais atual. Para resolver este problema, você deverá recuperar o backup do AD não-autoritativo e aguardar a replicação dos outros DCs para este DC recuperado.

Até o Windows Server 2008 R2, essa era a forma de operação. Ou seja, se ainda não está rodando o Windows Server 2012, tome muito cuidado com snapshot de DCs.

Já se você está utilizando o Windows Server 2012 como Host de seu ambiente de Virtualização e o DC também é Windows Server 2012, esse problema não ocorre. Isso por que no AD do WS2012 uma informação é verificada após a aplicação de um Snapshot, o Virtualization ID. Este item basicamente comprova que um snapshot foi aplicado nesta VM. Com essa informação, o AD é capaz de marcar o USN como não-autoritativo na VM que é um Domain Controller. Sabendo que não é autoritativo, este Domain Controller inicia o processo de replicação dos outros DCs normalmente.

 

image

Resumo: Se você utiliza Windows Server 2008 R2, seja como Host ou VM, não utilize Snapshot de VM. Se você utiliza WS2012 como Host e DC em máquina virtual, enjtão isso não será um problema.

Até mais!

By

Virtualização de Domain Controllers – Parte 02

Olá Pessoal,

Continuando nossa série de posts sobre virtualização de Domain Controllers, hoje quero falar sobre um assunto muito importante que se dá pouca importancia:  Sincronismo de Horário.

Muita gente acaba administrando o Active Directory sem se dar conta de alguns itens importantes sobre o mesmo. O AD é um serviço de diretório que pode ter uma arquitetura simples, para atender pequenos ambientes e com pouca configuração está pronto para funcionar, ou pode ter uma arquitetura bem complexa para atender organizações maiores. Porém, em ambos os casos, o funcionamento é o mesmo.

Desde o Active Directory na versão do Windows 2000 Server, o AD é multimaster, o que significa que todos os Domain Controllers podem escrever na base do AD. Isso é muito bom pois torna o AD muito simples para se implementar Alta disponibilidade. Porém, a reaplicação se torna algo extremamente importante. Mas o que vem ao caso aqui, é que mesmo sendo multimaster, algumas operações são executadas apenas por alguns servidores específicos. São os FSMO ou Flexible single master operation. São 5 FSMO, e para Virtualização uma delas é muito importante, o PDC Emulator.

Uma das funções do PDC Emulator é ser o ponto principal de Horário para os outros Domain Controllers, que por sua vez, fornecem o horário correto para as estações.

O problema é que no Hyper-V, quando você cria uma VM, a configuração padrão é que haja uma sincronia de horário entre VM e Host. Para um Domain Controller, isso é um problema, pois ele deveria estar seguindo a hierarquia do Active Directory.

A resolução deste problema é muito simples. Para VMs que são Domain Controllers, é preciso desmarcar a opção de sincronismo de horário nas opções de Integration Services.

image

Até mais!

By

Experiência em Nuvem versus Experimentos em Nuvem?

image

Olá Pessoal,

Queria deixar a dica de uma nova campanha da Microsoft para vocês. Para conhecer a campanha, acesse o site: http://www.microsoft.com/en-us/server-cloud/versus.aspx

Aproveite também para ler o post no Blog do time de produtos: http://blogs.technet.com/b/server-cloud/archive/2013/03/13/vmware-zigs-then-zags.aspx

Até mais!

By

Virtualização de Domain Controllers – Desvendando mitos!

Olá Pessoal,

Quando falamos de virtualização, um dos assuntos que causa um pouco de polêmica, é a relação do Active Directory com a plataforma de virtualização. Para jogar um pouco de luz sobre este assunto, pretendo fazer uma série de posts para que possamos dismistificar essas questões. Na verdade, pretendo fazer uma reflexão do que está neste documento oficial, que se você quiser ler antes de ler os posts, fique a vontade.

- Base de dados do AD em local padrão:

A base de dados do AD é composta por diversos componentes como Base de Dados, Arquivos de Log, Log de Transação e etc. Para preservar a integridade desta base, o AD utiliza um método de escrita sem buffer e tenta desabilitar um recurso de cache de escrita de disco nos volumes onde esta base se encontra. O problema com a virtualização é que o disco tem que suportar um recurso no disco virtual chamado de SCSI Emulation.

Existem 2 pontos que devem ser observados aqui:

Primeiro Ponto: Quando você promove o servidor a Domain Controller, no assistente de promoção, um dos passos é escolher o local onde a base e logs do AD serão armazenados. Este assistente sugere que você armazene esta base e log no disco C: que é, provavelmente, o seu disco de sistema, boot e etc. O primeiro motivo que você deve armazenar a base e log fora deste local é performance. Obviamente, existem outros pontos para que você não deixe esta base e log no volume do sistema, mas para nossa explicação aqui, o ponto mais importante é que o disco de boot em VMs do Hyper-V tem que ser um disco IDE. O que nos leva ao segundo ponto:

Segundo Ponto: O Hyper-V possui 2 tispos de barramento de disco. IDE e SCSI. Os discos IDE são discos que podem ser entregues para as VMs mesmo sem o funcionamento do Integration Components. Por isso é utilizado para disco de Boot. Porém, para que o AD do Domain Controller virtualizado consiga passar para o Host o processo de escrita sem cache, o disco tem que suportar isso. E para que o disco suporte, ele tem que ser SCSI. Logo, o disco onde você armazena a base e log do AD no Domain Controller Virtual devem ser SCSI. Veja abaixo, a diferença nas configurações de uma VM:

Discos

Essa foi a primeira dica para virtualizar Domain Controllers sem problemas em seu ambiente. Em breve volto com mais dicas para vocês.

Até mais!

By

Novidades de Group Policy para Windows Server 2012 e Windows 8

Olá Pessoal,

Desde o Windows Vista e Windows Server 2008, quando a Microsoft lança uma nova versão de Sistema Operacional, o lançamento vem em conjunto. Isso acontece por uma série de motivos como, utilização do mesmo kernel, updates e etc. No caso do Windows Server 2012 e Windows 8 não é diferente.

Agora, um ponto super importante é que o Sistema Operacional de Servidor possa gerenciar tanto o SO cliente legado, como o novo Sistema Operacional cliente. Para isso, como se pode esperar, o Windows Server 2012 contém uma série denovas políticas dentro dos objetos de Políticas de Grupo (GPO) para que Windows Server 2012 e Windows 8 possam trabalhar em harmonia.

Pensando que a quantidade de GPOs é muito grande para que alguém simplesmente saia procurando as novidades, a Microsoft sempre libera uma planilha com as novidades de GPO para uma visualização mais fácil.

Se você quiser baixar esta planilha, assim como a planilha de versões anteriores, acesse: http://www.microsoft.com/en-us/download/details.aspx?id=25250.

Até mais!

By

System Center Advisor agora é gratuíto!

Olá Pessoal,

Durante os ITCamps de System Center 2012, eu menciono um dos produtos que é da família System Center mas que poucos conhecem. O System Center Advisor. O Advidor é uma solução também conhecida como MaaS (Management as a Service) onde para gerenciar os serviços/agentes não é necessário uma infraestrutura interna de gerenciamento, pois a solução utiliza o conceito de Nuvem Pública, muito parecido com o Windows Intune, que mais conhecido no mercado.

A ideia principal do Advisor é fazer analise e reports do ambiente de servidores. O produto já existe há algum tempo, mas era licenciado com Software Assurance. Agora, o time de produtos anunciou que para diversos países, com Brasil incluso, o produto é oferecido gratuitamente.

Para saber mais sobre o produto e iniciar a utilização, acesse o post do time de produto aqui.

IC488281

Até mais!