Server Last Abschätzen

D

dragonknight

New Member
Hi,
hab nach zwei Tagen suchen im Netz nichts gefunden, was mir weiter hilft.
Einer meiner Kunden hat mich gebeten ihm eine Liste von dedizierten Servern zusammen zu stellen und dazu zu schreiben, wie viele User so ein Server auch verkraften kann.
Ich weiß beim besten willen nicht, wie ich das schaffen soll.

Zur Anwendung:

1. vhost: Joomla 1.5 als Portal Seite
2. vhost: Mantis Bugtracker
3. vhost: MyBB Forum
4. vhost: Software auf Basis von Zend Framework

Auf dem Server werden folgende Daemonen laufen:
Apache2 + PHP5 entweder via FCGI oder als modPHP
MySQL 5 als Cluster oder per Replikation
ProFTPd
Postfix
SpamAssassin*
Courier-Imapd*
Courier-Imapd-ssl*
Courier-Pop3*

*nicht auf allen Servern installiert

Als Betriebssystem plane ich Debian 5 oder die neueste Ubuntu Server OS Version.
Die Server sollen in verschiedenen Rechenzentren stehen um Ausfallsicherheit zu erreichen.

So viel zur Basis.
Jetzt meine eigentlichen Fragen:
1. Wieviel Ram/Systemleistung braucht ungefähr ein Kunde der über das Internet auf den Server zugreift (rein Webzugriff, da die anderen Dienste nur für die Mitarbeiter verwendet werden.).
Den meisten Zugriff wird die Application auf Basis von ZF produzieren, da die das Kerngeschäft meines Kunden darstellt.
2. Was ist auf Frage 1 bezogen besser: modPHP oder PHP via FCGI
3. Als Datenbankend verwende ich MySQL in der aktuellen 5er Version.
Um die Server syncron zu halten dachte ich an entweder Clustering oder Replikation.
Allerdings hab ich gelesen, das die größe der Datenbank = dem erforderlichen Arbeitsspeicher ist. (Bei Clustering).
Bei Replikation, wie lange dauert es da, bis die Server Syncron laufen?
Wird das per Cron Job gefahren?

Ich weiß das das recht schwer ist zum einschätzen, aber der Kunde will halt einen Leitfaden haben, welchen Server er mietet (Server Ausstattung).

Bin für jede konstruktive Hilfe dankbar.

dragonknight
 
Aus den gelieferten Infos kann man leider nichts sagen.

Es hängt von der jeweiligen Applikation ab, wie viel Systemresourcen jeweils benötigt werden.
 
1. vhost: Joomla 1.5 als Portal Seite
2. vhost: Mantis Bugtracker
3. vhost: MyBB Forum
4. vhost: Software auf Basis von Zend Framework

Das hilft nicht wirklich etwas, ohne Zugriffszahlen. Wenn alle nur 10 Aufrufe haben, wird der Server nur idlen. Aber wenn eine Anwendung hunderttausend Anfragen am Tag hat, sieht das schon wieder ganz anders aus.

Zum Thema PHP: Bei Apache ist mod_php das Schnellste, da es nun mal Bestandteil von Apache ist.

Hast du eventuell schon überlegt einen anderen Webserver als Apache einzusetzen? Lighttpd oder Nginx? Denn Lighttpd hat mit PHP über fastcgi eindeutig die Nase vorn.
 
Last edited by a moderator:
Ok,
hab ganz vergessen die Benutzer zahlen einzutragen.
Naja, der Kunde rechnet so mit bis zu 250.000 Benutzer die in der Regel die Plattform zwischen 8 und 20 Uhr benutzen.
Der Server selbst soll nach Möglichkeit eine MultiCore CPU haben.
(Ich achte schon darauf, dem Kunden ist dies Egal.)
Das mit Lighttpd ist mir auch schon gekommen.
Ich muß halt innerhalb kürzester Zeit eine ungefähre Abschätzung abgeben, wie viel User der Server verträgt.
Das ist vor allem wichtig, da der Kunde den Preis für die Dienstleistungen errechnen möchte.
Was ich bei FCGI und FCGID nicht ganz versteh, reichen da die 2 automatisch Startenden Prozesse für nur alle User oder startet FCGI pro User einen eigenen Prozess.


