Root server Frage

[brother]

Hey ich hoffe es kann mir jemmand hier Helfen

Wir wollen dort so was drauf machen
socialengine.net

So wir wollten uns diesen server als Webserver mieten

http://www.ovh.de/produkte/hg_2010_extralarge.xml
und wie sieht es aus wenn wir dort den Ram auf 48gb erweitern
Für msql

http://www.ovh.de/produkte/eg_max.xml


Nun haben wir dort mal ne Frage


Wieviel user können bei dieser Harware gleichzeitig online sein ohne das wir Probleme bekommen.

 

[matzewe01]

Wieviel user können bei dieser Harware gleichzeitig online sein ohne das wir Probleme bekommen.

Das kann man so nicht beantworten.
Woher auch? Kennen wir euer Script? Wissen wir was das Script für Last erzeugt? Wiesen wir wieviele Daten entstehen werden.

Deine Frage kommt wohl folgender sehr Nahe:

Wieviel Getränkeflaschen kann ich auf einen "spezifizierten" LKW und unter berücksichtigung gesetzlicher Bedingunen, laden?

Pauschale und formal richtige Antwort:

Wenn es Kunstoffflaschen sind, mehr als bei Glasflaschen.
Hingegen mehr leere Glasflaschen als volle Kunstofflaschen.
Generell gilt jedoch, dass mehr leere Flaschen einer Sorte auf dem LKW geladen werden können, als volle.
Das max. Zuladungsgewicht kann mit vollen Flaschen besser ausgenutzt werden.


-> Eine "solche formulierung" wäre nun für Deine Frage notwendig.
Mit ausprobieren eines lokalen hosts mit identischer Hardware führt dich schneller ans Ziel.
Stichwort heisst Lasttest.
Man beachte, dass die Datenmenge und die SQL Scripte erheblich die Performance und den Optimierungsaufwand beeinflussen.

Und im Gegensatz zu Deiner Frage, wäre man wenigstens annährend in der Lage das Gewicht der Flaschen zu ermitteln und daraus eine relativ genau Berechnung durchzuführen.

 

[IP-Projects.de]

Wenn Sie wirklich vor haben so ein System zu mieten, würde Ich einmal über eine Loadbalanced Clusterlösung nachdenken. Für den Preis würde man z.B. rund 6 normale Server erhalten und hätte die notwendige Flexibilität um das Cluster ohne Probleme um weitere Nodes zu erweitern.

https://www.ip-projects.de/cluster-failovered-kombiniert-mit-loadbalanced.html

So etwas wäre hier wohl am zweckmäßigsten inklusive einer sehr hohen Ausfallsicherheit.

 

[matzewe01]

Das wäre eine flexible Lösung um eine wachsende Community physisch zu skalieren.

Allerdings muss dann die Anwendung auch entsprechend Clusterfähig sein.
Sollte man zumindest berücksichtigen.

 

[d4f]

Webseiten sind in der Regel relativ clusterfreundlich, da bsp. jeder Aufruf eines PHP-Skriptes einen eigenen (recyclierten) Prozess erhaelt.
Allerdings muesste ein ClusterFS als Dateisystem her, MySQL mittels Replikatoren auf mehrere Server aufgeteilt werden und weitere Systeme wie Memcached und haProxy zum Zuge kommen.

Uebrigens bietet OVH selbst schon Cluster-IP's an (maximal 8 Server je Cluster)

Zumindest vom wirtschaftlichen Standpunkt her waere ein CLuster bedeutend vertretbarer da ich bezweifele dass der Boom auf eure Seite, sofern er ueberhaupt kommt, nur langsam anfaengt und somit der doch relativ happige Server in den ersten Monaten nur gelangweilt Daeumchen dreht.

 

[matzewe01]

Naja, also einen Mysql Proxy und master master Replikation lässt sich relativ einfach einrichten.

Allerdings ist das Sessionhandling durchaus ein nicht so Clusterfreundliches Thema. Ob man das wirklich über ein clusterfs syncen will?
Der Performance wegen auf keinen Fall.
Wenn, dann muss hier eine gewisse stikiness des Loadbalancers berücksichtigt werden.
Aber wie schon gesagt, ein Clusterfs, wird einem hier keine Freude bereiten.

 

[d4f]

Sessions sollten nach der Initialisierung stets auf den gleichen Server geleitet werden(ausser bei Ueberlastung oder Ausfall). Um jedoch gegen Ausfaelle zu sichern sollten, zumindest asynchron, die serialisierten Daten ueber eine Cluster-Datenbank (HBase oder bsp eine eigene RAM-basierende Loesung) global zur Verfuegung gestellt werden.

