NetApp Tech OnTap
     

Kundenreferenz: Kontinuierliche Datenverfügbarkeit

dank der Kombination von NetApp MetroCluster und V-Series

Es gibt einige Applikationen, für die die Verfügbarkeit entscheidend ist. Bei Energieversorgern im Südwesten der USA müssen einige geschäftskritische Applikationen eine Verfügbarkeit von mindestens 99,999 % besitzen. Durch gesetzliche Bestimmungen ist mein Unternehmen sowie andere dazu verpflichtet, geschäftskritische Applikationen für die Energieversorgung eine Woche pro Quartal von einem anderen Standort aus zu betreiben, um nachzuweisen, dass DR-Funktionen im vollen Umfang betriebsbereit sind.

Vier Monate vor der Implementierung der in diesem Artikel dargestellten NetApp MetroCluster-Lösung ist ein Vorfall eingetreten, durch den unsere geschäftskritische Applikation für über zwei Stunden ausgefallen ist und wir die Daten von vier Stunden verloren haben – ein Horrorszenario. Wir mussten etwas ändern und zwar schnell.

In diesem Artikel werde ich erläutern, wie sich unsere Verfügbarkeitsprobleme durch den Einsatz von MetroCluster und den Systemen der NetApp V-Series beheben ließen, und wir gleichzeitig unsere Investition in das bestehende Storage-System von Hitachi erhalten konnten. Ich werde Details zu unserer Implementierung ansprechen sowie die Erfahrungen erläutern, die wir seit der Implementierung der NetApp Lösung gemacht haben.

In einem späteren Artikel werde ich erläutern, wie wir NetApp und NFS verwenden, um unsere umfangreiche Servervirtualisierungs-Umgebung zu unterstützen, die unter anderem aus VMware und Oracle VM besteht. Bis vor zwanzig Monaten besaßen wir noch keinen NetApp Storage. Heute ist unser NetApp Storage auf nahezu ein halbes Petabyte angewachsen, und es ist noch kein Ende in Sicht.

Warum NetApp MetroCluster und V-Series?

Fünf Jahre lang, bis zur Implementierung von MetroCluster, wurde unsere geschäftskritische Applikation auf einem Windows-Server in einem sicheren Netzwerk ausgeführt. Die Applikation selbst führt Stapelverarbeitungen in einer Datenbank aus und schreibt die Ausgabedateien anschließend in einen lokalen Storage. Auf diese Ausgabedateien wird durch die Benutzer der Applikation zugegriffen.

Es wurde eine Double-Take-Software verwendet, um regelmäßig ein Image dieses Servers zu einem anderen Standort zu replizieren. In einem Idealfallszenario war das Failover von Double-Take nicht wirklich in der Lage, unsere Verfügbarkeitsanforderungen von 99,999 % zu erfüllen. Als der von mir oben erwähnte Ausfall stattgefunden hat, bestand ein Problem mit dem letzten Replikationsdurchlauf, was zu einem noch längeren Ausfall mit deutlichen Datenverlusten geführt hat.

Unser interner Kunde schlug vor, eine Lösung zu implementieren, bei der Applikationsserver in einer dualen Konfiguration auf WebLogic aufsetzen. Dabei sollte ein Applikationsserver am Standort A und ein zweiter Applikationsserver am Standort B, ca. 30 Kilometer entfernt, aufgestellt werden. Im Normalbetrieb würde ein Load Balancer vor den Servern den Workload zwischen beiden Servern aufteilen. (Wir verfügen über eine schnelle WAN-Verbindung zwischen den beiden Standorten, somit würden Anforderungen des Servers an Standort A an den Server an Standort B und umgekehrt kein Problem darstellen.)

Damit dies richtig funktioniert, müssten die Ausgabedateien auf ein freigegebenes Volume geschrieben werden, auf das von beiden Servern zugegriffen werden kann. Wir hatten ca. 15 TB Hitachi SAN-Storage in dieser isolierten und sicheren Applikationsumgebung, Hitachi konnte jedoch keine praktikable Lösung anbieten, die unseren Verfügbarkeitsanforderungen genügt hat. Wir haben uns daher nach NAS Gateways umgesehen.

