Xsan-Setup - optimale Einstellungen für verschiedene Videoformate

Dienstag, 13 September 2005
0.0/5 Bewertung (0 Stimmen)
Beschreibung

Wenn Sie sich für Apples zentrale Speicherlösung Xsan interessieren oder bereits damit arbeiten, dann wissen Sie, dass es unheimlich schwer ist, konkrete Zahlen zur Leistungsfähigkeit des Systems zu erhalten.
Je nachdem mit welchen Dateiarten Sie arbeiten, erzielen verschiedene Xsan-Topologien und Kombinationen aus Blockgröße und Streifenbreite des Xsan-Dateisystems ganz unterschiedliche Ergebnisse.
Obwohl einige Unternehmen bereits Erfahrungen mit unterschiedlichen Einstellungen gesammelt haben, gibt es kaum öffentlich abrufbare Zahlen hierzu. Mit diesem Artikel möchte ich versuchen, ein wenig Licht ins Dunkel der Xsan-Settings zu bringen.
Ich habe im Rahmen der MacEXPO Köln, auf der Björn Adamski und ich eine Xsan-basierte Videoumgebung vorgestellt haben (www.andre-aulich.de/perm/xsan-im-video-server-pro-lab), zahlreiche Tests zu optimalen Einstellungen durchgeführt, desweiteren bot mir mein Kooperationsparter Mediatec hier in Köln die Gelegenheit, drei Tage lang ein System, das zuvor auf der Tour de France zum Einsatz kam, als Grundlage für weitere Tests zu verwenden. Vielen Dank auch an dieser Stelle für die Unterstützung!
Darüber hinaus haben die Erfahrungen mit verschiedenen Xsan-Installationen bei meinen Kunden ebenfalls Einfluss auf diesen Artikel, so dass die hier genannten Angaben direkt meine Erfahrungen aus der Praxis widerspiegeln.
Da diese Informationen nur einen kleinen Aspekt einer Xsan-Installation betreffen, können Sie mich bei weiteren Fragen rund um Xsan sehr gerne auch über mein Feedback-Formular erreichen.
Zunächst möchte ich Ihnen die Tests vorstellen, die ich bei der Firma Mediatec durchgeführt habe:
[size=”2”]Verwendete Hard-/Software[/size]
[list]

  • 1 x Xserve RAID 14 x 180 GB
    statische IPs, 1 Controller 6 HDs RAID Level 5, 1 x Spare,
    1 Controller 2 HDs RAID Level 1

  • 1 x Xserve RAID 14 x 400 GB
    statische IPs, beide Controller: je 6 HDs RAID Level 5, 1 x Spare
  • Emulex Fiber Channel Switch 355
  • GigaBit-Ethernet
  • Power Mac G5 als Xsan-Client
    Dual 2,7 GHz G5
    3,5 GB RAM
    Mac OS X 10.4.2
    Xsan 1.1 Build M28
    250 GB HD
    Apple Fiber Channel-Karte
    Blackmagic DeckLink HD-Karte
  • Xserve G5 Cluster Node als Metadaten-Controller
    Dual 2,3 GHz G5
    3,5 GB RAM
    Mac OS X Server 10.4.2
    Xsan 1.1 Build M28
    80 GB HD
    Apple Fiber Channel-Karte
  • Fibre Channel komplett Kupferkabel (die mit der Apple-Karte mitgelieferten)
  • geswitchtes GigaBit-Ethernet dediziert für Metadaten
  • Xsan-Volume auf Client und MDC gemountet
  • Test-Tool: Blackmagic Disk Speed Test, Version 5.0
    [size=”2”]Topologie[/size]
    Ich hatte wie oben bereits erwähnt zwei Xserve RAIDs zur Verfügung. Da die Metadaten laut Apple dediziert auf einem Controller abgelegt werden sollen, ist die empfohlene Konfiguration laut Apple bei zwei Xserve RAIDs einen Controller des einen RAIDs so einzurichten, dass zwei Festplatten gespiegelt werden und ausschließlich zur Ablage von Metadaten dienen. Die anderen drei Controller können für maximale Performance zu einem auf RAID Level 5 basierenden Storage Pool zusammengefasst werden, der zur Speicherung der eigentlichen Daten dient.
    Da bei ein oder zwei RAIDs viele Kunden nicht auf die Speicherkapazität einer Xserve-RAID-Hälfte verzichten wollen, legen viele Anwender die Metadaten gemeinsam mit den eigentlichen Daten verteilt auf alle Xserve RAID-Controller ab. Ich habe zahlreiche Tests durchgeführt, um zu testen, ob dies tatsächlich mit Performance-Einbußen verbunden ist, wie Apple darstellt.
    In meinen Tests zeigte sich, dass bei bis zu zwei Xserve RAIDs die Performance mit dediziertem Xserve RAID-Controller für Metadaten vergleichbar mit der Leistung bei auf alle Xserve RAID-Controller verteilten Metadaten ist. Dies bedeutet also, dass in meinen Tests ein Storage-Pool über alle RAIDs für Metadaten und Anwenderdaten ebenso schnell ist wie die von Apple empfohlene Trennung der Metadaten. Mit dem Vorteil, dass Sie auf diese Weise die gesamte Kapazität der ein oder zwei Xserve RAIDs für Anwenderdaten verwenden können.
    Allerdings ist dazu einschränkend zu sagen, dass all meine Tests mit verschiedenen Videoformaten durchgeführt wurden, die von maximal fünf Clients gelesen und geschrieben wurden. Wenn Sie in der Praxis mit mehr Clients oder mit sehr vielen, sehr kleinen Daten arbeiten, kann es sein, dass diese Ergebnisse nicht auf Ihr Setup übertragbar sind.
    HINWEIS: Es gibt Umgebungen, in denen die Metadaten auf die internen Festplatten eines Xserves geschrieben werden. Von diesem Setup ist unbedingt abzuraten, da dadurch kein Failover auf einen zweiten Server möglich ist. Xsan sollte immer mit einem Backup-Metadaten-Controller geplant werden, um bei Systemausfällen oder (was öfter vorkommen kann) -aktualisierungen problemlos weiterarbeiten zu können.
    Zurück zur Speicherung der Metadaten: Wenn Sie mehr als zwei Xserve RAIDs verwenden, sollten Sie unbedingt einen Controller eines Xserve RAIDs für Metadaten reservieren. Wenn es irgendwie möglich ist, würde ich dies bereits ab zwei Xserve RAIDs empfehlen, da die dedizierte Metadatenspeicherung vergleichbar schnell wie die verteilte Speicherung ist und darüber hinaus später einfacher erweiterbar ist ohne das gesamte Xsan neu gestalten zu müssen.
    (Dies gilt allerdings auch nicht für alle Anforderungen.)
    Aktivieren Sie auf den Xserve RAIDs den Lese- und Schreibcache (dann aber unbedingt die Backup-Batteriemodule einbauen, um im Falle eines Stromausfalles keine Daten zu verlieren!), die anderen Einstellungen zur Cache-Optimierung können Sie in den Standardeinstellungen belassen, da jede Änderung in der Regel die Leistung des Xsan herabsenkt.
    [size=”2”]Test-Ablauf[/size]
    Ich habe jeweils die in der folgenden Tabelle beschriebenen Einstellungen vorgenommen, das Xsan-Volume auf dem Client gemountet, das Test-Programm darauf gespeichert und anschließend den Test ablaufen lassen.
    Um die nächste Einstellung zu testen, habe ich das Volume ungemountet und gestoppt, woraufhin sich die Kombination aus Blockgröße und Streifenbreite des bestehenden Xsan-Volumes ändern lässt. Achten Sie darauf, dass dadurch das Volume neu initialisiert werden muss und alle Daten gelöscht werden.
    Daher sollten Sie bereits vor Produktionseinsatz die optimalen Einstellungen für Ihr Xsan gefunden haben, um später für Einstellungsänderungen nicht alle Daten löschen zu müssen.
    [size=”2”]Testergebnisse[/size]
    Hier sind nun endlich die Testergebnisse (Ein Klick auf die Grafik zeigt Ihnen eine größere PDF-Version des Tests an):

    Hier eine grafische Darstellung der Setups.
    [size=”2”]Setup 1[/size]


    In diesem Setup nehmen die zwei rotmarkierten, als RAID-Level 1 gespiegelten Festplatten des ersten Controllers die Metadaten/Journalingdaten des Xsan-Volumes auf.
    Die Controller 2 bis 4 sind jeweils als RAID 5 konfiguriert und zu einem Daten-Storage-Pool zusammengefasst.
    In diesem Setup ist zu beachten, dass die beiden LUNs des unteren Xserve RAIDs nicht in voller Größe zur Verfügung stehen, da im oberen Xserve RAID kleinere Festplatten verbaut sind. In der Praxis ist darauf zu achten, dass alle LUNs eines Storage-Pools dieselbe Größe haben, um die volle Kapazität ausnutzen zu können.
    Da es in diesem Test um Performance ging und in der Praxis üblicherweise gleich ausgestattete Xserve RAIDs zum Einsatz kommen, wurde dieses Setup dennoch wie beschrieben gewählt.
    Die Topologie ist bereits sehr effektiv, jedoch ist die Blockgröße von 4 KB weder für Schreib- noch für Lesevorgänge optimal.
    [size=”2”]Setup 2[/size]


    Dieses Setup unterscheidet sich von Setup 1 dadurch, dass vier Festplatten des ersten Controllers zu einem RAID-Level 5-LUN zusammengefasst wurden und mit den anderen blau gefärbten Festplatten zu einem Daten-Storage-Pool zusammengefasst wurden.
    Dies wird in der Praxis so nicht gemacht, da dadurch pro Controller lediglich die Größe eines LUNs mit vier Festplatten angesprochen wird, so dass Sie auf diese Weise sehr viel Platz verlieren. Für diesen Test wurde dieses Setup gewählt, um die maximale Performance auch dieses Setups herauszufinden.
    Wollen Sie außer den zwei Festplatten für Metadaten auch weitere Festplatten des ersten Controllers für Ihr Xsan-Volume verwenden, so bietet es sich eher an, diese vier Festplatten zu einem zweiten Daten-Storage-Pool zu machen.
    Schreiben Sie dann neue Daten, so werden diese auf beide Storage-Pools verteilt. Unser Test-Tool hat jedoch alle Daten immer nur auf den ersten Daten-Storage-Pool geschrieben, da ein einzelner Schreibvorgang innerhalb eines Storage-Pools bleibt, erst der nächste Vorgang benutzt den zweiten Pool.
    Da der Daten-Storage-Pool auf dem ersten Controller auch nur über einen Controller erreicht werden kann, bietet es sich eher an, hier nicht allzu Performance-relevante Daten abzulegen.
    HINWEIS: Im Peachpit Press-Buch “Xsan Quick-Reference Guide” wird an vielen Stellen empfohlen, dedizierte Storage-Pools für Audio-, Render- und Videodateien anzulegen. Innerhalb eines Xsan-Volumes können Sie keine unterschiedlichen Blockgrößen/Streifenbreiten-Kombinationen pro Storage-Pool festlegen, so dass eine Optimierung für unterschiedliche Anwendungen pro Pool dadurch nicht möglich ist. Da ansonsten die Geschwindigkeit des Xsan dadurch entsteht, dass alle Daten über möglichst viele Controller verteilt werden, scheint es mir daher wesentlich sinnvoller, alle Daten außer Metadaten in einen einzigen großen Storage-Pool zu schreiben - die althergebrachte Trennung von Audio und Video stammt noch aus Zeiten, wo eine einzelne Festplatte neben zwei SD-Streams keine Audiospuren mehr ablegen konnte. Bei Xsan ist das mittlerweile anders.
    Die einzige wirkliche Verbesserung ist dann möglich, wenn Sie für Audiodaten ein zweites Volume anlegen, das von den Einstellungen her für Audio optimiert ist, während die Einstellungen des anderen Volumes für Video optimiert sind. Dabei ist jedoch zu beachten, dass sich die Einstellungen nur geringfügig unterscheiden und die Flexibilität der Datenablage durch die Unterteilung in mehrere Volumes stark abnimmt.
    Am sinnvollsten ist es daher, nur EIN großes Datenvolume einzusetzen, das bei mangelnder Performance einfach erweitert wird.
    [size=”2”]Setup 3[/size]


    Dieses Setup ist exakt das selbe wie Setup 2, jedoch befanden sich in Setup 2 ca. 81.500 Dateien auf oberster Volume-Ebene, da ich testen wollte, wie sich das auf den Test auswirkt. Erfreulicherweise blieben die Ergebnisse in die gleichen wie in Setup 3, wo überhaupt keine Daten auf dem Xsan-Volume lagen.
    [size=”2”]Setup 4[/size]


    Genau wie Setup 3, lediglich die Kombination aus Blockgröße/Streifenbreite wurde geändert.
    [size=”2”]Setup 5[/size]


    Wie Setup 4, jedoch werden keine Anwendungsdaten auf dem ersten Controller gespeichert. Die Performance sinkt dadurch recht deutlich.
    [size=”2”]Setup 6[/size]


    Wie Setup 5, jedoch mit einer anderen Kombination aus Blockgröße/Streifenbreite.
    [size=”2”]Setup 7[/size]


    In diesem Setup wurden die Metadaten/Journalingdaten nicht in einem dedizierten Storage-Pool gespeichert, sondern gemeinsam mit den Anwendungsdaten auf den vier grün gekennzeichneten LUNs gespeichert. In der Praxis erreicht diese Topologie ähnliche Werte wie die in Setup 4 beschriebene Aufteilung, zumindest, wenn man nur mit zwei Xserve RAIDs arbeitet. Ab drei RAIDs, sollten Sie sich eher für Setup 4 entscheiden (und das dritte, vierte, fünfte… RAID jeweils dem Daten-Storage-Pool hinzufügen).
    [size=”2”]Setup 8[/size]


    Wie Setup 4 mit anderer Blockgrößen-/Streifenbreiten-Kombination. Wenn Sie sich die Tests anschauen, so werden Ihnen außerdem einige Dinge auffallen:
    [list]
  • Als erstes werden Sie sehen, dass die Blockgröße und die Streifenbreite immer 1 MB ergeben, wenn man sie miteinander multipliziert. Dies liegt daran, dass Apples Xserve RAIDs mit dieser Datenmenge am besten umgehen können und so die höchste Bandbreite erreichen. Für welche Blockgröße Sie sich am Ende auch immer entscheiden, am Ende muss die Gleichung
    Blockgröße x Streifenbreite = 1
    immer wahr sein.

  • Zum anderen fehlen in der Tabelle Angaben zu Blockgrößen zwischen 8 und 64 KB. Hm. Das ist nicht gut, weil in der Praxis meist Einstellungen zwischen 16 und 64 KB die beste Performance bringen - auch für HD. Leider fehlte mir die Zeit, auch diese Ergebnisse in die Tabelle einfließen zu lassen, sobald ich mal wieder an einem Testsystem sitze und ein paar Tage Zeit für die Dokumentation habe, werde ich die Ergebnisse nachreichen.
  • Die besten Einstellungen für ein Format sind immer rot hinterlegt. Ist Ihnen aufgefallen, dass Sie sich entscheiden müssen, ob Ihnen die Lese- oder Schreibgeschwindigkeit wichtiger ist? Kleinere Blockgrößen ermöglichen offensichtlich höhere Schreibgeschwindigkeiten, während größere Blöcke eine höhere Lese-Performance ermöglichen. In der Praxis wird wahrscheinlich die Lese-Performance wichtiger sein, da die Lesedaten in Echtzeit übertragen werden müssen, während der Speichervorgang ruhig langsamer erfolgen kann.
  • Wie oben erwähnt, habe ich pro RAID-Controller lediglich sechs Festplatten zu je einem LUN zusammengefasst, um bei einem Hardware-Defekt einer Platte eine Ersatzfestplatte zu haben, die automatisch eine defekte Platte ersetzt. Dadurch wird die Datensicherheit des Gesamtsystems erhöht, jedoch lässt sich die Performance des Xsan unter Umständen noch etwas steigern, wenn Sie stattdessen sieben HDs zu je einem LUN zusammenfassen.
    Ich hoffe, dass diese Informationen nützlich für Sie sind und freue mich über jedes Feedback.

  • Spezifikationen

    Hits

    2980

    © by macjaner.ch | Powered by GoeGG-ArT.ch