Serverdaten von Stratos vServer (user_beancounters)

[jokedebuhr]

Hallo.

Könnte vielleicht jemand mal, der die ausgabe

cat /proc/user_beancounters

von seinem Strato vServer posten?

Ich bin zur Zeit auf der Suche nach einem neuen vServer, da mein alter Vertrag bei 1und1 bald auslaufen wird. Dabei bin ich auf das aktuelle Angebot von Strato gestoßen V-PowerServer A.

Wichtig sind mir dabei vor allem die genauen Ressourcen des vServers. Controlpanel und Betriebssystem sind mir egal, da ich sowieso eigene sachen aufspielen werde. Ich hatte bei der Strato Hotline angerufen um die Daten zu erfragen, aber die waren nicht gerade freundlich und Testserver bieten sie ja leider auch nicht. Das Wenige, was auf ihrer Homepage steht, klingt aber interessant.

Schon mal, Danke.

 

[Lord Gurke]

h83xxxx:~ # cat /proc/user_beancounters
Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
    83xxxx: kmemsize        6680399    7077832   28542866   31447330          0
            lockedpages           0          0       7600       8192          0
            privvmpages      130838     137565     238528     259324       8194
            shmpages           8839       8855     262144     262144          0
            dummy                 0          0          0          0          0
            numproc              86         92        396        396          0
            physpages         27834      27999          0 2147483647          0
            vmguarpages           0          0     132062 2147483647          0
            oomguarpages      27834      27999     132062 2147483647          0
            numtcpsock           33         33       1000       1000          0
            numflock             11         12        400        464          0
            numpty                2          2        128        128          0
            numsiginfo            0          1       1024       1024          0
            tcpsndbuf        295152     295152    5366512    8204912          0
            tcprcvbuf        516284     516284    5366512    8204912          0
            othersockbuf      71108      74488    3006464    8126464          0
            dgramrcvbuf         700       3636     480000     524288          0
            numothersock         45         50        764        764          0
            dcachesize            0          0    5023656    5672656          0
            numfile            3296       3425      12864      12864          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            73         73        256        256          0


h83xxxx:~ # uptime
 11:01pm  an 97 Tage 14:22,  1 Benutzer,  Durchschnittslast: 0,13, 0,10, 0,09

h83xxxx:~ # free -m
             total       used       free     shared    buffers     cached
Mem:          2019       1987         32          0        134       1173
-/+ buffers/cache:        680       1339
Swap:         2996          6       2989

Das ist das Modell V-PowerServer C, Uptime bei etwas über 97 Tagen.
Die Failcounts dürften zu einem Teil von amokgelaufenen YaST-Prozessen herrühren

Auf dem Gerät laufen mehrere Webseiten (etwa 200 bis 300 Besucher pro Tag) und ein Teeworlds-Server (Gameserver), von letzterem stammt auch die LoadAverage, weil der gerade komplett voll ist.
Vielleicht auch nicht ganz unwichtig: Es kann ein Tunneladapter installiert werden, zumindest Hamachi läuft fehlerfrei, auch nach einem Reboot.

 

[jokedebuhr]

danke.

das ist ungefährt mit dem zu vergleichen, was mein server bei 1und1 so kann. ich hatte auch mal einen vserver von server4you ausprobiert, aber die hatten eine sehr beschränkte ausstattung an kernelspeicher. zwar viel ram, aber was nützt der schon, wenn man keine sachen im kernel unterbringen kann, an der anzahl der dateideskriptoren kann man ja nur begrenzt viel tunen.

ja, mit dem tun/tap device ist durchaus interessant, wobei ich bis eben nichts von hamachi gehört hatte. du weißt nicht zufällig, ob der kernel ipv6 unterstützung hat, dann könnte man einen ipv6 tunnel anlegen.

 

[Lord Gurke]

Ich bin mir garnicht mal sicher, ob Strato überhaupt IPv6 anbietet
Zumindest habe ich keine IPv6-Addresse auf meiner Maschine, laut der DE-CIX haben die aber wohl IPv6-Support.

 

[TamCore]

Ich bin mir garnicht mal sicher, ob Strato überhaupt IPv6 anbietet

Natives IPv6 von Strato gibt es nicht, aber in meinem Blog gibts nen Script des IPv6 über nen 6to4 Gateway einrichtet. In wie fern des auch mit vServern funktioniert, weiß ich nicht.

Link: TamCore’s Blog IPv6 auf Root-Server

Zumindest habe ich keine IPv6-Addresse auf meiner Maschine, laut der DE-CIX haben die aber wohl IPv6-Support.

