[CfAll DE] Community-Server

Wed Apr 23 21:37:45 UTC 2014

Am 23. April 2014 23:36 schrieb Friedrich Lindenberg <friedrich at pudo.org>:

> 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 :)
>

Ah. Wusste ich nicht, dass es sowas gibt.

>
> 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
>
>
>
> _______________________________________________
> 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/6b0c5941/attachment-0001.html>