zur letzten seite

© S

IGM

A C

hem

nitz

Gm

bH /

200

7-05

-30;

Kot

twitz

, Jö

rg

- 1 -

zur letzten Seite

Mit Strategie zur dynamischen IT

>> Ihr Ansprechpartner

Mathias WolfSIGMA Chemnitz GmbH

Bereichsleiter SystemtechnikAm Erlenwald 1309128 Chemnitz

Hochverfügbare IT Infrastrukturen

11.06.2008

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 2 -

SIGMA in Chemnitz: Gesellschaft für Systementwicklungund Datenverarbeitung mbH

SIGMA in Stuttgart: Software und Consulting GmbH

Gründung: Mai 1990

Mitarbeiter: 45

Jahresumsatz: ca. 6 Mio. €

Wir über uns

zurück zur 1. Seite

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 3 -

Geschäftsfelder unserer Sparten


Service· IT-technische Innovationen· Infrastrukturlösungen und erstklassiger SupportBeratung· Ganzheitliche Prozessunterstützung und –optimierung· organisatorische Managementberatung· unternehmensweite SoftwarelösungenEmbedded Lösungen· Hochqualifizierte Eigenentwicklungen · Individuallösungen im Soft- und HardwarebereichSIGMA in Leonberg· Betriebswirtschaftliche Standardsoftware· Produktdatenmanagement

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 4 -

Partner und Lösungen


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 5 -

Inhalt


Hochverfügbare IT- Infrastrukturen

Katastrophenschutz

Technologien zur Daten- und Hochverfügbarkeit

Praxisbeispiele

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 6 -

Infrastruktur allgemein

…..

Win2003Mainframe LinuxUnix / Solaris

Client / Netzwerkbereich(Datenvisualisierung)

Serverbereich (Datenverarbeitung)

Bandllaufwerke

Plattenspeicher / Flash-Speicher

Jukebox / Plattenarchive

Storagebereich (Datenspeicherung)

Backupbereich (Datensicherung)

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 7 -


Quellen: International Data Corporation, Gartner Group und Contingency Planning Research

0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000 6500

Brokerage

Credit Card Sales

Telecommunications

Banking

Pay per View

Home Catalog Sales

Airline Reservation

[1000 $]

$ 89,500

$ 90,000

$ 150,000

$ 360,000

$ 370,000

$ 2,600,000

$ 6,450,000

Durch Ausfallzeiten der IT verursachte Kosten

Pro Stunde !

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 8 -

Konsequenzen eines Ausfalles

Es gilt also, Ausfallzeiten zu minimieren !

Mögliche Konsequenzen eines Ausfalls:

- Umsatzeinbußen

- Geschäftsverluste

- Kosten für Wartung- und Service - Kosten für Rollback einer Aktion

- Strafen

- Rechtliche Folgen

- Verlust von Kunden

- Imageverlust

- Verlust von Menschenleben


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 9 -


HW –SW Fehler

Sabotage

Infrastruktur

Naturkatastrophen

Quelle: Disaster Recovery Strategies, IBM Redbook SG24-6844-00, 2002

Mögliche Gründe für Ausfallzeiten

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 10 -

permanent laufende

Anwendung

Redundanz von HW

Komponenten

Anwendung nur “kurz”

unterbrochen

Permanenz des Services

Permanenz des Systems

SLA Qualität

Plattform Qualität

Ein System gilt als hochverfügbar, wenn eineAnwendung auch im Fehlerfall weiterhin verfügbar istund ohne unmittelbaren menschlichen Eingriff weiter

genutzt werden kann.

Anwender nimmt keine oder nur eine kurze Unterbrechung wahr.

Hochverfügbarkeit (HA – High Availability) bezeichnetdie Fähigkeit eines Systems, bei Ausfall einer seiner Komponenten einen uneingeschränkten Betrieb zu

gewährleisten.


Hochverfügbarkeit- was ist das ?

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 11 -

Definition Verfügbarkeit


