Warum SAN-Monitoring/Analyse direkt auf dem Link?

Transkript

1 Warum SAN-Monitoring/Analyse direkt auf dem Link? Weshalb ist es unerlässlich, mittels fehlertoleranter TAPs (Test Access Point) direkt auf dem SAN-Link zu messen, obwohl man über einen SAN-Wartungsvertrag eines Herstellers abgesichert ist? Begründung: Sämtliche SAN-Komponenten-Hersteller können nur die Statistiken und Parameter auslesen, welche die eingesetzten Komponenten anbieten. Was aber, wenn diese keine Antworten geben können und nur langwieriges Komponententauschen oder die berühmte "Stecknadel im Heuhaufen suchen" übrig bleibt? Was tun bei Fragen wie: Wie finde ich schnell die genaue Fehlerursache ohne langwieriges Komponententauschen? Wie sehe ich, was auf allen Protokollebenen los ist? Steht mir die vom Hersteller zugesicherte Bandbreite überhaupt zur Verfügung? Wer verbraucht Bandbreite wirklich (Accounting)? Ist die Lastverteilung optimal? Welche Bandbreitenreserven stehen zur Verfügung? Wie sind aktuell meine Bandbreitenverteilung, Durchsatz und Antwortzeiten? Wie ist der Trend? Was passiert genau Ende-zu-Ende auf dem Link? Wie ist die echte Performance über den Link? Wie viel Downtime/Performance-Einbrüche möchte sich ein Unternehmen leisten? Wer/was ist ganz konkret verantwortlich für Performance-Einbrüche? Ist die Kommunikation der Komponenten optimal? Früher oder später werden Sie mit einer dieser oder ähnlichen Fragen konfrontiert. Dann sind Sie fein heraus, wenn Sie zumindest TAPs im Link haben. Ohne den produktiven Betrieb in irgendeiner Weise zu beeinträchtigen, sind Sie dann in der Lage, einen SAN-Analysator oder ein SAN-Monitoring-System direkt auf den Link zu schalten! TRADE bietet Ihnen SAN-Analysatoren und SAN-Monitoring-Lösungen des Herstellers Finisar an, sowie natürlich auch Dienstleistungen mit diesen Produkten. Die Auswertung können dann entweder Sie selber oder unsere Spezialisten von TRADE oder der SAN-Komponentenhersteller durchführen.

2 Der Einsatz von TAPs ist heutzutage ein MUSS. Ein ständiges Monitoring direkt auf dem Link mit einem SAN-Analysator in der Hinterhand ist "Stand der Technik". Überblick der wesentlichen Vorteile: Gesamttransaktionszeit aus Anwendersicht (Total exchange completion time) Anzeige des Link-Verkehrs als individuelle Endgerätekommunikation genaue Zuordnung von SAN-Bandbreitennutzung je Endgerätekommunikation SAN-Monitoring auf einen Blick durch eine korrelierte Ansicht über den gesamten Netzwerkverkehr Intermittierende Geräteprobleme werden auf SCSI Endgeräten sichtbar Aktuelle Speicher-I/O-Antwortzeit für komplette SCSI-Transaktionen (Storage I/O Response Time) Erweiterte grafische Reporting-Möglichkeiten und Alarmfunktionen, basierend auf dem aktuellen Storage I/O Verhalten Ideal für heterogene Umgebungen Unabhängig vom SAN-Komponentenhersteller TRADE stellt Beispiele vor: FC SAN Performance Der Einsatz eines Quality of Service Monitoring Systems (QoS) für permanentes SAN-Monitoring zeigt versteckte Probleme auf, hebt neue Probleme im Augenblick ihres Auftretens hervor und eröffnet das volle SAN Performance Potential. Der rasante Zuwachs an Datenvolumen und die steigende Komplexität in Storageumgebungen (Virtualisierung, Loadbalancing etc.) macht es immer schwieriger, ein optimal eingestelltes, hoch performantes Storage Area Network (SAN) zu betreiben. Unsere Produkte helfen den Administratoren und Integratoren SAN Probleme und Flaschenhälse aufzuspüren und zu beseitigen, um die volle Performance und die Vorteile dieser Speichernetze zu gewährleisten. SAN Performance Monitoring umfasst low-level FC-2 bis FC-4 upper-layer Protokolle, welche die wichtigsten Performance Charakteristiken im SAN beinhalten. Damit werden alle Aspekte des Fibre Channel, von low-level Belangen bis zu Betriebsund Dateisystem-Eigenschaften, wie z.b. queue depth, I/O sizes, exchange completion times etc., wie auch neue Entwicklungen (z.b. Virtualisierung) erfasst.

