Estou configurando matrizes RAID para um servidor HP Proliant que executa o Windows Server 2008. Provavelmente usaremos configurações RAID10, mas as dividiremos em várias unidades lógicas.
É razoável criar uma única unidade lógica RAID 0 dedicada apenas para o arquivo de troca?
[Editar]
Aqui está a nossa informação do sistema:
- HP Proliant ML350 G6
- 1x Intel Xeon E5520 4 núcleos
- 6 GB de RAM PC3 UDIMM
- Controlador RAID P410i HW + 512 MB BBWC
- 4x SATA de 1,5 TB
- Windows Server 2008 R2 Enterprise
[Editar2]
Ok, no final percebi que estava falando bobagem.
Como eu planejava usar RAID10 para esses 4 discos de qualquer maneira (velocidade de gravação 2x, velocidade de leitura 4x), percebi que não parecia justificado fazer uma pequena partição RAID0 para o benefício relativamente pequeno que recebo (escrever 4x , leia 4x) comparado com a bagunça que acabaria se um dos meus discos morresse.
Minha ideia foi algo assim:
Matriz RAID - : 4x1,5Tb.
- 1º disco lógico: 4x16Gb RAID0 para troca
- 2º disco lógico: RAID10 4x1.3Tb para todo o resto
Depois de criar uma matriz a partir desses quatro discos físicos, o HP P410i permite a criação de várias configurações de RAID, que podem ser utilizadas parcialmente.
Não importa, vou simplesmente usar o RAID10 e ter uma máquina razoavelmente rápida, mas muito mais segura.
[Atualize alguns anos depois]
Encontrei essa pergunta há muito tempo e decidi atualizá-la, caso alguém tenha um dilema similar: no final, simplesmente optamos pelo RAID10 e atualizamos nossa RAM para 32 GB. Com os preços de RAM atualmente, você simplesmente não deve permitir que o servidor toque no arquivo de paginação. Além disso, se você quiser uma resposta incrivelmente rápida, usar alguns SSDs corporativos também não é uma despesa tão grande como costumava ser.
Uma conclusão adicional que temos é que, se você precisar de mais armazenamento, pode fazer sentido usar SSDs menores em seu servidor e usar uma SAN para armazenamento de dados real. Em algum momento, a capacidade de armazenamento do servidor atingirá seus limites de expansão, por isso é melhor ter isso em mente e projetar seu sistema para escalabilidade.