Zopebuch: Inhaltsverzeichnis 

Skalierbarkeit und ZEO

Bekommt eine Website mehr Anfragen als sie abarbeiten kann, wird sie langsam und gibt die Seiten nur zögernd heraus. Eine grosse Menge von Anfragen kann einen Server sogar dermassen überlasten, das Anfragen nicht mehr beantwortet werden können und der Server unter Umständen sogar unkontrolliert abstürzt. Dies ist nun nicht ein Problem was nur Zope betrifft, auch andere Serverdienste sind empfindlich gegen Überlast. Oft wird dieses Problem durch den Einsatz mehrerer Rechner mit identischen Serverkonfigurationen gelöst. Fällt nun einer der identischen Rechner aus, können auf eine einfache Art und Weise die noch zur Verfügung stehenden Rechner die Aufgabe der ausgefallenden Recheneinheit übernehmen.

Die Dienste auf mehrere Rechner zu verteilen hat seine Vor- und Nachteile. Wenn man beispielsweise fünf Rechner mit identischen Zope Installationen in Betrieb nehmen möchte, muss auch sichergestellt sein, dass auf allen Zope Instanzen die gleichen Informationen vorliegen. Dies ist nicht besonders schwer zu bewerkstelligen, wenn man als einziger User eine handvoll statischer Objekte anlegt und diese auf jeder Zope Instanz auf gleiche Art und Weise installiert. Auf einem Zope-Server in einer grossen Organisation mit mehreren Tausenden sich schnell änderen Objekten würde die manuelle Abgleichung der fünf verschiedenen Zope-Instanzen zu einer nicht mehr zu bewältigenden Aufgabe.

Um dieses Problem zu lösen hat die Zope Corporation die sogenannten "Zope Enterprise Objects" geschaffen - abgekürzt "ZEO" genannt. Dieses Kapitel gibt euch einen nur einen kurzen Einblick wie ZEO installiert wird. Viele andere tolle Sachen, die Ihr mit ZEO noch machen könnt, werden hier nicht abgehandelt. Um mehr über ZEO zu erfahren, lest euch die die mitgelieferte Dokumentation durch. Das ZEO Forum ist ebenfalls eine gute Informationsquelle ("Anmerkung des Übersetzers: Aber wo bloss ???").

Was ist ZEO?

ZEO ist ein System, was es uns ermöglicht, eine Website auf mehreren Rechnern zu betreiben. Eine derartige Anordnung von Rechnern wird auch "Cluster" genannt. Mit einer solchen Anordnung und einer Lastverteilungskomponente kann eine Lastverteilung erzielt werden (englisch: "load balancing"). Weil Zope auf mehreren Rechnern zur Verfügung steht, können durch eine geeignete Lastverteilungskomponente die Anfragen auf mehrere Rechner verteilt werden, falls die Anfragelast das erforderlich macht. Ausserdem können im Falle eines Serverausfalles, die noch intakten Rechner die Anfragen bedienen. Mit einem derartigem Serveraufbau kann man also ganz in Ruhe den defekten Rechner austauschen oder reparieren, ohne das von aussen ein Serverausfall spürbar wird.

Mit ZEO kann Zope auf mehreren Rechnern betrieben werden. ZEO garantiert, dass alle beteiligten Zope Installationen jederzeit auf genau die selbe Datenbank zugreifen. ZEO benutzt dazu eine Client/Server- Architektur. Alle Clients verbinden sich mit einer zentralen Instanz, dem ZEO Speicher Server, so wie auch in Bild 11-1 zu sehen ist.

Die Begrifflichkeit kann verwirrend wirken, weil man normalerweise gewohnt ist, von Zope als einen Server zu sprechen. Wenn ZEO allerdings im Spiel ist, dann übernimmt Zope zugleich Serverfunktionaliät (für die Beantwortung von Webanfragen) sowie Klientfunktionalität (um Daten vom ZEO-Server zu erhalten.)

ZEO Clients und Server kommunizieren mit einem standardisierten Internetprotokoll. Auf diese Art und Weise ist es möglich, beide im selben Raum oder aber auch in einem anderem Land zu betreiben.

Wann empfiehlt es sich ZEO einzusetzen

ZEO kann viele Anfragen in einer ausfallsicheren Art und Weise beantworten. Wenn eure Website nicht Millionen von Anfragen bekommt, dann braucht Ihr ZEO vielleicht nicht. Es gibt keine feststehenden Regeln wann man ZEO einsetzen sollte und wann nicht, aber folgende Argumente würden für den Einsatz von ZEO sprechen:

