Einfachheit, Geschwindigkeit, Standards und Stabilität:
Provisionierungsmodell für den schnellen Einsatz von Applikationen

Bei Sprint werden neue Applikationen von unserem Team für Test Environment Operations gründlich getestet, bevor wir sie für die Produktion für interne Kundengruppen freigeben. Dabei folgen wir dem bewährten Zyklus aus Entwicklung/Tests/Produktion.

Aber als das Unternehmen und die IT-Infrastruktur an Größe wie auch an Komplexität immer mehr zunahm, wurde die Bereitstellung von Test- und Produktionsumgebungen allmählich immer langsamer. Manchmal dauerte es gar Monate, ehe die zugrundeliegende Infrastruktur fertiggestellt werden konnte.

Da immer mehr Lösungen entwickelt wurden und auf die interne Freigabe für die Produktion warteten, begann unser Team mit der Evaluierung. Ziel waren Lösungen, mit denen die schnelleren Zyklen für die Umsetzung von Innovationen und den Applikationseinsatz erreicht wurden, die Sprint verlangte.

Dies war für uns der Anlass, einmal die Faktoren zu diskutieren, die uns daran hinderten, die unsre Testumgebungen schneller einzusetzen. Gleichzeitig wurde damit auch unser 4S Service-Provisionierungsmodell geboren. Wir hatten vom Erfolg der australischen Telstra mit dem OmniPresence „Storage Everywhere“ Projekt gehört und so begann unser Sprint Team zu überlegen, wie eine flexiblere Server-und-Storage-Farm-Infrastruktur uns helfen könnte, unsere Test- und Produktionsumgebungen schneller bereitzustellen, zu löschen und wieder neu aufzusetzen. Dieses Service-Provisionierungsmodell führte schließlich zu den vier S, die wir als entscheidend für das Erreichen dieses Ziels erachteten:

  • Einfachheit (Simplicity): Wir wussten, dass der derzeitige Deployment-Prozess, der mehrere Teams und mehrere IT-Ebenen umfasste, viel zu kompliziert war. Unsere neue Infrastruktur sollte weniger Schritte umfassen und weniger Unterstützung durch unterschiedliche Gruppen zur Bereitstellung von Testumgebungen erfordern.
  • Geschwindigkeit (Speed): Wir nahmen uns vor, dass die Bereitstellung einer Testumgebung für unsere Kunden weniger als eine Stunde dauern sollte. Dies war ein anspruchsvolles Ziel, da unser typischer Provisionierungszyklus für Umgebungen Wochen oder gar Monate dauern konnte.
  • Standards: Wir hatten so viele Variationen in unserer Umgebung. Es war unglaublich. Durch die Standardisierung der wichtigsten Infrastrukturkomponenten, die in Server-, Storage-, Datenbank-, Middleware- und Applikationsumgebungen zum Einsatz kommen sollten, so hofften wir, würden wir unserer Bemühungen vereinfachen und die Bereitstellung deutlich beschleunigen können. Wir wollten dahin gelangen, dass wir ggf. schnell 50 bis 100 exakt i
  • Stabilität: Wir wollten, dass unsere Implementierungen stabil genug wären, um sie zu erstellen, wieder zu löschen oder neu aufzusetzen, und zwar in kürzester Zeit. Und die freigestellten Kapazitäten sollten ebenso schnell für andere Test- oder Produktionsumgebungen zur Verfügung gestellt werden können.

Durch die Konzentration auf diese vier Bereiche konnten wir ein schnelles Service-Provisionierungsmodell entwickeln, das es uns nun erlaubt, mit nur wenigen Befehlen einen Server aufzusetzen und Oracle, WebSphere und beliebige andere Applikationskomponenten zu installieren. Dieses Modell umfasst die automatische Erstellung von Storage Volumes sowie die Fähigkeit, Storage so schnell zuzuweisen, dass wir es schon erlebt haben, dass das System in nur wenigen Sekunden sogar 1 TB an Storage für einen Host mountet.

