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/

No Community Zone que ocorreu na semana passada estávamos conversando em uma mesa, não vou citar os nomes porque não lembro todos e seria injusto, e chegamos no assunto acima. De um lado da mesa tinhamos alguns IT PROs e do alguns desenvolvedores. Os desenvolvedores já logo criticam o pessoal de Infra pela dificuldade que eles impõe e sempre jogam a culpa nos sistemas e programadores.

Eu atuo nas duas áreas desde que comecei a trabalhar em 1988. Neste época sistema operacional era CPM, rede era multiplexada serial, linguagem era Dbase II que já era o banco de dados também. Desde então tento manter os dois universos, estudo tanto os produtos de rede quanto as linguagem de programação. Posso dizer que está ficando dificil, os produtos se tornaram muito complexos, mas ainda consigo me organizar por estudar a fundo um por vez focando nas mudanças.

Mas enfim, a idéia do post é falar da experiencia de quem a um bom tempo convive nos dois mundos.

O que os desenvolvedores fazem para serem “odiados”?

O principal problema dos profissionais de redes é conseguir monitorar as aplicações. Os desenvolvedores não se interessam muito em como os IT PROs trabalham e não dão os recursos necessários para eles. Algumas coisas simples como métricas, logs e identificação clara de processos já resolveriam muitas discussões.

O que podemos fazer como desenvolvedores para trazer a paz?

Alguns exemplos de recursos que poderiam ser facilmente utilizados pelos desenvolvedores:

• Na string de conexão com o banco de dados inclua o parametro Application Name para o DBA poder monitorar a aplicação. É um parametro muito simples e extremamente necessário, porque em aplicações é comum utilizar usuários fixos para aplicações e sem o nome não é possivel saber qual sistema está executando aquele comando que gerou locks ou wait times excessivos. Um exemplo de uma string de conexão “bem feita” seria:
  ”Provider=SQLServerOleDB;Server=ABC;Database=DEF;UID=Joao;PWD=1234;Application Name=SISContabil”
• Inclua nos seus aplicativos contadores de performance utilizando os objetos PerformanceCounter e Installer. Estes objetos geram no Performance Monitor do Windows dados que podem ser transformados em gráficos, traces, alertas e logs. O processo para criar um contador é muito simples:
  1. Insira o objeto PerformanceCounter em sua aplicação
  2. Configure o objeto criando uma categoria (CategoryName) e contador (CounterName)
  3. Clique com o botão direito no objeto e escolha Add Installer para que sua aplicaçoes crie no registry do Windows os registros do contador
  4. No seu código ao acessar um banco de dados, por exemplo, utilize o objeto PerformanceCounter com o método Increment para aumentar o valor do contador
• Gere erros ou alertas de problemas no log de eventos do Windows. Este recurso permitirá aos operadores vasculhar no Event Viewer do Windows problemas que estão ocasionando paradas. Tão útil é este recurso que os IT PROs poderão utilizar produtos como o System Center Operations Manager, NetIQ ou Tivolli para quando um evento acontecer disparar emails de alerta para os administratores, ou melhor ainda, executar scripts que automaticamente resolvem o problema.
  Para fazer isso basta seguir os passos:
  1. Acrescente ao seu aplicativo o objeto EventLog
  2. Defina o nome do Log (Log) que será criado e o nome da aplicação (Source)
  3. Dentro do seu aplicativo utilize o método WriteEntry para passar os parametros que serão gravados no log do SO

Estes são 3 exemplo que poderão ser utilizados e resolverão muitos dos problemas que hoje existem entre estes grupos. Claro que os exemplos estão baseados em aplicações Windows Forms, mas os mesmos objetos podem ser utilizados programaticamente no ASP.NET.

Para que os desenvolvedores tenham uma idéia do porque é importante os passos acima, pense que o IT PRO trabalha com resolução de problemas baseados em comportamento de sintoma-causa-solução e sem contadores de performance e eventos não tem como achar a causa sobrando apenas culpar o programador que “andou mexendo no servidor”.

Outro recurso muito importante que os passos acima possibilitam é criar o Baseline onde os IT PROs tem uma base de alterações no ambiente. Por exemplo, fazem a medição de contadores ao longo de um periodo e quando o servidor apresenta problemas de performance eles comparam os contadores atuais com os de base para descobrir onde estão as variações. Se o desenvolvedor não dá as medições o IT PRO irá verificar os contadores e como nenhum demonstrará o problema, mais um vez o “programador que mexeu aqui” é o culpado.

Outra forma de monitoração com produtos que já foram citados são os Dashboards do SCOM que mostram em grandes monitores o estado de cada servidor por monitorar os eventos no log e o baseline de performance. Se a aplicação não gera nem log nem contadores, o servidor não irá apresentar o erro, resumindo a dizer que o IIS ou o SQL está com tempo de resposta lento quando o problema já se alastrou para todos os subsistemas (disco, processador e memória).

É isso ai, como programador também me incluo entre os que deixam de prover as ferramentas. Mas vamos mudar isso !!!!!

Se alguem lembra de outros métodos para “pacificar” essa apimentada relação, comente.