• Eure Webseite bekommt deutlich mehr Anfragen als der Rechner zügig ausliefern kann. Zope ist ein hochgerüstetes System, und Zope kann Millionen von Anfragen beantworten (natürlich abhängig von der eingesetzten Hardware). Wenn diese Leistung nicht mehr ausreicht um eure Anforderungen zu erfüllen, dann sollte ZEO zum Einsatz kommen.
• Eure Website ist sehr wichtig und erfordert konstante 24/7 Verfügbarkeit. In diesem Falle erlaubt ZEO den Einsatz mehrerer sofortige einsatzfähiger Ersatzserver.
• Ihr wollt Eure Website global über mehrere Mirror-Sites anbieten und an jedem Standort dieselben Daten per ZEO-Client zugreifen und schreiben können.
• Ihr wollt einen ZEO Client nach Fehlern untersuchen (debuggen), während die anderen Zeo-Clients noch weiterhin Webseiten ausliefern.

All diese Punkte sind bereits ziemlich vorgeschrittene Themen. Einrichtung, Konfiguration und Betrieb eines derartigen Systems erfordert schon vorgeschrittene Administrationskenntnisse und Betriebsmittel. Die meisten Zope User werden sich mit ZEO nicht auseinandersetzen zu brauchen oder haben nicht die erforderlichen Kenntnisse, ein verteiltes System wie ZEO einzusetzen. ZEO macht zwar Spass, aber ist auch aufwändiger als ein ganz normaler einzelner Zope - Server.

Installation und Inbetriebnahme des ZEO Systems

Am häufigsten wird ZEO mit einem ZEO Server und mehreren ZEO Clients betrieben. Bevor Ihr beginnt eurer eigenes ZEO-System zu installieren und zu konfigurieren, beachtet folgende Punkte:

• Alle ZEO Client- und Serversysteme müssen die selbe Zope-Version in Betrieb nehmen. Es sollten nur die neusten ZEO und Zope-Version verwendet werden. Dies ist erforderlich, um einen einwandfreien Betrieb des Gesamtsystemes zu ermöglichen.
• Alle ZEO Client Systeme sollten die selben Produkte von Drittherstellern installiert haben, und die Versionen der Produkte sollten identisch sein.
• Falls Dein Zope System auf externe Betriebsmittel wie E-Mailserver oder Relationale Datenbanken zugreifen muss, muss allen ZEO-Clients der Zugriff auf diese Betriebsmittel ermöglicht werden.
• Langsame oder zeitweise gestörte Netzwerkverbindungen zwischen dem Serversystem und dem Clientsystem können die Leistung der ZEO-Clientsysteme beeinträchtigen. Die ZEO Clientsysteme sollten eine gute Verbindung zu dem Serversystem haben.

ZEO wird nicht mit Zope mitgeliefert, Ihr müsst es euch von der Produktseite bei Zope.org runterladen.

Die Installation von ZEO erfordert ein wenig Handarbeit. Um ZEO zu installieren, lade zunächst das gepackte Archiv ZEO-1.0.tgz von der Zope.org Website herunter und speichere diese Datei in das ZopeInstallationsverzeichnis. Nun entpacke das Archiv. Auf einem UNIX System kann das mit folgendem Befehl bewirkt werden:

 tar -zxf ZEO-1.0.tgz

Auf einem Windows System kannst Du das Archiv mit Winzip entpacken. Bevor Ihr nun ZEO installiert, empfehlen wir noch dringend eine Sicherung des Zope System vorzunehmen.

Nun solltet Ihr ein ZEO-1.0 Verzeichnis haben. Als nächstes müsst Ihr noch ein paar Dateien vom Zope Stammverzeichnis in das Zope top level lib/python Verzeichnis kopieren. Unter Unix funktioniert dieses so:

 cp -R ZEO-1.0/ZEO lib/python

Falls Du unter Windows arbeitest, kannst Du folgende DOS Befehle absetzen um eure ZEO-Files zu kopieren:

C:\...Zope\>xcopy ZEO-1.0\* lib\python /S

Danach legt Ihr noch eine Datei mit dem Namen custom_zodb.py im Zope Hauptverzeichnis an. In diese Datei schreibt Ihr dann folgendene Python Anweisungen:

import ZEO.ClientStorage
Storage=ZEO.ClientStorage.ClientStorage(('localhost',7700))

