Por que o open-iscsi escreve duas vezes mais lentamente que o Samba via Ethernet 10G?

No meu servidor de arquivos local, tenho o raid-6 em unidades de disco rígido 7x.

dd if=/dev/zero of=tempfile bs=1M count=2048 conv=fdatasync

O teste de velocidade local fornece uma velocidade de gravação de 349 MB / s.

As gravações remotas no Samba a partir do SSD (> velocidade de leitura de 2 Gb / s) me proporcionam gravações de 259 MB / s. Porém, as gravações remotas na unidade iSCSI (no iniciador iSCSI Win10) me proporcionam meras gravações de 151 Mb / s.

configuração do raid6 - tamanho do pedaço de 128K, stripe_cache_size = 8191. O bitmap com intenção de gravação está no SSD (Samsung 860 PRO, pedaço de bitmap de 4096K).

Matriz montada com opções: rw,noatime,nobarrier,commit=999,stripe=128,data=writeback

Configuração do open-iscsi: o destino é baseado em um arquivo de 4 TB.

Alguma dica de por que o iSCSI é mais lento que o Samba nas gravações? Alguma dica sobre como melhorar a velocidade de gravação iSCSI?

Suponho que tenha algo a ver com o desejo do open-iscsi de liberar gravações no disco após cada operação, o que aumenta a amplificação de gravação no RAID6 devido a excessivas reescritas de paridade. Mas não sei como corrigi-lo. Acelere mais do que a segurança dos dados atualmente gravados em caso de falta de energia.

Como observação lateral, o destino ietd iSCSI mais antigo tinha a capacidade de ativar o modo de write-back (usando IOMode=wb) e a velocidade de gravação sustentada era muito mais rápida. Infelizmente, parece não ter manutenção no momento.

Primeiro de tudo, o RAID-6 é o problema devido ao cálculo de dupla paridade. Em segundo lugar, você pode conectar o destino iSCSI duas vezes no MS iSCSI Initiator, ativar RR ou menos profundidade da fila (infelizmente, o Win10 não oferece suporte a caminhos múltiplos, para testá-lo no Windows Server).

De fato, o acesso no nível do bloco deve ser mais rápido que o acesso no nível do arquivo. Que tipo de ferramenta de benchmarking você está usando no site do Windows? Eu recomendaria usar o diskspd ou o FIO. Além disso, você pode usar algo como Starwind como um destino iSCSI muito mais rápido.

https://www.starwindsoftware.com/starwind-virtual-san#Hyper-V

O iSCSI deve ser usado no nível do bloco; sua descrição da configuração parece que você está usando um sistema de arquivos, colocando um arquivo nele e, em seguida, executando esse arquivo como camada de bloco iSCSI.

Isso está longe de ser ideal e definitivamente não é uma configuração para comparar velocidades. Tente usar o lvm na parte superior do raid6 para segmentar o espaço e permanecer na camada de blocos do iSCSI ou use o raid6 diretamente como dispositivo iSCSI.

Na sua configuração atual, os dados são transferidos pela rede, atingindo um arquivo no sistema de arquivos, o qual (provavelmente) não é otimizado para esse tipo de carga de trabalho e também é compartilhado com outros processos. É possível fazer essa configuração com o iSCSI, mas deve ser considerada uma solução de fallback não otimizada.

Esteja ciente de que ddé uma referência muito simples e muito propensa a distorções. Por exemplo, você ddestá escrevendo zeros - se algo tiver um caso especial para dados cheios de zeros (por exemplo, porque pode fazer compressão), você verá um desempenho fantástico, mas passará a gravar "dados reais" diferentes de zero e, de repente, esse desempenho poderá desaparecer. ..

Para responder sua pergunta (como em todos os testes de referência), você realmente precisa isolar as peças para identificar o pouco que está introduzindo o problema. Por exemplo, a gravação diretamente no sistema de arquivos do Windows (e não no iSCSI) também é extremamente rápida? Se você usa a mesma configuração de hardware e executa o Linux em vez do Windows, é tão rápido ou mais lento? O que acontece se você mudar para o uso de uma ferramenta de benchmark como o fio ?

Infelizmente, existem muitas possibilidades para responder bem a uma pergunta como essa ...