Em uma série de palestras que ministrei do ano passado (TechEd 2011, SQLPass #127, MCT Summit e universidades), 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.

Ainda é um assunto muito novo para IT Pros por conta de não ser abordado em cursos de faculdade, apenas em treinamentos técnicos de certificação.

Neste primeiro artigo irei abordar os tipos de RAID e o que são IOPS. Em um próximo artigo comentarei sobre tipos de controladora e arquiteturas disponives (Fibre Channel, HBA, SMB e iSCSI).

Parte 1 – Tipos de RAID

RAID é o acronimo de Redundant Array of Independent Disk ou “Agrupamento redundante de discos independentes”, o que indica o uso de diversos discos para criar uma estrutura de alta disponibilidade.

Os tipos de RAID podem ser simplificados pelo uso de 4 tipos principais, sendo:

O mais usado hoje é o RAID 5/10, já que eles tem boa performance e redundância, como mostra o gráfico abaixo:

Abaixo um gráfico de itens gerais e comparação entre os tipos de RAID 5/6/10/50:

Observação: Os dados acima foram colhidos no docuemnto “Choosing a Member RAID Policy” que é baseado na arquitetura do Dell Equallogic e não é necessário se cadastrar: http://www.dellstorage.com/WorkArea/DownloadAsset.aspx?id=1066

Parte 2 - O que são IOPS?

É o número de operações por segundo que um disco individual consegue chegar. Por exemplo, um disco SAS de 10K consegue em média 140 IOPS.

Esta velocidade é padrão na industria com variações entre modelos, mas podemos ter uma base do que é aceitável e o fabricante do disco poderá lhe informar este número.

Porem, note que a diferença é muito grande, principalmente levando em conta os novos discos SSD. Por exemplo, o disco X25-E da Intel (Veja o pdf com as caracteristicas em http://download.intel.com/design/flash/nand/extreme/extreme-sata-ssd-datasheet.pdf) chega a números 30 vezes maiores que os discos SAS e SATA.

Porque o IOPS é tão importante?

Esta pergunta é óbvia, mas a explicação pode não ser tão simples. Acontece que na maioria dos casos temos a tendencia de minimizar a questão dizendo que é “performance” ou “percepção do usuário” mas na verdade pode impactar diretamente no funcionando de um aplicativo, em alguns casos até inviabilizando.

Por exemplo, um ambiente Exchange 2003 com 2 mil caixas de correio precisa de 1,5 mil IOPS e este número não é fácil de alcançar. O SQL Server para um banco de dados do SharePoint precisa de 5 mil IOPS para funcionar.

Como calcular o IOPS?

Multiplique o total de discos pelo tipo de RAID e conseguirá o seu número. Segue alguns exemplos:

O RAID 1, RAID 10 ou RAID 0 irá lhe proporcional o maior numero de IOPS possivel, já o RAID 5 o calculo leva em conta 1 disco a menos e no RAID 50 2 discos a menos para as paridades.

Como conseguir o maior IOPS possivel com maior capacidade?

Temos tres formas de fazer isso:

1. Utilize discos de alta performance, como os SAS de 15K ou o SSD, porem são caros e no caso do SSD de tamanhos de apenas 32/50/64/100GB
2. Utilize o tipo de RAID apropriado para a performance e não visando o tamanho desejado como muitos hoje fazem, o que muitas vezes implica em utilizar RAID 10 para ter a performance total ao invés de RAID 50, perderiamos em capacidade mas ganhamos em performance
3. Compre um storage que trabalha com as LUNs virtuais, ou seja, ele aloca os dados nos discos conforme a necessidade deste dado e não necessita dizer o tipo de RAID

Referencias interessantes

Como calcular IOPS para Exchange 2003 http://technet.microsoft.com/en-us/library/bb125019(EXCHG.65).aspx

Como calcular IOPS para Exchange 2010 http://technet.microsoft.com/en-us/library/ee832791.aspx

Como calcular IOPS para o SQL do SharePoint 2010 http://technet.microsoft.com/en-us/library/cc298801.aspx

Utilitário para medir IOPS para o SQL Server (SQLIO) http://www.microsoft.com/download/en/details.aspx?displaylang=br&id=20163

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/