Projektergebnisse:

  • Fähigkeit zur Bereitstellung von 1 TB für einen Host innerhalb weniger Sekunden
  • Fähigkeit zum automatischen Erkennen und Anwenden von Schutzrichtlinien für neu bereitgestellte Datensets
  • Verkürzung der Bereitstellungszeit für Datenbanken, Applikationen und Storage auf einem Server auf nur 15 Minuten

Frustration und Verzögerungen: Das Motiv für Veränderung
Wenn uns ein Kunde bat, eine neue Testumgebung einzurichten, war früher die Koordination von mindestens sechs Teams dafür erforderlich. Die Server-Komponente wurde von der Facilities-Abteilung bereitgestellt, der Storage von unserer Systems Administration-Abteilung. Dann war eine weitere Gruppe für die Installation von Middleware oder einer Datenbankschicht zuständig. Irgendjemand anders war dann für die Anwendungsseite oder die Installation von WebLogic oder WebSphere verantwortlich, wenn diese erforderlich waren. In den meisten Fällen wurde jeder Teil der Software von einer anderen Gruppe individuell bearbeitet.

Da unser Deployment von Umgebungen in so hohem Maße davon abhing, dass jedes Team für die Erledigung der entsprechenden Arbeiten zur Verfügung stand, dauerte der Prozess so lange. Wenn wir endlich einen Zeitplan für alle aufgestellt hatten, vergingen von der Anfrage bis zur Bereitstellung üblicherweise Wochen oder gar Monate.

Wir begannen uns zu fragen, wie viel schneller wir Testumgebungen wohl bereitstellen könnten, wenn wir die Abhängigkeit von anderen Teams für die Ausführung ihrer Komponenten minimierten. Wie wäre es, wenn wir stattdessen einfach ihren Teil der Implementierung automatisierten, und zwar auf der Grundlage ihrer eigenen, vorher festgelegten Richtlinien und Prozesse? Wenn wir die „Ausführungsseite“ für jede Umgebungsbereitstellung erfolgreich von der zugehörigen „Richtlinienseite“ jeder Gruppe trennen könnten, welche Effizienzsteigerung könnten wir dann erzielen?

Um diese Prämisse zu testen, entschieden wir uns letztes Jahr zur Durchführung eines informellen Pilotprojekts mit Unterstützung eines Vertreters des Managements. Mit einem Kernteam von nur vier oder fünf Leuten konnten wir einen Prototypprozess erstellen, der im Großen und Ganzen immer noch manuell war. Mit diesem Prototyp konnten wir aber immerhin beweisen, dass sich Bereitstellungszeit für eine Test- oder Produktionsumgebung für die Kunden drastisch reduzieren lässt. Bei unserem Pilotprojekt konnten wir die Umsetzung von 80 Stunden Kalenderzeit auf nur vier Stunden und eine einzige Person verringern. Damit konnten wir die Zeit und den Aufwand, die für die Durchführung der eigentlichen Aufgaben erforderlich waren (und die relativ gering waren), von Koordination und Zeitplanung trennen.

Eine zeitsparende Provisionierungsstrategie, die während des Pilotprojekts eingesetzt wurde, war das Ersetzen der traditionellen Installationsvorgänge für Middleware und die individuelle Software des Unternehmens durch ein installiertes Image der Middleware-Applikation, das mit NetApp Snapshot Software, die auf einem unserer NetApp FAS-Storage-Systeme lief, erstellt worden war. Die zuvor in ihrer installierten Form gespeicherte und katalogisierte Snapshot-Kopie konnte dann schnell für eine neue Testumgebung bereitgestellt werden, indem schnell eine Snapshot-Kopie unter Verwendung von NFS auf einem entsprechenden Ziel-Server gemounted wurde.

Da unsere erste Hypothese damit bewiesen war, nahmen wir nun ein größeres Projekt in Angriff, das letztlich zur Entwicklung unseres derzeitigen 4S Service-Provisionierungsmodells führte.