Damit ist der Zope Server zu einem ZEO Client konfiguriert worden. Falls dem ClientStorage ein Tuple üben wird, wie dieses Programm es macht, beachtet folgendes: Das Tuple hat zwei Elemente, eine Zeichenkette, welche die Serveradresse enthät, sowie einen Dienstzugangspunkt (Port) unter dem der Server seine Dienste anbietet. In diesem Beispiel zeigen wir, wie Client und Server auf demselbem Rechner laufen. Aus diesem Grunde haben wir den Rechnernamen auf "localhost" gesetzt.

Okay, nun ist ZEO auf einem einzigen Rechner soweit startklar. Versucht nun zunächst den Server zu starten. Geht hierzu in einem Terminalprogramm oder dem DOS-Eingabefenster in das Zope Hauptverzeichnis und tippt folgendenes ein:

python lib/python/ZEO/start.py -p 7700

Dies wird den ZEO Server so starten, dass er unter dem Dienstzugangspunkt(Port) mit der Nummer 7700 zu erreichen ist. Nun fehlt noch ein Zope, der als ZEO-Client diesen ZEO Server nutzt. Starte in einem anderem Fenster den Zope Server ganz normal mit dem z2.py Skript:

python z2.py -D

------
2000-10-04T20:43:11 INFO(0) client Trying to connect to server
------
2000-10-04T20:43:11 INFO(0) ClientStorage Connected to storage
------
2000-10-04T20:43:12 PROBLEM(100) ZServer Computing default pinky
------
2000-10-04T20:43:12 INFO(0) ZServer Medusa (V1.19) started at Wed Oct  4 15:43:12 2000
        Hostname: pinky.zopezoo.org
        Port:8080

Beachte, dass in dem obigen Beispiel, Zope zunächst darauf hinweist, dass Zope versucht sich mit dem (ZEO-) Server in Verbindung zu setzen (client Trying to connect to server) um anschliessend darüber zu informieren, dass er es tatsaechlich geschafft hat (ClientStorage Connected to storage). Da ja alles wie geplant funktioniert, kannst Du Dich jetzt wie gewohnt mit http://localhost:8080/manage (oder halt eine andere URL, auf der der Zope-Server zu erreichen ist.) in das Zope-Verwaltungstool einloggen.

Wie Du gesehen hast, sieht noch alles genauso aus wie vorher. Gehe nun in das Kontrollfeld (Control Panel) und klicke auf Datenbankverwaltung (Database Management). Hier wird angezeigt, das Zope mit einem ZEO Server verbunden ist.

ZEO auf einem einzigen Computer ist schonmal ein guter Einstieg, sich mit dem ZEO-System vertraut zu machen und zu sehen wie es funktioniert. ZEO auf einem einzigen Computer zu betreiben, kann die Leistungsfähig der Website nicht verbessern, tatsächlich wird die Leistungsfähigkeit oftmals ein wenig reduziert. Um nun aber wirklich in den Genuss der Vorteile eines ZEO-Systems zu kommen, muss ZEO auf mehreren Rechnern installiert und funktionsfähig sein. Wie man ein solches System in Betrieb nimmt, erklären wir nun im nächsten Abschnitt.

Wie man ZEO auf mehreren Rechnern zum Einsatz bringt.

Die Vorgehensweise ZEO auf mehreren Rechnern zum Betrieb zu bringen, unterscheidet sich von der Inbetriebnahme auf einem einzelnem Rechner kaum. Im Allgemeinen gibt es zwei Arbeitsschritte. Im ersten Schritt startet man einen ZEO Server und im zweitem Schritt startet man einen oder mehrere ZEO Clientsysteme.

Mal angenommen, Ihr hättet vier Rechner. Der erste Rechner mit dem Namen "zooserver" wäre der Zeo Server, und die anderen drei Rechner mit den Namen "zeoclient1","zeoclient2","zeoclient3" wären die Zeo-Clients. Dann wäre der erste Schritt, den Server auf dem Rechner mit dem Namen "zooserver zu starten".

Um den ZEO Server so zu starten, dass er Aufträge; auf dem Dienstzugangspunkt (Port) mit der Nummer 9999 auf dem Rechner "zooserver" bearbeitet, starte den Server mit dem Skript start.py wie folgt:

 python lib/python/ZEO/start.py -p 9999 -h zooserver.zopezoo.org

Dies wird den ZEO Server starten. Nun kannst Du die ZEO-Clients starten, indem Du auf jeden Rechner das Skript custom_zodb.py wie folgt anpasst:

import ZEO.ClientStorage
Storage=ZEO.ClientStorage.ClientStorage(('zooserver.zopezoo.org',9999))

