KVM e scheduler Linux

[DonChisciotte]

salve, in questo thread riguardante la soluzione di cloud computing adottata da Seeweb, Antonio ha mosso l'obiezione sull'utilizzo di KVM, in quanto non e' possibile assegnare una quota cpu alla singola vm.

ecco la risposta datami da Antonio, e spero di aver fatto bene ad aprire un nuovo thread per non andare - forse - off-topic in quell'altro.

Ciao,

KVM utilizza lo scheduler del kernel linux per gestire le VM (ogni vm è vista come un processo a se stante); se ci sono più VM che core a disposizione avrai ovviamente 1 core assegnato a 2 o più VM e, purtroppo, non avrai fair share delle CPU da parte delle VM (e non è possibile neanche assegnare XX% di CPU a VM).

E' un pò come se le vm si rubassero cicli cpu a vicenda, questo significa che se hai 2VM su una cpu ed una di queste si appropria della CPU per calcoli intensivi, all'altra VM non resta che aspettare e sperare che la prima VM diminuisca l'uso della CPU.

Seeweb ha aggirato il problema non facendo overbooking della CPU, quindi presumibilmente si avranno ad esempio 8VM su un server octacore

EDIT: naturalmente con xen e vmware ciò non accade perché è il virtualizzatore che gestisce CPU, ram e quant'altro (con maggiore overhead rispetto a kvm, come è logico attendersi). Ci vorrebbe uno scheduler per il kernel linux fatto appositamente per essere usato con KVM, ma non mi sembra ci sia una cosa del genere attualmente (mi piacerebbe essere smentito se qualcuno sa qualcosa ).

Giusto per far capire che non sono io paranoico:

CFS Optimizations to KVM Threads on Multi-Core Environment

Conferenza di metà dicembre 2009 che tratta il problema e spiega che con KVM non è che sia molto fair lo scheduler linux (in realtà il fatto è che trattando le vm come normali processi sorgono diversi problemi)

non conosco approfonditamente lo scheduling del kernel, ma credo che esso sia in grado di gestire attraverso le priorita' dei processi i cicli di cpu da assegnare ad ogni singola vm (ovvero ad ogni singolo processo). certo, non potendo assegnare un valore fisso di quota cpu alla singola vm, puo' succedere che una di esse prenda il 100% della cpu, ma se succede e' perche' gli altri processi non fanno richiesta di cicli cpu.
nel caso in cui un'altra vm richieda cicli di cpu, lo scheduler si dovra' occupare di gestire nel modo piu' equo possibile le risorse, gestione che si puo' fare anche "giocando" con le priorita' dei processi per far assegnare piu' o meno cicli a seconda delle necessita'.

facendo una domanda banale: perche' vuoi limitare una vm se le altre non fanno niente, considerato che se vengono richiesti lo scheduler si preoccupa di assegnare correttamente le risorse?
inoltre, l'overhead introdotto dagli scheduler "interni" di xen o vmware quanto impatta prestazionalmente rispetto a kvm?

[Antonio]

salve, in questo thread riguardante la soluzione di cloud computing adottata da Seeweb, Antonio ha mosso l'obiezione sull'utilizzo di KVM, in quanto non e' possibile assegnare una quota cpu alla singola vm.

Nel caso di Seeweb ciò è ininfluente perché dicono di assegnare un core ad ogni vm (ed io giurerei che lo fanno anche per aggirare quanto detto il precedenza )

non conosco approfonditamente lo scheduling del kernel, ma credo che esso sia in grado di gestire attraverso le priorita' dei processi i cicli di cpu da assegnare ad ogni singola vm (ovvero ad ogni singolo processo). certo, non potendo assegnare un valore fisso di quota cpu alla singola vm, puo' succedere che una di esse prenda il 100% della cpu, ma se succede e' perche' gli altri processi non fanno richiesta di cicli cpu.
nel caso in cui un'altra vm richieda cicli di cpu, lo scheduler si dovra' occupare di gestire nel modo piu' equo possibile le risorse, gestione che si puo' fare anche "giocando" con le priorita' dei processi per far assegnare piu' o meno cicli a seconda delle necessita'.

facendo una domanda banale: perche' vuoi limitare una vm se le altre non fanno niente, considerato che se vengono richiesti lo scheduler si preoccupa di assegnare correttamente le risorse?
inoltre, l'overhead introdotto dagli scheduler "interni" di xen o vmware quanto impatta prestazionalmente rispetto a kvm?

Andiamo per gradi, per spiegare un pò come stan le cose devo annoiarti/vi 30 secondi con la spiegazione di come si è avoluto lo scheduler linux.

Prima del kernel 2.6.23 lo scheduler usato di default era lo scheduler a priorità (a secoda della priorità del processo e dei quanti di tempo man mano usati dal processo lo stesso veniva inserito in una determinata coda) con aging (i processi che sono da molto tempo in attesa di usare la cpu col passare del tempo aumentano la loro priorità per evitare che essi siano perennemente in coda in attesa del loro quanto di tempo). Questo algoritmo di scheduling, di complessità O(1), che per i server può andare bene, per i desktop può penalizzare i processi interattivi e quindi si è deciso di cambiarlo.

