MVP: System Center Cloud and Datacenter Management, MCT, MCSE, MCITP, MCPD, MCDBA
MVP Logo

Pageviews 2017: 3178727
Pageviews 2016: 3991973
Pageviews 2015: 2675433
Pageviews 2014: 2664208
Pageviews 2013: 2399409
Pageviews 2012: 3209633
Pageviews 2011: 2730038
Pageviews 2010: 1470924
Pageviews 2009: 64608

Últimos posts

Categorias

Arquivo

Tags

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:

clip_image001

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:

clip_image002

Na sequencia podemos ver as placas de rede, times já existentes e nas tarefas a opção de criar novos times:

clip_image003

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:

image

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

image

Referencias:

Windows 2012 – NIC Team
http://technet.microsoft.com/en-us/library/hh831648

 

 

image

Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/

Posted: jan 20 2013, 11:42 by msincic | Comentários (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: Hardware | Windows 2012

Atualizando System Center 2012 RTM/SP1 RC para SP1 RTM-Parte 2 (SCVMM, SCDPM, SCSM e AppController)

Com o lançamento da versão final do Service Pack 1 do System Center 2012 foi necessário fazer upgrade das versões dos produtos sem o Service Pack ou com o Service Pack 1 na versão Release Candidate (RC). Não irei abordar o Beta pois ele já estava defasado em relação aos testes em geral.

No meu caso, fiz as atualizações a partir das duas versões de todos os produtos e este será um resumo em duas partes, sendo o primeiro com o System Center Configuration Manager 2012, System Center Operations Manager 2012 e Orchestrator (http://www.marcelosincic.com.br/blog/post/Atualizando-System-Center-2012-RTMSP1-RC-para-SP1-RTM-Parte-1-(SCCM-e-SCOM-Orchestrator).aspx).

Este segundo post abordarei o System Center Virtual Machine Manager, System Center Data Protection Manager, System Center Service Manager e System Center AppController.

  A partir do RTM A partir do SP1 RC Agentes
Data Protection Manager Upgrade sem intervenções Upgrade sem intervenções Exige upgrade, desabilita os jobs até que seja atualizado
Virtual Machine Manager Não permite upgrade, mas permite selecionar o mesmo database Não permite upgrade, mas permite selecionar o mesmo database Atualiza os agentes automaticamente
Service Manager Permite o upgrade, desde que esteja com o Cumulative Update 2 instalado Não permite upgrade, mas permite selecionar o mesmo database

--

AppController Não permite upgrade, mas permite selecionar o mesmo database Não permite upgrade, mas permite selecionar o mesmo database Recomendado que o VMM 2012 seja atualizado para o SP1

 

Data Protection Manager (DPM)

Dos 4 produtos que migrei nesta onda o DPM é o unico que permite a migração de forma automática. Basta colocar o instalador e o upgrade ocorrerá sem problemas:

07-01-2013 18-19-38

Porem, é importante que após a migração do servidor seja realizado o upgrade dos agentes, o que pode exigir que o servidor seja reiniciado:

07-01-2013 18-20-55

Importante: O Windows Server 2012 possui um hotfix para evitar que o CSV fique offline durante operações de backup disponivel em http://support.microsoft.com/kb/2799728

 

Virtual Machine Manager (VMM)

A migração do VMM não é permitida, exigindo que seja desinstalada a versão anterior:

07-01-2013 21-05-49

Porem, a solução de manter o mesmo banco de dados (Retain Database) resolve o problema permitindo que a estrutura anteriormente seja  configurada seja aproveitada. Para isso escolha a opção apropriada quando for detectado pelo instalador que já existe um database no SQL Server:

07-01-2013 21-07-42

Na tela posterior será possivel confirmar o banco de dados e permitir o upgrade:

07-01-2013 21-11-51

Por fim, indique que deseja utilizar o mesmo Library existente:

07-01-2013 21-12-13

Assim o ambiente fica operacional e no console será mostrado um warning nos hosts indicando que existe uma nova versão de agente, porem não impossibilita o gerenciamento.

 

Service Manager (SCSM)

O Service Manager pode ser atualizado desde que esteja o Cumulative Update 2 na versão RTM. Se for a versão SP1 Beta/RC o upgrade não é possivel.

Ao iniciar o instalador será possivel escolher a opção de upgrade que ocorre sem muitos problemas, como acontece com o DPM no tópico acima.

Quando temos um servidor com o SP1 beta ou RC a mensagem será de erro como abaixo:

07-01-2013 21-42-03

 

AppController

O AppController não permite upgrade, mas permite a reutilização da base de dados na reinstalação do produto.

O processo é desinstalar a versão existente e reinstalar a nova. Note que não é possivel mudar o banco, as informações aparecem desabilitadas pois o instalador detecta que já havia a configuração anteriormente:

07-01-2013 23-00-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:

image

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.

image

Voltando ao assistente, o primeiro passo é selecionar quais servidores estarão no grupo:

image

O passo seguinte é indicar o nome e o IP criados para esta finalidade:

image

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

image

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:

image

Após acrescentar o serviço, será habilitado um novo nome e IP virtual específico para este cluster trabalhar as réplicas:

image

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:

image

Na sequencia define o File Share onde deseja que a VM fique hospedada:

image

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:

image

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

 

image Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/

Posted: jan 17 2013, 09:40 by msincic | Comentários (1) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: Windows 2012

Escolhendo o Tipo de RAID e Solução de Storage

Na palestra que realizei no MCT Summit (http://www.mctsumm.it/Pages/default.aspx) abordei o assunto sobre a escolha do melhor meio de armazenamento e os tipos de RAID disponiveis, com as vantagens e desvantagens de cada um.

Recebo muitos emails para o ppt, porem alguns conteudos não posso publicar em blog pessoal, porem está disponivel no site da Dell um documento completo sobre a escolha do melhor RAID para Equallogic, que foi a base que usei para este tópico.

Segue o link para o documento “Choosing a Member RAID Policy”, não é necessário se cadastrar

http://www.dellstorage.com/WorkArea/DownloadAsset.aspx?id=1066

Posted: jan 16 2013, 12:43 by msincic | Comentários (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: Hardware

Atualizando System Center 2012 RTM/SP1 RC para SP1 RTM-Parte 1 (SCCM e SCOM, Orchestrator)

Com o lançamento da versão final do Service Pack 1 do System Center 2012 foi necessário fazer upgrade das versões dos produtos sem o Service Pack ou com o Service Pack 1 na versão Release Candidate (RC). Não irei abordar o Beta pois ele já estava defasado em relação aos testes em geral.

No meu caso, fiz as atualizações a partir das duas versões de todos os produtos e este será um resumo em duas partes, sendo este primeiro com o System Center Configuration Manager 2012, System Center Operations Manager 2012 e Orchestrator.

Segue uma tabela básica com o resultado e depois passo ao detalhamento:

  A partir do RTM A partir do SP1 RC Agentes
Configuration Manager Upgrade após desinstalar o WAIK e instalar o Windows ADK Upgrade sem intervenções Não exige o upgrade, mas relaciona os agentes no relatório das versões
Operations Manager Upgrade sem intervenções Upgrade sem intervenções Não exige o upgrade, apenas apresenta a versão correspondente em “Agent Managed”
Orchestrator Não permite upgrade, mas permite selecionar o mesmo database. Não permite upgrade, mas permite selecionar o mesmo database. Integration Packs com as novas funcionalidades do SP1 precisam ser instalados

 

System Center Configuration Manager (SCCM)

Tanto a migração do RTM como do SP1 RC foram transparentes e simples, porem é importante lembrar que o SCCM 2012 ainda utilizava o Windows AIK. O SCCM 2012 SP1 já foi atualizado para utilizar o Windows ADK que era beta na ocasião do lançamento do SCCM 2012. Porem, o processo é simplesmente desinstalar o WAIK e instalar o Windows ADK.

Em ambientes com hierarquia “Parent-Child” (onde são independentes mas fazem troca de dados) pode-se iniciar a atualização em qualquer um dos sites com o risco de ser recusado o upload de dados no Parent em versões diferentes. Por outro lado, em hierarquias “Primary-Secundary” (apenas o primário tem banco de dados) o upgrade deve ser feito de cima para baixo, ou seja, primeiro atualizamos o primário para o banco de dados ser atualizado e depois os secundários, que não irão funcionar corretamente até serem atualizados. Lembrando que neste caso a atualização pode ser feita pelo próprio console do SCCM.

Importante: Um erro no timestamp do certificado usado no agente do SCCM 2012 SP1 gera um erro “Couldn't verify 'C:\WINDOWS\ccmsetup\MicrosoftPolicyPlatformSetup.msi' authenticode signature. Return code 0x800b0101”. Baixe o hotfix em http://support.microsoft.com/kb/2801987

Ao abrir o setup já é possivel ver a opção de Upgrade disponivel, sem qualquer intervenção, como mostram os dois prints a seguir.

07-01-2013 12-06-15

07-01-2013 12-36-18

Os sites e configurações continuam ativas sem problemas, incluindo os agentes:

07-01-2013 14-45-31

 

System Center Operations Manager (SCOM)

Foi a migração mais simples de todas, não foi necessário qualquer atualização de componentes, nem a partir do RTM.

Em ambientes com instalação em multiplos servidores, a ordem básica se mantem como a do upgrade de versões anteriores. Iniciamos a migração pelo servidor que contem o Operational Database antes dos Management Servers e Gateway Servers.

O wizard de instalação detectou com facilidade os componentes instalados e listou o que estava sendo atualizado:

07-01-2013 15-29-13

Ao realizar a atualização foram alteradas as estruturas do banco de dados, motivo pelo qual o wizard recomenda o backup das bases antes do processo de upgrade.

07-01-2013 16-19-38

Ao final, o console abriu com todos os agentes saudáveis e o SCOM atualizado. Lembrando que o agente mostra a versão anterior mas não exige o upgrade:

07-01-2013 16-37-05

 

System Center Orchestrator (SCO)

Na ordem em que eu inicie as migrações, o Orchestrator foi o primeiro a não permitir o upgrade direto das versões anteriores. Tanto a partir do RTM quanto do SP1 RC a mensagem abaixo foi o resultado:

07-01-2013 22-41-24

Neste caso o processo consiste em desinstalar o Orchestrator e reinstalar o produto, porem utilizando a opção “Retain database” na seleção do banco de dados a ser utilizado.

07-01-2013 22-46-43

Após isso, todos os Runbooks estavam disponiveis e funcionaram corretamente, assim como os Integration Packs que continuaram disponiveis no Runbook Designer.

Porem, é importante que para tirar proveito das novas funcionalidades do SP1 é necessário baixar os Integration Packs novos (http://www.marcelosincic.com.br/blog/post/Novos-Integration-Packs-para-Orchestrator-2012-SP1-e-Toolkit.aspx) e fazer o deploy a partir do Orchestrator Deployment Manager, que passa a mostrar a versão 7 (RTM) e as versões 7.1 (SP1):

07-01-2013 23-13-20

É importante que após a instalação dos novos Integration Packs os Runbooks continuaram funcionando normalmente, como o exemplo abaixo:

image

Posted: jan 15 2013, 11:16 by msincic | Comentários (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Login