Nun kannst Du auf jedem Client-Rechner das Skript z2.py, wie im letzten Abschnitt (Installation und Inbetriebnahme) erklärt, starten. Beachte, dass bei jedem Client-System die Parameter "host" und "port" (Dienstzugangspunkt) identisch sind. Wenn Du alle drei Rechner mit der gleichen Client-Konfiguration gestartet hast, wirst Du bemerken, dass alle drei Rechner dieselbe Zope-Website anzeigen. Dies kannst Du dadurch überprüfen, dass Du alle Rechner nacheinander auf dem Dienstzugangspunkt (Port) 8080 mit dem Webbrowser untersuchst.

Du möchtest bestimmt ZEO deswegen auf mehreren Rechnern in Betrieb nehmen, um Geschwindkeitsvorteile zu erzielen. Mehrere Rechner in Betrieb zu nehmen, sollte ja auch heissen, dass mehr Seiten pro Zeiteinheit ausgeliefert werden können. Eine geschickte Verteilung der Anfragelast auf mehrere Rechner erfordert jedoch ein wenig Feinarbeit in der Einrichtung des Gesamtsystems. Der nächste Abschnitt erklärt, warum und wie die Last auf mehrere Rechner verteilt werden kann.

Wie man die Last verteilt

Im letztem Beispiel hatten wir einen ZEO-Server und drei ZEO Clients mit den Bezeichnungen zeoclient1. zeoclient2 und zeoclient3. Die drei ZEO Clients sind mit dem ZEO-Server verbunden und jeder Client ist auf seine korrekte Arbeitsweise überprüft worden.

Nun haben wir also drei Rechner, die Inhalte an die Besucher der Website ausliefern können. Das nächste Problem ist nun die einkommenden Seitenanfragen auf alle drei Rechner zu verteilen. Die Besucher der Website sollen aber nur www.zopezoo.org kennen, es wäre viel zu umständlich, die Webseitenbesucher darauf hinzuweisen, dass es ebenfalls möglich ist, die Rechner zeoclient1, zeoclient2, oder zeoclient3 zu benutzen. Auch wäre eine gleichmässige Verteilung der Anfragelast nicht leicht zu bewerkstelligen. Im Grunde genommen wäre es aber viel einfacher den Vorgang der Lastverteilung zu automatisieren.

Es gibt eine Reihe von Lösungsansätzen für dieses Problem, einige davon sind einfach, die anderen sind fortgeschritten und dann gibt es auch auch noch eine kostenintensive Lösung. Im nächsten Abschnitt werden wir auf die üblichsten Formen, Webseitenanfragen auf mehrere Rechner zu verteilen, eingehen. Jede Lösung nutzt eine andere Technologie, während die einen Lösungen mit Hilfe freier oder kommerzieller Software aufbauen, bauen die anderen mit auf Spezialhardware auf.

Die Benutzer wählen einen Server aus

Die einfachste Methode eine Lastverteilung zu erreichen ist es den Besuchern eine Auswahl von Rechnern anzubieten, unter der sie einen ZEO-Client erreichen können. Diese Vorgehensweise erfordert keine zusäztliche Software oder Hardware, es ist nur erforderlich die Liste der verfügbaren ZEO-Clients stets aktuell zu halten. Mit dieser Methode entscheidet also der Benutzer, mit welchem ZEO-Client er in Kontakt treten wird.

Es sei angemerkt, dass diese Methode der Lastverteilung passiv erfolgt, daher hast Du keine Kontrolle darüber für welchen ZEO-Client der Kunde sich entscheidet. Wenn der Benutzer sich für keinen der Serveralternativen entscheidet, wird die Hauptlast weiterhin von dem Hauptrechner mit der Bezeichnung www.zopezoo.org getragen.

Wenn Du keinen Zugriff auf die gespiegelten Websites hast, ist das eine ganz brauchbare Loesung. Wenn eine gespiegelte Website ausfällt, kann der Besucher immer noch entscheiden zu der Website zurückzukehren, über die Du ja auch technischen Zugang hast, um eine andere gespiegelte Site auszuwählen.

Die Methode steigert schon deutlich die Leistungsfähigkeit der Website. Der Benutzer wählt zum Beispiel eine gespiegelte Website aus, die geographisch näher liegt und hat dadurch wahrscheinlich eine gute Antwortzeit bei der Navigation durch die Website. Wenn Ihr beispielsweise einen Server in Dortmund und einen in Sydney stehen hättet, dann wären die User aus Australien meist gut beraten den Server in Syndey auszuwählen.