Erhöhung der Verfügbarkeit eines Systems, definiert durch IEEE als

x 100 (%).

Eine Hochverfügbarkeits-Konfiguration dient dazu, ungeplante Unterbrechungen (d.h. Ausfälle einzelner Betriebsmittel), sowie geplante Ausfallzeiten (z. B. HW-Wartungsfenster, Einbringen von SW-Korrekturen oder neuer SW) mit einer möglichst kurzen Unterbrechung des Produktionsbetriebes zu überstehen.

Betriebsdauer – Ausfallzeit

Betriebsdauer

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 12 -

Verfügbarkeit


Gesamtverfügbarkeit eines IT-Systems ist die geschlossene Betrachtung von

Hardware und

Software

Hochverfügbarkeit ist keine spezielle Technologie, sie ist vielmehr ein Ziel, dass für die spezielle Situation in einer Firma maßgeschneidert werden muss. Sie ist eine Kombination aus Strategien, Technologien, Training der Mitarbeiter und verschiedenen Serviceprozessen, um Unterbrechungen zu minimieren.

In der Praxis unterscheidet man zwischen geplanten und ungeplanten Unterbrechungen.

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 13 -

Geplante / ungeplante Unterbrechung


Quelle: Metagroup

Anwendungen8 %

Andere9 %

DB Backup52 %

Software13 %

Netzwerk10 %

Hardware8 %

Bedienung25 %

Software30 %

Anwendungen27 %

Andere3 %

Hardware15 %

geplante Unterbrechungen

Etwa 90%

ungeplante Unterbrechungen

Etwa 10%

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 14 -


Verfügbarkeit Ausfallzeit / Jahr

99.99 %99.99 %

99.9 %99.9 %

99 %99 %

52 min.52 min.

8,8 Std.8,8 Std.

99.999 %99.999 % 5 min.5 min.

3,7 Tage3,7 Tage

KonventionellKonventionell

Hoch- verfügbar

Verfügbarkeitsstufen

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 15 -


Aber: Wann gilt ein System wieder als “verfügbar”?

Power On Diagnose läuft durch ?

System Prompt/ Adminshell ist da?

Service für den Endbenutzer steht zur Verfügung ?

Klasse Bezeichnung Verfügbarkeit Downtime pro Jahr

2 Stabil 99.0% 3,7 Tage3 Verfügbar 99.9% 8,8 Stunden4 Hochverfügbar 99.99% 52,2 Minuten5 Fehlerunempfindlich 99.999% 5,3 Minuten6 Fehlertolerant 99.9999% 32 Sekunden7 Fehlerresistent 99.99999% 3 Sekunden

Die berühmten Neunen…

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 16 -

Lüfter, Netzteile, Steckkarten, Raid-SystemeNetzwerk- und Kontrolleranschlüsse

Auswahl Komponenten Qualität im Design und in Produktion,

Hardwaremanagement, Monitoring & Warnung vor Ausfällen,Fehlerkorrektur Hauptspeicher (ECC)

Hot plug / hot spare Lüfter, AC/DC, Platten, Tape Laufwerke, PCI boards,

Clustering

Automatic Server Restart,Rekonfiguration

Remote Management

Redundanz

Fehlerkorrektur und

Vermeidung

Hot swapMechanismen

Failover –Lösungen(no single Point of

failure)Automatische

Isolation von defekten Komponenten


Verfügbarkeitsmaßnahmen

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 17 -


• Mit heutiger Technologie kann eine Verfügbarkeit von mehr als 99.99 % nur mittels eines Clusters erreicht werden.

• Maßnahmen:

HW- und SW-mäßige Redundanz aller für die Produktion notwendigen Betriebsmittel,

Softwaremäßige Überwachung der Betriebsmittel,

Automatisierte Reaktionen auf Hard- und Softwarefehler(z.B. Verlagerung der Produktion auf ein anderes System, oder Rekonfigurationen),

