Eu procuraria mover os bancos de dados req altos de IOPS / baixo espaço para matrizes baseadas em SSD - esses discos são pequenos e fornecem um throughput excelente. Essa é uma abordagem tão simples quanto jamais chegará
Eu tenho um número razoavelmente grande de matrizes RAID (controladores de servidor e armazenamento SAN de médio porte) que sofrem do mesmo problema: eixos com fenda insuficiente para manter o pico de desempenho de E / S e toneladas de espaço em disco não utilizado. / p>
Eu acho que é um problema universal, já que os fornecedores oferecem os menores discos com capacidade de 300 GB, mas o desempenho de E / S aleatória não cresceu muito desde o momento em que os discos menores tinham 36 GB.
Um exemplo é um banco de dados com 300 GB e que precisa de um desempenho aleatório de 3200 IOPS, para obter 16 discos (4800 GB menos 300 GB e 4,5 TB de espaço desperdiçado).
Outro exemplo comum são os redo logs de um banco de dados OLTP que são sensíveis em termos de tempo de resposta. Os redo logs obtêm seu próprio espelho de 300 GB, mas consomem 30 GB: 270 GB desperdiçados.
O que eu gostaria de ver é uma abordagem sistemática para o ambiente Linux e Windows. Como configurar o espaço para que a equipe sysadmin seria lembrado sobre o risco de dificultar o desempenho do principal db / app? Ou, melhor ainda, ser protegido desse risco? A típica situação que vem à minha mente é "ah, eu tenho esse arquivo zip muito grande, onde eu descompacte? Umm, vamos ver o df -h e descobrir algo em um instante ..." Eu não coloco ênfase no rigor da segurança (os administradores confiam em agir de boa fé), mas na simplicidade geral da abordagem.
Para o Linux, seria ótimo ter um sistema de arquivos personalizado para limitar a taxa de E / S a um nível muito baixo - isso é possível?
LUNs , partições e apresentação seletiva de recursos ...
O fato de uma SAN ser suportada por 16 eixos de disco não significa que o servidor que está consumindo esses dados precisa ver a capacidade total da matriz. Mesma coisa com armazenamento anexado diretamente. Há momentos em que posso ter um grande número de discos em uma matriz, mas ainda vou dimensionar corretamente o LUN / partição / dispositivo apresentado ao sistema operacional.
O exemplo abaixo de um controlador HP ProLiant SmartArray mostra 4 x SSDs de 480 GB em uma matriz RAID 1 + 0. Isso é 960GB utilizável. Eu esculpi um LUN de 400GB desses 960GB. O sistema operacional só vê 400 GB. E até mesmo esses 400 GB são particionados em partes lógicas que fazem sentido para o aplicativo. O ponto é que você pode controlar o que os consumidores do espaço de armazenamento veem:
array B (Solid State SATA, Unused Space: 1012121 MB)
logicaldrive 3 (400.0 GB, RAID 1+0, OK)
physicaldrive 1I:1:3 (port 1I:box 1:bay 3, Solid State SATA, 480.1 GB, OK)
physicaldrive 1I:1:4 (port 1I:box 1:bay 4, Solid State SATA, 480.1 GB, OK)
physicaldrive 2I:1:7 (port 2I:box 1:bay 7, Solid State SATA, 480.1 GB, OK)
physicaldrive 2I:1:8 (port 2I:box 1:bay 8, Solid State SATA, 480.1 GB, OK)
Mas, no final, se o desempenho atender às suas necessidades e a organização puder arcar com a configuração atual, por que você considera o espaço não utilizado como "desperdiçado"?
BTW - É possível acelerar o I / O no Linux em um nível de dispositivo de bloco using cgroups . Mas se houver um risco para seus principais aplicativos ou bancos de dados, por que não separar as cargas de trabalho?
Tags storage best-practices