| Benutzer | | Gäste online: 5
Benutzer online: 0
|
 | |
| Die Ersteigung der Spirale: Ein besseres Restrukturierung-Modell | | Der OpenVMS-Fachberater - 24-Nov-2010 08:24 UTC | vom OpenVMS-Fachberater Bob Gezelter
Die erste Frage bei der Planung eines neuen Systems ist oft "Wie groß muss das anzuschaffende System sein?" In vielen Fällen wird das System ausgelegt, lange bevor irgend jemand eine fundierte Schätzung der Auslastung oder Arbeitslast hat. Die Größenbemessung wird oft vorgenommen, bevor relevanter Code überhaupt entworfen, geschweige denn geschrieben oder debuggt wird.
Dies führt zu einer Zwickmühle. Man kann ein kleines System wählen und das Risiko eingehen, dass es unzureichend ist. Alternativ kann man sehr konservativ viel mehr Kapazität einkaufen, als vermutlich je benötigt wird, in der Hoffnung, dass jeglichen Engpaß vermieden wird. Es ist dies ein multidimensionales Dilemma. Es ist eine Entscheidung von beträchtlicher finanzieller Bedeutung; ein Übermaß an Rechenkapazität über einen kleinen Sicherheitsspielraum hinaus ist eine der schlechtesten Investionen überhaupt. Effektiver Kapitaleinsatz erfordert den Kauf von genug Rechenkapazität zur Deckung der Bedürfnisse, mit einem vernünftigen Spielraum zum Abfangen von Spitzen. Das ist schon immer ein Dilemma gewesen. Die heutige anspruchsvolle Finanzlandschaft verschärft das Problem zusätzlich.
OpenVMS-Cluster beeinflussen dieses Dilemma positiv, indem sie eine Flexibilität bieten, die Risiken und die Versuchung verringert, Ressourcen im Übermaß vorzuhalten.
"Restrukturierung" wird oft als Euphemismus für "Abbau" verwendet. Während viele das Wort mit Bezug auf Server-Konsolidierung oder -Eliminierung verwenden, hat doch das Konzept viel mehr Potential als nur ein "Erbsenzähler"-Euphemismus zu sein.
Seit Anbeginn der EDV sind die Kosten pro Rechen-Einheit stetig geschrumpft. Es spielt i.allg. keine Rolle, ob die Kapazität geleast, gemietet oder gekauft wird; die Anschaffung von mehr als der benötigten Kapazität ist fast immer eine schlechte Wahl.
Das gilt für alle Klassen von EDV, sowohl für den ältesten Mainframe als auch für die jüngste Cloud-Implementation. Aus der Sicht des Besitzers ist installiertes Equipment, das nicht benutzt wird, Verschwendung.
Sicherheitsspielräume, um Spitzen aufzufangen, sind ein wesentlicher Bestandteil der Kalkulation. Die durchschnittliche Nutzung ist nicht der relevante Faktor, sondern die zu erwartende Nutzung plus einer Kapazitätsreserve für die Bewältigung unerwarteter Nutzungsspitzen.
Nun herrscht auf Systemen selten eine einförmige Aktivität. Manchmal ist es eine generell geringe Nutzung während eines Entwicklungszyklus mit Spitzen während der Testphase. Später beschleunigt sich das Tempo, wenn das System produktiv wird. Während dieses Zeitraums ist das System den Gezeiten der Geschäftsaktivität ausgesetzt - sei es die erwartete Last während der Urlaubs-Einkaufssaison oder eines planetaren Zusammentreffens, oder die von einer Massenhysterie ausgelöste unerwartete Last. Die Berechnung bleibt dieselbe: erwartete Nutzung auf Basis bekannter Faktoren plus ein zusätzlicher Rahmen für unvorhergesehene Schäden und Ausfälle.
Sogar wenn man Hosting-Kapazität bei anderen kauft, kann diese Kalkulation nicht ignoriert werden. Ein Provider, der unterprovisioniert, riskiert das Cyber-Äquivalent eines "Sturms auf die Bank" bezüglich Bandbreite oder Rechenkapazität, das zu geplatzten Verpflichtungen führen kann (ich habe über dieses Thema allgemein am 12.5.2010 einen Artikel in meinem Blog Ruminations – An IT Blog unter dem Titel Why Settle on a Hosting Provider? Bandwidth liquidity and other issues geschrieben). OpenVMS ist für Unter-Provisionierung genauso anfällig wie jedes andere System.
Der Unterschied mit OpenVMS ist die Flexibilität von OpenVMS-Clustern, die es erlauben, Rechen- und Speicher-Kapazität einem erhöhten Bedarf anzupassen, ohne Unterbrechung der Verfügbarkeit für die Benutzer. Die Fähigkeit von OpenVMS-Systeme, Platten gemeinsam zu nutzen, gepaart mit der Einfachheit, neue Knoten einzurichten und in einen OpenVMS-Cluster einzubinden, ermöglicht eine "kontinuierliche Restrukturierung". Knoten können einem OpenVMS-Cluster hinzugefügt oder aus ihm abgezogen werden, wie es der Kapazitätskorridor erfordert.
OpenVMS bringt von Haus aus die Fähigkeit mit, einfach zwischen Konfigurationen umzuschalten. Wenn logische Namen richtig eingesetzt werden, sind Anwendungen unabhängig von der Hardware-Konfiguration des Hostsystems. OpenVMS-Cluster steigern diese Handhabung noch, durch weiter verbesserte Flexibilität. Der erste Schritt in diese Richtung ist, als Standard-Auswahl nicht mehr das alleinstehende OpenVMS-System zu nehmen, sondern einen OpenVMS-Solo-Cluster (siehe OpenVMS Solo-Cluster: Eine neue Perspektive - funktioneller, flexibler, benutzbarer). Allerdings ist ein Solo-Cluster nur der erste Schritt. Als nächstes kann man den einzigen Knoten eines OpenVMS-Solo-Clusters auf einer virtuellen Maschine einrichten, sei es eine Alpha oder eine Integrity VM. Damit können zu nominalen Kosten Projekt-Prototypen erstellt und Projekte entwickelt werden, ohne die Notwendigkeit, zusätzliche Hardware-Kapazitäten anzuschaffen.
Ähnliche Strategien können durch Verwendung von Shadowing auf OpenVMS, allgemein bekannt als Host-based Volume Shadowing (HBVS) and Dynamic Volume Expansion (DVE), verfolgt werden, um Upgrades der Speicherkapazität und Änderungen der Datenspeicher-Technologien für Benutzer und den allgemeinen Systembetrieb unsichtbar zu machen. Dieser Ansatz wird in Migrating OpenVMS Storage Environments without Interruption or Disruption beschrieben, einem Vortrag auf dem HP Enterprise Technology Symposium 2007.
Auf diesen Grundlagen wird Systemerweiterung unkompliziert. Die Verzögerung zwischen dem Bedarf nach Kapazität und deren Bereitstellung kann wesentlich reduziert werden, indem man für zusätzliche, noch nicht realisierte Mitglieder des OpenVMS-Clusters schon einmal Bootstrap-Verzeichnisse anlegt. Die Bereitstellung von Kapazität reduziert sich damit auf das Beschaffen von realen (oder virtuellen) Ressourcen und dem Starten des schon konfigurierten (aber derzeit nicht aktiven) OpenVMS-Clusterknotens.
Diese Betriebs- und Geschäftskonzepte waren der Kern meines Vortrags Using OpenVMS Technologies to Build an Agile Computing Base auf dem diesjährigen OpenVMS Bootcamp. Als Gefälligkeit für die Community haben wir die Folien und den Audiomitschnitt dieses Vortrags zum Herunterladen zur Verfügung gestellt.
Dies sind meine Ansichten darüber, wie OpenVMS die Ziele von HPs Konzept der adaptiver Infrastruktur erfüllt.
Wie immer begrüße ich Leserkorrespondenz zu den Inhalten dieser Kolumne. Ich bin zu erreichen über den Website meiner Firma unter http://www.rlgsc.com.
Über den Autor:
Robert Gezelter, CDP, CSA, CSE, Software Consultant, hat mehr als 30 Jahre internationale Erfahrung mit der Fachberatung im privaten und öffentlichen Sektor. Er ist regelmäßiger Gastredner auf technischen Konferenzen weltweit, einschließlich des HP Technology Forums. 2004 hat die IEEE Computer Society Mr. Gezelter in ihr Distinguished Visitors Program berufen, das Redner auf Veranstaltungen von IEEE-Verbänden in ganz Nordamerika vermittelt. Außerdem hat er zahlreiche technische Artikel und Buchkapitel verfasst, einschließlich zweier Kapitel im Computer Security Handbook, 5. Auflage.
Außerdem veröffentlicht er Ruminations - An IT Blog über IT-Themen, die nicht unbedingt mit OpenVMS in Verbindung stehen.
Die Tätigkeit seiner Firma betont detaillierte technische Expertise in den Bereichen Computer-Architekturen, Betriebssysteme, Netzwerke, Sicherheit, APIs und verwandte Themen. Mr. Gezelter hat mit OpenVMS seit der ersten Release von VAX/VMS 1977 gearbeitet.
Seine Kundenstamm umfasst sowohl kleinere Firmen wie auch Firmen in den Fortune 10, lokal, national und international, mit Arbeitsbereichen, die von individuellen Telefon-Fragen bis zu größeren Projekten reichen.
Im Web ist er über den Website seiner Firma unter http://www.rlgsc.com zu erreichen.
Original auf www.openvms.org
Original auf Bob Gezelters Site
| | Links zum Thema: | Version zum Drucken | |
|
|
|
![[OpenVMS Swoosh]](/images/OpenVMS_VSI_72x88.png)
de.OpenVMS.org![[Future Forward]](/images/swoosh160w.jpg)