NetApp Tech OnTap
     

Kundenreferenz: National Semiconductor maximiert Storage-Effizienz mit NetApp V-Series

Wie die meisten Storage-Teams waren wir auch bei National Semiconductor in den letzten Jahren mit der Konsolidierung von Storage beschäftigt, um ein Maximum an Effizienz zu erzielen. Eine absolute Notwendigkeit, wenn der implementierte Storage um 50 % oder mehr pro Jahr wächst (wie das bei uns der Fall ist). Da wir über separate NAS- und SAN-Systeme und damit zwei getrennte Speicherpools verfügen, ließ sich jedoch ein gewisses Maß an Ineffizienz nicht vermeiden.

Mit den Storage-Virtualisierungssystemen der NetApp® V-Series konnten wir dieses Problem letztendlich lösen und Multiprotokollzugriff auf unseren EMC SAN Storage bieten. Vor Kurzem haben wir zwei ältere, geleaste NetApp FAS960 Systeme gegen Systeme der V-Series, die auf vorhandenem SAN Storage aufsetzen, ausgetauscht und damit unsere Kosten um 50 % gesenkt.

Themen dieses Artikels:

  • Bewertung von NAS Gateways
  • Gründe für NetApp V-Series
  • Von uns eingesetztes Verfahren zur Datenmigration auf die V-Series
  • Zusätzliche Effizienzsteigerung dank Thin Provisioning, Deduplizierung usw.
  • Pläne für die Zukunft

Bewertung von NAS Gateways

Seit wir vor einiger Zeit zu der Erkenntnis gekommen sind, dass nicht alle Daten auf teuren Fibre Channel-Festplatten gespeichert werden müssen, haben wir die Vorteile von Tiered Storage entdeckt. National hat große Mengen an SATA Storage auf EMC DMX-3 Storage-Systemen erworben und fast überall Tier 3 LUNs eingeführt. Da wir diesen Storage nur mit SAN verwenden konnten, zogen wir NAS Gateways als eine Möglichkeit zur besseren Nutzung dieses Speicherpools in Betracht.

Zur Prüfung unseres Konzepts griffen wir zunächst auf ein NAS Gateway eines anderen Herstellers zurück, stießen aber schnell auf eine Reihe von Einschränkungen:

  • Das Gateway verfügte nur über zwei Fibre Channel-Ports, sodass wir unsere Tape Library nicht mehr anschließen konnten.
  • Das Gerät war nicht für unsere Backup Software, Tivoli Storage Manager, zertifiziert.
  • CIFS war unzulänglich implementiert, und es gab keinen Support für CIFS.

Zu diesem Zeitpunkt besaßen wir zwei in einem MetroCluster eingebundene NetApp FAS960 Storage-Systeme, die für CIFS konfiguriert waren und langsam an die Grenzen ihrer Speicherkapazität stießen. In Gesprächen mit NetApp sind wir zu dem Schluss gekommen, dass wir die vorhandenen FAS960 Systeme durch zwei V3040 Systeme ersetzen und dem bereits erworbenen SAN Storage als Front-End vorschalten könnten. Damit würden wir nicht nur unsere Storage-Umgebung vereinfachen, sondern auch Kosten sparen. Es gelang uns, die gesamte Beschaffung, Installation und Migration in weniger als zwei Monaten durchzuführen.

Momentan sind bei uns zwei V-Series Systeme im Einsatz. In Santa Clara dient ein V3040 Cluster als Front-End für ein EMC DMX-3. An unserem DR-Standort in Sacramento ist ein einziger V3040 Controller einem weiteren EMC DMX-3 vorgeschaltet. Das System in Santa Clara fungiert als Front-End für 42 TB EMC Storage. Die EMC Systeme bieten weiter direkten, blockbasierten Zugriff auf andere Systeme, die ebenfalls an unser SAN angebunden sind.

V-Series Storage-Infrastruktur von National Semiconductor

Abbildung 1: V-Series Storage-Infrastruktur von National Semiconductor

Gründe für NetApp V-Series

Dass wir den V-Series Systemen gegenüber Konkurrenzprodukten letztendlich den Vorzug gaben und unsere vorhandenen Systemen nicht einfach um Storage erweitert haben, hat verschiedene Gründe:

  • Da wir nicht ausgelastete EMC SATA Festplatten im Back-End nutzen konnten, beliefen sich die Kosten für die Implementierung der V-Series auf die Hälfte des Leasingbetrags für die FAS960 Systeme.
  • Durch den Einsatz der V-Series Systeme als Front-End für unseren vorhandenen SAN Storage erhalten wir einen einzigen Speicherpool und damit eine flexiblere Storage-Umgebung.
  • Da wir schon seit Jahren NetApp Storage einsetzen, unterhalten wir ausgezeichnete Beziehungen zu NetApp und sind mit dem Data ONTAP® Betriebssystem und den zusätzlichen Vorteilen, die NetApp in Sachen Storage-Effizienz bietet, bestens vertraut. (Siehe Abschnitt zur gesteigerten Storage-Effizienz weiter unten.) Damit war unsere Entscheidung nahezu risikofrei – wir wussten, was auf uns zukommt und dass NetApp dahintersteht.
  • Der Migrationsprozess ging einfach und ohne Komplikationen vonstatten. Unsere Arkivio Archive blieben intakt, sodass keine besonderen Maßnahmen für unsere Archivierungsumgebung erforderlich waren.

