MySQL auf zweitem Server?
0 
Marc Reichelt
0 0 0 dedlfix
MySQL auf zweitem Server?
Hallöle,
ist es eine sinnvolle Lastverteilung, wenn die DB auf einem zweiten Server läuft?
Während PHP auf die Antwort von MySQL wartet, müsste der PHP- Rechner doch für weitere Requests mehr Zeit haben?
Oder frisst das Handling für das Übertragen diesen Zeitvorteil wieder weg?
Aus Sicherheitsgründen kann es dennoch sinnvoll sein. Wird der PHP- Server gehackt, ist die DB nicht automatisch betroffen.
Gruß, Kalle
-
Hallo Kalle_B,
Aus Sicherheitsgründen kann es dennoch sinnvoll sein. Wird der PHP- Server gehackt, ist die DB nicht automatisch betroffen.
Das ist so nicht korrekt. Wenn der PHP-Server gehackt ist, gelten auch die Zugangsdaten zum MySQL-Server als gehackt. Kein Problem also. ;-)
Grüße
Marc Reichelt || http://www.marcreichelt.de/
--
DPRINTK("Last time you were disconnected, how about now?");
linux-2.6.6/drivers/net/tokenring/ibmtr.c
Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:) -
Hi,
Während PHP auf die Antwort von MySQL wartet, müsste der PHP- Rechner doch für weitere Requests mehr Zeit haben?
Während das PHP-Script „wartet“, bleibt eine Verbindung zum Client geöffnet.
MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]-
Während das PHP-Script „wartet“, bleibt eine Verbindung zum Client geöffnet.
Was willst du damit sagen? Kann Apache nur eine Verbindung zur Zeit haben?
-
Hi,
Während das PHP-Script „wartet“, bleibt eine Verbindung zum Client geöffnet.
Was willst du damit sagen? Kann Apache nur eine Verbindung zur Zeit haben?
Nein, aber er hat ein Limit, was die Anzahl gleichzeitig offener Verbindungen angeht.
MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]-
Hi,
Nein, aber er hat ein Limit, was die Anzahl gleichzeitig offener Verbindungen angeht.
Gut, dann also nochmal die Frage, etwas anders formuliert:
Wenn 10 (20, 50, ...) Anfragen nahezu gleichzeitig reinkommen. Ist der PHP- Server dann schneller fertig, wenn der MySQL- Teil auf einem separaten Rechner erledigt wird?
Wäre eigentlich logisch, zwei schaffen schneller als einer ...
Gruß, Kalle
-
-
-
-
Moin Moin!
Wie immer: It depends.
ist es eine sinnvolle Lastverteilung, wenn die DB auf einem zweiten Server läuft?
Ja, oft, aber nicht immer. Es ist jedenfalls ein gängiges Setup für größere Web-Anwendungen (nicht nur PHP/MySQL), Webserver und DB-Server auf zwei verschiedene Maschinen zu legen. Damit ist es oft auch möglich, einfach zwei oder drei identische Webserver auf die selbe DB zugreifen zu lassen und vor die Webserver einen Loadbalancer zu stellen. Genau dieses Setup läuft seit fast 10 Jahren bei einem meiner früheren Arbeitgeber zur Zufriedenheit aller.
(In dem Setup gibt es außerden noch einen dedizierten Fileserver, der den Webservern größere Datenmengen außerhalb der DB bereitstellt.)
Während PHP auf die Antwort von MySQL wartet, müsste der PHP- Rechner doch für weitere Requests mehr Zeit haben?
Nicht Zeit, sondern Resourcen. Die Arbeit, die die DB macht, entfällt und steht der Web-App zur Verfügung.
Oder frisst das Handling für das Übertragen diesen Zeitvorteil wieder weg?
Damit hast Du genau den Knackpunkt getroffen. Wenn Du riesige Datenmengen aus der DB ziehen mußt, kann die Verbindung zwischen Web-Server und DB-Server zum Nadelöhr werden. In der Regel ist es aber so, dass man möglichst viel innerhalb der DB anstellt und dann nur die Daten wirklich aus der DB holt, die letztlich beim Browser landen. Wenn man riesige Mengen aus der DB zieht, um dann zwei oder drei Zahlen zum Browser schickt, macht man etwas grundsätzlich falsch, vermutlich angefangen bei der DB-Struktur.
Eine dedizierte Verbindung zwischen DB- und Webserver (Crossover-Kabel und/oder Gigabit Ethernet) ist auf jeden Fall sehr hilfreich. Über PPP und RS232 würde ich so ein Setup jedenfalls nicht fahren wollen. ;-) So ein privates DB-Netz reduziert auch die Angriffsmöglichkeiten auf die DB, die explizit so eingestellt wird, dass sie nur auf Anfragen aus dem privaten DB-Netz reagiert.
Aus Sicherheitsgründen kann es dennoch sinnvoll sein. Wird der PHP- Server gehackt, ist die DB nicht automatisch betroffen.
Doch, ist sie. Sobald ich den Programmcode analysieren kann, kenne ich auch den Weg, auf die DB zuzugreifen. Und damit hast Du verloren. Egal, ob Du PHP, Java, Perl, C, C++, VB.NET oder Assembler einsetzt. Du kannst es mir mit einigen Techniken etwas schwerer machen, Deinen Code zu analysieren, aber Du kannst es nicht verhindern.
Wenn Du Dein System (egal ob 1 oder 2 Server) sicher machen willst, sorg erst einmal dafür, dass es möglichst wenig Angriffsflächen gibt:
* Alle Eingaben als Angriff werten, bis das Gegenteil durch einen mathematischen Beweis bewiesen ist. Triviales Beispiel: Eine Altersangabe sollte auf /[1]+$/ matchen, meinetwegen auch noch strenger auf /[2]{1,3}/ oder auf /[3][0-9]{0,2}$/, nach der Umwandlung in einen Integer sollte der Wert >=0 und <130 sein. Ist auch nur eine Bedingung nicht erfüllt, wird die Eingabe nicht angenommen.
* Möglichst wenige Services laufen lassen. Beispiel: IRC hat auf einem reinen Webserver nichts verloren, ebenso wenig ein SVN-Repository oder ein Game-Server.
* Keine bekannt unsicheren Services laufen lasssen: Beispiele: rsh, rlogin, rexec auf gar keinen Fall. Telnet und FTP besser durch SSH ersetzen.
* Services so sicher wie möglich konfigurieren. Beispiel: SSH nur mit Protokollversion 2, root-Login ausschalten, Passwort-basiertes Login ausschalten, nur Public Key Login erlauben.
* Keine unnötigen Optionen aktivieren. Beispiel: Wenn der Webserver nur FastCGI braucht, haben mod_proxy, mod_php, mod_perl, mod_rewrite und mod_speling dort nichts verloren.
* Keine unnötigen Informationen preisgeben. Beispiel: Apache kann sich mit Versionsnummer plus jedem Modul plus Betriebssystem identifizieren (ServerTokens Full). Besser konfiguriert hält der Apache aber die Klappe und verrät nur so viel wie absolut nötig (SererTokens ProductOnly). Idealerweise würde der Apache gar nichts verraten, aber das geht nur mit Eingriffen in den Code. Anderes Beispiel:use CGI::Carp qw(fatalsToBrowser)gibt im Fehlerfall möglicherweise sehr viele Informationen über die Programmstruktur preis.Dann solltest Du einen fähigen, guten Freund bitten, Dein System anzugreifen, so hart und so böse wie möglich. Laß ihn alle Informationen zukommen, die er haben will (Konfigurationsdateien, Programmcode, ... -- denn genau das wird sich auch ein echter Angreifer besorgen), bis auf Passworte und SSH-Keys. Idealerweise scheitert er kläglich. Für den Lerneffekt ist es aber besser, wenn er in das System reinkommt und Dir die noch vorhandenen Lücken aufzeigt.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
-
Hi!
Wenn man riesige Mengen aus der DB zieht, um dann zwei oder drei Zahlen zum Browser schickt, macht man etwas grundsätzlich falsch, vermutlich angefangen bei der DB-Struktur.
Spezielle Ergänzung zu MySQL: Auch dann, wenn das Ergebnismengen-Abholen unbemerkt im Hintergrund läuft.
mysql_query(SELECT * FROM tabelle WHERE ...);
Anzahl = mysql_num_rows(); // als einziges interessierendes Datum der Abfrage.Bei mysql_query() findet bereits im Hintergrund eine Übertragung der gesamten Ergebnismenge zum Client statt. Nur deshalb ist es mysql_num_rows() möglich, die Anzahl der Datensätze zu kennen. SELECT COUNT(*) hingegen liefert als Ergebnismenge nur einen Wert.
Lo!
-