[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kvm | shared san storage



On Wed, May 04, 2016 at 09:57:34AM +0200, Paul van der Vlis wrote:
> Op 04-05-16 om 07:21 schreef Wouter Verhelst:
> > Omdat je er expliciet naar vraagt (en omdat ik zelf de
> > reference-implementatie ervan beheer): nbd wordt meer en meer het
> > "standaard" protocol voor virtualisatie-storage onder Linux. Dit heeft
> > te maken met het feit dat qemu tegenwoordig goede builtin ondersteuning
> > heeft voor nbd (zowel client als server); libvirt is dan ook zinnens om
> > bv live-migratie via nbd te laten lopen. Sinds een jaar ofzo is er ook
> > een spec voor STARTTLS binnen NBD, die in de soon-to-be-released qemu
> > 2.6 geïmplementeerd is en beschikbaar zal zijn als eerste implementatie.
> 
> Heel fraai!
> 
> > Ik heb, puur uit interesse, afgelopen weekend ook eens een paar
> > benchmarks gedraaid (AoE vs iSCSI vs NBD, alles over 1GigE tussen
> > dezelfde client en server), en daaruit had ik het gevoel dat NBD niet
> > hoeft onder te doen (qua performance) tov de andere twee. Details zet ik
> > later nog op mijn blog.
> 
> Ik vond in het verleden wel dat NBD traag was, of kon zijn.
> Weet je ook wanneer die problemen zijn opgelost?

"Traag" is, uiteraard, subjectief.

Ik heb voor nbd 3.13 (de meest recente release, zit nog niet in stable)
een thread pool toegevoegd, waardoor requests nu in parallel afgehandeld
kunnen worden. Voordien was dat sequentiëel. Dat heeft er mogelijk mee
te maken.

Het protocol an sich is echter altijd in staat geweest om parallel te
werken, en andere implementaties (o.a. qemu) hebben dat lang gedaan.

> > Qua configuratie is iSCSI wel een ramp. Veel complexer dan noodzakelijk;
> > duidelijk een geval van "design by committee". 
> 
> Als je weet hoe het moet, is (bijna) alles simpel ;-)

Mja, maar zelfs dan nog is iSCSI overdreven.

Je maakt eerst een target aan met een naam die (als je het volgens de
regels van de kunst doet) ofwel belachelijk verbose is (IQN), ofwel
belachelijk onleesbaar (EUI).

Dan maak je een LUN aan, waarbij de grootte van het device *verplicht*
een veelvoud van de block size moet zijn (anders werkt de boel niet)

Dan moet je client-side eerst discovery doen op de host waarmee je wilt
verbinden, de target kiezen op die host, en dan de LUN. En als je tussen
de discovery van de beschikbare targets een wijziging doet target-side,
dan wordt de discovery ook niet automatisch geüpdated enzo.

Beetje belachelijk allemaal, IMO.

NBD daarentegen is "maak export aan, HUP server, done". Client-side heb
je (optioneel) nbd-client -l om de namen te zien. Je kan daarbij
eventueel je eigen naming scheme gebruiken, maar in sé houdt het NBD
protocol zich niet zo geweldig bezig met het controleren van namen; het
enige wat het protocol zegt is dat de naam UTF-8 moet zijn en een
maximum lengte heeft. Block devices mogen gelijk welke grootte zijn
(hoewel ze naar beneden afgerond zullen worden op de block size).

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12


Reply to: