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

Pageviews 2017: 3472484
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 Windows Azure Pack como Portal do Service Manager

Uma reclamação constante dos usuários do System Center Service Manager (SCSM) é o seu portal. Na versão disponivel para teste Technical Preview que será lançada neste ano, o portal do SM continua sendo em SharePoint Foundation 2010 e sem permitir customizações na interface. Desta forma, os clientes que utilizam o WAP como acesso externo, tinham que ter uma ferramenta de terceiro para fazer requisições.

Porém, algo que poucos já utilizaram é a integração entre o Windows Azure Pack (WAP) com o Service Manager para fornecer um portal completo de auto-provisionamento com VMs, bancos de dados, sites e requisições de serviço.

 

Configurando o Windows Azure Pack como Portal do Service Manager

O primeiro passo para a integração é fazer o download do componente GridPro que é gratuito até uma assinatura (tenant), sendo necessário adquirir a versão Pro para trabalhar com multiplas assinaturas (multi-tenant).

Entre no portal do WAP e em Request Management baixe o componente GridPro, que será manualmente e simples, solicitando alguns dados do servidor do Service Manager:

2015-01-08_15-30-18

Após a instalação do componente utilizamos a interface do WAP para incluir os dados do servidor que está com o GridPro:

SNAG-0001

SNAG-0003

O passo seguinte é incluir o serviço Request Management como parte da assinatura padrão que é ofertada no portal do Azure Pack:

SNAG-0014

 

Utilizando o Windows Azure Pack como Portal

Agora já podemos abrir o portal do WAP e ver que a aba “Solicitações” foi habilitada, permitindo que sejam vistos chamados em aberto ou adicionar novos chamados (incidentes):

SNAG-0015

Ao utilizar a criação de uma nova solicitação, a interface moderna do WAP se alinha com os dados fornecidos na oferta do serviço, de forma muito clara e fácil de entendimento:

SNAG-0016

Caso a sua oferta de serviço contenha objetos, como lista e enumeradores, todos são suportados no WAP:

SNAG-0017

Como resultado, ao abrir a solicitação pelo portal do WAP podemos verificar todos seus dados e a lista de solicitações em aberto:

SNAG-0018

SNAG-0019

Ao abrir a solicitação registrada, podemos ver detalhes e a lista de atividades que o template do Service Manager define nos workflows, de forma muito mais intuitiva que o Self-Portal do Service Manager, assim como documentos anexados e artigos de conhecimento (KB):

SNAG-0020

SNAG-0021 

Mesmo a parte de comentários e interações entre o sistema/operador e o usuário são simples e fáceis de serem acessados e utilizados:

SNAG-0022

SNAG-0023

Porem, caso sua empresa ainda utilize o Self-Portal, será possivel visualizar os chamados abertos no WAP dentro dele, como o exemplo abaixo da requisição que abrimos:

SNAG-0025

 

Conclusão

Com a integração entre o Windows Azure Pack 2.0 e o System Center Service Manager, oferecer serviços de Cloud (público ou privado) se tornará muito mais profissional!

Utilizando IP Fixo em Maquinas Virtuais no Windows Azure

Um novo recurso que se tornou disponivel nas novas versões do PowerShell para o Windows Azure são os comandos “StaticVNetIP”. Você pode baixar a nova versão em http://www.windowsazure.com/pt-br/downloads/#cmd-line-tools

Estes comandos permitem que se fixe o IP dentro do range da rede virtual que você já tenha definido, permitindo assim que consiga garantir o IP de cada VM sem a necessidade de fazer o “Start” na ordem fixa todas as vezes.

Passo 1: Saiba os Riscos e Gerencie Seus IPs

