Wie viele physische Kerne?

Im prinzip beliebig viele. Die Frage ist doch, wie Deine Software diese Kisten ausreizt.

lks

Moin,

das kommt natürlich ganz auf deine VMs und deine Umgebung an!

Grundsätzlich kann man immer mehr Kerne zuweisen als die Maschine physisch zur Verfügung hat, wenn davon aber 24 unter voller Last laufen wird es schwierig.
Dann müsstest du bestimmte VMs priorisieren.

Meistens idlen aber viele VMs nur rum, deshalb hab ich bei mir auf einem Quadcore problemlos 12 VMs bei 10% Last laufen.

Wie das bei dir aussieht musst du selbst herausfinden.

VG
Val

Moin,
aus meiner Sicht sind das keine genauen Informationen. Schon alleine bei "viel Performance" gehen die Meinung weit auseinander. Genauso bei Microsoft Dynamics oder den vier RDS-Hosts. Es gibt einfach in jedem Fall gewisse Abhängigkeit, bei denen du entweder auf Herstellerinfos in Abhängigkeit von Benutzeranzahl zurückgreifen musst oder ein Monitoring der Server über mehrere Wochen um belastbare Zahlen zu erhalten. Wichtig ist die Auslastung für CPU(Kerne), RAM, lokale und Storagefestplatten (Lese-Schreibzugriffe), Netzwerkverkehr, etc...
Die Dimensonierung hängt auch davon ab, wie viele Hosts ausfallen dürfen. Das spielt vorallem bei Prozessor und Arbeitsspeicher pro Host eine Rolle. Ein Host sollte unter Normalbedingungen nicht mehr als 60% ausgelastet ein. Wenn's kurzfristig zu Spitzen kommt auch kein Problem. Aber mittel- oder sogar langfristig tödlich für einen evtl. Failover. Da macht es vllt. sogar Sinn die Server auf vier Hosts zu verteilen, um so den Load gering zuhalten aber dadurch dürfen auch 2 Hosts ausfallen. Das sind lauter Bedingungen die in Abhängigkeit zu den Anforderungen stehen, welcher aber keiner von uns kennt.

Unabhängig davon besagt Regel Nr. 21: DMZ Services wie ADFS-Proxy oder Webserver haben nichts auf einem Cluster im LAN zu suchen. Gerade bei der Wichtigkeit und Zuverlässigkeit der Server, eigentlich völlig logisch. Wenn dafür kein Geld (mehr) da ist, dann läuft aber einiges schief.


Gruß,
Dani

Hi

nimm 2 Sockel á 8 Kerne á 3Ghz+ statt 12 x unter 3Ghz und RAM, jede Menge RAM. Für den SQL Server würde ich je nach DB Größe alleine 64-128Gb RAM einplanen. Unsere TS haben ~ 15-20 Leute die parallel arbeiten und sind mit 48Gb RAM ausgestattet und laufen nicht auf Last - pro MA 4Gb RAM reicht im Regelfall vollkommen aus (außer man nutzt DATEV ....)

Unsere NAV Server (6 St für 250 User) haben je nach Abteilung 12-32Gb RAM. CPU Last macht nur die BI, Sharepoint (vor allem die SearchEngine) und der Exchange, alles andere "dümpelt" vor sich hin.

Die Ausfallrate kannst ja einfach ermitteln, bei 3 Server darfst die max mit 66% Last laufen lassen, bei 4 Servern mit 75%, bei 5 mit 80% usw. (bei einer Fehlertoleranz von einer Kiste). Von VMWare gibt es eine Essential Plus Lizenz, die ist für 3 Server ausgelegt und bietet alle Funktionen einer "vollen" Version, dazu dann noch Veeam als Backuplösung (gibt es in einem ähnlichen Paket) auf einem separaten Server (z.B. HL DL180 / Dell R520 mit je 12 x 4Tb Platten als Backupstorage, dort dann eine kleine 8 Fach LTO5 oder 6 Library und damit hast dann auch das Thema erledigt).

Die nächste Frage die sich dann stellt, welches Storage? Dell bietet eine Langzeitmessung an damit man das richtig Dimensionieren kann, alles andere ist nur geraten oder vermutet und führt nicht zum Ergebnis - was soll man z.B. mit einem reinen SSD Storage wenn die 1000 IO abgefragt werden... - im Regelfall reicht ein SSD/10krpm Kombi-Storage für 99% deiner Anforderung würde ich behaupten - d.h. 8 x SSD und 16 x 10k Platten - kommt auch immer auf die Gesamtkapazität an - aber das kann dir nur eine Messung sagen und diese sollte mind. 4 Wochen laufen und auch die Ausreißer mitzubekommen, die Peak-Last dann zzgl. 50-100% (je nach Geldbeutel) und du hast auch für die Zukunft noch Spiel nach oben.

Gruß
@clSchak

PS: achja SAN: FC, FCoE oder iSCSI...das kommt ja noch additiv dazu

Moin,

wie Du ja schon festgestellt hast, gibt es keinen einfachen Weg Hardware hier zu skalieren.
Das ist immer die Krux in diesem "kleinem" Bereich. Es ist viel einfacher die gleiche Aufgabe für 1000 Server durchzuführen.

Eigentlich ist es ganz einfach
Du schätzt den Bedarf so wie es halt geht.