Migration auf NetApp V-Series

Für die Migration kam die SnapMirror® Software von NetApp zum Einsatz. Damit war es uns möglich, die Migration völlig transparent für unsere Endbenutzer durchzuführen und die Downtime auf ein Minimum zu reduzieren. Wenn unsere Wahl auf einen anderen Anbieter gefallen wäre, hätten wir sicherlich mit einer längeren Ausfallzeit rechnen müssen.

Zur Durchführung der Migration haben wir einfach SnapMirror Beziehungen zwischen den vorhandenen FAS960 Systemen und dem V3040 Cluster erstellt. Nachdem die Daten vollständig gespiegelt und auf dem letzten Stand waren, konnten wir die Umstellung in einer geplanten Downtime von zwei Stunden vollziehen. Wir haben die FAS960 Systeme heruntergefahren, die IP-Adressen auf dem V3040 Cluster in die IP-Adressen der alten Systeme geändert und dann einen Neustart durchgeführt. Auf den Client-Systemen waren keine Änderungen erforderlich. Die Clients haben von der Umstellung nichts bemerkt.

Zu den auf den FAS960 Systemen gespeicherten Daten gehörten eine Reihe von Datenarchiven, die mit Arkivio erstellt wurden. Wäre die Wahl auf das Gateway eines anderen Herstellers gefallen, hätten all diese Daten aus dem Archiv-Storage in die Quelle zurückgeschrieben werden müssen. Da Arkivio aber bereits für die Ausführung mit NetApp eingerichtet war, entfiel dieser zeitaufwändige Schritt.

Verbesserte Storage-Effizienz

Obwohl der Back-End Storage nun auf unseren EMC DMX Systemen angesiedelt ist, können wir dank der NetApp V-Series von den bewährten NetApp Technologien zur Steigerung der Storage-Effizienz wie NetApp FlexVol®, Snapshot™, Thin Provisioning und Deduplizierung profitieren.

Die flexiblen Volumes von NetApp ermöglichen uns, den zugrunde liegenden Speicherplatz optimal zu nutzen, indem die Daten auf alle verfügbaren Spindeln verteilt und damit automatisch Engpässe vermieden werden. Infolgedessen liegt die Auslastung unserer V-Series File-Systeme derzeit bei etwa 80 %, was im Vergleich zum branchenüblichen Durchschnitt von 25 bis 40 % äußerst positiv abschneidet.

Wir setzen die V-Series Systeme für eine Vielzahl von Zwecken ein, beispielsweise für Engineering-Daten aus unseren Cadence und Synopsys Applikationen sowie das File Storage für Home und Group Directories unserer Geschäftsanwender. Seit Kurzem führen wir die NetApp Deduplizierung auf einigen unserer Volumes für Engineering-Archive aus. Dank dieser Funktionalität, die auf dem Back-End Storage von EMC nicht als native Funktion verfügbar ist, können wir insgesamt 1,8 TB Speicherplatz einsparen, was pro Volume durchschnittlich 34 % ausmacht. Bei diesen deduplizierten Volumes erreichen wir eine Auslastung von 112 %. (Mit Ausnahme eines Volumes überschreitet die genutzte Kapazität plus die durch Deduplizierung eingesparte Kapazität bei den restlichen Volumes die Gesamtgröße des Volumes.) Da es sich offensichtlich lohnt, werden wir die Deduplizierung in Zukunft auch bei anderen Storage Volumes anwenden.

Einsparungen durch Deduplizierung

Abbildung 2: Einsparungen durch Deduplizierung

Einen weiteren Effizienzgewinn stellt das Disaster Recovery dar, das mit den V-Series Systemen praktisch umsonst implementiert wurde. An unserem DR-Standort war bereits ein EMC DMX-3 Storage-System in Betrieb, das DR-Storage für geschäftskritische Systeme bereitstellte. Durch die Implementierung eines V3040 an diesem Standort können wir nun mithilfe von NetApp SnapMirror Online-DR für geschäftskritische NAS Daten bieten. Dies war vormals nicht möglich.

Zukünftige Projekte: SnapVault und FlexClone

