No primeiro artigo desta série Conceitos de Storage para IT Pros–Tipos de RAID e IOPS abordamos alguns conceitos importantes e básicos para profissionais de TI sobre os tipos de RAID disponiveis e utilizados hoje em storages e também como calcular IOPS (operaçoes de leitura e escrita) para cada tipo de disco e aplicações.

No segundo artigo http://www.marcelosincic.com.br/blog/post/Conceitos-de-Storage-para-IT-Pro-2-e28093-Controladoras-e-Modelos.aspx abordamos os tipos de controladoras e tecnologias de storage mais comuns hoje existentes no mercado.

Neste terceiro artigo veremos o que são conceitos de tierização e virtualização de storages.

Virtualização

A virtualização de storage conceitualmente é diferente da virtualização de computadores.

Na virtualização de storages o conceito é utilizarmos um produto que faça a conexão com vários tipos e modelos de storage. Por exemplo, o System Center Virtual Machine Manager 2012 é capaz de ser a interface entre os diferentes storages e as máquinas virtuais. Mais detalhes sobre isso podem ser vistos no post http://www.marcelosincic.com.br/blog/post/Gerenciamento-de-Storage-com-o-System-Center-Virtual-Machine-2012.aspx

O mesmo recurso pode ser alcançado com o SMB 3.0 do Windows Server 2012, onde podemos apontar todas as LUNs disponíveis em um File Server e por meio do SMB 3.0 mapear as VMs entre os diferentes storages.

Tierização

Este recurso está presente em alguns storages de mercado e pode ser simulado pelo VMM. Significa ter a possibilidade de termos diversos storages com performances diferentes e ter a capacidade de mover uma VM de um storage mais lento para outro mais rápido de forma transparente a operação.

Isso pode ser simulado pelo VMM e pelo Hyper-V 3.0 com o recurso Storage Migration, onde podemos mover as VMs com Live Storage Migration permitindo que a operação não seja interrompida quando movemos entre os diferentes modelos de storage disponíveis.

Porem, alguns modelos storage como, por exemplo Compellent e Equallogic, podem conter “gavetas” de discos de diferentes tipos e mover os dados entre as gavetas conforme a performance necessária da aplicação ou maquina virtual. Neste caso o software do storage faz isso automaticamente conforme a carga que cada VM ou aplicação impõe ao storage.

Fonte: http://www.dellstorage.com/storage-tiering-archiving/storage-tiering.aspx

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

Muitos que usam os produtos System Center 2012 ainda utilizam as ferramentas como nas versões 2007 e 2008, ou seja, de forma autônoma.

Assim, o Service Manager recebe incidentes manualmente quando algum tipo de alerta é gerado no Operations Manager. Os relatórios e dados de inventário (CI) precisam ser consultados no Configuration Manager.

Utilizando os conectores do Service Manager podemos integrar todos os produtos como mostra o diagrama abaixo:

Como pode ser visto no diagrama, é o Service Manager que faz o papel de integrador entre os diferentes produtos System Center. O Orchestrator também atua, porem por meio dos Runbooks que podem interagir com o desenho de atividades, mas já comentei em outro post http://www.marcelosincic.com.br/blog/post/Orchestrator-Integration-Packs-para-System-Center-2012.aspx

Criação de Conectores no Operations Manager

Os conectores precisam ser criados dos dois lados, inicialmente pelo Operations Manager em Administration –> Internal Connectors, como pode ser visto abaixo, onde os diversos conectores já estão criados, sendo que apenas um é criado no assistente e os outros criados automaticamente conforme o número de Management Packs:

O primeiro passo é definir o nome do conector e quais os grupos de computadores do SCOM serão integrados:

No passo seguinte definimos quais são os Management Packs que serão integrados com o Service Manager, sendo que no momento de criação do conector pode-se escolher todos e fazer a manutenção após o conector já criado e testado, como será mostrado no próximo tópico:

O ultimo passo ao criar o conector é definir critérios de filtro. Este item é mais importante que os dois acima (Computer Groups e Management Packs), pois permite definir de forma granular quais alertas irão gerar os incidentes no Service Manager. Por exemplo, apenas os erros são importantes em incidentes, assim como a prioridade e o estado do alerta no SCOM.