Also CPU Leistung in GHz, Ram in GB und IO in IOPS.
Das Storage mit SAS und SSD mischen, dazu ein paar große SATA, angebunden mit FC16 (Switche nicht vergessen).
Und HyperThreading wegdenken!

Wenn der IIS mit 4x2x2.0 zu langsam ist, kalkulieren mal 24-32 GHz.

Nach dem Schätzen kommt die eigentliche Frage: Button/Up oder Top/Down.
Also Deine Schätzung * z.B. 0,8 und dann solange Server dazukaufen bis es langt.

Oder Deine Schätzung * z.B. 2 oder 3 und man ist auf der sicheren Seite.

Deinem Chef wird Beides nicht gefallen.
Also nimm Deine Schätzung * 2, zeige irgendeine komplizierte Rechnung und alle sind glücklich.

Viele Grüße

Stefna

Hallo,

alles was du augezählt hast ist vor allem RAM und HDD(IO) Lastig (jeh nach Auslastung).
Wie schaut das Failover Sccenario aus? Ein server muss alles Stemmen können?
Wichtiger noch wie schaut es mit dem Shared Storrage für die VM-HDD aus? Wie groß wie schnell und wie an die Server angebunden?
Ist das Storrage auch Redundant?
Warum 3 Server? 3 Server bedeutet nicht automatisch auch mehr Leistung wenn die VM auf 3 Server verteilt sind und alles vom selben Stor läuft.
Ohne SharedStor auch kein Failover und und und.

Gruß

Chonta

Wie hier schon genannt wurde, gibts da keine Faustformel.
Du kannst im Grunde beliebig viele vCPUs haben, wenn diese dann jeweils alle nur am Idlen sind.
Wenn du allerdings mehrere Maschinen hast, die permanent viel CPU brauchen, dann musst du bedenken, das die VMs sich um die physischen Kerne streiten.
Je mehr vCPUs zugriff auf Leistung wollen, je mehr ist der ESX mit der Verwaltung mit den Anfragen beschäftigt.
Prinzipiell geht man davon aus, das bei Last-Systemen die physischen CPUs nicht mehr als 50% Durchschnittsbelastung haben sollten, da sonst durch das Warten auf die CPU die Leistung leidet.

Bei TS-Servern kommt es ganz stark darauf an, wie viel CPU so ein User benötigt. Wenn die User über den TS Surfen, viel GUI haben usw, dann braucht das meist mehr Leistung als man erwarten würde.


CPUs: viele Kerne sind gut bei vielen vCPUs. Sobald diese aber ausgelastet werden, kommt es fast nur noch auf die reine Leistung an. Je mehr GHZ du hast, desto mehr Dampf hast du auch.
Wenn man seine Umgebung überprovisioniert, dann bricht die die Performance dramatisch ein. Darauf also immer ein Auge haben.

RAM: Kann man nie genug haben. Am besten von Anfang an immer die grösssten RAMs nehmen, die es gibt. Will man später aufrüsten, muss man dann, um noch was dazu zu gewinnen, die alten idR austauschen. Das Geld hat man dann in den Sand gesetzt.
Deshalb von Anfang an: Maximaler Ausbau. Rein was geht. Was hier "zu viel" ist, gibt man dann lieber den Terminalservern. Hier gilt es Swapping um jeden Preis zu vermeiden.


SQL:
Ganz klare Empfehlung: NICHT Virtualisieren
Wenn es WIRKLICH auf die SQL Performance ankommt, sollte das doch besser auf einer eignen Maschine laufen. Lieber eine VM als Live-Mirror einrichten, so dass im Falle eines Ausfalles einfach auf die VM geswitcht werden kann. (Ich kann hier als Datenträger wärmstens eine FusionIO empfehlen. Auf den ersten Blick teuer, aber im Vergleich zu Enterprise-SSDs kaum ein unterschied, dafür aber eine abartige Performance).
Bedenke bei virtuellen VMs immer:
1. Virtualisierung bedeuted "Overhead"
2. Deutlicher Performanceverlust, wenn die vCPU der VM warten muss, bis sie an der Reihe ist. Hier kann man zwar mit Priorisierung etc am ESX gegensteuern, aber das bedeutet im Umkehrschluss auch, das die anderen Maschinen dann auf den SQL warten müssen.
3. SQL braucht LEISTUNG. Und zwar (je nach dem was da so alles gemacht wird) aus allen Bereichen:
RAM: Je mehr Tabellen im RAM liegen, desto schneller ist das System. -> Viel RAM Reserven benötigt.
IO: Logfile, Datafile, TempDB: Braucht alles jede Menge IO. Das sollte jeweils auf dedizierten Platten liegen. Das will man nicht mit anderen Teilen. Viel IO bedeutet viel Last für den Controler. Ein zentrales Storage hat dann evtl. schon zu kämpfen, da viele Anfragen reinkommen. Das wirkt sich auf die Performance der anderen VMs aus
CPU: Je nach Qualität der Anwendungen (also der Querys), Datenbankdesign und Indexierung kann hier durchaus viel CPU Power benötigt werden.


Das ist alles sehr schwer "pauschal" zu beurteilen und hängt eigentlich immer vom Einzelfall ab. Aber mMn ist virtualisierung nicht die Antwort auf alles.