Um diese Methode zum Einsatz zu bringen, lege ein neues Attribut mit dem Namen "mirror_servers" im Hauptverzeichnis an. In jeder Zeile dieser Property, schreibe eine URL für jeden ZEO client - ein Beispiel ist in Abbildung 11-2 zu sehen.

Figure of property with URLs to mirrors

Figure 11-2 Figure of property with URLs to mirrors

Füge nun etwas DTML zu Deiner Website hinzu, um die Liste der Website-Spiegel anzuzeigen:

Dieses DTML listet alle Spiegel auf, aus denen der Besucher wählen kann. Bei diesem Model ist es gut die Computer so zu benennen, dass die Besucher in der Wahl ihres Spiegels unterstützt werden. Zum Beispiel, wenn Du die Belastung geographisch aufteilst, benenne die Computer nach dem Namen der L�nder.

Falls Du den Usern nicht einen beliebigen Server auswählen lassen willst, kommt noch folgende Mö,glichkeit in Frage: eine Methode index_html nimmt zufällig die Weiterleitung vor. Zum Beispiel könntest Du folgendes DTML-Programm in Deiner www.zopezoo.org verwenden:

This code will redirect any visitors to www.zopezoo.org to a random mirror server. Dieses Programm leitet jeden Besucher der Site www.zopezoo.org zu einem zufälligen Spiegel Server weiter.

Lastverteilung mit Round-Robin DNS.

Das "Domain Name System" oder kurz "DNS" ist ein Verzeichnisdienst ähnlich einem Telefonbuch, der Computernamen (wie zB.: "www.zope.org") in numerische Adressen abbilden kann. So ist es beispielsweise auch möglich, dass einem Rechnernamen mehrere numerische Adressen zugeordnet wird. Durch diesen Trick, der auch als "Round-Robin DNS" bezeichnet wird, wird wie unten in der Abbildung 11-3 auch zu sehen ist, auf eine einfache Art und Weise eine Lastverteilung erreicht.

Figure 11-3 Lastverteilung mit Round-Robin DNS.

Immer wenn www.zopezoo.org im DNS-Verzeichnisdienst angefragt wird, gibt der zuständige Nameserver (zB. Bind oder tinydns) eine der drei Internet-Adressen der Rechner zeoclient1, zeoclient2 oder zeoclient3 heraus und zwar immer in abwechselnder Reihenfolge nacheinander. Auf diese Art und Weise wird die Anfragelast unter den verschiedenen ZEO-Clients verteilt.

Dies ist keineswegs eine optimale Lastverteilungsstrategie, weil DNS-Informationen von anderen Nameservern zwischengespeichert werden. Sobald ein Besucher also die Internet-Adresse für www.zopezoo.org aufgelöst hat, surft er für einen gewissen Zeitraum auf dem selben ZEO-Client. Im allgemeinen ist die dadurch erzielte Lastverteilung durchaus akzeptabel, weil sich die Summe aller Anfragen in der Regel durchaus auf alle ZEO-Clients verteilt.

Eine Schattenseite dieser Lösung ist, daß manche Nameserver die IP-Adresse der Website www.zopezoo.org für Stunden, wenn nicht sogar Tage, auf denselben ZEO-Client abbilden. Wenn ein ZEO-Client ausserhalb Deines Wirkungsbereich liegt und dieser aus irgendeinem Grunde ausfällt, dann wird für einen Bruchteil 1/N von Internetnutzern (wobei N die Anzahl der ZEO-Clients ist) Deine Website nicht erreichbar sein, bis der für sie zuständige Nameserver seine gespeicherten DNS-Informationen erneut aktualisiert.

Deinen zuständigen DNS-Server so einzurichten, das die DNS-Auflösung im Round-Robin ausgeführt wird, ist eine ziemlich fortgeschrittene Technik, die wir in diesem Buch nicht mehr abhandeln werden. Eine gute Einführung in diese Technik, kann aber in der Dokumentation des Apache-Webservers gefunden werden. Lastverteilung mit Round-Robin DNS ist eine nützliche und preiswerte Methode, aber ist doch auch mit Nachteilen verbunden. DNS-Namensdienste können merkwürdige Speicherstrategien haben, der Wunsch nach Verteilung der Last auf mehreren ZEO-Server ist halt von der Strategie der Namensdienste Anfragelast zu verteilen, abhängig geworden. Der nächste Abschnitt erklärt eine komplexere aber auch effektivere Methode Last zu verteilen. Diese Methode wird als "Layer 4 Switchung" (Schicht 4 Lastverteilung) bezeichnet.

Lastverteilung mit Hilfe eines Layer 4 Switches

