Re: kvm | shared san storage
Ik had tot zeer recent een ontwikkel/test datacenter omgeving draaien op Xencenter met storage op een antiek iSCSI san. Om precies te zijn hebben we ons rack afgebroken/uitbesteed naar 'de cloud' en heb ik een tijdje wat test/ontwikkel servers gedraaid op servers die al uit de productie waren gehaald, tot alles uit productie was en het rack kon worden opgezegd. Het nadeel is dat de beheeromgeving op Windows draait, maar het dagelijks beheer gaat wel erg prettig ten opzichte van command-line KVM vind ik. Dan met name als je je er niet dagelijks mee bezig hoeft te houden en de command line dingen dan betekent dat je alles mag gaan zoeken op internet.
Xencenter ondersteund oa live migratie, en dat werkte zelfs met het antieke SAN prima met antieke servers, en als het niet werkt, geeft hij dat ook aan voordat hij er aan begint.
Daarnaast hebben we 2 klanten draaien met KVM + LVM met libvirt, en Fedora/Redhat Virt-Manager als schil. Werkt ook wel prettig. Veel meer basic dan Xencenter, maar als je een MKB omgeving hebt voldoet dat prima. En de communicatie verloopt over een SSH tunnel, dus dat maakt het standaard al redelijk veilig.
Verder hebben we nu bij 2 locaties Proxmox draaien. In ons geval hebben we nog wel eens wat hulpjes / losse krachten / studenten die niet zo erg handig zijn, en dan is zo'n webbased omgeving wel practisch. Je gaat gewoon naar de URL toe, en kan zonder plugins oid alle dagelijkse beheertaken doen, met een Javascript/HTML based console viewer. En de installatie is ook gewoon in een handomdraai, dus wat dat betreft wel goede concurrentie voor Xencenter.
Met storage weinig ervaring, behalve dat je de Openfiler 'open source edition' als de pest moet mijden. Exacte details kwijt, maar als je OSS gebruikt, wat in ons geval zo was, dan krijg je alleen een rare userspace iSCSI implementatie, als je betaald dan 'mag je' de kernel based iSCSI gebruiken. Het rare aan dit model vind ik vooral dat beide iSCSI implementaties niet van de makers van Openfiler zijn, dus het is wat apart naar mijn mening om daar de grens te maken.
Met vriendelijke groet,
App b akkers
germ@appbakkers.nl
----- Original Message -----
> From: "Wouter Verhelst" <wouter@debian.org>
> To: "Paul van der Vlis" <paul@vandervlis.nl>
> Cc: debian-user-dutch@lists.debian.org
> Sent: Maandag 9 mei 2016 08:55:16
> Subject: 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: