Re: LAMP: ansatz korrekt?

[Marc Haber <mh+uugrn@xxxxxxxxxxxx>]

Hallo Markus,

On Tue, Nov 18, 2008 at 01:21:55AM +0100, Markus Bucher wrote:
> >Hat die Installation so viel zu tun dass die Trennung von Apache und
> >MySQL not tut?
> >  
> Ja, wir rechnen mit > 4M PI/Monat
> >Ist es im Stoerungsfall wichtig, dass man wirklich auf aktuellem
> >Datenbankstand weiterfaehrt, oder ist akzeptabel, dass man (z.B.
> >viermal am Tag) Schnappschuesse der Datenbank macht und die dann
> >ruebersynced?
> >
> >Wenn der Rueckfall auf den letzten Schnappschuss akzeptabel ist, wuerde
> >ich auf die Replikation verzichten (das war mir immer schon
> >unsympathisch) und besser mit mylvmbackup arbeiten.
> >  
> Bislang laeuft die Replikation reibungslos. Da dahinter unter anderem ein 
> Shop steht kommen wir mit 4 Snapshots eher nicht aus.

Ok, dann braucht's den groesseren Aufwand.

> >>Mein zweiter Teil betrifft den Nameserver. Ich dachte mir, Server 1 als 
> >>primary und Server 2 als secondary nameserver laufen zu lassen.
> >>    
> >
> >Sind die beiden Server in unterschiedlichen Netzen?
> >  
> Ja. ein 85er und ein 214er oder so.

Das ist fuer die Redundanz vorteilhaft, fuer das Zusammenspiel zwischen
Applikation und Datenbank eher nicht.

Wenn der Redundanzgedanke auch den Wunsch nach Katastrophenfestheit
beinhaltet, muss man sich auch Gedanken ueber die Raeumliche Trennung
der beiden Systeme machen. Das wiederum erzeugt Latenzen zwischen den
Systemen, was gegen die Verwendung von System B als Datenbank fuer
System A spricht.

> >Das ist nicht so einfach, weil Du in aller Regel keinen Einfluss
> >darauf hast, welcher Server zuerst gefragt wird. Der DNS selbst - im
> >Gegensatz zum Fall SMTP - kennt das Konzept von primary und secondary
> >nicht.
>
> Schade eigentlich.

Ein Fallback-Mechanismus waere auf den ersten Blick sexy, aufgrund von
raeumlich begrenzten Stoerungen koennte man aber auf diese Weise auch
leicht Situationen erzeugen, bei denen die eine Haelfte der Welt auf
dem Fallbacksystem arbeitet, obwohl das primaere System von der anderen
Haelfte der Welt erreichbar ist.

> >Ich wuerde beide Server als Master laufen lassen und die Datenbestaende
> >mit rsyncen, weil Du ja eh ein rsync am Hals hast.
> >
> >Steht im Pflichtenheft, dass das Failover transparent und ohne
> >menschlichen Eingriff zu erfolgen hat?
> >  
> Hatte ich mal so geplant. Du meinst, das kann ich so vergessen? Waere es 
> schlauer, die NS-Eintraege von einem dritten Rechner verwalten zu lassen, 
> der dann wenn noetig die Daten aendert?

Das ist alles eine Frage des Geldes und der Ansprueche die man hat.
Wenn man mal hohe Ansprueche voraussetzt und die finanzielle Seite
ausser Acht laesst, koennte ich mir das folgende Setup vorstellen:

  * Datenbank und Applikationsserver sind gedoppelt, beide Instanzen
    (also vier Systeme) stehen in unterschiedlichen Rechenzentren
    (Produktiv P und Backup B) in unterschiedlichen Autonomen Systemen.
  * Der Applikationsserver B dreht im Normalbetrieb Daeumchen; der
    Datenbankserver B laeuft als Slave des Datenbankservers P mit.
  * Die Domains sind zu einem Anbieter mit hochverfuegbarem DNS delegiert

Die wirkliche Herausforderung entsteht, wenn im Katastrophenfall (RZ P
brennt ab, Hardware P stirbt) die Umschaltung notwendig ist. Wenn man
das mit DNS-Aenderungen erschlagen will, hat man eine Ausfallzeit von
maximal der TTL des DNS-Eintrags, die man nicht zu niedrig ansetzen
moechte wenn man will dass die grossen ISPs sie noch beachten. Ob man
die Aenderung des DNS-Eintrags dann haendisch oder automatisch macht,
ist Geschmackssache; ein Projekt dieser Groessenordnung wird ja eh eine
organisierte Bereitschaft haben.

Wenn diese Ausfallzeit (Groessenordnung ein paar Stunden) nicht
hinnehmbar ist, muss man ein Szenario bauen, das den Uebergang der
IP-Adressen im Stoerungsfall auf ein anderes RZ ermoeglicht, dazu
braucht's ein eigenes Autonomes System und ein eher fuenfstelliges
Budget. Darueber lass ich mich dann aus, wenn es gewuenscht wird.

Gruesse
Marc
 

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190
--
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/