Welche (Server)Hardware für diese Anforderungen

J

jm14

Guest
Hallo,

ich weiß konkrete Antworten sind mit diesen schwammigen und unzureichenden Angaben nicht möglich, ich bitte aber um Anhaltspunkte, treu nach dem Motto ".... das sollte wenn du glück hast passen...."
wink.gif


Also meine Anforderungen:
Auf dem WebServer soll eine Application und eine Datenbank laufen. (Application + Datenbank sollen dabei auf dem selben Server laufen - das ist leider nicht änderbar)
Gerechnet werden kann mit bis zu 1500 Anfragen / Sekunde. (also im worst case 1500 DB anfragen / sek)
Bei der Application handelt sich um ein shopähnliches Online-System.
Von den genannten 1500 Anfragen / Sekunde fallen daher rund 90 % auf gewöhnliches Durchbrowsen des Angebots.

Daher meine Fragen:

Wie könnte ein System aussehen, dass diesen Anforderungen genügt? (Kosten sind vorerst sekundär, das System solle jedoch nicht überdimensioniert sein)
Welche Datenbank ist zu empfehlen? (Das Datenbankdesign ist primitiv und arbeitet meist mit trivialen select abfragen)
Welche Internetanbindung ist zu empfehlen?


Ich danke für jede Hilfe!
 
Hi jm14

Ich schlage mich auch mit diesem Thema auseinander.

Ich wäre für sowas wie Load Balancing und würde die Last auf mehreren Server verteilen.
http://de.wikipedia.org/wiki/Server_Load_Balancing dort findest du noch ein paar Infos.
Ich würde dir Managed Hosting empfehlen, falls du es nicht selber machen möchtest.

Gruss, Baki
 
Das ist echt so schwamming, da fällt mir ja mal gar nichts zu ein.
Gibt es die Applikation schon? In was ist die geschrieben? Was für einen Memory Footprint hat die?
Ist das ne Web-Applikation? Welchen Memory Footprint hat der Webserver? Welcher wird eingesetzt?
Welches Betriebssystem?
Wie groß ist die Datenmenge die in die Datenbank soll?
Wo kommen die 1500 req/s her? Ist das ein Schätzwert? Bei einem neuen Projekt wird das
gewiss am Anfang nicht so viel sein.
 
QUOTE Auf dem WebServer soll eine Application und eine Datenbank laufen. (Application + Datenbank sollen dabei auf dem selben Server laufen - das ist leider nicht änderbar)


Warum ist das nicht änderbar? In deinem Fall sehe ich nämlich keine andere (geeignete) Möglichkeit... (90000 DB Anfragen pro Minute ist recht viel). Da reicht 1 Server nicht mal für die normale Application aus (also gerrechnet 10 Anfragen / Besucher ergibt das gleichzeitig ca. 9000-20000 Besucher). Wenn ich das hochrechne ergibt das schnell mal einen Traffic von 6-10 GB / Minute > Da wird allein die Anbindung schon zum Problemfaktor.

Event. Load Balancing wie erwähnt, aber dies ist ziemlich teuer (aber immer noch günstiger als der Rechner wie oben erwähnt).
Ich würde die DB und die Application trennen.

Gruss marc
 
Solche Projekte werden normalerweise wirklich nicht mehr mit einem einzigen Server bedient, schon alleine wegen der Verfügbarkeit. In dieser Projektgrösse sollte ja eigentlich auch die passenden finanziellen Mittel vorhanden sein..

Die 1500 Anfragen sind bezogen auf was? Rechnest du mit Visits oder Hits? Wenn du wirklich einen Schnitt von 1500 Visits/s hast, dann wird das einer der grösseren Onlineshops auf unserem Kontinent sein..
wink.gif



Ach ja, was verstehst du unter Shopähnlich?

Zur Technik
Ich wurde ebenfalls auf Load Balancing tendieren, da wirst du kaum drum rum kommen..
 
QUOTE (Marc Schuler @ Fr 12.1.2007, 8:55)
Event. Load Balancing wie erwähnt, aber dies ist ziemlich teuer (aber immer noch günstiger als der Rechner wie oben erwähnt).



Load Balancing muss nicht teuer sein, man kann dies sehr effizient und skalierbar ohne extra Load-Balancing Hardware realisieren wenn der Hoster mitspielt.
 
Hallo,

für Zugriffszahlen in diesm Bereich sollte man in jedem Fall Content, statische Seiten und DB trennen. Für die DB würde ich einen Cluster vorschlagen. Ein Clustersystem aus n-Servern sollte diese Anfragen bewälltigen können. Hier ist dann nur noch die Hardware und die Art der Umsetzung von Interesse. Je nach Clustersystem wird die DB teilweise komplett im Speichergehalten, daher muss dieser ausreichend gross dimensioniert sein.

Ein Beispielsystem als Platzsparende 1HE Variante könne z.B. so aussehen:
- 2 x Intel Xeon Processor 5120 (1866 MHz, 4096 KB Cache, 64Bit, DualCore, VT)
- 16 GB DDR2-RAM (8x Infineon FBDIMM 2 GB PC2-5300 ECC)
- 4 mal 36,7 GB Fujitsu (8 MB Cache/15.000 UPM/SCSI U320) im RAID

Wert gelegt wurde hier vor allem auf schnelle Platten, da diese die Anfragen auch transportieren können. Aus Netzwerksicht sollten die Systeme untereinander mittels Gbit angebunden werden um auch hier die nötigen Ressourcen zur Verfügung zu haben.

Alternative wäre ein grosses System als zentraler Datenspeicher. Da man hier aber auf gute Ausfallsicherheit achten muss, wird dies nicht so günstig sein wie ein Clustersystem.
 
Bei den Anfragen weiß ich nicht genau was damit gemeint ist, waren damit 1500 Datenbankabfragen pro Sec gemeint?
Also wir haben auf einem Server im Schnitt so um die 100 Sql-Anfragen pro Sekunde, da es sich um einen Durchschnittswert handelt und in der Nacht nicht ganz so viel los ist dürften 1500 pro Sekunde durchaus oft vorkommen und nicht das Problem sein. Ich nehme mal an, das hier im Forum etliche noch wesentlich mehr Anfragen pro Sekunde haben.
Db und Applikation ist dabei auf einem Server (Xenon Dualcore, Raid 5, insgesamt nicht so schnell wie ein neues System) und das ist im Moment kein Performance Problem. Die DB auf einem getrennten Server zu haben ist aber sicher immer gut.
Bei 1500 Visits pro Sekunde würden wir aber schon ein Problem haben, aber das ist eine andere Geschichte….
 
Ich danke erstmal für die reichlichen Antworten!

Ich habe aus euren Antworten Schlüsse gezogen und daraus enstand quasi ein "neues" Anforderungsprofil:

Und zwar soll auf dem Server eine Application mit Datenbank laufen wobei mit rund 120 transactions / sekunde zu rechnen ist.

Kein Shop mehr.

Ich bräuchte neben Hardwareangaben für den Server auch einen Vorschlag für eine genügende Internet-Anbindung.

Vielen Dank nochmals für die zahlreichen brauchbaren Antworten.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben