die fabasoft referenzarchitektur im microsoft windows

die fabasoft referenzarchitektur im microsoft
windows-umfeld
die fabasoft referenzarchitektur
im microsoft windows-umfeld
ISBN: 3-902495-04-9
Helmut Fallmann, Oliver Albl, Robert Hell, Christoph Jerschitz
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 1
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 2
ISBN: 3-902495-04-9
Alle Rechte der Verbreitung, auch durch fotomechanische Wiedergabe,
Tonträger jeder Art, auszugsweisen Nachdruck oder Einspeicherung und Rückgewinnung in Datenverarbeitungsanlagen aller Art, sind vorbehalten.
Es wird darauf verwiesen, dass alle Angaben in diesem Fachbuch trotz
sorgfältiger Bearbeitung ohne Gewähr erfolgen und eine Haftung der Autoren
oder des Verlages ausgeschlossen ist.
Aus Gründen der einfacheren Lesbarkeit wird auf die geschlechtsspezifische
Differenzierung, z.B. Benutzer/-innen, verzichtet. Entsprechende Begriffe gelten im
Sinne der Gleichbehandlung grundsätzlich für beide Geschlechter.
Fabasoft und das Fabasoft Logo sind registrierte Warenzeichen der Fabasoft AG.
Microsoft, MS-DOS, Windows, das Windows-Logo, Windows 95, Windows 98,
Windows Me, Windows XP, Windows NT, Windows 2000, Windows Server,
Active Directory, Outlook, Excel, Word, PowerPoint, Visual Studio, Visual Basic,
Visual C++ sind entweder registrierte Warenzeichen oder Warenzeichen der
Microsoft Corporation.
Alle anderen verwendeten Hard- und Softwarenamen sind Handelsnamen
und/oder Marken der jeweiligen Hersteller.
© Fabasoft Intl. Software GmbH, Linz 2004
Honauerstraße 4, 4020 Linz
Tel.: +43 (732) 606162
http://www.fabasoft.at
Gestaltung: SCHRANGL’PRESLMAYER’SCHAURHOFER Marketing GmbH, Linz
Druck: Gutenberg-Werbering GmbH, Linz
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 3
die fabasoft referenzarchitektur
im microsoft windows-umfeld
Helmut Fallmann, Oliver Albl,
Robert Hell, Christoph Jerschitz
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 4
inhaltsverzeichnis
2004
die fabasoft referenzarchitektur
im microsoft windows-umfeld
______________________________________________
1
2
einleitung und zieldefinition
____________________________________________________
definition von hochverfügbarkeit
______________________________________
1
10
16
2.1 Fehler ____________________________________________________________________________________________________________ 17
2.2 MTBF
____________________________________________________________________________________________________________
17
2.3 MTTR
____________________________________________________________________________________________________________
19
2.4 Systemstillstandszeit (engl. Downtime) __________________________________________________________ 19
2.5 Service-Level-Management
__________________________________________________________________________
21
2.6 Verfügbarkeit (engl. Availability) ____________________________________________________________________ 21
2.7 Verfügbarkeitsgrade ______________________________________________________________________________________ 22
2.8 Hochverfügbarkeit
________________________________________________________________________________________
3
die fabasoft referenzarchitektur 5.0
im überblick
4
technologien für hochverfügbarkeit
__________________________________________________________________________________________
4.1 Lastverteiler (Load-Balancer, Content-Switch)
24
28
________________________________
38
______________________________________________
39
Verteilungsalgorithmen (Load Balancing Policies) __________________________________________________ 40
Sitzungsaffinität (Session Affinity) ______________________________________________________________________ 42
Fehlerstrategien (Server Failure Policies) ______________________________________________________________ 45
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 5
5
4.2 Microsoft Windows Server 2003 Clustering Services
____________________________________
48
Architektur der Servercluster – Virtuelle Server ____________________________________________________ 48
Clustertaugliche Dienste ____________________________________________________________________________________ 49
Clusterressourcen ____________________________________________________________________________________________ 50
Active/Active versus Active/Passive ____________________________________________________________________ 50
Quorum __________________________________________________________________________________________________________ 51
Heartbeat ________________________________________________________________________________________________________ 51
Failover __________________________________________________________________________________________________________ 51
Failback __________________________________________________________________________________________________________ 54
4.3 Hochverfügbare Server __________________________________________________________________________________ 57
Lüfter ______________________________________________________________________________________________________________ 57
Netzteile__________________________________________________________________________________________________________ 57
Systemplatten __________________________________________________________________________________________________ 57
Speicher __________________________________________________________________________________________________________ 57
Netzwerkanbindung __________________________________________________________________________________________ 58
SAN-Anbindung ________________________________________________________________________________________________ 59
5
die subsysteme der fabasoft
referenzarchitektur 5.0
________________________________________________________________
62
5.1 Arbeitsplatz (Webbrowser-Client) __________________________________________________________________ 64
Beschreibung __________________________________________________________________________________________________ 64
Verfügbarkeit____________________________________________________________________________________________________ 65
5.2 Arbeitsplatz-LAN (Client-LAN) ________________________________________________________________________ 66
Beschreibung __________________________________________________________________________________________________ 66
Hochverfügbarkeit ____________________________________________________________________________________________ 67
5.3 Client-Firewall
______________________________________________________________________________________________
68
Beschreibung __________________________________________________________________________________________________ 68
Hochverfügbarkeit ____________________________________________________________________________________________ 69
5.4 WAN ______________________________________________________________________________________________________________ 71
Beschreibung __________________________________________________________________________________________________ 71
Hochverfügbarkeit ____________________________________________________________________________________________ 71
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 6
5.5 Anschaltknoten ______________________________________________________________________________________________ 72
Beschreibung __________________________________________________________________________________________________ 72
Hochverfügbarkeit ____________________________________________________________________________________________ 73
5.6 Server-Firewall ______________________________________________________________________________________________ 75
Beschreibung __________________________________________________________________________________________________ 75
Hochverfügbarkeit ____________________________________________________________________________________________ 75
5.7 Lastverteiler (Load-Balancer, Content-Switch)
______________________________________________
78
Beschreibung __________________________________________________________________________________________________ 78
Hochverfügbarkeit ____________________________________________________________________________________________ 79
5.8 Frontend-LAN
________________________________________________________________________________________________
85
Beschreibung __________________________________________________________________________________________________ 85
Hochverfügbarkeit ____________________________________________________________________________________________ 85
5.9 Webserver-Farm ____________________________________________________________________________________________ 87
Beschreibung __________________________________________________________________________________________________ 87
Performance-Überlegungen ________________________________________________________________________________ 88
Hochverfügbarkeit ____________________________________________________________________________________________ 89
5.10 Backend-LAN ________________________________________________________________________________________________ 91
Beschreibung __________________________________________________________________________________________________ 91
Hochverfügbarkeit ____________________________________________________________________________________________ 92
5.11 Konvertierungsserver-Farm ____________________________________________________________________________ 95
Beschreibung __________________________________________________________________________________________________ 95
Performance-Überlegungen ________________________________________________________________________________ 95
Hochverfügbarkeit ____________________________________________________________________________________________ 96
5.12 AT-Server (Automated Tasks)
________________________________________________________________________
98
Beschreibung __________________________________________________________________________________________________ 98
Hochverfügbarkeit ____________________________________________________________________________________________ 99
5.13 Backendserver-Cluster
________________________________________________________________________________
100
Beschreibung __________________________________________________________________________________________________ 100
Hochverfügbarkeit ____________________________________________________________________________________________ 101
Performance-Überlegungen ______________________________________________________________________________ 101
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 7
7
5.14 Datenbankserver-Cluster ______________________________________________________________________________ 103
Beschreibung __________________________________________________________________________________________________ 103
Hochverfügbarkeit __________________________________________________________________________________________ 104
Performance-Überlegungen ______________________________________________________________________________ 104
5.15 Storage Area Network (SAN) ________________________________________________________________________ 106
Beschreibung __________________________________________________________________________________________________ 106
Hochverfügbarkeit __________________________________________________________________________________________ 107
Performance-Überlegungen ______________________________________________________________________________ 107
5.16 Storagesystem ______________________________________________________________________________________________ 108
Beschreibung __________________________________________________________________________________________________ 108
Hochverfügbarkeit __________________________________________________________________________________________ 109
Performance-Überlegungen ______________________________________________________________________________ 109
5.17 Tape-Library__________________________________________________________________________________________________ 112
Beschreibung __________________________________________________________________________________________________ 112
Hochverfügbarkeit __________________________________________________________________________________________ 112
Performance-Überlegungen ______________________________________________________________________________ 112
5.18 Server für Basisdienste ________________________________________________________________________________ 113
Microsoft Windows-Domaincontroller ________________________________________________________________ 113
Mailserver ______________________________________________________________________________________________________ 115
Managementserver __________________________________________________________________________________________ 117
Backupserver __________________________________________________________________________________________________ 120
Indexserver ____________________________________________________________________________________________________ 122
6
datensicherheit: online-backup, recovery
________________
126
6.1 Voraussetzungen __________________________________________________________________________________________ 127
6.2 Datensicherung und Wiederherstellung einer
Fabasoft Components Domäne (Backup und Recovery)
________________________________
128
Konsistenz ______________________________________________________________________________________________________ 128
Die Microsoft SQL Server Datenbanken ______________________________________________________________ 129
Fabasoft Components MMC-Service-Bereiche ______________________________________________________ 129
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 8
6.3 Beispiel ________________________________________________________________________________________________________ 130
Beschreibung der Infrastruktur __________________________________________________________________________ 131
EMC2 Symmetrix Device Group Layout ________________________________________________________________ 136
Datensicherung (Backup) __________________________________________________________________________________ 137
Wiederherstellung (Restore / Recovery) ______________________________________________________________ 138
Beispiele für die Prozeduren fsc_settxmark und fsc_setlocaltxmark ________________________ 141
7
betriebsprozesse und
systemmanagement
__________________________________________________________________
144
7.1 Installation der wesentlichen Fabasoft Services __________________________________________ 146
Backendserver-Rollout ______________________________________________________________________________________ 146
Webserver-Rollout __________________________________________________________________________________________ 147
Konvertierungsserver-Rollout ____________________________________________________________________________ 149
Überprüfung der Produktionsumgebung vor Inbetriebnahme____________________________________ 150
7.2 Systemmanagement für die Fabasoft Referenzarchitektur ____________________________ 152
Kurzbeschreibung einiger Systemmanagementwerkzeuge ______________________________________ 154
8
glossar
9
abbildungsverzeichnis
10
literaturverzeichnis
__________________________________________________________________________________________________
160
______________________________________________________________
164
______________________________________________________________________
168
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 9
9
05Referenzarchitektur
1
04.04.2005
12:25 Uhr
Seite 10
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 11
11
1 einleitung und zieldefinition
Der Erfolg eines Unternehmens im globalen Wettbewerb basiert auf dem Einsatz der Informationsund Kommunikationstechnologie. Dazu ist eine Infrastruktur Voraussetzung, die den Anforderungen
des jeweiligen Unternehmens entspricht sowie ausbau- und anpassungsfähig an zukünftige Anforderungen ist.
Am Beispiel von E-Government vom Antrag bis zur Zustellung (siehe Abbildung 1) ist absehbar, dass aufgrund
des Nutzenversprechens jedenfalls im Bereich der Kommunikation mit dem Bürger der Bedarf an einem hochverfügbaren Betrieb von 24 Stunden an allen Tagen eines Jahres (7x24-Betrieb) besteht.
Darüber hinaus stellen die über E-Government angebotenen Dienste in Form von Webanwendungen und WebServices einen wesentlichen Standortfaktor dar, beispielsweise im Bereich des globalen Wettbewerbes um
(Konzern)-Standorte. Dazu findet auch jährlich ein Benchmarking der EU-Kommission (ein Vergleich von
15 EU-Mitgliedsstaaten sowie Island, Norwegen und Schweiz) statt [EuUn04]. Österreich konnte sich hinsichtlich des Online-Umsetzungsgrades der öffentlichen Serviceangebote vom Platz 11 im Jahr 2002 auf Platz 4 im
Jahr 2003 steigern. Bei den vollständig elektronisch abwickelbaren E-Government-Diensten liegt Österreich auf
Platz 2.
Unter Webanwendungen werden solche Systeme verstanden, deren Benutzerschnittstelle auf den Standards
HTML (grafische Darstellung im Webbrowser-Client) und HTTP (Übertragungsprotokoll) basiert.
Die Benutzerschnittstelle einer Webanwendung kann überall im Internet (zu jeder Zeit, an jedem Ort, idealerweise in jedem Webbrowser) zur Verfügung stehen.
Die Softwareprodukte Fabasoft eCRM-Suite 5.0 (Customer Relationship Management, Enterprise Content
Management etc.), Fabasoft eGov-Suite 5.0 (Elektronische Aktenverwaltung, Public Records Management),
Fabasoft eGov-Forms 5.0 (Online-Formulare) und Fabasoft Zustellung 5.0 (Elektronische Zustellung, in Österreich geregelt durch das Zustellgesetz und E-Government Gesetz) bedienen sich der Fabasoft Referenzarchitektur 5.0, um Hochverfügbarkeit, Skalierbarkeit und Managebarkeit zu erreichen.
Die Informationstechnologie spielt aber auch hinsichtlich sozialpolitischer Fragestellungen eine entscheidende
Rolle. Beispielsweise zeigt die Diskussion zu den Ladenöffnungszeiten in der Europäischen Union die Wünsche
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 12
der Konsumenten und der Arbeitgeber einerseits sowie die Sorgen der Angestellten andererseits recht deutlich
auf:
Die Konsumenten wollen längere Öffnungszeiten. Ihre Konsumbedürfnisse sollen außerhalb ihrer – immer
flexibler werdenden Arbeitszeiten – gedeckt werden können.
Die Arbeitgeber müssen im Wettbewerb zwischen großen und kleinen Unternehmen, globalen und lokalen
Marktteilnehmern ihre Entscheidungen über den Erfolg ihres Unternehmens treffen.
Die von den verlängerten Ladenöffnungszeiten betroffenen Angestellten verteidigen ihr Privatleben, sehen
aber auch die Arbeitsplatzsituation (z.B. Arbeitslosenrate in Deutschland).
Abbildung 1
E-Government: Von Antrag
bis Zustellung
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 13
1 Einleitung und Zieldefinition
In vielen Bereichen sind Online-Dienste ein Lösungsansatz für diesen scheinbaren Widerspruch, beispielsweise:
Online Banking (z.B. www.ba-ca.com, www.netbanking.at, www.elba.at)
bargeldloses Bezahlen mit Karte und Code (z.B. Maestro-Karte, Kreditkarten)
E-Government (z.B. www.help.gv.at)
Buchhandel (z.B. www.amazon.de)
etc.
Um erfolgreich sein zu können, muss ein Online-Dienst zumindest folgende Kriterien erfüllen:
massentaugliche Geschäftsprozesse: einfachste Bedienung ohne Schulung
7 Tage mal 24 Stunden Verfügbarkeit in jeder Woche
Als Beispiel für ein solches einfach zu bedienendes und – für uns alle selbstverständlich – hochverfügbares
System ist das internationale Telefonsystem. Es ist dies wohl das bislang global erfolgreichste Netzwerksystem.
Zehn Tasten (Ziffern), ein Hörer und ein internationales Telefonverzeichnis reichen aus, um mittlerweile jeden
Punkt der Erde (inkl. Satellitentelefon) erreichen zu können.
Unternehmen, die ihre Geschäftsprozesse einmal auf E-Business umgestellt haben, sind von der Verfügbarkeit
ihrer Systeme abhängig. Jeder Systemstillstand gefährdet den Bestand des Unternehmens. Der Wettbewerb findet global statt. Ein Systemstillstand führt nicht nur zu einem Umsatzentgang, sondern insbesondere zu einem
Verlust von Kunden. Die Loyalität der Kunden hängt von der Verfügbarkeit der Online-Dienste ab.
Systemstillstandszeiten können in zwei Kategorien klassifiziert werden. Die geplanten Systemstillstandszeiten
(Planned Downtime) werden von der Betriebsführung für Wartungsarbeiten und Aktualisierungen der Hard- und
Software genutzt. Die ungeplanten Systemstillstandszeiten (Unplanned Downtime) werden von unvorhersehbaren Ereignissen wie beispielsweise Stromausfällen, Hardware- und Softwarefehlern, menschlichem Versagen
oder Naturkatastrophen verursacht.
Um die Verfügbarkeit zu maximieren, müssen diese Systemstillstandszeiten und deren negative Auswirkungen
auf die Nutzer des Systems minimiert werden.
13
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 14
Die Technologie zur Erreichung von hoher Verfügbarkeit und fehlertoleranten Systemen hat sich in den letzten
Jahren wesentlich weiterentwickelt. Die Preise dieser Technologien sind gefallen. Hochverfügbarkeit ist leistbar geworden.
Hier wird eine Architektur für hochverfügbare Online-Dienste vorgestellt, die als Implementierung unter dem
Betriebssystem Microsoft Windows Server 2003 dem Stand der Technik entspricht.
Für die Fabasoft Referenzarchitektur 6.0 wird zusätzlich eine Implementierung auf Basis des Betriebssystems
Linux sowie als Mischform Microsoft Windows und Linux unterstützt werden.
Die Kapitel dieses Buches sind folgendermaßen aufgebaut:
Einleitung
Motivation zum Thema Hochverfügbarkeit für Anwendungsgebiete im Bereich Web-Services und Webanwendungen insbesondere am Beispiel E-Government.
Definition von Hochverfügbarkeit
Die grundlegenden Definitionen und Formeln für Hochverfügbarkeit, Stillstandszeiten und Verfügbarkeitsklassen.
Die Fabasoft Referenzarchitektur 5.0 im Überblick
Vermittlung des Basiswissens über die Fabasoft Softwarearchitektur in der Version 5.0 der auf der Fabasoft
Components Technologie basierenden Softwareprodukte und die zugehörige Fabasoft Referenzarchitektur 5.0
für die einer Produktionsumgebung zugrunde liegende Infrastrukturtechnologie.
Technologien für Hochverfügbarkeit
Beschreibung der von der Fabasoft Referenzarchitektur verwendeten Technologien für die Bereitstellung der in
den einzelnen Subsystemen benötigten Redundanz.
Die einzelnen Subsysteme der Fabasoft Referenzarchitektur 5.0
Kurzbeschreibungen, Überlegungen zur Hochverfügbarkeit und Leistungsfähigkeit sowie konkrete Beispiele zu
jedem einzelnen Subsystem der Fabasoft Referenzarchitektur 5.0.
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 15
1 Einleitung und Zieldefinition
Datensicherheit: Online-Backup, Recovery
Online-Backup und Recovery der Geschäftsobjekte einer Fabasoft Components Domäne am Beispiel von EMC2
TimeFinder und Microsoft SQL Server 2000.
Betriebsprozesse und Systemmanagement
Kurzanleitungen zur Installation der Server und zu den Aufgaben einer Betriebsführung.
Dieses Buch soll mit dem Überblick über die Fabasoft Referenzarchitektur ein gemeinsames Verständnis zu den
Komponenten und zur Begrifflichkeit hinsichtlich einer Infrastruktur für die Fabasoft Softwareprodukte herstellen.
Für die Umsetzung der Fabasoft Referenzarchitektur 5.0 in einem konkreten Projekt inklusive Dimensionierung
der Infrastrukturkomponenten sollte im Einzelfall auf die Beratungsleistungen des Produktherstellers Fabasoft
zurückgegriffen werden.
15
05Referenzarchitektur
2
04.04.2005
12:25 Uhr
Seite 16
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 17
definition von
2 hochverfügbarkeit
Die hier dargestellten Definitionen und Grundregeln zur Erreichung einer hohen Verfügbarkeit von
IT-Systemen stellen die Eckpfeiler für die Fabasoft Referenzarchitektur 5.0 dar.
2.1
fehler
„[engl. error, fault], eine Diskrepanz zwischen den wahren, festgelegten bzw. theoretisch korrekten Werten,
Bedingungen und Vorgängen einerseits und den berechneten, eingegebenen oder beobachteten Werten, Bedingungen und Vorgängen im Rechner andererseits. Daneben gibt es Systemstörungen oder Abweichungen vom
Sollzustand eines Geräts (z. B. bei einem Drucker Papierstau, entleerte Tintenpatrone, fehlendes Papier o. Ä.),
die zwar nicht von der obigen Definition erfasst werden, aber trotzdem auch als Fehler bezeichnet werden. Je
nach Schwere eines Fehlers führt ein Fehler zum Systemausfall (fataler Fehler), zu schwerer, deutlicher oder
geringer Funktionsbeeinträchtigung (kritischer Fehler, Hauptfehler, Nebenfehler) oder ein Fehler äußert sich
überhaupt nicht (belangloser Fehler). Die Auslegung eines Systems auf Fehlertoleranz, z. B. durch Schaffung von
Redundanz, begünstigt das unbeeinträchtigte Ablaufen eines fehlerhaften Programms. Aus historischen
Gründen wird ein Fehler oft Bug genannt.” [Broc02]
2.2
mtbf
„[Abk. für Mean Time Between Failures, dt. »mittlere Zeit zwischen Ausfällen«], ein Wert, der angibt, wie lange ein Gerät störungsfrei läuft, bis es durch einen Defekt ausfällt. Üblicherweise sollte die Zahl mit einer Zeiteinheit versehen sein; wo sie fehlt, sind meist Stunden gemeint. Ein MTBF von 500 000 bedeutet beispielsweise, dass ein Gerät 500 000 Stunden fehlerfrei läuft, entsprechend etwas mehr als 57 Jahre.
Die Zahlen entsprechen i. d. R. nicht den technischen Gegebenheiten. Würden die Geräte wirklich so lange
getestet, wären sie schon längst veraltet, wenn sie in den Handel kämen. Vielmehr ermittelt man den MTBF in
statistischen Versuchen, indem man eine große Zahl von Geräten, meist mehrere Tausend, über eine bestimmte Zeitspanne, die einige Tage bis wenigen Wochen umfasst, ununterbrochen laufen lässt. Danach zählt man die
defekten Geräte, addiert die störungsfreien Betriebsstunden aller Geräte auf und teilt die so ermittelte Stunden-
17
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 18
zahl durch die Anzahl der Störungen. Dies liefert als Resultat direkt den MTBF, der also nur einen groben Hinweis gibt, wie robust ein bestimmtes Gerät ist.
Die Garantiezeiten, in denen ein Hersteller für seine Produkte haftet, sind i. d. R. weitaus geringer als der MTBF.
Sie sind meist ein Resultat unterschiedlicher betriebswirtschaftlicher Schätzungen der Hersteller, z. B. wie lange es dauern wird, bis das aktuelle Gerät aus dem Handel verschwunden ist und durch ein Nachfolgemodell
ersetzt werden kann. Die Anfang 2002 in der EU eingeführte einheitliche Mindestgarantie von zwei Jahren auf
Elektrogeräte ist eine politische Vorgabe.” [Broc02]
Diese Definition hat die Definition MTTF [Mean Time To Failure, dt. »mittlere Zeit bis zum Ausfall«] – ein Wert,
der angibt, wie lange ein Gerät ab Inbetriebnahme störungsfrei läuft, bis es durch einen Defekt ausfällt – abgelöst. Historisch gesehen basiert die Formel für die Berechnung der Verfügbarkeit auf der MTTF.
Abbildung 2
MTTF einiger
Hardwarekomponenten
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 19
2. Definition von Hochverfügbarkeit
2.2 MTBF
2.3 MTTR
2.4 Systemstillstandszeit (engl. Downtime)
2.3
mttr
„[Abk. für Mean Time To Recovery, dt. »mittlere Zeit bis zur Fehlerbehebung«], ein statistischer Wert, der angibt,
wie lange es dauert, bis ein Defekt behoben ist.“ [Broc02]
Die Fehlerbehebung besteht aus drei Phasen:
1. Bemerken (Erkennen) des Fehlers
2. Diagnose der Fehlerursache
3. Behebung des Fehlers
Es ist wichtig, die MTTR möglichst klein zu halten. Maßnahmen dazu sind beispielsweise häufige Voll-Backups
auf Festplatten, ein Lager mit Ersatzteilen vor Ort, „selbstheilende“ Softwarekomponenten etc.
2.4
systemstillstandszeit (engl. downtime)
Wenn ein Nutzer seine Arbeit nicht in der dafür vorgesehenen Zeit erledigen kann, dann steht das System still.
Diese Systemstillstandszeit setzt sich aus Zeiten geplanter Stillstände (engl. Planned Downtime) und Zeiten
ungeplanter Stillstände (engl. Unplanned Downtime) zusammen.
Je mehr die externe, globale Nutzung der angebotenen Dienste durch Kunden im Wege des Internets im Vordergrund steht, umso mehr Gewicht bekommen auch die geplanten Stillstände im Hinblick auf die zugesicherten
Service-Levels.
Diese enge Auslegung definiert Stillstandszeit als die Summe der geplanten und der ungeplanten Systemstillstandszeiten.
Die (statistisch) voraussichtliche Stillstandszeit pro Jahr bei bekannter Verfügbarkeit wird wie folgt
berechnet:
19
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 20
1 Jahr
= 525.960 [Minuten]
ν
= Verfügbarkeit in Prozent
Stillstandszeit pro Jahr
= 525.960 – ν × 525.960
Eine Statistik zu den Ursachen für Systemstillstände wird in Abbildung 3 wiedergegeben. Ausdrücklich sei hier
auf den kritischen Erfolgsfaktor Serversoftware hingewiesen. Insbesondere Treibersoftware für die im Serverbereich eingesetzten Hardwarekomponenten ist genau zu beobachten.
Abbildung 3
Ursachen für Systemstillstände [IEEE95]
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 21
2. Definition von Hochverfügbarkeit
2.4 Systemstillstandszeit (engl. Downtime)
2.5 Service-Level-Management
2.6 Verfügbarkeit (engl. Availability)
2.5
service-level-management
„Das Service Level Management beschäftigt sich mit den Verhandlungen für Service Level Agreements (SLAs)
sowie mit deren Management. Die Verfügbarkeit ist dabei eines der wichtigsten Themen, die es festzulegen
gilt.“ [vBKP02]
2.6
verfügbarkeit (engl. availability)
„Merkmal von Computersystemen, Geräten oder Komponenten, zur Nutzung bereitzustehen und Nutzern Zugang
zu gewähren.“ [Broc02]
Der Verfügbarkeit liegen folgende Rahmenbedingungen zugrunde:
Die Definition der Qualität der zur Verfügung stehenden Dienste (Service-Level)
Die Definition des Beobachtungszeitraumes (7x24 Stunden pro Woche)
Die Verfügbarkeit wird als Prozentwert angegeben
Verfügbarkeit =
MTBF
(MTBF + MTTR)
Daraus ergeben sich folgende, in der Architektur und deren Umsetzung zu berücksichtigende Schlussfolgerungen:
Wenn die MTTR sehr klein (gegen Null) gehalten werden kann, dann strebt die Verfügbarkeit gegen 100 %.
Eine vorausschauende Planung mit umfassenden Tests und einer lückenlos dokumentierten Umsetzung samt
laufend zu aktualisierendem Betriebshandbuch für alle vorhersehbaren Störfälle schaffen hierzu für ein trainiertes Team die geeignete Voraussetzung.
Wenn die MTBF sehr groß ist, dann hat die MTTR weniger Einfluss auf die Verfügbarkeit. Durch den Einsatz
von Redundanz wird die MTBF für jeweils parallel geschaltete Komponenten erhöht.
21
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 22
Die Verfügbarkeit eines großen Gesamtsystems wird aus den Verfügbarkeiten der parallel und seriell geschalteten Komponenten entlang des Datenpfades – erkennbar im Blockdiagramm des Systems – berechnet.
ν = Verfügbarkeit der einzelnen Komponente
n
Serielle Verfügbarkeit
=
∏ν
i
i=1
n
Parallele Verfügbarkeit
1 – ∏ (1 – νi )
i=1
Eine Komponente in diesen Gleichungen kann sowohl eine Einzelkomponente, als auch eine zusammengesetzte
Komponente sein.
Die Gleichung für die parallele Verfügbarkeit gilt für einfache parallel geschaltete Komponenten. Darüber hinaus
sei noch die n+m-Redundanz erwähnt, für die gesonderte Gleichungen existieren. Bei einer n+m-Redundanz
werden n Komponenten für die Funktion benötigt und m Komponenten stehen als redundante Reserve bereit.
Beispielsweise werden im Bereich der modularen Rechenzentrumsklimatisierung bevorzugt n+1 Klimageräte
eingesetzt.
2.7
verfügbarkeitsgrade
Systeme werden nach den Anforderungen ihrer Nutzung im entsprechenden Verfügbarkeitsgrad ausgelegt.
Beispiele für die in Abbildung 4 definierten Verfügbarkeitsgrade sind:
Für den privaten Gebrauch trifft man häufig keine besonderen Vorkehrungen (lediglich Sicherungen der
Daten).
In Abteilungsrechnern werden die Daten durch Plattenspiegelung (RAID-1) geschützt.
Für unternehmenskritische Anwendungen werden hochverfügbare Systeme konzipiert. Seit einigen Jahren
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 23
2. Definition von Hochverfügbarkeit
2.6 Verfügbarkeit (engl. Availability)
2.7 Verfügbarkeitsgrade
werden diese Systeme immer häufiger geographisch auf zwei Rechenzentren mit zusätzlicher Redundanz
(z.B. durch synchrone Spiegelung zwischen zwei Storagesystemen) verteilt um für ein Desaster (Stromausfall, Hochwasser, Naturkatastrophen, Terroranschlag etc.) vorzusorgen.
In Anlagen wie Atomkraftwerken und Raumfahrzeugen werden fehlertolerante Systeme benötigt. Diese
Anforderung wird oftmals durch eine dreifache Redundanz auf der Gesamtsystemebene und einem Mehrheitsquorum für die Entscheidungsfindung im Fehlerfall umgesetzt, d.h. dass das Ergebnis der Mehrheit der
Systeme als Gesamtergebnis herangezogen wird.
Abbildung 4
Verfügbarkeitsgrade
23
05Referenzarchitektur
2.8
04.04.2005
12:25 Uhr
Seite 24
hochverfügbarkeit
Als Voraussetzung für eine hohe Verfügbarkeit (siehe Abbildung 5) wird jede einzelne Komponente der Architektur so ausgelegt, dass im Fall eines einzelnen Fehlers eine andere, gleichwertige Komponente die ausgefallene
Komponente in möglichst kurzer Zeit ersetzt (kein Single Point of Failure: SPOF).
Diese Definition beeinflusst viele Entscheidungen in Bezug auf die Festlegung der Architektur, der Technologie,
der Topologie und der Auswahl der einzelnen Komponenten.
Darüber hinaus beeinflussen die Regeln 2 und 3 aus Abbildung 5 insbesondere die Festlegungen an den Schnittstellen der Architektur (elektrischer Strom, Kühlung, Internet, Betriebsführung, Systemmanagement).
Abbildung 5
Voraussetzungen
für Hochverfügbarkeit
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 25
2. Definition von Hochverfügbarkeit
2.8 Hochverfügbarkeit
Wie kann Redundanz (gemäß Regel 1) erreicht werden?
Eine Komponente wird redundant ausgelegt, indem Komponenten gruppiert werden. Folgende drei Hauptarten
solcher Gruppen können die in Abbildung 5 definierten Voraussetzungen erfüllen:
1. Hochverfügbarkeitspaar (primäre und sekundäre Komponente oder so genannte Peers)
Bestimmte Produkte haben die eingebaute Funktionalität, als redundante Paare verwendet werden zu können.
Dies entweder im Sinne einer (primären) Hauptkomponente und einer sekundären Komponente ohne Last, die
im Fehlerfall die Arbeit übernimmt, oder im Sinne zweier parallel unter Teillast arbeitender Komponenten
(Peers).
2. Rechnercluster
„Ein Rechner-Cluster ist eine Gruppe von Computern, die zu einem Verbundsystem zusammengeschlossen
sind und die gemeinsam genutzt werden, um eine Aufgabe zu bewältigen. Im engeren Sinne spricht man dann
von einem Rechnercluster, wenn in einem solchen Verbundsystem alle Rechner ausschließlich für diese Aufgabe zur Verfügung stehen, ihre Einzelaufgaben zugeteilt bekommen und auf einen gemeinsamen Datenbestand zugreifen.
Im Cluster arbeiten die Rechner (Nodes) im Prinzip parallel an gleichartigen Aufgaben, die auf sie verteilt werden. … Das Zusammenwirken der Nodes führt zu hoher Ausfallsicherheit: Tritt in einem Node eine Störung
auf, können die anderen Nodes seine Aufgaben mit übernehmen.“ [Broc02]
3. Thread-Pool
Wenn die Komponenten einer Gruppe Threads eines Software-Prozesses sind, so spricht man von einem
Thread-Pool. Ein Thread-Pool benötigt eine dedizierte Instanz zur Verteilung der Aufgaben und zur Einhaltung
von Regel 2 und Regel 3 der Voraussetzungen. Diese Instanz kann auch die Anzahl der Threads an die aktuelle
Last anpassen.
Nach der Höhe der Verfügbarkeit werden Hochverfügbarkeitsklassen (siehe Abbildung 6) unterschieden.
25
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 26
Abbildung 6
Hochverfügbarkeitsklassen
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 27
2. Definition von Hochverfügbarkeit
2.8 Hochverfügbarkeit
Zusammenfassung
Abbildung 7
Zusammenfassung
Verfügbarkeit
27
05Referenzarchitektur
04.04.2005
3
12:25 Uhr
Seite 28
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 29
die fabasoft referenz3 architektur 5.0 im überblick
Die Fabasoft Produktfamilie (Fabasoft eCRM-Suite, Fabasoft eGov-Suite, Fabasoft eGov-Forms,
Fabasoft Zustellung etc.) ist – in Ergänzung zu einer Microsoft Windows basierten Client-/ServerArchitektur – als verteilte Webanwendung implementiert. Die Kommunikation mit den Diensten
erfolgt einerseits interaktiv im Wege einer grafischen Benutzeroberfläche, wobei für die Darstellung ein Webbrowser-Client genutzt wird, und andererseits programmatisch über Web-Services
(SOAP-Aufrufe insbesondere zur Integration von Fachanwendungen).
Für die Interaktion mit dem Anwender wird eine grafische Benutzeroberfläche (Thin-Client) auf Basis von HTML
und JavaScript zur Verfügung gestellt Die Funktionalität der Fabasoft Softwareprodukte kann somit im Wege
eines marktüblichen Standard-Webbrowsers (z.B. Microsoft Internet Explorer) genutzt werden.
Für Anwendungen, die mit der Betriebssystem-Umgebung des Arbeitsplatzes interagieren, stehen Controls zur
Verfügung. Das betrifft z.B.
die Integration von Bearbeitungswerkzeugen, wie etwa Microsoft Office-Anwendungen,
das Ausführen einer digitalen Signatur oder
die Nutzung von COM-Add-ins für eingebundene Schaltflächen beispielsweise in Microsoft Outlook oder
Microsoft Word.
Die eintreffenden Benutzeranfragen werden vom Microsoft Internet Information Service an das Fabasoft
Components Webservice (Thread-Pool des Web-Tiers der verteilten Anwendung, ISAPI-Erweiterung des
Microsoft Internet Information Service) weitergereicht. Die verteilte Anwendung implementiert im Fabasoft
Components Webservice die Verarbeitungslogik (Business Logic) und generiert die Darstellung (HTML für den
Webbrowser-Client).
Durch den Fabasoft Components Kernel wird im Fabasoft Components Webservice das Objektmodell zur Verfügung gestellt, die Objektplatzierung und der Zugriffsschutz festgelegt bzw. überprüft, Eigenschaften werden
zwischengespeichert, Methodenaufrufe zugeteilt und Transaktionen ausgeführt.
29
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 30
Das Fabasoft Components Webservice verarbeitet die Benutzeranfrage durch den Zugriff auf die von den
Backendservices verwalteten Daten. Die Kommunikation zwischen Fabasoft Components Webservices und
Backendservices erfolgt über ein internes Kommunikationsprotokoll auf TCP/IP-Basis.
Die Fabasoft Components Backendservices (Fabasoft Components COO-Services und Fabasoft
Components MMC-Services) werden für den Zugriff auf und die Speicherung von Daten in den Fabasoft
Components Stores verwendet (siehe Abbildung 8).
Fabasoft Components Stores sind logische Datenspeicher, die Geschäftsobjekte in einem relationalen Datenbanksystem (des Datenbankserver-Clusters) und im Dateisystem (des Backendserver-Clusters) speichern.
Durch die Fabasoft Components Konvertierungsservices wird die Konvertierung von Inhalten ermöglicht.
Konvertierungsanfragen werden von den Fabasoft Components Webservices zu den Fabasoft Components
Konvertierungsservices weitergeleitet. Es erfolgt keine direkte Kommunikation mit dem Webbrowser-Client.
Eine Fabasoft Components Domäne besteht aus den logisch zusammengehörigen Fabasoft Components
Webservices, den Fabasoft Components Konvertierungsservices, den Fabasoft Components Backendservices,
den Fabasoft Components AT-Services, den Fabasoft iArchive-Services und den Fabasoft Components
Anwendungsintegrationsservices (beispielsweise Fabasoft iArchiveLink-Services als ArchiveLinkSchnittstelle für SAP/R3). Jede Fabasoft Components Domäne ist über eine weltweit eindeutige Domänenidentifikation (Domain-ID) gekennzeichnet.
Die Zustandsänderungen in Geschäftsobjekten werden als Transaktionen abgearbeitet (siehe Abbildung 9). Im
Zuge dieser Transaktionen können sowohl Daten in den Datenbanken der Fabasoft Components COO-Services
als auch Inhalte in den Dateisystemen der Fabasoft Components MMC-Services transaktional verändert werden.
Dafür werden die MMC-Logged-Areas der Fabasoft Components MMC-Services eingesetzt, welche auch die
Basis für ein Point-in-Time-Recovery bilden (siehe Kapitel „Datensicherheit: Online-Backup, Recovery“ auf
Seite 127).
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 31
3. Die Fabasoft Referenzarchitektur
5.0 im Überblick
Abbildung 8
Fabasoft Components
Softwarearchitektur
Abbildung 9
Fabasoft Components
Transaktionen
31
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 32
Sind in einer Transaktion Änderungen in unterschiedlichen Fabasoft Components COO-Services erforderlich,
wird die Transaktion als verteilte Transaktion abgewickelt. Diese verteilten Transaktionen werden vom Fabasoft
Components Kernel als Teil der Fabasoft Components Webservices unter Verwendung des Microsoft Distributed
Transaction Coordinators (MSDTC) überwacht und können im Fehlerfall vom Fabasoft Components Kernel unter
bestimmten Bedingungen auch wiederholt werden (siehe Abbildung 10).
Die Fabasoft Referenzarchitektur 5.0 wurde für unternehmenskritische Anwendungen im Sinne der Erreichung
eines hochverfügbaren Gesamtsystems konzipiert.
Die Subsysteme können auch geographisch auf zwei Rechenzentren mit zusätzlicher Redundanz (z.B. durch synchrone Spiegelung zwischen zwei Storagesystemen) verteilt werden, um für einen Desasterfall (Stromausfall,
Hochwasser, Naturkatastrophen, Terroranschlag etc.) vorzusorgen. Dies ist allerdings mit höheren Kosten und
höherer Komplexität verbunden.
Die Grundprinzipien für die Fabasoft Referenzarchitektur 5.0 sind in Abbildung 11 dargestellt.
Für den effizienten und kosteneffektiven Betrieb dieser Softwarearchitektur wurde die Fabasoft Referenzarchitektur 5.0 entworfen. Abbildung 12 gibt einen Überblick über diese Infrastruktur-Architektur für Webanwendungen und Web-Services basierend auf der Fabasoft Components Technologie.
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 33
3. Die Fabasoft Referenzarchitektur
5.0 im Überblick
Abbildung 10
Verteilte Transaktionen mit
Fabasoft Components
Abbildung 11
Ausgewählte
Architektur-Prinzipien für
Hochverfügbarkeit
33
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 34
Abbildung 12
Referenzarchitektur
Ein Gesamtsystem (eine verteilte Webanwendung oder ein Web-Service) basierend auf der Fabasoft Referenzarchitektur 5.0 besteht aus folgenden Subsystemen:
1. Arbeitsplatz (Webbrowser-Client)
Arbeitsplatzrechner mit grafischer Benutzerschnittstelle auf Basis von HTML. Die Darstellung der HTMLInhalte wird von einem Webbrowser übernommen.
2. Arbeitsplatz-LAN (Client-LAN)
Das Arbeitsplatz-LAN verbindet die Arbeitsplätze mit der Client-Firewall.
3. Client-Firewall
Die Client-Firewall soll das Arbeitsplatz-LAN und somit die Arbeitsplätze vor Angriffen aus dem WAN (aus
dem Internet) schützen.
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 35
3. Die Fabasoft Referenzarchitektur
5.0 im Überblick
4. WAN
Netzwerkverbindung (beispielsweise als VPN auf Basis des Internets) zwischen dem Arbeitsplatz-LAN und
dem Anschaltknoten des Rechenzentrums.
5. Anschaltknoten
Der Anschaltknoten ist der Übergabepunkt für die Anwendung und der Messpunkt für den Service-Level.
6. Server-Firewall
Die Server-Firewall soll das Rechenzentrum vor Angriffen aus dem WAN (aus dem Internet) schützen.
7. Lastverteiler (Load-Balancer, Content-Switch)
Der Lastverteiler verteilt die eintreffenden Anfragen der Benutzer auf die Webserver-Farm und damit auf die
Fabasoft Components Webservices.
8. Frontend-LAN
Das Frontend-LAN verbindet den Lastverteiler mit der Webserver-Farm.
9. Webserver-Farm
Die Webserver-Farm besteht aus jenen Servern, auf welchen die Fabasoft Components Webservices (Verarbeitungslogik der Anwendung und Generierung der Darstellung) ablaufen.
10. Backend-LAN
Das Backend-LAN verbindet die Webserver mit den Backendserver-Clustern und den Konvertierungsservern
sowie die Backendserver-Cluster mit den Datenbankserver-Clustern. Darüber hinaus verbindet das BackendLAN auch die Server für die Basisdienste mit den anderen Servern.
11. Konvertierungsserver-Farm (Conversionserver-Farm)
Die Konvertierungsserver-Farm besteht aus jenen Servern, auf welchen die Fabasoft Components Konvertierungsservices (Formatkonvertierungen für Dokumente) ablaufen.
12. AT-Server (Automated Tasks)
Am AT-Server laufen die Fabasoft Components AT-Services für die Durchführung automatischer Aufgaben im
Kontext eines Benutzers ohne Benutzerinteraktion ab.
35
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 36
13. Backendserver-Cluster
Der Backendserver-Cluster erledigt die Datenhaltung (Persistenz) für die Geschäftsobjekte im Wege der
Fabasoft Components COO-Services für die strukturierten Daten (in relationalen Datenbanken) und im Wege
der Fabasoft Components MMC-Services für die unstrukturierten Daten (Dokumente, Bilder, Multimediadaten im Dateisystem).
14. Datenbankserver-Cluster
Das auf dem Datenbankserver-Cluster laufende relationale Datenbanksystem (Microsoft SQL Server) speichert die strukturierten Daten in je einer Datenbank für jedes Fabasoft Components COO-Service.
15. Storage Area Network (SAN)
Das SAN verbindet die Backend-Cluster (Speicherung von Dokumenten im Dateisystem) sowie die Datenbank-Cluster (Speicherung der Datenbankdateien) mit dem Storagesystem.
16. Storagesystem
Das (Enterprise) Storagesystem ist ein großer Festplattenspeicher (Kapazität bis in den Terabytes-Bereich).
17. Tape-Library
Die Tape-Library (Bandroboter) verwendet schnelle und zuverlässige Bandlaufwerke für die Datensicherungen.
18. Server für Basisdienste
Domaincontroller
Mailserver
Managementserver
Backupserver
Indexserver
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 37
3. Die Fabasoft Referenzarchitektur
5.0 im Überblick
Die Messung der Qualität der Dienste erfolgt, wenn nicht anders vereinbart, am Anschaltknoten als dem Übergabepunkt für die Dienstleistungen. Die Verfügbarkeiten auf der Seite des Dienstebeziehers (Arbeitsplatz-LAN,
Client-Firewall, WAN) können durch entsprechende Verträge beispielsweise mit dem Internetdiensteanbieter
(Internet Service Provider: ISP) vereinbart werden.
37
05Referenzarchitektur
4
04.04.2005
12:25 Uhr
Seite 38
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 39
technologien für
4 hochverfügbarkeit
Im Kapitel „Definition von Hochverfügbarkeit“ wird die Gruppierung von Komponenten zur Bildung
von Redundanz beschrieben. Im Folgenden sollen konkret verfügbare Technologien für Rechnercluster (Server-Farmen mit Hardware-Lastverteilern, Microsoft Windows Server 2003 Clustering
Services) und Technologien für hochverfügbare Server auf Basis von Paarbildungen (z.B. redundante Netzteile) vorgestellt und beschrieben werden.
Die Gruppierung von Komponenten und die hier vorgestellten Technologien für Hochverfügbarkeit werden, wie
im Folgekapitel beschrieben, in der Fabasoft Referenzarchitektur auf jeder Subsystemebene gezielt eingesetzt.
4.1
lastverteiler (load-balancer, content-switch)
Der Lastverteiler stellt eine virtuelle IP-Adresse zur Verfügung und verteilt die eintreffenden Anfragen der Benutzer auf die Webserver-Farm, konkret auf die einzelnen Fabasoft Components Webservices. Aus PerformanceGründen ist unbedingt anzuraten, auf softwarebasierte Lastverteilung zu verzichten und stattdessen HardwareLastverteiler (beispielsweise Cisco Catalyst 6500 mit Content Switch Module) einzusetzen.
Der Lastverteiler muss folgende Aufgaben erfüllen:
Verteilungsalgorithmen (Load Balancing Policies)
Für die Skalierbarkeit der Webserver und für ausgewogene Antwortzeiten müssen neue Sitzungen (Sessions) so auf die Fabasoft Components Webservices verteilt werden, dass alle Fabasoft Components Webservices möglichst gleich belastet werden. Kommt es im Laufe des Tages durch wechselnde Arbeitsaktivität
sowie durch An- und Abmeldungen zu starken Ungleichgewichten, sind auch einzelne bereits zugeordnete
Sitzungen nach längerer Inaktivität auf einen geringer belasteten Server umzusiedeln. Die Verteilung erfolgt
in der Regel auf Basis von TCP-Sessions. D.h. der Lastverteiler ordnet die TCP-Session beim Eintreffen der
ersten Benutzeranfrage einem Webserver zu, der dann für diese TCP-Session gleich bleibt.
Sitzungsaffinität (Session Affinity, Persistence Policies)
Webbrowser beenden nach kurzer Inaktivität des Benutzers die offenen TCP-Sessions und bauen diese bei
weiteren Anfragen wieder neu auf. Aufeinander folgende Anfragen derselben Sitzung eines Benutzers (nicht
39
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 40
mit TCP-Session zu verwechseln) sollten jedoch demselben Fabasoft Components Webservice zugeteilt werden. Die Fabasoft Components Webservices erlauben zwar den Wechsel des Fabasoft Components Webservice sogar innerhalb einer Transaktion, der zeitliche Mehraufwand für einen solchen Wechsel ist aber erheblich, da die für die laufende Transaktion benötigten Daten zuerst vom neu zugeteilten Fabasoft Components
Webservice in den Cache geladen werden müssen.
Hohe Verfügbarkeit der Fabasoft Components Webservices und Unterstützung verschiedener Fehlerstrategien (Server Failure Policies)
Der Lastverteiler muss alle Fabasoft Components Webservices laufend überwachen. Fehlerstrategien werden aktiv, wenn eines der Fabasoft Components Webservice in der Webserver-Farm keine – oder eine ungültige – Antwort auf eine Testanfrage (Health-Check-Probe) liefert. Die Fehlerstrategien legen fest, was mit
aktiven Verbindungen auf dem ausgefallenen Fabasoft Components Webservice passiert. Fällt ein Fabasoft
Components Webservice aus, müssen die darauf befindlichen Sitzungen auf andere Fabasoft Components
Webservices verteilt werden. Dem fehlerhaften Fabasoft Components Webservice dürfen keine neuen Sitzungen zugeteilt werden. Ist das Fabasoft Components Webservice wieder verfügbar, soll dieses automatisch wieder Anfragen erhalten.
Hohe Verfügbarkeit des Lastverteilers
Dedizierte Hardware-Lastverteiler (z.B. Cisco 6500 Series mit Content Switch Module) können als ein Hochverfügbarkeitspaar (primärer und sekundärer Lastverteiler) konfiguriert werden.
Dedizierte Hardware-Lastverteiler unterstützen sowohl unterschiedliche Verteilungsalgorithmen als auch mehrere Formen der Affinität.
Verteilungsalgorithmen (Load Balancing Policies)
Trifft eine Anfrage von einer neu gestarteten TCP-Session am Lastverteiler ein, wird diese je nach aktueller Last
einem Fabasoft Components Webservice zugeteilt. Das dafür zu verwendende Verfahren kann am Lastverteiler
konfiguriert werden. Da die Verteilung bei der ersten Anfrage einer TCP-Session passiert, wird in weiterer
Folge nur mehr von Anfrage gesprochen.
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 41
4. Technologien für Hochverfügbarkeit
4.1 Lastverteiler (Load-Balancer, Content-Switch)
Round-Robin
Der Lastverteiler speichert eine Liste mit allen konfigurierten Fabasoft Components Webservices. Die erste eingehende Benutzeranfrage wird dem ersten konfigurierten und lauffähigen Fabasoft Components Webservice in
dieser Liste zugeteilt. Die Liste wird für alle weiteren Benutzeranfragen der Reihe nach durchgegangen und
jeweils eine Benutzeranfrage auf ein Fabasoft Components Webservice verteilt.
Weighted-Round-Robin
Der Verteilungsalgorithmus Weighted-Round-Robin funktioniert wie Round-Robin. Zusätzlich können jedem
Fabasoft Components Webservice Gewichtungen zugeordnet werden. Aufgrund der Gewichtungen kommt ein
Fabasoft Components Webservice in der vom Lastverteiler erstellten Liste öfter vor als andere Fabasoft Components Webservices. Diese Gewichtung kann beispielsweise im Falle der Verwendung von Webservern unterschiedlicher Leistungsklassen eingesetzt werden.
Least-Connections
Der Lastverteiler speichert eine Liste mit allen konfigurierten Fabasoft Components Webservices. Die eingehenden Benutzerverbindungen werden gleichmäßig auf alle Fabasoft Components Webservices aufgeteilt.
Weighted-Least-Connections
Der Verteilungsalgorithmus Weighted-Least-Connections funktioniert wie Least-Connections. Zusätzlich können
jedem Fabasoft Components Webservice Gewichtungen zugeordnet werden. Aufgrund der Gewichtungen werden einem Fabasoft Components Webservice mit höherer Gewichtung mehr Benutzerverbindungen zugeordnet
als einem Fabasoft Components Webservice mit geringerer Gewichtung. Auch hier kann diese Gewichtung beispielsweise im Falle der Verwendung von Webservern unterschiedlicher Leistungsklassen eingesetzt werden.
Predictive-Hash
Der Lastverteiler erzeugt über einen bestimmten Schlüsselwert einen Hash-Wert und verteilt die Benutzeranfra-
41
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 42
gen aufgrund des erzeugten Hash-Wertes auf die einzelnen Fabasoft Components Webservices. Mögliche
Schlüsselwerte sind Teile bzw. der gesamte HTTP-URL (URL-Hashing) oder die Quell- bzw. Ziel-IP-Adresse (Source and/or Destination IP Hash) der Benutzeranfrage.
Sitzungsaffinität (Session Affinity)
Eine reine Reihum- oder Gleichverteilungs-Zuteilung (z.B. Round-Robin oder Least-Connections) der Benutzeranfragen ist nicht ausreichend. Die – insbesondere aus Gründen der geringeren Antwortzeiten sinnvolle – Zuordnung von aufeinander folgenden Anfragen derselben Benutzersitzung (Session) zum selben Fabasoft Components Webservice (Affinität) kann mittels folgender Technologien sichergestellt werden:
Affinität mittels Cookies
Die Verwendung von Cookies setzt voraus, dass Cookies auf den Arbeitsplätzen erlaubt sind und nicht von eventuell vorhandenen Proxyservern gefiltert werden.
Je nach verwendetem Lastverteiler und Konfiguration der Fabasoft Components Webservices wird im Falle einer
neuen Anfrage (Request) entweder vom Lastverteiler selbst oder von den Fabasoft Components Webservices ein
Cookie in die Antwort des Fabasoft Components Webservice (Response) eingefügt, dessen Wert das Fabasoft
Components Webservice eindeutig identifiziert. Soll dieses Cookie vom Fabasoft Components Webservice eingefügt werden, so muss das in der Fabasoft Components Domäne konfiguriert werden (im Konfigurationsobjekt
Virtual Application Default-Konfiguration in der Eigenschaft CS-Cookie). Dabei wird üblicherweise die IPAdresse des Fabasoft Components Webservice als Wert des Cookies gesetzt. Optional kann eine Lebensdauer
des Cookies in Minuten angegeben werden.
Der Lastverteiler speichert in einer internen Tabelle die Zuordnung der Fabasoft Components Webservices zu
den entsprechenden Cookie-Werten. Der Webbrowser schickt das Cookie bei jeder weiteren Anfrage der Session mit. Der Lastverteiler sucht den Cookie-Wert einer einlangenden Anfrage in seiner Tabelle und schickt die
Anfrage zu jenem Fabasoft Components Webservice, das zu diesem Cookie-Wert gehört.
Kommt ein Cookie für einen definierbaren Zeitraum (z.B. zwei Stunden) in keiner Anfrage vor, wird die Zuordnung
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 43
4. Technologien für Hochverfügbarkeit
4.1 Lastverteiler (Load-Balancer, Content-Switch)
aus der Tabelle des Lastverteilers gelöscht, da die dazugehörige Session entweder beendet wurde oder inaktiv
ist. Ebenso werden alle Einträge eines nicht mehr verfügbaren Fabasoft Components Webservice aus der Tabelle entfernt.
Die Lebenszeit des Cookies am Arbeitsplatz läuft nach einigen Stunden ab. Die nächste Anfrage nach dem
Ablauf des Cookies wird ohne Cookie verschickt. Dadurch wird diese Anfrage entsprechend der aktuellen Lastsituation neu verteilt.
Bei der Verwendung von Affinität mittels Cookies muss ein Layer-7-Lastverteiler verwendet werden, da der
Inhalt der Benutzeranfragen (HTTP-Anfragen) analysiert werden muss. Die Lastverteilung basiert auf dem HTTPProtokoll (ISO-OSI Layer-7), das vom Lastverteiler interpretiert wird.
Affinität mittels URL-Hashing
Jeder URL einer Anfrage (ausgenommen benutzer- bzw. sessionunabhängige Anfragen, z.B. das Laden statischer
Inhalte) enthält einen Parameter, der einen für den jeweiligen Benutzer eindeutigen Wert enthält. Je nach
Lastverteiler kann dieser Wert entweder wie ein Cookie verwendet werden, oder das zu verwendende Fabasoft
Components Webservice wird mit einem Hashing-Algorithmus bei jedem einzelnen Request direkt
(ohne Speicherung in einer Tabelle) aus dem URL-Parameter berechnet. Das heißt, der Hashing-Algorithmus
des Lastverteilers liefert eine eindeutige Zuordnung von Benutzerkennwerten zu Fabasoft Components
Webservices.
Diese Hash-Zuordnung ist typischerweise in etwa gleich verteilt, liefert aber deutlich schlechtere Ergebnisse als
beispielsweise eine lastabhängige Zuordnung nach dem Least-Connections-Prinzip. Weiters ist zu beachten,
dass benutzer- bzw. sessionunabhängige Anfragen von diesem Verfahren nicht erfasst werden und alle derartigen Anfragen entweder einem einzigen Fabasoft Components Webservice zugeordnet werden (Achtung: Überlast) oder mit einem anderen Verfahren (ohne Affinität) verteilt werden müssen.
Bei der Verwendung von Affinität mittels URL-Hashing muss ein Layer-7-Lastverteiler verwendet werden, da der
Inhalt der Benutzeranfragen (URL in HTTP-Anfragen) analysiert werden muss.
43
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 44
Affinität mittels IP-Adressen
Die Verwendung von Affinität im Wege von IP-Adressen setzt voraus, dass zwischen den Arbeitsplätzen und dem
Lastverteiler keine Network Address Translation (NAT) erfolgt. Das heißt, jede Anfrage muss über seine Absender-IP-Adresse eindeutig einem Arbeitsplatz bzw. einer Session zugeordnet werden können.
Ähnlich der Affinität mittels Cookies speichert der Lastverteiler für jede IP-Adresse das zuletzt verwendete
Fabasoft Components Webservice. Wird über einen bestimmten Zeitraum keine Anfrage von dieser Adresse
gesendet, wird die Zuordnung gelöscht. Anfragen von Adressen, zu denen keine Zuordnung gespeichert ist, werden entsprechend der aktuellen Last und der für neue Sessions konfigurierten Verteilungsmethode zugeordnet.
Am Lastverteiler sollte ein Zeitraum konfiguriert werden, der bestimmt, wie lange die Zuordnung von IP-Adresse zu Webservice gespeichert werden soll. Dieser Zeitraum sollte nicht mehr als zwei Stunden betragen.
Affinität mittels SSL-Session-ID
In diesem Fall wird die 32-Bit lange Identifikation (SSL-Session-ID) der verschlüsselten Benutzeranfrage als
Schlüsselwert verwendet. Der Lastverteiler speichert in einer internen Tabelle, welches Fabasoft Components
Webservice zu welcher SSL-Session-ID gehört. Ist für eine SSL-Session-ID noch kein Eintrag in der Tabelle vorhanden, wird die eingehende Benutzeranfrage aufgrund des konfigurierten Lastverteilungsalgorithmus auf die
Fabasoft Components Webservices verteilt. Jede weitere Benutzeranfrage mit derselben SSL-Session-ID wird
auf das zugehörige Fabasoft Components Webservice verteilt.
Kommt eine SSL-Session-ID für einen definierbaren Zeitraum (ein bewährter Wert sind zwei Stunden) in keiner
Benutzeranfrage vor, wird die Zuordnung aus der Tabelle des Lastverteilers gelöscht, da die dazugehörige
Sitzung entweder beendet wurde oder inaktiv ist.
Da bei Verwendung von HTTPS mit Terminierung (Entschlüsselung der HTTPS-Anfragen) im Webserver die Entschlüsselung der Benutzeranfrage durch das Microsoft Internet Information Service erfolgt, muss auf den Fabasoft Components Webservices mit deutlich höherer Systembelastung (insbesondere CPU-Belastung) als bei Verwendung von HTTP gerechnet werden. Die Terminierung sollte daher mit dedizierter Hardware (SSL-Beschleuni-
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 45
4. Technologien für Hochverfügbarkeit
4.1 Lastverteiler (Load-Balancer, Content-Switch)
ger) vor dem Lastverteiler erfolgen. Zu beachten ist dabei allerdings, dass in diesem Fall die Konfiguration der
Affinität mittels SSL-Session-IDs unter Umständen nicht mehr möglich ist.
Fehlerstrategien (Server Failure Policies)
Der Lastverteiler prüft regelmäßig die Webserver (ICMP-Probes, z.B. alle 10 Sekunden, „looksalive“) und die
Fabasoft Components Webservices (HTTP-Probes, z.B. alle 30 Sekunden, „isalive“) hinsichtlich deren Verfügbarkeit mit so genannten Health-Check-Probes.
Fehlerstrategien werden aktiv, wenn einer der Webserver oder eines der Fabasoft Components Webservices in
der Webserver-Farm keine – oder eine ungültige – Antwort auf die Health-Check-Probe liefert. Die Fehlerstrategien legen fest, was mit aktiven Verbindungen auf dem ausgefallenen Webserver oder dem ausgefallenen Fabasoft Components Webservice passiert.
Connection-Reset
Beim Ausfall eines Fabasoft Components Webservice wird die HTTP-Verbindung zwischen Webbrowser-Client
und Fabasoft Components Webservice abgebrochen, der Benutzer erhält eine Fehlermeldung und wird beim
Neuaufbau der Verbindung zu einem funktionierenden Fabasoft Components Webservice in der Webserver-Farm
weitergeleitet.
HTTP-Redirect
Beim Ausfall eines Webservers werden die zu diesem Zeitpunkt zu bearbeitenden Benutzeranfragen abgebrochen und auf einen anderen Webserver auf einen statischen URL umgeleitet. Typischerweise ist unter diesem
URL eine HTML-Seite mit einer entsprechenden, für den Benutzer verständlichen Fehlermeldung zu finden.
Connection-Rebalance
Beim Ausfall eines Webservers werden die HTTP-Verbindungen zwischen dem Fabasoft Components Webservice und dem Lastverteiler abgebrochen. Der Lastverteiler verteilt die Verbindung aufgrund der konfigurierten
45
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 46
Load-Balancing-Policy neu auf einen funktionierenden Webserver. Der Benutzer bemerkt diesen Vorgang nicht
und kann wie bisher auf dem neu zugewiesenen Webserver weiterarbeiten.
Sorry-Server
Beim Ausfall eines Webservers wird die HTTP-Verbindung zwischen Webserver und Lastverteiler abgebrochen.
Der Lastverteiler baut eine neue Verbindung zu einem speziell dafür vorgesehenen Webserver auf und leitet die
Benutzeranfragen auf diesen Server um. Der Benutzer bemerkt diesen Vorgang nicht, und kann wie bisher auf
dem so genannten Sorry-Server weiterarbeiten.
Zusammenfassung
Abbildung 13
Beschreibung des
Lastverteilers
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 47
4. Technologien für Hochverfügbarkeit
4.1 Lastverteiler (Load-Balancer, Content-Switch)
Abbildung 14
Verteilungsalgorithmen und
Sitzungsaffinität des
Lastverteilers
Abbildung 15
Verfügbarkeit und
Fehlerstrategien des
Lastverteilers
47
05Referenzarchitektur
4.2
04.04.2005
12:25 Uhr
Seite 48
microsoft windows server 2003 clustering services
Microsoft Windows Server 2003 Clustering Services bieten hohe Verfügbarkeit und Skalierbarkeit für unternehmenskritische Anwendungen wie beispielsweise Datenbanken, Mailsysteme sowie Datei- und Druckdienste.
Sie sind im Lieferumfang von Microsoft Windows Server 2003 Enterprise und Datacenter Edition enthalten.
In einem Servercluster werden mehrere Server (Clusterknoten) miteinander verbunden, um Hochverfügbarkeit
und einfaches Management von Applikationen und Daten im Cluster zu erreichen. Servercluster bieten insbesondere die folgenden grundsätzlichen Vorteile:
Verbesserte Verfügbarkeit
In einem Servercluster bleiben Services und Applikationen auch während einem Hardware- oder Softwarefehler bzw. während Wartungsarbeiten verfügbar.
Erhöhte Skalierbarkeit
Microsoft Windows Server 2003 Enterprise Edition unterstützt Serverkonfigurationen mit bis zu 8 Prozessoren, Microsoft Windows Server 2003 Datacenter Edition unterstützt Serverkonfigurationen mit bis zu 32 Prozessoren.
Verbessertes Management
Das Management von Applikationen erfolgt im gesamten Cluster anstatt auf jedem einzelnen Server.
Architektur der Servercluster – Virtuelle Server
Die clustertauglichen Dienste, welche in einem Cluster installiert und konfiguriert sind, werden nach außen über
jene IP-Adresse, die der Clusterdienst als Adresse des virtuellen Servers veröffentlicht, zugänglich gemacht. Für
die Software-Clients scheint kein Unterschied gegenüber einer Verbindung zu einem Dienst auf einem einzelnen
realen Server (Computer) zu bestehen.
Fällt ein Dienst (Service) aus, so verschiebt das Clusterdienst den gesamten virtuellen Server auf einen anderen
Clusterknoten und ordnet diesem Clusterknoten die IP-Adresse des virtuellen Servers zu. Die Software-Clients
können die – durch den Ausfall unterbrochene – Verbindung wiederherstellen.
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 49
4. Technologien für Hochverfügbarkeit
4.2 Microsoft Windows Server 2003 Clustering Services
Die Microsoft Windows Server 2003 Clustering Services ermöglichen somit eine Hochverfügbarkeit für Dienste,
bieten jedoch kein für den Anwender transparentes Failover der verteilten Anwendung. Wenn die Anwendung
nicht selbst über entsprechende Mechanismen verfügt, gehen die Zustandsinformationen in den Diensten und
in den durch den Ausfall unterbrochenen Sitzungen bei einem Failover verloren.
Clustertaugliche Dienste
Folgende Voraussetzungen muss eine verteilte Anwendung (in den Software-Clients und in den Diensten) erfüllen, damit ein Failover von den Anwendern nicht bemerkt wird:
1. Eine clustertaugliche verteilte Anwendung muss auf dem Protokoll TCP/IP basieren und als Adresse die IPAdresse bzw. den Netzwerknamen des virtuellen Servers verwenden.
2. Ein clustertauglicher Dienst darf keine Zustände verwalten, die im Fall eines Failovers zu Datenverlust oder
Inkonsistenz führen können.
3. Ein clustertauglicher Dienst muss nach einem Failover einen konsistenten Zustand auf Basis der im gemeinsamen Festplattenspeicher abgelegten Daten wiederherstellen können. Es kann dabei zu geringen Datenverlusten kommen (beispielsweise durch ein Rollback einer laufenden Transaktion).
4. Ein clustertauglicher Client muss eine Verbindung zum virtuellen Server, welche durch ein Failover unterbrochen wurde, ohne Fehlermeldung wieder aufsetzen können.
5. Ein clustertauglicher Client muss eine Transaktion, in welcher ein Failover (und daher ein automatisches Rollback) stattgefunden hat, wiederholen können.
6. Ein clustertauglicher Dienst muss über eine Installationsprozedur installiert werden, welche auf die Besonderheiten eines Clusters Rücksicht nimmt (z.B. Regeln für Einträge in der Microsoft Windows-Registry oder die
automatische Verteilung auf alle Clusterknoten).
7. Ein clustertauglicher Dienst implementiert Methoden, die es dem Cluster ermöglichen, den aktuellen Zustand
des Dienstes zu bewerten und entsprechende Maßnahmen zu setzen (Failover)
49
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 50
Clusterressourcen
Servercluster basieren auf einem „Shared Nothing“-Modell, d.h. jeder Server im Cluster verwaltet seine lokalen
Ressourcen. Ressourcen, die dem gesamten Cluster zur Verfügung stehen, z.B. Storagesystem-Volumes, IP-Adressen oder Hostnamen werden zu jedem Zeitpunkt immer nur von einem einzelnen Server im Cluster verwaltet.
Eine Ressource entspricht einem physikalischen Objekt oder einer Instanz eines ablaufenden Programmcodes.
Eine Festplatte, eine IP-Adresse, ein Microsoft Windows-Service oder ein COM-Objekt sind Ressourcen in
diesem Sinne. Aus Sicht der Systemverwaltung können Ressourcen unter Berücksichtung der Abhängigkeiten
getrennt voneinander gestartet und angehalten werden. Jede von ihnen kann separat überwacht werden, um
sicherzustellen, dass die Anwendung noch sauber ausgeführt wird.
Für die Planung der Clusterressourcen sind folgende Festlegungen wesentlich:
Anzahl der benötigten IP-Adressen und Netzwerknamen
Namensschema
Anzahl und Größe des Festplattenspeichers inkl. Platz für weiteres Wachstum
Konfiguration des Storagesystems
Clusterressourcen müssen zu Ressourcengruppen zusammengefasst werden:
Ressourcen mit wechselseitigen Abhängigkeiten müssen in dieselbe Gruppe zusammengefasst werden
Ressourcen gehören jeweils zu genau einer Ressourcengruppe
Ein Failover betrifft immer die gesamte Ressourcengruppe und niemals eine Ressource alleine
Active/Active versus Active/Passive
In einem Active/Active-Clustersystem arbeiten alle Knoten aktiv. Die Ressourcen und die Last werden auf alle
Knoten aufgeteilt. Fällt ein Knoten aus, werden dessen Ressourcen entsprechend der Failover-Richtlinien auf die
noch übrigen Clusterknoten verteilt. Für diese Mehrbelastung bei Ausfall eines Knotens müssen alle Clusterknoten mit ausreichend Reserven an CPU-Leistung, Hauptspeicher, Netzwerkbandbreite usw. ausgestattet sein.
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 51
4. Technologien für Hochverfügbarkeit
4.2 Microsoft Windows Server 2003 Clustering Services
In einem Active/Passive-Clustersystem werden ein oder mehrere Knoten passiv betrieben, diesen Clusterknoten
wird keine Arbeit zugeteilt. Fällt ein aktiver Knoten aus, so übernimmt ein passiver Knoten dessen Ressourcen.
Quorum
Das Quorum ist die Konfigurationsdatenbank des Clusters. Sie enthält die aktuelle Clusterkonfiguraton, z.B.
Clusterknoten, Clusterressourcen oder Clustergruppen. Diese Datenbank wird auf einer Festplatte des Storagesystems gespeichert und steht dem Cluster als herkömmliche Clusterressource zur Verfügung.
Heartbeat
Eine eigene Netzwerkverbindung zwischen den Clusterknoten (Heartbeat) wird für den Transfer von clusterspezifischen Daten, z.B. im Zuge von Verfügbarkeitstests implementiert. Sollte ein Clusterknoten weder über diese
Heartbeat-Verbindung noch über andere mögliche Netzwerkverbindungen erreichbar sein, wird automatisch ein
Failover initiiert.
Failover
Fällt ein Clusterknoten aus, so werden die betroffenen virtuellen Server auf einem anderen Clusterknoten gestartet. Für die Definition, welcher Server bei einem Failover die betroffenen virtuellen Server übernimmt, stehen
Failover-Richtlinien zur Verfügung:
Failover-Paare
Hot-Standby-Server
Failover-Ring
Zufälliges Failover
Angepasstes Failover
51
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 52
Failover-Paare
In dieser Konfiguration werden für jeden virtuellen Server zwei mögliche Clusterknoten definiert, die diesen
betreiben können, z.B.:
APPLIKATION
STANDARDSERVER
FAILOVER-SERVER
APPLIKATION A
Server 1
Server 3
APPLIKATION B
Server 2
Server 4
Tabelle 1: Beispielkonfiguration für Failover-Paare
Hot-Standby-Server
Für die Konsolidierung von Failover-Paaren wird für mehrere virtuelle Server ein zusätzlicher Clusterknoten als
möglicher Betreiber konfiguriert (n+1), z.B.:
APPLIKATION
STANDARDSERVER
FAILOVER-SERVER
APPLIKATION A
Server 1
Server 3
APPLIKATION B
Server 2
Server 3
Tabelle 2: Beispielkonfiguration für Hot-Standby-Server (n+1)
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 53
4. Technologien für Hochverfügbarkeit
4.2 Microsoft Windows Server 2003 Clustering Services
Abhängig von der Konfiguration können anstatt einem Failover-Server mehrere Failover-Server konfiguriert werden (n+i), z.B.:
APPLIKATION
STANDARDSERVER
FAILOVER-SERVER
APPLIKATION A
Server 1
Server 6, Server 7
APPLIKATION B
Server 2
Server 6, Server 7
APPLIKATION C
Server 3
Server 6, Server 7
APPLIKATION D
Server 4
Server 6, Server 7
APPLIKATION E
Server 5
Server 6, Server 7
Tabelle 3: Beispielkonfiguration für Hot-Standby-Server (n+i)
Failover-Ring
Auf allen Clusterknoten werden Applikationen ausgeführt, die Clusterknoten werden dabei zu einem logischen
Ring zusammengeschlossen. Fällt ein Clusterknoten aus, wird die Anwendung auf den nächsten Clusterknoten
im Ring verschoben.
Zufälliges Failover
Fällt ein Clusterknoten aus, werden die betroffenen virtuellen Server zufällig auf andere Clusterknoten verteilt.
Angepasstes Failover
Für virtuelle Server werden die möglichen Clusterknoten spezifisch konfiguriert.
53
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 54
Failback
Sobald der Fehler auf dem bevorzugten Clusterknoten behoben ist, kann der Dienst durch ein (automatisches
oder manuelles) Failback wieder zurück verlagert werden. Ein automatisches Failback kann entweder sofort bei
Verfügbarkeit des bevorzugten Knotens oder zu einer vordefinierten Zeit erfolgen.
Zusammenfassung
Abbildung 16
Microsoft Windows
Server Cluster
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 55
4. Technologien für Hochverfügbarkeit
4.2 Microsoft Windows Server 2003 Clustering Services
Abbildung 17
Microsoft Cluster:
Failover-Richtlinien
55
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 56
Abbildung 18
Ausfall eines Clusterknotens: Failover
Abbildung 18 dokumentiert beispielhaft die Auswirkungen eines Failovers im Cluster auf eine Client-Applikation. Die Anfragen an den Clusterdienst sind kurzfristig nicht durchführbar, werden aber fortgesetzt,
sobald der Clusterdienst wieder verfügbar ist.
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 57
4. Technologien für Hochverfügbarkeit
4.2 Microsoft Windows Server 2003 Clustering Services
4.3 Hochverfügbare Server
4.3
hochverfügbare server
Um einen Server hochverfügbar zu halten müssen die wichtigsten Hardwarekomponenten ausfallsicher ausgelegt sein. Bei einem Ausfall einer Komponente muss eine andere deren Aufgaben übernehmen.
Weiters müssen die Komponenten eines hochverfügbaren Servers so weit als möglich während des laufenden
Betriebes austauschbar sein (Hot Swap).
Insbesondere folgende Hardwarekomponenten eines Servers müssen redundant ausgeführt werden:
Lüfter
Mehrere im laufenden Betrieb austauschbare Lüfter sorgen in einem hochverfügbaren Server für eine adäquate
Kühlung der wichtigsten Komponenten. Sollte ein Lüfter ausfallen, wird die Leistung der anderen Lüfter erhöht,
um die notwendige Kühlung bis zum Tausch des defekten Lüfters aufrecht zu erhalten.
Netzteile
Für einen hochverfügbaren Server müssen mindestens zwei im laufenden Betrieb austauschbare Netzteile mit
eigenen Stromverbindungen (zu unterschiedlichen Stromanbietern) implementiert werden.
Systemplatten
Zwei im laufenden Betrieb austauschbare Festplatten bilden in Kombination mit einem RAID-Controller ein
RAID-1-Array für das Betriebssystem.
Speicher
In einem hochverfügbaren Server unterstützt das Speichersubsystem Redundanzfunktionalitäten, wie z.B. den
Austausch von defekten DIMMs (Hot Swap), die Erweiterung durch neue DIMMs (Hot Add) im laufenden Betrieb
oder die Spiegelung von Speicher (Memory Mirroring). Zusätzliche tägliche automatische Speichertests zur
Erkennung von Fehlern unterstützen bei der Verhinderung von Serverausfällen durch Speicherfehler.
57
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 58
Netzwerkanbindung
In einem hochverfügbaren Server wird die Netzwerkanbindung mit mindestens zwei Netzwerkadaptern pro
LAN-Segment implementiert, wobei das Heartbeat-LAN in einer Clusterkonfiguration die Ausnahme bildet.
Diese Netzwerkadapter werden durch die Verwendung von spezieller Software zu einem virtuellen Netzwerkadapter zusammengefasst (Teaming). Weiters unterstützt diese Software insbesondere die folgenden Funktionalitäten:
Ausfallsicherheit
Bei einem Ausfall eines Netzwerkadapters (Network Interface Card – NIC), einer Netzwerkverbindung (Kabel)
oder des Link-Partners (z.B. Switch) übernimmt automatisch ein anderer Netzwerkadapter die Aufgaben. Durch
dieses Design wird die Verfügbarkeit des Servers am Netzwerk gesichert.
Link-Aggregation
Durch Link-Aggregation werden mehrere Netzwerkadapter zu einer logischen Verbindung kombiniert, um eine
größere Bandbreite zu erreichen.
IEEE 802.3ad definiert den Protokollstandard für Link-Aggregation.
Weitere Bezeichnungen dafür sind „Trunking“, „Channel Bundling“ oder „Teaming“.
Das Link-Aggregation-Protokoll fasst zwei oder mehrere parallele Netzwerkverbindungen zu einer logischen Verbindung zusammen. Dieses Verfahren funktioniert nur bei Vollduplex-Verbindungen mit gleicher Übertragungsrate.
Die Bündelung mehrerer Verbindungen bringt zwei wesentliche Vorteile mit sich:
Geschwindigkeit, Lastverteilung
Die gesendeten Pakete werden auf alle Leitungen aufgeteilt; die Bandbreite wird vervielfacht.
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 59
4. Technologien für Hochverfügbarkeit
4.3 Hochverfügbare Server
Ausfallsicherheit
Fallen eine oder mehrere Leitungen aus, wird auf die verbleibenden Leitungen verteilt. Es ergibt sich eine
redundante Netzwerkanbindung.
Voraussetzungen
Unterstützt werden nur direkte Verbindungen oder Verbindungen über Switches. Hubs werden nicht unterstützt.
Alle verwendeten Switches müssen die Aggregation von Ports unterstützen.
Die Treiber der Netzwerkadapter müssen das Bündeln von mehreren Netzwerkadaptern unterstützen.
Ethernet-Pakete mit gleicher MAC-Adresse werden nicht über mehrere Kanäle eines Aggregates verteilt. Bei
einer Verbindung von Gerät A mit 1 Gbit-NIC zu Gerät B mit 3 x 100 Mbit-NIC erreicht man weiterhin maximal 100 Mbit/s. Link-Aggregation macht somit nur bei Servern oder Switch-Interconnects (Direktverbindungen zwischen Switches) Sinn.
SAN-Anbindung
Die SAN-Anbindung erfolgt durch zwei Host Bus Adapter (HBA), die durch spezielle Software (Multipathing) als
eine logische SAN-Verbindung dargestellt werden. Weiters unterstützt diese Software insbesondere die folgenden Funktionalitäten:
Multipathing
Durch ein hochverfügbares SAN-Design stehen einem Server mehrere mögliche Pfade zum Storagesystem zur
Verfügung. Die Multipathing-Software verwaltet diese Möglichkeiten und bietet dem Server somit eine konsistente Sicht auf das Storagesystem.
59
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 60
Failover-Recovery
Bei Verlust eines Pfades, z.B. durch HBA-Fehler oder Kabelfehler, erfolgt eine automatische Auswahl eines neuen Pfades, ohne Unterbrechung der Applikation.
Load-Balancing
Die Multipathing-Software muss weiters die Funktionalität unterstützen, die Last gleichmäßig über alle möglichen Pfade zu verteilen.
Zusammenfassung
Abbildung 19
Hochverfügbare Server
05Referenzarchitektur
04.04.2005
12:25 Uhr
Seite 61
4. Technologien für Hochverfügbarkeit
4.3 Hochverfügbare Server
61
05Referenzarchitektur
5
04.04.2005
12:25 Uhr
Seite 62
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 63
die subsysteme der faba5 soft referenzarchitektur 5.0
Bei der Festlegung der Fabasoft Referenzarchitektur wurde insbesondere auf die Skalierbarkeit,
Managebarkeit und Verfügbarkeit aller Subsysteme und des Gesamtsystems geachtet.
Die Verfügbarkeit eines Gesamtsystems wird aus den Verfügbarkeiten der parallel und seriell geschalteten Komponenten entlang des Datenpfades – erkennbar im Blockdiagramm des Systems – berechnet.
Die Verfügbarkeit eines Gesamtsystems ist als das Produkt der Verfügbarkeiten der einzelnen seriell geschalteten Subsysteme definiert.
Die Verfügbarkeit der einzelnen Subsysteme wird durch die Parallelschaltung (redundante Gruppierung) hochverfügbarer Komponenten (z.B. hochverfügbarer Server) erhöht.
Beispiel
Verfügbarkeit eines Backendserver-Clusters oder eines Datenbankserver-Clusters. Die MTBF für einen
hochverfügbaren Server wird vom Hardwarehersteller mit etwa 15000 Stunden (für die Hardware) angegeben. Die MTTR wird hier mit 8 Stunden angenommen.
Die Verfügbarkeit eines einzelnen solchen Servers (HW) beträgt: 99,946695 %.
Die Verfügbarkeit eines Clusters (zwei solche Server) beträgt: 99,999972 %. Dies unter der idealisierten
Annahme, dass ein Fehler eines Clusterknotens den anderen Clusterknoten nicht beeinflusst und ohne
Berücksichtigung der Software, welche aber insbesondere in Form der Treiber nach unserer Erfahrung ein
entscheidender Einflussfaktor auf die Verfügbarkeit ist.
In diesem Kapitel werden die einzelnen Subsysteme (insbesondere jene im Rechenzentrum des Diensteanbieters) hinsichtlich deren Teilaufgaben und geeigneter Maßnahmen zur Erhöhung deren Verfügbarkeit (Redundanz)
beschrieben.
63
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 64
Darüber hinaus werden Beispiele für Implementierungen der einzelnen Subsysteme auf Basis jener Hardwareund Softwarekomponenten angeführt, die in den Labors bei Fabasoft für Testzwecke zur Simulation einer Produktionsumgebung herangezogen werden.
Die Beispiele für die Backend-Infrastrukturkomponenten sind so gewählt, dass mit der angeführten Beispielkonfiguration nach Erfahrungswerten etwa 2000 registrierte Benutzer arbeiten können.
Hinsichtlich der technischen Kenndaten zu den einzelnen Beispielen, der Installations- und Gebrauchshinweise
wird auf die Datenblätter und die technische Dokumentation des jeweiligen Herstellers verwiesen.
5.1
arbeitsplatz (webbrowser-client)
Beschreibung
Arbeitsplatzrechner dienen der Kommunikation der Benutzer mit den Fabasoft Webanwendungen unter Verwendung eines Webbrowsers und der Bearbeitung der in der Fabasoft Produktionsumgebung gespeicherten Dokumente mithilfe entsprechender Anwendungssoftware.
Für lokale Client-Anwendungen, die mit der Betriebssystem-Umgebung des Arbeitsplatzes interagieren, stehen
Controls zur Verfügung. Das betrifft z.B.
die Integration von Bearbeitungswerkzeugen am Webbrowser-Client, etwa Microsoft Office-Anwendungen,
das Ausführen einer Digitalen Signatur am Webbrowser-Client,
die Nutzung von COM-Add-ins für eingebundene Schaltflächen in Microsoft Outlook oder Microsoft Word
oder die Einbindung von Arbeitsplatz-Scannern.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 65
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.1 Arbeitsplatz (Webbrowser-Client)
Verfügbarkeit
Die Arbeitsplätze sollten so installiert und konfiguriert werden, dass jeder Anwender jeden Arbeitsplatz benutzen kann. Somit kann der Benutzer bei Ausfall seines Arbeitsplatzes auf einen anderen Webbrowser-Client
wechseln.
Zusammenfassung
Abbildung 20
Subsystem 1: Arbeitsplatz
(Webbrowser-Client)
65
05Referenzarchitektur
5.2
04.04.2005
12:26 Uhr
Seite 66
arbeitsplatz-lan (client-lan)
Beschreibung
Das Arbeitsplatz-LAN verbindet die Arbeitsplatzrechner mit der Client-Firewall.
Je nach Arbeitsprofil der Benutzer muss die Dimensionierung des Arbeitsplatz-LANs individuell vorgenommen
werden. Folgende Faktoren sollten bei der Wahl einer Bandbreite für das Arbeitsplatz-LAN berücksichtigt werden:
Anzahl der Benutzer
Arbeitsprofil der Benutzer (Datenvolumen, gleichzeitige Nutzung etc.)
durchschnittliche Größe von Dokumenten
andere Anwendungen auf demselben LAN (Internet, Intranet, E-Mail, File- und Print-Services usw.)
Die Authentifizierung der Benutzer im Microsoft-Umfeld erfolgt über Microsoft Active Directory. Benutzer müssen sowohl im Arbeitsplatz-LAN (z.B. bei der Anmeldung am Microsoft Windows Arbeitsplatz) als auch im
Backend-LAN (durch die Microsoft Internet Information Serivces bzw. die Fabasoft Components Webservices)
authentifiziert werden.
Bei Verwendung einer übergeordneten Microsoft Windows-Domäne kann zur Authentifizierung Microsoft
Windows-Integrated-Authentication genutzt werden. Die Domaincontroller sind dann jeweils redundant im
Arbeitsplatz-LAN und Backend-LAN verfügbar. Die Details zur Verteilung einer Microsoft Windows-Domäne
über Firewalls hinweg sind im Einzelfall mit Microsoft abzuklären.
Besteht keine übergeordnete Microsoft Windows-Domäne, so sind entweder HTTP-Basic-Authentication, die
Nutzung von Zertifikaten (X.509) oder MOA-ID möglich. Im Fall der Verwendung von X.509-Zertifikaten wird ein
Betriebssystembenutzer mit einem Zertifikat assoziiert. Bei Einsatz von MOA-ID wird über einen MOA-ID-Server
mittels SAML (Security Assertions Markup Language [Oasi04]) authentisiert und über ein SAML-Artefakt
identifiziert. Eine Zuordnung zu einem Betriebssystembenutzer ist nicht erforderlich.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 67
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.2 Arbeitsplatz-LAN (Client-LAN)
Bei Verwendung von Basic-Authentication werden die Benutzerdaten (Benutzername und Passwort) unverschlüsselt (Base64-Kodierung) im Netzwerk übertragen.
Bei der Verwendung von HTTPS oder anderen Verschlüsselungstechnologien wird der gesamte Netzwerkverkehr
verschlüsselt. Die daraus resultierende Prozessormehrbelastung (am Arbeitsplatz sowie entweder am Lastverteiler oder am Webserver je nach Endpunkt für die Verschlüsselung) muss bei der Ressourcenplanung entsprechend berücksichtigt werden.
Im Arbeitsplatz-LAN wird ein DNS-Server (Domain Name System Server) für die Adressierung des Lastverteilers
verwendet. Die virtuelle Adresse des Lastverteilers ist damit über einen Namen ansprechbar.
Bei Verwendung eines Proxyservers oder der Verwendung von NAT stehen die Möglichkeiten der Lastverteilung
und der Affinität auf Basis von IP-Adressen nicht zur Verfügung!
Hochverfügbarkeit
Hochverfügbarkeit beim Netzwerk erreicht man durch:
Zwei Netzwerkanschlüsse je Arbeitsplatz
Redundante Netzwerk-Switches
Bei Domaincontroller wird Hochverfügbarkeit erzielt durch:
Hardware: hochverfügbare Server
Software: Active Directory des Microsoft Windows Server 2003
File- und Print-Server sollten ebenfalls hochverfügbar ausgelegt werden:
Hardware: hochverfügbare Server
Software: Microsoft Windows Server 2003 Clustering Services
67
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 68
Zusammenfassung
Abbildung 21
Subsystem 2:
Arbeitsplatz-LAN
(Client-LAN)
5.3
client-firewall
Beschreibung
Zwischen dem Client-LAN und dem WAN wird eine Firewall zum Schutz des Arbeitsplatz-LANs installiert. Da als
Protokoll zwischen den Arbeitsplätzen und den Webservern ausschließlich HTTP (bzw. HTTPS) verwendet wird,
sollte die Client-Firewall jeden anderen Netzwerkverkehr blockieren (Ausnahme: sowohl im Arbeitsplatz-LAN als
auch im Backend-LAN wird eine übergreifende Microsoft Windows-Domäne genutzt). Zu beachten ist auch, dass
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 69
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.2 Arbeitsplatz-LAN (Client-LAN)
5.3 Client-Firewall
insbesondere für den Zugriff auf Dokumente das auf HTTP basierende WebDAV-Protokoll verwendet wird und
die Client-Firewall diese Erweiterungen zulassen muss.
Hochverfügbarkeit
Die Client-Firewall wird als Hochverfügbarkeitspaar ausgeführt.
Zusammenfassung
Abbildung 22
Subsystem 3:
Client-Firewall
69
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 70
Beispielkonfiguration
Als Client-Firewall wird eine Cisco PIX 515E verwendet. Die Firewall lässt nur HTTP und HTTPS auf die
definierten Webserver-Farmen durch. Über einen Router des ISPs (in der Beispielkonfiguration
192.84.221.200) wird die Verbindung zum Anschaltknoten hergestellt.
PIX Version 6.3(1)
hostname clientfw
domain-name fabasoft.com
interface ethernet0 auto
nameif ethernet0 outside security0
ip address outside 192.84.221.98 255.255.255.0
interface ethernet1 100full
nameif ethernet1 inside security100
ip address inside 172.16.0.1 255.255.0.0
fixup protocol http 80
fixup protocol https 443
names
name 172.30.0.200 webfarm1
name 172.30.0.201 webfarm2
object-group network webfarm
network-object webfarm1 255.255.255.255
network-object webfarm2 255.255.255.255
object-group service web tcp
description HTTP + HTTPS
port-object eq http
port-object eq https
access-list inside_access_in permit tcp any object-group
webfarm object-group web
access-list inside_access_in deny tcp any any
access-list outside_access_in deny tcp any any
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
static (inside,outside) 172.16.0.0 172.16.0.0
netmask 255.255.0.0 0 0
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 71
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.3 Client-Firewall
5.4 WAN
static (outside,inside) 172.20.0.200 172.20.0.200
netmask 255.255.255.255 0 0
static (outside,inside) 172.20.0.201 172.20.0.201
netmask 255.255.255.255 0 0
route inside 0.0.0.0 0.0.0.0 172.16.0.254 1
route outside 172.30.0.0 255.255.0.0 192.84.221.200 1
Quelltext 1: Beispielkonfiguration einer Client-Firewall (Cisco PIX 515E)
5.4
wan
Beschreibung
Das WAN verbindet die Diensteanbieter (Rechenzentren, Service-Provider) mit den Anwendern, konkret die
Client-Firewall mit dem Anschaltknoten.
Die Bandbreite kann je nach verwendeter Netzwerktechnologie in Stufen erhöht werden. Darüber hinaus können Leitungen zu einer virtuellen Leitung zusammengeschaltet werden, wobei sich die Gesamtbandbreite als die
Summe der einzelnen Bandbreiten ergibt.
Die Telekommunikationsgesellschaften bieten definierte Service-Level für ihre Kommunikationslösungen an,
wobei hier der Anbieter das Management der Kommunikationsinfrastruktur übernimmt.
Nichtsdestotrotz muss die WAN-Infrastruktur laufend hinsichtlich Verfügbarkeit und Auslastung (verfügbarer
Bandbreite) überwacht werden.
Hochverfügbarkeit
Diese wird über eine duale Anbindung durch zwei unterschiedliche Anbieter auf Basis unterschiedlicher Technologien und entweder einer automatischen Lastverteilung zwischen diesen Netzwerken oder einer automatischen Umschaltung auf das sekundäre Netzwerk im Fehlerfall erreicht.
71
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 72
Zusammenfassung
Abbildung 23
Subsystem 4: WAN
5.5
anschaltknoten
Beschreibung
Der Anschaltknoten verbindet das WAN mit der Server-Firewall und ist durch seine Positionierung außerhalb der
Server-Firewall im Internet exponiert. Aus Sicherheitsgründen ist die professionelle Installation und laufende
Beobachtung dieser Komponente entsprechend wichtig.
Der Anschaltknoten wird entsprechend seiner Aufgabe als Router ausgeführt.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 73
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.4 WAN
5.5 Anschaltknoten
Hochverfügbarkeit
Der Anschaltknoten wird als Hochverfügbarkeitspaar ausgeführt.
Zusammenfassung
Abbildung 24
Subsystem 5:
Anschaltknoten
Beispielkonfiguration
Als Anschaltknoten wird ein Cisco 1721 Modular Access Router mit zwei Fast-Ethernet-Interfaces verwendet. Der Anschaltknoten verbindet sich über einen Router des ISPs (in der Beispielkonfiguration
192.84.221.100) sowohl ins Internet (zum Versenden von Mails) als auch zur Client-Firewall.
73
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 74
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname serveras
!
boot-start-marker
boot-end-marker
!
no aaa new-model
ip subnet-zero
!
!
ip cef
no scripting tcl init
no scripting tcl encdir
!
!
interface FastEthernet0
ip address 192.168.0.2 255.255.255.0
speed auto
full-duplex
!
interface FastEthernet1
ip address 192.84.221.99 255.255.255.0
no fair-queue
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.84.221.100
ip route 172.20.0.0 255.255.0.0 192.168.0.1
ip route 172.30.0.0 255.255.0.0 192.168.0.1
!
!
no scheduler allocate
!
End
Quelltext 2: Beispielkonfiguration eines Anschaltknotens (Cisco 1721 Modular Access Router)
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 75
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.5 Anschaltknoten
5.6 Server-Firewall
5.6
server-firewall
Beschreibung
Zwischen dem Anschaltknoten, der die Verbindung zum WAN herstellt und den Servernetzwerken wird die Server-Firewall zum Schutz der Servernetzwerke (des Rechenzentrums) installiert. Da als Protokoll zwischen den
Arbeitsplätzen und den Webservern ausschließlich HTTP (bzw. HTTPS) verwendet wird, sollte auch die ServerFirewall jeden anderen Netzwerkverkehr (ausgenommen SMTP falls benötigt) blockieren (Ausnahme: sowohl im
Arbeitsplatz-LAN als auch im Backend-LAN wird eine übergreifende Microsoft Windows-Domäne verwendet).
Hochverfügbarkeit
Die Server-Firewall wird als Hochverfügbarkeitspaar ausgeführt.
75
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 76
Zusammenfassung
Abbildung 25
Subsystem 6:
Server-Firewall
Beispielkonfiguration
Als Server-Firewall wird eine Cisco PIX 515E verwendet. Die Firewall lässt nur HTTP und HTTPS auf die definierten Webserver-Farmen durch. Aus dem Backend-LAN dürfen nur die DNS-Server über Portnummer 53
bzw. die Mailserver via Portnummer 25 in das Internet.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 77
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.6 Server-Firewall
PIX Version 6.3(1)
hostname serverfw
domain-name fabasoft.com
interface ethernet0 auto
nameif ethernet0 outside security0
ip address outside 192.168.0.1 255.255.255.0
interface ethernet1 100full
nameif ethernet1 inside security100
ip address inside 172.20.0.1 255.255.0.0
fixup
fixup
fixup
fixup
protocol
protocol
protocol
protocol
domain 53
http 80
https 443
smtp 25
names
name 172.20.0.50 dnsserver1
name 172.20.0.51 dnsserver2
name 172.20.0.100 mailserver1
name 172.20.0.101 mailserver2
name 172.30.0.200 webfarm1
name 172.30.0.201 webfarm2
object-group network dnsserver
network-object dnsserver1 255.255.255.255
network-object dnsserver2 255.255.255.255
object-group network mailserver
network-object mailserver1 255.255.255.255
network-object mailserver2 255.255.255.255
object-group network webfarm
network-object webfarm1 255.255.255.255
network-object webfarm2 255.255.255.255
object-group service web tcp
description HTTP + HTTPS
port-object eq http
port-object eq https
access-list inside_access_in permit tcp object-group mailserver any eq smtp
access-list inside_access_in permit tcp object-group dnsserver any eq domain
access-list inside_access_in deny tcp any any
access-list outside_access_in permit tcp any object-group
webfarm object-group web
access-list outside_access_in deny tcp any any
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
77
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 78
global (outside) 1 interface
nat (inside) 1 172.20.0.50 255.255.255.255 0 0
nat (inside) 1 172.20.0.51 255.255.255.255 0 0
nat (inside) 1 172.20.0.100 255.255.255.255 0 0
nat (inside) 1 172.20.0.101 255.255.255.255 0 0
static (outside,inside) 172.16.0.0 172.16.0.0 netmask 255.255.0.0 0 0
static (inside,outside) 172.20.0.200 172.20.0.200
netmask 255.255.255.255 0 0
static (inside,outside) 172.20.0.201 172.20.0.201
netmask 255.255.255.255 0 0
route outside 0.0.0.0 0.0.0.0 192.168.0.2 1
route inside 172.20.0.0 255.255.0.0 172.20.0.254
route inside 172.30.0.0 255.255.0.0 172.20.0.254
Quelltext 3: Beispielkonfiguration einer Server-Firewall (Cisco PIX 515E)
5.7
lastverteiler (load-balancer, content-switch)
Beschreibung
Eine gute Skalierbarkeit durch möglichst gleichmäßige Verteilung der Benutzeranfragen auf die Webserver kann
durch Einsatz eines Lastverteilers (Load-Balancer) erreicht werden. In gleicher Weise werden die Konvertierungsanfragen und die E-Mail-Anfragen der Webserver an die Konvertierungsserver bzw. die Mailserver durch
den Einsatz des Lastverteilers verteilt.
Der Lastverteiler stellt eine virtuelle IP-Adresse zur Verfügung und verteilt die eintreffenden Anfragen der Benutzer entsprechend dem konfigurierten Verteilungsalgorithmus und Sitzungsaffinität (z.B. Least-Connections und
Affinität mittels Cookies) auf die Webserver-Farm und die Konvertierungsanfragen der Fabasoft Components
Webservices auf die Konvertierungsserver-Farm.
Um die notwendige Performance (insbesondere auch durch die Affinität) und Stabilität zu erreichen, ist
in der Fabasoft Referenzarchitektur 5.0 ausschließlich eine hardwarebasierte Lösung zur Lastverteilung vorgesehen.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 79
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.6 Server-Firewall
5.7 Lastverteiler (Load-Balancer, Content-Switch)
Der Lastverteiler ist die einzige Komponente einer Fabasoft Produktionsumgebung, die für die Arbeitsplätze netzwerkmäßig sichtbar ist. Der Lastverteiler ist für die Arbeitsplätze wie ein einziges Fabasoft Components Webservice mit einer dedizierten IP-Adresse erreichbar.
Über unterschiedliche Verfahren (z.B. ICMP, HTTP) prüft der Lastverteiler laufend den Status der Services jener
Server-Farmen, auf die er Anfragen zu verteilen hat. Bei Ausfall eines Fabasoft Components Webservice (Konvertierungsservice) erhält genau dieses Fabasoft Components Webservice (Konvertierungsservice) keine neuen
Benutzeranfragen mehr.
Eine reine Reihum- oder Gleichverteilungs-Zuteilung (z.B. „Least Connections“, „Round Robin“) der Benutzeranfragen ist nicht ausreichend. Die – insbesondere aus Gründen der geringeren Antwortzeiten erforderliche –
Zuordnung von aufeinander folgenden Anfragen derselben Benutzersitzung (Session) zum selben Fabasoft Components Webservice wird mittels Affinität der Sitzung sichergestellt.
Hochverfügbarkeit
Zwei Cisco 6500 Content Switch Modules (CSM) können als fehlertolerante Konfiguration (Hochverfügbarkeitspaar) definiert werden. Dabei wird der Verbindungsstatus zu den Benutzersitzungen in Echtzeit auf das passive
CSM (Standby-CSM) repliziert. Im Falle eines Fehlerstatus am aktiven CSM übernimmt dieses Standby-CSM alle
aktiven Verbindungen, ohne dass dies der Anwender bemerkt. Dies ist insbesondere für Transaktionen und verschlüsselte Sitzungen eine wesentliche Funktionalität.
Darüber hinaus können CSM auch geographisch auf bis zu 128 Standorte verteilt eingesetzt werden (Global Server Load Balancing: GSLB).
79
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 80
Zusammenfassung
Abbildung 26
Subsystem 7: Lastverteiler
Beschreibung
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 81
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.7 Lastverteiler (Load-Balancer, Content-Switch)
Abbildung 27
Subsystem 7: Lastverteiler
Hochverfügbarkeit,
Beispielkonfiguration
Beispielkonfiguration
Als Lastverteiler wird ein Cisco Catalyst 6500 mit Content Switch Module (WS-X6066-SLB-APC) verwendet. Dieser Lastverteiler dient weiters (unterteilt in mehrere VLANs) als zentraler Switch für das FrontendLAN und das Backend-LAN.
Am Lastverteiler ist eine (oder mehrere) Webserver-Farm für alle Fabasoft Components Webservices
eingerichtet, die nach dem Verteilungsalgorithmus Least-Connections arbeitet. Neue Anfragen ohne
Benutzerkennung werden dadurch dem Fabasoft Components Webservice mit der geringsten Anzahl
81
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 82
aktiver Sitzungen zugeteilt. Auch für alle Fabasoft Components Konvertierungsservices ist eine WebserverFarm konfiguriert. Bei dieser ist jedoch keine Sitzungsaffinität anzuwenden.
Die Zuordnung von aufeinander folgenden Anfragen derselben Benutzersitzung wird über Cookies sichergestellt. Weiters wird durch den eingesetzten Cisco Catalyst 6500 über unterschiedliche Verfahren ständig
der Status der eingesetzten Webserver (ICMP) und Fabasoft Components Webservices (HTTP) geprüft. Bei
Ausfall eines Fabasoft Components Webservice erhält dieses Fabasoft Components Webservice keine
neuen Benutzeranfragen mehr.
module ContentSwitchingModule 8
! Backend LAN
vlan 101 server
ip address 172.20.0.252 255.255.0.0
alias 172.20.0.253 255.255.0.0
!
! Client LAN
vlan 102 client
ip address 172.30.0.252 255.255.0.0
gateway 172.30.0.254
!
! Frontend LAN
vlan 103 server
ip address 172.21.0.252 255.255.0.0
alias 172.21.0.253 255.255.0.0
!
! Natpool
natpool CLIENTS 172.21.250.1 172.21.250.100 netmask 255.255.0.0
natpool SERVERS 172.20.250.1 172.20.250.100 netmask 255.255.0.0
! PING Probe
probe PING icmp
interval 2
retries 2
receive 2
!
! HTTP Probe
probe WEBTEST http
credentials <username> <password>
request method get url
/fsc/fscasp/content/bin/fscvext.dll?h&stallmsecsmax=5000
expect status 200
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 83
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.7 Lastverteiler (Load-Balancer, Content-Switch)
interval 10
retries 5
failed 10
open 2
receive 15 y
!
! Webserverfarm 1
serverfarm WEBFARM1
nat server
nat client CLIENTS
predictor leastconns
real 172.21.100.1 80
inservice
real 172.21.100.2 80
inservice
real 172.21.100.1 81
inservice
real 172.21.100.2 81
inservice
real 172.21.100.1 82
inservice
real 172.21.100.2 82
inservice
real 172.21.100.1 83
inservice
real 172.21.100.2 83
inservice
probe PING
probe WEBTEST
!
! Webserverfarm 2
serverfarm WEBFARM2
nat server
nat client CLIENTS
predictor leastconns
real 172.21.101.1 80
inservice
real 172.21.101.2 80
inservice
real 172.21.101.1 81
inservice
real 172.21.101.2 81
inservice
real 172.21.101.1 82
inservice
real 172.21.101.2 82
inservice
83
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 84
real 172.21.101.1 83
inservice
real 172.21.101.2 83
inservice
probe PING
probe WEBTEST
!
! Conversionserverfarm 1
serverfarm CONVFARM1
nat server
nat client SERVERS
predictor leastconns
real 172.20.100.11 80
inservice
real 172.20.100.12 80
inservice
real 172.20.100.13 80
inservice
probe PING
probe WEBTEST
!
sticky 10 cookie SERVER timeout 120
!
vserver FSCWEBFARM1
virtual 172.30.0.200 tcp www
serverfarm WEBFARM1
sticky 120 group 10
pending 15
persistent rebalance
parse-length 4000
client 0.0.0.0 0.0.0.0
inservice
!
vserver FSCWEBFARM2
virtual 172.30.0.201 tcp www
serverfarm WEBFARM2
sticky 120 group 10
pending 15
persistent rebalance
parse-length 4000
client 0.0.0.0 0.0.0.0
inservice
!
vserver FSCCONVFARM1
virtual 172.20.0.200 tcp www
serverfarm CONVFARM1
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 85
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.7 Lastverteiler (Load-Balancer, Content-Switch)
5.8 Frontend-LAN
pending 15
no persistent rebalance
client 172.20.0.0 255.255.0.0
inservice
Quelltext 4: Beispielkonfiguration eines Lastverteilers (Cisco Catalyst 6500 Content Switch Module)
5.8
frontend-lan
Beschreibung
Das Frontend-LAN (typischerweise 1 Gbit/s Ethernet) verbindet den Lastverteiler mit der Webserver-Farm. Über
dieses LAN werden nur Benutzeranfragen bzw. die Antworten der Webserver übertragen.
Das Frontend-LAN wird als ein logisch und physikalisch eigenständiges Netz implementiert.
Hochverfügbarkeit
Die Verbindung zwischen dem Lastverteiler und der Webserver-Farm muss hoch verfügbar ausgelegt sein. Es
dürfen maximal einige wenige Webserver gleichzeitig ausfallen.
85
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 86
Zusammenfassung
Abbildung 28
Subsystem 8:
Frontend-LAN
Beispielkonfiguration
Die Cisco Catalyst 6500 Series Supervisor Engine 720 Netzwerkkomponente kann in einer sogenannten
Dual-Supervisor-Konfiguration zum Einsatz kommen. Dadurch wird der Protokollstatus zwischen der
primären und der redundanten Supervisor-Engine laufend abgeglichen. Ein Stateful-Failover ist in weniger
als drei Sekunden möglich. Die redundante Supervisor-Engine kann bei Bedarf im laufenden Betrieb
getauscht werden (hot-swapping of Standby Supervisor Engine).
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 87
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.8 Frontend-LAN
5.9 Webserver-Farm
Die Webserver werden aus Redundanzgründen an möglichst vielen Line-Cards angeschlossen, welche
direkt mit der Supervisor-Engine verbunden sind (Fabric Enabled) [CiSy04i].
5.9
webserver-farm
Beschreibung
Die Webserver-Farm besteht aus der für das gewünschte Antwortzeitverhalten nötigen Anzahl an Webservern.
Bei der Auslegung ist zu beachten, dass der festgelegte Service-Level auch bei einem allfälligen Fehlerstatus
einzelner Webserver noch eingehalten werden kann.
Für unterschiedliche Benutzergruppen sollten jeweils dedizierte Webserver-Farmen definiert werden. Dies gilt
insbesondere auch für die Verwendung von Webservern als Anwendungsintegrationsserver.
Die eintreffenden Benutzeranfragen werden vom Microsoft Internet Information Service an den Thread-Pool des
Fabasoft Components Webservice (Web-Tiers der verteilten Anwendung) weitergereicht. Die verteilte Anwendung implementiert mit dem Fabasoft Components Webservice die Verarbeitungslogik (Business Logic: Fabasoft
Components Kernel) und generiert die Darstellung (HTML für den Webbrowser-Client: VAPPs). Das Fabasoft
Components Webservice verarbeitet die Benutzeranfragen durch den Zugriff auf die von den Backendservern
verwalteten Daten. Die Kommunikation zwischen Fabasoft Components Webservices und Backendservices
erfolgt über ein RPC-Protokoll auf TCP/IP-Basis.
Das Fabasoft Components Webservice mit dem Fabasoft Components Kernel stellt die grundlegende Steuerungslogik dar. Dieses kommuniziert über LAN-Verbindungen mit den Backendservices. Durch den Fabasoft Components Kernel wird das Objektmodell zur Verfügung gestellt, die Objektplatzierung und der Zugriffsschutz festgelegt bzw. überprüft, Eigenschaften werden zwischengespeichert, Methodenaufrufe zugeteilt und Transaktionen ausgeführt.
87
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 88
Performance-Überlegungen
Der Durchsatz der Webserver hängt vor allem von der CPU-Leistung ab, daher werden leistungsfähige Dualprozessor-Systeme in der Bauhöhe 1U („Pizzaboxen“) eingesetzt. Weiters bestimmt die Geschwindigkeit
der Systemplatte den Durchsatz. Es werden daher SCSI-Festplatten mit mindestens 10000 U/min (besser
15000 U/min) verwendet. Aktuell kommen Systeme mit 2 GB Hauptspeicher und 36 GB Festplattengröße zum
Einsatz.
Blade-Systeme ([IBMC04e], [HePa04d]) mit lokalen IDE- oder SATA-Festplatten sind ebenfalls erhältlich und aus
Platzgründen interessant. Zu berücksichtigen sind bei der Verwendung von Blade-Systemen aber insbesondere
die im Vergleich zu SCSI-Festplatten unterschiedliche IO-Performance, das Systemmanagement z.B. des integrierten Netzwerk-Switches sowie der Netzwerkdurchsatz durch die gemeinsame Nutzung der Netzwerkverbindung durch mehrere Blades.
Die Webserver sind sowohl mittels Frontend-LAN mit dem Lastverteiler als auch mittels Backend-LAN mit den
Backendservern und den sonstigen Servern verbunden. Sie benötigen daher zwei Netzwerk-Interfaces
(dual-homed, kein Routing), wobei zumindest das Backend-LAN-Interface ein Gigabit-Ethernet-Interface sein
sollte.
Auf den Webservern sollte die Anzahl der eingesetzten Fabasoft Components Webservices gleich der Anzahl der
logischen Prozessoren sein (2 Prozessoren mit aktiviertem Hyperthreading = 4 logische Prozessoren = 4 Fabasoft
Components Webservices auf einem Webserver).
Als unverbindlicher Erfahrungswert für die Anzahl der Webserver gilt:
Anzahl der registrierten Benutzer / 50.
Aus Gründen der Ausfallsicherheit sollten zumindest zwei Webserver vorgesehen werden. Für 2000 registrierte
Benutzer würde man demnach etwa 40 Webserver einsetzen.
Erhöhte Applikationsanforderungen, Virenscanner und/oder HTTPS mit dem Endpunkt (der Terminierung) im
Microsoft Internet Information Service können zu signifikant anderen Auslegungen (zu einem deutlich höheren
Bedarf an Webservern) führen.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 89
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.9 Webserver-Farm
Hochverfügbarkeit
Da die Fabasoft Components Webservices als Server-Farm durch den Lastverteiler verwaltet werden, sind
einzelne Ausfälle von Fabasoft Components Webservices bzw. Webservern tolerierbar und die Webserver-Hardware muss selbst nicht hochverfügbar ausgelegt werden. Dennoch sollten die Systemplatten der Webserver
über RAID-1 gespiegelt werden.
Der Lastverteiler verteilt die Benutzeranfragen – unter Berücksichtigung der Sitzungsaffinität – mit dem Verteilungsalgorithmus Least-Connections, oder im Fall von Webservern mit unterschiedlicher Hardware über den
Verteilungsalgorithmus Weighted-Least-Connections.
Der Lastverteiler überwacht kontinuierlich die Fabasoft Components Webservices im Hinblick auf deren
Verfügbarkeit. Im Fehlerfall werden die an ein fehlerhaftes Fabasoft Components Webservice adressierten
Anfragen neu innerhalb der verfügbaren Fabasoft Components Webservices verteilt. Wenn der Anwender
diesen Fehler nicht (bzw. nur minimal) bemerken soll, so dürfen durch das Fabasoft Components Webservice
keine Zustände (beispielsweise Transaktionsdaten) (zwischen-)gespeichert werden (Stateless Services).
Die Webserver-Farm muss im laufenden Betrieb um einzelne Webserver erweitert und verringert werden können (dynamische Rekonfiguration des Lastverteilers).
89
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 90
Zusammenfassung
Abbildung 29
Subsystem 9:
Webserver-Farm
Beschreibung,
Hochverfügbarkeit
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 91
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.9 Webserver-Farm
5.10 Backend-LAN
Abbildung 30
Subsystem 9:
Webserver-Farm
Beispielkonfiguration
5.10backend-lan
Beschreibung
Das Backend-LAN verbindet alle Server der Fabasoft Produktionsumgebung untereinander. Als BackendLAN wird ein Gigabit-Ethernet verwendet. Durch die wesentlich schnellere Übertragung umfangreicher
Dokumente können beispielsweise deutlich bessere Antwortzeiten bei Anfragen mit Konvertierungen erreicht
werden.
91
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 92
Innerhalb des Backend-LANs werden Firewalls und andere Sicherheitsmaßnahmen aus Performance-Gründen
üblicherweise nicht eingesetzt. Daher muss das Backend-LAN von allen anderen Netzen isoliert werden.
Hochverfügbarkeit
Die Server werden an eine hochverfügbare Switch-Infrastruktur (Hochverfügbarkeitspaare) angeschlossen.
Zusammenfassung
Abbildung 31
Subsystem 10:
Backend-LAN
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 93
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.10 Backend-LAN
Beispielkonfiguration
Alle Web- und Konvertierungsserver sind einfach mit dem Cisco Catalyst 6500 verbunden (Redundanz durch
den Lastverteiler zusammen mit der jeweiligen Server-Farm).
Alle weiteren Server sind redundant (zwei Kabel an verschiedene Switch-Module) mittels Gigabit-Ethernet
an den Cisco Catalyst 6500 angebunden.
port-channel load-balance src-mac
diagnostic cns publish cisco.cns.device.diag_results
diagnostic cns subscribe cisco.cns.device.diag_commands
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync standard
!
vlan internal allocation policy ascending
!
vlan 101
name backendlan
!
vlan 102
name clientlan
!
vlan 103
name frontendlan
!
! Teaming Interface Backend LAN
interface Port-channel1
no ip address
logging event link-status
ntp disable
switchport
switchport access vlan 101
switchport mode access
!
! Backend LAN Port
interface GigabitEthernet1/1
no ip address
logging event link-status
switchport
switchport access vlan 101
93
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 94
switchport mode access
!
! Frontend LAN Port
interface GigabitEthernet1/2
no ip address
logging event link-status
switchport
switchport access vlan 103
switchport mode access
!
! Client LAN Port
interface GigabitEthernet1/2
no ip address
logging event link-status
switchport
switchport access vlan 102
switchport mode access
!
! Teaming Port 1 Backend LAN
interface GigabitEthernet7/1
no ip address
logging event link-status
switchport
switchport access vlan 101
switchport mode access
no cdp enable
channel-group 1 mode active
!
! Teaming Port 2 Backend LAN
interface GigabitEthernet7/2
no ip address
logging event link-status
switchport
switchport access vlan 101
switchport mode access
no cdp enable
channel-group 1 mode active
!
! Backend LAN
interface Vlan101
ip address 172.20.0.254 255.255.0.0
no ip proxy-arp
!
! Client LAN
interface Vlan102
ip address 172.30.0.254 255.255.0.0
no ip proxy-arp
!
! Frontend LAN
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 95
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.10 Backend-LAN
5.11 Konvertierungsserver-Farm
interface Vlan103
no ip address
no ip proxy-arp
!
! Default Route
ip route 0.0.0.0 0.0.0.0 172.20.0.1 1
Quelltext 5: Beispielkonfiguration des Backend-LANs (Cisco Catalyst 6500)
5.11
konvertierungsserver-farm
Beschreibung
Durch die Fabasoft Konvertierungsservices wird die Konvertierung von Inhalten (z.B. von Microsoft OfficeFormaten in PDF oder HTML) ermöglicht.
Konvertierungsanfragen werden von den Fabasoft Components Webservices zu den Fabasoft Components
Konvertierungsservices weitergeleitet. Es erfolgt keine direkte Kommunikation mit dem WebbrowserClient. Auf einem Konvertierungsserver (Server, auf dem die Fabasoft Components Konvertierungsservices
installiert sind) läuft analog zu den Fabasoft Components Webservices im Kontext der Microsoft
Internet Information Services eine ISAPI-Erweiterung, die die Anfragen verarbeitet und ein Fabasoft
Components Kernel, der mit den Fabasoft Components Backendservices kommuniziert. Als
zusätzliche Software wird Anwendungs- und Konvertierungssoftware (z.B. Microsoft Office,
Adobe Acrobat Distiller) benötigt. Konvertierungsanfragen werden unter Verwendung des HTTP-Protokolls
von den Fabasoft Components Webservices an die Fabasoft Components Konvertierungsservices
übermittelt.
Performance-Überlegungen
Der Durchsatz der Konvertierungsservices hängt vor allem von der CPU-Leistung und den Systemplatten ab,
daher werden leistungsfähige Dualprozessor-Systeme in der Bauhöhe 1U („Pizzaboxen“) und SCSI-Festplatten
95
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 96
mit 15000 U/min eingesetzt. Aktuell kommen Systeme mit 4 GB Hauptspeicher und 36 GB Festplattengröße zum
Einsatz.
Blade-Systeme mit lokalen IDE- oder SATA-Festplatten sind ebenfalls erhältlich und aus Platzgründen interessant. Zu berücksichtigen sind bei der Verwendung von Blade-Systemen aber insbesondere die im Vergleich zu
SCSI-Festplatten unterschiedliche IO-Performance, das Systemmanagement z.B. des integrierten NetzwerkSwitches sowie der Netzwerkdurchsatz in Bezug auf die gemeinsame Nutzung der Netzwerkverbindung durch
mehrere Blades.
Die Konvertierungsserver sind via Backend-LAN sowohl mit dem Lastverteiler als auch mit den Backendservern
und den sonstigen Servern verbunden. Sie benötigen daher lediglich ein Netzwerk-Interface, wobei ein GigabitEthernet-Interface verwendet werden sollte.
Auf den Konvertierungsservern sollte die Anzahl der eingesetzten Fabasoft Components Konvertierungsservices
(Fabasoft Components Kernel-Instanzen) gleich der Anzahl der physischen Prozessoren sein (2 physische Prozessoren mit aktiviertem Hyperthreading = 2 Fabasoft Components Konvertierungsservices auf einem Konvertierungsserver).
Der Bedarf an Konvertierungsservern hängt sehr stark vom Systemnutzungsprofil ab, als unverbindlicher Erfahrungswert kann ein Drittel der Anzahl der Webserver-Hardware angenommen werden. Für 2000 registrierte
Benutzer würde man demnach etwa 14 Konvertierungsserver vorsehen.
Hochverfügbarkeit
Die Fabasoft Components Konvertierungsservices sind wie die Fabasoft Components Webservices als ServerFarm organisiert.
Die Verteilung der Konvertierungsanfragen auf die Fabasoft Components Konvertierungsservices übernimmt der
Lastverteiler. Dieser verteilt die Konvertierungsanfragen entweder über den Verteilungsalgorithmus LeastConnections, oder im Fall von Fabasoft Konvertierungsservern mit unterschiedlicher Hardware über den Verteilungsalgorithmus Weighted-Least-Connections.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 97
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.11 Konvertierungsserver-Farm
Die einzelnen Konvertierungsserver müssen nicht hochverfügbar ausgelegt sein, gespiegelte Systemplatten
(RAID-1) werden allerdings empfohlen.
Der Lastverteiler überwacht kontinuierlich die Fabasoft Components Konvertierungsservices im Hinblick auf
deren Verfügbarkeit. Im Fehlerfall werden die an ein fehlerhaftes Konvertierungsservice adressierten Konvertierungsanfragen neu innerhalb der verfügbaren Konvertierungsservices verteilt.
Die Konvertierungsserver-Farm muss im laufenden Betrieb um einzelne Konvertierungsserver erweitert und verringert werden können (dynamische Rekonfiguration des Lastverteilers).
Zusammenfassung
Abbildung 32
Subsystem 11:
KonvertierungsserverFarm Beschreibung,
Hochverfügbarkeit
97
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 98
Abbildung 33
Subsystem 11:
Konvertierungsserver-Farm
Beispielkonfiguration
5.12
at-server (automated tasks)
Beschreibung
Der AT-Server, auf dem die Fabasoft Components AT-Services installiert werden, wird für die Ausführung zeitgesteuerter, periodischer Vorgänge verwendet. Dieser Server wird je nach Systemgröße und Bedarf ausgestattet.
Ein Fabasoft Components AT-Service arbeitet die Taskliste für einen registrierten Benutzer ab. In der Taskliste
liegen Tasks, die jeweils einen Status und eine Startzeit haben.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 99
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.11 Konvertierungsserver-Farm
5.12 AT-Server (Automated Tasks)
Der AT-Server kann aufgrund von Anwendungsintegrationen (SAP R/3, Fabasoft eGov-Forms) auch eine Verbindung in das Frontend-LAN benötigen.
Hochverfügbarkeit
Mehrere Fabasoft Components AT-Services (auf unterschiedlicher AT-Server Hardware) können die Tasks der
Tasklisten parallel abarbeiten. Der Ausfall eines AT-Servers bzw. eines Fabasoft Components AT-Services führt
zu einer langsameren Abarbeitung der Tasks.
Zusammenfassung
Abbildung 34
Subsystem 12:
AT-Server (Automated
Tasks)
99
05Referenzarchitektur
5.13
04.04.2005
12:26 Uhr
Seite 100
backendserver-cluster
Beschreibung
Die Fabasoft Backendserver speichern Geschäftsobjekte bestehend aus Dokumenten (im Dateisystem) und strukturierten Eigenschaften (in Datenbanksystemen wie z.B. Microsoft SQL Server). Auf diesen Servern werden die
Fabasoft Components Backendservices installiert.
Die Fabasoft Backendserver werden für den Zugriff auf und die Speicherung von Daten in den Fabasoft
Components Stores verwendet. Fabasoft Components Stores sind logische Datenspeicher, die für die
persistente Datenhaltung von Geschäftsobjekten auf den Serversystemen sorgen. Grundsätzlich werden zwei
Arten von Stores unterschieden:
Component Object Store (COO-Store)
speichert die strukturierten Eigenschaften von Objekten, indem ein Metadatenservice (Fabasoft Components
COO-Service) verwendet wird, um die Daten physisch in einer relationalen Datenbank (RDBMS) zu speichern.
Multimedia Content Store (MMC-Store)
speichert Inhalte (Inhaltseigenschaften) von Objekten (Dokumente, Images usw.), indem ein Dokumentenservice (Fabasoft Components MMC-Service) verwendet wird, um die Daten im Dateisystem (NTFS) zu
speichern.
Zur Skalierung kann eine Fabasoft Components Backendservices-Installation in mehrere Metadatenservices
(Fabasoft Components COO-Services) und mehrere Dokumentenservices (Fabasoft Components MMC-Services)
aufgeteilt werden. Jedes Fabasoft Components Backendservice speichert einen Teil der Gesamtdaten und verarbeitet die Zugriffe auf die ihm zugeordneten Daten (Partitionierung auf Ebene der Geschäftsobjekte). Jeder
Backendserver betreibt ein oder mehrere solcher Backendservices. Ein Metadatenservice und das dazugehörige
relationale Datenbanksystem (RDBMS) werden dabei auf gesonderten Servern betrieben. Dadurch können die
Server für die jeweiligen Anforderungen der Backendservices und des RDBMS hin optimiert und unterschiedlich
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 101
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.13 Backendserver-Cluster
konfiguriert werden. Zur Kommunikation mit dem relationalen Datenbanksystem verwenden die Fabasoft Components Backendservices das Protokoll des jeweiligen RDBMS (Tabular Data Stream (TDS) via OLE-DB für den
Microsoft SQL Server).
Hochverfügbarkeit
Würde ein Fabasoft Backendserver ausfallen, wäre ein Zugriff auf die in den Fabasoft Components Backendservices dieses Servers gespeicherten Daten der Geschäftsobjekte nicht mehr möglich. Die Fabasoft Backendserver müssen daher hochverfügbar ausgelegt werden.
Im Rahmen der Fabasoft Referenzarchitektur wird vorausgesetzt, dass die Dokumente und Datenbanken von den
Backendservices auf einem zentralen Storagesystem gespeichert werden und nicht auf lokalen Festplattensubsystemen.
Die Fabasoft Backendserver werden als hochverfügbare Server ausgelegt und in einer Active/Active-Clusterkonfiguration mit mindestens zwei Clusterknoten auf Basis der Microsoft Windows Server 2003 Clustering Services
betrieben. Auf den Knoten eines Backendserver-Clusters laufen verschiedene Fabasoft Components Backendservices.
Performance-Überlegungen
Jeder Clusterknoten wird mit mindestens 16 GB Hauptspeicher bestückt. Bei Ausfall eines Clusterknotens müssen die Backendservices dieses ausgefallenen Clusterknotens auf dem anderen Clusterknoten ohne Speicherengpass übernommen werden können.
Bei der Dimensionierung eines Clusters mit zwei Clusterknoten mit Active/Active-Konfiguration muss beachtet
werden, dass jeder Knoten nur zur Hälfte ausgelastet wird, damit bei einem Failover der Betrieb mit gleicher Performance fortgesetzt werden kann.
Als unverbindlicher Erfahrungswert für die Dimensionierung der Backendserver ist ein Cluster mit zwei Servern
mit je vier physischen Prozessoren pro 2000 registrierten Benutzern vorzusehen.
101
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 102
Diese Auslegung ist signifikant abhängig von der Häufigkeit und vom Umfang der Suchvorgänge sowie der
Transaktionslast und dem Datenvolumen.
Zusammenfassung
Abbildung 35
Subsystem 13:
Backendserver-Cluster
Beschreibung,
Hochverfügbarkeit
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 103
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.13 Backendserver-Cluster
5.14 Datenbankserver-Cluster
Abbildung 36
Subsystem 13:
Backendserver-Cluster
Beispielkonfiguration
5.14
datenbankserver-cluster
Beschreibung
Der Datenbankserver-Custer ist ein dedizierter Cluster (2 Knoten) für die Services des Datenbanksystems, die die
Datenbanken der Fabasoft Components COO-Services betreiben.
Die Services des Datenbanksystems werden in einer Active/Active-Konfiguration (z.B. durch die Verwendung
von zwei Microsoft SQL Server 2000 Instanzen) implementiert. Dadurch wird die Last auf beide Clusterknoten
nach Möglichkeit gleichmäßig verteilt. Bei dieser Active/Active-Konfiguration ist zu berücksichtigen, dass bei
103
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 104
Ausfall eines Clusterknotens der verbleibende Clusterknoten die gesamte Last ohne Performance-Nachteile für
die Anwendung zu bewältigen hat. Insbesondere CPU- und Hauptspeicher-Reserven sind daher ausreichend zu
dimensionieren.
Hochverfügbarkeit
Die Hochverfügbarkeit des Datenbankserver-Clusters wird durch die Implementierung als Failover-Cluster sowie
durch den Einsatz von hochverfügbaren Servern (Clusterknoten), insbesondere durch die redundante Auslegung
und die Möglichkeit des Komponentenwechsels am laufenden System von z.B. Lüftern, Netzteilen und Systemplatte erreicht.
Performance-Überlegungen
Jeder Clusterknoten wird mit mindestens 16 GB Hauptspeicher bestückt. Bei Ausfall eines Clusterknotens müssen die Datenbankservices dieses ausgefallenen Clusterknotens auf dem anderen Clusterknoten ohne Speicherengpass übernommen werden können.
Bei der Dimensionierung eines Clusters mit zwei Clusterknoten mit Active/Active-Konfiguration muss beachtet
werden, dass jeder Knoten nur zur Hälfte ausgelastet wird, damit bei einem Failover der Betrieb mit gleicher Performance fortgesetzt werden kann.
Als unverbindlicher Erfahrungswert für die Dimensionierung der Datenbankserver ist ein Cluster mit zwei 4-Prozessor-Servern pro 2000 registrierten Benutzern vorzusehen. Für den Fall großer Transaktionslast, großem
Datenvolumen oder intensiver Recherchetätigkeiten werden wesentlich mehr Prozessoren benötigt.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 105
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.14 Datenbankserver-Cluster
Zusammenfassung
Abbildung 37
Subsystem 14:
Datenbankserver-Cluster
Beschreibung,
Hochverfügbarkeit
105
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 106
Abbildung 38
Subsystem 14:
Datenbankserver-Cluster
Beispielkonfiguration
5.15
storage area network (san)
Beschreibung
Das Storage Area Network (SAN) ist ein dediziertes Fibre Channel Netzwerk zum Transport von Daten zwischen
den Servern (Backendserver-Cluster, Datenbankserver-Cluster, Backupserver und optional Indexserver) und dem
Storagesystem bzw. der Tape-Library.
Das SAN verbindet die Backendserver-Cluster (Speicherung von Dokumenten im Dateisystem) sowie die Datenbankserver-Cluster (Speicherung der Datenbankdateien) mit dem Storagesystem.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 107
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.14 Datenbankserver-Cluster
5.15 Storage Area Network (SAN)
In einem SAN können Daten ohne Auswirkungen auf die Performance des Frontend-LANs oder Backend-LANs
übertragen werden. Die Anbindung der Server an das SAN erfolgt mit je zwei HBA pro Server.
Hochverfügbarkeit
Die Hochverfügbarkeit wird im SAN insbesondere durch redundante Anbindungen der Systeme und durch das
Design von mehreren möglichen Pfaden von den Servern zu den Storagesystemen erreicht. Bei Verlust eines Pfades erfolgt eine automatische Auswahl eines neuen Pfades ohne Unterbrechung der Applikation.
Performance-Überlegungen
In der Fabasoft Referenzarchitektur wird das SAN mit 2 Gbit/s Verbindungen implementiert. Die HBAs der Server sollen, sofern von der eingesetzten Treibersoftware unterstützt, parallel betrieben werden können (automatische Lastverteilung), insbesondere um Lastspitzen, z.B. bei der Datensicherung, bestmöglich bewältigen zu
können.
107
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 108
Zusammenfassung
Abbildung 39
Subsystem 15:
Storage Area Network
(SAN)
5.16
storagesystem
Beschreibung
Das Storagesystem stellt den Servern (Backendserver-Cluster, Datenbankserver-Cluster und optional Indexserver) Speicherkapazitäten (Plattenspeicher) in Form von Volumes zur Verfügung, insbesondere zur Ablage der
Datenbanken und der Dokumente der Fabasoft Softwareprodukte bzw. zur Ablage der Kataloge der Microsoft
Indexing Services.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 109
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.15 Storage Area Network (SAN)
5.16 Storagesystem
Das Storagesystem speichert Dokumente, Datenbanken, das Clusterquorum und wahlweise auch die Volltextindizes des Indexservers. Das Storagesystem ist über ein SAN mit allen Backendservern, Datenbankservern, dem
Backupserver und eventuell auch mit den Indexservern verbunden. Eine Anbindung der sonstigen Server an das
SAN ist nicht vorgesehen.
Hochverfügbarkeit
Die Hochverfügbarkeit wird im Storagesystem insbesondere durch ein durchgängig redundantes Design – Einsatz mehrerer redundanter Netzteile, Batterie-Backup, global verfügbare Hot-Spare-Platten, spezielle Kühlmechanismen – intensiver proaktiver Überwachung und automatischer Fehlererkennung und Fehlerbehebung
erreicht.
Für Sicherungen bzw. für einen schnellen Wiederanlauf im Problemfall werden vom Storagesystem spezielle
Mechanismen zur Verfügung gestellt, insbesondere die Möglichkeit, Volumes im Storagesystem mehrfach zu
spiegeln und diese Spiegel als eigenständige Volumes zu verwenden. Mit einer auf dieser Basis implementierten Backup/Recovery-Strategie (Split-Mirror: siehe Kapitel „Datensicherheit: Online-Backup, Rcovery“ auf Seite
127) und der Verwendung der entsprechenden Software, insbesondere der Integration mit dem Datenbanksystem, können Sicherungen mit minimalen Auswirkungen auf den Produktionsbetrieb (z.B. durch Synchronisation eines Spiegels im Storagesystem, Trennung des Spiegels, Zuweisung des Spiegels zum Backupserver als
eigenständiges Volume und Sicherung der Daten vom Spiegel auf Band) implementiert werden. Bei einem Wiederanlauf können diese Spiegel, sofern darauf noch verwendbare Daten verfügbar sind, für eine performante
Rücksicherung herangezogen werden, da die Rücksicherung auf die Original-Volumes Storagesystem-intern
erfolgen kann.
Performance-Überlegungen
Die Konfiguration des Storagesystems in Bezug auf Performance ist insbesondere von den zu erwartenden
Datenmengen bzw. Zugriffsprofilen abhängig. Faktoren, die die Performance des Storagesystems beeinflussen,
sind z.B. die Verwendung von schnellen Festplatten (15000 U/min), durchgängige interne und externe 2 Gbit/s
Fibre-Channel-Verbindungen und ein ausreichend dimensionierter Cache.
109
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 110
Für eine gute Performance bei vielen einzelnen Lese- und Schreibzugriffen sind die logischen Volumes auf entsprechend viele physische Laufwerke zu verteilen. Aus diesem Grund sind Storagesysteme mit vielen kleineren
physischen Laufwerken aus Sicht der Antwortzeiten besser als solche mit einer geringen Anzahl sehr großer
physischer Laufwerke.
Empfohlen wird, die ermittelten Größen für die Volumes (insbesondere Volumes für die Transaktionsprotokolle
der Datenbanken) in einer Testinstallation in der Praxis zu validieren. Dabei ist auch auf selten auftretende Operationen zu achten (z.B. Index-Rebuilds auf großen Dabenbanktabellen).
Logische Volumes mit mehr als 100 GB sollten aus Gründen der Systemverwaltung (rasche Wiederherstellung,
Überprüfung der Integrität des Dateisystems etc.) nicht verwendet werden.
Ab Microsoft Windows Server 2003 können Mount-Points verwendet werden, um mehrere Festplattenlaufwerke unter einem Laufwerksbuchstaben ansprechen zu können. Dabei ist allerdings auf Inkompatibilitäten
der eingesetzten Softwareprodukte in Bezug auf Mount-Points zu achten. Es ist vorher sicherzustellen
(gegebenenfalls durch Installation von Service-Packs), dass die Softwareprodukte auf derartige Verzeichnisse
zugreifen können.
Um ein effizientes Backup ohne Betriebsunterbrechung durchführen zu können, muss das Storagesystem die
Möglichkeit von Snapshots bzw. Flash-Copies bieten. Für diese Operationen muss eine Integration in die verwendete Datenbanksoftware verfügbar sein, um ein konsistentes Online-Backup der Datenbank im laufenden
Betrieb zu ermöglichen.
Für ein rasches Recovery wird empfohlen, zumindest den letzten Backupstand aller Volumes als vollwertige,
physisch getrennte Volumes am Storagesystem selbst verfügbar zu halten. Ideal sind zwei physische BackupVolumes mit den letzten beiden Backup-Ständen, die im Wechsel überschrieben werden, sodass selbst bei
Betriebsstörungen während des Kopiervorgangs stets eine unversehrte Kopie vorhanden ist. Der dafür
benötigte Platz ist bei der Dimensionierung des Storagesystems zu berücksichtigen. Von diesen Kopien werden
üblicherweise Sicherungskopien auf Sicherungsbändern erstellt.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 111
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.16 Storagesystem
Zusammenfassung
Abbildung 40
Subsystem 16:
Storagesystem
111
05Referenzarchitektur
5.17
04.04.2005
12:26 Uhr
Seite 112
tape-library
Beschreibung
Die Tape-Library ist ein Bandroboter mit mehreren schnellen und zuverlässigen Bandlaufwerken mit hoher Kapazität zur effizienten Datensicherung.
Hochverfügbarkeit
Redundante Netzteile mit Anbindung an unterschiedliche Stromkreise, eine redundante SAN-Anbindung durch
den Einsatz mehrerer auf unterschiedlichen Wegen angebundener Bandlaufwerke und die Verwendung einer
Backup-Software mit Unterstützung mehrerer Bandlaufwerke (Neuverteilung der Aufgaben bei Ausfall eines
Laufwerks) ergeben eine hohe Verfügbarkeit der Infrastruktur für Datensicherungsläufe.
Performance-Überlegungen
Die Tape-Library muss bei Ausfall eines einzelnen Bandlaufwerkes alle für den Sicherungslauf definierten Daten
in dem dafür vorgesehenen Zeitraum sichern bzw. auch wiederherstellen können.
Verfügbare Ressourcen der Tape-Library müssen dafür mindestens nach dem Prinzip der n+1-Redundanz berechnet werden (Vorkehrung für einen Einzelfehler).
Grundlagen dafür sind:
das zu sichernde Datenvolumen,
die Anzahl und Art (voll, inkrementell, differenziell etc.) der Sicherungsläufe sowie
die Zeitfenster für die Sicherungsläufe.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 113
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.17 Tape-Library
5.18 Server für Basisdienste
Zusammenfassung
Abbildung 41
Subsystem 17:
Tape-Library
5.18
server für basisdienste
Microsoft Windows-Domaincontroller
Beschreibung
Microsoft Windows-Domaincontroller speichern und replizieren Schemainformationen, Konfigurationsinformationen und Anwendungsinformationen.
113
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 114
Auf den Microsoft Active Directory Domaincontrollern sollte zusätzlich ein DNS-Server (Domain Name System)
konfiguriert werden.
Änderungen des Verzeichnisdienstes müssen nicht mehr wie unter Microsoft Windows NT am primären Domaincontroller durchgeführt werden. Statt dessen kann die Änderung auf einem beliebigen Domaincontroller erfolgen. Active Directory repliziert die Änderungen automatisch auf alle anderen Domaincontroller, auch wenn einer
defekt sein sollte.
Hochverfügbarkeit
Microsoft Windows Server 2003 Domaincontroller erreichen durch Replikation eine hohe Verfügbarkeit der Informationen, eine Lastverteilung und damit Vorteile hinsichtlich des Antwortzeitverhaltens. Active Directory nutzt
Multimaster-Replikation.
Durch die Microsoft Active Directory Multimaster-Replikation können Netzwerkverbindungen zwischen Standorten durch gelegentliches Neubewerten von Verbindungen entsprechend deren Bandbreite besser genutzt werden. Die Verwendung unterschiedlicher Routen erhöht darüber hinaus die Verfügbarkeit.
Die Kosten für die Replikation werden minimiert, indem nur Änderungen repliziert werden.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 115
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.18 Server für Basisdienste
Zusammenfassung
Abbildung 42
Subsystem 18a:
Domaincontroller
Mailserver
Beschreibung
Im Wege der Mailserver werden von den Fabasoft Components Webservices generierte E-Mails automatisch
versendet.
Der Mailserver dient auch der Übermittlung von Informationsnachrichten der Systemmanagementsoftware (z.B.
einer Antiviren-Software) an die Betriebsführung.
115
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 116
Hochverfügbarkeit
In der Fabasoft Referenzarchitektur existieren (mindestens zwei) gleich installierte Mailserver. Auf den Mailservern läuft ein SMTP-Service, das die vom Fabasoft Components Webservice gesendeten E-Mails entgegennimmt und an den entsprechenden SMTP-Server der Empfängerdomäne weiterleitet. Je nach Anforderungen
müssen die Mailserver (zum Erreichen der SMTP-Server) und die DNS-Server (zum Auflösen der MX-Records der
entsprechenden Empfängerdomain) einen Internetzugang besitzen.
Die von den Fabasoft Components Webservices versendeten E-Mails werden über den Lastverteiler auf die
Mailserver verteilt. Der Lastverteiler überprüft in periodischen Abständen den Status der Mailserver und schickt
bei Ausfall eines Servers alle E-Mails zum funktionierenden Mailserver.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 117
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.18 Server für Basisdienste
Zusammenfassung
Abbildung 43
Subsystem 18b:
Mailserver
Managementserver
Beschreibung
Der Managementserver dient zur Überwachung aller Subsysteme der Fabasoft Referenzarchitektur 5.0, somit zur
Überwachung aller Hardware- und Softwarekomponenten der Fabasoft Produktionsumgebung und der Infrastruktur-Systemkomponenten.
117
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 118
Der Managementserver wird je nach Systemgröße und Bedarf ausgestattet. Weiters sind die Empfehlungen der
jeweiligen Softwarehersteller zu beachten.
Folgende Aufgaben sollten von den Anwendungen und Werkzeugen, welche auf dem Managementserver eingesetzt werden, übernommen werden:
Überwachung aller Server in der Fabasoft Produktionsumgebung
Dazu werden der Microsoft Operations Manager und der Fabasoft Operations Manager verwendet
Überwachung der Performance-Werte aller Server z.B. unter Verwendung des Microsoft Windows Performance Monitors
Virenschutz mit entsprechender Virenscannersoftware
Auswertung der gesammelten Performance-Werte mithilfe des Fabasoft Operations Managers unter Verwendung eines Data-Warehouses, wie zum Beispiel Microsoft SQL Server Analysis Components
Werkzeuge zur Konfiguration/Überwachung des Lastverteilers
Werkzeuge zur Konfiguration/Überwachung des SANs sowie des eingesetzten Storagesystems
Fabasoft Components Server Management
Weitere Werkzeuge zur Steuerung der Webserver (Stoppen, Starten, …)
Hochverfügbarkeit
Für den Managementserver wird als Hardware ein hochverfügbarer Server verwendet. Bei Bedarf können mehrere Managementserver gleich installiert werden, um mehr Redundanz zu erzielen.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 119
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.18 Server für Basisdienste
Zusammenfassung
Abbildung 44
Subsystem 18c: Managementserver
119
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 120
Abbildung 45
Subsystem 18c:
Data-Warehouse-Server
Backupserver
Beschreibung
Der Backupserver wird zur Steuerung und Durchführung der Datensicherung aller im Storagesystem abgelegten
Daten (unter Verwendung von z.B. Veritas Backup Exec) verwendet. Eine redundante Anbindung an das Storagesystem und die eingesetzte Tape-Library wird empfohlen. Für die Backup-Kataloge der eingesetzten Backup-Software muss entsprechender Speicherplatz vorgesehen werden.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 121
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.18 Server für Basisdienste
Der Backupserver wird je nach Systemgröße und Bedarf ausgestattet. Weiters sind die Empfehlungen des jeweiligen Softwareherstellers zu beachten.
Hochverfügbarkeit
Für den Backupserver wird als Hardware ein hochverfügbarer Server verwendet. Der Backupserver wird redundant an das SAN (somit an das Storagesystem und die eingesetzte Tape-Library) angebunden.
Zusammenfassung
Abbildung 46
Subsystem 18d:
Backupserver
121
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 122
Indexserver
Beschreibung
Der Indexserver wird für die Volltextsuche in Dokumenten verwendet. Erforderlich ist die Installation von Software zum Indizieren von Dateisystemen (Microsoft Indexing Services). Der Indexserver wird je nach Systemgröße und Bedarf ausgestattet. Weiters sind die Empfehlungen des jeweiligen Softwareherstellers (Microsoft)
zu beachten.
Hochverfügbarkeit
Je nach Verfügbarkeits- und Geschwindigkeitsanforderung kann der Volltextindex wahlweise auf dem Storagesystem oder einem lokalen Festplattensystem (RAID-1 oder RAID-10) abgelegt werden.
Performance-Überlegungen
Für die Dimensionierung des Indexservers sind die Empfehlungen des Herstellers der Indexing-Software zu
berücksichtigen. Als unverbindlicher Erfahrungswert wird bei den Microsoft Indexing Services häufig ein Drittel
der Größe des Speicherplatzes der Dokumente selbst angenommen. Da die Geschwindigkeitsanforderung an das
Speichersystem relativ hoch ist, sollte dieses möglichst leistungsfähig ausgelegt werden.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 123
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.18 Server für Basisdienste
Zusammenfassung
Abbildung 47
Subsystem 18e:
Indexserver Beschreibung,
Hochverfügbarkeit
123
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 124
Abbildung 48
Subsystem 18e:
Indexserver
Beispielkonfiguration
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 125
5. Die Subsysteme der Fabasoft Referenzarchitektur 5.0
5.18 Server für Basisdienste
125
05Referenzarchitektur
6
04.04.2005
12:26 Uhr
Seite 126
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 127
datensicherheit:
6 online-backup, recovery
Dieses Kapitel stellt ein Szenario für eine konsistente Datensicherung und Wiederherstellung der
Geschäftsobjekte einer Fabasoft Components Domäne der Version 5.0 auf Basis von EMC2 TimeFinder/Integration Modules und Microsoft SQL Server 2000 vor.
Der Fokus liegt auf einer Online-Datensicherung der Fabasoft Components Domäne unter Berücksichtigung der
Konsistenz zwischen mehreren Fabasoft Components Datenbanken (Fabasoft Components COO-Services) und
Dateisystemen (Fabasoft Components MMC-Services).
Auf die Datensicherung und die Wiederherstellung der für die Fabasoft Components Domäne nötigen Infrastruktur, insbesondere der Registry, der Microsoft Windows Server 2003 Clustering Services, der Microsoft SQL Server Systemdatenbanken wie „master“ oder „msdb“ wird hier nicht eingegangen. Ebenso bleiben mögliche andere Sicherungsstrategien wie Microsoft SQL Server Transaktionsprotokoll-Sicherungen und inkrementelle Datensicherungen unberücksichtigt.
Die Beispiele in diesem Kapitel sollen lediglich einen Überblick über die Datensicherung und die Wiederherstellung geben. Die eigentliche Umsetzung muss jedoch projektspezifisch implementiert und getestet
werden.
6.1
voraussetzungen
Die Kenntnis folgender Produkte wird vorausgesetzt:
Fabasoft eGov-Suite 5.0 oder Fabasoft eCRM-Suite 5.0
EMC2 ResourcePak Version 3.2 for Windows
EMC2 Solutions Enabler Version 4.3.x
EMC2 TimeFinder
EMC2 TimeFinder-SQL Server Integration Module
Microsoft SQL Server 2000 Service Pack 3a, Enterprise Edition
127
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 128
Microsoft Windows Server 2003 Clustering Services
Microsoft Windows Server 2003 Enterprise Edition
6.2
datensicherung und wiederherstellung einer fabasoft
components domäne (backup und recovery)
Eine vollständige Datensicherung einer Fabasoft Components Domäne besteht aus einem Backup der Microsoft
Windows Server 2003 Registry, der Fabasoft Components COO-Service-Datenbanken und der Fabasoft Components MMC-Service-Bereiche.
Die Microsoft Windows Server 2003 Registry
Die Microsoft Windows Server 2003 Registry enthält Daten für eine allfällige Wiederherstellung der Definitionen für die Fabasoft Components Backendservices. Die Datensicherung und Wiederherstellung der Registry
selbst wird hier nicht beschrieben.
Die Fabasoft Components COO-Service-Datenbanken
Die Fabasoft Components COO-Services speichern die strukturierten Daten der Geschäftsobjekte in Microsoft
SQL Server Datenbanken. Die Datensicherung und das Wiederherstellen dieser Datenbanken werden in diesem
Kapitel anhand eines Beispiels erläutert.
Die Fabasoft Components MMC-Service-Bereiche
Die Fabasoft Components MMC-Services speichern die Dokumente der Geschäftsobjekte im Dateisystem
(NTFS). Die Datensicherung und das Wiederherstellen dieser Fabasoft Components MMC-Service-Bereiche werden in diesem Kapitel anhand eines Beispiels erläutert.
Konsistenz
In einer Fabasoft Components Domäne übernehmen die Fabasoft Components COO-Services und die Fabasoft
Components MMC-Services die Funktion Geschäftsobjekte zu persistieren.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 129
6. Datensicherheit: Online-Backup, Recovery
6.2 Datensicherung und Wiederherstellung einer Fabasoft
Components Domäne (Backup und Recovery)
Jede Fabasoft Components Domäne besteht aus mehreren Fabasoft Components COO-Services und mehreren
Fabasoft Components MMC-Services. Somit werden Geschäftsobjekte über mehrere Microsoft SQL Server
Datenbanken und mehrere Dateisysteme verteilt gespeichert.
Die Konsistenz dieser verteilten Datenbestände ist eine der Hauptanforderungen an die Datensicherung und die
Wiederherstellung.
Die Microsoft SQL Server Datenbanken
Die Fabasoft Components COO-Services speichern die strukturierten Daten der Geschäftsobjekte in Microsoft
SQL Server Datenbanken. Fabasoft Components nutzt verteilte – vom Microsoft Distributed Transaction
Coordinator (MSDTC) koordinierte – Transaktionen, um die Konsistenz zwischen den Microsoft SQL Server
Datenbanken sicherzustellen (2-Phasen-Commit).
Die Datensicherungs- und Wiederherstellungsprozeduren müssen ebenfalls die Konsistenz zwischen den Datenbanken bewahren.
Der Microsoft SQL Server 2000 implementiert dazu einen Mechanismus mehrere Datenbanken zu einem einheitlichen Zeitpunkt (Point-in-Time) auf einen konsistenten Stand wiederherzustellen. Dazu werden sogenannte
Named-Transactions und Transaktionsmarken verwendet.
Bei Named-Transactions handelt es sich um Transaktionen, die mit einem Namen versehen werden. Bei der Verwendung von Transaktionsmarken wird dieser Name explizit im Microsoft SQL Server 2000 Transaktionsprotokoll vermerkt.
Weiterführende Informationen dazu finden sich in [MiCo04m] (Microsoft SQL Server Books Online, Backup and
Recovery of Related Databases).
Fabasoft Components MMC-Service-Bereiche
Die Fabasoft Components MMC-Services speichern die Dokumente der Geschäftsobjekte im Dateisystem
(NTFS).
129
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 130
Die Voraussetzung für eine konsistente Online-Datensicherung der Dateisysteme zu einem einheitlichen Zeitpunkt (Point-in-Time) mit den Datenbanken einer Fabasoft Components Domäne stellen die Fabasoft Components MMC-Service-Bereiche mit Logging (MMC-Logged-Areas) dar.
Die in solchen MMC-Logged-Areas gespeicherten Dokumente werden im Zuge einer Transaktion weder geändert noch gelöscht, sondern als neue Datei gespeichert und die Referenz in der Datenbank wird bei positivem
Ende der Transaktion (Commit) aktualisiert. Zum Zeitpunkt des Commits muss das Dokument im Dateisystem
bereits vollständig auf die Festplatte geschrieben worden sein.
Somit sind die Fabasoft Components MMC-Logged-Areas innerhalb einer Domäne nicht nur zum letztaktuellen
gemeinsamen Zeitpunkt mit den Fabasoft Components COO-Service-Datenbanken konsistent, sondern auch mit
historischen Ständen (Point-in-Time) der Datenbanken der Fabasoft Components COO-Services konsistent,
solange die MMC-Logged-Areas nicht aufgeräumt wurden.
Demnach ist für eine konsistente Wiederherstellung einer Fabasoft Components Domäne eine Datensicherung
der Dateisysteme der MMC-Logged-Areas zu einem Zeitpunkt nach der konsistenten Datensicherung der Datenbanken und vor dem Aufräumen der MMC-Logged-Areas nötig.
6.3
beispiel
Das folgende Beispiel illustriert eine vollständige Datensicherung und Wiederherstellung der Fabasoft Components COO-Service-Datenbanken und der Fabasoft Components MMC-Service-Bereiche.
Für die Wiederherstellung werden ein laufender Microsoft Windows Server 2003 Cluster, gestartete Microsoft
SQL Server 2000 Instanzen und Fabasoft Components Backendservices, jeweils vollständig und richtig installiert
und konfiguriert, vorausgesetzt.
Die für das Beispiel verwendete Fabasoft Components Domäne besteht aus drei Fabasoft Components COO-Services und drei Fabasoft Components MMC-Services.
Beispielhaft beschrieben werden:
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 131
6. Datensicherheit: Online-Backup, Recovery
6.2 Datensicherung und Wiederherstellung einer Fabasoft
Components Domäne (Backup und Recovery)
6.3 Beispiel
Die konsistente Online-Datensicherung der Fabasoft Components Domäne
Die konsistente Wiederherstellung zu einem Point-in-Time
Das Beispiel bezieht sich lediglich auf die Datenbestände der Fabasoft Components Domäne selbst, nicht jedoch
auf die nötige Infrastruktur.
Beschreibung der Infrastruktur
Dieses Beispiel basiert auf folgender Infrastruktur:
Backupserver
Fabasoft Backendserver-Cluster
Microsoft SQL Server Datenbankserver-Cluster
EMC2 Symmetrix Storagesystem
Alle Komponenten sind am selben SAN angeschlossen.
Der Backupserver
Der Backupserver ist ein Microsoft Windows Server 2003 System, welches die Datensicherungs- und Wiederherstellungsprozeduren steuert. Darüber hinaus speichert der Backupserver die Datenbestände der BCVs
(BCV: Business Continuance Volume) auf Sicherungsbänder.
Der Fabasoft Backendserver-Cluster
Der Fabasoft Backendserver-Cluster basiert auf einem Microsoft Windows Server 2003 Cluster mit zwei Clusterknoten mit den virtuellen Servern FSC1 und FSC2 in einer Active/Active-Konfiguration.
Der virtuelle Server FSC1 ist für die Fabasoft Components COO-Services COOGW1 und COOST1 und die Fabasoft Components MMC-Services MMCGW1 und MMCST1 zuständig.
131
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 132
Der virtuelle Server FSC2 ist für das Fabasoft Components COO-Service COOST2 und das Fabasoft Components
MMC-Service MMCST2 zuständig.
Jedes Fabasoft Components MMC-Service verwendet ein EMC2 Symmetrix STD-Volume zur Speicherung der
Fabasoft Components MMC-Service-Bereiche wie aus Abbildung 49 ersichtlich.
Abbildung 49
Datensicherheit: Fabasoft
Backendserver-Cluster
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 133
6. Datensicherheit: Online-Backup, Recovery
6.3 Beispiel
MMC1:
Fabasoft Components MMC-Service-Bereiche für die Fabasoft Components
MMC-Services MMCGW1 und MMCST1
MMC2:
Fabasoft Components MMC-Service-Bereich für das Fabasoft Components
MMC-Service MMCST2
Tabelle 4: Definition der Volumes für die Fabasoft Components MMC-Service-Bereiche
Für beide STD-Volumes existiert innerhalb der EMC2 Symmetrix je ein BCV-Volume, das für die Datensicherung
dem Backupserver zugewiesen wird. In dieser Konfiguration wird pro STD-Volume/BCV-Volume-Paar eine EMC2
Symmetrix Device Group definiert.
Der Microsoft SQL Server Datenbankserver-Cluster
Der Microsoft SQL Server Datenbankserver-Cluster basiert auf den Microsoft Windows Server 2003 Clustering
Services mit zwei Clusterknoten mit zwei Microsoft SQL Server Instanzen SQL1\INST1 und SQL2\INST2 in einer
Active/Active-Konfiguration.
Die Microsoft SQL Server Instanz SQL1\INST1 ist für die Microsoft SQL Server Datenbanken COOGW1 und
COOST1 der Fabasoft Components COO-Services COOGW1 und COOST1 zuständig.
Die Microsoft SQL Server Instanz SQL2\INST2 ist für die Microsoft SQL Server Datenbank COOST2 des Fabasoft
Components COO-Service COOST2 zuständig.
Jede Microsoft SQL Server Instanz verwendet gesonderte EMC2 Symmetrix STD-Volumes für die Systemdatenbanken, für die Datenbankdateien der Fabasoft Components COO-Service-Datenbanken und für die Transaktionsprotokolle der Fabasoft Components COO-Service-Datenbanken wie aus Abbildung 50 ersichtlich:
133
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 134
Abbildung 50
Datensicherheit:
Microsoft SQL Server
Datenbankserver-Cluster
SQL1 System:
Microsoft SQL Server Systemdateien, master, model und
msdb Datenbankdateien.
SQL1 Data:
Microsoft SQL Server Datenbankdateien für die Fabasoft Components
COO-Service-Datenbanken COOGW1 und COOST1.
SQL1 Log:
Microsoft SQL Server Transaktionsprotokolle für die Fabasoft Components
COO-Service-Datenbanken COOGW1 und COOST1.
SQL1 Backup:
Ziel-Volume für die Microsoft SQL Server Transaktionsprotokoll-Sicherungen der
Fabasoft Components COO-Service-Datenbanken COOGW1 und COOST1.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 135
6. Datensicherheit: Online-Backup, Recovery
6.3 Beispiel
SQL2 System:
Microsoft SQL Server Systemdateien, master, model und
msdb Datenbankdateien.
SQL2 Data:
Microsoft SQL Server Datenbankdateien für die Fabasoft Components
COO-Service Datenbank COOST2.
SQL2 Log:
Microsoft SQL Server Transaktionsprotokolle für die Fabasoft
Components COO-Service Datenbank COOST2.
SQL2 Backup:
Ziel-Volume für die Microsoft SQL Server Transaktionsprotokoll-Sicherungen der
Fabasoft Components COO-Service Datenbank COOST2
Tabelle 5: Definition der Volumes für die Microsoft SQL Server Datenbanken
Für die STD-Volumes SQL1 Data, SQL1 Log, SQL1 Backup, SQL2 Data, SQL2 Log und SQL2 Backup existiert innerhalb der EMC2 Symmetrix je ein BCV-Volume, das für die Datensicherung dem Backupserver zugewiesen wird.
In dieser Konfiguration wird pro STD-Volume/BCV-Volume-Paar eine EMC2 Symmetrix Device Group definiert.
Während des Datensicherungsprozesses wird eine Transaktionsmarke in die Transaktionsprotokolle aller Fabasoft Components COO-Service-Datenbanken geschrieben. Dazu wird eine spezielle Konfiguration („linked“) der
beteiligten Microsoft SQL Server 2000 Instanzen vorausgesetzt.
135
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 136
EMC2 Symmetrix Device Group Layout
Das Beispiel geht von folgendem EMC2 Symmetrix Device Group Layout aus:
DEVICE
GROUP
DATEISYSTEM
BESCHREIBUNG
DATA_01
M:\
Microsoft SQL Server Dateien für die Fabasoft Components
COO-Service-Datenbanken COOGW1 und COOST1
DATA_02
N:\
Microsoft SQL Server Dateien für die Fabasoft Components
COO-Service Datenbank COOST2
LOG_01
O:\
Microsoft SQL Server Log Dateien für die Fabasoft Components
COO-Service-Datenbanken COOGW1 und COOST1
LOG_02
P:\
Microsoft SQL Server Log Dateien für die Fabasoft Components
COO-Service Datenbank COOST2
MMC_01
U:\
Fabasoft Components MMC-Service-Bereiche für die Fabasoft
Components MMC-Services MMCGW1 und MMCST1
MMC_02
V:\
Fabasoft Components MMC-Service-Bereiche für das Fabasoft
Components MMC-Service MMCST2
BACK_01
K:\
Dateisystem für die Microsoft SQL Server TransaktionsprotokollSicherungen der Fabasoft Components COO-Service-Datenbanken
COOGW1 und COOST1
BACK_02
L:\
Dateisystem für die Microsoft SQL Server TransaktionsprotokollSicherungen der Fabasoft Components COO-Service Datenbank
COOST2
Tabelle 6: Device-Group- und Mount-Konfiguration
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 137
6. Datensicherheit: Online-Backup, Recovery
6.3 Beispiel
Datensicherung (Backup)
Die folgenden Schritte sind für eine konsistente Datensicherung (vollständiges Online-Backup einer Fabasoft
Components Domäne) beispielhaft nötig:
Die im Storagesystem EMC2 Symmetrix von den Fabasoft Components COO-Service-Datenbanken und von
den Fabasoft Components MMC-Service-Bereichen verwendeten Volumes müssen sich im „Synchronized
Mode“ befinden:
symmir
symmir
symmir
symmir
symmir
symmir
symmir
symmir
-g
-g
-g
-g
-g
-g
-g
-g
DATA_01 establish DEV001 BCV ld BCV001
DATA_02 establish DEV001 BCV ld BCV001
LOG_01 establish DEV001 BCV ld BCV001
LOG_02 establish DEV001 BCV ld BCV001
MMC_01 establish DEV001 BCV ld BCV001
MMC_02 establish DEV001 BCV ld BCV001
BACK_01 establish DEV001 BCV ld BCV001
BACK_02 establish DEV001 BCV ld BCV001
EMC2 TimeFinder Befehle zur Überprüfung des Status der einzelnen Volumes:
symmir
symmir
symmir
symmir
symmir
symmir
symmir
symmir
-g
-g
-g
-g
-g
-g
-g
-g
DATA_01 query
DATA_02 query
LOG_01 query
LOG_02 query
MMC_01 query
MMC_02 query
BACK_01 query
BACK_02 query
Alternativ kann jedes BCV beispielsweise alle 5 Sekunden auf Synchronizität mit dem Standardvolume überprüft werden:
symmir –g DATA_01 verify –synched –i 5
Datensicherung der Fabasoft Components COO-Service-Datenbanken, dabei wird automatisch ein VDIMetafile generiert. Dadurch werden automatisch die Volumes (BCVs) der Datenbanken entkoppelt.
tsimsnap2 backup -d COOGW1 COOST1 -f K:\meta -s SQL1\INST1
tsimsnap2 backup -d COOST2 -f L:\meta -s SQL2\INST2
Setzen einer verteilten Transaktionsmarke in allen Transaktionsprotokollen der Fabasoft Components COOService-Datenbanken. Die Prozedur (Stored Procedure) fsc_settxmark wird weiter hinten gesondert
beschrieben (Transact-SQL-Kommandos):
TSQL: execute fsc_settxmark
137
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 138
Datensicherung der Transaktionsprotokolle der Fabasoft Components COO-Service-Datenbanken (TransactSQL-Kommandos):
TSQL: backup log COOGW1 to file='K:\MSSQL\COOGW1_LOG.BAK'
TSQL: backup log COOST1 to file='K:\MSSQL\COOST1_LOG.BAK'
TSQL: backup log COOST2 to file='L:\MSSQL\COOST2_LOG.BAK'
Entkoppeln der restlichen Volumes (BCVs):
symmir
symmir
symmir
symmir
-g
-g
-g
-g
MMC_01 -instant split DEV001
MMC_02 -instant split DEV001
BACK_01 -instant split DEV001
BACK_02 -instant split DEV001
Nun können die Volumes (BCVs) zum Backupserver umgehängt und die Datenbestände (Microsoft SQL Server Datenbanken, Fabasoft Components MMC-Service-Bereiche, ...) dieser Volumes auf andere Medien, beispielsweise auf Sicherungsbänder geschrieben werden.
Wiederherstellung (Restore / Recovery)
Die folgenden Schritte sind für die Wiederherstellung der Datenbestände einer Fabasoft Components Domäne
aus einem konsistenten und vollständigen Online-Backup beispielhaft nötig:
Die Fabasoft Domäne (Fabasoft Components Webservices, Fabasoft Components Konvertierungsservices, Fabasoft Components AT-Services und Fabasoft Components Backendservices) werden
gestoppt:
Die Fabasoft Components COO-Service-Datenbanken werden im Microsoft SQL Server Enterprise Manager
oder mittels der sp_detach_db Stored Procedure abgetrennt (Transact-SQL-Kommandos):
TSQL: sp_detach_db 'COOGW1'
TSQL: sp_detach_db 'COOST1'
TSQL: sp_detach_db 'COOST2'
Mit dem symntctl list -volume Kommando erhält man eine Liste der aktuellen Informationen
zu den STD-Volumes:
symntctl list –volume
Die STD-Volumes für die Fabasoft Components COO-Service-Datenbanken, die Fabasoft Components
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 139
6. Datensicherheit: Online-Backup, Recovery
6.3 Beispiel
MMC-Service-Bereiche, die Transaktionsprotokolle und die Backup-Volumes werden vom Fabasoft Backendserver-Cluster und vom Microsoft SQL Server Datenbankserver-Cluster abgetrennt:
symntctl
symntctl
symntctl
symntctl
symntctl
symntctl
symntctl
symntctl
umount
umount
umount
umount
umount
umount
umount
umount
-drive
-drive
-drive
-drive
-drive
-drive
-drive
-drive
m:
n:
o:
p:
u:
v:
k:
l:
Die BCV-Volumes für die Fabasoft Components COO-Service-Datenbanken, die Fabasoft Components MMCService-Bereiche, die Transaktionsprotokolle und die Backup-Volumes werden vom Backupserver mit
symntctl umount Befehlen abgetrennt. Danach werden die Daten der BCV-Volumes mit EMC2 TimeFinder „Restore“ Operationen auf die STD-Volumes zurückkopiert:
symmir
symmir
symmir
symmir
symmir
symmir
symmir
symmir
-g
-g
-g
-g
-g
-g
-g
-g
DATA_01 restore DEV001 BCV ld BCV001
DATA_02 restore DEV001 BCV ld BCV001
LOG_01 restore DEV001 BCV ld BCV001
LOG_02 restore DEV001 BCV ld BCV001
MMC_01 restore DEV001 BCV ld BCV001
MMC_02 restore DEV001 BCV ld BCV001
BACK_01 restore DEV001 BCV ld BCV001
BACK_02 restore DEV001 BCV ld BCV001
Mit EMC2 TimeFinder symmir query oder symmir verify Operationen wird der Zustand der Volumes geprüft, bis die Daten vollständig auf die STD-Volumes zurückkopiert wurden. Danach werden die STDVolumes wieder von den BCV-Volumes getrennt:
symmir
symmir
symmir
symmir
symmir
symmir
symmir
symmir
-g
-g
-g
-g
-g
-g
-g
-g
DATA_01 split DEV001
DATA_02 split DEV001
LOG_01 split DEV001
LOG_02 split DEV001
MMC_01 split DEV001
MMC_02 split DEV001
BACK_01 split DEV001
BACK_02 split DEV001
Die STD-Volumes werden dem Fabasoft Backendserver-Cluster und dem Microsoft SQL Server Datenbankserver-Cluster auf Basis der zuvor mit symntctl list-volume generierten Liste wieder zur Verfügung gestellt:
symntctl mount -drive m: -vol HarddiskVolume8
symntctl mount -drive n: -vol HarddiskVolume9
139
05Referenzarchitektur
04.04.2005
symntctl
symntctl
symntctl
symntctl
symntctl
symntctl
mount
mount
mount
mount
mount
mount
12:26 Uhr
-drive
-drive
-drive
-drive
-drive
-drive
o:
p:
u:
v:
k:
l:
Seite 140
-vol
-vol
-vol
-vol
-vol
-vol
HarddiskVolume10
HarddiskVolume11
HarddiskVolume12
HarddiskVolume13
HarddiskVolume14
HarddiskVolume15
Die Fabasoft Components COO-Service-Datenbanken werden mit Informationen aus dem VDI-Metafile
wiederhergestellt, dabei werden die Transaktionsprotokoll-Sicherungen bis zur Transaktionsmarke nachgezogen.
tsimsnap2 restore -d COOGW1 COOST1 -f K:\meta -s SQL1\INST1
tsimsnap2 restore -d COOST2 -f L:\meta -s SQL2\INST2
Der Zeitpunkt der zuletzt verwendeten Transaktionsmarke wird aus allen msdb Datenbanken der beteiligten
Microsoft SQL Server Instanzen gelesen (Transact-SQL-Kommandos):
TSQL: select * from msdb.dbo.logmarkhistory
Die Transaktionsprotokolle werden bis zu dieser Transaktionsmarke nachgezogen (Transact-SQL-Kommandos):
TSQL: restore log COOGW1 from file='K:\MSSQL\COOGW1_LOG.BAK' with
replace, recovery,
stopatmark='FSCTXMARK' after '2004-08-20 04:00:00'
TSQL: restore log COOST1 from file='K:\MSSQL\COOST1_LOG.BAK' with
replace, recovery,
stopatmark='FSCTXMARK' after '2004-08-20 04:00:00'
TSQL: restore log COOST2 from file='L:\MSSQL\COOST2_LOG.BAK' with
replace, recovery,
stopatmark='FSCTXMARK' after '2004-08-20 04:00:00'
Die Caches der Fabasoft Components Win32-Clients und der Fabasoft Components Webservices müssen
gelöscht werden, um Inkonsistenzen zu vermeiden.
Die Fabasoft Components Backendservices werden im „Recovery Mode“ gestartet, um permanente Objektsperren aus den Datenbanken zu entfernen.
Danach werden die Fabasoft Components Backendservices in den „Normal Mode“ geschaltet.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 141
6. Datensicherheit: Online-Backup, Recovery
6.3 Beispiel
Beispiele für die Prozeduren fsc_settxmark und fsc_setlocaltxmark
fsc_settxmark sample (SQL1\INST1)
USE COOST1
GO
CREATE PROCEDURE fsc_settxmark
AS BEGIN
BEGIN DISTRIBUTED TRANSACTION
BEGIN DISTRIBUTED TRANSACTION FSCTXMARK WITH MARK
UPDATE COOGW1.dbo.cootxmark SET counter = counter + 1
UPDATE COOST1.dbo.cootxmark SET counter = counter + 1
COMMIT
EXEC [SQL2\INST2].COOST2.dbo.fsc_setlocaltxmark
COMMIT TRANSACTION
END
Quelltext 6: Beispiel für die Prozedur fsc_settxmark
fsc_setlocaltxmark sample (SQL2\INST2)
USE COOST2
GO
CREATE PROCEDURE fsc_setlocaltxmark
AS BEGIN
BEGIN TRANSACTION FSCTXMARK WITH MARK
UPDATE cootxmark SET counter = counter + 1
COMMIT
END
Quelltext 7: Beispiel für die Prozedur fsc_setlocaltxmark
141
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 142
Zusammenfassung
Abbildung 51
Backup und Recovery
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 143
6. Datensicherheit: Online-Backup, Recovery
6.3 Beispiel
143
05Referenzarchitektur
7
04.04.2005
12:26 Uhr
Seite 144
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 145
betriebsprozesse und
7 systemmanagement
Die Fabasoft Referenzarchitektur 5.0 kann für sich allein lediglich die erste Regel der Voraussetzungen für Hochverfügbarkeit (siehe Abbildung 5) erfüllen. Die Einhaltung der Regel 2 muss zur
Gänze in den Betriebsprozessen und im Systemmanagement verankert werden.
Auch für die Einhaltung von Regel 3 ist die Aufmerksamkeit des Betriebsführungsteams gefordert, insbesondere
dann, wenn die Systemkomponenten für die Behandlung von Fehlersituationen selbst fehlerbehaftet sind, ein
Mehrfachfehler aufgetreten ist oder die Umschaltung auf die redundante Komponente als manueller Eingriff vorgesehen ist.
Um ein kosteneffektives und vereinbartes Verfügbarkeitsniveau (Service-Level Agreement) für eine Fabasoft
Components Domäne gewährleisten zu können, müssen insbesondere die Betriebsprozesse standardisiert und
hochqualitativ ausgeführt werden.
Die Hauptaufgaben des Managements für Hochverfügbarkeit liegen
1. in der Erreichung möglichst langer MTBF-Zeiten für jede einzelne Systemkomponente durch laufende Überwachung und durch proaktives Handeln, beispielsweise das Erkennen von Ressourcenengpässen (ein volles
Dateisystem kann einen langen Stillstand zur Folge haben) und
2. in der Erzielung möglichst kurzer MTTR-Zeiten durch rasches Erkennen, Diagnostizieren und Beheben eines
Fehlers. Dabei ist größte Wachsamkeit bei der Fehlerbehebung durch Fremdfirmen im laufenden Betrieb angebracht: Der Austausch einer fehlerfreien statt der schadhaften Festplatte in einem RAID-Array zieht üblicherweise einen Stillstand nach sich.
Dazu ist eine notwendige Voraussetzung die jederzeit wiederholbare Installation der Subsysteme bzw. deren
Komponenten sowie die lückenlose zugehörige Dokumentation. Es dürfen im Betrieb nur Handgriffe getan
werden, die vorher durchdacht, dokumentiert und am Testsystem (System zur Simulation des Echtbetriebs)
getestet wurden.
Dieses Kapitel kann wiederum nur einen Einstieg in das Thema vermitteln, das Betriebshandbuch mit den
detaillierten Prozessen zum Incident-Management, Problem-Management, Configuration-Management, Change-
145
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 146
Management, Release-Management, Servicedesk, Service-Level-Management, Capacity-Management, Continuity-Management, Availability-Management und Security-Management muss projektspezifisch erstellt, gelebt,
überwacht und gesteuert werden.
In den folgenden Abschnitten werden einerseits die Grundzüge der Installation der wesentlichen Server einer
Fabasoft Components Domäne beschrieben und andererseits einige wichtige Monitoring-Aufgaben festgehalten.
7.1
installation der wesentlichen fabasoft services
Backendserver-Rollout
Schritt 1 – Installation des Betriebssystems
In diesem Schritt werden folgende Punkte abgedeckt:
Installation Betriebssystem
Installation aller benötigten Treiber
Installation aller erwünschten Microsoft Patches
Allgemeine Einstellungen (Remote-Desktop etc.)
Netzwerkkonfiguration (Backend-LAN, Heartbeat)
Schritt 2 – Volumes definieren
In diesem Schritt werden die zukünftig benötigten Volumes am Storagesystem angelegt.
Mindestvoraussetzung zum Anlegen eines Clusters ist eine Quorum-Disk.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 147
7. Betriebsprozesse und Systemmanagement
7.1 Installation der wesentlichen Fabasoft Services
Schritt 3 – Cluster installieren
Mittels Microsoft Cluster Administrator wird auf einem Knoten ein neuer Cluster angelegt.
Nach erfolgreicher Installation wird im Microsoft Cluster Administrator der zweite Server als neuer Knoten hinzugefügt. Anschließend werden mindestens zwei Clustergruppen und alle benötigten Clusterressourcen erzeugt.
Schritt 4 – Fabasoft Components Backendservices installieren
Es erfolgt die Installation der Fabasoft Components Backendservices auf allen Clusterknoten. Nach der erfolgreichen Installation wird die Fabasoft Components Domäne erstellt, dabei werden bereits die Datenbankservices
am Datenbankcluster verwendet.
Webserver-Rollout
Für den Betrieb der Fabasoft Components Webservices wird im Microsoft Internet Information Service für jeden
logischen Prozessor eine Website erzeugt. In jeder der erzeugten Websites wird ein Fabasoft Components Webservice installiert. Jede Website wird mit unterschiedlichen IP-Adressen oder Ports betrieben, um eine direkte
Verteilung der Benutzeranfragen auf die Fabasoft Components Webservices zu ermöglichen. Dadurch kann der
Lastverteiler aufgrund des konfigurierten Verteilungsalgorithmus die Sitzungsaffinität auf jedes Fabasoft Components Webservice aufrechterhalten. Diese Technik ermöglicht aufgrund der Cache-Technologie der Fabasoft
Components Webservices einen erheblichen Performance-Gewinn.
Wenn auf dem Webserver nur eine Website mit vier Worker-Processes im Microsoft Internet Information Service Application Pool konfiguriert werden würde, würde die Verteilung auf die einzelnen Fabasoft Components
Webservices das Microsoft Internet Information Service durchführen. Dieses wiederum verteilt die Benutzeranfragen nach einem Round-Robin-Algorithmus, welcher weder Sitzungsaffinität noch Gleichverteilung ermöglicht.
Vorraussetzungen
Microsoft Windows Server 2003 – Installation mit folgenden zusätzlich installierten Komponenten:
147
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 148
RIS (Remote Installation Services)
DHCP
Computerobjekte aller Webserver, gebunden an entsprechende GUIDs für die einzelnen Server, müssen im Active Directory zwecks korrekter Namensvergabe erzeugt werden.
Am DHCP-Server werden Reservierungen sowohl für das Frontend- als auch für das Backend-LAN eingerichtet.
Folgende RIS-Images werden erzeugt:
1. Microsoft Windows Server 2003 Web Edition CD-Based-Image
Wird bei der Installation von RIS automatisch erzeugt
Stellt die Grundlage für alle weiteren Images dar
2. Microsoft Windows Server 2003 Web Edition Custom-Based-Image für die Webserver
CD-Based Image installiert auf einem Webserver dient als Grundlage
Installierte Software:
Microsoft Internet Information Service
Alle benötigten Treiber
4 IIS-Websites
Je Website wird ein Fabasoft Components Webservice installiert.
Alternativ können die Fabasoft Components Webservices auch nach der Image-Installation
über Scripts ausgerollt werden. Dafür muss im Custom-Based-Image der Registry-Key für
Remote-Scripting gesetzt werden.
System- , IIS- und Netzwerkeinstellungen werden gemäß „Fabasoft Webserver Installation Guide“ konfiguriert
Custom-Based-Images werden mittels RIS auf allen Webservern ausgerollt.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 149
7. Betriebsprozesse und Systemmanagement
7.1 Installation der wesentlichen Fabasoft Services
Konvertierungsserver-Rollout
Für den Betrieb der Fabasoft Components Konvertierungsservices wird im Microsoft Internet Information Service
eine Website erzeugt. In dieser Website werden zwei Fabasoft Components Konvertierungsservices, durch Konfiguration im Microsoft Internet Information Service Application Pool, betrieben. Die Verteilung der Konvertierungsanfragen auf die beiden Fabasoft Components Konvertierungsservices erfolgt durch das Microsoft Internet
Information Service. Die Verteilung der Konvertierungsanfragen im Round-Robin-Algorithmus ist in diesem Fall
kein Nachteil, da die Fabasoft Components Konvertierungsservices nicht so stark wie die Fabasoft Components
Webservices vom Cache profitieren.
Vorraussetzungen
Microsoft Windows Server 2003 – Installation mit folgenden zusätzlich installierten Komponenten:
RIS
DHCP
Computerobjekte aller Konvertierungsserver, gebunden an entsprechende GUIDs für die einzelnen Server, müssen im Active Directory zwecks korrekter Namensvergabe erzeugt werden.
Am DHCP-Server werden Reservierungen für das Backend-LAN eingerichtet.
Folgende RIS-Images werden erzeugt:
1. Microsoft Windows Server 2003 Standard Edition CD-Based-Image
Wird bei der Installation von RIS automatisch erzeugt
Stellt die Grundlage für alle weiteren Images dar
2. Microsoft Windows Server 2003 Standard Edition Custom-Based-Image für die Konvertierungsserver
CD-Based-Image installiert auf einem Konvertierungsserver dient als Grundlage
Installierte Software:
149
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 150
Microsoft Internet Information Service
Alle benötigten Treiber
2 IIS-Websites
Je Website wird ein Fabasoft Components Webservice installiert.
Alternativ können die Fabasoft Components Webservices auch nach der Image-Installation
über Scripts ausgerollt werden. Dafür muss im Custom-Based-Image der Registry-Key für
Remote-Scripting gesetzt werden.
Konvertierungssoftware (Adobe Distiller, ActivePDF etc.)
System- , IIS- und Netzwerkeinstellungen werden gemäß „Fabasoft Web Server Installation Guide“ konfiguriert
Custom-Based-Images werden mittels RIS auf allen Konvertierungsservern ausgerollt.
Zusätzliche Software wie Microsoft Office und Microsoft XML Parser werden über Active Directory-Gruppenrichtlinien verteilt.
Überprüfung der Produktionsumgebung vor Inbetriebnahme
Vor Inbetriebnahme einer Fabasoft Components Domäne sind Tests zur Überprüfung der Implementierung vorzusehen. Diese Tests müssen vor der Durchführung im Detail geplant und definiert werden.
Die Zielsetzung ist, das System lückenlos kennen zu lernen und Überraschungen im Produktionsbetrieb hintanzuhalten (vergleichbar einem „Flight Manual“ in der Luftfahrt: ein Pilot geht auch in einer Notsituation gemäß
Anweisungen vor).
Mindestens in folgenden Bereichen müssen Tests durchgeführt werden:
Security
Tests betreffend die Netzwerksicherheit (Firewalls etc.), das Active Directory (Authentisierung, Autorisierung etc.), den Virenscanner, das SAN etc.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 151
7. Betriebsprozesse und Systemmanagement
7.1 Installation der wesentlichen Fabasoft Services
Installations- und Upgrade-Tests
Zusätzlich zum Produktionssystem muss ein Testsystem existieren, welches ein Klon des Produktionssystems sein sollte. In diesem Testsystem muss jede Änderung vor der Umsetzung im Produktionssystem
getestet werden. Auf diesem Testsystem werden auch die Erkenntnisse zur voraussichtlichen geplanten
Stillstandszeit für geplante Aktualisierungen gewonnen.
Backup- und Recovery-Tests
Tests des Backup- und Recovery-Konzepts hinsichtlich Performance und Funktionalität müssen durchgeführt
werden.
Availability-Tests
Die Redundanz in jedem Subsystem muss vollständig getestet werden. Das Erkennen eines Fehlers und die
Auswirkungen des Wegfalls der Redundanz (Fehlerdiagnose) sowie die Maßnahmen zur Wiederherstellung
der Redundanz (Fehlerbehebung) müssen detailliert dokumentiert werden. Dazu gehören beispielsweise
Cluster-Failover-Tests, Tests für den Ausfall eines oder mehrerer Web- und/oder Konvertierungsserver, Verlust von Datenpfaden im SAN, schadhafte Festplatten usw.
Stabilitäts- und Überlasttests
Stabilitätstests sollen sicherstellen, dass sich das System auch unter Hochlast stabil und performant verhält. Subsystemkomponenten werden gezielt überlastet, um die Auswirkungen kennen zu lernen und zu
dokumentieren.
Performance-Tests
Simulation der im Service-Level Agreement vereinbarten Anzahl an registrierten Benutzern, um Systemengpässe und Tuningpotenziale bereits vor dem Echtbetrieb erkennen zu können.
Managementtests
Tests für die Implementierung der Managementanwendungen und Werkzeuge, wie z.B. Microsoft Operations
Manager, Fabasoft Operations Manager, Microsoft Windows Performance Monitor usw. müssen durchgeführt werden. Die Management-Werkzeuge werden im Zuge aller Tests verwendet, um Fehlerbilder anhand
der Messdatenmuster erkennen zu lernen.
151
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 152
Anwendungstests
Vollständige Tests aller Use-Cases der Anwendung sowohl über automatische Tests als auch durch manuelle Tests. Dies sowohl unter Normalbedingungen als auch parallel zu den anderen Tests.
7.2
systemmanagement für die fabasoft referenzarchitektur
Die Betriebsführung hat für die laufende Überwachung aller Subsysteme und deren Komponenten der Fabasoft
Components Domäne Sorge zu tragen.
Für die manuellen Tätigkeiten sollten dazu alle Server der Fabasoft Components Domäne vom Betriebsführungsteam über Remote-Console und Remote-Desktop (Microsoft Terminal Server) erreichbar sein.
Die Überwachung der Subsysteme (Software und Hardware) erfolgt nach Möglichkeit mit Managementwerkzeugen der jeweiligen Hersteller, z.B. IBM Director, HP Insight Manager, CiscoWorks, Fabasoft Operations Manager
etc.
Diese Werkzeuge stellen einerseits der Betriebsführung die Möglichkeit des aktiven Monitorings zur Verfügung,
zusätzlich werden Fehlersituationen automatisch an eine zentrale Problemmeldestelle (Leitstand) weitergeleitet,
z.B. via SNMP-Traps oder durch eine Integration in diesen Leitstand.
Der Leitstand, z.B. Microsoft Operations Manager, muss der Betriebsführung eine aktuelle und konsolidierte Darstellung des Zustands aller Systeme der Fabasoft Referenzarchitektur ermöglichen.
Aus der folgenden beispielhaften Aufstellung ist für die Fabasoft Referenzarchitektur 5.0 einerseits ersichtlich,
mit welchen Managementwerkzeugen die einzelnen Subsysteme überwacht und konfiguriert werden, und
andererseits, welche wesentlichen Überwachungsaufgaben die Betriebsführung für diese Subsysteme zu
erbringen hat.
Netzwerk-Subsysteme
Die Überwachung und das Management der Netzwerk-Subsysteme, Arbeitsplatz-LAN (Client-LAN), Client-
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 153
7. Betriebsprozesse und Systemmanagement
7.2 Systemmanagement für die Fabasoft Referenzarchitektur
Firewall, Anschaltknoten, Server-Firewall, Lastverteiler, Frontend-LAN und Backend-LAN erfolgen mit Managementwerkzeugen des Herstellers, z.B. CiscoWorks für das Cisco Catalyst 6500 Management.
Die Betriebsführung erbringt weitere Management- und Überwachungsaufgaben, insbesondere in Bezug auf:
1. Netzwerk-Fehlerstatistiken (z.B. Lost Packets)
2. Netzwerkauslastung und Analyse von Auslastungstrends zur Verhinderung von Engpässen
3. Gleichmäßige Verteilung der Last innerhalb der Webserver-Farmen
4. Zustand der Webserver aus Sicht des Lastverteilers
5. Webserver-Ausfälle, fehlgeschlagene ICMP-Probes oder HTTP-Probes
Die Überwachung und das Management des WANs werden hier nicht betrachtet.
Server-Subsysteme
Die Überwachung und das Management der Server-Subsysteme, Webserver-Farm, Konvertierungsserver-Farm,
AT-Server, Backendserver-Cluster, Datenbankserver-Cluster und der Server für Basisdienste erfolgen mit
Managementwerkzeugen des Herstellers, z.B. IBM Director oder HP Insight Manager.
Zusätzlich werden die folgenden Managementwerkzeuge eingesetzt, um die installieren Softwareprodukte zu
überwachen und zu konfigurieren:
1. Microsoft Operations Manager Agents für die Überwachung von Betriebssystem und Datenbanksystemkomponenten
2. Fabasoft Operations Manager für die Integration der Überwachung der Fabasoft Components Services in den
Microsoft Operations Manager
Die Betriebsführung erbringt weitere Management- und Überwachungsaufgaben, insbesondere in Bezug auf:
1. Performance durch die Überwachung mit dem Microsoft Performance Monitor und Werkzeugen des Fabasoft
Operation Managers
153
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 154
2. Auslastung und Auslastungstrends mit dem Microsoft Performance Monitor und Werkzeugen des Fabasoft
Operation Managers
3. Fehlererkennung und Fehleranalysen durch die zusätzliche Überwachung mit dem Microsoft Event Viewer und
durch Analyse von Fehlerprotokollen, z.B. Microsoft SQL Server Fehlerprotokoll, IIS-Protokoll, Cluster-Protokoll
und Fabasoft Components Fehlerprotokolle
4. SQL Analysen durch die Überwachung mit dem Microsoft SQL Server Profiler
Die Überwachung und das Management des Arbeitsplatzes (Webbrowser-Client) werden hier nicht betrachtet.
Storage-Subsysteme
Die Überwachung und das Management der Storage-Subsysteme, SAN, Storagesystem und Tape-Library erfolgen mit Managementwerkzeugen des Herstellers, z.B. EMC2 Control Center.
Die Betriebsführung erbringt weitere Management- und Überwachungsaufgaben, insbesondere in Bezug auf:
1. Performance durch die Überwachung mit dem EMC2 Control Center bzw. webbasierten Werkzeugen der Hersteller
2. Auslastung und Auslastungstrends
3. Fehlererkennung und Fehleranalyse
Kurzbeschreibung einiger Systemmanagementwerkzeuge
Microsoft Operations Manager
Für die Überwachung der Server kann der Microsoft Operations Manager Agent auf allen Servern installiert werden. Weiters muss ein Microsoft Operations Manager Server existieren (z.B. Managementserver).
Der Microsoft Operations Manager überwacht die Event-Logs und kritische Performance-Werte aller Server der
Fabasoft Produktionsumgebung. Weiters sollte das Fabasoft Operations Manager Management Pack installiert
werden, das die Überwachung der Fabasoft Components Services übernimmt.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 155
7. Betriebsprozesse und Systemmanagement
7.2 Systemmanagement für die Fabasoft Referenzarchitektur
IBM Director und andere Anwendungen
Anwendungen, wie z.B. der IBM Director, überwachen die Hardwarekomponenten der Fabasoft Produktionsumgebung. Dadurch ist es möglich Hardwareprobleme möglichst frühzeitig zu erkennen.
Performance-Werte
Das Sammeln von Performance-Werten auf allen Servern der Fabasoft Produktionsumgebung wird empfohlen
(z.B. unter Verwendung des Microsoft Windows Performance Monitors). Diese Performance-Werte können zur
statistischen Auswertung in ein Data-Warehouse importiert werden (z.B. mithilfe des Fabasoft Operations
Manager Werkzeugs „loadcsv“).
Virenscanner
Weiters ist es notwendig die gesamte Fabasoft Produktionsumgebung mit einem (oder mehreren)
Virenscanner(n) zu überwachen. Der Virenscanner sollte – je nach Anforderung – täglich oder wöchentlich Überprüfungen der Dateien aller Dateisysteme durchführen. Außerdem müssen alle eingehenden (und allenfalls alle
ausgehenden) Dokumente auf den Webservern geprüft werden.
Überwachung von SAN und Storagesystem
Das SAN bzw. das Storagesystem sollten durch entsprechende Werkzeuge (je nach Storagesystem) ständig
überwacht werden, z.B. EMC2 Control Center für das EMC2 Symmetrix DMX Management.
155
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 156
Zusammenfassung
Abbildung 52
Betriebsführung:
Beispiele für Systemmanagementwerkzeuge
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 157
7. Betriebsprozesse und Systemmanagement
7.2 Systemmanagement für die Fabasoft Referenzarchitektur
Abbildung 53
Betriebsführung: Erkennen
von Lastspitzen
Abbildung 54
Aufgaben der
Betriebsführung:
Monitoring
157
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 158
Abbildung 55
Aufgaben der
Betriebsführung:
Operating
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 159
7. Betriebsprozesse und Systemmanagement
7.2 Systemmanagement für die Fabasoft Referenzarchitektur
159
05Referenzarchitektur
8
04.04.2005
12:26 Uhr
Seite 160
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 161
161
8 glossar
Fabasoft Components __________________________________________________________________________________________________________ Seite 14
Sammelbegriff für die Basistechnologien, auf der die Fabasoft Softwareprodukte aufbauen.
Fabasoft Components Anwendungsintegrationsservices
____________________________________________________
Seite 30
Die Fabasoft Components Anwendungsintegrationsservices sind dedizierte Fabasoft Components Webservices auf eigenen Webservern in eigenen Webserver-Farmen, die von Fachanwendungen im Wege von WebServices genutzt werden.
Fabasoft Components AT-Services ______________________________________________________________________________________ Seite 30
Die Fabasoft Components AT-Services werden für die Ausführung zeitgesteuerter, periodischer Vorgänge verwendet. Ein Fabasoft Components AT-Service arbeitet die Taskliste für einen registrierten Benutzer ab. In der
Taskliste liegen Tasks, die jeweils einen Status und eine Startzeit haben.
Fabasoft Components Backendservices ______________________________________________________________________________ Seite 30
Die Fabasoft Components Backendservices speichern Geschäftsobjekte bestehend aus Dokumenten (im Dateisystem) und strukturierten Eigenschaften (in Datenbanksystemen, wie z.B. Microsoft SQL Server).
Die Fabasoft Backendserver werden für den Zugriff auf und die Speicherung von Daten in den Fabasoft Components Stores verwendet.
Fabasoft Components COO-Services____________________________________________________________________________________ Seite 30
Das Fabasoft Components COO-Service wird verwendet, um die Daten der Geschäftsobjekte in einer relationalen Datenbank zu speichern.
Fabasoft Components Domäne ____________________________________________________________________________________________ Seite 30
Eine Fabasoft Components Domäne besteht aus den logisch zusammengehörigen Fabasoft Components Webservices, den Fabasoft Components Konvertierungsservices, den Fabasoft Components Backendservices, den
Fabasoft Components AT-Services, den Fabasoft iArchive-Services und den Fabasoft Components Anwendungsintegrationsservices. Jede Fabasoft Components Domäne ist über eine weltweit eindeutige Domänenidentifikation (Domain-ID) gekennzeichnet.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Fabasoft iArchive-Services
Seite 162
________________________________________________________________________________________________
Seite 30
Die Fabasoft iArchive-Services stellen für eine Fabasoft Components Domäne Archivfunktionalitäten zur
Verfügung und binden Archivsysteme zur physischen Auslagerung von Geschäftsobjekten an die Fabasoft
Components Domäne an.
Fabasoft Components Kernel
______________________________________________________________________________________________
Seite 29
Durch den Fabasoft Components Kernel wird im Fabasoft Components Webservice das Objektmodell zur Verfügung gestellt, die Objektplatzierung und der Zugriffsschutz festgelegt bzw. überprüft, Eigenschaften werden
zwischengespeichert, Methodenaufrufe zugeteilt und Transaktionen ausgeführt.
Fabasoft Components Konvertierungsservices ____________________________________________________________________ Seite 30
Durch die Fabasoft Components Konvertierungsservices wird die Konvertierung von Inhalten ermöglicht.
Konvertierungsanfragen werden von den Fabasoft Components Webservices zu den Fabasoft Components
Konvertierungsservices weitergeleitet. Es erfolgt keine direkte Kommunikation mit dem WebbrowserClient.
Fabasoft Components MMC-Services __________________________________________________________________________________ Seite 30
Das Fabasoft Components MMC-Service wird verwendet, um die Inhalte (Inhaltseigenschaften) von Geschäftsobjekten (Dokumente, Images usw.) im Dateisystem (NTFS) zu speichern.
Fabasoft Components Stores
____________________________________________________________________________________________
Seite 161
Fabasoft Components Stores sind logische Datenspeicher, die für die persistente Datenhaltung von Geschäftsobjekten auf den Serversystemen sorgen.
Fabasoft Components Webservice __________________________________________________________________________ Seite 29, 161,162
Die am Webserver eintreffenden Benutzeranfragen werden vom Microsoft Internet Information Service an das
Fabasoft Components Webservice (Thread-Pool des Web-Tiers der verteilten Anwendung; ISAPI-Erweiterung
des Microsoft Internet Information Service) weitergereicht.
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 163
163
Simple Object Access Protocol (SOAP)
____________________________________________________________________________
Seite 163
Ein Standard für die plattformunabhängige Kommunikation zwischen verteilten Systemen, basierend auf XMLStandards. SOAP dient zum Austausch von strukturierten Informationen in einer dezentralen Netzwerkumgebung. Um eine möglichst hohe Flexibilität zu erreichen wird für die Datenübergabe das Dateiformat XML
verwendet.
Webanwendung __________________________________________________________________________________________________________________ Seite 11
Unter Webanwendungen werden solche Systeme verstanden, deren Benutzerschnittstelle auf den Standards
HTML (grafische Darstellung im Webbrowser-Client) und HTTP (Übertragungsprotokoll) basiert.
Webbrowser-Client ______________________________________________________________________________________________________ Seite 11, 163
Unter einem Webbrowser-Client wird in diesem Buch ein Arbeitsplatzrechner (PC-Arbeitsplatz) mit dem
Betriebssystem Microsoft Windows, dem Webbrowser Microsoft Internet Explorer und entsprechender Anwendungssoftware (z.B. Microsoft Office) verstanden.
Web-Service ______________________________________________________________________________________________________________ Seite 161, 163
Ein auf Webstandards (in der Regel XML, HTTP) aufbauender Dienst zum Austausch von Informationen in einer
verteilten und dezentralisierten Umgebung. Dazu wird in der Regel das Protokoll SOAP verwendet. Das WebService kann von einem Client über das Internet mit einem Uniform Resource Locator (URL) angesprochen werden. Die Funktionalität des Web-Service wird in einer definierten Schnittstelle – häufig mit Hilfe der Web Service Definition Language (WSDL) – beschrieben. Aufgrund der verwendeten Standards (XML und HTTP) sind
Web-Services unabhängig von einer bestimmten Programmiersprache und Systemplattform.
Web Service Definition Language (WSDL)
________________________________________________________________________
Ein XML-Dokument zur Beschreibung der Schnittstelle eines Web-Service.
Seite 163
05Referenzarchitektur
9
04.04.2005
12:26 Uhr
Seite 164
05Referenzarchitektur
04.04.2005
12:26 Uhr
Seite 165
165
9 abbildungsverzeichnis
Abbildung 1
Abbildung 2
Abbildung 3
Abbildung 4
Abbildung 5
Abbildung 6
Abbildung 7
Abbildung 8
Abbildung 9
Abbildung 10
Abbildung 11
Abbildung 12
Abbildung 13
Abbildung 14
Abbildung 15
Abbildung 16
Abbildung 17
Abbildung 18
Abbildung 19
Abbildung 20
Abbildung 21
Abbildung 22
Abbildung 23
Abbildung 24
Abbildung 25
Abbildung 26
Abbildung 27
Abbildung 28
E-Government: Von Antrag bis Zustellung ______________________________________________________________ 12
MTTF einiger Hardwarekomponenten __________________________________________________________________ 18
Ursachen für Systemstillstände [IEEE95] ________________________________________________________________ 20
Verfügbarkeitsgrade __________________________________________________________________________________________ 23
Voraussetzungen für Hochverfügbarkeit ________________________________________________________________ 24
Hochverfügbarkeitsklassen __________________________________________________________________________________ 26
Zusammenfassung Verfügbarkeit __________________________________________________________________________ 27
Fabasoft Components Softwarearchitektur ____________________________________________________________ 31
Fabasoft Components Transaktionen ____________________________________________________________________ 31
Verteilte Transaktionen mit Fabasoft Components __________________________________________________ 33
Ausgewählte Architektur-Prinzipien für Hochverfügbarkeit ______________________________________ 33
Referenzarchitektur ____________________________________________________________________________________________ 34
Beschreibung des Lastverteilers __________________________________________________________________________ 46
Verteilungsalgorithmen und Sitzungsaffinität des Lastverteilers ________________________________ 47
Verfügbarkeit und Fehlerstrategien des Lastverteilers ______________________________________________ 47
Microsoft Windows Server Cluster ______________________________________________________________________ 54
Microsoft Cluster: Failover-Richtlinien __________________________________________________________________ 55
Ausfall eines Clusterknotens: Failover __________________________________________________________________ 56
Hochverfügbare Server ________________________________________________________________________________________ 60
Subsystem 1: Arbeitsplatz (Webbrowser-Client) ______________________________________________________ 65
Subsystem 2: Arbeitsplatz-LAN (Client-LAN) __________________________________________________________ 68
Subsystem 3: Client-Firewall ______________________________________________________________________________ 69
Subsystem 4: WAN ____________________________________________________________________________________________ 72
Subsystem 5: Anschaltknoten ______________________________________________________________________________ 73
Subsystem 6: Server-Firewall ______________________________________________________________________________ 76
Subsystem 7: Lastverteiler Beschreibung ______________________________________________________________ 80
Subsystem 7: Lastverteiler Hochverfügbarkeit, Beispielkonfiguration ________________________ 81
Subsystem 8: Frontend-LAN ________________________________________________________________________________ 86
05Referenzarchitektur
04.04.2005
Abbildung 29
Abbildung 30
Abbildung 31
Abbildung 32
Abbildung 33
Abbildung 34
Abbildung 35
Abbildung 36
Abbildung 37
Abbildung 38
Abbildung 39
Abbildung 40
Abbildung 41
Abbildung 42
Abbildung 43
Abbildung 44
Abbildung 45
Abbildung 46
Abbildung 47
Abbildung 48
Abbildung 49
Abbildung 50
Abbildung 51
Abbildung 52
Abbildung 53
Abbildung 54
Abbildung 55
12:27 Uhr
Seite 166
Subsystem 9: Webserver-Farm Beschreibung, Hochverfügbarkeit ______________________________ 90
Subsystem 9: Webserver-Farm Beispielkonfiguration ______________________________________________ 91
Subsystem 10: Backend-LAN ______________________________________________________________________________ 92
Subsystem 11: Konvertierungsserver-Farm Beschreibung, Hochverfügbarkeit ______________ 97
Subsystem 11: Konvertierungsserver-Farm Beispielkonfiguration ______________________________ 98
Subsystem 12: AT-Server (Automated Tasks) __________________________________________________________ 99
Subsystem 13: Backendserver-Cluster Beschreibung, Hochverfügbarkeit __________________ 102
Subsystem 13: Backendserver-Cluster Beispielkonfiguration __________________________________ 103
Subsystem 14: Datenbankserver-Cluster Beschreibung, Hochverfügbarkeit ________________ 105
Subsystem 14: Datenbankserver-Cluster Beispielkonfiguration ________________________________ 106
Subsystem 15: Storage Area Network (SAN) ________________________________________________________ 108
Subsystem 16: Storagesystem ____________________________________________________________________________ 111
Subsystem 17: Tape-Library ______________________________________________________________________________ 113
Subsystem 18a: Domaincontroller ______________________________________________________________________ 115
Subsystem 18b: Mailserver ________________________________________________________________________________ 117
Subsystem 18c: Managementserver ____________________________________________________________________ 119
Subsystem 18c: Data-Warehouse-Server ____________________________________________________________ 120
Subsystem 18d: Backupserver ____________________________________________________________________________ 121
Subsystem 18e: Indexserver Beschreibung, Hochverfügbarkeit ________________________________ 123
Subsystem 18e: Indexserver Beispielkonfiguration ________________________________________________ 124
Datensicherheit: Fabasoft Backendserver-Cluster __________________________________________________ 132
Datensicherheit: Microsoft SQL Server Datenbankserver-Cluster ____________________________ 134
Backup und Recovery ________________________________________________________________________________________ 142
Betriebsführung: Beispiele für Systemmanagementwerkzeuge ________________________________ 156
Betriebsführung: Erkennen von Lastspitzen __________________________________________________________ 157
Aufgaben der Betriebsführung: Monitoring __________________________________________________________ 157
Aufgaben der Betriebsführung: Operating ____________________________________________________________ 158
05Referenzarchitektur
04.04.2005
12:27 Uhr
Seite 167
167
05Referenzarchitektur
04.04.2005
10
12:27 Uhr
Seite 168
05Referenzarchitektur
04.04.2005
12:27 Uhr
Seite 169
169
10 literaturverzeichnis
[vBKP02]
van Bon, Jan (Hg.)/ Kemmerling, Georges (Hg.)/ Pondman, Dick (Hg.): IT Service
Management. Eine Einführung. Hägendorf: Buchzentrum AG, 2002.
[BmLd99]
Brain, Marshall/Libertone David: Windows NT Cluster Server Guidebook. Old Tappan:
Prentice Hall PTR, 1999.
[BbVr03]
Braswell, Byron/Voegeli, Richard: Patterns for the Edge of Network. High Availability
and High Performance. New York: International Business Machines Corporation, 2003.
[BrCo04]
Brocade Communications Systems Inc.: „Brocade SilkWorm 3900 Switch“.
URL: http://www.brocade.com/products/switches/silkworm_3900/index.jsp.
[Stand: 22.10.2004]
[Broc02]
Brockhaus: Der Brockhaus Computer und Informationstechnologie.
Mannheim: Brockhaus, 2002.
[CiSy04a]
Cisco Systems Inc.: „Cisco Catalyst 6500 Series Switches“.
URL: http://www.cisco.com/en/US/products/hw/switches/ps708/index.html.
[Stand: 22.10.2004]
[CiSy04b]
Cisco Systems Inc.: „Cisco Content Switching Module White Paper“. URL:
http://www.cisco.com/en/US/products/hw/modules/ps2706/products_white_paper09186
a0080160311.shtml. [Stand: 22.10.2004]
[CiSy04c]
Cisco Systems Inc.: „Cisco 6500/Cisco 7600 Series Supervisor Engine 720 Data Sheet“.
URL:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_data_sheet09186a0
080159856.html. [Stand: 22.10.2004]
[CiSy04d]
Cisco Systems Inc.: „Cisco Catalyst 6500 Series Content Switching Module“. URL:
http://www.cisco.com/en/US/products/hw/modules/ps2706/products_data_sheet09186a
00800887f3.html. [Stand: 22.10.2004]
[CiSy04e]
Cisco Systems Inc.: „SSL Service Module for the Catalyst 6500 & Cisco 7600 Series“.
URL:
http://www.cisco.com/en/US/products/hw/modules/ps2706/products_data_sheet09186a
00800c4fe9.html. [Stand: 22.10.2004]
[CiSy04f]
Cisco Systems Inc.: „Cisco Catalyst 6500 Series Switches Data Sheets“. URL:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_data_sheets_list.ht
ml. [Stand: 22.10.2004]
05Referenzarchitektur
04.04.2005
12:27 Uhr
Seite 170
[CiSy04g]
Cisco Systems Inc.: „Cisco PIX 515E Firewall“. URL: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/ps4094/index.html. [Stand: 22.10.2004]
[CiSy04h]
Cisco Systems Inc.: „Cisco 1721 Modular Access Router“.
URL: http://www.cisco.com/en/US/products/hw/routers/ps221/ps224/index.html.
[Stand: 22.10.2004]
[CiSy04i]
Cisco Systems Inc.: „Cisco Catalyst 6500 Series Supervisor Engine 720 Whitepaper“.
URL: http://newsroom.cisco.com/dlls/Sup_720_DS.pdf. [Stand: 22.10.2004]
[EmCo04a]
EMC Corporation: „EMC Power Path Product Description Guide“. URL:
http://www.emc.com/products/product_pdfs/pdg/powerpath_pdg.pdf.
[Stand: 22.10.2004]
[EmCo04b]
EMC Corporation: „EMC Symmetrix DMX Series Data Sheet“. URL:
http://www.emc.com/products/systems/symmetrix/DMX_series/pdf/DMX_series.pdf.
[Stand: 22.10.2004]
[EmCo04c]
EMC Corporation: „EMC Symmetrix DMX800 Specification Sheet“. URL:
http://www.emc.com/products/systems/symmetrix/symmetrix_DMX800/pdf/DMX800.pdf.
[Stand: 22.10.2004]
[EuUn04]
European Union: Online availability of public services: How does Europe progress? Web
based survey on electronic public services. Report of the fourth measurement. October
2003. URL:
http://europa.eu.int/information_society/eeurope/2005/doc/all_about/cgey4_measure
ment_final.pdf [Stand: 25.10.2004]
[EmSh04]
Evan, Marcus/Stern, Hal: Blueprints for High Availability. 2. Auflage. Indianapolis: John
Wiley & Sons Inc, 2004.
[HZFE01]
Hendrik, Ernst/Zustak, Martin/Fuchs, Peter/Erdenberger, Silvio/Tschoeke, Arwed:
Implementing UPS Configurations with Microsoft Cluster Server. New York: International
Business Machines Corporation, 2001.
[HePa04a]
Hewlett-Packard Company: „ProLiant DL740 – Overview & Features“.
URL: http://h18004.www1.hp.com/products/servers/proliantdl740/index.html.
[Stand: 22.10.2004]
[HePa04b]
Hewlett-Packard Company: „ProLiant DL380 G4 – Overview & Features“.
URL: http://h18004.www1.hp.com/products/servers/proliantdl380/index.html.
[Stand: 22.10.2004]
05Referenzarchitektur
04.04.2005
12:27 Uhr
Seite 171
171
[HePa04c]
Hewlett-Packard Company: „ProLiant DL360 G4 – Overview & Features“.
URL: http://h18004.www1.hp.com/products/servers/proliantdl360/index.html.
[Stand: 22.10.2004]
[HePa04d]
Hewlett-Packard Company: „HP BladeSystem“. URL:
http://h71028.www7.hp.com/enterprise/cache/80316-0-0-0-121.aspx. [Stand: 28.10.2004]
[InCo04]
Intel Corporation: „Networking and Communications: Advanced Networking Services Teaming“. URL: http://www.intel.com/support/network/sb/cs-009747.htm.
[Stand: 22.10.2004]
[IBMC04a]
International Business Machines Corporation: „eservers from IBM: xSeries 445“.
URL: http://www.pc.ibm.com/us/eserver/xseries/x445.html. [Stand: 22.10.2004]
[IBMC04b]
International Business Machines Corporation: „eservers from IBM: xSeries 345“.
URL: http://www.pc.ibm.com/us/eserver/xseries/x345.html. [Stand: 22.10.2004]
[IBMC04c]
International Business Machines Corporation: „eservers from IBM: xSeries 335“.
URL: http://www.pc.ibm.com/us/eserver/xseries/x335.html. [Stand: 22.10.2004]
[IBMC04d]
International Business Machines Corporation: „IBM LTO Ultrium Scalable Tape
Library 3583: Overview“.
URL: http://www-1.ibm.com/servers/storage/tape/3583/index.html. [Stand: 22.10.2004]
[IBMC04e]
International Business Machines Corporation: „IBM eServer Blade Center“.
URL: http://www-1.ibm.com/servers/eserver/bladecenter/index.html. [Stand: 28.10.2004]
[IEEE95]
IEEE Computer Society (Hg.): IEEE Computer Magazine. 4/1995. Los Alamos: IEEE
Computer Society, 1995.
[JBHR98]
Johner, Heinz/Brown, Larry/Hinner, Franz-Stefan/Reis, Wolfgang/Westman,
Johan: Understanding LDAP. New York: International Business Machines Corporation,
1998.
[KMTN99]
Kumar Khattar, Ravi/Murphy, Mark S./Tarella, Giulio John/Nystrom, Kjell E.:
Introduction to Storage Area Network, SAN. New York: International Business Machines
Corporation, 1999.
[LeeR99]
Lee, Richard R.: Windows NT Microsoft Cluster Server. Emeryville: Osborne/McGrawHill, 1999.
[MjCb98]
McMains, John R./Chronister, Bob: Windows NT Backup & Recovery. Emeryville:
Osborne/McGraw-Hill, 1998.
05Referenzarchitektur
04.04.2005
12:27 Uhr
Seite 172
[MDMW02]
Mellish, Barry/Demmer, Christian/McGeoch, Graham/Wallace, Ian: IBM TotalStorage FAStT700 and Copy Services. New York: International Business Machines Corporation, 2002.
[MiCo04a]
Microsoft Corporation: „High Availability Resources“.
URL: http://www.microsoft.com/sql/techinfo/administration/2000/availability.asp.
[Stand: 22.10.2004]
[MiCo04b]
Microsoft Corporation: „Windows Server 2003 Cluster“. URL:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/clustering/default.mspx. [Stand: 22.10.2004]
[MiCo04c]
Microsoft Corporation: „Windows Server 2003 Clustering“. URL:
http://www.microsoft.com/windowsserver2003/techinfo/overview/bdmtdm/default.mspx.
[Stand: 22.10.2004]
[MiCo04d]
Microsoft Corporation: „White Paper: Windows Server 2003 Server Cluster Architecture“. URL: http://www.microsoft.com/windowsserver2003/techinfo/overview/servercluster.mspx. [Stand: 22.10.2004]
[MiCo04e]
Microsoft Corporation: „White Paper: Technical Overview of Windows Server 2003
Clustering Services“. URL: http://www.microsoft.com/windowsserver2003/techinfo/overview/clustering.mspx. [Stand: 22.10.2004]
[MiCo04f]
Microsoft Corporation: „Server Clusters: Cluster Configuration Best Practices for
Windows Server 2003“. URL: http://www.microsoft.com/technet/prodtechnol/
windowsserver2003/technologies/clustering/scconbp.mspx. [Stand: 22.10.2004]
[MiCo04g]
Microsoft Corporation: „Server Clusters: Network Configuration Best Practices“. URL:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/
clustering/clstntbp.mspx. [Stand: 22.10.2004]
[MiCo04h]
Microsoft Corporation: „Recommended Private „Heartbeat“ Configuration on a Cluster
Server:“. URL: http://support.microsoft.com/default.aspx?scid=kb;en-us;258750.
[Stand: 22.10.2004]
[MiCo04i]
Microsoft Corporation: „Microsoft SQL Server 2000 High Availability Series“. URL:
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/sqlhalp.mspx.
[Stand: 22.10.2004]
05Referenzarchitektur
04.04.2005
12:27 Uhr
Seite 173
173
[MiCo04j]
Microsoft Corporation: „Microsoft SQL Server High Availability Planning Guide“. URL:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0C4357E5EE56-4EA2-A028-EB40893F1049. [Stand: 22.10.2004]
[MiCo04k]
Microsoft Corporation: „Microsoft SQL Server High Availability Deployment Guide“.
URL:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=AD924002F355-4EB9-973E-F5DBAD264214. [Stand: 22.10.2004]
[MiCo04l]
Microsoft Corporation: „Microsoft SQL Server 2000 Failover Clustering“. URL:
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/failclus.mspx. [Stand:
22.10.2004]
[MiCo04m]
Microsoft Corporation: „Microsoft SQL Server Books Online: Backing up and Restoring
Databases“. URL: http://www.microsoft.com/sql/techinfo/productdoc/2000/default.asp.
[Stand: 22.10.2004]
[MiCo04n]
Microsoft Corporation: „PRB: Installation of a Named Instance of a SQL Server 2000
Virtual Server on a Windows 2003-Based Cluster Fails“. URL:
http://support.microsoft.com/default.aspx?scid=kb;en-us;815431. [Stand: 22.10.2004]
[MiCo04o]
Microsoft Corporation: „How to Configure Microsoft Distributed Transaction Coordinator on a Windows Server 2003 Cluster“. URL:
http://support.microsoft.com/default.aspx?scid=kb;en-us;301600. [Stand: 22.10.2004]
[Oasi04]
Oasis Consortium: „Oasis Standards“. URL: http://www.oasis-open.org. [Stand:
08.11.2004]
[Ogge01]
Oggerino Chris: High Availability Network Fundamentals. San Jose: Cisco Press, 2001.
[RGDF01]
Russell, Steve/Gonzalez, Olga Lucia Baquero/de Coutere, Bert/ Furniss, Duncan:
High Availability Without Clustering. New York: International Business Machines
Corporation, 2001.
[Spor97]
Sportack, Mark A.: Windows NT Clustering Blueprints. Indianapolis: Sams Publishing,
1997.
[TCGV00]
Tate, Jon/Cole, Geoff/Gomilsek, Ivo/van der Pijll, Jaap: Designing an IBM Storage
Area Network. New York: International Business Machines Corporation, 2000.
[TCGL02]
Tate, Jon/Coates, Gareth/Gomilšek, Ivo/Lewis, Andy: Designing and Optimizing an
IBM Storage Area Network. New York: International Business Machines Corporation,
2002.
05Referenzarchitektur
04.04.2005
[WAFK02]
[WdBK00]
[WAYW03]
12:27 Uhr
Seite 174
Watts, David/Aghdam, Reza Fanaei/Furniss, Duncan/King, Jason: IBM eServer
xSeries 440 Planning and Installation Guide. New York: International Business Machines
Corporation, 2002.
Watts, David/Bullard, Roger/Kalmantas, Marius: IBM eServer xSeries Clustering
Planning Guide. New York: International Business Machines Corporation, 2000.
Watts, David/Arzensek, Jure/Yong Wang, Jian/Weiner, Russ/Collins, Antony: IBM
eServer xSeries 445 Planning and Installation Guide. New York: International Business
Machines Corporation, 2003.
05Referenzarchitektur
04.04.2005
12:27 Uhr
Seite 175
175