Unidades lógicas Muliplte em um único EVA

Question

A prática recomendada do SQL Server recomenda unidades separadas para os dados e arquivos de log. Você realmente obtém um aumento de velocidade se ambas as unidades lógicas estiverem localizadas no mesmo EVA?

    

Answer 1

Ah - apenas minha área de especialização!

As 'melhores práticas' do SQL assumem que você usa um disco físico separado para os dados e registra sim, mas isso é em um servidor com discos físicos conectados localmente ou por métodos SAN tradicionais em que um LUN era apenas parte de um único disco SAN. Os EVAs são muito diferentes disso.

Dependendo do modelo que você tiver, qualquer LUN será distribuído em um MÍNIMO de oito discos físicos; se for um P6xxx, isso pode ser 12 ou mais, apenas para começar. Então, se você tiver seu log espalhado em um grupo de oito ou mais discos e seus dados se espalharem por outros oito ou mais, obviamente você verá um desempenho muito melhor do que se esses mesmos dados estivessem em apenas dois discos. Tendo em conta que esta é a configuração de menor desempenho e você pode realmente ver melhor desempenho devido à divulgação mais ampla, eu acho que você vai concordar que esta 'melhor prática' vai para o inferno com EVAs.

Basicamente, basta cortá-los do maior Grupo de Discos possível (você realmente quer o mesmo tipo / velocidade de discos em DGs únicos) e deixar que o EVA se preocupe com o resto. Eu executo muitos clusters MSSQL em várias caixas EVA / P6xxx / 3Par e realmente não há necessidade de ficar muito específico na composição do LUN nos dias de hoje com matrizes SAN mais antigas.

    

Answer 2

Possivelmente, sim ... o enfileiramento por dispositivo em bloco é uma área distinta que pode se beneficiar da separação, mesmo quando for para o mesmo grupo físico de discos.

    

Answer 3

Concordo totalmente com o Chopper3. A separação teórica do disco de arquivos / logs do banco de dados por desempenho que você fez para os antigos JBODs já passou.

Um EVA com um grande grupo de discos (bastantes fusos) é tudo o que você precisa.

Além disso, se você realmente observar o que o SQL Server ou Oracle, no nível do hardware, a quantidade de E / S de disco nos arquivos de banco de dados pode ser amplamente negada por ter muita RAM. Logs, sim, eles ainda escrevem sequencialmente; Apenas certifique-se de ter seus limites de rolagem de log definidos para corresponder à sua taxa de transação.

Nós executamos algumas instâncias do Oracle de tamanho moderado (300 GB) no VMware, rodando em EVAs. Isso adiciona outra camada de abstração; ou seja:

Volumes O / S (NTFS) - > Arquivos VMware VMDK - > Armazenamento de dados VMware (sistema de arquivos VMFS) - > EVA vDisk (LUN) com seu nível de vRAID associado - > Grupo de discos EVA - > Unidade FC / AL física

Então, se você pedisse a um cientista da computação para localizar o bloco de disco contendo o bloco de banco de dados, para aplicar algumas recomendações de otimização, ele ou ela simplesmente encolhia os ombros.

    

Answer 4

Geralmente, em armazenamento antigo que possui invasões específicas para volumes específicos, eles recomendam manter os registros e os dados em invasões diferentes. Atualmente, a maioria dos armazenamentos é instalada com pools que abrangem todo o IO em grandes grupos de discos. Em um pool grande, não há necessidade de evitar logs e dados para qualquer banco de dados nos mesmos discos, mas eu ainda recomendaria mantê-los em volumes diferentes pelos motivos mencionados por ewwhite em sua resposta (contenção de fila).