Große Rechenzentren benötigen daher eine Testumgebung, die ihr reales Netz und den tatsächlichen Verkehr möglichst genau abbildet. Sie muss alle eingesetzten Anwendungen und Protokolle wie Facebook, Skype, Amazon EC2/S3, SQL, SAP, Oracle oder Netflix unterstützen und in der Lage sein, solchen Verkehr in der Größenordnung zu generieren, die im täglichen Betrieb tatsächlich anfällt. Es hilft wenig, die Infrastruktur mit 200 GBit/s zu testen, wenn im Realbetrieb Spitzenlasten über 500 GBit/s auftreten. Zudem sind realistische Verkehrsmuster erforderlich, die dem im täglichen Betrieb des Rechenzentrums entsprechen. Der Rechenzentrumsbetreiber muss dabei auch illegitimen Verkehr berücksichtigen, um gegen die immer häufigeren DDoS- und Multithread-Attacken gewappnet zu sein. Auch solchen illegitimen Verkehr muss die Testumgebung generieren, um das Verhalten des Netzwerks bei Angriffen determinieren zu können. Da Angriffsmuster einem stetigen Wandel unterliegen, sind Aktualität und fortlaufende Tests entscheidende Faktoren. Eine Möglichkeit, die Aktualität sicherzustellen, ist ein externer Dienst, der gegenwärtige Angriffsmuster analysiert und die Testumgebung kontinuierlich und automatisch aktualisiert.
Auch das Verhalten komplexer Storage Workloads kann nur durch Tests mit realem Verkehr wirklich vorhergesagt werden. Cache-Auslastung, Deduplizierung, Kompression, Locking sowie Backup und Recovery müssen mit allen verwendeten Protokollen wie SMB2.1/3.0, NFS, CIFS, CDMI oder iSCSI getestet und gegebenenfalls getuned werden, um die Einhaltung definierter Service-Level auch im Realbetrieb jederzeit zu gewährleisten.
So offensichtlich wie der Testbedarf bei einer neuen Architektur eines Rechenzentrums ist, sei es Neubau, Konsolidierung oder die Einbeziehung hybrider Clouds, so oft werden fortlaufende Tests vernachlässigt. Doch jede neue Anwendung und manchmal sogar Updates und Patches existierender Applikationen können das Verhalten des Netzwerks in einzelnen Punkten deutlich verändern.
Vor dem Rollout beliebiger neuer Software sollte man daher durch Tests prüfen, wie sich die neue Anwendung im konkreten Netzwerk verhält. So lässt sich sicherstellen, dass Upgrades und Patches die Performance und die Antwortzeiten nicht negativ beeinflussen. Es muss also kontinuierlich getestet werden – von der Entwicklung über das Deployment bis hin zum laufenden Betrieb.
Do it Yourself oder Testing as a Service?
Um ein Rechenzentrum auf Herz und Nieren testen zu können, sind Investitionen in Testsysteme, vor allem aber auch in die Qualifikation der damit betrauten Mitarbeiter nötig. Betreiber, die Entwicklung und Test ihrer Netzwerke als Teil ihrer Kernkompetenz sehen, sollten daher ein eigenes Testteam aufbauen und ein entsprechendes Budget bereitstellen. Wer das nicht möchte oder einfach nicht die Ressourcen dafür zur Verfügung hat, kann stattdessen auf Testing as a Service zurückgreifen.
Auch bei solchen externen TaaS-Angeboten müssen die Tests natürlich onsite beim Kunden ablaufen. In diesem Fall stellt aber der Dienstleister sowohl die personellen Ressourcen als auch das entsprechende Know-how zur Verfügung. Insbesondere bei größeren Projekten kann TaaS zudem eine sinnvolle Ergänzung zu einer Inhouse-Lösung sein, um zusätzliche Ressourcen oder sehr spezifische Expertise in das Projekt einzubringen.
So kann ein externer Dienstleister etwa vor der Entscheidung für eine neue Firewall-Generation unter Realbedingungen prüfen, welche Systeme sich am besten in die bestehende Umgebung einfügen – oder vor dem Rollout einer neuen anspruchsvollen Applikation wie etwa Online Gaming – und wie diese sich unter der Last der projektierten Nutzerzahl verhält. Performance- und Zuverlässigkeits-Tests von Wifi-Umgebungen oder WAN Assessments sind weitere Beispiele für solche Projekte.
Zusätzlich zu den genannten Testlösungen und -technologien gibt das sogenannte Applications Performance Management (APM) Entwicklern und Support-Teams Monitoring-Lösungen an die Hand, mit denen sie während der Entwicklung und im produktiven Betrieb sehr tiefgehende Ursachenforschung betreiben können.
Diese Tools sind weniger auf Stresstests der Netzwerk- und Server-Infrastruktur mit typischen Workloads oder auf detaillierte Metriken von Sprache und Video in Streaming-Media-Anwendungen ausgelegt, sondern auf die Überwachung und das Management komplexer Anwendungen und deren Interaktionen auf Transaktionsebene, um Performance-Probleme zu identifizieren und zu lösen.
Paul O‘Reilly ist Sales Director DACH bei Ixia