Wir haben vor Kurzem ein NetApp FAS3070 mit CIFS-Freigaben angeschafft, und wir waren mit seiner Leistung sehr zufrieden. Daher haben wir uns an NetApp gewandt und nach einer hochverfügbaren CIFS-Freigabe gefragt. Schließlich riet uns NetApp zu einer Lösung mit zwei NetApp V-Series Systemen (eines an jedem Standort), die auf unserem bestehenden Hitachi-Storage aufsetzt, sodass diese Laufwerkinvestition erhalten blieb. NetApp MetroCluster ermöglicht ein synchrones Spiegeln zwischen den V-Series Systemen, sodass an beiden Standorten ohne Verzögerung und mit sofortigem Failover auf die gleichen CIFS-Freigaben zugegriffen werden kann. Ohne dass es bei einem Problem zu Datenverlust kommt.

Wir haben uns mehrere andere Technologien von anderen Anbietern angesehen, von denen einige geringere Anschaffungskosten aufwiesen. Deren Back-End-Komplexität und das für diese Lösungen erforderliche Management hätte jedoch zu wesentlich höheren laufenden Kosten geführt.

Einzelheiten zur Bereitstellung

Abbildung 1 bietet einen grundlegenden Überblick über unsere MetroCluster Umgebung.

Abbildung 1) Überblick über die Implementierung von MetroCluster/V-Series

Wie Sie sehen können, ist nahezu alles redundant. Einschließlich der Fibre Channel-Verbindungen zwischen den Standorten, um die größtmögliche Verfügbarkeit zu erzielen. MetroCluster auf den NetApp V3020 Nodes erzeugt ein exaktes Replikat aller freigegebenen Volumes an beiden Standorten. Wir verfügen genau genommen über drei separate Freigaben: eine für die Produktion, eine für die Entwicklung und eine dritte zu Testzwecken.

Die V-Series Systeme ermöglichen uns die Verwendung aller NetApp Funktionen mit unserem vorhandenen Storage – einschließlich MetroCluster. Unsere Hitachi-Storage-Systeme haben bereits den Storage für eine Datenbankkomponente der Applikation bereitgestellt. Da diese Umgebung vom Rest unseres Betriebs isoliert ist, konnten wir den ungenutzten Storage auf den beiden Hitachi-Systemen (15 TB freier Storage auf jedem) nicht zu anderen Zwecken nutzen. Daher war es sinnvoll, diesen für die CIFS-Freigaben (1,5 TB) zu nutzen, anstatt NetApp Storage zu kaufen.

Erste Tests

Um die Konfiguration vor dem Beginn des Produktionsbetriebs zu testen, haben wir zahlreiche Fehler simuliert, einschließlich Trennung der Stromversorgung an einem der Storage Nodes, Trennung der Netzwerk- und Fibre Channel-Verbindungen, Abschaltung eines der beiden Cisco Directors usw. Das Failover-Verhalten erfolgte unverzüglich und in allen Fällen fehlerfrei. Wir haben auch die manuellen Failover-Fähigkeiten getestet, um Standort B anstelle von Standort A als primären Standort festzulegen. Wie erwähnt, müssen wir diesen Wechsel mindestens einmal im Quartal vornehmen. Bei keinem unserer Tests ist ein einziges Problem aufgetreten. Alles funktionierte erwartungsgemäß ohne Probleme.

Bisher erzielte Ergebnisse

Seit der Installation der MetroCluster Konfiguration sind keinerlei Probleme aufgetreten. Die Fibre Channel-Verbindungen zwischen den Standorten wurden aufgrund von planmäßigen Wartungen getrennt, und MetroCluster hat sich immer ohne Eingriff selbstständig neu synchronisiert. Wir erhalten eine E-Mail von MetroCluster, die uns darüber informiert, dass die Verbindung getrennt wurde. Wenn sie wieder verfügbar ist, erhalten wir eine weitere Benachrichtigung, dass die Verbindung hergestellt ist, und dass sich MetroCluster neu synchronisiert.

Zusätzlich zur Unterstützung von MetroCluster ermöglichen uns die V-Series Systeme die Nutzung weiterer NetApp Funktionen mit unserem Hitachi-Laufwerk-Storage, wie beispielsweise Snapshots. Unsere Backup- und Recovery-Strategie für unsere gesamte IT-Infrastruktur (nicht nur MetroCluster) zielt auf einen Wechsel von Magnetband zu Online-Backups. Aus diesem Grund erstellen wir regelmäßige Snapshot-Kopien von unseren MetroCluster Freigaben. Das synchrone Spiegeln liefert Snapshot-Kopien auf beiden Standorten, die zur Verfügung stehen, wenn nach irgendeinem Fehler ein Recovery erforderlich sein sollte. Außerhalb der MetroCluster Konfiguration verwenden wir SnapMirror für ähnliche Backup- und DR-Funktionen für weniger kritische Applikationen, wenn eine asynchrone Replikation zweckmäßig ist.