Bei geplanten Unterbrechungen kommandogesteuert die automatisierte Ausführung der notwendigen Aktionen, sowie

Organisatorische Maßnahmen (Kompetenz der Mitarbeiter, Verbesserung der Service-Qualität, HV-Leitstand, Betriebsführungskonzept).

Hochverfügbarkeit Maßnahmen

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 18 -

Katastrophenschutz (KS)

Im IT-Bereich ist Katastrophenschutz diejenige Vorsorge, welche nach einer teilweisen oder vollständigen Zerstörung eines Rechenzentrums die Wiederaufnahme der Produktion und damit der geschäftskritischen Anwendungen ermöglicht.

Unter einer Katastrophe soll der Ausfall eines Rechenzentrums durch Stromausfall oder Zerstörung (Brand, Wassereinbruch, Explosion, Erdbeben, Sturm, Sabotage etc.), oder etwas spezifischer der Ausfall eines Hosts und der räumlich in der Nähe aufgestellten Speicherperipherie oder auch nur von Teilen der Speicherperipherie, die aktuelle Produktionsdaten enthält, verstanden werden.


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 19 -


Katastrophen führen zu einem Abbruch des Produktionsbetriebs und erfordern die Verfügbarkeit aller Betriebsmittel, die für die Wiederaufnahme des Produktionsbetriebs erforderlich sind, auf einem Standby-RZ.

Unter Standby-RZ versteht man ein räumlich mehr oder weniger weit entferntes RZ mit einer Hardware- und Software-Ausstattung, so dass die nach den KS-Anforderungen des Kunden relevanten Anwendungen des Produktions-RZs darauf ablauffähig sind.

Auf den Systemen im Standby-RZ können im Normalbetrieb Anwendungen laufen, die im Katastrophen-Fall (mit geringerer Performance) weiterlaufen, oder (bei weniger hohen Verfügbarkeitsanforderungen) terminiert werden.

Katastrophenschutz (KS)

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 20 -

Charakterisierung:

HV und KS schließen sich nicht aus; sie können vielmehr hervorragend kombiniert werden.Idealzustand:

Das wesentliche Merkmal von KS besteht darin, dass im Idealzustand über HV hinausgehend die für die Aufrechterhaltung des Produktionsbetriebes redundanten Betriebsmittel und Daten räumlich entfernt und damit gegenüber zerstörenden Einwirkungen am Produktionsort geschützt sind.

HV + räumliche Trennung = BC

HV = „Single failure recovery“

KS = „Site failure recovery“

BC-Cluster

Kombination von HV und KS


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 21 -


Business Continuity (HV und KS):

Der Kunde will keine Störung seiner Geschäfts-prozesse, auch nicht im Katastrophen-Fall.

HV ohne KS:

Risiko einer Katastrophe wird vom Kunden in Kauf genommen.

KS ohne HV:

Rasche Wieder-aufnahme des Betriebs nach Ausfall eines RZs ist so wichtig, dass der Kunde dafür das Risiko von Ausfallzeiten in Kauf nimmt.

HV KS

BC

Kombination von HV und KS

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 22 -

Business Continuity (BC)


Business Continuity:

Die wichtigen Geschäftsprozesse

des Kunden sollen möglichst wenig

gestört werden.

Die Störungen können vielfältige Gründe haben und werden üblicherweise kategorisiert nach

Zerstörung eines RZs:Störungen

innerhalb eines RZs: Hochverfügbarkeit

Katastrophenschutz

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 23 -

Vom Einzelsystem zum BC-Cluster

Einzelsystem HV-Cluster BC-Cluster (HV+KS)

Netz Netz

Local Site

RAID RAID

Netz

RAID

Remote Site


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 24 -

Konfigurationsbereiche

Ziel: Verfügbarkeiten von mindestens 99.99 %.Hierzu muss man die folgenden Konfigurationsbereiche einbeziehen:

Server-Bereich

Storage-Bereich

Client / Netz-Bereich

