Re: 2 Webservers - LB loesung

From: Peter Ross <Peter.Ross(at)alumni.tu-berlin.de>
Date: Sat, 22 Mar 2008 19:32:50 +1100 (EST)

Hi Hannes,

ich schicke die Antwort mal an die Liste, ich denke, das war nicht nur
an mich privat gedacht (entschuldige bitte, wenn ich mich da irre).

On Sat, 22 Mar 2008, Hannes Widmer wrote:

> > > Ich habe einen Kunden, welcher bei uns eine Typo3 Lösung hostet. Was an
> > > Hardware so möglich ist, haben wir ihm bereitgestellt.
>
> Nun, ich fange mal unten an. Dass wird die DB und den Webserver trennen
> werden, ist wie gesagt wohl Nr1 der Aktion. Dies habe ich bei einem
> anderen Kunden bereits getan, was die Problematik vorerst gelöst hatte.

Okay.
 
> Aber auch dort, rein vom zuwachs dieser Seite (auch ein CMS aber von ner
> deutschen Firma) kommen immer mehr die Aussagen des Kunden, dass es
> längere Wartezeiten gibt bis der content geladen wird. Wenn ich dir
> richtig verstehe, würdest du als mit Hardware die Probleme erschlagen,
> korrekt ?

Erst einmal herausfinden, wo der Bottleneck ist. Könnte z.B. auch die
Internetverbindung sein (bei uns aufgetreten, als beim ISP ein Techniker
ausversehen die Leitung gedrosselt hat:-(

Man muß einen Webserver auch nicht damit belasten, statischen Inhalt immer
wieder auszuliefern. Squid als Cache davor kann hilfreich sein.

Wenn es die DB ist, diese beobachten und aufbohren. Optimieren, Indexes.
Den Code angucken.. ich habe mich vor kurzem durch SQL-Logs eines CMS
durchgewühlt, da waren haaresträubende Statements dabei.

Wenn dann das Ende der Fahnenstange erreicht ist, kann eine bessere DB
helfen. Auch eine, die echtes Clustering unterstützt (Oracle, MS-SQL..)

> An pound habe ich dabei auch schon gedacht, wüsste nun aber die Antwort
> auch nicht, ob der Sessionhandling supportet.

Hiernach kann es SessionIDs mit Hilfe von Cookies:

http://www.apsis.ch/pound/

> Bezüglich den Datenbanken, hätte ich mit einer Repplikation gearbeitet
> die ich bereits jetzt an mehreren Orten einsetze und damit eigentlich
> selten bis gar nie Probleme hab.

So lange Deine Session nur lesen, kannst Du die Anfragen auch auf Replikas
verteilen.

Wenn geschrieben wird, geht es nicht, das muß an die Meister-DB.

> Files hätte ich mit gmirror untereinander abgeglichen, war mal so die
> Idee.

Sinngemäß das Gleiche fürs Filesystem.

Wie auch immer, Spiegeln von DB und Files erhöht natürlich die
Datensicherheit.

> Der Juniperansatz tönt sehr intressant nur weiss ich ned was die Dinger
> kosten und das dem Kunden zu verkaufen ist nochmals ein anderes Thema.
> So eine Lösung aber nachzubauen währe intressant.

Mit squid, pound, CARP oder VRRP (Failover auf IP-Ebene) und pf inklusive
pfsync (für Redirects auf Paketebene) wären die Bedürfnisse unserer
Anwendungen wahrscheinlich abgedeckt, aber es mag mehr Feature bei den
Juniper DXen geben, die wir nicht benutzen und die nicht durch Open Source
abgedeckt werden.

Ich benutze nur so viele Feature, wie ich wirklich brauche.

Unsere Webseite z.B. ist über eine halbe Stunde Downtime nicht gerade
glücklich, wir überleben es aber.

Wenn ich automatisches Failover einbaue, muß ich darauf auch vertrauen
können. Leider halten einige Lösungen nicht das, was sie versprechen. Das
ist dann eher schlimmer, weil es Sicherheit vorgaukelt, die im Falle des
Falles nicht da ist:-(

MySQL-Clustering ist so ein Beispiel. Es arbeitet nur mit einer Memory-DB
als Backend, das ist für 99% der Fälle absurd.

Es grüßt
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 22 Mar 2008 - 09:31:07 CET

search this site