Gesammelte Erfahrungen

Das einzige Problem, das während der Installation von MetroCluster aufgetreten ist, lag darin begründet, dass wir zu Beginn unsere bestehende Fibre Channel-Verbindung zwischen den beiden Standorten nicht in vollem Umfang verstanden haben. Wir haben dieses Netzwerk „geerbt“, und wir verfügten nicht über zuverlässige Daten zu seiner Konfiguration. Schließlich mussten wir während des Betriebs lernen, wie dieses Netzwerk konfiguriert war und verloren wertvolle Zeit.

Meine Empfehlung für alle, die eine MetroCluster Implementierung vornehmen, lautet, zu Beginn mit NetApp eine vollständige Bewertung vorzunehmen, um die Besonderheiten festzustellen und die Konfiguration zu überprüfen. Einige der Informationen, die wir NetApp zu Beginn zur Verfügung gestellt haben, waren nicht vollkommen richtig, was zu Implementierungsverzögerungen geführt hat. Nach meiner Einschätzung hätte eine Inanspruchnahme von Professional Services vor dem Kauf die Implementierung wesentlich reibungsloser vonstatten gehen lassen, was sich im Nachhinein als gute Investition erwiesen hätte.

Schlussfolgerung

Technologie von NetApp hat uns ermöglicht, mit unserer gesamten IT-Infrastruktur einen sehr produktiven Weg für das gesamte Unternehmen einzuschlagen. Heute wird unser gesamter NetApp Storage von 480 TB von einem einzigen Vollzeitmitarbeiter gemanagt. Die Wartungsverträge für den Hitachi-Storage in unserer MetroCluster Konfiguration stehen zurzeit zur Verlängerung an, und wir überlegen, dieses teure System durch zwei zusätzliche NetApp Cluster zu ersetzen, um den Storage für das Datenbank-Back-End der Applikation bereitzustellen. Wir werden unseren vorhandenen V-Series Cluster mit Platten-Shelves erweitern, um den Storage für die mit dem MetroCluster gespiegelten CIFS-Freigaben zu nutzen.

Wir überlegen auch, für unsere MetroCluster Freigaben Deduplizierung zu implementieren. Wir verwenden Deduplizierung im Rest unserer Umgebung, was zu Einsparungen von bis zu 90 % bei Servervirtualisierungs-Umgebungen, von 35 % bei nicht-MetroCluster CIFS-Freigaben und von 60-65 % bei NFS-Freigaben führt. Es muss nicht besonders betont werden, dass bei jeder Datenspiegelung die Verringerung der zu speichernden Daten zu großen Storage-Einsparungen führt sowie zu Einsparungen bei der Bandbreite, die notwendig ist, um diese Daten zwischen den Standorten zu spiegeln.

Langfristig planen wir einen dritten DR-Standort in einer Entfernung von mindestens 150 Meilen. Mit dieser Konfiguration müsste MetroCluster eine kontinuierliche Datenverfügbarkeit bereitstellen sowie eine dritte SnapMirror Kopie der Daten am dritten Standort, um ein vollständiges Disaster Recovery zu ermöglichen, wenn sowohl am primären als auch am sekundären Standort ein lokaler Ausfall auftritt. Dies entspricht den NetApp Best Practices für geschäftskritische Applikationen.

Ihre Meinung zu MetroCluster

Stellen Sie Fragen, tauschen Sie Ideen aus, und teilen Sie Ihre Meinung mit der NetApp Online Community!

Joshua Konkle

Dave Larson
Supervisor of Infrastructure Architecture

Vor dem Wechsel zu seinem gegenwärtigen Arbeitgeber vor sieben Jahren war Dave in mehreren IT-Positionen bei Digital Equipment Corporation und anderen Unternehmen beschäftigt. Dabei sammelte er umfangreiche Erfahrungen mit Storage von führenden Anbietern wie EMC, Hitachi und HP StorageWorks. In seiner gegenwärtigen Position leitet er die Teams für SAN, UNIX und Oracle Database, was ihm einzigartige und umfangreiche Perspektiven für die Herausforderungen von IT-Infrastrukturen ermöglicht.

 
Weitere Infos hier