Nachdem wir jetzt die V-Series Systeme eingebunden haben und über einen einzigen, großen Back-End-Speicherpool verfügen, erschließen sich immer mehr Einsatzmöglichkeiten für diese Systeme. Hier ein Beispiel: National Semiconductor besitzt ungefähr 20 Remote Design Center (RDCs), die sich auf USA, Europa und Asien verteilen. In diesen Centern kommt eine beträchtliche Menge an geistigem Eigentum zusammen, das wir gerne besser schützen würden.

Da wir in unseren RDCs standardmäßig NetApp Storage einsetzen, beabsichtigen wir nun, jedes dieser Systeme um die NetApp SnapVault® Software zu erweitern. Somit können wir die Storage-Systeme über unsere Firmennetzwerke auf unsere V-Series Systeme sichern. SnapVault sorgt dabei für Effizienz, da nur die geänderten Datenblöcke übertragen werden, was Netzwerkbandbreite einspart und den von jedem Backup belegten Speicherplatz drastisch reduziert. Wir haben diesen Prozess bereits in fünf oder sechs RDCs mit sehr zufriedenstellenden Ergebnissen implementiert.

Ein weiteres Projekt, dass wir derzeit in Angriff nehmen, ist der Einsatz von NetApp FlexClone® in Kombination mit unserer VMware® Umgebung. Wenn Sie ein FlexClone Volume erstellen, wird nur dann zusätzlicher Speicherplatz benötigt, wenn am Klon-Volume Änderungen vorgenommen werden. Ein Klon lässt sich sehr schnell erstellen und ist äußerst platzsparend. Die Anzahl der Instanzen von Microsoft® Windows® Betriebsumgebungen, die in Virtual Machines ausgeführt werden, geht bei uns in die Hunderte. Diese größtenteils identischen Umgebungen belegen große Mengen an Storage, und die Zeit, die zur Bereitstellung einer neuen Virtual Machine benötigt wird, richtet sich nach der Zeit, die das Erstellen einer Kopie des gesamten Betriebssystems in Anspruch nimmt.

Im Rahmen eines Pilotprojekts haben wir jüngst unter Verwendung von VMware VDI (Virtual Desktop Infrastructure) und verschiedenen Desktop-Systemen getestet, inwieweit der Einsatz von FlexClone zum Klonen von virtuellen Betriebsumgebungen statt der Verwendung separater Kopien für jedes System durchführbar ist. In dieser begrenzten Umgebung traten keinerlei Probleme auf. Nachdem wir uns einen besseren Überblick über die Menge der Virtual Machines verschafft haben, die sich über ein einziges geklontes Volume ausführen lassen, werden wir dieses Projekt definitiv vorantreiben. [Dieser Ansatz wurde bereits ausführlicher in verschiedenen früheren Tech OnTap Artikeln beschrieben, darunter in den Artikeln zum NetApp Kilo Client und zu einer Implementierung an der North Carolina State University.]

Schlussfolgerung

Alles in allem verlief diese V-Series Implementierung äußerst erfolgreich. Nachdem wir weniger als zwei Monate für die Umstellung benötigt haben, profitieren wir nun von einer flexibleren Umgebung mit einem einzigen Speicherpool für NAS und SAN, der unsere skalierbare Storage-Einheit für die SAN Infrastruktur optimal nutzt. Unserem Management fiel die Umstellung erst im Nachhinein auf, da der Wechsel unsere Ausführungsrate für diesen Storage sogar um 50 % reduziert hat. Dass das Management mit dem Ergebnis zufrieden war, versteht sich von selbst.

Ihre Meinung zur V-Series?

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

Anthony Villegas und Tien Tran

Anthony M. Villegas
Enterprise Storage Team Management Lead
National Semiconductor

Anthony (links) hat seine 30-jährige Laufbahn im IT-Sektor ausschließlich bei National Semiconductor verbracht. Zunächst mit der Systemprogrammierung für IBM Mainframes betraut, wechselte er später in den Bereich Open Systems und Storage-Administration. Derzeit ist er für Konzeption, Design, Implementierung und Management von Enterprise Storage verantwortlich, einschließlich SAN, NAS, Backup, DR und Bereitstellung.

 

Tien Tran
Enterprise Storage Administrator
National Semiconductor

Tien (rechts) ist seit elf Jahren in der IT-Abteilung von National Semiconductor tätig (und damit quasi ein Neuling). Neben der Administration von Storage-Einheiten, zu denen auch VTLs gehören, ist er für EDA-Tools wie Cadence und Synopsys zuständig. Während seiner 15 Berufsjahre im IT-Sektor war er außerdem bei LSI, Sun Microsystems und Pacific Bell beschäftigt.

Weitere Infos hier