Win2003Mainframe LinuxUnix / Solaris

…..

…..

EMC2 HP / IBM / Storagtek Tape

…..

Netapp


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 25 -

Anforderungen an ein HV-Konzept


Durchführung folgender Aktionen ‒ gemäß den HV-Anforderungen des Kunden ‒ für jeden Bereich:

Etablierung eines Clusters von Systemen

Redundante Auslegung der Plattenspeicher mit Datenspiegelung,

Redundante Auslegung der Netzkomponenten inkl. der Netzanschlüsse für die Server,

Im Fehlerfall (idealerweise) automatische, bzw. bei geplanten Unterbrechungen gezielte Verlagerung von Anwendungen (inkl. ihren Umgebungen) auf ein anderes System (Standby System)

Restart der Anwendungen auf diesem System.

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 26 -

Geplante Unterbrechungen


BeispieleEinführung, Austausch oder

Upgrade von Hardware-komponenten (inkl. Wartung)

Einführung, Austausch oder Upgrade von Software-komponenten (in System- und Anwendersoftware), und/oder die

Einführung von Software-Korrekturen (in System- und Anwendersoftware).

Vorteile eines HV-ClustersAm Standby-System kann man vor der

Verlagerung einen Update/Upgrade des Betriebssystems oder der Anwendersoftware durchführen, ohne die Produktion zu stören,

Falls gewünscht, können der Software-Update bzw. Upgrade auf dem ehemaligen Produktionssystem nachgezogen und danach die Anwendungen zu einem unkritischen Zeitpunkt dahin zurückverlagert werden, und

Wenn nach der Verlagerung auf das Standby-System Probleme auftreten, kann automatisch auf das ehemalige Produktionssystem mit dem bisherigen Software-Stand zurückgeschaltet werden.

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 27 -

Ungeplante Unterbrechungen

BeispieleEin Fehler in einer Hardware-

Komponente wie einer CPU, einem peripheren Controller oder Gerät, oder einer Datenverbindung,

Ein Fehler im Betriebssystem oder Netz,

Ein Fehler in der Anwendung,Ein Bedienfehler des Operators oder

System Administrators, und/oderDie Zerstörung des gesamten

Rechenzentrums(“Katastrophen-Fall”).

VorteileAutomatische und rasche Ausfallerkennung ggf. automatische Übernahme der Produktion (Applikation) mit allen betroffenen Betriebsmitteln auf ein anderes System, und ggf. automatischer Restart der zur Produktion gehörenden Anwendungen an diesem SystemDie Ausfallerkennung selbst kann auf den verschiedenen Plattformen unterschiedlich realisiert sein.


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 28 -

Disaster Recovery Technologien


Datensicherung mit RAID TechnikBackup-SystemeContinuous Data Protection (CDP)ClusterImageReplikationVirtualisierung

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 29 -




© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 30 -

RAID Systeme


sind eine Kombination aus mehreren (austauschbaren) Festplatten. Die

Bezeichnung RAID steht dabei für Redundant Array of Independent Disks.

Die RAID-Systeme sind ausfallsicher, der Ausfall eines Einzellaufwerks gefährdet weder den Gesamtbetrieb noch die Daten. Hierfür verwendet das System einen Teil der Gesamtkapazität zum Speichern der Parity-Informationen.

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 31 -

RAID Level 0


RAID 0 fasst mehrere Laufwerke zu einem großen logischen Laufwerk zusammen. Die Daten werden im Stripping Verfahren, abhängig von der Blockgröße, auf alle Platten verteilt. Bei diesem Verfahren können zwar Kapazität und Geschwindigkeit maximal genutzt werden, allerdings ohne Redundanz.

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 32 -

RAID Level 1


Durch Mirroring (Plattenspiegelung) werden die Daten einer oder mehrerer Platten auf die gleiche Anzahl zusätzlicher Platten übertragen. Eine höhere Lesegeschwindigkeit wird erreicht, da die Requests auf 2 Platten aufgeteilt werden können, die unabhängig voneinander arbeiten. (50 % der Kapazität werden für die Redundanz genutzt.)

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 33 -

