Welchen Server kaufen & Setup

Grüßt euch,
benötige mal ein wenig Beistand von jemandem, der von Servern Ahnung hat. Wir stehen kurz vor dem Release unserer App, aktuell läuft alles noch über einen Webserver bei 1&1, aufgrund von bestimmten Anforderungen im medizinischen Bereich wo wir uns bewegen und einigen weiteren Modulen die wir im Rack verbauen müssten (für die Verbindung zu den Krankenkassen), müssen wir uns eigene Server anschaffen. Platz im Rechenzentrum haben wir bereits mit 10 Höheneinheiten im Rack.

Der Traffic lässt sich aktuell noch nicht wirklich einschätzen. Was wir machen ist jedoch nicht sehr CPU & RAM lastig, es basiert fast ausschließlich auf Web / API Abfragen, eine gewisse Größe es CPUs benötigen wir jedoch, da später recht CPU-lastige Aufgaben darüber laufen werden.

Ich hab mir nun überlegt, insgesamt 2 Server zu verbauen, einerseits als Backup falls einer durch brennt, andererseits (während beide funktionieren) als Load Balancing. Ein etwas größerer und ein etwas kleinerer. Unserer Architektur würde rein über Linux bzw. einen LEMP Stack laufen, ggf. auf Debian.
Habe die 2 Server hier raus gesucht:
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]

Lässt sich damit arbeiten? Sobald wir CPU-lastige Aufgaben durchführen, würden wir evtl. noch mal den zweiten Server upgraden, das liegt jedoch noch etwas in der Ferne, vor erst eben reiner Web-Server der hauptsächlich SQL & PHP Tasks auszuführen hat.
Was ich mich aktuell vom Setup her noch frage - habe meinen Ursprung in der Softwareentwicklung, habe nur ein Grundverständnis von Serveradministration - wie würde das Load Balancing mit unserer Datenbank funktionieren bzw. wie funktioniert das Synchronisieren der Daten? Wenn ich das richtig verstanden habe ist Load Balancing erstmal nichts anderes als den Traffic auf zwei Server/IPs zu verteilen. Wie sähe dann aber die Synchronisation der Daten aus? Ist das umsetzbar? Oder lieber doch einen richtig dicken Server, dafür ohne Load Balancing, und einen kleineren als Backup, auf den wir umswitchen falls der dicke durchbrennt?

Wäre top, wenn jemand meine Verwirrung ein wenig lösen könnte :handsdown:

Quote:

Originally Posted by i0N Grüßt euch, benötige mal ein wenig Beistand von jemandem, der von Servern Ahnung hat. Wir stehen kurz vor dem Release unserer App, aktuell läuft alles noch über einen Webserver bei 1&1, aufgrund von bestimmten Anforderungen im medizinischen Bereich wo wir uns bewegen und einigen weiteren Modulen die wir im Rack verbauen müssten (für die Verbindung zu den Krankenkassen), müssen wir uns eigene Server anschaffen. Platz im Rechenzentrum haben wir bereits mit 10 Höheneinheiten im Rack. Der Traffic lässt sich aktuell noch nicht wirklich einschätzen. Was wir machen ist jedoch nicht sehr CPU & RAM lastig, es basiert fast ausschließlich auf Web / API Abfragen, eine gewisse Größe es CPUs benötigen wir jedoch, da später recht CPU-lastige Aufgaben darüber laufen werden. Ich hab mir nun überlegt, insgesamt 2 Server zu verbauen, einerseits als Backup falls einer durch brennt, andererseits (während beide funktionieren) als Load Balancing. Ein etwas größerer und ein etwas kleinerer. Unserer Architektur würde rein über Linux bzw. einen LEMP Stack laufen, ggf. auf Debian. Habe die 2 Server hier raus gesucht: [Only registered and activated users can see links. Click Here To Register...] [Only registered and activated users can see links. Click Here To Register...] Lässt sich damit arbeiten? Sobald wir CPU-lastige Aufgaben durchführen, würden wir evtl. noch mal den zweiten Server upgraden, das liegt jedoch noch etwas in der Ferne, vor erst eben reiner Web-Server der hauptsächlich SQL & PHP Tasks auszuführen hat. Was ich mich aktuell vom Setup her noch frage - habe meinen Ursprung in der Softwareentwicklung, habe nur ein Grundverständnis von Serveradministration - wie würde das Load Balancing mit unserer Datenbank funktionieren bzw. wie funktioniert das Synchronisieren der Daten? Wenn ich das richtig verstanden habe ist Load Balancing erstmal nichts anderes als den Traffic auf zwei Server/IPs zu verteilen. Wie sähe dann aber die Synchronisation der Daten aus? Ist das umsetzbar? Oder lieber doch einen richtig dicken Server, dafür ohne Load Balancing, und einen kleineren als Backup, auf den wir umswitchen falls der dicke durchbrennt? Wäre top, wenn jemand meine Verwirrung ein wenig lösen könnte :handsdown:

Zu den Servern direkt kann ich nichts sagen, da habe ich auch vermutlich genau so viel Ahnung wie du.

Jedoch zu dem Load Balancing und dem Cluster-Betrieb kann ich dir bisschen was erzählen.

Im Prinzip ist Load-Balancing erst einmal nichts anderes als die Anfrage so aufteilen, dass die Server entsprechend ihrer Leistung ausgelastet sind. Sprich bei zwei gleichstarken Servern wäre die Auslastung im Optimalfall bei beiden 50% bzw. die Aufteilung der Requests bei genau 50%.

Jetzt gibt es mehrere Varianten das umzusetzen:
1. Ihr schnappt euch einen zentralen Datenbank-Server, der ausschließlich für die Datenbank zuständig ist und dementsprechend auch nur optimiert ist auf Throughput (das kann am Anfang auch einer der zwei bestehenden Server sein).
2. Ihr baut einen Mirror-Datenbank-Server auf, der exakt mirrored was der andere Server in der Datenbank macht (was performancetechnisch aber fraglich ist, zumindest sofern ihr nicht Minuten lange Berechnungen habt).
3. Ihr splittet die Datenbank auf die zwei Server auf. So könnte Server A alle Kunden von A-K verwalten und Server B den Rest. Oder Server A hat alle Rechnungen und Server B alle Kundendaten, etc.
4. Noch zig Abwandlungen und verwandte Lösungen...

Die Frage ist jetzt wirklich:
Was ist euer Use-Case? Was wollt ihr mit mehreren Server erreichen? Ausfallsicherheit? Dann reicht die Standardlösung von jedem x beliebigem SQL-Server, der AlwaysOn Failover Cluster ermöglicht.

Wollt ihr besser Skalieren? Dann kommt ihr um eine Custom-Lösung oder um ein paar Lizenzen wohl schwer drum rum.

Was genau ist euer Hauptziel mit den zwei Datenbanken?
Ist es Sicherheit vor Ausfall oder ist es Performance?

Beides gleichzeitig lässt sich mit zwei Servern nur schwer optimieren.

Quote:

Originally Posted by Shadow992 1. Ihr schnappt euch einen zentralen Datenbank-Server, der ausschließlich für die Datenbank zuständig ist und dementsprechend auch nur optimiert ist auf Throughput (das kann am Anfang auch einer der zwei bestehenden Server sein).

Dabei wäre jedoch das Ausfallrisiko genauso hoch wie vorher, nicht? Wäre also nur eine Performance-Lösung.

Quote:

Originally Posted by Shadow992 2. Ihr baut einen Mirror-Datenbank-Server auf, der exakt mirrored was der andere Server in der Datenbank macht (was performancetechnisch aber fraglich ist, zumindest sofern ihr nicht Minuten lange Berechnungen habt).

Exakt, da unsere Datenbank teilweise relativ schnelle Abfragen durchführen muss wäre das synchronisationstechnisch eher suboptimal.

Quote:

Originally Posted by Shadow992 3. Ihr splittet die Datenbank auf die zwei Server auf. So könnte Server A alle Kunden von A-K verwalten und Server B den Rest. Oder Server A hat alle Rechnungen und Server B alle Kundendaten, etc.

Wäre wohl an und für sich eine Lösung, würde jedoch ziemlich gravierende Änderungen an unserer aktuellen Systemarchitektur erfordern + das volle Risiko des Ausfalls wäre nach wie vor da, zumindest 50% der Daten ;)

Quote:

Originally Posted by Shadow992 Die Frage ist jetzt wirklich: Was ist euer Use-Case? Was wollt ihr mit mehreren Server erreichen? Ausfallsicherheit? Dann reicht die Standardlösung von jedem x beliebigem SQL-Server, der AlwaysOn Failover Cluster ermöglicht. Wollt ihr besser Skalieren? Dann kommt ihr um eine Custom-Lösung oder um ein paar Lizenzen wohl schwer drum rum. Was genau ist euer Hauptziel mit den zwei Datenbanken? Ist es Sicherheit vor Ausfall oder ist es Performance? Beides gleichzeitig lässt sich mit zwei Servern nur schwer optimieren.

Unser Hauptziel ist definitiv Ausfallsicherheit, da selbst ein Teilverlust der Daten in unserem Sektor das Todesurteil wäre. Wenn ich mir so noch mal Gedanken darüber mache wäre es vielleicht doch sinnvoller, einen etwas größeren Server zu nehmen und einen zweiten Server nur als Backup wenn der erste durch brennt, als temporäre Lösung bis ein neuer Server vorhanden ist. Die Daten müssten dann eben auf den Backup Server gesynced werden, sodass bestenfalls nur einige Sekunden an Daten fehlen beim Ausfall.