Negli ultimi tempi nella community linux c'erano 2 scheduler che venivano sviluppati per sostituire lo scheduler a priorità: scheduler RSDL e CFS.

• Per farla semplice lo scheduler RSDL usa le code multilivello con feedback (multilevel feedback queue per chi volesse approfondire) che cercava di organizzare i processi in maniera tale da favorire quelli che fanno molto I/O (dato che questi ultimi spesso si sospendono da soli per eseguire I/O call [scrivere su disco, leggere i dati da tastiera etc etc], non utilizzano tutto il quanto di tempo a loro dedicato e quindi non vengono reinseriti nelle code dei processi a priorità minore) o che portano a termine i propri task in poco tempo, mentre i task CPU-bound (non sospendendosi o terminando i propri task nel quanto di tempo prefissato) vengono penalizzati e posti nelle code a minore priorità. Questo scheduler è ottimo per i sistemi interattivi, dove è importante la reattività del sistema e si da per scontato che i processi CPU-bound siano processi batch (e quindi "sacrificabili").

Questo scheduler è stato proposto da Con Kolivas (chi è avvezzo alla compilazione del kernel linux avrà sicuramente sentito parlare delle patch "-ck" )

• Lo scheduler CFS (Completely Fair Scheduler), poi scelto da Torvalds con grande disappunto di molti, non utilizza più le code di proccessi ma un albero RB (red-black tree). L'algoritmo non ha più complessità O(1) ma O(log n) (n=numero di processi nell'albero), quindi all'aumentare del numero dei processi in esecuzione aumenta il tempo necessario per effettuare lo scheduling.L'algoritmo alla base del CFS cerca di mantenere un’equa distribuzione del tempo a tutti i processi; nel caso in cui uno o più processi non ricevono la loro giusta parte di tempo macchina allora l’algoritmo ribilancia l'albero dando a suddetti processi la possibilità di essere eseguiti. Per effettuare il bilanciamento vengono mantenute le informazioni sul tempo processore utilizzato e sul tempo in attesa di input/output.
  Il CFS elimina la distinzione fra processi interattivi e non, ciò che importa ai fini del suo utilizzo sono solo il momento in cui un processo arriva ad ottenere la CPU e quanto velocemente lo scheduler effettua lo switch fra processi. Quest’ultimo valore, detto granularità, é variabile: se basso, lo switch avviene frequentemente, situazione ideale per sistemi interattivi, se alto , lo switch è meno frequente e il sistema avrà un comportamento da server.
  Per altre info potete dare una occhiata a http://people.redhat.com/mingo/cfs-s...design-CFS.txt

Con lo scheduler CFS in teoria sembrerebbero risolti i problemi per le vitual machine che fanno uso di kvm, dato che lo scheduler dovrebbe assicurare quantomeno pari utilizzo della cpu ai vari processi-VM di KVM (quindi comunque non è possibile assegnare un limite minimo o massimo di CPU utilizzabile da una vm). Il problema sorge a causa dei meccanismi di allocazione dei thread e di blocco eseguiti all'interno delle virtual machine che possono far crollare le prestazioni delle VM che fanno uso di kvm.

Per evitare questo problema si devono ridurre al minimo i context switch, seeweb lo ha fatto decidendo di non effettuare overbooking delle CPU (uno spreco di risorse, ma per l'utente questo dovrebbe essere un vantaggio ).

Mi scuso per lo sproloquio, anche se ho cercato di essere quanto più sintetico possibile.

PS: provate voi stessi a far girare 3-4VM con software di benchmark su un server con processore dual core e vedrete le differenze usando KVM e XEN o VMWARE

[Stoned]

Mi scuso per lo sproloquio, anche se ho cercato di essere quanto più sintetico possibile.

Altro che "scusarsi": magari fossero tutti così gli interventi
Grazie per la precisa spiegazione

[Antonio]

Altro che "scusarsi": magari fossero tutti così gli interventi
Grazie per la precisa spiegazione

Prego

Anche se, rileggendo la risposta, mi accorgo che non è scritta nel migliore dei modi; purtroppo, però, per rispondere a DonChisciotte, dovevo necessariamente mettere "molta carne a cuocere"

[gnu]

Scusate ma sono disperato. Sto lavorando su una SL5.5 e ho seri problemi di performance dei dischi logici su vm windows anche usando i driver virtio. Ho cercato di far migliorare le cose anche lavorando sugli scheduler ma le mie prestazioni reali su dischi da 200MB/s vanno appena da 8 a 20 MB/s. Potete darmi qualsche consiglio in merito? Scusate se non è molto pertinente con la discussione ma dopo giorni che giro voi mi sembrate i più ferrati. Grazie a tutti.

[valent]

Ben due anni fa, ho intuito lo stesso problema evidenziato. Se Xen utilizza un suo scheduler per distribuire il tempo cpu fra le macchine virtuali in modo omogeneo esempio circa 1/n dove n è il numero di macchine virtuali, Kernel-based VM utilizza quello della distribuzione di Linux dove è installato. Tempo fa avevo per questo motivo scelto Xen a KVM.
Qui potete leggere alcune mie considerazioni sulla questione: KVM vs Xen non si tratta di un discorso completo ma per i tempi in cui l'ho svolto era sufficiente