RAID Level 3/4


Level 3/4 speichert alle Parity-Informationen auf einer Festplatte. Die Daten werden im Stripping Verfahren auf die restlichen Platten verteilt. RAID 3 bietet eine hohe Transferrate und relativ kurze Zugriffszeiten. RAID Level 4 funktioniert wie Level 3, jedoch mit einem Stripping Faktor von einem Block und mehr, was noch bessere Zugriffsmöglichkeiten bewirkt. (10-20% der Kapazität werden für die Redundanz genutzt.)

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 34 -

RAID Level 5


RAID Level 5 verteilt Daten und Parity-Informationen gleichmäßig, blockbereichsweise auf die Platten. Damit ist jedes Laufwerk für einen bestimmten Blockbereich Parity-Laufwerk. Dadurch werden Lesezugriffe noch schneller.

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 35 -

RAID 0+1


Kombination aus unterschiedlichen RAID-Level

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 36 -

RAID Level 10


Kombination aus unterschiedlichen RAID-Level

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 37 -




© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 38 -



Magnetbandspeichersind abnehmbar und gehen Sturzfolgen immun sind sehr preiswertbieten ihnen die Möglichkeit, all ihre Daten

an einem gesicherten Ort abzulegen bieten fast immer Rückwärtskompatibilität

Magnetbänder sind auch heute noch das beste Medium für einfache und sichere Archivierung

Title > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > 10 > 11 > 12 > 13 > 14 > 15 > 16 > 17 > 18

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 39 -




© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 40 -

A

B

C

A

B

C

Snap 1

Snapshot™ Technologie (NetApp)

– Copy pointers only– No data movement

Blocks in LUN or File

Blocks on the Disk

A

B

C


Take snapshot 1

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 41 -

A

B

C

Snap 1


Blocks on the Disk

A

B

C

A

B

C

B1

B1

Take snapshot 1

Continue writing data– Write data anywhere



© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 42 -

A

B1

C

A

B

C

Snap 1


Blocks on the Disk

B

A

B

C

A

C

B1

B1

Snap 2

A

B

C

Snap 1

Continue writing data

Take snapshot 2– Copy pointers only– No data movement



Take snapshot 1

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 43 -

A

B1

C

Snap 2

A

B

C

Snap 1


Blocks on the Disk

A

B

C

A

B

C


Take snapshot 2

Continue writing data– Write data anywhere

B1

B1

C2

C2



Take snapshot 1

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 44 -

A

B1

C2

Snap 3

A

B1

C

Snap 2


Blocks on the Disk

A

B

C

A

B

C

Continue writing data Take snapshot 2


Take snapshot 3

Simplicity of model =– Best disk utilization– Fastest performance– Unlimited snapshots

B1

B1

C2

C2



Take snapshot 1

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 45 -

Vollständige Integration in Windows Explorer

– seit Windows XP mit ServicePack 2 – Standard in Windows 2003


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 46 -

Einblick in einen SnapShot


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 47 -




© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 48 -

Servercluster

Hochverfügbarkeit & Skalierbarkeit fürFile-, Mail-, Web-, Directory-ServerERP und Datenbankanwendungen

Ausgefeilte Überwachung und Recovery

Schützt gegen jede Art von Ausfällen (System,Applikation, HW/SW-Komponenten)

Unterbrechungsfreier Datenzugriff

Einfache Handhabung: GUIs und Wizards für Installation und BetriebWächst mit den Anforderungen –Erweiterbarkeit im laufenden Betrieb


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 49 -

Clustering- diverse Grundformate und Nutzen

• Failover Cluster active/passive oder active/active Varianten

• HA der Applikation durch Failover keine Dienstunterbrechung,Verfügbarkeit der Daten durch Shared disk-Array, HA der Daten durch Storage-Mirrors