Wechsel zu einer Bereitstellungsplattform für gemeinsam genutzte Services
Wir begannen damit, eine neue Rechnerfarm zu entwickeln und zu testen, die uns eine schnelle Bereitstellung ermöglichen würde, wobei sowohl Server- als auch Storage-Ressourcen entsprechend den Anforderungen jedes Hosts skalierbar waren. Nachdem wir analysiert hatten, wo wir die größten Effizienzsteigerungen bei der Bereitstellung erzielen konnten, entschieden wir, uns als erstes die Bereitstellung von Testumgebungen aus einem Sun Solaris Server und einer Oracle Datenbank oder Bea WebLogic oder IBM WebSphere oder Sun iPlanet zu automatisieren. Anwendungen mit einer oder mehreren dieser Komponenten machten ungefähr 45% der insgesamt bereitgestellten Testumgebungen aus. Dies sollte unser erster Testfall für unser im Entstehen begriffenes Service-Provisionierungsmodell sein.

Wir entwickelten eine Server- und Storage-Farm, die beide über ein TCP/IP-Netzwerk liefen und von einer Infrastrukturmanagement-Software-Schicht verwaltet wurden. Diese sollte dazu dienen, die Bereitstellung von Ressourcen von innerhalb der Farm aus zu automatisieren und zu beschleunigen. Zu den entscheidenden Funktionen, welche die Infrastrukturmanagement-Schicht ausführen musste, zählten:

  • Provisionierung
  • Storage und Backup Management
  • Betriebssystem-Provisionierung mit Hilfe von Jumpstart

Diese Funktionen sowie das konzeptuelle Design der Farm werden in Abbildung 1 dargestellt. Wir gingen davon aus, dass jede Verbindungslinie in der Abbildung von Punkt A zu Punkt B einiges an individuellem Entwicklungs- und Integrationsaufwand erfordern würde, ehe wir bei der Bereitstellung von Testumgebungen und zugehörigen Services zu einem stärker automatisierten Prozess gelangen würden, bei dem alles auf Knopfdruck funktionierte. Aber als wir uns mit der Storage und Backup Management-Komponente befassten, stellten wir überrascht fest, wie wenig Integrationsaufwand beim NetApp Protection Manager erforderlich war, der Applikation, die wir für das Prozess-Management einsetzten.



Abbildung 1: Das 4S Service-Provisionierungsmodell von Sprint für die Server- und Storage-Farm
Für die Server-Farm verwendeten wir Sun Solaris Server, anfangs 50, hatten aber etwa 100 Server als Ziel. Beim Storage nutzten wir zentral 100 TB Storage der NetApp FAS3000 Serie und 100 TB Nearline-Storage an NetApp NearStore als unseren primären und sekundären Storage. Die Systeme sind über ein IP-SAN miteinander verbunden, das so ausgelegt ist, dass es bis in jeden Winkel unseres Datenzentrums skalieren kann. Die Architektur selbst ist so ausgelegt, dass sie sich auch für die Unterstützung von Tausenden von Hosts skalieren lässt.

Für unsere größere Infrastrukturmanagement- und Provisionierungskomponente entschieden wir uns für IBM Tivoli Provisioning Manager zur Verwaltung, Katalogisierung und Automatisierung der Bereitstellung von vorgefertigten Server/Betriebssystem-Umgebungen für die Wiederverwendung. Damit wir die Datensätze für jede Testumgebung schneller verwalten, sichern und bereitstellen konnten, haben wir eine Reihe von Backup&Recovery-Anwendungen ausprobiert, ehe wir uns für den Einsatz von NetApp Protection Manager in Verbindung mit weiteren NetApp Datensicherungstools wie NetApp Snapshot, SnapMirror und SnapVault entschieden.

Die optimale Storage und Backup Management-Lösung zu finden erwies sich als einer der schwierigsten Aspekte des zu implementierenden Modells.

Neue Verwendungen für Datensicherungstools: schnelle Provisionierung und Freigabe von Storage-Ressourcen
Als wir mit dem Entwurf des 4S Modells begannen, wussten wir, dass wir eine sehr hochverfügbare und robuste Backup-Funktion haben wollten, so dass wir potenzielle Verzögerungen bei der Bereitstellung von Services vermeiden konnten. Wir wussten auch, dass wir in Sachen Management der Datensätze mehr machen wollten, als diese nur für den Fall eines lokalen oder umfassenderen Systemausfalls zu sichern.