Ich hatte mir heut ein paar Gedanken selbst schon gemacht.
Dachte an 4GB Ram für 1000 User.
(MySQL + Lighttpd + FCGId + PHP5 (.ini mit 32-64MB PHP eigenen Speicher + APC oder eAccelerator)
 
Der Vorteil beim fastcgi ist, dass nicht für jeden Benutzer ein extra PHP-Prozess gestartet wird, sondern lighttpd kontaktiert über fastcgi PHP, wenn es für die Anfrage benötigt wird.

Die Abschätzungen unter der Seite sind sehr realistisch. Natürlich ist es von System zu System unterschiedlich, aber im groben und ganzen stimmt das schon mit der Realität überein.

Was natürlich ein K.O.-Punkt sein könnte, wäre das lighttpd keine .htaccess unterstützt. Sprich rewrite-rules müssen vom Administrator definiert und eingebunden werden.
 
dragonknight said:
Bei Replikation, wie lange dauert es da, bis die Server Syncron laufen?
Wird das per Cron Job gefahren?
Click to expand...

Der Slave ist permanent mit dem Master verbunden. Sobald ein Query auf dem Master ausgeführt wird, kommt der in den Binlog und der Slave führt diesen nahezu in Echtzeit aus. Eine Sache von Millisekunden. Ohne Chronjob.
 
dragonknight said:
3. Als Datenbankend verwende ich MySQL in der aktuellen 5er Version.
Um die Server syncron zu halten dachte ich an entweder Clustering oder Replikation.
Allerdings hab ich gelesen, das die größe der Datenbank = dem erforderlichen Arbeitsspeicher ist. (Bei Clustering).
Bei Replikation, wie lange dauert es da, bis die Server Syncron laufen?
Wird das per Cron Job gefahren?
Click to expand...


Clustering bei Mysql?
Mysql untersützt per se keine Clusterlösung.
Es gibt Ansätze wie Master Master Replikation oder mysql-proxy, dieses wiederum ist nicht sehr sicher.
Es kann hierbei zu inkonsistenzen im Datenstamm kommen.
Eher selten, da die Replikationen i.d.R. zuverlässig ist. Aber Bugs wie z.B. im Release 5.1.48 http://bugs.mysql.com/bug.php?id=53893
können einem das Leben schon schwehr machen.

Im Bezug auf "hohe" Verfügbarkeit gibt es einen halbwegs brauchbaren Weg.
Man kann den Storage z.B. per drbd syncen und im Falle eines Ausfalles die Node auf der 2. Umgebung anstarten.

Da es aber auch vor kommen kann, dass Mysql verstirbt oder im laufenden Betrieb die Datenfiles zerschiesst, sollte man immer einen "Medienbruch" einplanen.
*Ein wirklicher Medienbruch wäre ein gänzlich andere Medium zu verwenden z.B. Festplatte -> DVD.

Hier baut man also 2 Hosts auf, deren Storage per drbd gesynct wird.
Ein 3. host oder wenigstens eine dritte Mysql Instanz wiederum wird als Slave repliziert.
Im Falle eines Plattencrashes oder FS Crashes... ist die Replikation nicht davon betroffen und man kann relativ schnell die Daten der 3. Instanz auf den prod. Server kopieren und den Betrieb wieder aufnehmen.

Recovery über Binlogs ist i.d.R. ebenfalls eine alternative dauert aber ggf. zu lange, sofern es im Falle eines Platten / FS / File crashes noch anwendbar ist.

Wie kommst Du darauf, dass der RAM für die Mysql der Datenmenge entsprechen muss?
Das ist häufig gar nicht mehr möglich. Weil die Datenmengen dem physisch möglichen RAM oft übersteigen. Natürlich wäre das Ideal, allein wegen der Performance, aber es geht oft genug nicht.

Achja, bei der oben skizzierten Lösung mit gesynctem Storage:

Die Systeme sollten über min. ein 2. tes Netzwerkinterface miteinander verbunden sein.
Über das öffentliche Netz sollte man den Sync aus sicherheits und Performance Gründen nicht durchführen.

Es gibt nun genau genommen 2 Fallback Szenarien:

1. Eine Node ist immer innaktiv. Das System läuft, der Storage ist gesynct, aber auf einer Node sind ansonsten keine Dienste gestartet.
Erst bei einem Ausfall wird die andere Node gestartet.
-> Als Produkt sei hier heartbeat bzw. pacemaker genannt, welche die Dienste überwachen und einen Failover einleiten können.

2. Beide Nodes werden als Applicationserver genutzt. Also auf beiden Nodes laufen bis auf Mysql alle Dienste. Ein Loadbalancer verteilt dann die Requests auf beide Nodes.
(Für schreibende Dienste wie Mailsever, Uploadserver wird dann ein Clusterfilesystem wie z.B. ocfs2 benötigt. Damit die Daten im sync bleiben. Für den Mysqlserver ist das nichts! Dieser sollte nur auf dem aktiven Node beschreibar sein bzw. auch nur dort gemountet sein.)

Der Zugriff auf die DB erfolgt dann übers Netz. Hier nutzt man dann entweder das. 2. Interface welches schon für drbd
sync genutzt wird oder besser, spendiert dem Servere eine 3. NIC.
Nachteil ganz klar, Netzwerkverbindungen sind langsamer und etwas resourcenaufwendiger als Socketverbindungen über localhost.
Zum Switch der Node und DB, wird dann z.B. die /etc/hosts ausgetauscht, sodass die URL zur DB immer auf den aktiven Host zeigt.
 
Last edited by a moderator:
das System soll eh kein Massenhost werden, somit hat sich das mit Mod Rewrite eh erledigt, da ich nur die Regeln vorgebe.

Zu der Aussage das MysQL das Clustering nicht unterstützt verwundert mich.

Im MySQL Handbuch

http://dev.mysql.com/doc/refman/5.1/de/ndbcluster.html

steht drinnen das 5.1 es unterstützt.
Hab gerade auf einem meiner Server nachgeschaut und dort läuft die Version 5.1 wenn ich mich nicht stark täusche.
Aber ich kann mich auch irren, deshalb erkundige ich mich auch im Forum.
 
ndb ist eine eigene Storage Engine.
Das hat mit dem Mysql Basisystem erstmal nicht viel zu tun, ausser, dass es eben durch Mysql genutzt werden kann.
Für aussenstehend mag das befremdlich sein, aber in den Kernel aufgenommene Komponenten haben mit dem Kernel per se auch nichts zu tun sind eigenständige Produkte wie z.B. drbd.
Aber auch hier ist das Clustering eben nicht ganz das, was man sich unter Clustering vorstellt.


Och sehe es eher als eine Art Cloudcomputing statt als Cluster Lösung an.

Ich komme aber später nochmals zurück zum Thema bin lediglich auf dem Sprung. Lies Dir mal genau durch, wie das funktioniert und Frage Dich, was Du von einem Cluster erwartest.
Failover, redundante Datenhaltung für ein Worst Case Szenario.

Ein System muss die Verwaltung übernehmen und es kann im Falle eines Ausfalles eben nicht ein System Autark arbeiten wie es z.B. ein Oracle Real Application Cluster macht.

Zudem fehlt mir der Sync des Storages auf FS ebene.
 
Korrekt. MySQL unterstützt Clustering. Dafür gibt es doch extra das Produkt MySQL Cluster und die entsprechende Storage Engine ndb. Habe sebst einen MySQL-drei-Server-Cluster testweiße aufgesetzt: zwei MySQL-Server und ein Management Server. Dazu kommen dann natürlich noch Loadbalancer. Ein HowTo gibt es auf howtoforge.de, wobei die MySQL Dokumentation ausreichend gut ist.

Edit: zu langsam :-/
 
Im moment spiel ich mit dem Gedanken das als Replication laufen zu lasen.
Wie schauts dann eigentlich aus, wenn jemand sagen wir auf einem Slave Server ein update vornehmen würde.
Läuft das dann zuerst auf dem Master und dann auf den Slaves?
Oder Updated der Slave dann den Master?
Ich blick da nicht ganz durch
 
Bei einer Master-Slave-Replikation dürfen/können nur auf dem Master Schreioperationen ausgeführt werden. Der Slave ist ausschließlich für Leseoperationen. Möchtest Du auf beiden Schreibenoperationen ausführen musst Du eine Master-Master-Replikation einrichten. Bei dieser replizieren die MySQL-Server sich gegenseitig.
 
DerMitSkill said:
Bei einer Master-Slave-Replikation dürfen/können nur auf dem Master Schreioperationen ausgeführt werden. Der Slave ist ausschließlich für Leseoperationen.
Click to expand...

Jaein,

technisch gesehen, muss man sich um die Unterbindung, durch setzen eines write Locks, selbst kümmern.
Manchmal kann es auch sinnvoll sein, Operationen auf dem Slave durch zu führen z.B. statistische Auswertungen. Dann ist es ggf. auch ganz legitim auf dem Slave Writes durch zu führen.
Allerdings sollte man dieses natürlich in Tabellen, welche repliziert werden tunlichst vermeiden. Constraintverletzungen unterbrechen die Replikation. Vom Inkonsistenten Datenstamm mal abgesehen.


Die Replikation Master Slave läuft also nur in eine Richtung ab.
Der Master schreibt, der Slave holt sich die Änderungen und übernimmt diese.
Mysql untertsützt aber nach meinem Kenntisstand keine transaktionsichere Replikation.
-> Client liefert per Insert,Update Daten und werden auf dem Master verarbeitet, Daten werden auch auf dem Slave verarbeitet, der Client erhält erst dann die Meldung "Alles erledigt und i.o."
 
Last edited by a moderator:
Es gibt eine einfache Methode ohne viel Aenderung am Quellcode ein Master-Slave Setup statt Master-Master zu benutzen.
mysql-proxy unterstuetzt sog. r/w-splitting. Der Client verbindet sich -in der Annahme dass er direkt mit dem MySQL-Server redet- auf mysql-proxy welcher alle Lese-Operationen transparent an den Slave weiter reicht waehrend entsprechende Schreib-Operationen (ebenfalls transparent) an dessen Master geleitet werden.

Dieses Setup ist jedoch -wie jede Replikation- nur als "eventually consistent" zu bezeichnen da es zeitliche Verzoegerungen zwischen Master und Slave gibt.
Der notwendigen Programmierstil etspricht in etwa dem beim Einsatz des "delayed"-Keywords. Folgendes koennte zb passieren
SELECT `a` FROM `tabelle` WHERE `id` = 1 <-- a = 2
UPDATE `tabelle` SET `a` = 5 WHERE `id` = 1
SELET `a` FROM `tabelle` WHERE `id` = 1 <-- a = 2
[... 1 Sekunde spaeter ...]
SELET `a` FROM `tabelle` WHERE `id` = 1 <-- a = 5
 
d4f said:
Es gibt eine einfache Methode ohne viel Aenderung am Quellcode ein Master-Slave Setup statt Master-Master zu benutzen.
mysql-proxy unterstuetzt sog. r/w-splitting. Der Client verbindet sich -in der Annahme dass er direkt mit dem MySQL-Server redet- auf mysql-proxy welcher alle Lese-Operationen transparent an den Slave weiter reicht waehrend entsprechende Schreib-Operationen (ebenfalls transparent) an dessen Master geleitet werden.
Click to expand...

Da wäre ich aber ggf. verleitet, eine Master-Master Replikation aufzubauen und einen möglichen Ausfall einer Node direkt ab fangen zu können.
 
Ok,
wie ich dem Thread entnehme ist MySQL nicht unbedingt für eine größere Applikation geeignet (größer == viele Server, gleicher Datenbestand).
Wie schauts denn dann eigentlich mit pgsql?
Postgres wird ja in einigen Foren hoch gelobt.
Was haltet ihr davon?
 
Postgres bringt vieles mit, was man von Datenbanken erwartet und orientiert sich in einigen Dingen an der "Oracle" und anderen grossen DBMS.
Leider ist die Akzeptanz noch nicht so gross, es gibt halt noch viele opensource Projekte, welche postgres nach wie vor nicht untersützen.

Für die eigene Entwicklung würde ich allerdings postgres bevorzugen.
Die Hürde ist jedoch gegenüber Mysql doch auch etwas höher. Zudem erfordert die postgres mehr diszilin bei der Erstellung Datenbankdesign, als z.B. mysql.
Fängt also schon damit an, dass man Constraints pflegen muss / sollte. Was Mysql AFAIK nur mit der InnoDB kann.
Aber auch hier nur in einem recht abgespeckten Rahmen wie z.B. Fremschlüssel Verweise.

Mit der Cluster Funktionialität bei postgres habe ich mich noch nicht näher befasst. Aber auch hier scheint es nur so zu sein, dass die Daten auf mehreren Knoten verteilt (Partitioniert) werden. Aber nicht redundant auf allen Knoten zur Verfügung stehen.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top