O Beta do SCOM foi liberado dia 20/jul e como participante do CEP, que é o programa de avaliação de produto, iniciei os testes com a nova ferramenta. Este primeiro post será para detalhar o processo de instalação, mas acrescentando dicas. Caso deseje participar do programa de avaliação entre em http://connect.microsoft.com/site1211/Survey/Survey.aspx?SurveyID=12787

O primeiro passo é preparar os pré-requisitos da instalação que requerem um cuidado ou configuração especial.

SQL Server

O SCOM 2012 não é mais compatível com o SQL Server 2005, apenas as versões do SQL 2008 e SQL 2008 R2.

Porem, ele exige que o collation (código de página utilizado) seja SQL_Latin1_General_CP1_CI_AS quando normalmente utilizamos o SQL_General_CI_AS. A figura abaixo mostra a configuração correta para o SQL Server:

E caso o seu SQL esteja instalado com outro collation?  O ideal é instalar uma nova instância ao invés de alterar a atual e o motivo é que ao mudar o collation bancos de dados de usuário serão desatachados, ou seja, continuaram no disco mas sairam do catálogo.

Se desejar, pode alterar utilizando o comando abaixo e depois executar o “Attach” para retornar os bancos de dados anteriores.

Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=dominio\usuario
/SAPWD=Senha /SQLCOLLATION=SQL_Latin1_General_CP1_CI_AS

O comando deverá ser executado do diretório de instalação do SQL, subdiretório Setup Bootstrap.

Internet Information Server (IIS)

O IIS precisa estar instalado com as features padrão utilizadas para suporte a portais que utilizem .NET Framework, que aliás exigirá a instalação manual do .NET 4.0 no Windows 2008 R2.

Porem, exige-se a configuração adicional do ISAPI para executar o Framework 4.0, como mostra a figura abaixo:

Para isso vá ao gerenciador do IIS e na opção ISAPI Restrictions e utilize a opção Allowed no ASP.NET 4.0.

Instalando o SCOM 2012

A tela inicial do instalador é típica dos produtos atuais da Microsoft, com as opções para instalar agentes, coletor de auditoria e gateway. Do lado direito da tela é possivel acessar os documentos de suporte para a instalação.

A seguir escolhemos as opções desejadas, que fazem parte da estrutura principal do ambiente, lembrando que opção como coleta de auditoria e gateway são instalados diretamente na tela principal, acima.

O passo seguinte é executar o pré-requisito do sistema, que tem a vantagem em relação ao SCOM 2007 que não é necessário dar os nomes dos servidores que serão utilizados e é possivel re-executar a verificação sem a necessidade de sair e retornar a instalação. Alem disso, ele indica o que fazer para resolver os problemas de pré-requisitos. Caso queira detalhes clique no link Full System Requirements para trazer a página online com todos os dados necessários.

A tela seguinte permite criar um novo grupo de gerenciamento ou ingressar em um que já exista. Caso escolhe a opção de adicionar um novo servidor será solicitado o nome do servidor que já existe.

Na sequencia é definido o nome do servidor SQL Server e os dados do banco a ser criado, lembrando as restrições de versão e collation explanadas no inicio do post.

Por fim, definimos as contas que serão utilizadas para subir os serviços e fazer as conexões. Caso deseje criar contas especificas para cada função clique no link do Security Guide que trará detalhes das permissões necessárias a cada papel.

Instalação iniciada e terminada com sucesso rapidamente.

Nos próximos posts iremos ver o SCOM 2012 em funcionamento, aguardem!

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!!!

Neste terceiro post iremos tratar de como trabalhar com as politicas de backup “long-term” para ajudar a escolher a mais apropriada para sua necessidade.

Como abordado no primeiro post é necessário escolher algumas opções ao criar o grupo de proteção e utilizar a opção “Long-term”.

A primeira opção Retention range indica qual o tempo de retenção ou expiração do backup. Esta opção é importante ao ser planejada pois se este tempo for alto indica o numero de fitas que precisam ser utilizadas, já que como abordado na parte II a fita só pode ser reutilizada quando este periodo terminar.

A opção Frequency of backup e Backup schedule obviamente indicam quando o backup será executado na janela de retenção.

Quantas fitas (tapes) são necessárias?

Utilizando o backup acima como exemplo, precisariamos de 6 fitas. O motivo é que o backup é diario realizado de segunda a sexta (sabado e domingo está como excluido) o que formaria um conjunto de 5 fitas. A 6ª fita é a de arquivamento, já que o rodizio das fitas só seria possivel ao completar uma semana.

Ou seja, sempre serão necessárias uma fita a mais do que o periodo indicado para ser possivel realizar o rodizio.

Utilizando o Co-location não diminuo o numero de fitas?

Sim e muito, principalmente se os grupos de proteção forem menores que 400/800GB da fita LTO-3, por exemplo, já que diversos backups poderão estar contidos em uma unica fita.

O problema do co-location é o fato do gerenciamento ser manual. No exemplo da pergunta anterior poderá existir uma rotina de backup onde o operador em um horário determinado irá trocar a fita.

Quanto o co-location está ligado é necessário ficar manualmente olhando o quanto da fita está livre para fazer a troca, alem do co-location acabar misturando backups de grupos de proteção diferentes na mesma fita, o que torna mais complexo o arquivamente em cofre ou outra forma persistente.

Exemplos com politica de renteção em cofre

Vamos fazer um exemplo de uma empresa com 3 grupos de proteção, o que é comum. Levaremos em conta que o arquivamento mensal será permanente:

• Grupo 1 – File Server com backup diário (seg-sex), retenção semanal e arquivamento mensal
• Grupo 2 – Exchange com backup diário (todos os dias), retenção semanal e arquivamento semanal/mensal
• Grupo 3 – SQL Server com backup diário (todos os dias), retenção semanal e arquivamento semanal/mensal

Para o grupo 1 precisariamos anualmente de 12 fitas permanentes mais 6 rotativas:

• 5 fitas para os backups diários
• 1 fita para fechar o ciclo semanal
• 12 fitas para os backups mensais que são o ultimo semanal do mês, que será arquivada

Como o grupo 2 e 3 são similares seriam necessárias anualmente 56 fitas permanentes e 7 rotativas que ao longo do

• 7 fitas para os backups diários
• A ultima fita de backup diário na semana será a fita semanal, portanto 4 fitas por mês que serão arquivadas
• A fita de backup mensal é a última fita do semanal, que será será arquivada

Se o mesmo grupo 2 e 3 não exijam que o backup das semanas anteriores sejam guardados ao terminar o mensal teriamos a redução de 3 fitas ao mes o que somaria 12 fitas permanentes, 3 rotativas semanais e 7 rotativas diárias:

• 7 fitas para os backups diários
• A ultima fita de backup diário na semana será a fita semanal, portanto 4 fitas por mês que serão arquivadas
• A fita de backup mensal é a última fita do semanal, que será será arquivada dispensando as 3 anteriores para rodizio

Conclusão

Espero ter esclarecido as principais dúvidas sobre backup em fitas com o DPM e fiquem a vontade para comentar ou enviar perguntas e sugestões.

Parte I – Criando grupos de proteção incluindo tapes Utilizando Fitas (Tape Drive) no DPM 2010–Parte I

Parte II – Gerenciando tapes http://www.marcelosincic.com.br/blog/post/Utilizando-Fitas-(Tape-Drives)-no-DPM-2010e28093Parte-II.aspx