Antes de iniciarmos, é importante ressaltar que não há suporte se houver problemas (http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx#BKMK_IPAddressDNS):

“Use DHCP-leased addresses (this is mandatory — static addresses are NOT supported)

Portanto, antes de começar a designar IPs fixos as suas VMs, lembre de manter uma lista dos IPs definidos!

Além disso, não utilize IPs que não estejam no range da sua rede virtual. Por exemplo, a minha rede tem o range 10.0.1.4 a 254 e se eu fixar o IP 10.0.2.4 a uma VM, ele ficará incomunicável e precisará ser excluida.

image

 

Passo 2: Registrar a Assinatura no PowerSell

Este passo é permanente, e basta executar o comando Add-AzureAccount que irá abrir uma janela de autenticação e importará os dados da sua assinatura:

Capture

Para verificar se importou com sucesso use o comando Get-AzureSubscription que retornará os dados da assinatura registrada:

image

Caso precise remover uma assinatura que tenha utilizado no passado para teste, o comando Remove-AzureSubscription é indicado. Se necessário, precisará redefinir sua assinatura padrão, o comando abaixo redefinirá o default:

image

 

Passo 3: Registre o IP de cada VM

Para registrar os IPs lembre-se do que foi comentado no início, é necessário que eles estejam no range da rede virtual que você tenha definido, senão a VM não poderá mais ser acessada e ficará incomunicável.

O comando que utilizaremos para fixar o IP não trabalha com strings, o primeiro passo é usar o comando Get-AzureVM para retornar em uma variável o PermanentID da VM desejada:

image

O comando acima procura a VM “W2012-Exch-3” no catálogo e retorna o ID, e o comando Set-AzureStaticVNetIP abaixo fixa o IP:

image

Obs: Pode-se usar o “pipe |” para executar os comandos na mesma linha se desejado

Porem, note que o comando acima não foi confirmado, apenas como que simulado. O correto é utilizar o Update-AzureVM na sequência para confirmar a alteração, como um commit.

Sendo assim, a sequencia de comandos para alterar as VMs seria como o exemplo abaixo:

image

Note que neste exemplo 3 diferentes VMs tiveram seus IPs fixados e é possivel com o comando Get-AzureStaticVNetIP consultar se a VM fixou o IP desejado:

image

Por fim, ao verificar o escopo de rede no Azure, pode-se ver que as maquinas reiniciadas receberam o IP que fixamos:

ListaIPs

Posted: mar 11 2014, 00:25 by msincic | Comentários (0) RSS comment feed |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

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.

Utilizando o Hyper-V Replica Parte I–Vantagens e Primeira Réplica

O segundo artigo sobre Hyper-V Replica abordando RPO e RTO esta disponivel em http://www.marcelosincic.com.br/blog/post/Utilizando-o-Hyper-V-Replica-Boas-Praticas-para-RTO-e-RPO.aspx

Apesar de muito noticiado como novidade no Windows Server 2012, o Hyper-V Replica não está sendo tão utilizado pelos profissionais de TI como esperado. Muito provavelmente temos o desconhecimento e a restrição a ser uma nova tecnologia, o que é natural.

Porem, uma das formas hoje usadas para réplica de VMs e que no Hyper-V criam diversos problemas é a réplica de storage, ou seja, a replicação que ocorre entre os storages em casos de datacenter de redundância (DR).

A tabela abaixo mostra alguns motivos pelo qual Hyper-V Replica é melhor opção a réplica de storage:

Storage

Hyper-V Replica

Performance da Réplica

Performance da cópia usa algoritmos dedicados de compressão

Boa performance, só replica alterações no VHDX, Windows 2012 R2 oferece compressão
Consistência Assegura consistência na réplica

Replica baseada em NTFS, permitindo ativo/passivo e Live Migration

RPO

Permite a réplica em agendamentos regulares ou contínuos Permite agendar a primeira réplica, as atualizações são a cada 5 minutos no Windows 2012 RTM e 30 segundos, 5 minutos ou 15 minutos no Windows 2012 R2

RTO

Necessita que os discos sejam ativados e os hosts Hyper-V inicializados Imediatamente os hosts ativam as VMs no DR
Replica de Novas VMs É necessário criar manualmente no site DR Replica qualquer alteração no XML da VM

Admin Tools

Storage console

Console do Cluster/Hyper-V

Nivel de Especialização Conceitos de Storage geral e do fabricante

Hyper-V e Microsoft Cluster

Cancelamento da Réplica Permite cancelar réplica de uma LUN Permite cancelar a réplica apenas de uma VM ou até mesmo um VHDX
Inversão Necessário reconfigurar a réplica Permite a inversão em modo gráfico

Cluster Mode

Ativo/Passivo Ativo/Ativo
Ação de Recover Recriar/Reiniciar os algoritmos de réplica Menu de contexto para reiniciar ou inverter

O maior problema da réplica de storage para Hyper-V é que a LUN replicada no site DR está offline. Sendo assim, não dá para alterar ou mesmo ver no Hyper-V as VMs no site DR, uma vez que a LUN não está acessivel e só pode ficar no momento de uma virada de operação.

Já o Hyper-V Replica permite inverter as VMs sem qualquer passo adicional, incluindo a reversão (inverter primário com secundário). Porem, iremos falar disso em outro post. Vamos focar no momento da primeira réplica.

Existem duas formas de a primeira réplica ser realizada sem utilizar o link entre os sites do exemplo abaixo:

image

A primeira forma é fazer local a configuração do Hyper-V Replica e esperar o secundário ter todas as VMs prontas.

Este método tem a desvantagem da montagem do storage e servidores em dois momentos, o que pode encarecer o serviço e em muitos casos não haver espaço ou recursos de energia elétrica suficientes.

A outra forma é fazer isso por usar o próprio wizard do Hyper-V Replica escolhendo exportar a VM.

Para isso, ao configurar a réplica de uma VM escolha a opção "Send initial copy using external media” e defina um local para exportar os arquivos como abaixo:

image

O passo seguinte é importar a VM no host onde ela foi criada. Note que a VM é criada no final do wizard acima no host destino, mas sem os arquivos e sem ativar a réplica:

Imagem1

Escolha a localização criada pelo wizard e aguarde a importação:

Imagem3

Completado este item no servidor destino o status estará Warning e no servidor de origem Normal indicando que está ok.

Imagem4

O próximo passo é clicar no servidor de origem na VM e usar a opção Resume Replica para que ele inicie a cópia de sincronização.

Uma dica importante é que o Hyper-V Replica funciona criando um snapshot e enviando o arquivo de snapshot da origem para o destino, portanto não demore muito tempo para fazer a sincronização inicial pois poderá ter problemas de espaço e performance por conta do uso de um disco diferencial do snapshot.

Nos próximos posts iremos abordar melhores configurações e como montar um ambiente de Hyper-V Replica.

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