Responderei em duas partes: primeiro "por que a resposta tradicional sobre a separação seqüencial e aleatória geralmente não se aplica".
Depois, discutirei os possíveis benefícios da separação de arquivos no disco físico do Windows, além de adicionar vHBAs adicionais e distribuir os discos físicos entre eles.
Esperar o benefício da separação de E / S de disco aleatória e seqüencial no nível do disco físico do Windows normalmente assume dispositivos HDD para o armazenamento de dados. Também supõe que discos físicos separados do Windows significam dispositivos de disco rígido separados. A idéia é que algum conjunto de HDDs esteja lidando principalmente com E / S de disco sequencial e tenha movimento muito limitado da cabeça do disco (por exemplo, os HDDs que hospedam um único txlog ocupado *) enquanto um conjunto separado de HDDs está lidando com E / S aleatória de disco.
Essas suposições raramente são válidas atualmente - especialmente em uma VM. Primeiro, a menos que os discos físicos do Windows das VMs sejam RDMs, vários deles podem estar em um único armazenamento de dados - ou talvez vários armazenamentos de dados estejam em um único LUN host do ESXi. Portanto, o que está separado no convidado pode ser misturado no nível do host ESXi.
Mas digamos que os RDMs sejam usados ou que cada disco físico convidado esteja em seu próprio armazenamento de dados, em seu próprio ESXi LUN. Mesmo assim, o io sequencial e aleatório separado no convidado é frequentemente misturado na matriz, porque os LUNs apresentados ao host ESXi podem ser do mesmo conjunto único de dispositivos de disco. Quase todas as matrizes de armazenamento fazem isso agora - exclusivamente ou como uma opção para facilitar o gerenciamento e aumentar a eficiência / utilização dos recursos da matriz.
Finalmente, hoje em dia, tanto armazenamento é todo flash ou híbrido + disco rígido. Sem se preocupar com o movimento da cabeça, o flash não se preocupa com a separação sequencial aleatória ... nem se importa com a tecelagem de IO.
Então ... essas são todas as razões que separam o seqüencial do aleatório podem não ser tão benéficas. A seguir, por que a distribuição de arquivos entre discos físicos e a distribuição de discos físicos entre vHBAs ainda pode aumentar o desempenho de qualquer maneira.
* Mencionei propositadamente um único log de transações neste exemplo de disco rígido. Quando vários fluxos de E / S de disco sequenciais separados (por exemplo, 8 logs de transação ocupados) estão ocorrendo nos mesmos HDDs - a menos que de alguma forma quase toda a atividade esteja dentro do cache da SAN - o movimento constante da cabeça entre as trilhas de E / S sequenciais leva à tecelagem de E / S. Esse é um tipo específico de debulhar a cabeça do disco, o que leva à latência do disco que é "pior que aleatória". Acontece no RAID5 e RAID10, embora o RAID10 possa tolerar um pouco mais de variação nesse aspecto do que o RAID5 antes de uma degradação significativa.
Agora - considerando essa conversa demorada sobre como separar seqüencial e aleatório pode não ajudar - como a disseminação de arquivos entre discos físicos ainda ajuda? Como a distribuição de discos físicos entre vHBAs pode ajudar?
É tudo sobre filas de E / S de disco.
Qualquer disco físico do Windows ou LogicalDisk pode ter até 255 E / S de disco pendentes por vez no que é relatado pela perfmon como "Fila de disco atual". Nas E / S de disco pendentes na fila do disco físico, o storport pode passar até 254 para o minidriver. Mas o minidriver também pode ter uma fila de serviço (passada para o próximo nível inferior) e uma fila de espera. E o storport pode ser instruído a diminuir o número que passa de 254.
Em um convidado do VMware Windows, o driver pvscsi possui uma profundidade de fila padrão de "dispositivo" de 64, em que o dispositivo é um disco físico. Portanto, embora o perfmon possa mostrar até 255 E / S de disco no "tamanho atual da fila de disco" para um único disco físico, apenas 64 deles serão passados para o próximo nível por vez (a menos que os padrões sejam alterados).
Quantos E / S de disco podem ser excelentes para umlog de transações ocupadas por vez? Bem, as gravações no log de transações podem ter até 60kb de tamanho. Durante um ETL de alta escala, frequentemente verei todas as gravações no txlog em 60kb. O gravador txlog pode ter até 32 gravações de 60kb pendentes para um txlog por vez. E se eu tiver um txlog temporário ocupado e um dw txlog ocupado no mesmo disco físico, com as configurações padrão do VMware? Se os dois txlogs atingirem o máximo de 32 gravações pendentes de 60kb cada, esse disco físico estará na sua profundidade de fila de 64. Agora ... e se houver também arquivos simples como uma fonte ETL no disco físico? Bem ... entre as leituras dos arquivos simples e as gravações do txlog, eles teriam que usar a fila de espera, porque apenas 64 podem sair por vez. Para bancos de dados com txlogs ocupados como esse, seja servidor físico ou virtual, recomendo o txlog em seu próprio disco físico, com mais nada no disco físico. Isso evita filas nesse nível e também elimina qualquer preocupação com o conteúdo da intercalação de vários arquivos (que é uma preocupação muito, muito menor nos dias de hoje).
Quantas E / S de disco podem ser destacadas em um arquivo de linha por vez (da perspectiva do SQL Server, não necessariamente submetidas a níveis mais baixos)? Não há realmente um limite no próprio SQL Server (que eu encontrei, de qualquer maneira). Mas, supondo que o arquivo está em um único disco físico do Windows (eu não recomendo o uso de discos dinâmicos listrado por SQL Server, isso é assunto para outra altura), não é um limite. É o 255 que eu mencionei antes.
Com a mágica do readahead do SQL Server e da E / S assíncrona, vi quatro consultas simultâneas, cada uma executando na unidade serial, com um "comprimento atual da fila de disco atual" de mais de 1200! Por causa do limite 255, isso nem é possível com todo o conteúdo do arquivo de linha em um único disco físico. Era contra um grupo de arquivos primário com 8 arquivos, cada um no próprio disco físico.
Portanto, as leituras de readahead podem ser muito agressivas e estressar as filas de E / S. Eles podem ser tão agressivos que outras leituras e gravações de arquivos de linha acabam esperando. Se os logs de transações estiverem no mesmo disco físico dos arquivos de linha, durante as leituras simultâneas de leitura à cabeça e gravações no txlog, é muito fácil aguardar a ocorrência. Mesmo que essa espera não esteja no nível "tamanho da fila de disco atual", ela pode estar esperando na fila do dispositivo (64 por padrão com pvscsi).
As leituras de backup em arquivos de linha também podem ser agressivas, especialmente se a contagem de buffer tiver sido ajustada para maximizar a taxa de transferência do backup.
Há mais um tipo de SQL Server io a considerar ao considerar o isolamento de txlogs: derramamento de consulta no tempdb. Quando o derramamento de consulta ocorre, cada trabalho derramado é gravado no tempdb. Tem muitos trabalhadores paralelos espalhados ao mesmo tempo? Isso pode ser uma carga de gravação. Manter um txlog ocupado e arquivos de linha importantes longe disso pode ser realmente útil :-)
Agora, é possível alterar a profundidade da fila do dispositivo padrão para o driver pvscsi. O padrão é 64 e pode ser definido como 254, que é o maior armazenamento armazenado. Mas tenha cuidado ao mudar isso. Eu sempre recomendo alinhar a profundidade da fila do dispositivo convidado com a profundidade da fila LUN do host ESXi subjacente. E definindo a profundidade da fila do LUN do host ESXi por práticas recomendadas da matriz. Usando um EMC VNX? A profundidade da fila do host LUN deve ser 32. O convidado usa RDMs? Ótimo. Defina a profundidade da fila do dispositivo convidado pvscsi como 32 para que fique alinhada com a profundidade da fila do LUN do host do ESXi. EMC VMAX? Normalmente, 64 no nível do host ESXi, 64 no convidado. Pure / Xtremio / IBM FlashSystem? Às vezes, a profundidade da fila do LUN do host é definida como 256! Vá em frente e defina a profundidade da fila do dispositivo pvscsi como 254 (máximo possível).
Aqui está um link com instruções.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
O link também fala sobre requestringpages - WhatAreThose ?? Eles determinam a profundidade da fila para o próprio adaptador pvscsi. Cada página fornece 32 slots na profundidade da fila do adaptador. Por padrão, requestringpages é 8 para uma profundidade da fila do adaptador de 256. Ele pode ser configurado como 32 para slots de profundidade da fila do adaptador 1024.
Digamos que tudo esteja no padrão. Eu tenho 8 discos físicos com arquivos de linha e o SQL Server está um pouco ocupado. Há uma média de 32 "comprimento da fila de disco atual" nos 8 e nenhum é maior que 64 (tudo se encaixa nas várias filas de serviço do dispositivo). Ótimo - isso dá 256 OIO. Ele se encaixa nas filas de serviço do dispositivo, na fila de serviço do adaptador, para que todos os 256 saiam do convidado para as filas no nível do host ESX.
Mas… se as coisas ficarem um pouco mais ocupadas, uma média de 64 com a fila de alguns discos físicos chega a 128. Para os dispositivos com mais de 64 pendentes, o excesso está na fila de espera. Se mais de 256 estiverem na fila de serviço dos dispositivos nos 8 discos físicos, o excesso estará na fila de espera até que os slots na fila de serviço do adaptador sejam abertos.
Nesse caso, adicionar outro pvscsi vHBA e espalhar os discos físicos entre eles dobra a profundidade total da fila do adaptador para 512. Mais io pode ser transmitido do convidado para o host ao mesmo tempo.
Algo semelhante pode ser alcançado permanecendo em um adaptador pvscsi e aumentando as páginas solicitadas. Passar para 16 renderia 512 slots e 32 renderia 1024 slots.
Quando possível, eu recomendo ir além (adicionando adaptadores) antes de ir adiante (aumentando a profundidade da fila do adaptador). Mas ... em muitos dos sistemas mais movimentados, é necessário fazer as duas coisas: colocar 4 vHBAs no convidado e aumentar as páginas solicitadas para 32.
Existem muitas outras considerações também. Coisas como sioc e otimização da profundidade da fila adaptável se vmdks forem usados, configuração de caminhos múltiplos, configuração do adaptador ESXi além da profundidade da fila LUN, etc.
Mas não quero ficar mais do que bem-vindo :-)
Nina Niederstadt @Na_Nerderstadt