Como devo configurar a matriz RAID de unidades SSD no meu SQL Server?

Estou construindo um SQL Server com 48 GB de RAM, 1 CPU e 8 unidades SSD SATA III (6 GB / s) (128 GB Crucial m4) e um controlador LSI MegaRAID (SAS 9265-8i). Espero que a carga de trabalho típica seja principalmente de leitura. Haverá alguns períodos de atividade de gravação mais pesada (sincronização de dados por hora com provedores de dados de terceiros - backups noturnos), mas suspeito que a taxa de leitura / gravação típica seja de cerca de 90% das leituras / 10% das gravações.

Opção 1:
Unidade lógica C: - RAID 1 (2 unidades físicas) -
Unidade lógica do sistema operacional D: - RAID 10 (6 unidades físicas) - Arquivos / logs / tempdb / backups de banco de dados?

OU

Opção 2:
Unidade lógica C: - RAID 1 (2 unidades físicas) -
Unidade lógica do sistema operacional D: - RAID 1 (2 unidades físicas) - Arquivos Db
Unidade lógica E: - RAID 1 (2 unidades físicas) - arquivos de log / backups?
Unidade lógica F: - RAID 1 (2 unidades físicas) - tempdb

OU

Opção 3:
outras sugestões?

Estou pensando que a opção 1 me daria melhor desempenho, já que toda a atividade do banco de dados seria dividida em três unidades (e espelhada nas outras três da matriz), embora a opção 2 pareça imitar a sabedoria convencional (que parece se aplicar mais à mecânica). drives do que SSDs). Parece que o estouro de pilha foi com a opção 1 .

Suponho que, com os SSDs, não há problema em colocar tudo em uma única unidade lógica, já que seu servidor provavelmente tem mais CPU restrito do que E / S naquele momento?

Outra pergunta que tenho é onde devo colocar os backups noturnos? Não queremos que os backups diminuam a velocidade do restante do servidor SQL, e acho que escrever os backups no mesmo local dos logs é uma boa prática, porque o comportamento de leitura / gravação nos dois casos é gravado em seqüência.

A sabedoria convencional sobre o RAID não se aplica bem aos SSDs. Eles realmente não precisam de striping (RAID0). Eles são propensos a falhas por projeto, mas o RAID-1 geralmente não é a resposta certa para o SSD por dois motivos: a) é um desperdício, reduz pela metade a capacidade do conjunto de SSD (e são caros) e 2) leva às características de falha dos SSDs para que ambas as unidades no espelho falhem em intervalos muito próximos (isto é, falhas correlacionadas) e, assim, inutilizam toda a matriz. Consulte RAID diferencial: repensando o RAID para obter confiabilidade de SSD para uma discussão mais longa. Alguns recomendaram o uso do Raid-6 para SSDs.

Além disso, a sabedoria convencional do layout de arquivo do SQL Server não se aplica aos SSDs. Eu recomendo que você assista o SQL nos SSDs: Hot and Crazy Love e repasse os links de referência nesta resposta .

A abordagem padrão de separar os padrões aleatórios de E / S para dados do seqüencial de logs simplesmente não se aplica aos SSDs; portanto, eu escolheria sua opção 1 com ressalvas:

• Os backups DEVEM ser feitos em uma máquina separada. Há pouco sentido em ter backups que você não pode acessar no caso de o servidor ficar com fumaça.
• Existe algum valor em separar os dados e as unidades de log, de forma que uma falha na matriz de dados permita que você faça um backup do log.
• Esteja ciente de que você não tem um hot spare.
• Lembre-se de que você possui unidades de nível de consumidor. Não assuma que eles serão tão confiáveis ​​quanto os equivalentes da empresa a múltiplos custos.
• Assista ao SQL divertido e muito informativo sobre SSDs: Hot and Crazy Love, de Brent Ozar.

A questão da separação dos logs dos dados em que os SSDs são usados ​​é uma questão de RPO (objetivo do ponto de recuperação) para o sistema, e não de desempenho. Se o RPO for definido em minutos, vá com uma matriz compartilhada e faça backups de log a cada [RPO] minutos. Se o RPO for definido em segundos, vá com matrizes separadas.

Para ser honesto, se o RPO fosse restrito, eu manteria SSDs para a matriz de dados e usaria um par espelhado de giradores caros (corporativos) confiáveis ​​para o log.

Você deve ir com a opção 2 da seguinte maneira:

Logical Drive - RAID 1 (2 physical drives)
 1 partition C: OS
 2 partition D: backups / log files
Logical Drive E: - RAID 1 (2 physical drives) - DATA files
Logical Drive F: - RAID 1 (2 physical drives) - INDEX files
Logical Drive G: - RAID 1 (2 physical drives) - tempdb

Ao separar seus dados e seus índices em 2 arquivos de dados diferentes, que são armazenados em 2 unidades lógicas físicas diferentes, você obteria um grande aumento no disco io simplesmente porque, ao consultar, teria um disco girando para os dados da tabela e outro girando para o seu índice ao mesmo tempo.

Deixe o tempdb separado dos seus backups também, porque muitas coisas acontecem lá também. Não misture seus backups e seu arquivo de dados. mesmo que os backups não sejam feitos diariamente, quando ocorrem, eles sofrem muito com o seu pedido de veiculação. com base nos negócios e no uso do banco de dados, algumas pessoas ou MUITAS pessoas podem reclamar durante o tempo de backup.

Espero que isto ajude