• Nutzen: relative kurze Wiederherstellzeit für Applikation, Dienstebereitschaft abhängig von Datenbereitstellungszeit !!

shared Disk Array


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 50 -


shared Disk Array

Scalable ClusterAnwendung läuft parallel im Cluster, HA durch ParallelitätHA der Applikation durch Resync der Instanzen Keine DiensteunterbrechungShared Data-Lockmanagement, HA der Datendurch Storage- Mirrors

Nutzen: Keine Diensteunterbrechung, da takeover statt failover,aufwändigeres Datenmanagement wegen “shared

data“


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 51 -


Shared Disk Array

Load Balance Cluster Anwendung läuft multiple im Cluster, Lastverteilung auf Clusterknoten, HA der Applikation durch Restart und any-to-any failover sehr geringe Dienstunterbrechung, evtl schlechtere Dienstequalität,

Nutzen: geringe Diensteunterbrechung, Skalierung der Applikationen

Load Dispatcher


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 52 -

FCP, ISCSI, NFS, CIFS, HTTP. FTP

A

A

Speichercluster


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 53 -


B‘

A

A

Speichercluster


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 54 -


A

A

B

B

Speichercluster


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 55 -


A

A

B

B

Speichercluster


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 56 -


A

A

B

B

B‘ A‘

Speichercluster


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 57 -


A

A‘

B

B‘

Speichercluster


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 58 -


A B‘ A‘ B

Speichercluster


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 59 -

Was ist X10sure


x10sure bietet Hochverfügbarkeit für Windows-Server

und -Anwendungen• Bei Serverausfall springt automatisch das

Ersatzsystem ein konsolidiert isolierte Server & Anwendungen

• Server und Speicher sind gemeinsam nutzbar und redundant ausgelegt

Komponenten• Windows / Linux Server• VMware Virtual Machines als Option• FibreCAT & NetApp Storage• x10sure Software

x10sure bietet N:1-Verfügbarkeit und gemeinsam nutzbare Ressourcen

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 60 -

N+1 Verfügbarkeit


SAN-Storage

– x10sure überwacht Server und Speicher

– Bei Ausfall automatischer FAILOVER auf Ersatzsystem

– Speichersystem und Speicherzugriff kann redundant ausgelegt und automatisch wiederhergestellt werden

1

2

3

4

5

6

4

Ersatz Server

Produktiv-Server

Server-Images

2

3

4

5

6

1

Ausfall

x10sure

x10sure bietet dynamische Verfügbarkeit

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 61 -


Phase #1Speicherkonsolidierung

Phase #2Server-Konsolidierung

& -Virtualisierung

Phase #3Überwachung

& Wiederherstellung

– Anwendungs- + Datenkonsolidierung

– Migration der kompletten Software

– “Remote-Boot” aus Zentralspeicher

– TCO-Einsparungen• gemeinsam genutzten

Speicher• mehr Datensicherheit• zentrale, einfachere

Verwaltung

– Konsolidierung + Virtualisierung

– Serverkonsolidierung mit homogenen Formaten

– Virtualisierung für optimale Auslastung + Hardwarereduktion

– Effiziente Nutzung und einfachere Verwaltung der Server

– Dynamic Service Levels

– N:1-HV senkt Investitionen

– Automatische Überwachung & Wiederherstellung

– Ausfallzeit geht runter, Zuverlässigkeit & Produktivität aller Anwendungen rauf

Wertschöpfung

Wie gelangt man durch x10sure zur strukturierten und zuverlässigen IT ?

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 62 -




© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 63 -

• Dezentrale Server Landschaft– Unterschiedliche Server

Modelle– Unterschiedliche Ausstattung

der Server– Dezentrale Datenhaltung

Komplexität und niedrige Effizienz

• Daraus resultierende Probleme– Kaum Synergien beim Handling– Vielfältige Varianten bei OS und

Treibern– Komplexe Sicherungsverfahren

unflexible Skalierbarkeit Überkapazitäten

