Qual agendador alterar no LVM para beneficiar as máquinas virtuais

5

Quando você tem o LVM, você tem uma entrada para um planejador em /sys/block para seus volumes físicos, mas também para cada volume lógico individual e o dispositivo bruto.

Nós temos um sistema kernel 6 LTS x64, kernel 2.6.32 rodando o Xen hypervisor 4.0 (RAID1 de hardware 3Ware 9650 SE). Ao executar máquinas virtuais em cada volume lógico, em qual você precisa definir o agendador se você quiser influenciar como eles são agendados pelo sistema operacional? Se você definir o volume lógico como deadline , isso fará alguma coisa quando o volume físico estiver definido como cfq ? E se você definir o prazo no volume lógico, esses prazos serão respeitados mesmo quando o disco estiver desacelerando devido a IO em outros LVs que estão definidos como cfq ?

A pergunta refere-se ao IO em VMs que diminuem muito a velocidade de outras VMs. Todos os hóspedes usam noop como agendador internamente.

Editar: de acordo com this , em um ambiente multipath, somente o agendador do DM entrará em vigor. Então, se eu quiser lidar com IO entre máquinas virtuais em deadline , eu tenho que definir o caminho DM do volume físico (dm-1 no meu caso) para deadline . Isso esta certo? Existe também um agendador para o sdc, que é o dispositivo de bloco original do meu dm-1. Por que não não deve ser feito sobre isso?

edit2: mas então alguém diz nos comentários que o dm-0/1 não tem um agendador nos kernels mais novos:

famzah@VBox:~$ cat /sys/block/dm-0/queue/scheduler
none

No meu sistema (Debian 6, kernel 2.6.32), eu tenho:

cat /sys/block/dm-1/queue/scheduler 
noop anticipatory [deadline] cfq

A questão é também, eu tenho uma configuração multipath? pvs mostra:

# pvs
PV         VG                 Fmt  Attr PSize PFree
/dev/dm-0  universe           lvm2 a-   5,41t 3,98t
/dev/dm-1  alternate-universe lvm2 a-   1,82t 1,18t

Mas eles foram criados com / dev / sd [bc]. Isso significa que eu tenho multipath, mesmo sendo uma configuração padrão do LVM?

A questão principal, eu acho, é que eu tenho que definir o agendador em sdc ou dm-1? Se eu faço iostat, vejo muito acesso em ambos:

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sdc               0,00     0,00   13,02   25,36   902,71   735,56    42,68     0,08    2,17   0,73   2,79
dm-1             82,25    57,26   12,97   25,36   902,31   735,56    42,72     0,18    4,73   0,84   3,23

Então, o que é o que e quem é o chefe? Se for sdc, posso dizer que configurá-lo para prazo não faz nada para o desempenho das minhas VMs. Olhando para a diferença nas colunas "pedidos mesclados" (os dois primeiros), eu diria que é o dm-1 que controla o agendamento.

    
por Halfgaar 19.01.2015 / 10:52

3 respostas

2

Então, a resposta acabou sendo simplesmente: o dispositivo subjacente. Os kernels mais recentes só têm 'none' em /sys/block/*/queue/scheduler quando não há agendador para configurar.

No entanto, por um motivo desconhecido para mim, os dispositivos neste servidor são criados como dispositivos multipath, portanto, meu mexer com o agendador em /dev/sd[bc] nunca fez nada no passado. Agora eu defino dm-1 e dm-0 para prazo final com um read_expire=100 e write_expire=1500 (muito mais rigoroso que o normal) e os resultados parecem muito bons.

Este gráfico mostra o efeito na latência do disco em uma máquina virtual, causada por outra máquina virtual com uma tarefa por hora:

Você pode ver claramente o momento em que alterei os parâmetros do agendador.

    
por 20.01.2015 / 07:30
1

Hmm, Debian ...

Bem, posso compartilhar como o Redhat aborda isso com seus ajustados estrutura . Existem perfis para "virtual-host" e "virtual-guest". As descrições de perfil são explicadas em detalhes aqui , e o trecho a seguir mostra quais dispositivos são afetados. Os dispositivos "dm- *" e "sdX" têm seus agendadores alterados.

# This is the I/O scheduler ktune will use.  This will *not* override anything
# explicitly set on the kernel command line, nor will it change the scheduler
# for any block device that is using a non-default scheduler when ktune starts.
# You should probably leave this on "deadline", but "as", "cfq", and "noop" are
# also legal values.  Comment this out to prevent ktune from changing I/O
# scheduler settings. 
ELEVATOR="deadline"

# These are the devices, that should be tuned with the ELEVATOR 
ELEVATOR_TUNE_DEVS="/sys/block/{sd,cciss,dm-,vd,zd}*/queue/scheduler"

Veja também: CentOS Tuned Equivalent For Debian e Entendendo os perfis ajustados recomendados do RedHat

    
por 19.01.2015 / 13:47
0

como vmware recomenda, é melhor usar o noop scheduler, se o seu convidado estiver usando o arquivo como virtualdisk, desta forma seu convidado passe o IO diretamente para o seu host sem reorganizar o IO duas vezes no seu guest e no seu host físico

    
por 19.01.2015 / 14:03

Tags