NetApp NearStre VTL für TSM-Kunden (Tivli Strage Manager) Zusammenfassung zur Kmbinatin TSM und NearStre VTL: TSM ist mit seiner Incremental Frever Lgik ein hervrragendes Backup-Tl, hat aber bei einigen Restreszenarien erheblich mit den technischen Limitatinen vn Physischen Tapes zu kämpfen. Die NearStre VTL bringt hier erhebliche Perfrmancevrteile bei den Przessen Restre, Tape Space-Reclamatin und Cllcatin (letzteres ist verzichtbar). Deduplicatin: TSM-Kunden werden für incremental frever Sicherungen meist einen nur sehr begrenzten Zusatznutzen vn ca 1:1 bis 1,5:1 bei Deduplicatin aller Anbieter erzielen können. Für diesen Teil der Sicherungen wird man daher Deduplicatin ft nicht aktivieren. Die NSVTL ist auch hne Deduplicatin schn sehr sinnvll. TSM-Kunden können die Reife vn Deduplicatin gelassen abwarten und bis dahin die Stärken der VTL für die Incremental Frever Przesse nutzen. Drt w Deduplicatin auch für TSM-Kunden Sinn macht (Datenbank-, NDMPund Image-Backups, ), wird NetApp in Kürze kstenfrei eine Deduplicatin Technik bieten, welche Backups nicht bremst. Über die nachflgend skizzierten Maßnahmen/Effekte werden bestehende TSM-Server erheblich vn bisheriger Last befreit und die Leistungsfähigkeit einer TSM-Landschaft deutlich verbessert. Meist sind die NSVTL Investitinsksten deutlich geringer als in eine nur annähernd s leistungsfähige Diskpl- & PTL-Kmbinatin dies ermöglicht, denn die NearStre VTL erreicht Enterprise-Lesitung mit minimalem Hardwareeinsatz: Unter Anderem spart die im Standard verfügbare sehr schnelle Hardwarecmpressin und die Optimierung auf grße SATA-Disks Ksten. NSVTL Einsatzempfehlungen für Incremental Frever: Gestreute Lese-IOs auf ältere Tapes sind bei TSM-Kunden für die flgenden täglich ablaufenden TSM-Przesse die Regel: "Tape Space-Reclamatin": hierbei werden vm TSM die nch zu haltenden Sicherungsteile vm alten Tape ausgelesen und auf ein neues Tape lückenls umgespeichert. Ziel ist, ältere Tape-Medien wieder für neue Sicherungen frei / überschreibbar zu bekmmen. "Cllcatin": Verstreut gespeicherte Incremental-Sicherungen für ein Quellvlume werden vn vielen Tapes auf ein Tape umgespielt/zusammengefasst, um bei einem möglichen Restre Tape-Lads und Psitinierungszeiten zu sparen. Diese regelmäßig durchgeführten Leseprzesse auf ältere Tapes sind nur bei TSM-Kunden tägliche Praxis und eine Ntwendigkeit. Aufgrund dieser Prblematik sllte unsere NSVTL für TSM-Kunden (heute und in der Zukunft) idealer weise s eingesetzt werden, dass alle Daten eines TSM Tape Pls auf der VTL Platz finden.
Flgende Varianten erscheinen sinnvll: V1) Primary Tape Pl = VTL-nly; Cpy Tape Pl = PTL: Der Primary Tape Pl wird kmplett auf VTL abgebildet und man überlässt TSM (über den Backup Cpy Pl Przess) das Schreiben auf eine physikalische TL (den Cpy Tape Pl) (dies ist die meist verwendete Variante). V2) Primary Tape Pl = VTL-nly; Cpy Tape Pl = VTL-nly: Swhl der Primary Tape Pl als auch der Cpy Tape Pl werden VTL-nly betrieben und man überlässt TSM (über den Backup Cpy Pl Przess) das Schreiben auf den Cpy Tape Pl (dies setzt z.b. die Uni Stuttgart ein). V3) Primary Tape Pl = VTL, welche per VTL-Clning auf eine weitere PTL/VTL repliziert wird: TSM schreibt nur auf den Primary Tape Pl (alles passt auf diese VTL). Statt eines Cpy Tape Pls werden Tapeveränderungen über die Clning-Funktin der NSVTL autmatisch: 3a) auf eine PTL 3b) der auf eine zweite VTL geclned. Diese Zweitkpien werden nur bei einem K-Fall benötigt und können nach dem Anschluss des TSM-Servers direkt verarbeitet werden, da die erstellten Tapes nach dem VTL-Clning den gleichen Aufbau/Barcde haben, wie TSM ihn im Katalg vermerkt hat. Der TSM-Przess "Backup Cpy Pl" ist nicht mehr ntwendig! Im TSM-Katalg sind flglich weniger Einträge vrzuhalten. V4) Primary Tape Pl = VTL-nly; kein zweites Backup-Medium: die NSVTL hat aufgrund der RaidVTL-Technik einen höheren Schutz vr Nichtlesbarkeit als einzelne physikalische Tapemedien. Bei einfachen Verfügbarkeitsanfrderungen kann diese Variante ausreichen. Auch Mischknzepte können sinnvll sein: V4 für geringere, kmbiniert mit V1/V2/V3 für höhere Verfügbarkeitsanfrderungen der Datensicherung. Klassisches Backup über Primary Disk Cache auf PTL für perfrmance-unkritische, aber V1/V2 für perfrmancekritische Datensicherungen. Die Variante V1 dürfte meist verwendet werden. Daher wird im Flgenden vr allem vn dieser Variante ausgegangen.
Typische Vrteile für TSM-Kunden, welche die NearStre VTL einsetzen, sind: Kmpletter der überwiegender Verzicht des Disk-Staging (Primary Disk Pl): Die NSVTL ist dem snst üblichen Diskcache überlegen (Speed, Virensicherheit, Hardwarecmpressin, zukünftig Deduplicatin hne TSM-Serverlast). Stand VTL OS 5.6 macht die parallele Nutzung vn bis zu ca. 90 (davr ca. 50) VTapeDrives je VTL-Head für Backups Sinn (Begrenzung über maxsessins im TSM üblich). Falls diese Menge paralleler TSM-Backups reicht, wird empfhlen den Primary Disk Pl kmplett abzuschaffen. Sllten mehr parallele TSM-Sessins benötigt werden, empfiehlt sich den Primary Disk Pl für die unperfrmantesten und vn der Datenmenge her kleinsten Backups zu benützen. Smit entfällt erhebliche Last beim TSM Migratin Przess (Primary Disk Pl zum Primary Tape Pl). Nur, falls man die Anwendung V3 erwägt: Es sllte bedacht werden, dass abhängig vn der definierten Anzahl der VTapeDrives i.d.r. viele virtuelle Tape beim Backup mit kleinen Datenmengen ergänzt werden. Dies führt dann in der Flge zu einer evtl. störend hhen Anzahl physischer Tape-Ladevrgänge auf PTL-Seite (wenn z.b. 40 VTapes mehr auf PTapes zu clnen sind, dann können z.b. 40 * 3 = 120 Minuten zusätzliche PTL-Lade/Psitinierzeiten anfallen). Cllcatin für auf NearStre VTL gespeicherte Sicherungen ist verzichtbar, da bei einem Restre der Tape Space-Reclamatin jedes VTape nach ca 2 Sekunden geladen und psitiniert ist - als prduktiv arbeitet. Auch das Halten eines Active File Pl auf Primary Disk Pl ist verzichtbar. Tape Space-Reclamatin zeigt sich typischerweise für VTapes erheblich beschleunigt (die Uni Stuttgart hat über mehr als 20 mal schnellere Durchführungszeiten gegenüber den abgelösten PTape-Laufwerken berichtet). Auch stehen mehr VtapeDrives zur Verfügung, um viele Spae-Reclatin Przesse parallel durchführen zu können. Aus diesen Gründen kann Space-Reclamatin deutlich frühzeitiger und häufiger ausgeführt werden (z.b. schn bei einem Füllgrad vn 75%; dies resultiert in einer Verminderung des Medienverschnitts). Grße Restre-Aktinen (sehr viele Files nach Incremental-Frever Sicherungen) werden typischerweise extrem beschleunigt: Aufgrund fast vernachlässigbar kurzer Munt-/Psitinier-Zeiten für die Tapes sind Restres ft um ein Mehrfaches schneller als vn einer PTL. Viel mehr parallele Restre Sessins können parallel anstarten. Die Uni Stuttgart hat für die Wiederherstellung eines zentralen Webservers vn der PTL im Jahr 2004 über 25h benötigt. Der Test im Jahr 2007 nach Umstellung auf die NearStre VTL ergab (trtz inzwischen deutlich gestiegenem Datenumfang und Verzicht vn Cllcatin) eine ca. 20-fach schnellere Laufzeit. Oft macht es auch Sinn, mehrere lgische VTLs innerhalb einer physischen VTL parallel zu nutzen: Man kann mehrere TSM-Server parallel betreiben und/der Über Tape Library Sharing / Strage-Agesnts können mehr LAN-free Backups für perfrmante Applikatins-/DB-Server mit grßen Datenmengen durchgeführt werden, wenn viele VTapeDrives vn der VTL zur Verfügung gestellt werden.
Andere Backup-Szenarien haben grßes Deduplicatin Ptential: Drt, w eine Reihe gleichartiger Backup-Inhalte gehalten wird, sllte der Kstenvrteil vn Deduplicatin genutzt werden: mehrere Fullbackups vn DB-Sicherungen und / der NDMP-Sicherungen Image- und Systempartitin-Backups (hier ist Deduplicatin zu inhaltsgleichen Incremental Frever Sicherungen möglich), TSM Archiv-Sicherungen Was beeinflusst die erzielbare Deduplicatin Rati? Die Anzahl gehaltener Backup-Versinen und die Change-Rate zwischen diesen. Die Anwendbarkeit und Wirkung vn VTL-Kmprimierung: Besnders die hhe Kmprimierbarkeit vn Datenbankenbackups (3:1 bis 5:1 sind dafür typisch) sprechen dafür, dass Deduplicatin mit Hardware- Kmpressin kmbiniert eingesetzt werden sllte. Die NSVTL ist s knstruiert, dass sich die Faktren für Kmprimierung und Deduplicatin multiplizieren. Falls bei einem Kunden eine Kmprimierbarkeit (aufgrund typisch hhem DB-Anteil) vn 3:1 vrliegt und ein Deduplicatin (aufgrund vn ca. 10 Backupgeneratinen) den Faktr 7:1 ermöglicht, resultiert dies dann in einer Gesamtrati vn 21:1. Sehr wichtig ist, dass swhl Kmpressin als auch Deduplicatin die Backups nicht bremsen: Da die hier vrliegenden Backuparten meist hch perfrmanten Nachschub haben (40 120 MB/sec per Stream/Tape sind typischerweise möglich), sllte die eingesetzte Technik einen sehr hhen Durchsatz per Tape bieten. Die NSVTL wird erfahrungsgemäß bei allen Kunden mit aktivierter Hardware- Kmpressin benützt, da dies im Standard enthalten und hch perfrmant ist. Das rate-adaptive Deduplicatin (dynamisches Umschalten vn Inline Dedupe auf Pstprcess Dedupe) verhindert (ab dessen Freigabe), dass Backup-Datenströme durch den Dedupe-Przess gebremst werden. Grße, kstengünstige SATA-Disks sllten einsetzbar sein: Besnders für Backups mit Vrhaltung vieler Generatinen entsteht ein grßer Speicherbedarf. Nur VTLs, welche mit relativ wenig grßen SATA-Diskspindeln eine hhe Perfrmance erzielen, können den günstigen Preis pr TB nutzen.
Die NSVTL bietet hier insgesamt eine ideale Kmbinatin: eine höchst perfrmante Hardwarecmpressin eine hhe Perfrmance auch mit den größten verfügbaren SATA 1000GB Disks ein hervrragendes Deduplicatin-Design: rate-adaptive Deduplicatin: Backups werden nicht gebremst Verify bei Hash-Gleichheit; smit hne Hash Key Cllisin Risik (eine Marktübersicht dazu bietet die Spalte Dedupe Methd in http://www.backupcentral.cm/cmpnents/cm_mambwiki/index.php/ Disk_Targets%2C_currently_shipping kstenfrei (keine Hardware-/Sftware-Ksten) im Rahmen des üblichen Sftware-Wartungsvertrages (ab Verfügbarkeit) durch VTL OS-Upgrade. Perfrmance-Details: Die NSVTL erreicht bei 3:1 kmprimierbaren Daten und nur 28 SATA-Diskspindeln eine Backup-Speed vn 1.100 MB/sec pr VTL300/VTL700- Head (VTL1400 bei dppelt s vielen Disks das Dppelte). Die Speed per VTtape/Stream liegt hier bei 125 MB/sec beim Schreiben und 175 MB/sec beim Lesen. Eine TSM-Serverlast für (ab TSM 6.1 vermutlich für File Pls des Primary Disk Pls mögliches) TSM-eigenes Pstprcess Deduplicatin wird vermieden. Meist wird man mit Deduplicatin mehr Generatinen vn Backups vrhalten können. Eine tabellarische Gegenüberstellung der Vr- und Nachteile möglicher Backup-Medien für den Primary Pl: Primary Disk Pl in Kmbinatin mit physischer Tape Library NetApp NearStre VTL Snstige VTLs getrennt nach Incremental Frever Backups und DB/NDMP/Image-Sicherungen ist bei NetApp Deutschland verfügbar unter: http://web.netapp.cm/~dunterse/dcs/nearstrevtl_und_tsm_d.pdf
Weitere kleine Tipps, welche einen günstigen Einfluss haben: Sfern Sie mehr als einen NearStre VTL-Head einsetzen, sllten Sie die Heads in Datentypen aufteilen (z.b. alle Oracle-DB auf einen Head, alle Windws-Sicherungen in einen Head; alle Unix-Sicherungen in einen Head). Grund: Erhöhung dedupe-rate. Schalten Sie jegliche TSM Client- und DB-Cmpressin aus. Grund: Erhöhung dedupe-rate. Oracle: Falls Sie RMAN s Multiplexing einsetzen sllte, der Default vn 4 auf File seq=1 geändert werden. Dies verhindert ein Zusammenmischen der Datenströme und ermöglicht smit weniger dedupe-overhead und bessere dedupe-ratis. Empfehlungen für die NearStre VTL-Inbetriebnahme (V1) der Testbetrieb in einer bestehende TSM-Landschaft: Virtueller Rbtik-Typ: der ehemals empfhlene Rbtik-Typ Exabyte ist ab TSM 5.5 nicht mehr möglich. W möglich, sllte ab TSM 5.4.3 bzw. TSM 5.5.1 (der späteren TSM-Releases) der Rbtik-Typ NetApp eingestellt werden. In anderen Fällen (insbesndere auch bei Upgrades vn VTL-Bestandskunden auf TSM 5.5 der später) sllte ein VTL-erfahrener NetApp SE knsultiert werden, welcher für den jeweiligen Fall die ptimale Einstellung bzw. das ptimale Vrgehen ermittelt. Zunächst die NSVTL als weiteren Primary Tape Pl installieren und dem TSM-Server bekannt machen. Rules vn ersten TSM-Clients s ändern, dass deren Backup direkt auf diese VTL als Primary Tape Pl durchgeführt wird. Über Mve eine Migratin dieser Daten vn der PTL zur VTL flgen lassen (High- und Lw Treshhld auf 0% setzen). Bebachtung der psitiven Effekte durch die neue Art des Backups. Falls man die VTL wieder aus dem Testbetrieb entfernen will: Rules der Client-Server zurück ändern auf Primary Disk Pl und Primary Tape Pl PTL. Über Mve eine Migratin dieser Daten vn der VTL zur PTL flgen lassen (Highund Lw Treshhld auf 0% setzen). Abbau der VTL, nachdem diese frei vn Backupdaten ist. Falls man dann kmplett vn PTL auf VTL für den Primary Tape Pl umstellen will: Rules der restlichen TSM-Clients s ändern, dass deren Backup direkt auf diese VTL als Primary Tape Pl durchgeführt wird. Über Mve eine Migratin dieser Daten vn der PTL zur VTL flgen lassen (Highund Lw Treshhld auf 0% setzen). Abbau der PTL, nachdem diese frei vn Backupdaten ist der Nutzung zur Erhöhung der Backup Cpy Pl Kapazität. Autr: Dieter Unterseher, Slutins Architect Data Prtectin, NetApp Deutschland, Stand: 5.6.2008