[CfAll DE] Community-Server

Friedrich Lindenberg friedrich at pudo.org
Wed Apr 23 21:36:52 UTC 2014


Hey, 

On 23 Apr 2014, at 17:35, Morris Jobke <hey at morrisjobke.de> wrote:

> Hallo,
> 
> Am 23. April 2014 23:32 schrieb Friedrich Lindenberg <friedrich at pudo.org>:
> Zwei Stimmen für KVM, dann haben wir wohl einen Sieger! :) Danke für eure Beiträge, so macht Planen Spaß. 
> 
> Müssen wir dafür einen Plan schreiben oder sowas? Vielleicht wäre irgendein Dokument gar nicht schlecht, wo man die Kommandos, Policy und aktuellen Instanzen ein wenig dokumentieren kann. Hat jemand Lust sich dessen anzunehmen?
> 
> Also Doku wäre ja ein Wiki nicht ganz verkehrt. Zu Beginn kann man das hier ja benutzen: https://github.com/okfde/codefor.de/wiki 


Dann lieber: wiki.okfn.de - sonst sind das irgendwann so viele Wikis :) 

Lg, Fr. 

>  
> 
> @Jochen: danke für den Key, ich gebe Dir gleich ne Account mit sudo! 
> 
> Lg, Friedrich
> 
> 
> On 23 Apr 2014, at 13:23, Morris Jobke <hey at morrisjobke.de> wrote:
> 
>> Hallo,
>> 
>> na dann möchte ich auch noch paar kleine Gedanken dazuwerfen.
>> 
>> Ich bin in einem Studentennetz tätig, was für das Verwalten eines Netzwerks
>> für ca. 1800 Studenten zuständig ist. Wir haben eine Virtualisierung einiger
>> Server über KVM und libvirt gemacht. Für die graphische Administration
>> verwenden wir hier (außer virsh falls man mal auf der Shell ist) virt-manager,
>> welcher zuverlässig und intuitiv zu bedienen ist.
>> 
>> KVM: Ich bezeichne das jetzt mal als "vollständige" Virtualisierung, d.h. die
>> virtualisierten Server haben ihren eigenen Kernel und die Einrichtung, etc.
>> ist komplett Lab-Sache. Nachteil dabei ist natürlich, dass das ganze
>> ressourcenhungriger ist.
>> 
>> OpenVZ: Der Kernel des Hosts wird von den virtualisierten Servern genutzt und
>> es ist somit ressourcenschonender. Ich habe damit noch nicht weiter zu tun
>> gehabt - zumindest Host-seitig.
>> 
>> Docker: Finde ich einen interessanten Ansatz, jedoch bin ich über mal kurz
>> damit rumspielen nicht hinaus gekommen und kann bezüglich Verwaltungsaufwand,
>> etc. nicht viel sagen.
>> 
>> Spontan würde ich mich wahrscheinlich für libvirt mit KVM entscheiden, da ich
>> damit bereits mehr Erfahrung sammeln konnte.
>> 
>> Falls Hilfe oder ein paar Augen bei der Fehlersuche benötigt werden, stehe ich
>> gerne zur Seite.
>> 
>> Viele Grüße,
>> Morris
>> 
>> 
>> Am 23. April 2014 19:02 schrieb Jochen Klar <mail at jochenklar.de>:
>> Hallo,
>> 
>> > Wenn Du mir mal Deinen Key schickst gebe ich Dir gerne Zugriff;
>> > vielleicht kannst Du uns kurz erzählen wie das mit KVM/libvirt
>> > aussehen würde?
>> 
>> Ok, ich hole mal ein bisschen aus:
>> 
>> Ich arbeite in der E-Science Gruppe am Leibniz-Institut für
>> Astrophysik Potsdam. Viele der Webseiten die wir hosten sind schlecht
>> bis gar nicht migrierbar. Oft ist die Wissenschaftlerin oder der
>> Wissenschaftler den Code mal geschrieben hat nicht mehr am Institut,
>> wenn eine neue Maschine kommt und der Kram umgezogen werden soll.
>> 
>> Die Idee war dann das auf virtuelle Maschinen zu packen damit man
>> zumindest ab dem nächsten Umzug weniger Stress hat. Nachdem ich mich
>> ein paar Tage mit OpenStack rumgeschlagen habe habe ich dann
>> beschlossen das das in unserem Fall overkill ist. Seit dem nutze ich
>> libvirt direkt über virsh und ein Skript was mir das erstellen neuer
>> Maschinen und klonen und so etwas erleichtert.
>> 
>> Das Setup besteht im Prinzip aus einem Server (16 Cores, 64 GB) für
>> die Maschinen mit einem Raid dran und einem vorgeschalteten Proxy
>> Server (4 Cores, 32 Gb, Apache). Die einzelnen Maschinen haben eigene
>> (interne) IP Adressen und sehen sowohl Host als auch Proxy (und noch
>> ein paar Maschinen). Die Images sind so 50 - 100 Gb groß und wenn
>> nötig hängen wir da noch 2Tb vom Raid als block device dazu. Im Moment
>> laufen 20 Maschinen, die mit einem Core und 1 GB Ram konfiguriert
>> sind, und eine mit 8 Cores und 8 Gb.
>> 
>> Insgesamt läuft das ganz gut und stabil und macht wenig Arbeit. Es
>> gibt aber nur ein paar Admins die auf die Maschinen dürfen und nicht
>> eine Masse von Usern. Wir haben auch kaum Requests, da es in der Regel
>> um wissenschaftliche Daten geht und da halt die Zielgruppe klein ist.
>> Da wir aber Terrabyte-große Datenbanken hosten, pumpen wir, wenn mal
>> ein Request kommt, da ganz schön Daten durch. Das hält das alles bis
>> jetzt ganz gut aus.
>> 
>> Man könnte das auch auf dem Server ausrollen mit einer Maschiene pro
>> Lab und vll einem Apache (oder was anderes) zusätzlich auf dem Host
>> als Proxy. Das kommt darauf an wie das mit dem Netzwerk aussieht und
>> den IPs und Domains. Dann würde man die virtuellen Maschinen eher in
>> ein NAT packen.
>> 
>> Als ich das ganze aufgebaut habe, habe ich noch keine Ahnung von
>> OpenVZ oder Docker oder so gehabt (hab ich immer noch nicht).
>> Vielleicht ist das als Lösung hier (und auch bei meiner Arbeit)
>> besser. In jedem Fall kann ich helfen und lerne vielleicht noch was.
>> 
>> cheers,
>> Jochen
>> 
>> _______________________________________________
>> cfallde mailing list
>> cfallde at lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/cfallde
>> 
>> _______________________________________________
>> cfallde mailing list
>> cfallde at lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/cfallde
> 
> 
> _______________________________________________
> cfallde mailing list
> cfallde at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/cfallde
> 
> 
> _______________________________________________
> cfallde mailing list
> cfallde at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/cfallde

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/mailman/private/cfallde/attachments/20140423/863ce8fa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.okfn.org/mailman/private/cfallde/attachments/20140423/863ce8fa/attachment.sig>


More information about the cfallde mailing list