BSI-Vorgaben umsetzen: So spiegeln Sie Rechenzentren über große Entfernungen

Backup- und DR-Strategien für die redundante Sicherung über mehr als 200 km Entfernung
1 Bewertungen
100 %
1
5
5
 
 
 
Bewerten
 
 
 
 
 
 
0 Kommentare  
48 Downloads  
Das BSI hat seine Entfernungsempfehlung für redundante Rechenzentren massiv erhöht. Statt wie bisher 5 km soll die Distanz nun mindestens 200 km betragen. In diesem Whitepaper erfahren Sie, welche Probleme die Umsetzung dieser Empfehlung mit sich bringt, und wie Sie diese lösen können.

Inhalt:

Ende 2018 hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) seine Distanzempfehlung für redundante Rechenzentren massiv erhöht. Statt wie bisher nur 5 km gelten nun 200 km Entfernung als Mindestabstand. Auch wenn diese Vorgabe als „Empfehlung“ bezeichnet wird, ist sie für viele Rechenzentrumsbetreiber bindend, so etwa für Energieversorger, Krankenhäuser und Telekommunikationsanbieter, aber auch für die Öffentliche Verwaltung und alle anderen Unternehmen, die zur „kritischen Infrastruktur“ (KRITIS) gezählt werden.

 

Die BSI-Empfehlung bedeutet unter Umständen nicht nur eine erhebliche Investitionen in neue, weit entfernte Rechenzentren, sie macht auch bisher genutzte Konzepte für Datenspiegelung, Backup und Desaster Recovery obsolet. Eine synchrone Spiegelung, wie sie bei nahe beieinander liegenden Rechenzentren häufig verwendet wird, ist bei diesen Distanzen in der Regel nicht möglich, vor allem wenn Latenz-sensitive Applikationen wie SAP oder SQL-Datenbanken gespiegelt werden sollen.

Dieses Whitepaper zeigt Ihnen, wie Sie mit der Herausforderung umgehen und ein tragfähiges Redundanzkonzept über große Entfernungen hinweg entwickeln. Erfahren Sie unter anderem:

  • Wie Sie von synchroner auf asynchrone Replikation umsteigen, ohne in neue Speichersysteme  investieren zu müssen.
  • Wie Sie bestehende Cluster aufbrechen und in ein Metrocluster mit asynchroner Replikation und Continuous Data Protection (CDP) migrieren.
  • Wie Sie auf ein Cloud-basiertes Replikationsszenario umsteigen.  

 

Originalauszug aus dem Dokument:

Eines der größten Probleme beim Thema BC/DR ist die heutzutage noch immer weit verbreitet Snapshot-Technologie. Zum einen schützen Storage-Snapshots LUNs, nicht aber VMs. Für die Sicherheit der VMs wäre es jedoch besser, Schutz auf VM-Ebene zu gewährleisten, da bei einem Problem eventuell andere VMs von einem Failover auf einem LUN in Mitleidenschaft gezogen würden. Des Weiteren ist es ein Problem, dass man pro VM-Datastore maximal zwei bis

drei aktive Snapshots laufen lassen kann. Bei 200 geschützten VMs wären dies 600 Snapshots. Und da eine RPO von acht bis zwölf Stunden für moderne Unternehmen nicht akzeptabel ist, werden dazu noch Storage-Snapshots erstellt, die nicht nur die Komplexität erhöhen, sondern auch zusätzliche Bandbreite und Speicherplatz verschlingen. Bei einer Anzahl von etwa 200 VMs, die über 200 Kilometer repliziert werden müssen, kann man VMs nicht mehr effektiv mit Snapshots schützen. Hierfür wird eine andere Lösung benötigt, wie etwa journalbasierte Checkpoints, die ein Journaling, ähnlich einer Datenbank bieten, dies aber auf der Ebene des Hypervisors realisieren.