Host Europe - VServer

MikeMüller

Banned
Registriert
Jan. 2014
Beiträge
1.340
Mir gefällt das Produkt "Virtual Server Expert" von den Daten her soweit recht gut.

https://www.hosteurope.de/Server/Virtual-Server/Expert-HighIO/

Ich möchte da gerne die Version mit 250 GB SSD Speicher nehmen.

Dazu habe ich ein paar Fragen, welche Einschränkungen der V-Server mit sich bringt.

Es heißt CPU: 4 vCores. Wie muss man sich das verstehen? Sind das dann tatsächlich 4 Kerne die nur für mich sind, oder teile ich mir die 4 Kerne mit anderen Leuten?

Ram 8 GB. Die sind nur für mich alleine, oder?

Garantierte Peak-Bandbreite: 100 Mbit/s. Was bedeutet das?
 
Bei der CPU heißt das einfach nur, dass dir 4 Kerne mit Taktrate XY reserviert werden. Die sind dann wirklich für dich. Die teilst du auch mit niemanden. Gleiches gilt für den RAM. Steht ja auch so da "RAM _garantiert_".

Gleiches gilt für die Bandbreite. Du kannst halt maximal 100mbit nutzen. Irgendwie merkwürdige fragen hast du da :D

Edit: Vielleicht sollte ich noch erwähnen, dass virtuelle Server heute quasie das Mass aller Dinge sind. Dedizierte Maschinen machen kaum noch Sinn.
 
Das sehe ich anders. 4 vCores bedeutet, du darfst bis zu vier Kerne am Endsystem auslasten (können dort auch nur zwei sein z.B. wegen Intel HT), dein OS bekommt vier dargestellt. Die CPUs, die du verwendest, sind jedoch nicht reserviert. Weder an Taktrate noch in der Anzahl. Die 8GB RAM gehören dir alleine, die Netzwerkgeschwindigkeit ist geshared, mehr als 100MBit ist nicht möglich.

Ob vServer oder dedizierter Server einen Sinn macht, kommt auf den Einsatzbereich an. Benötigt deine Anwendung viel CPU Last, nimmt man sich, alleine schon aus Gründen des Anstands, einen dedizierten Server. Für 30 Euro bekommt man womöglich schon was, bei Hetzner gibt es außerdem schon ordentlich ab 30 Euro in der Serverbörse (Altserver in Versteigerung). Kommt eben auf den Einsatzbereich an.
 
@Andy_0: Sorry aber das kann ich nicht unterschreiben. Die Cores sind reserviert. Jede VM benutz bei solchen System zu 99% ihre eigenen Cores. Die Kisten laufen Systemen mit >256 CPU Cores. CPU Sharing ist gar nicht mal so einfach zu realisieren, daher ists einfacher jeder VM Cores zu garantieren und gut ist. Allerdings ist die Leistung pro Core natürlich etwas beschnitten, das stimmt. Warum man bei CPU lastigen Diensten einen dedizierten Server nehmen soll ist mir absolut schleierhaft. Es gibt doch inzwischen super skalierbare Cloud Dienste wie z.B. von Amazon wo je nach Bedarf die Leistung skaliert wird. Dedizierte Server sterben aus, und das ist auch gut so. Warum 20 Einzelsysteme betreiben, wenn man diese fast ohne merkbaren Unterschied in einem unterbringen kann? Das ist viel effizienter, spart Strom, ist ausfallsicherer, leichter zu backupen, etc. pp.
 
Mir gehts bei dem System nur um eine von überaus für mich verfügbares CRM System, das auf Microsoft SQL läuft.
Auch meine normalen Dokumente werde ich darauf speichern. Daher gefällt mir auch die SSD gut, da sie das öffnen der Dokumente noch beschleunigt.

4 Cores und 8 GB Ram brauche ich eigentlich nicht wirklich.

Mir gehts eher um die 250 GB Speicherplatz, der eben SSD sein soll.

Maximal 2 Benutzer werden gleichzeitig auf den Server zugreifen.