3 Es kommen unterschiedliche Probleme im SAN vor, die in der Regel für den Anwender nicht offensichtlich sind, jedoch die Performance dramatisch beeinträchtigen oder sogar zu Datenverlusten führen können. Diese unsichtbaren Verhaltensweisen können aus einer Vielzahl von Gründen auftreten. Selbst wenn das SAN- Netzwerk hohe Zuverlässigkeit hat - wenn ein Netzwerkproblem auftritt, kann das beteiligte Datenvolumen das ganze System zum Absturz bringen. Netzwerkfehler- Recovery-Mechanismen verbergen häufig frühe Anzeichen dieser Art von Fehlern. Umso wichtiger ist es, frühzeitig solche Probleme zu finden, zu analysieren und zu beheben, und so derartige Abstürze zu vermeiden. Mit der wachsenden Größe von SANs steigt auch die Komplexität und Vielfältigkeit. Höhere Geschwindigkeiten und neue Protokolle beeinflussen heterogene SANs. Die Anzahl der Ports steigt, die Speicher-Netzwerk-Topologie wird ohne geeignete Produkte komplexer und schwieriger zu verwalten. Neue Entwicklungen wie Virtualisierung helfen, den verfügbaren Speicher besser zu nutzen, machen es aber auf der anderen Seite immer schwieriger, Fehler zu erkennen und zu analysieren. Dies erhöht den Bedarf an Monitoring Produkten. Fibre Channel Netzwerke können je nach Kundenanforderung sehr verschieden konzipiert und konfiguriert sein, von arbitrated loop Konfigurationen bis zu long-haul inter-switch links, welche die WDM Technologie nutzt. Deshalb benötigen SAN- Administratoren und Integratoren geeignete Monitoring- und Analyse-Möglichkeiten, um ein SAN effektiv zu betreiben und Probleme zu lösen, sobald erste Anzeichen dafür auftreten. Unerkannte physikalische Fehler Physikalische Fehler werden von einer Vielzahl von Faktoren beeinflusst, wie z.b. geknickte Kabel, Kabelanschlussprobleme, fehlerhafter Laser oder Kabelbruch. Diese können auf Anwenderebene nicht erkannt werden. So werden häufig micron Kabel für FDDI oder ATM eingesetzt. Fibre Channel Multimode Laser sind aber für 50-micron Kabel konzipiert, die zwar mit 62.5-micron Kabel funktionieren, aber nur solange eine Länge von 200 bis 220 Metern nicht erreicht wird. Längere Kabel oder unterschiedliche Infrastrukturen verursachen intermittierende Fehler, Codeverletzungen oder andere Netzwerkprobleme. Durch das Real-Time-Monitoring des Netzwerkverkehrs, ist SANQoS ein unersetzliches Werkzeug, um derartige Fehler sofort zu finden. Wie auch andere unsichtbare Verhaltensweisen bleiben physikalische Fehler für Geräte und Managementprodukte oft unerkannt. Fibre Channel basiert auf Standards, die bis hinunter auf den ordered set level vollkommen redundant definiert sind. In Kombination mit den Recovery Methoden für SCSI werden viele Rahmenfehler automatisch auf der niedrigsten physikalischen Ebene behoben und niemals an ein Managementsystem berichtet. Hinzu kommt, dass Geräte automatisch viele