Hoher Verwaltungsaufwand

Begrenzte Wachstumsmöglichkeiten

Einschränkungen bei HV

Ausgangssituation


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 64 -

– Schlecht ausgelastete Server

– Hohe Komplexität bei Hochverfügbarkeit

– Kaum Flexibilität bei Lastschwankungen

– Keine Dynamik in der Skalierung

Ohne Virtualisierung


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 65 -

Traditionell

Hardware

OS

Application

Virtualisiert

Hardware

OS

Application

Virtualisierung macht Software unabhängig von Hardware

Virtualisierung präsentiert Hardwareresourcen in einer Art, dass man auf diese optimaler zugreifen kann als in ihrer originären Form

Virtualisierung

Virtualisierungsschicht


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 66 -

Mit Virtualisierung


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 67 -

Virtualisierungsprodukte


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 68 -

Zielkalkulation VM ware Host


ΣAnzahl Zielsysteme= NPH • FPH • CPH • ZiellastHost

ΣS für die Summe aller Server

NPS Anzahl Prozessoren des zu konsolidierenden Servers

FPS Taktfrequenz Prozessoren der zu konsolidierenden Server

CPS, CPH CPU Faktor

LastPS gemessene Last der zu konsolidierenden Server

NPH Anzahl Prozessoren Host

FPH Taktfrequenz Prozessoren Host

ZiellastHost kalkulatorische Auslastung

ΣS (NPS • FPS • CPS • LastPS)

CPU Faktor

mono core: 1

dual core: 1,5

dual core LV: 1,25

quad core: 2,5

quad core LV: 1,75

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 69 -

Virtuelle Tape Librarys

Lokale libraries

UNIX W2K / Linux

SAN

Mainframe

Virtual Tape Appliance

ESCON / FC

Cen

tric

Sto

r

Remote libraries

Viele virtuelle Laufwerke

ServerPlattformen

Intelligenz

RealeLaufwerke &

Librariescentricstor_virtueller_rundgang_de.exe


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 70 -

Praxisbeispiele


Bsp. 1 - Kunde mit dezentraler inhomogener IT Infrastruktur

Bsp. 2 - Kunde mit nicht redundanter Infrastruktur

Bsp. 3 - Kunde mit nicht hochverfügbarer Infrastruktur

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 71 -


Beispiel 1 - Ist-Zustand

Standort 3

Hauptstandort

Standort 4

Standort 2

Company Connect 2 Mbit/s

ADSL 2000

ADSL 1000

ADSL 768

Server (4)- R/3 System FI, MM, PP- R/3 Server anKapazitätsgrenze- Datenaustausch- Speditionssystem unterNovell- verschiedene Serverunter verschiedenenBetriebssystem mitverschiedenen Aufgaben

Clients (ca. 45)- verschiedene MSBetriebssysteme- verschiedene MSAnwendungen- vereinzelt CAD-Anwendungen- verschiedene andereAnwendungen

Probleme:- Auswertungen SAP R/3- Austausch von Daten- e-mail Verkehr:abgewickelt über 1&1,Datenaustauscht erfolgt imWesentlichen über e-mail,Sicherheit nichtgewährleistet- Maschinenverwaltung- Beherrschbarkeit- Datenhaltung lokal oderlokal in denNiederlassungen

Server (1)PPS:Fremd PPS

Clients (ca. 4)

Clients (?)Server (1)

Clients (?)Server (1)Fremd PPS

Beispielunternehmen

Auslandsniederlass. 2Auslandsniederlass. 1

Sehr stark heterogenes Netz, sowohl imNetzwerk, Hardware- und Softwarebereich

GeschäftsführungInhaber

VPN Zugang

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 72 -


Beispiel 1 - Ist-Zustand

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 73 -

Beispiel 2 – nr. Infrastruktur


SIGMAChemnitzGmbH

Systemtechnik

Netzwerkstruktur Ist-Stand