Mir gefällt die angegebene Verfügbarkeit von 99,95% und die Beschreibung, wie redunant die Ihr System aufbauen.

Zuverlässigkeit und Verfügbarkeit sind mir wichtiger als die Leistung.

Denke für 30,- € im Monat bekomme ich da ein ganz gutes Paket für meine Zwecke.
 
@ Ex0r
Jaja, superskalierbare Server. Die sind, trotz allen Möglichkeiten wie z.B. bei Amazon, eben nicht die Regel. Sowas ist häufig viel zu teuer, das ist es deutlich günstiger sich dafür 10 günstige Server hinzustellen (1x Mainboard mit jeweils 2x CPU und vlt. 12 Cores pro CPU). Backup ist irrelevant, darum muss sich der Kunde schon selber kümmern und Strom ist zwar ein wichtiger Faktor, aber kein Killerkriterium. Der Kunde zahlt das ganze schließlich. "Selbst" Google baut nur 0815 Server, dafür eben eine ganze Menge.

Zu den vCores z.B. für Microsoft Hyper-V (https://social.technet.microsoft.co...yper-v-concepts-vcpu-virtual-processor.aspx):
"A physical CPU core is controlled by the hypervisor and this is divided up into virtual CPU cores. It is these virtual CPU cores that are presented to the virtual machines (and used by the virtual machines).
A virtual CPU is not a one to one assignment - it represents time. It is a representation of time on the physical CPU resource stack."

Für CPU lastige Anwendungen ist ein vServer häufig nicht geeignet, da man 1. nicht genügend Ressourcen hat (unbekannte CPU Ressourcen durch CPU Sharing) und 2. diese mit anderen Leuten teilt. Das bedeutet, hat man eine permanent hohe CPU Auslastung, könnte das einen anderen Nutzer am selben Server deutlich stören. Genauso könnte es einen selber stören, wenn jemand anderes viel Leistung benötigt. 4 vCPUs bedeutet eben NICHT, dass man diese garantiert hat und alleine nutzt. Wäre dies der Fall, wären diese vier vCPUs garantiert zugesagt. Vier vCPUs garantiert zusagen ist aber schon wieder eine "dumme Idee", da man ja nur Prozesszeit zusagen würde und keine wirklichen CPUs/Cores.

@ MikeMüller
Das ist etwas anderes. Ich sehe zwar selber keine Notwendigkeit für eine SSD, dein Einsatzbereich ist für ein vServer aber gut geeignet.
 
@Andy_0: Um Backups geht es sowieso nicht. Das ist wie du ja schon sagst so oder so Kundensache. Es geht hier maximal um Verfügbarkeit und Performance und die sind beide bei HE wohl mit die besten am Markt. Klar wie die CPUs jetzt verwaltet werden, werden weder wir, noch der TE erfahren. Von daher machts auch nicht viel Sinn darüber zu debattieren, was bei nem CPU Peak passiert. Ich denke aber ehrlich nicht, dass jemand anderem bei Vollauslastung Performance geklaut wird. Jede größere Firma ist übrigens dabei, ihre kleinen (schei*) Server zu virtualisieren. Nur weil wir das CPU Managment nicht kennen, ist das kein Grund um vServer für CPU Lastige Sachen auszuschließen.

Auch hier gilt: Im Zweifel für den Angeklagten. So aufwändig ist ein Skalieren nach oben und unten nun auch nicht mehr. Eher im Gegenteil. Jeder Hoster der sparen will, skaliert die Maschinen vernünftig. Ob man jetzt Prozessorzeit oder Cores zuordnet ist doch ehrlich gesagt Jacke wie Hose. Der Anwender kriegt davon eh nix mit.

Führen wir etwa gerade im Jahre 2014 eine einigermaßen interessante Diskussion über den Sinn von vServern? Ich bin überrascht. Sowas hatte ich hier lange nicht mehr :D
 
Ich werfe noch die Datensicherheit in den Ring ich würde bei sensiblem Daten z. B Personenbezogen ( je nach CRM kann sich da was ansammeln) immer auf ein eigenen Server setzten. Am Ende weißt du nie wirklich genau wo der Server steht und wer wirklich Zugriff auf die Daten hat. Grade wenn man Beispiele wie Amazon oder Googel in den Raum wirft. Die Leute dort wissen teilweise nicht mal wie das geschrieben wird.^^

@TE die andere frage ist ob du dir das zutraust ein eigenen Server zu installieren und zu administrieren. Ist schon ein Aufwand den man nicht unterschätzen sollte Grade wenn du so auf Ausfallsicherheit aus bist was ich verstehen kann.

Ich nutze auch einen physischen Server auf den 5 virtuelle Server laufen also das eine schließt sich nicht aus :D
 
Zuletzt bearbeitet:
@Seiyaru2208: Wenn du deine Daten schon an einen externen Dienstleister abgibst, ist es ziemlich egal ob dies auf einen vServer oder aufm echten Root passiert. Wenn der Hoster da drann will, kommt er auch drann.
 
Und deshalb habe ich ein physischen Server. Ich wollte das bloß mal mit zu Bedenken geben das man das beachten sollte
 
andy_0 schrieb:
Zu den vCores z.B. für Microsoft Hyper-V (https://social.technet.microsoft.co...yper-v-concepts-vcpu-virtual-processor.aspx):
"A physical CPU core is controlled by the hypervisor and this is divided up into virtual CPU cores. It is these virtual CPU cores that are presented to the virtual machines (and used by the virtual machines).
A virtual CPU is not a one to one assignment - it represents time. It is a representation of time on the physical CPU resource stack."

Für CPU lastige Anwendungen ist ein vServer häufig nicht geeignet, da man 1. nicht genügend Ressourcen hat (unbekannte CPU Ressourcen durch CPU Sharing) und 2. diese mit anderen Leuten teilt. Das bedeutet, hat man eine permanent hohe CPU Auslastung, könnte das einen anderen Nutzer am selben Server deutlich stören. Genauso könnte es einen selber stören, wenn jemand anderes viel Leistung benötigt. 4 vCPUs bedeutet eben NICHT, dass man diese garantiert hat und alleine nutzt. Wäre dies der Fall, wären diese vier vCPUs garantiert zugesagt. Vier vCPUs garantiert zusagen ist aber schon wieder eine "dumme Idee", da man ja nur Prozesszeit zusagen würde und keine wirklichen CPUs/Cores.

Dem stimme ich prinzipiell zu... aber ich weiß nicht, ob du das so im vollen Umfang auch auf Virtuozzo (bzw. OpenVZ) übertragen kannst. Dahinter steckt ja ein anderes Virtualisierungskonzept (die Prozesse aller Container werden in einem einzelnen Kernel verarbeitet).

Wenn ich den Parallels-Virtuozzo Artikel "CPU limits design" richtig interpretiere, dann geht's dort schon um "echte" vcores (bzw. Threads). Zudem muss man nicht unbedingt core-Sharing betreiben.

/proc/cpuinfo schaut bei mir übrigends wie folgt aus (habe bei Hosteurope den kleinsten vserver, allerdings aus der Vorgängergeneration):

Code:
root@lvpsx-xx-xxx-xxx:/home/xxx# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 45
model name      :        Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz
stepping        : 7
cpu MHz         : 2000.069
cache size      : 15360 KB
physical id     : 0
siblings        : 12
core id         : 0
cpu cores       : 6
apicid          : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx pdpe1gb rdtscp lm constant_tsc ida nonstop_tsc arat pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm
bogomips        : 4000.13
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management: [8]

Gemäß dem oben verlinkten CPU-Limit-Artikel entspräche das einem "echten" vcore im vollen Umfang (ansonsten müsste bei CPU-MHz hier ein Wert <2Ghz stehen). Wobei das natürlich bedeutet, dass mir hier nur eine logische Hälfte eines Xeon-Cores gehört. ;)

Wobei einem die größte CPU-Leistung nix nützt, wenn der Durchsatz eines geshareten I/O-Sybsystems zum eigentlichen Problem wird...
 
Zuletzt bearbeitet:
Natürlich gibt es auch andere Systeme. Die einzelnen Hypervisor arbeiten da durchaus unterschiedlich. Es geht aber um das Prinzip, dass ein vCore nicht ein Core sein _muss_. Davon abgesehen kann man, theoretisch, einen Kern auch mehrfach zuweisen. So ein virtualisierter Server ist doch zum Großteil überbucht, die Threads könnte der Hypervisor auf die einzelnen Kerne aufteilen.

Ich kenne z.B. noch den Microsoft Virtual Server 2005 (oder so) da konnte man schon damals x VMs starten und denen jeweils ein Limit zuweisen. Natürlich erhielt jede VM noch eine maximale Core-Anzahl, aber die war eigentlich irrelevant. Wichtig war die % CPU Auslastung vom Gesamtsystem (oder eine Teilmenge des Gesamtsystems). Sitzen 20 Personen auf einen Rechner mit insgesamt 24 Kernen, wird das schnell zu einem Problem, wenn da sechs Kunden ihre "4 Kerne" voll auslasten. Da ist der Server komplett voll, deshalb braucht man nicht argumentieren, man selber darf/kann ja auch vier auslasten. Das wird erst relevant, wenn man garantiert Ressourcen zur Verfügung hat also z.B. garantiert einen Kern oder z.B. 15% CPU Last oder der Server die jeweiligen Ressourcen noch frei hat. Ist dies nicht der Fall stehen die Anwendungen für die restlichen 14 Nutzer.

Das ist natürlich keine Diskussion "vServer sind doof". Ein virtualisierter Server hat, insbesondere für den Betreiber, Vorteile. Es sind, trotz allem, häufig nur "kleine" Server (eben ein Board mit zwei CPUs) die total überbucht werden. Problem ist also nicht die Technik, sondern die Politik wie die jeweiligen Rechner betrieben und mit Kunden vollgestopft werden. Bekommt jeder Kunde seine garantierten Ressourcen, könnte man als Betreiber fast wieder Root Server hinstellen.

Sehen wir jetzt von dem Prozessor ab, kommt man zu dem von dir angesprochen I/O-Subsystem. Was nützt mir 24 Kerne, wenn irgendein Heini die HDD/SSD komplett beschäftigt? Dann steht meine Anwendung wieder schön rum und zeigt mir den "Wartebildschirm".
 
Ich gehe mal stark davon aus, dass die IOPS pro VM bei sowas limitiert sind. Wie sowas geht, würde mich aber auch mal interessieren ^^

/Edit: Wobei wir reden ja von SAN's. Da kann man doch bestimmt auch die Bitrate pro Fibre Channel limitieren, was dann ja auch die IOs pro HDD/SSD senken dürfte.
 
Zuletzt bearbeitet:
Sehr gute Frage die du da in den Raum stellst. Ich denke nicht, dass es sich um SANs handelt. Die richtig großen Server bei den großen Firmen (insbesondere Cloudanbieter wie Amazon) haben natürlich SAN, die günstigen und handlichen Server eher nicht. So ein SAN ist extrem teuer..
 
Ja allerdings geht es hier doch auch primär um HE oder? Und die haben garantiert eins. Ich kenne die Preise zwar jetzt nicht auswändig, aber ein richtig gutes NAS, was nen halben 19" Schrank belegt ist preislich glaub ich gar nicht mal so weit weg von nem SAN. Allerdings ist die Grenze zwischen NAS und SAN wohl auch eher fließend.

Hab da gerade was gefunden: http://kb.vmware.com/selfservice/mi...nguage=en_US&cmd=displayKC&externalId=1038241
Wenn VMWare sowas kann, geht das sicher auch bei noch größeren Systemen. Somit kann man also die Performance einer SSD z.B. schön zu 50:50 auf 2 VMs splitten.
 
Die SAN die ich so kenne kosten schnell mal 40000 Euro (so 10 bis 20 Festplatten). Da war der Anschluss an die Geräte noch nicht mit eingerechnet, wenn ich mich nicht täusche.
 
Zurück
Oben