Latência em discos e problemas de desempenho

comentado por Bruno Domingues em abril 1, 2009

Por algum tempo, num passado não muito distante, quando fazíamos planejamento de capacidade para máquinas x86 sempre nos preocupávamos principalmente com CPU e memória (estou deliberadamente generalizando!), e quando se falava em discos, no máximo era para dizer quanto espaço era necessário. Porém o tempo foi passando e as evoluções de desempenho dos processadores, seguindo a Lei de Moore, e a capacidade de memória bem como sua velocidade de acesso, superaram em muito a capacidade de IOPS (I/O por segundo) dos discos, que por mais de 10 anos, apesar de terem melhorado muito nas tecnologias de transferência de dados, não obteve o mesmo avanço em escrever e capturar o dado no disco, ficando limitado a faixa de 7.200rpm para os discos mais simples de desktops e pequenos servidores até 15.000rpm para servidores e storage high-end, o que na melhor das hipóteses nos confere desempenho igual a 160 IOPS (antes da controladora) e 180 IOPS (depois da controladora).

Bem, para que vocês tenham uma melhor noção do que isso representa no planejamento de capacidade para uma aplicação real, vamos tomar como exemplo o caso do servidor de caixas postais do Exchange Server 2003 da Microsoft, onde uma boa média de utilização por usuário seja de 1,2 IOPS, apesar de já ter visto casos de 2,2 IOPS, porém 1,2 IOPS é um excelente número para usuários intensivos de correios.

Analisando estritamente do ponto de vista de capacidade de I/O para o subsistema de discos, um disco comum de 10.000rpm (100/130 IOPS - antes e depois da controladora) seria capaz de atender até 108 usuários [130 IOPS/1,2 IOPS], e a conta inversa, de quantos discos são necessários para atender, digamos 5.000 usuários, seriam necessários portanto 47 discos [5.000 * 1.2 IOPS/130 IOPS], ou seja, nos dias de hoje precisamos mesmo usar um armazenamento externo… mas espere um pouco, e a respeito a tolerância a falhas destes dados? Vamos ver como fica…

Se utilizarmos o RAID 5, que é uma configuração atualmente trivial e que menos impõe penalidade na utilização de espaço em disco, a nossa conta de IOPS muda por completo, pois neste cenário, existe uma penalidade de desempenho para escrita, pois para dado inserido no disco é necessário antes ler as paridades no RAID (duas leituras), calcular a nova paridade para escrevê-la novamente (duas escritas), ou seja, no exemplo anterior onde necessitávamos de 6.000 IOPS para atender 5.000 usuários, e assumindo que temos uma relação de 2:1 nas operações de leitura:escrita, teríamos a seguinte conta:

Leituras: 4.000 IOPS

Escritas: 2.000 IOPS

Para o RAID 5 necessitaremos de capacidade do subsistema de discos para: 4.000 IOPS + (2.000 IOPS * 4) = 12.000 IOPS, logo será necessário 93 discos [12.000/130] de 10.000 rpm ou 67 discos [12.000/180] de 15.000 rpm… não precisa ir muito além para ver a inviabilidade desta abordagem nos dias atuais. Você pode me perguntar: e se usarmos o RAID 1+0 (também conhecido como RAID 10) que oferece melhor desempenho, como ficaria essa conta? Fácil, pelo fato da penalidade de escrita no RAID 10 ser de apenas x2, pois preciso somente escrever em dois discos, contra os x4 do RAID 5, teremos a seguinte situação:

4.000 IOPS + (2.000 IOPS * 2) = 8.000 IOPS, logo será necessário 62 discos [8.000/130] de 10.000 rpm ou 45 discos [8.000/180] de 15.000 rpm, melhorou bastante, mas não se assuste se quando você montar essa infra-estrutura e descobrir que os dados reais não coincidem com os dados da prancheta. Por quê? Porque disco não é o único componente do subsistema de I/O, há de se dimensionar e escolher os parâmetros da HBA adequadamente. Em algumas situações eu me deparei com essa situação, e acabei descobrindo que para a maioria dos casos os valores padrão da HBA não são ótimos, e normalmente você vê enfileiramento de disco no sistema operacional e não saturação do lado do storage, e é ai que você aprende que existem vários parâmetros da HBA, porém dois se destacam entre eles: Queuedepth e Queuetarget, basicamente definem quantas filas serão criadas na HBA e qual é o tamanho do buffer de cada um delas. Se você verificar na figura seguinte a tela do Performance Monitor de uma máquina gerando constantemente a mesma taxa de requisições de I/O e o enfileiramento das requisições somente alterando o tamanho do buffer vai perceber o que estou falando:

Agora que você já definiu quantos discos você precisa para ter desempenho suficiente para seu servidor e caixa postais do Exchange Server, e acha que agora sabe de tudo sobre como dimensionar subsistema de discos e não será por isso que o seu correio eletrônico ficará lento, veja o vídeo do Brendan Gregg da Sun’s Fishworks a respeito de uma descoberta, no mínimo inusitada de latência em discos…

Já fez o dimensionamento de ruído do seu Data Center? Hummm….

Olhando tudo isso, e vendo como esta indo a tecnologia de SSDs me sinto naqueles momentos da história onde via vendendo lado a lado na mesma loja, máquina de escrever e computadores…

Somente como curiosidade, se tiver interesse em saber quantos discos SSDs (Intel X-25E) seriam necessários para o mesmo servidor Exchange, refaça as contas com capacidade de 35.000 IOPS para leitura e 3.300 IOPS para escrita, ambos aleatória de páginas de 4KB (o mesmo tamanho de página do Exchange 2003), se ainda estiver interessado em entender porque eu me sinto como na transição das máquinas de escrever para os computadores, leia ainda sobre outro post meu a respeito de eficiência energética em Data Centers.

Abraços e até a próxima.

Comentários (5)

Outros posts com as tags: discos, planejamentodecapacidade, ssd