Erfahrungen Performance Web- <-> SQL-Server über VPN?

peterle

Forenkasper
Im bisherigen Setup habe ich in beiden Servern zwei Netzwerkkarten stecken. Die ersten sind für die Anbinung ans Internet und die zweiten treffen sich in einem Switch zu einem privaten Netzwerk.

Nun muß ich den alten Plunder langsam mal umbauen und überlege zwar im Webserver noch eine zweite Karte zu lassen, aber die nicht gebrauchte Internetverbdinung im SQLserver als VPN anzubinden.

Die Frage ist nur, ob das Performanceprobleme geben wird oder ob ich die einfach vernachlässigen kann?
 
Also, du hast einen Server A (Web) und B (SQL). Nun soll A direkt ans Internet und du möchtest, dass A und B über ein VPN kommunizieren? Also ein VPN innerhalb deines privaten Netzes? Das wäre meiner Meinung nach ziemlich unsinnig, wenn die ohnehin hinter einem Switch verschwinden.

Steht denn hinter dem Switch noch ein Router?
 
Stehen die Server irgendwo in einer Collo oder bei dir zu Hause?

Webserver:
- Karte 1 = Internet
- Karte 2 = Ungenutzt

SQL-Server:
- Karte 1 = VPN?
- Karte 2 = Ausgebaut?

Verstehe die Ausgangsfrage nicht.
Ansonsten sind da eher so die Standardfragen:
- Welche Datenbank?
- Wie viele Requests?
- Was für eine Anwendung? (Wenn du für "jede" Aktion ein Request brauchst (bspw. dynamisches CMS), dann würde ich abraten...)
- Wo stehen die Rechner denn (gleiches RZ, im Keller...)

Gruß
Markus
 
Aktuell steht das alles in einem RZ.

Nun soll das ggf. auf verschiedene RZ verteilt werden.

Webserver:
- Karte 1 - Internet
- Karte 2 -> Switch 192.168.x.x -> - Karte 2
- Karte 1 Internet
SQLserver

Da gehen ein paar Requests in der Minute durch. So wie es jetzt ist, ist es auf jeden Fall performant und es scheitert sicherlich nicht an den 100Mbit Karten, da läuft eher der RAM voll.
 
Irgendeine bestimmte Applikation?
Welche Datenbanksoftware?

Ansonsten: Warum mehrere Rechenzentren? Warum mehrere Server?
Gruß
Markus
 
vbulletin mit MySQL

Mehrere Server, weil man vb mit MySQL auf einem Server als Gute Nacht Geschichte nutzen kann, aber nicht um ein paar Tausend Menschen pro Tag mit Informationen schnell zu beliefern.

Mehrere Rechenzentren oder weitere Abstände zwischen Servern, weil ich flexibler gegenüber den Anbietern bin.
 
Inwiefern denn flexibler? Wenn der eine dichtmacht, geht mit dem tollen Setup dann trotzdem nichts.
 
Hallo Peterle,

ich bezweifel, dass das eine gute Idee ist. Je nach Rechenzentrum und Anbindung zueinander, hast du eine "recht" hohe Latenz zwischen den beiden Servern.
In der Regel bieten alle Provider Testserver an, bei denen du Test-Downloads und Pings durchführen kannst, um eine ungefähre Abschätzung zu machen, wie die Verbindung zwischen deinem alten Anbieter und einem neuen wäre.

Bei einem Forum ist ja jeder Thread, jede Ansicht usw. dynamisch aus der DB generiert, das heißt es kommt schon auf die Zugriffszeit an.
Ich weiß auch nicht, ob vBulletin die Anhänge in der DB speichert (auch hier müsste jeder Download von beiden Servern bearbeitet werden) oder lokal verarbeitet (Webserver)

Wenn du jetzt von mehreren Tausend Menschen pro Tag sprichst, würde ich dir mehr empfehlen, das ganze lokal auf innerhalb des Rechenzentrums aufzubauen, damit die Latenz zwischen Web- und DB-Server minimal ist.

Ob du wirklich zwei Server brauchst, musst du selbst für dich feststellen. Ich habe sehr viele Jahre ein Forum (damals noch phpBB) auf einem einzelnen Server betrieben und dort waren auch mehrere Tausend Besucher am Tag und viele Anhänge. Heute läuft das Forum unter vBulletin, aber auf eben einem Server.

Gruß
Markus
 
Das mit dem HA für Arme war eine von den Überlegungen.

Meine Erfahrungen mit vb und sql auf einem Server sind nett, aber irgendwie immer zu langsam.

Was waren denn das damals für Server?

Momentan sind das bei Hetzner zwei i7 mit 12GB RAM und an dem scheitern erst die Webserver. Mit nur einem Server scheitern wir vor allem an der Disk-Performance.
 
Ich glaube Core i7 920 mit ca. 16 GB RAM.

Warum Diskperformance?
Habt ihr mal Analysen gefahren?
Wie groß ist denn eure Datenbank?
Habt ihr MySQL? Je nach Konfiguration kann man große Teile der DB in den Speicher legen - daher die Frage, was an Optimierung gelaufen ist.
Um wieviele User handelt es sich denn?

Gruß
Markus
 
Die Datenbanken haben zusammen ca. 8GB, dazu kommen noch ein beträchtlicher Teil an Bildern und Anhängen, was vielleicht nochmal ca. 30 GB ausmacht.

Wenn Du es genau wissen willst, sagen die Statistiken aktuell:
Benutzer: 119.659
Themen: 154.466
Beiträge: 2.031.632
Fotos: 74.013

In Hochzeiten sind pro Tag ca. 30.000 unique users da und brauchen im Schnitt was um die 4 bis 5 Seiten, blöderweise verteilen die sich nicht gleichmäßig. :p
 
Hallo Peterle,

das ist ja schon ordentlich! Hast du denn jetzt MySQL oder PostgreSQL?

Ich bin weiterhin der Meinung, dass du keine Lösung mit zwei Rechenzentren brauchst und möchtest, da du wie gesagt, bei dynamischen Zugriffen pro Request die Roundtime zwischen den Servern mit einbeziehen musst.

Ich habe zwei Server bei myLoc, die untereinander ähnlich wie bei mir zu Hause < 1ms aufeinander zugreifen können.
Von den Servern bei myLoc zu Hosteurope und netcup sind es jeweils 10 ms...

Ich würde dir weiterhin raten, dass du bei einem Provider bleibst.
Als neuen Server würde ich dir dann einen raten, der neben Datenplatten auch SSDs enthält, wobei bei der geringen Größe aktuell auch 2 x 256 GB SSD reichen würden.
Diesen Server optimierst du (Caching, Datenbankkonfiguration...).
Wenn es dann wirklich am IO liegt - also die Zugriffsarten Dateizugriff für statische und Datenbankzugriffe für dynamische sich so stark beeinflussen, dass spürbare Verzögerungen auftreten kannst du im gleichen RZ einen zusätzlichen Server aufstellen und eine Trennung anstreben.

Auch zwischen zwei Providern würde ich für Datenbankzugriffe kein VPN aufbauen, sondern auf die Funktionalität der Datenbanksoftware zurückgreifen.
Das heißt: Konfiguration der Allowed Hosts (zusätzlich kannst du natürlich auch noch ipfw / pf nehmen), sowie SSL-Verschlüsselung. Falls vBulletin das unterstützt, können die gängigen Datenbanksysteme auch zertifikatsbasierte (am Client) Authentisierung.
Nachteil der Lösung: Die Server können sich nur über das DB-Protokoll unterhalten - aber das ist ja auch Sinn des Ganzen.

Gruß
Markus
 
Zurück
Oben