4 Link-Level Fehler, wie z.b. Code violations, verwerfen und ersetzen und diese unerkannt über das SAN laufen. Das SANQoS ist jedoch in der Lage solche Symptome zu erkennen und eine rechtzeitige Behebung zu ermöglichen. Fibre Channel bietet Geräten viele Möglichkeiten Fehlersituationen selbst zu beheben. Die heutigen SAN Management Produkte benutzen üblicherweise Link Resets und CRC Fehler als Problemindikatoren. Sie schauen nicht nach den Fehler-Recovery Mechanismen auf Protokollebene innerhalb des Datenverkehrs. Die Geräte sind auch nicht in der Lage zu erkennen, ob fehlerhafte Übertragung durch ein defektes GBIC oder Kabel verursacht wird. Dies zu erkennen wird dem Gerät überlassen, das die fehlerhafte Übertragung erhält. Werden derartige Fehler einem Betriebs- oder Datei-System berichtet, kann dadurch das SCSI Subsystem unter Umständen erdrosselt werden. Keine überlappenden I/O s mehr, es wird nur noch ein einziger I/O pro Gerät pro Zeitfenster erlaubt. Da die meisten Enterprise Server sich jedoch voll auf überlappende I/Os für die Speichersystem-Performance verlassen, kann dies den Durchsatz auf ein Schneckentempo herunterziehen. Dann bleibt nur noch, den Server neu zu starten. Datei-System I/O splitting Wenn ein Anwender von einem SAN-Dateisystem Daten liest oder schreibt, sind mehrere Ebenen von Treibern involviert, die diese Daten bearbeiten, ehe sie über das SAN transportiert werden. Diese Ebenen sind für die Datenbearbeitung soweit verantwortlich, dass diese ordnungsgemäß im Speicher abgelegt und auch wieder abgerufen werden können. Diese Ebenen unterteilen entweder diese I/O Operationen, um Anfragen auf dem SAN kleiner zu halten, oder führen sie mit anderen Operationen zusammen, um größere Anfragen zu erreichen. Daraus resultiert, dass die Anwenderanfrage nicht zwingender Weise in die entsprechende I/O Operation auf dem SAN umgesetzt wird. Die Datei-System-Performance wird jedoch maßgeblich von der Größe der I/O Operationen beeinflusst. Üblicherweise führen größere Anfragen auch zu einem höheren Durchsatz. Werden sie zu groß, kann die Anfrage verhungern (starvation problems). Die meisten Monitoringprodukte, wie Windows NT s Performance Monitor, kann nur die Größe der Anfrage sehen, die von der Endanwender-Applikation an das Betriebssystem gestellt wurde. Dies macht es sehr schwierig, Dateisysteme optimal zu konfigurieren. Nehmen wir als Beispiel eine Bandsicherung. Hiervon laufen die meisten optimal mit einer I/O Paketgröße von 256KB. Jedoch kann eine einzelne 256KB Anfrage durch untergeordnete Treiber in 4x64 KB Anfragen aufgeteilt werden, mit dem Ergebnis, dass durch die zusätzlich notwendigen Rahmen und Zugriffe die komplette Anfrage verlangsamt.

5 Auch Treiber reagieren, abhängig davon wie sie angesprochen werden, sehr unterschiedlich. Sequentielle I/O Operationen sind meist signifikant schneller als zufallsgesteuerte Operationen. Die Zugriffsmuster und Methoden sind für den Anwender ebenfalls unsichtbar. Die meisten Server nutzen heutzutage ihr erweitertes RAM als großen Dateizwischenpuffer. Was als sequentieller Lesevorgang von einer Applikation angefordert wurde, kann durchaus damit enden, dass die Anforderung zufallsgesteuert über das Netzwerk an den Speicher gesendet wird. Dieser Fall tritt ein, wenn einige Fragmente der Anfrage im Server RAM gepuffert werden, andere davon jedoch nicht. Das Betriebssystem wird daraufhin viele individuelle I/Os wegen der fehlenden Fragmente starten, was die Datenbank- oder WebServer-Performance drastisch herunterziehen kann. All diese Belange kann man mit dem SANQoS auf einen Blick sehen, worauf der SAN-Manager die System Performance optimal einstellen kann. Datenüberlastung in Geräten Entgegen vielen anderen Netzwerktechnologien erreichen FC- und SCSI-Protokolle nahezu die theoretischen Durchsatzmengen. Dies stellt einige Herausforderungen an die beteiligten Geräte dar. Server and Hostbus Interfaces, wie PCI, können die Fibre Channel Performance verringern. So haben viele Server 33MHz/64-bit PCI Interfaces, die theoretisch mehr als 240MBps Durchsatz bieten sollten. Könnte damit problemlos ein 2Gbit/s Fibre Channel SAN bedient werden? Wohl kaum. Die meisten 2Gbit/s Fibre Channel SAN Konfigurationen sind für 400Mbyte/s Voll- Duplex Betrieb ausgelegt. Dabei benötigen die meisten SANs diese Durchsatzanforderungen für typische Applikationsprozesse nicht. Jedoch bei Anwendungen wie Datensicherungen kann dies zum Engpass werden. Betrachten wir beispielweise einen Server während der Datensicherung über ein 2Gbit/s SAN, mit sequentiellem Lesezugriff auf die Laufwerksubsysteme und sequentiellen Schreibvorgängen auf ein Bandsubsystem. Der Server erhält Daten vom Laufwerksubsystem in bursts mit 200Mbyte/s. Um die laufende Bandsicherung aufrecht zu erhalten, müssen die Daten sehr schnell zum Bandsicherungssubsystem weitergeleitet werden. Ein 33MHz/64-bit PCI Interface ist nicht in der Lage 200Mbyte/s zu übertragen und gleichzeitig zu empfangen. Das führt in der Regel zu längeren Befehlsausführungszeiten und einer generell geringen Performance. Solche Situationen können leicht mit dem SANQoS erkannt werden. Im Idealfall hätte der SAN-Administrator die Möglichkeit, Unmengen von Low-Level Paketen zu beobachten, er würde vorsorglich Spitzen sehen oder zumindest vergleichbare Netzwerk Performance-Informationen. Diese Daten werden vom ganzen Netzwerk zusammengeführt, nicht nur von einem speziellen Switch oder Server. Die Analyse, die Interpretation und das Verständnis der SAN-Mechanismen sind die

