All-Flash-Speicher-Systeme reduzieren Entwicklungszeiten Agile Software-Projekte profitieren von All-Flash-Storage

Mit Konzepten wie DevOps, Continuous Integration und Continuous Delivery können Software-Entwickler schneller und effizienter denn je arbeiten. In der Praxis spielt dabei ein zentraler Faktor eine große Rolle: die Storage-Infrastruktur.

Anbieter zum Thema

AixpertSoft GmbH

FNT GmbH

Schwarz IT KG

NetApp Deutschland GmbH

Software ist im Zeitalter des Digitalen Wandels ein zentraler Erfolgsfaktor für Unternehmen. Wer als erster eine innovative App auf den Markt bringt oder seinen Online-Shop schneller als Mitbewerber an geänderte Marktanforderungen anpasst, zählt zu den Gewinnern. Mithilfe von DevOps lässt sich die Zeit für die Entwicklung neuer Apps reduzieren und gleichzeitig die Qualität des Entwicklungsprozesses steigern, sprich die Fehlerzahl senken – was die Kundenzufriedenheit erhöht.

Software-Entwicklung "fordert" Speicher-Systeme

Agile Entwicklungsverfahren und der Einsatz von DevOps lohnen sich für ein Unternehmen. Doch das ist nur dann der Fall, wenn Entwickler nicht durch langsame und unflexible IT-Komponenten "ausgebremst" werden. Das gilt insbesondere für Storage-Arrays. Speichersysteme müssen die speziellen Anforderungen von DevOps-Abteilungen und der damit verknüpften Ansätze wie Continuous Integration and Testing (CI) und Continuous Delivery and Deployment (CD) berücksichtigen.

Bei CI speisen Entwickler vielmals am Tag neuen Source Code in ein Code Repository wie Git oder ähnlichem ein. Tools wie Jenkins erstellen daraus automatisiert Build-Prozesse und führen daraufhin automatisierte Testläufe aus. Nach dem erfolgreichen Abschluss der Tests kann der Code in die Produktionsumgebung transferiert werden.

De facto handelt es sich um einen Vorgang, der in der Regel mehrere Durchgänge und damit viele Datenzugriffe erfordert: Erstellen eines Builds, anschließender Test, dann Feedback an den Entwickler, eventuell die Behebung von Fehlern, Erstellen eines neuen Builds, ausführen der automatisierten Tests und so fort.

In Bezug auf die Storage-Ressourcen bedeutet dies, dass durch die Build- und Testjobs die IOPS-Last (Input/Output Operations per Second) drastisch zunimmt. Speziell bei großen Projekten wo viele Testcases automatisiert ablaufen (wie es bei agilen Teams der Fall ist), kann diese hohe Auslastung traditionelle Storage-Arrays überfordern. Die Konsequenz sind Antwortzeiten, die oft im Bereich von bis zu 150 Millisekunden und höher liegen.

Zum Vergleich: All-Flash-Systeme wie etwa Netapp Solidfire garantieren je nach Workload Latenzzeiten im Bereich von 1 bis etwa 2 ms. Diese Werte werden auch bei Datenbanken wie z. B. MySQL, Postgres, MongoDB oder Couchbase erreicht – also selbst bei starker Belastung durch eine etwa gleich hohe Zahl von Read- und Update-Prozessen.

Auf den ersten Blick wirken diese Zeitdifferenzen unerheblich. Doch speziell bei großen Projekten werden dadurch die Feedbackzyklen für Entwickler, insbesondere bei vielen automatisierten Tests, unnötig länger. Das bedeutet Wartezeiten für die Entwickler und damit vor allen Dingen unnötige Verzögerungen bei agilen Software-Entwicklungsprojekten.

Mit Kopien von Produktionsdaten arbeiten

Die Storage-Architektur spielt auch in einem weiteren Punkt eine wichtige Rolle. Um den Ablauf von Entwicklungsprojekten zu beschleunigen, ist es hilfreich, mehrere Kopien der Produktionsdaten zu Testzwecken zu erstellen und, vergleichbar mit der Produktion, auf ebenso leistungsfähigen Speicher-Systemen abzulegen. "Leistungsfähig" heißt in der Praxis: All-Flash-Systeme statt Arrays mit SAS-Festplatten. Denn ein Faktor, der bei der Auswahl einer Storage-Lösung für Entwicklungsumgebungen zu beachten ist, sind die Datenvolumina, die transferiert bzw. kopiert werden. Vor allem das Erstellen von Build-Artefakten und das Ausführen von automatisierten Tests für komplexe Applikationen erfordert eine Storage-Umgebung, die eine hohe IOPS-Performance bietet.

Nur dann haben DevOps-Teams die Möglichkeit, parallel mit diesen Daten zu arbeiten und Varianten einer Software für spezielle Einsatzfelder oder Kunden zu entwickeln. Zu diesem Zweck werden statt Datenbank-Dumps "schlanke" Kopien via Snapshots der Produktionsdaten erstellt. Vergleichbare Vorteile in puncto Geschwindigkeit lassen sich erzielen, wenn Datensätze geklont und parallel mehreren Entwicklern zur Verfügung gestellt werden. Dies spart nicht nur Speicherplatz, sondern auch Zeit, insbesondere in Verbindung mit den Performance-Vorteilen einer All-Flash-Storage-Lösung wie Netapp Solidfire.

"Performance-Diebe" in die Schranken weisen

Allerdings bedeutet der Einsatz von All-Flash-Systemen nicht automatisch, dass Entwickler effizienter und produktiver arbeiten. Denn Storage-Administratoren übersehen häufig folgende Faktoren:

• 1. Es mangelt an Mechanismen, um wichtigen Anwendungen einen bevorzugten Zugriff auf Storage-Ressourcen zu ermöglichen, Stichwort Quality of Service (QoS). Eine mögliche Folge: das Überführen von Produktionsdaten in Testumgebungen oder automatisierte Testläufe dauern länger, weil andere Applikationen zu viel I/O-Performance auf sich ziehen.

• 2. Entwicklungsteams haben keine oder nur begrenzte Möglichkeiten, bei Bedarf eigenständig mehr Speicherplatz auf einem All-Flash-Array zu ordern. Die Folge: Entwickler müssen bei der IT-Abteilung weitere Storage-Ressourcen beantragen und konfigurieren lassen. Das geht zu Lasten der Agilität.

Der erste Fall tritt beispielsweise dann auf, wenn Datenbank-Prüfpunkte erstellt oder Table Scans durchgeführt werden. Hier kommt es zu einem plötzlichen Anstieg der I/O-Operationen, der andere Applikationen gewissermaßen ausbremst – auch diejenigen, die für Entwickler relevant sind. Verhindern lässt sich dies mithilfe von Quality-of-Service-Verfahren. Diese dürfen sich allerdings nicht darauf beschränken, die I/O-Werte einzelner Applikationen mit einem Grenzwert zu versehen, also die Performance zu "kappen".

Netapp Solidfire setzt hier vielmehr auf ein variables Verfahren, mit dem sich für einzelne Volumes und Applikationen QoS-Parameter definieren lassen. Das heißt, die Performance wird unabhängig von der Kapazität verwaltet. Für Applikationen, die Entwickler nutzen, bedeutet dies beispielsweise, dass sich eine minimale IOPS-Rate definieren lässt, die jederzeit zur Verfügung steht, ebenso eine maximale IOPS-Quote.

Geht es darum, beispielsweise Entwicklungsdaten zum Testen aus der Produktion zu überführen, kann es kurzfristig zu einem massiven Anstieg der IOPS-Werte kommen. Auch dieses Szenario sollte eine QoS-Lösung berücksichtigen. Der Vorteil einer solchen mehrdimensionalen QoS-Funktion ist, dass für wichtige Aktivitäten wie die Software-Entwicklung jederzeit die erforderlichen Kapazitäten zur Verfügung stehen.

Mehr Storage? Gerne!

Der zweite Fall, das Hinzubuchen von weiteren Storage-Ressourcen "on demand", lässt sich mithilfe von Self-Service-Funktionen lösen. Das heißt, Entwickler müssen in der Lage sein, per API-Aufruf mehr Speicherplatz zu einer Entwicklungsumgebung hinzuzufügen.

Das setzt voraus, dass sich die Storage-Umgebung im Falle von Ressourcenknappheit möglichst einfach erweitern lässt. Im Idealfall erfolgt das im Rahmen eines Scale-out-Ansatzes, wie ihn Netapp Solidfire unterstützt: Bei Bedarf wird ein All-Flash-Storage-Cluster einfach um weitere Knoten ergänzt.

Entwickler können anschließend die benötigten Server-Instanzen, Storage-Ressourcen und Applikationen zusammenstellen – mit Wissen der IT-Fachleute, aber ohne diese dabei mit der Aufgabe zu behelligen. Dies beschleunigt Bereitstellungsprozesse und lässt Entwicklungsabteilungen den Raum, eine Umgebung zu konzipieren, die ihren Anforderungen entspricht.

Wichtig ist, dass das Storage-System Integrationen in Virtualisierungsplattformen wie VMware und OpenStack anbietet. Zudem sollten sich Systemkonfigurationswerkzeuge wie Puppet, Ansible, und Chef, und ebenso Continuous-Integration-Tools wie Jenkins einfach einbinden lassen. Um zukunftssicher zu sein, sollte das Storage-System schon heute Plattformen wie Kubernetes, OpenShift, und Docker nativ unterstützen.

Beispiel aus der Praxis

Wie sich der Umstieg auf ein All-Flash-System in der Praxis auswirkt, zeigt das Beispiel eines Anbieters von Services im Bereich Augenheilkunde und Augenoptik. Die Ausganssituation: Die Software-Entwicklungsabteilung des Unternehmens hatte nur begrenzten Zugang zu den Datenbanken mit aktuellen Produktionsdaten. Den Entwicklern stand nur eine Kopie der Datenbasis zur Verfügung, die einmal pro Tag im Rahmen des nächtlichen Backup-Prozesses erstellt wurde.

Allerdings dauerte ein Sicherungsvorgang mit der vorhandenen Storage-Umgebung auf Basis eines traditionellen iSCSI-SAN-Arrays fünf bis neun Stunden. Zudem kam es immer wieder vor, dass die Entwicklungsumgebung wegen einer Fehlfunktion oder eines Bedienungsfehlers nicht aktualisiert wurde. Die Entwickler hatten dann keine Möglichkeit, mit aktuellen Datenbeständen zu arbeiten.

Dies änderte sich erst durch die Implementierung eines All-Flash-Storage-Systems von Netapp Solidfire mit integrierten Snapshot-, Cloning- und Quality-of-Service-Funktionen. Dadurch reduzierte sich die Zeit für die Erstellung einer Datensicherung auf sieben Minuten. Das bedeutet, dass sich die Software-Entwicklungsumgebung nun innerhalb von Minuten mehrmals täglich aktualisieren lässt.

Den Entwicklern des Dienstleisters stehen damit jederzeit aktuelle Daten zur Verfügung, die sie für das Erstellen oder Anpassen von Applikationen nutzen können. Das bedeutet kürzere Release-Zyklen, eine höhere Agilität und letztlich einen deutlich besseren Kundenservice.

* Clemens Siebler ist Manager Solution Architects EMEA bei NetApp und Experte für NetApp SolidFire

(ID:44655496)