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

Pageviews The process cannot access the file 'D:\home\site\wwwroot\Visitas2.xml' because it is being used by another process. 2019: 2905763
Pageviews 2018: 4296564
Pageviews 2017: 4351543
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

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

Login
Marcelo de Moraes Sincic | Utilizando o Hyper-V Replica Parte II - Boas Práticas para RTO e RPO
MVP: System Center Cloud and Datacenter Management, MCT, MCSE, MCITP, MCPD, MCDBA
MVP Logo

Pageviews 2019: 2905763
Pageviews 2018: 4296564
Pageviews 2017: 4351543
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

Utilizando o Hyper-V Replica Parte II - Boas Práticas para RTO e RPO

No primeiro post sobre Hyper-V Replica abordamos as vantagens sobre réplica de storage e como iniciar a configuração e réplica http://www.marcelosincic.com.br/blog/post/Utilizando-o-Hyper-V-Replica-Parte-1e28093Vantagens-e-Primeira-Replica.aspx

Neste segundo post vamos abordar como o RTO e RPO são importantes e como o Hyper-V Replica se encaixa nestes conceitos.

Recovery Time Objective e Recovery Point Objective

Basicamente os termos RTO e RPO indicam os objetivos que uma solução de desastre deve cumprir:

  • RTO – Tempo máximo para se recolocar o serviço em produção
  • RPO – Tempo máximo de dados que podem ser “perdidos” entre o evento de desastre e o ambiente restaurado

Um bom exemplo de como estes valores se relacionam e o que significam pode ser explicado no gráfico abaixo:

image

No exemplo acima conseguimos “enxergar” claramente o RTO e o RPO:

  • RTO foi de 5 horas e 3 minutos, entre as 05:15 e as 10:18
  • RPO foi de 3 horas e 15 minutos, entre as 02:00 e as 05:15, uma vez que o backup foi realizado as 2 da manhã

Como determinar o RTO e RPO

Estes valores são determinados por um plano que é chamado de DRP (Disaster Recovery Plan) que é orquestrado por consultorias especializadas neste tipo de processo. Geralmente é realizado quando uma organização está atualizando seu datacenter e, consequentemente revendo suas políticas de recuperação dos dados ou montagem do datacenter redundante.

O processo de levantamento destes dados se baseia em entrevistas e dados do ambiente de TI e, entre outras coisas, coleta:

image

Porque o Hyper-V Replica é uma ótima opção

O processo de backup é uma das formas que o RPO e RTO podem ser cumpridos, porem as práticas normais de restore muitas vezes são impeditivas levando em conta o tempo que é perdido entre o ultimo backup e a falha (RPO) e o tempo necessário para se restaurar um servidor a partir de backups (RTO).

Com o Hyper-V Replica o tempo de RTO é minimo, uma vez que as réplicas mantem a maquina virtual (VM) no ambiente de redundância integra.

E o RPO?

Em um ambiente de backup o RPO é facilmente calculado e mantido. Por exemplo, se o RPO da aplicação CRM tem perda máxima calculada em 30 minutos, podemos fazer o backup incremental a cada 15 ou 30 minutos.

No caso do Hyper-V Replica este tempo não é determinado de forma simples, uma vez que o tempo de replicação (Replication Frequency) de cada VM indica o intervalo e não o periodo desejado de proteção. Seria muito bom ter uma opção onde pudesse ser indicado qual o tempo máximo em que uma réplica pode estar desatualizada…

Um segundo item importante é levar em conta o grupo de uma aplicação, por exemplo mais de um servidor que forma a mesma aplicação e precisa estar com a réplica sincronizada por igual. Como o Hyper-V Replica não tem o conceito de grupo de serviço, não temos como garantir a integridade do conjunto da aplicação.

Outra dificuldade no Hyper-V Replica é o baixo número de opções de intervalo da réplica (Windows 2012 a cada 5 minutos, Windows 2012 R2 a cada 30 segundos, 5 minutos ou 15 minutos):

image

Imagine um cluster com 80 VMs, sendo que cada VM tem impacto diferente no negócio ou requisitos técnicos particulares. Destas 80 VMs algumas são servidores web que podem ser replicadas uma vez por dia, outras são servidores de aplicação que só precisam ser replicados quando sofrem algum tipo de atualização e, por fim temos os servidores que precisam ser replicados continuamente.

Como configurar diferentes RPO?

Uma prática que pode ser adotada de forma simples, é colocar as máquinas em grupos de criticidade e configurar utilizando as 3 janelas de réplica do Windows 2012 R2 (30 segundos, 5 minutos e 15 minutos).

O problema é que se a VM que será replicada a cada 30 segundos for, por exemplo um banco de dados e o ambiente de redundância for por WAN, o consumo do link será muito alto e as outras VMs entrarão em intervalo de réplica e com isso todas as réplicas ocorrerão simultaneamente. Com isso, o RPO ficará prejudicado para todas as VMs críticas e muito baixo para as maquinas não criticas.

Uma boa prática neste caso é configurar as VMs com RPO maior que 2 horas para serem replicadas manualmente por meio de PowerShell abaixo:

Resume-VMReplication MaquinaVirtual –Resynchronize –ResynchronizeStartTime “8/1/2012 05:00 AM”

Este comando pode ser executado pelo Task Scheduler ou utilizando o Orchestrator com schedule embutindo o comando.

No exemplo citado anteriormente, as VMs de banco de dados ou informações como File Server ficariam com a configuração do próprio Hyper-V a cada 5 ou 15 minutos. As VMs estáticas poderiam ser configuradas com replicação manual, e com tarefas ou runbook agendados e recorrentes replicar pontualmente conforme o grupo de criticidade.

Conclusão

Este segundo post abordamos como alcançar o RTO e RPO.

O próximo post irei abordar os comandos e a sequencia de comandos PowerShell que podem ser executados como script ou com Runbook no Orchestrator.

Os comentários estão fechados
Login