FileserverDatensicherung 4 GB Applikationsserver

"Marvin"

WebserverInternetProvider

PC zur Datensicherungbzw.externesFestplattensystem

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 74 -

Beispiel 2 – nr. Infrastruktur


SIGMAChemnitzGmbH

Systemtechnik

Netzwerkstruktur Var. 2

Clusterknoten 1FileserverApplikationsserver "Marvin"ExchangeserverDatensicherung ArcservLTO III Laufwerk

E-Mail ServerWEB-Server

Internet

CITRIXTerminalserverload ballancing

FirewallAntispamAntivir

DMZ

Clusterknoten 2FileserverApplikationsserver "Marvin"Exchangeserver

CITRIXTerminalserverload ballancing

2 x Switch mit UplinkGlasfaser und Leitungsredundanz

2 x Switch mit UplinkGlasfaser und Leitungsredundanz

Storage FC SX 60 Storage FC SX 60

4 GB FCData Duplex Manager

4 GB FCData Duplex Manager

DC 2 DC 1

Serverraum neu Serverstandort vorhanden

Komplette Ausfallsicherheit„Clusterbildung“,2 getrennte Rechenzentren

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 75 -

Bsp. 3 keine HV-Infrastruktur

TX300

FCAT S80

RAID10

7x36GB

TX300

MSCSLP9802 LP9802

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 76 -

Bsp. 3 keine HV-Infrastruktur

ca. 800m

TX300

FCAT S80

FC-Switch (Fabric A)

FC-Switch (Fabric B)

RAID10

7x36GB

TX300

FCAT SX80

RAID10

7x73GB

MSCS

FC-Switch (Fabric B)

FC-Switch (Fabric A)

LP1050 LP1050 LP1050 LP1050

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 77 -

Zusammenfassung


Sicherung der Daten

Sicherung der Applikation

Sicherung des Standortes

Wiederanlauf Kosten

RAID Plattensysteme

Periodische Bandsicherung

Periodische Plattensicherung

Kontinuierliche Sicherung auf Platte

Speichersysteme NAS / SAN

Imaging von Systemen

Applikationscluster

Standby Failover

Virtualisierung

Ausfallrechenzentrum

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 78 -

Zusammenfassung


Sicherung der Daten

Sicherung der Applikation

Sicherung des Standortes

Wiederanlauf Kosten

RAID Plattensysteme ja ja nein Kein Ausfall gering

Periodische Bandsicherung

ja ja ja, wenn Bänder verlagert werden

langsam gering

Periodische Plattensicherung

ja ja ja, über Speichersysteme

mittel gering

Kontinuierliche Sicherung auf Platte

ja nein ja, über Speichersysteme

mittel gering

Speichersysteme NAS / SAN

integrierte Mirroring-Funktion

Ja, mittels Virtualisierung

ja, FC oder Ethernet-connect

schnell hoch

Imaging von Systemen bedingt ja ja, bei Verlagerung der Images

mittel gering

Applikationscluster nein ja ja, FC oder Ethernet-connect

Schnell für Applikationen

mittel

Standby Failover ja ja ja schnell mittel

Virtualisierung ja (Mirroring) Ja (Failover) ja schnell mittel

Ausfallrechenzentrum ja ja ja schnell extrem

© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 79 -

www.sigma-chemnitz.de


© S

IGM

A C

hem

nit

z G

mb

H /

20

08

-01

-30

/ E

rste

ller:

Kott

wit

z, Jörg

; W

olf

. M

ath

ias

- 80 -

Danke für Ihre Aufmerksamkeit


Haben Sie Fragen?Kontakte:SIGMA Chemnitz GmbH SIGMA Software und Consulting GmbHAm Erlenwald 13 Mollenbachstr. 2509128 Chemnitz 71229 LeonbergTel.: 0371/ 2371-0 Tel.: 07152/ 335393-0http://www.sigma-chemnitz.de http://www.sigmagmbh.de

zur letzten seite

Documents