6 Schlüssel, um die SAN-Performance zu maximieren und zukünftig sicher zu stellen. In dem gigantischen Datenvolumen sind die frühen Indikatoren für Datenverlust oder -korruption versteckt. Diese Auslöser von Systemausfällen und Performance-Einbrüchen sind oft die "Nadel im Heuhaufen", die es zu finden gilt. Derartige Probleme können mit SANQoS als permanente Monitoring Lösung erkannt werden. Die von Finisar entwickelten SAN-Analyse und Monitoring Produkte unterstützen mit ihren Funktionalitäten diese "Nadeln im Heuhaufen" zu finden. Gezieltes Echtzeit"- Performance-Monitoring mit SANQoS stellt automatisch die wesentlichen Performance Charakteristiken, sowie abweichendes Verhalten von SANs heraus. SAN- Monitoring führt eine Unmenge von Daten automatisch zusammen, konsolidiert diese und stellt sie in einem übersichtlichen Format, einer Liste von potentiellen Engpässen und Problemen dar. Dies erübrigt die Notwendigkeit, Millionen von Ereignissen zu überprüfen, da der SAN-Administrator lediglich auf eine Handvoll wichtiger Ereignisse schauen muss. SANQoS und der GTX-Analysator bieten auch eine grafische Darstellung und Reports, um leichter einen schnellen visuellen Eindruck zu bekommen. Hierbei wird quasi auf einer Seite alles Wesentliche übersichtlich zusammengestellt, im Gegensatz zum sonst üblichen Zusammensuchen der relevanten Informationen aus Tausenden unterschiedlicher Quellen. Bessere SAN-Performance hängt also von der Möglichkeit ab, zu analysieren, Unmengen Low-Level Daten zu interpretieren und dann das Problem zu lösen, ehe es den Betrieb beeinträchtigt. Das SANQoS versetzt den Administrator in die Lage SANs kontinuierlich zu überwachen, Probleme sofort bei ersten Anzeichen zu erkennen und zu diagnostizieren. Dies trägt wesentlich dazu bei, die SAN-Zuverlässigkeit, -Verfügbarkeit und -Performance zu gewährleisten. Für eine volle SAN- Analyse kann zusätzlich ein Fibre Channel Analysator erforderlich sein. Durch ihn wird der Administrator unmittelbar bei den ersten Anzeichen von Problemen informiert, anstatt lange Zeit unwissend zu bleiben und erst zu spät vor gravierende Probleme gestellt zu werden, wie z.b. der Einschränkung von Datenzugriffen oder im schlimmsten Fall dem kompletten Datenverlust. Notizen von Steve Klotz, Gründungsmitglied und hauptverantwortlicher Ingenieur von Medusa Labs ( überarbeitet von Neil Collier, autorisierter Trainer für Medusa Solutions ( übersetzt und überarbeitet von TRADE (