Erfahrung mit SLES oder RHEL bezüglich Skalierbarkeit (ab 8 Kerne)

[ThorstenHirsch]

Servus!

Wollte mal in die Runde fragen, ob jemand Erfahrung mit mittelgroßen Servern hat, was die Skalierbarkeit von Linux angeht. Wir setzen momentan noch Solaris 10/UltraSPARC IV ein und sind eigentlich auch super zufrieden mit der Leistung. Wenn's nur danach geht, würde als nächstes ein SPARC64 VI/VII kommen ...aber man muss ja auch die Kosten betrachten.

Vertikal sehe ich kein Problem darin, dass Linux/x86 mithalten kann. Aber wie sieht das aus, wenn 8, 12 oder 16 Kerne voll ausgelastet sind und richtig viel I/O geschaufelt werden muss (MQ, Oracle, ...) und das ganze noch in einem HA-Cluster. Klar, ich erwarte da keine Wunder, im Extremfall geht auch Solaris in die Knie. Ach ja, weil ich's noch gar nicht erwähnt hatte - Solaris/x86 kommt auch nicht in Frage.

Theoretisch kommt nur SLES 9 oder RHEL 4 in Frage, aber ich vermute, dass SLES 10 und RHEL 5 gerade bei der Skalierbarkeit wieder deutlich zugelegt haben.

[marce]

vor ein 2/3 Jahren gab's mal einen entsprechenden Test AFAIK in der iX - wie aktuell die Ergebnisse noch sind kann ich aber nicht sagen.

Quintessenz war damals, daß ab 8 Kernen aufwärts bei Linux mit annähernd linearer Skalierung def. Schluss ist und dort "ernsthafte" OS auf ernsthafter Hardware im Vorteil sind.

[Roger Wilco]

Solaris/x86 kommt auch nicht in Frage.
Wieso eigentlich nicht, wenn ich mal zwischenfragen darf?

[bla!zilla]

Ich glaube da hat sich bis heute nix getan. Gerade bei hoher Last und vielen Kernen ziehen die "traditionellen" Unicse noch immer weg. Die Ergebnisse sind zwar deutlich besser als vor ein paar Jahren, aber so der letzte Kick fehlt noch.

Frage: Was spricht gegen scale-out? Also lieber viele kleine Linux-Kisten statt weniger großer? Auf was für eine Hardwarebasis soll gegangen werden? XEON oder Opteron?

[ThorstenHirsch]

@marce: Hmm... ja, vor 2/3 Jahren hätte ich gar nicht erst gefragt. :) Ich vermute SLES 11 mit Kernel 2.6.27 könnte interessant sein, wird aber noch nicht von unserer proprietären Software unterstützt.

@Roger: Gegen Solaris/x86 spricht ebenfalls, dass es nicht von der proprietären Software unterstützt wird.

@bla!zilla: Ja, hatte ich auch schon drüber nachgedacht ...wir hätten da sogar eine ziemlich elegante Abstraktionsebene, auf der wir das gut durchführen könnten. Aber damit würde zu unserem Wechsel des Sourcing-Partners und dem Wechsel der Architektur auch noch eine komplette Überarbeitung der Architektur kommen. Naja, wir müssen da auch abwägen, wieviel wir auf einmal stämmen können.
Xeon oder Opteron? Ist mir bislang Wayne gewesen - muss ich darauf besonders achten?

[bla!zilla]

@bla!zilla: Ja, hatte ich auch schon drüber nachgedacht ...wir hätten da sogar eine ziemlich elegante Abstraktionsebene, auf der wir das gut durchführen könnten. Aber damit würde zu unserem Wechsel des Sourcing-Partners und dem Wechsel der Architektur auch noch eine komplette Überarbeitung der Architektur kommen. Naja, wir müssen da auch abwägen, wieviel wir auf einmal stämmen können.
Xeon oder Opteron? Ist mir bislang Wayne gewesen - muss ich darauf besonders achten?

Oh nee, dann ist das keine gute Idee. Man sollte nie mehr als eine Baustelle aufmachen. :D

Also bei Xeon oder Opteron gibt es schon Unterschiede, je nach Applikation skalieren die besser oder schlechter.

[ThorstenHirsch]

Aber je mehr ich drüber nachdenke, desto sexier finde ich das. Könnte man ja in einem zweiten Schritt machen. Doch, das ist sogar ne super Idee. Da machen wir aus 1 Kiste im ersten Schritt so 4 bis 8 Stück und wenn das so funktioniert, wie ich mir das vorstelle, kann man theoretisch beliebig viele dazupacken ...naja, man will ja auch den Überblick behalten, also lieber nicht übertreiben. Aber vielleicht bekommen wir auch nen hot-swap hin. Das wäre ja genial.

[bla!zilla]

Der Vorteil liegt natürlich auch bei der Verfügbarkeit. Wenn eine Kiste ausfällt, brauchst du sie im Load-Balancer nur rauszunehmen. Je nach Kostensituation kann eine Lösung, die auf scale-out basiert, deutlich günstiger werden beim Betrieb. Und wenn eure Applikationsinfrastruktur damit umgehen kann, why not. Oracle ist da auch nicht so das Problem, mit einem RAC sollte das kein Thema sein.

[marce]

#9 als Spam gemeldet.