Mit "Layer 4 Switching" wird die Last transparent, daher für die Surfer unmerklich auf eine Anzahl Rechner umgelenkt. Die Technik ist schon sehr fortgeschritten und wird in diesem Handbuch auch nicht weiter abgehandelt, aber es lohnt sich auf die verschiedenen Produkte hinzuweisen, die das "Layer 4 switching" für euch leisten können.

Beim "Layer 4 Switching" verteilt ein Switch die hereinkommenden Anfragen auf eine Gruppe von ZEO Clienten. Der Switch nimmt die Verteilung nach der ihm gegebenen Konfiguration vor, die Arbeitsweise wird in Abbildung 11-4 dargestellt.

Skizze: Lastverteilung mit einem Layer 4 Switch

Ab hier fette Baustelle

There are hardware and software Layer 4 switches. There are a number of software solutions, but one in general that stands out is the Linux Virtual Server (LVS). This is an extension to the free Linux operating system that lets you turn a Linux computer into a Layer 4 switch. More information on the LVS can be found on its web site.

Es gibt Layer 4 Switches in Hardware- und Softwareausführung. Es gibt eine Reihe von Hardware-Lösungen die für sich beanspruchen eine höhere Leistung zu erbringen wie die reinen Softwarelösungen.(like LVS???)

There are also a number of hardware solutions that claim higher performance than software based solutions like LVS. Cisco Systems has a hardware router called LocalDirector that works as a Layer 4 switch, and Alteon also makes a popular Layer 4 switch.

Wie man mit einer für das Gesamtsystem kritischen Einzel-Kompententen umgeht (Single Point of Failure)

Ohne ZEO ist Dein komplettes Zope System eine kritische Einzelkomponente. Mit ZEO ist es möglich die Gefahr eines Komplettausfalles auf mehrere Rechner zu verteilen, daher der von dem Gesamtsystem erbrachte Dienst ist nur dann bedroht, wenn alle Rechner auf einmal ausfallen. Das Gesamtsystem kann also noch weiterarbeiten, wenn nur ein Rechner ausfäl;t und seinen Dienst einstellt - die restlichen Systeme übernehmen dann einfach die durch den Ausfall erzeugte Mehrarbeit.

Zum Zeitpunkt der Texterstellung, waren ZEO-System nicht komplett ausfallsicher, weil bei Ausfall des zentralen ZEO-Servers, das komplette ZEO-System zum Stillstand kommt - daher es gibt keine Möglichkeit in diesem Fall den zentralen ZEO-Server zu ersetzen. Die nachfolgend beschriebenen Methoden versuchen die Risiken eines Ausfalls durch Verteilen des ZEO-Systems auf mehrere Rechner zu mildern.

Eine weitverbreitete Methode ist es, das Ausfallrisiko des ZEO-Servers durch Einsatz hochwertiger Hardware- Komponenten, regelmässige Sicherungen und den Einsatz leicht zu ersetzender, billiger Standardrechner für die ZEO-Clients, zu verringern.

By investing the bulk of your infrastructure budget on making your ZEO server rock solid (redundant power supplies, RAID, and other fail-safe methods) you can be pretty well assured that your ZEO server will remain up, even if a handful of your inexpensive ZEO clients fail.

Dadurch das der ZEO-Server auf teurer und hochwertiger Hardware läuft ( redundante Stromversorgung, RAID und andere Sicherheitsvorkehrungen ) kann man schon recht sicher sein, das der ZEO-Server stabil läuft und gegebenenfalls im Falle einer Stöhrung schnell wieder zu Einsatz kommen kann.

Like Layer 4 switching, there are a number of products, software and hardware, that help you mitigate this kind of risk. One popular software solution for linux is called fake. Fake is a Linux based utility that can make a backup computer take over for a failed primary computer by "faking out" network addresses. When used in conjunction with monitoring utilities like mon or heartbeat, fake can guarantee almost 100% up-time of your ZEO server and Layer 4 switches. Using fake in this way is beyond the scope of this book.

Anmerkung eines unbekannten Benutzers: Why cann't we program ZEO so that it will make one of the client ZEOs take over the failed ZEO server? Warum können wir ZEO nicht so umprogrammieren, dass einer der ZEO-Clients die Rolle eines ausfallenden ZEO-Servers übernehmen kann ?

So far, we've explained these techniques for mitigating a single point of failure: Bis jetzt haben wir folgende Techniken beschrieben

