Neuer Server: Plötzlich sda (anstelle vda)

  • Hallo,


    ich hatte bisher mehrere (root-v)Server hier bei netcup und immer konnte ich die "Festplatte" per /dev/vda unter Linux ansprechen. Auch bei einem neuen G7-root-Server (RS 2000 G7 SSD) ist das so. Nun habe ich einen RS 1000 G7 SSD bestellt und muss das erste mal feststellen, dass hier /dev/sda verwendet wird.


    Ist das normal oder bin ich unfreiwilliges Opfer eines Konfigurationsexperiments?

  • Das hängt davon ab, wie die Festplatte eingebunden ist (Stichwort virtio). Falls es bei Dir Probleme macht, kann der Support es normalerweise einfach umstellen. Normalerweise ist das aber nicht notwendig, wenn man überall konsequent die UUID der Partition verwendet. Diese findest Du z.B. über blkid heraus und kannst sie danach u.a. in der /etc/fstab verwenden.


    Warum das bei verschiedenen Produkten anders ist, weiß ich auch nicht. Ich könnte nur vermuten, dass der jeweils andere Modus bei Single/Dual Core Systemen vielleicht eine bessere Performance erzielt oder so andere Probleme umgangen werden. In diesem Punkt unterscheiden sich die beiden Tarife nämlich. Oder eines der beiden Hostsysteme läuft noch unter einer älteren Version, wo das nicht vollständig unterstützt wird. Letzen Endes wird das nur netcup selbst aufklären können.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich hatte das halt noch nie gesehen, dass die Platte als sda läuft.


    Außerhalb von ncLabs habe ich es bei netcup bisher auch noch nie gesehen, und dort auch nur auf expliziten Wunsch… :)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Hm, wie ich jetzt in einem anderen Thread mitbekommen habe, wird auch bei anderen neuen (G7) Servern sda verwendet. Den RS 2000 G7 SSD habe ich relativ früh nach Erscheinen bestellt - kann es sein, dass da mittlerweile optimiert wurde und nun generell nicht mehr vda verwendet wird?


    Wäre schade, wenn mein RS 2000 G7 SSD diese Optimierung noch nicht erhalten hat...

  • Guten Morgen,



    /dev/sda steht nach einer Installation mit einem aktuellen Image bei allen vServern / Root-Server / Storage und VPS zur Verfügung. Die Optimierung bieten wir unabhängig vom Tarif an.



    Mit freundlichen Grüßen


    Felix Preuß

  • Normalerweise werden bei vda nicht alle Funktionen emuliert, sondern direkt an die Platte durchgereicht. Das kann Vor- als auch Nachteile haben. I.d.R. gilt dies als schneller.
    Nun kann aber bei der Implementierung hier je nach Soft- und Hardware die SATA/SCSI-Emulation (was in sda resultiert) besser/schneller/stabiler (such dir was davon aus ;)) funktionieren und netcup dieses als Standard verwenden.

  • Zusätzlich könnte man auch die TRIM-Befehle mittels der Mountoption "discard" oder über fstrim durchreichen, was besonders für die Snapshots von Vorteil ist, da eine Defragmentierung dadurch unnötig wird. Je nach Konfiguration könnte man dadurch auch Speicherplatz am Hostsystem sparen. Ob das bei den aktuellen Produkten genutzt wird, kann ich nicht mangels Testsystem nicht sagen.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    • Offizieller Beitrag

    Ich möchte hier nochmal sicher gehen: Wenn ich jetzt einen neuen root-Server bestelle (egal welchen RS 1000 bis 8000 G7) bekomme ich sda anstelle vda?


    Es hat nichts mit den neuen Tarifen zu tun, sondern mit einer Umstellung der vorgefertigten Images. Bei einer Neuinstallation eines jeden auf KVM basierenden Server mit einem aktuellen Image (Debian Jessie, Ubuntu 16, Fedora 24 etc.) erfolgt die Umstellung von "vda" auf "sda".

  • Hallo,

    Es hat nichts mit den neuen Tarifen zu tun, sondern mit einer Umstellung der vorgefertigten Images. Bei einer Neuinstallation eines jeden auf KVM basierenden Server mit einem aktuellen Image (Debian Jessie, Ubuntu 16, Fedora 24 etc.) erfolgt die Umstellung von "vda" auf "sda".

    das verstehe ich anders. Es hat nichts mit den Images aber alles mit dem kvm-Aufruf zu tun.


    Der Thread hat mich dazu gebracht, damit auf meiner Entwicklermaschine zu experimentieren. Dort herrscht ständig Platzmangel, da alle Projekte ihre eigene KVM-Jessie haben. Ich starte meine VMs immer direkt per Kommandozeile mit kvm.


    Bisher habe ich meine Images mit

    Code
    -drive file=$DISK_IMG,index=0,media=disk,format=$DISK_IMG_FORMAT,if=virtio,cache=none


    eingebunden und die Partitionen waren vda's.


    Nach der Änderung in

    Code
    -drive file=$DISK_IMG,index=0,media=disk,format=$DISK_IMG_FORMAT,if=none,cache=none,id=drive0,discard=unmap \
    -device virtio-scsi-pci,id=scsi0 \
    -device scsi-hd,bus=scsi0.0,drive=drive0


    waren die Partitionen in sda's geändert.


    Dank der allgemein bei Jessie verwendeten UUIDs in der fstab war keine weitere Änderung notwendig.


    Den großen Vorteil bringt nun die Option discard=unmap. Damit kann nicht benutzter Speicherplatz im Host wieder freigegeben werden (eigentlich ne SSD-Geschichte: killerbees19 hat ja fstrim erwähnt).


    Das kann man dann an den Images sehen, wenn man in der VM mal trimmt:

    Code
    xxx@yyy:~/Qemu VMs/zzz$ ssh root@zzz
    root@zzz:~# fstrim -a -v
    /: 25,2 GiB (27044970496 bytes) trimmed
    root@zzz:~# exit
    xxx@yyy:~/Qemu VMs/zzz$ ls -lhs
    insgesamt 1,9G
    1,9G -rw------- 1 xxx xxx 3,4G Aug 14 22:09 zzz.qcow2
       0 -rw-r--r-- 1 xxx xxx	0 Aug 14 19:13 kvm.log
    4,0K -rwx------ 1 xxx xxx  849 Aug 13 17:59 vm.sh
    xxx@yyy:~/Qemu VMs/zzz$


    Der Effekt ist also deutlich: links der tatsächlich belegte Platz von zzz.qcow2, rechts die Dateigröße: qcow2 als Sparse-File.


    Das Potential liegt IMHO vor allem in dem Shrinken der Images ohne Rumhampeln (s. z.B. Shrink Qcow2 Disk Files - Proxmox VE).


    Dieser Vorteil wird in den Netcup-Images auch genutzt. Das von mir genutzte Jessie-Image (installiert in den letzten Tagen) hatte zwar keine discard-Option in der /etc/fstab, mit der der Speicherplatz von der VM sofort zurückgegeben wird, es existiert aber ein Netcup-spezifischer CronJob, der fstrim ausführt.


    Der Vorteil für Netcup ist, dass der Festplattenplatz effizienter genutzt werden kann. Der mittelbare Vorteil für den Kunden ist der gute Preis.


    Falls ich falsch liege oder was vergessen habe, bitte Rückmeldung!


    Viele Grüße!

    Produkte bei Netcup: Neues Webhosting (2018) / VPS G7, Debian Bullseye

    Einmal editiert, zuletzt von potato () aus folgendem Grund: cat /etc/cron.d/kernel 59 6 * * * root /sbin/fstrim /

  • Danke für die genaue Analyse, vor allem die Sache mit dem Cronjob! ;) Gerade im Hinblick auf die Storageserver würde das sehr viel Sinn machen… :) (nur geht der Vorteil halt schnell verloren, wenn jemand über eine ISO installiert und die Option nicht setzt.)


    Zu Hause wäre mein KVM-Host auch schon an Platzmangel gestorben, wenn ich dieses Feature nicht nutzen würde. Bei mir halt mit Raw-Images über libvirt. Eine ~100GB SSD ist für viele Debian-VMs halt nicht gerade viel, wenn Datenverzeichnisse auch noch mit drauf müssen.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Kann man das auch irgendwie umstellen ohne ein neues Image zu installieren?
    Von Kundenseite müsste es ja genügen virtio_blk durch virtio_scsi zu ersetzen, nur der Host muss natürlich auch die enstprechende Unterstützung aktivieren. Beim Netzwerk kann man ja im VCP den Treiber wählen, für die Festplatte sehe ich aber nichts derartiges.