Wechsel von vServer Pluto KVM auf Root-Server M - Fragen vor dem Kauf

  • Hallo.
    Ich habe derzeit den vServer Pluto KVM mit 512MB Arbeitsspeicher, weshalb auch Minecraft-Server nur sehr schlecht funktioniert.
    Jetzt bietet Netcup ja zum gleichen Preis (5,49€) den Root-Server M mit 6GB Arbeitsspeicher an. Vor dem Wechsel habe ich allerdings noch einige Fragen.
    Hat der Root-Server M irgendwelche gravierenden Nachteile gegenüber dem vServer Pluto KVM?
    Gibt es eine Möglichkeit, meine ganzen Daten (Konfiguration, Froxlor, Kundendaten, SSH, etc.) ohne große Mühe zu übertragen / übertragen zu lassen? (Ich habe Debian 7).

  • Hallo,
    leider kenne ich die Spezifikationen Deines aktuellen vServers nicht. Der aktuelle Root-Server M hat den Nachteil, dass Du keine dedizierten Kerne bekommst, was bei den größeren Servern der Fall ist.
    Zum Übertragen der Daten Deines alten Servers kannst Du ein Snapshot Deines aktuellen Servers erstellen, dieses exportieren und auf dem neuen Server einspielen, unter der Voraussetzung dass der neue Server genauso viel oder mehr Speicherplatz hat.

  • Der Root-Server M unterstützt keine Snapshots. Außerdem fehlen das CD-/DVD-Laufwerk und die Möglichkeit eigene Images hochzuladen. Du bist somit von den Netcup-Images abhängig oder musst die Installation über das Rettungssystem durchführen.


    5,49 Euro/Monat kostet der Root-Server M v5a1 24M nur bei einer Mindestvertragslaufzeit von zwei Jahren; der Vertrag verlängert sich danach immer wieder um zwei Jahre.


    Ringelnatz : vServer Pluto KVM

  • Ich steige im Moment selbst von einem Root Server S auf Root Server M um. Übertragen habe ich ganz normal mit SSH/rsync.


    Sorgen bereitet mir der hohe IO-wait. Beim entpacken eines Linux-Kernel-Tarballs bleibt die Kiste praktisch stehe.


    Überschreiben einer 512MB-Partition mit Zufallsdaten:


    Code
    1. # truncate -s 512M /dev/shm/foobar
    2. # shred -n 1 /dev/shm/foobar
    3. # dd bs=1M if=/dev/shm/foobar of=/dev/vda4
    4. 512+0 records in
    5. 512+0 records out
    6. 536870912 bytes (537 MB) copied, 164.985 s, 3.3 MB/s


    Das gleiche im Rettungssystem:


    Code
    1. rescue:~# truncate -s 512M /dev/shm/foobar
    2. rescue:~# shred -n 1 /dev/shm/foobar
    3. rescue:~# dd bs=1M if=/dev/shm/foobar of=/dev/vda4
    4. 512+0 records in
    5. 512+0 records out
    6. 536870912 bytes (537 MB) copied, 12.7916 s, 42.0 MB/s


    Es liegt also allem Anschein nach am Kernel. Das Rettungssystem ist 3.2.63 - das ist mir etwas zu stabil :D -, im installierten System habe ich 3.18.1 und 3.17.7 probiert.


    Auf der LKML habe ich noch jemanden mit IO-wait-Problemen bei aktuellem Kernel gefunden: LKML: =?UTF-8?Q?Jonas_Bofj=C3=A4ll?=: Stuck in iowait regression in 3.18.1


    Ich versuche es als nächstes mit 3.14, das läuft auf meinem Root Server S...


    Edit: Und siehe da, mit 3.14.2 und ansonsten ident. Konfiguration (make oldconfig) klappts auf einmal wunderbar:


    Code
    1. # truncate -s 512M /dev/shm/foobar
    2. # shred -n 1 /dev/shm/foobar
    3. # dd bs=1M if=/dev/shm/foobar of=/dev/vda4
    4. 512+0 records in
    5. 512+0 records out
    6. 536870912 bytes (537 MB) copied, 11.8879 s, 45.2 MB/s


    Fröhliches Kernel-Bug-Hunting... ;)