Também é importante notar que os incidentes no Service Manager podem ser abertos pelos estados resultantes dos Healthy Monitors do Operations Manager, o que amplia em muito o número de incidentes que serão gerados:

Edição do Conector no Service Manager

Criado o conector no console do Operations Manager é possivel ver o mesmo conector replicado no Service Manager em Administration –> Conectors.

Se for necessário alterar como os incidentes são abertos, registrados e auto-atualizados é necessário alterar o conector pelo console do Service Manager, como mostrado na tela abaixo:

Na tela de configuração do template definimos os critérios dos incidentes que serão sincronizados, lembrando que caso não seja configurado corretamente o conector no Service Manager, ao fechar um incidente este não será encerrado no Operations Manager e vice-versa.

No exemplo abaixo, selecionei todos os computadores pelo grupo, mas poderia ser feito um filtro pelo Management Pack, nivel de severidade, prioridade ou mesmo um campo personalizado:

Criando Conectores de Itens (CI) no Service Manager

Note que a importação dos Management Packs tem a ver com os itens de configuração e não com os alertas definidos anteriormente.

Neste caso, o que será importado são itens, computadores e dados recolhidos dos agentes pelo Operations Manager, para formar a biblioteca de dados de configuração junto com o próprio System Center Configuration Manager.

Sendo assim, criar o conector de itens de configuração não é tão importante quanto criar o conector para os alertas, principalmente em ambientes onde o System Center Configuration Manager também foi implementado e sincronizado.

De qualquer forma, recomendo que se crie o conector de CI para que máquinas monitoradas pelo Operations Manager e que não contenham agente do Configuration Manager estejam contempladas no banco de dados do Service Manager ao abrir um chamado. Alem disso, o conector permitirá ver aplicações como sites do IIS e outros serviços do Windows pelo Service Manager.

Para criar e administrar este conector, basta definir quais os Management Packs que irão enviar dados e o agendamento para esta tarefa:

Outros Conectores

Mais detalhes de cada um dos conectores pode ser vista no TechNet em http://technet.microsoft.com/en-us/library/hh524326.aspx

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

A Microsoft disponibiliza diversas ferramentas de análise da implementação de um produto. Alguns são nativos e outros opcionais:

Vários artigos abordam o uso do BPA e do validador do Cluster são nativos e o MBSA foi descontinuado para o Windows Server 2012, então neste artigo trataremos apenas do MBCA e seu uso exemplo com o System Center 2012.

Instalação do MBCA e Pacotes

A instalação deste produto é muito simples, bastando executar o instalador.

Após instalar o MBCA passamos a instalar as ferramentas, ou pacotes de análise, permitindo que ao abrir o MBCA vejamos uma lista dos pacotes de análise disponiveis:

Executando o System Center 2012 Configuration Analyzer

Note que ao abrir o menu não terá uma opção para o SCCA, uma vez que ele é um plugin do MBCA, como pode ser visto abaixo:

O passo seguinte é selecionar os computadores que serão validados. Porem, para validar alguns servidores remotos pode ser necessário fazer o registro de segurança com Setspn. Se você não sabe como utilizar, pode usar as instruções do próprio SCCA, como mostrado nos tópicos a frente:

Os resultados são mostrados em duas abas, sendo possivel ver um resumo ou detalhamento dos dados analisados. No exemplo abaixo executei em um SCSM 2012 SP1 e o resultado inicial é que não há pendencias e permitindo exportar o relatório que pode ser revisado posteriormente depois de salvo com a opção “Open Report” no primeiro pront.

Utilizando a opção Collected Data é possivel ver os dados utilizados pelo SCCA para validar o SCSM:

Servidores Remotos

Instalar o MBCA e o SCCA em um único servidor é útil para evitar a instalação em uma farm de servidores ou mesmo para maquinas com acesso limitado. Porem, em alguns casos nao é possivel executar o SCCA remotamente tendo como resultado a mensagem abaixo:

A função Credssp permite que o servidor onde o SCCA está instalado tenha acesso ao servidor que está sendo analisado, sendo simples de ser executado e necessário para análises remotas.

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