Wie überlebt man ein Disaster?

Transkript

1 Einige Ideen und Ansätze

2 Themenübersicht Disaster auch hier in Österreich? Kundenenvironments wohin geht die Reise? Ideen und Ansätze Lizensierung nicht vergessen!

3 Disaster auch hier in Österreich? Überschwemmungen Zuletzt Mai 2014 Feuer Erdbeben Flugzeugabstürze Vandalismus

4 Kundenenvironments wohin geht die Reise Virtualisierung wird immer weiter verbreitet Kaum ein Unternehmen hat nicht auch Virtualisierung Immer mehr Unternehmen haben großteils virtualisiert Das gilt auch für die großen Unix Lösungen Solaris Zonen/Container, AIX mit HACMP, usw. Storages werden immer smarter Snapshot Technologie ist weit verbreitet Bandbreiten steigen 10 bis 100MBit sind üblich, mehrere Gbitoft problemlos verfügbar Cloud Anbieter immer kreativer Eigene Storage beim Cloud Anbieter, exklusive für einen Kunden

5 Aber. Der Unterhalt von zwei (oder mehr) Rechenzentren ist teuer Liegen diese zu nahe beieinander, schützen diese unter Umständen nicht vor einem Disaster Liegen sie zu weit auseinander, hat man Latenzprobleme Bedeutet Lizensierungsrisiken Oracle hat sehr spezielle Ansichten, was man wie lizensieren muss

6 Einige Ideen und Ansätze Was sind die Kostentreiber Kostentreiber für redundante Systeme in mehreren Rechenzentren aufwändigere Administration höhere / zusätzliche Lizenzkosten Miet- und Betriebskosten für zusätzliche Serverräume Leitungskosten zwischen den Serverräumen

7 Einige Ideen und Ansätze Was wäre wenn Vereinheitlichung der Infrastruktur Alle Systeme virtualisieren Saubere Trennung zwischen Software und Daten Beispiel Datenbank: o OS und Betriebssystem in Vdisk o Datenbank, Archivelog Files und Backups separiert Daten muss man öfter sichern Software seltener Nutzen von möglichst einheitlichen Templates Staging von jeder Software, die installiert wird Zentral nur an einer Stelle automatisierte Dokumentation, was wo installiert ist Ist essentiell, um Lizensierungsthemen zu lösen (Beispiel Oracle)

8 Einige Ideen und Ansätze Was wäre wenn NFS bietet viele Vorteile Direkter Zugriff auf veränderte Dateien auf Storage-Ebene Nutzung von Features wie Deduplication Spart Platz (vor allem beim durchgängigen Nutzen von Templates) Reduziert den Platzbedarf bei Snapshottingund somit Bandbreite für die Replizierung von Snapshots Direktes Speichern von Archivelogs auf Secondary Storage

9 Einige Ideen und Ansätze Nehmen wir das Beispiel Oracle Datenbank & NetApp(1) Operating System und Oracle Software (Template) in Vdisk NFS Verzeichnisse Lokal DBF: Datenbank Files CTRL: Control Files OLOG: Online Logfiles ARCH1: lokale Kopie der Archivelog Files Remote ARCH2: remote Kopie der Archivelog Files

10 Einige Ideen und Ansätze Nehmen wir das Beispiel Oracle Datenbank & NetApp(2) Snapshots der Datenbank Lokal Stündliche Snapshots für schnelles Restore/ Recover Tägliche (oder wöchentliche) Snapshots Remote Tägliche (oder wöchentliche) Snapshots kann man länger aufheben Sicherung: Operating System und Oracle Software Darf man nicht einfach auf das Ziel replizieren, da Oracle sonst gleich verlangt, dass man die zweite Seite lizensiert. Man darf aber Templates bereitliegen haben Mit Hilfe des StagingBereiches und Automatisierung kann man sehr schnell einen Server provisionieren, ohne ein Lizenzvergehen zu begehen.

11 Einige Ideen und Ansätze Nehmen wir das Beispiel Oracle Datenbank & NetApp(3) Die Secondary Storage Einmietung bei einem Anbieter nur Platz Eigene Storage bei einem Anbieter Anbindung Via Internet abgesehen vom initialen Transfer aller Daten reichen hier oft einige 100MBit / wenige GBit

12 Einige Ideen und Ansätze Beispiel Microsoft Active Directory Anmietung eines Servers beim Cloud Anbieter füractivedirectory Replikation Backup des ActiveDirectory direkt beim Cloud Anbieter auf die dortige Storage Dadurch kein zusätzlicher Bandbreitenbedarf für die Replizierung

13 Einige Ideen und Ansätze Beispiel File Shares Zur Erinnerung: Saubere Trennung von Software und Daten Umsetzung Daten direkt auf dem Storage (CIFS) Nutzen der Snapshotting Technologie wie bei den Oracle Datenbanken Vorteile Geringer Bandbreitenbedarf Zusätzlicher Vorteil durch die lokalen Snapshots

14 Lizensierung nicht vergessen Jeder Softwarerherstellerhat andere Lizenzrichtlinien hier betrachten wir das ganze an Hand von Oracle Was ist erlaubt Ein Backup der Datenbank darf auch an beliebige andere Lokationen verbracht werden (auch auf Storage) Jedoch darf es dort keine Möglichkeit geben, ein System zu starten und auf diese Datenbanken zuzugreifen (es darf auch kein stromloser Server herum stehen, sofern dort die Oracle Software installiert ist!) Staging der Oracle Software ist explizit erlaubt Grenzwertig: Auch die Softwareinstallation auf NFS, dann müsste man nur noch ein Template eines Server instanzieren und alles mounten das muss man sich von Oracle explizit absegnen lassen!

15 Vorteile eines solchen Ansatzes Deutliche Reduktion der Kosten, da nur ein Rechenzentrum nötigsowie eine (günstigere) Secondary Storage nötig Administration deutlich einfacher, da man nur die Primärsysteme administrieren muss

16 Nachteil des Ansatzes Kein transparentes Überleben des Ausfalls eines Rechenzentrums Im Disasterfall muss man Beim Cloud Anbieter Systeme anmieten / zahlen Das Rechenzentrum wieder aufbauen Die Daten ins Rechenzentrum übernehmen Die Konfiguration mit dem Cloud Anbieter wieder aufbauen Potentielle Lizensierungsfallen bestehen Man muss dem Anbieter vertrauen, weil ja die Daten bei Fremden liegen rechtliche Themen!

17 Zusammenfassung Hat man noch kein Ausfallrechenzentrum, kann man verhältnismäßig günstig zu einer Disasterlösung kommen Durch die vorgestellten Ansätze kann man die Kosten für Ausfallrechenzentren deutlich reduzieren Im Disasterfall hat man deutlich höhere Aufwände Die hier vorgestellten Ansätze sind sicher nicht für jeden Kunden sinnvoll Die Frage ist: Wie häufig passieren solche Disaster wirklich?

18 Q&A Q & A Wir helfen Ihnen gerne bei der Analyse und einer Machbarkeitsstudie sowie bei Umsetzung und Betrieb.