Wir brauchten eine Lösung, die uns die Bereitstellung des Storage erlauben würde, aber auch die nachfolgende Löschung oder Freigabe dieses Service, so dass die zugrundeliegenden Storage-Ressourcen wiederverwendet werden könnten. Außerdem wollten wir für die Testumgebung einen „Wiederherstellungspunkt“, so dass wir sie stoppen konnten, aber auch später wiederaufnehmen, um so in der Zwischenzeit die entsprechende Serverkapazität für eine bessere Auslastung freizugeben.

Host-zentrierte im Vergleich zu Storage-zentrierter Sichtweise
Als wir NetApp Protection Manager mit anderen hostbasierten Backup-Anwendungen verglichen, gefiel uns, dass es eine Storage-zentrierte statt einer Host-basierten Sicht auf die Backup-Daten bot. Wenn wir Storage Services für eine neue Testumgebung bereitstellen wollten (also die Volumes auf einem Host mounten, sie dann dismounten und entfernen), hatten wir den Eindruck, dass ein hostbasierter Backup-Ansatz dazu führen würde, dass ein Teil des Storage „verwaist” und ohne zugehörigen Host sein würde. Dies war einer der Hauptgründe dafür, dass wir den Host aus dem Blickfeld verlagern wollten, wenn es um die Sicherung und Verwaltung der Datensätze ging.

Nachdem wir Protection Manager getestet hatten, gefiel uns die Tatsache, dass er einen Storage-basierten Überblick von zugrundeliegendem physischem Storage, Volumes, Snapshot-Kopien und Datensätzen bot. Noch wichtiger aber war, dass er ein wichtiges Feature mitbrachte, das keine der anderen Lösungen aufwies, die wir uns angeschaut hatten: Die Fähigkeit, Storage-Komponenten und zugrundeliegende Storage Volumes innerhalb unserer NetApp FAS- und NearStore Storage-Systeme selbstständig zu entdecken. Dies war ein enormer Vorteil für uns, denn es bedeutete, dass wir nicht monatelang spezielle Scripts schreiben mussten, um dem System zu ermöglichen, den aktuellen Status der unterschiedlichen Datensätze herauszufinden, zu berichten oder zu verwalten.

Außerdem gefiel uns die Tatsache, dass uns Protection Manager ermöglichte, Datensätze oder Volumes mit gemeinsamen Schutzanforderungen entsprechend zu gruppieren, um dann eine vordefinierte Backup/Restore-Richtlinie anwenden zu können. Hieraus ergab sich eine andere Art von Provisionierungsrichtlinie innerhalb unseres Modells. Dieser Ansatz passte auch mit unserer ursprünglichen Vision zusammen, die Beteiligung der unterschiedlichen Gruppen beim Einrichten von Testumgebungen zu verringern, diesen aber dennoch die Kontrolle darüber zu belassen, was die einzelnen Builds enthalten sollten.

Wir richteten unsere gemeinsam genutzte Storage-Farm möglichst allgemein und einfach ein, mit Sicherungsrichtlinien für Backups unserer Software-Klone, mit separaten Sicherungsrichtlinien für Backups von Benutzerdaten und separaten Sicherungsrichtlinien für Root-Volumes und Storage-System-Dateien. Dieser Prozess ist in Abbildung 2 dargestellt.



Abbildung 2: Datensätze und Backups werden von NetApp Protection Manager verwaltet.
Beispiele für schnelle Storage-Bereitstellung (und erneute Bereitstellung)
NetApp Protection Manager funktionierte schon mit den Werkseinstellungen gut. Nach nur wenigen Tagen für die Implementierung dieses Aspekts des Modells und mit nur zwei Seiten geschriebener Anweisungen waren wir in der Lage, auf einfache Weise neue Storage- und Testumgebungen bereitzustellen.