Das ClusterFS dient als praktischen Unterbau um allen Servern die gleiche Festplattenstruktur zu garantieren. Wenn man jedoch im Vorheraus den Code kennt kann man darauf verzichten indem man von jedglicher Speicherung direkt im Dateisystem absieht. Verschiedene Cluster-Datenbanken wie HBase (Non-SQL) setzen jedoch im Unterbau auf ein ClusterFS (HDFS).
Alle Faelle wo der Code variieren kann sind mit DRBD besser aufgehoben da alle Server die Daten lokal vorhalten und nur Aenderungen uebermittelt werden muessen. Bei vielen kleinen Aenderungen oder beim Zugriff auf ein gigantisches pseudo-SAN (a la google) ist natuerlich ein Clustersystem wie HBase, BigTable oder ein ClusterFS erste (und einzige ) Wahl

MySQL Replikation ist uebrigens in solchen Groessenordnungen eher von Nach- denn von Vorteil. Die Zeit, Bandbreite und Last die ausschliesslich in die Replikation einfliesst koennte in einem anderen System den Benutzern zur Verfuegung stehen. Entweder man muss strikt zwischen Read- und Write-Server unterscheiden oder man erstellt komplexe Master-Master Replikationsvorgaenge...
(Oder man wechselt das Datenbanksystem)

 

[matzewe01]

Sessions sollten nach der Initialisierung stets auf den gleichen Server geleitet werden(ausser bei Ueberlastung oder Ausfall). Um jedoch gegen Ausfaelle zu sichern sollten, zumindest asynchron, die serialisierten Daten ueber eine Cluster-Datenbank (HBase oder bsp eine eigene RAM-basierende Loesung) global zur Verfuegung gestellt werden.

Wobei jedoch Session Daten bei PHP verteilt auf mehrere Rechner, nicht eindeutig sind. Auch hier muss man sich dann noch etwas einfallen lassen.
Man läuft also gefahr, dass Sessions unbeabsichtigt gehijackt werden.


Bezüglich "Clusterdatenbanken". Das ganze macht nur bei einem zentralen oder sehr schnellen Storage Sinn. Das ist die Grundvorraussetzung. Die typischen Rootserver, allerdings, eigenen sich für eine geclusterte Datenbanke eher nicht. Dafür ist der Storage zu langsam und die Anbindung zwischen den Systemen, ebenfalls zu langsam. Das Signalhandling zwischen beiden Nodes bremst hier ungemein. Allgemein gilt ohnehin, wer auf eine geclusterte Datenbankanwendung setzt, setzt in erster Linie of hohe Verfügbarkeit und Redundanz statt Performance.

Auf jeden Fall, gibt es doch einige Dinge zu beachten, als dass man "Webanwendungen" grundsätzlich als leicht clusterfähig ansieht.

Welche DB dann dahinter läuft, ist dann auch nicht mehr so wichtig.

 

[d4f]

Wobei jedoch Session Daten bei PHP verteilt auf mehrere Rechner, nicht eindeutig sind. Auch hier muss man sich dann noch etwas einfallen lassen.

Man muss nicht PHP's eigene Session-Funktion benutzen sondern kann diese durch eine eigene ersetzen: http://php.net/manual/en/function.session-set-save-handler.php
Zu Redundanzzwecken mit hoher Leistung liesse sich MemcacheDB im Hintergrund einsetzen wo die Session vom jeweiligen Server mit einem Prefix versehen wird.
Im Fall eines Takeover durch einen anderen Server muss dieser die Session im MemcacheDB auf sich selbst ueberschreiben was somit ein Split-Brain Problem vermeiden sollte.

Bezüglich "Clusterdatenbanken". Das ganze macht nur bei einem zentralen oder sehr schnellen Storage Sinn.