Ich hatte Strato mal ne email geschrieben, die nette Dame an anderen Ende meinte, dass Strato aus Sicherheitsgründen noch kein IPv6 für seine Kunden anbietet.

@jokedebuhr: Vielleicht wäre so nen RPS von OVH für dich Interessant, /dev/net/tun steht dir dort zur verfügung und meiner hat sogar natives IPv6.

 

[jokedebuhr]

Natives IPv6 von Strato gibt es nicht, aber in meinem Blog gibts nen Script des IPv6 über nen 6to4 Gateway einrichtet. In wie fern des auch mit vServern funktioniert, weiß ich nicht.

Also ohne native Kernelunterstützung von IPv6, ist man auch nicht in der Lage, einen 6to4-Tunnel über einen Tunnelbroker wie Sixxs aufzubauen. Das Betriebssystem muß halt irgendwie wissen, was es zum Schluß mit den IPv6 Paketen machen soll. Abgesehen davon geschieht das Tunneln selbst im Kernel, folglich muß die Unterstützung für die 6to4-Umsetzung einkompiliert sein.

Ich hatte Strato mal ne email geschrieben, die nette Dame an anderen Ende meinte, dass Strato aus Sicherheitsgründen noch kein IPv6 für seine Kunden anbietet.

Eine nette Ausrede für: Wir wollen kein IPv6, weil unsere Switches das nicht unterstützen. Ein Sicherheitsgewinn besteht da eindeutig nicht.

@jokedebuhr: Vielleicht wäre so nen RPS von OVH für dich Interessant, /dev/net/tun steht dir dort zur verfügung und meiner hat sogar natives IPv6.

Also von OVH hatte ich auch mal wieder bis eben nichts gehört, ich muß aber zugeben, daß sich diese RPS interessant anhören. Nett ist, soweit ich verstanden habe, daß man die Möglichkeit hat, den Kernel auszutauschen. Womit man folglich völlig frei ist.

 

[d4f]

Bei den RPS Kernel austauschen klingt einfacher als es ist.
Diese Server greifen ja auf einen (in den Abendstunden öfter mit spürbaren Latenzen verbundenen) iSCSI-SAN zurück, also muss iSCSI einkompiliert sein.

Und wenn man Kernelmodule beim Standartkernel nehmen will: aus Sicherheitsgründen sind Module bei allen OVH-Kerneln standartmässig deaktiviert.
Der Anbieter gibt aber Zugriff auf seine Configs, so dass man schnell einen eigenen Kernel basteln kann in welchem Modul-Support an ist

 

[jokedebuhr]

Bei den RPS Kernel austauschen klingt einfacher als es ist.
Diese Server greifen ja auf einen (in den Abendstunden öfter mit spürbaren Latenzen verbundenen) iSCSI-SAN zurück, also muss iSCSI einkompiliert sein.

Also soweit ich deren Homepage richtig gelesen habe, gibt es einen Bootmanager z.B. grub. Wenn grub es fertig bringt ein Kernelimage zu laden, dann braucht man sich ja nicht darum sorgen, ob der neue Kernel ein einkompiliertes Modul für iSCSI hat, hauptsache es gibt eines als Modul.

 

[d4f]

Soviel ich weiß nutzen sie Netboot über PXE von wo aus dann irgendein Bootmanager genommen wird.

Bei mir zumindest hatte der Kernel gestreikt bis ich ihn hübsch eingebaut habe.
Aber vielleicht lag das auch an meinen eher mäßigen Kernelkompiler-Fähigkeiten

OVH's vKVM und RecueModus sind dann echt praktisch

 

[jokedebuhr]

Bei mir zumindest hatte der Kernel gestreikt bis ich ihn hübsch eingebaut habe.

Also man muß natürlich, wenn der Treiber nicht einkompiliert ist, mit anderen Worten als Modul vorliegt, den zur Bootzeit bereitstellen. Dazu nutzen normale Distributionen eine Ramdisk (initramfs oder initrd). Die Distributionen haben meist eine Datei, in die fügt man den Modulenamen ein, läßt die Ramdisk neu bauen und fertig.
So eine Ramdisk wird vom Bootmanager zusätzlich zum Kernel in den Speicher galaden und damit steht das Modul beim Boot dem Kernel zur Verfügung. Damit hat sich die Sache mit dem Kernelkompilieren auch gleich erledigt.

In Debian/Ubuntu reicht da zum Beispiel folgendes aus:

echo {modulename} >> /etc/initramfs-tools/modules && update-initramfs