Dachte mir schon dass es eine Lösung die Performance und Ausfallsicherheit mit 2 oder 3 Servern vereint nicht wirklich gibt. Vielleicht fällt jemand anderem ja noch was ein, danke dir :)

Quote:

Originally Posted by i0N Dabei wäre jedoch das Ausfallrisiko genauso hoch wie vorher, nicht? Wäre also nur eine Performance-Lösung. Exakt, da unsere Datenbank teilweise relativ schnelle Abfragen durchführen muss wäre das synchronisationstechnisch eher suboptimal. Wäre wohl an und für sich eine Lösung, würde jedoch ziemlich gravierende Änderungen an unserer aktuellen Systemarchitektur erfordern + das volle Risiko des Ausfalls wäre nach wie vor da, zumindest 50% der Daten ;) Unser Hauptziel ist definitiv Ausfallsicherheit, da selbst ein Teilverlust der Daten in unserem Sektor das Todesurteil wäre. Wenn ich mir so noch mal Gedanken darüber mache wäre es vielleicht doch sinnvoller, einen etwas größeren Server zu nehmen und einen zweiten Server nur als Backup wenn der erste durch brennt, als temporäre Lösung bis ein neuer Server vorhanden ist. Die Daten müssten dann eben auf den Backup Server gesynced werden, sodass bestenfalls nur einige Sekunden an Daten fehlen beim Ausfall. Dachte mir schon dass es eine Lösung die Performance und Ausfallsicherheit mit 2 oder 3 Servern vereint nicht wirklich gibt. Vielleicht fällt jemand anderem ja noch was ein, danke dir :)

Jetzt stellt sich mir aber doch die Frage was genau ihr erreichen wollt. Performance optimieren wäre gut, aber nicht nötig, soweit ist das klar.

Aber Daten-Verlust begegnest du ja nicht primär mit mehreren Servern, sondern mit mehreren Festplatten in einem RAID (welcher sogar minimal Leseoperationen beschleunigt).

Was du maximal an Daten verlierst bei einem Server mit RAID-Festplatten sind die Daten, die genau in dem Moment reinkommen solange wie der Server down ist. Genau hier würde dann ein zweiter gemirroreder Server einsetzen, dann habt ihr zwar effektiv keine Performance-Gewinne, aber ihr könnt diese Down-Zeit praktisch auf 0 drücken und damit weiterhin Daten sammeln/rausgeben.

Ich kenne euren Anwendungszweck immernoch nicht so richtig und durchschaue auch nicht 100% was da das Ergebnis sein soll. Aber im Prinzip sieht mittlerweile folgende Lösung gut aus:

1. Definitiv 2-3 Festplatten im RAID10 Verbund
2. Zwei (einen starken und einen vergleichsweise schwachen) Server, wobei der schwache Server die Hauptdatenbank mirrored. Der Server tut nichts anderes als darauf warten zum Einsatz zu kommen, wenn der Hauptserver down ist.
3. Regelmäßige BackUps (1-12x täglich)
4. Für Performance ohne größere Anpassungen: Einen extra Server holen für die Datenbank, der auf Throuput optimiert ist. Ansonsten lässt sich performancemäßig auch noch über Lizenzen bzw. custom Lösungen was machen (Microsoft SQL bietet zum Beispiel von Haus aus an zwei Datenbanken im Cluster zu betreiben, soweit ich weiß aber nur als AlwaysOn Failover Cluster).

1. und 3. scheint für euch zwingend erforderlich. 2. und 4. müsst ihr selbst wissen, ob sich Nutzen/Aufwand lohnt.

Im besten Falle stellt ihr die Server noch in zwei verschiedene Rechenzentren, denn es kann auch schonmal passieren, dass ein Rechenzentrum einfach Probleme mit Hardware o.ä. hat und wenn die zwei Server ausgerechnet am selben Switch hängen, bleibts dunkel trotz Redundanz.

@[Only registered and activated users can see links. Click Here To Register...] Klar, ein RAID-Setup wird sowieso verbaut, zwei Server im Zusammenhang mit Ausfallrisiko meinte ich auch eher bzgl. der Downtime. Hatte mich da etwas unklar ausgedrückt.
Alles klar, dann werden wir wohl anfangs tatsächlich nur mit einem Hauptserver und einem Backup für Downtime-Zwecke arbeiten, auf Dauer wird sich sowieso jemand drum kümmern, der von Serveradministration mehr Ahnung hat als ich :rolleyes:

Danke dir!