Inzwischen können wir eine standardisierte dreischichtige Server-Umgebung (mit drei Servern, jeder für ein Datenbanksystem, Applikations- und Internet-Umgebungen und sogar Terabytes an Storage) innerhalb von nur noch 15 Minuten bereitstellen, und ein einzelner Mitarbeiter muss dafür nur noch wenige Befehle eintippen. Dieser Vorgang hatte sonst Stunden oder gar Wochen gedauert!

Bei einem anderen Szenario hatten wir bereits Ressourcen für eine Testumgebung bereitgestellt, die auf der ursprünglichen Anforderung des Kunden nach einer Oracle10g Datenbank basierten. Nachdem die Umgebung bereitgestellt worden war, wurde uns eine neue Anforderung für die Umgebung mitgeteilt. Diese sollte nun stattdessen mit Oracle9i laufen. Bei unserem alten Bereitstellungsverfahren wäre dies ein wahrer Albtraum gewesen. Mit unserem neuen Service-Modell brauchten wir nur wenige Befehle, um Ressourcen von Oracle10g zu trennen und diese in Oracle9i neu aufzusetzen.

Effizienzsteigerung sollte an erster Stelle stehen, denn Kosteneinsparungen ergeben sich dann von selbst
Einer der interessanten Aspekte bei diesem Projekt war die Tatsache, dass wir anfangs nicht mit Kosteneinsparungen als wichtigstem Ziel an die Sache herangegangen sind. Manchmal kann eine zu starke Fixierung auf Kosteneinsparungen zur Verwässerung eines Projekts führen. Stattdessen setzten wir die richtigen Schwerpunkte, indem wir uns zuerst auf die Geschäftsabläufe konzentrierten. Unser wichtigstes Geschäftsproblem waren nicht Kosteneinsparungen. Sondern es ging darum, wie wir die Bereitstellung von Applikationen und Umgebungen für die Produktion beschleunigen konnten. Wir sind überzeugt, dies mit unserem 4S Modell erreicht zu haben, und beginnen nun damit, dieses Modell auch auf andere Aspekte unseres Unternehmens anzuwenden. Wir sehen bereits die ersten Vorteile dieses Ansatzes in Form von Kosteneinsparungen aufgrund besserer Storage-Auslastung und kürzeren Zeiten bis zur Produktionsreife.

Der wichtigste Aspekt, dessen sich andere Gruppen bewusst werden müssen, ist, dass diese Art von Service-Provisionierungsinfrastruktur sie nicht der Verantwortlichkeit und Eigentümerschaft für diesen Teil der Infrastruktur beraubt. Stattdessen werden ihre Komponenten auf eine Weise neu zusammengestellt, die es ihnen ermöglicht, proaktiver bei Festlegung und Verfeinerung von Richtlinienentscheidungen und Standards vorzugehen, wenn wir damit weitermachen. Und da wir die Vorzüge des Projekts zuerst mit Unterstützung von nur wenigen Kernmitgliedern und einem Befürworter aus dem Management belegen konnten, waren wir in der Lage, schneller einen großen Vorteil zu demonstrieren. Daher hoffen wir, dass das Unternehmen schneller die Vorteile einer solchen Architektur auch für andere Bereiche nutzbar machen wird.

Rich Angalet
Manager, Sprint

Rich Angalet hat eine 25jährige IT-Erfahrung in den Bereichen Operations, Hardware, Betriebssysteme, Netzwerk, Datacenters, Facilities und Automatisierung. Derzeit ist er verantwortlich für die Implementierung der 4S Initiative bei Sprint. Rich ist Absolvent der Rutgers University, liebt Motorräder, Oldtimers und die freie Natur.

  Dale Elmer
Director of IT Operations Management, Sprint

Dale Elmer begann seine IT-Karriere 1976 bei Centel, einem kleinen Versorgungsunternehmen, das 1993 mit Sprint fusionierte. Dale war bei Sprint in unterschiedlichen IT-Positionen tätig. Vor seinem derzeitigen Posten war Dale Director of Quality Assurance für die 4S Initiative von Sprint.

Explore