• Various tools (mirrors, round-robin DNS, Layer 4 switching) can be used to multiplex requests across multiple computers.
• ZEO can be used to distribute your database (ZEO server) to multiple ZEO clients.
• fake, and other tools can be used to provide redundant servers and Layer 4 switches.

The final piece of the puzzle is the ZEO server itself, and where it stores its information. If your primary ZEO server fails, how can your backup ZEO server ensure it has the most recent information that was contained in the primary server? As usual, there are several ways to solve this problem, and they are covered in the next section.

Der ZEO Server im Detail

Bevor wir die Details eines ZEO Server darstellen, werden wir noch einige Details über die Funktion des Zopespeichers im Allgemeinen ausf�hren.

Zope speichert seine Objekte oder andere Informationen nicht unmittelbar auf Festplatte. Stattdessen benutzt Zope eine Speicherkomponente, die sich um die Einzelheiten eines Speichervorgangs kümmert.

This is a very flexible model, because Zope no longer needs to be concerned about opening files, or reading and writing from databases, or sending data across a network (in the case of ZEO). Each particular storage takes care of that task on Zope's behalf.

For example, a plain, stand-alone Zope system can be illustrated in Figure 11-5.

Zope connected to a filestorage

Figure 11-5 Zope connected to a filestorage Comment

You can see there is one Zope application which plugs into a FileStorage. This storage, as its name implies, saves all of its information to a file on the computer's filesystem.

When using ZEO, you simple replace the FileStorage with a ClientStorage, as illustrated in Figure 11-6.

Zope with a Client Storage and Storage server

Figure 11-6 Zope with a Client Storage and Storage server Comment

Instead of saving objects to a file, a ClientStorage sends objects over a network connection to a Storage Server. As you can see in the illustration, the Storage Server uses a FileStorage to save that information to a file on the ZEO server's filesystem.

Storages are interchangeable and easy to implement. Because of their interchangeable nature, ZEO Storage Servers can use ZEO ClientStorages to pass on object data to yet another ZEO Storage Server. This is illustrated in Figure 11-7.

Multi-tiered ZEO system

Figure 11-7 Multi-tiered ZEO system

Here, you can see a number of ZEO clients funnel down through three ZEO servers, which in turn act as ZEO clients themselves and funnel down into the final, central ZEO server than saves its information in a FileStorage. Now, that central ZEO server is the single point of failure in the system. If any of your other clients, or intermediate servers fail, the system will still continue to work, but if the central server fails, then you need an alternative.

Using fake you can have a back-up storage server strategy, but this method is not very well proven and hasn't been explored by the authors. In the future, ZEO will have a "multiple-server" feature, that allows a group of storage servers to act as a quorum, so if one or more storage servers fail, the remaining servers in the quorum can continue to serve objects.

Es gibt zahlreiche Vorteile für ein derartiges Vorgehen, insbesondere falls Sie eine stark über das Netz verteilte Objektdatenbank aufbauen wollen. Wie bei allen Systemen mit Vorteilen, gibt es auch hier einige Nachteile. Diese Nachteile werden im folgenden Abschnitt untersucht.

ZEO Fallstricke

Größtenteils unterscheidet sich der Betrieb mit ZEO nicht vom Betrieb eines normalenZopeservers, aber es gibt doch einige Dinge zu beachten.

Zum einem dauert es länger bis Informationen in die Zope object Datenbank weggeschrieben werden. Dies verlangsamt zwar die Benutzung eines Zope nicht (weil Zope diese Operation nebenläufig im Hintergrund erledigt), aber es erhöht die Wahrscheinlichkeit einen "ConflictError" zu erhalten. Ein derartiger "ConflictError" passiert wenn beispielsweise zwei ZEO-Clients gleichzeitig auf ein Object schreibend zugreifen wollen. Einer der beiden ZEO Clients gewinnt diesen "Konfikt" dann und kann ganz normal weiterarbeiten. Der andere ZEO-Client hingegen verliert diesen "Konfikt" und muss seinen Schreibvorgang wiederholen.

Derartike Konflikte sollten so selten wie möglich vorkommen, da sie das System ausbremsen können. Während es ganz normal sein kann, hin und wieder einen derartiken Konflikt zu haben (aufgrund der vielen nebenläufigen Aufgaben, die ein Zope bearbeitet), ist es nicht wünschenswerte eine Menge dieser Fehlerfehler zu haben. Ein schlimmer Fall wäre beispielsweise ein ZEO Client, der in sehr kurzen Intervallen wiederholt versucht, auf ein Objekt schreibend zuzugreifen. In diesem Fall wird es eine Anhäufung von "ConflictErrors" geben und infolgedessen eine große Menge Wiederholungsversuche. Wenn ein ZEO client dreimal erfolglos versucht hat in die Datenbank zu schreiben, weil er jedesmal einen "ConflictError" ausglöst hat, dann wir der Schreibvorgang dieses ZEO-Clients nicht geschrieben und die Daten werden nicht geschrieben.