3 DB-Server mit je 2 Festplatten (oder SSD's) im RAID-0 sollten schneller sein als 1 zentraler Datenbankserver mit 6 Festplatten im RAID-5 (und gleichzeitig ausfallsicherer). Allerdings habe ich mein Testcluster desbezueglich erst fuer diesen Sommer geplant, kann es also noch nicht belegen Nur der Overhead zu den Master-Servern und der anschliessende Lookup auf den Storage-Servern duerfte die gesamte Abfrage-Prozedur (und Bandbreite) erhoehen, jedoch nicht so weit als dass es ein Killerkriterium waere.
Ein solcher Server (wenn wir schon bei OVH sind) sollte genug Leistung bieten um einen mixed-Cluster aufzubauen: http://www.ovh.de/produkte/eg_hybrid.xml

Interessant ist dass auch Google auf diese Technik fuer ihre propreitaere BigTable setzen - ein Unternehmen dieser Groesse (laut eigenen Aussagen 100 Petabyte Festplattenbelegung ausschliesslich fuer den Suchindex) sollte die Vor- und Nachteile aller Techniken durchgespielt haben.
Die eingesetzten Server sehen uebrigens so aus: http://www.romantika.name/v2/wp-content/uploads/2009/04/googleservermedium.jpg
(Rechts fehlt der GelAkku-Pack der servereigenen Notstrom-Versorgung)

Auf jeden Fall, gibt es doch einige Dinge zu beachten, als dass man "Webanwendungen" grundsätzlich als leicht clusterfähig ansieht.

Verglichen mit herkoemmlichen Desktop- und Serveranwendungen sind Webseiten relativ einfach clusterfaehig - zumindest bis zu einem gewissen Punkt.

 

[matzewe01]

3 DB-Server mit je 2 Festplatten (oder SSD's) im RAID-0 sollten schneller sein als 1 zentraler Datenbankserver mit 6 Festplatten im RAID-5 (und gleichzeitig ausfallsicherer). Allerdings habe ich mein Testcluster desbezueglich erst fuer diesen Sommer geplant, kann es also noch nicht belegen

Über DRBD gesynct? Da ist der bottleneck mehr oder minder immer noch der Sync der Daten insbesondere wenn man auf protocol C fährt, was ich an der Stelle auch ausschliesslich tun würde.
(Da ist das lokale Schreiben auf Platte nicht auschlaggebend sondern wie schnell die anderen zurück melden, dass auch dort die Transaktion durch ist.)
Mit einem geeigneten Storage über SAN oder Fibrechannel angebunden, übergeht man das Problem relativ elegant.

Raid-5 ist für eine Datenbank garantiert das fälscheste was man nehmen kann.

Ich weiss, angebliche Profis und so mancher Hersteller wirbt damit dass Raid 5 genau so schnell ist und überhaupt.
Die Realität zeigt jedoch, ein gutes Raid 10 (gut bezieht sich insbesondere auf den Controller) ist in einem solchen Fall kaum zu toppen und min. genau so stabil betreibbar.

So zumindest meine Erfahrung, besonders nach prod. Ausfällen wo so mancher Raid5 als SAME empfohlen und auch umgesetzt hat.

 

[d4f]

Über DRBD gesynct?

Nein ueber eine non-SQL Cluster-Datenbank wie HBase - welches uebrigens interessanterweise keinen eigenen SPOF aufweist und sich somit fuer hoch-kritische Anwendungen nahezu aufdraengt. (Basiert uebirgens auf dem Google BIgtable Whitepaper)
Vorteil:
- hohe Read-Performance
- Stabil und weltweit im Einsatz befindlich
- ausgelegt fuer moeglicherweise unstabile Uplinks und hohe Latenzzeiten
- Der Ausfall eines Nodes wird nicht als Ausnahme sondern als Regel betrachtet (entsprechend abgesichert)
- SEHR weit skalierbar

NachteilL
- nicht ganz so hohe Write-Performance
- Write's sind nicht garantiert erfolgreich (Status muss ueberprueft werden)

--
[EDIT]
RAID10 sind schneller, da stimm ich zu (kann aber auch an den doch relativ guenstigen Controller gelegen haben ). Aber man verliert gleichzeitig wieder Festplattenkapazitaet was bei grossen Datenbanken ein nicht negligierbarer Kostenaufwand ist.

 

[matzewe01]

NachteilL
- nicht ganz so hohe Write-Performance
- Write's sind nicht garantiert erfolgreich (Status muss ueberprueft werden)

--
[EDIT]
RAID10 sind schneller, da stimm ich zu (kann aber auch an den doch relativ guenstigen Controller gelegen haben ). Aber man verliert gleichzeitig wieder Festplattenkapazitaet was bei grossen Datenbanken ein nicht negligierbarer Kostenaufwand ist.

Genau das meine Ich.
"Write's sind nicht garantiert erfolgreich."

Darauf will man sich aber eigentlich verlassen. Und writes sind wichtig, will man ja keine Daten verlieren.
Für flüchtige Informationen wie Sessions mag das ja i.O. sein. allerdings spricht die schlechtere Schreibperfoemance auch nicht für ein Session Handlung.

-> Ich kenne ad hoc keine Gesellschaft, die Sessionreplizierung ernsthaft einsetzt. Vor allem, weil der damit verbundene technische Aufwand den Nutzen nicht gerecht wird.

Zu den Platten.
Also gerade Storage ist inzwischen so billig geworden, dass hier der höhere Preis seltener eine Rolle spielt.


Da das aber schon sehr Oftopic ist, stelle ich mir gerade die Frage, ob der Threadersteller wirklich seine Anwendung nochmals umschreiben will oder ein Kompromiss besser für Ihn geeignet ist.

Ich betreue zwar keine google Grössenordnung, aber 250 000 Transaktionen / Sekunde (nicht Hits) bei einer Nettodatenmenge von knapp 80 TB hat man hier mit relativ wenig Blech einer guten Architektur und Setup gut in den Griff bekommen.

 

[adalbert-walter]

Bei so großen Projekten würde ich das Angebot von ip-projects bevorzugen.
Habe schon selber einige Cluster eingerichtet. Die Webseite auch wenn php-sessions genutzt werden, werden 100%ig laufen.

Zum MySQL:
Einen MySQL-Cluster zu erstellen ist relativ simpel aber auch sehr unproduktiv langsam.Ich würde wie bereits erwähnt die etwas komplexere Master-Master-Replika nehmen, wobei es dort nur ein paar Kleinigkeiten zu beachten gibt damit die REplika sauber und stabil läuft.

Würd ma bei ip-projects.de anfragen, evtl. ist nen clusterbetrieb wirklich besser für dich.