Weil es bei Verwendung von ZEO länger dauert bis Daten geschrieben werden, sind die Chancen einen "ConflictError" zu bekommen auch höher als wenn man ein Zope ohne ZEO betreiben würde. Aus diesem Grunde ist es ein ZOPE mit ZEO bei Schreibvorg�ngen fehleranfälliger. Dieses Problem sollten Sie beim Design Ihrer Netzwerkes oder Ihrer Anwendung im Blickfeld behalten. Als eine Daumenregel gilt: die Wahrscheinlichkeit einen "ConflictError" zu bekommen erhöht sich mit zunehmender Anzahl regelmässiger Schreibvorg&aum;nge. Auf der einen Seite verringern schnellere und zuverlässigere Netzwerkverbindungen und Computer die Chancen einen "ConflictError" zu bekommen. Auf der anderen Seite hingegen können die meisten der Probleme mit "ConflictErrors" vermieden werden, wenn man diese beide Faktoren berücksichtigt.

Es ist noch wichtig zu erwähnen, daß zwischen ZEO-Server und ZEO-Client zur Zeitpunkt der Erstellung dieses Dokumentes keine abhörsichere Verbindungen aufgebaut werden, daher der komplette Datenaustausch geschieht ungeschützt über das Netzwerk. Aus diesem Grunde solltet Ihr das ZEO-System nicht einfach ohne Sicherungsmassnahmen ins &oum;ffentlich zugreifbare Internet stellen. Falls Ihr doch auf diese dumme Idee kommen solltet, braucht Ihr natuer;ich nicht zu wundern, wenn irgendjemand irgendwelche Daten in euren ZEO-Server schreibt!!! - Dies kann schon sehr gravierende Auswirkungen auf euren Serverbetrieb haben !!!

Schliesslich sei noch erwähnt, daß es zwischen ZEO-Server und ZEO-Client keine verschlüsselten, und daher abhörsicheren Verbindungen gibt. Dies ist kein unlösbares Problem, da Du ja auch andere Werkzeuge wie Firewalls dazu einsetzen kannst, um Deine ZEO-Server abzuschirmen. Wenn Du hingegen keine Möglichkeit siehst, eine Firewall einzusetzten, Du aber trotzden den Datenaustausch zwischen den ZEO-Systemen über ein unsicheres Netzwerk, wie z.B. das öffentliche Internet-System gewährleisten willst, können wir Dir nur wärmstens den Einsatz von Programmen wie OpenSSH und stunnel empfehlen. Diese ermöglichen einen verschlüselten Datenverkehr zwischen ZEO Server und den ZEO Clients. Wie diese Programme zu installieren und einzurichten sind werden wir an dieser Stelle nicht beschreiben - die wüde den Rahmen dieses Handbuches zu sehr strapazieren. Es sei nur auf die gute Dokumentation auf den Herstellerseiten der Programme im Internet verwiesen. Wenn Ihr wissen wollt wie eine Firewall funktioniert und einzurichten ist, können wir euch das Buch "Linux Firewalls" von Robert Ziegler empfehlen, welches vom Verlag "New Riders" herausgegeben wurde. (Anmerkung des Übersetzers: lieber mal eine deutsches Buch empfehlen ?)

Schlussbemerkungen

In diesem Kapitel haben wir einen Blick auf ZEO geworfen, und haben dabei erfahren wie ZEO die Kapazitäten eines Webauftrittes verbesser kann. Ausserdem haben wir nicht nur ZEO auf einem Rechner zum Laufen gebracht um und mit dessen Funktionsweise vertraut zu machen, sondern wir haben ZEO auch auf mehreren Rechnern zum Einsatz gebracht. Weiterhin haben wir uns mit verschiedenen Lastverteilungsverfahren beschäftigt, mit denen wir die Last unsere Webseitenbesucher auf mehrere Rechner zu verteilen.

ZEO is nicht die Antwort auf alle Probleme, und wie jedes andere System, welches mit vielen Rechnern im Verbund arbeitet, wird eine zusätliche Komplexität hinter den Kullisen der Website aufgebaut. Die Komplexität wird besonders dann stark spürbar, wenn viele dynamisch erzeugte Webseiten an das Publikum ausgeliefert werden sollen.