Posts Tagged: ‘pureapplication’

Isolation and multi-tenancy in the IBM PureApplication System – Cloud Groups are the NEW Virtual Systems

9. April 2014 Posted by Yathish Kumar

(This is a guest entry posted on behalf of Georg Ember)

Almost any application running in the cloud is designed to share resources. Virtualization is the key enabler for cloud computing in integrated or converged systems. Applications run in the cloud as workloads that share system resources, such as CPU, memory and networking.  However, there are legal or organizational requirements where workloads must be isolated from each other and the key question is: What type of isolation is the right way to protect the application environments from each other?

Isolation (also as know as multi-tenancy) is a key requirement for cloud computing. An application deployed into a cloud environment must be able to run independently and separately from other applications in the cloud. Each application requires it to move traffic along the network and protect its data as well.

Isolation of applications and data, by physical separation or by virtualization within an integrated system, may satisfy security requirements and ensure that a failure of one application will not cause the failure of other applications. While the data has to be kept isolated, in many cases, other departments within a company are not allowed to see deployed resources (Virtual Machines) of other environments.

An ideal solution to implement such an application and virtual systems isolation is to exploit the multi-tenancy features of the IBM PureApplication System.

A comfortable and easy way to isolate LAN, SAN and Server resources, on a physical as well as a logical level in PureApplication System, is to use the concept of Cloud Groups and environment profiles.

Using the isolation techniques that are incorporated within the IBM PureApplication System can help minimize business risks and increase the availability. By selecting nodes to Cloud Groups which are placed in separate chassis modules, the performance and availability of a Cloud Group can be greatly increased.

image

If you are required to isolate applications and data not only on a logical level, the concept of Cloud Groups in the PureApplication Systems is the right choice for you. You do not need to acquire multiple physical systems, except for high availability or disaster recovery reasons, when you need to separate multiple application environments in a multi-tenant infrastructure. PureApplication System offers the concept of dedicated Cloud Groups.

IBM PureApplication System Cloud Groups physically separate:

  • Compute Nodes (server nodes), across IBM Flex Chassis,
  • LANs by defining VLANs (on dedicated LAN ports) and IP groups (IP address ranges),
  • Services running on the System (so called shared services), each Cloud Group can have “private” services running, without affecting other Cloud Groups. Examples of shared services are monitoring, OS updates, Load Balancers and clustered file systems services, just to name a few.
  • Workload (deployment) users, where each user belongs to one or more environment profiles, can deploy an application to the designated Cloud Group, without seeing other deployed resources from other users or being seen by other users on the Cloud Groups.

image

Companies normally separate environments according to application development lifecycle. The typical divisions are:

  • Development (DEV): An environment used for developing applications.
  • Testing (TEST): Used for testing applications.
  • Production (PROD): Used for running applications; this is the realm of business or end users.

Each of these environments typically runs on totally independent sets of hardware and networks to avoid cross-environment issues. But, when using Cloud Groups in the PureApplication System, application environments are totally isolated from each other, if required, even by the users and shared services they use. Consecutively, you do not need to acquire multiple physical systems – one PureApplication System does it all for isolation of application environments. There is full isolation and protection in any layer of the stack.

Pure UrbanCode Chef. Oder: Wohin mit all den DevOps Tools?

12. Februar 2014 Posted by Wladislaw Nill

DevOps und Continuous Delivery sind heute de facto Standards in der Software-Entwicklung. Zumindest wenn man einigen Statistiken[1][2] glauben kann, die in den letzten Jahren veröffentlicht wurden.
Ich persönlich denke, dass die tatsächliche Verbreitung geringer ist als es diese Zahlen glauben lassen - alleine schon deshalb, weil es kein Rezept für DevOps gibt. Außerdem ist der Begriff sehr vage und überladen. Fragt man drei IT Professionals nach einer Definition bekommt man wahrscheinlich drei verschiedene Antworten. Manche setzen damit (zu Unrecht) Infrastructure-as-Code gleich, für andere ist es hauptsächlich ein organisatorischer oder kultureller Prozess.

Egal wie eng oder weit man es fasst, Automatisierung und Tool-Unterstützung spielen sowohl bei DevOps als auch bei Continuous Delivery eine wichtige Rolle. Aber der Markt für „DevOps-Tools“ ist genauso unübersichtlich wie die Begriffe selbst.  Ich habe in letzter Zeit häufiger mit Kollegen über dieses Thema gesprochen und dabei kamen immer wieder Fragen auf wie: „Wozu brauche ich denn Chef [oder Puppet, Salt, Ansible...], wenn es doch schon PureApplication Systems gibt?“. Seit der Übernahme von UrbanCode im vergangenen Jahr hat IBM seine eigene DevOps Plattform weiter ausgebaut. Ist das nicht das gleiche wie der IBM Workload Deployer? Gibt es nicht das gleiche als Open-Source-Lösung?

Die (nicht sehr überraschende) Antwort ist: Nein, es ist nicht alles das gleiche.
Es macht Sinn sich alle angesprochenen Tools und Systeme anzuschauen weil sie sich gegenseitig ergänzen, nicht ersetzen.

 

Wie baut man einen Bauplan?

Die Stärke von PureApplication System ist es Anwendungen und die darunterliegende Infrastruktur, die durch Patterns abgebildet werden, in einer Cloud bereitzustellen. In vielen Fällen reichen dazu vorgefertigte oder selbst erstellte Application Patterns aus. Theoretisch lassen sich ganze Anwendungslandschaften damit aufsetzen und betreiben. Aber leider ist es nicht immer so einfach. Nicht alle Systeme fallen in ein typisches, weit verbreitetes Schema. Wenn neben Standard-Komponenten auch selbst entwickelte Tools, Frameworks, Scripte, Monitoring und sonstige Utilities benötigt werden (und seien wir ehrlich, das ist nicht selten), muss eine individuelle Lösung her. In PureApplication System heißt das System Patterns.

Um beliebige Systeme zu modellieren benötigt man im Wesentlichen zwei Teile: Ein Basis-Image (z.B. ein vorkonfiguriertes Linux System und Middleware) und Skripte, um die eigentliche Konfiguration zu automatisieren. In den meisten Fällen werden diese Skripte nicht nur aus ein paar Kommandos bestehen. Je größer und heterogener die verwalteten Umgebungen sind, desto weniger sollte man sich darauf einlassen sie von Grund auf selbst zu schreiben. Die Kosten für Wartung und Weiterentwicklung schießen dadurch nur unnötig in die Höhe.

 

Rezept des Tages: Virtual System Patterns

An dieser Stelle kommen Tools wie Chef oder Puppet ins Spiel. Ihre wesentliche Eigenschaft ist, dass sie die Konfiguration von Systemen in Form von Code abbilden können, meist ohne dass man sich mit Implementierungsdetails beschäftigen muss.  Damit lässt sich praktisch jeder Zielzustand, von der Betriebssystemkonfiguration, über installierte Pakete bis zu laufenden Services beschreiben und reproduzieren. Weil diese Tools relativ leicht einzusetzen, aber gleichzeitig sehr mächtig sind, haben sie zu Recht mittlerweile viele Anhänger gefunden.

Die gute Nachricht ist, dass PureApplication System solche DevOps Tools unterstützt. Genauer gesagt setzt IBM auf Chef als Infrastructure-as-Code Anbieter. Es gibt einen frei verfügbaren IBM Script-Package Generator[3], mit dessen Hilfe Chef Skripte (auch Rezepte genannt) in Virtual System Patterns verwendet werden können. Auf diese Weise können auch sehr komplexe und individuelle Umgebungen automatisiert in der Cloud bereitgestellt werden.

Die schlechte Nachricht: Es gibt Dinge, die auch Chef und PureApplication System gemeinsam nicht optimal abbilden können.
 

Leben in die Cloud bringen

Was dieser Lösung noch zu einer vollen Continuous Delivery Pipeline bzw. DevOps-Toolunterstützung fehlt sind automatisierte Deployments auf die provisionierten Systeme. Damit meine ich nicht nur eine Datei, die auf einen Server kopiert wird, sondern komplette Releases, die  Anwendungen, Datenbanken, Backendsysteme simultan betreffen.

Releases durchlaufen mehrere Stufen und Umgebungen, bevor sie in Produktion gehen. Jedes  Deployment ist mit bestimmten Prozessen (manuelle und/oder automatisierte) verbunden und muss dementsprechend geplant und koordiniert werden. Für diesen Zweck gibt es Produkte wie UrbanCode Deploy und UrbanCode Release. Mit UrbanCode Deploy lassen sich Deployments über alle Stages hinweg automatisieren. Release setzt noch eine Ebene höher an und koordiniert, welche Änderungen an welchen Artefakten, auf welchen Umgebungen und zu welcher Zeit durchgeführt werden. Dadurch erhält man ein zentrales Tool zur Verwaltung eines Anwendungslebenszykluses. Die darunterliegende Infrastruktur kommt im Idealfall aus der Cloud – womit wir wieder bei PureApplication System wären. Aufbauend auf den zuvor erstellten System Patterns lässt sich damit die Bereitstellung von Umgebungen vergleichsweise einfach automatisieren.

 


image

Quelle: Sehenswerte Slideshare-Präsentation von Sanjeev Sharma [4]

 

Zusammengefasst ergibt sich aus den drei vorgestellten Produkten ein sehr mächtiges Set an Werkzeugen um eine Continuous Delivery Pipeline aufzubauen: UrbanCode Software für Release and Deployment Management, PureApplication System als Cloud Provider und Chef für die Infrastruktur-Konfiguration.
Die Implementierung dieser Lösung allein macht zwar aus Dev und Ops noch kein DevOps. Die Automatisierung großer Teile des Anwendungslebenszykluses nimmt aber viele Routineaufgaben ab und schafft Zeit für die wirklich schwierigen Aufgaben.

 

 

[1] http://velocityconf.com/velocity2013/public/schedule/detail/28446

[2] http://www.heise.de/newsticker/meldung/Studie-Continuous-Delivery-ist-De-facto-Standard-fuer-Software-Entwicklung-2100842.html

[3] https://www-304.ibm.com/software/brandcatalog/ismlibrary/details?catalog.label=1TW10SO0M#tab-details

[4] http://www.slideshare.net/Urbancode/deliver-contuniously-to-cloud

Magic Worker

25. September 2012 Posted by Thomas Wedel

Sind wir nicht alle dann und wann Magic Worker?
In meinen langen Jahren bei der IBM, fühlte ich mich von Zeit zu Zeit wie einer, der Wunder vollbringen soll - zuweilen gelingt mir dies sogar.
Im Frühjahr diesen Jahres durfte ich den PureApplication System-Launch in Deutschland begleiten. Dabei wurde ich mit technischen Details konfrontiert,
welche manch einem die Ohren schlackern lassen. Mir ging es da etwas besser - mein Informatik Background hält mich seit meinem Studium zuverlässig,
in jeder technisch kniffligen Frage, über Wasser. Auch meine Tätigkeit als Field Marketing Leader für den Produktbereich WebSphere,
der sich rund um die Themen Application Infrastructure, Integration und Middleware dreht, verschaffte mir Einsichten, durch die ich das eine oder
andere aus dem Hut zaubern konnte.
Und genau das Produkt, dessen Geburt ich miterlebte, hilft nun auch anderen dabei, Wunder zu vollbringen.

Denn Wunder gibt es nicht nur in weit entfernten Galaxien


Ich möchte an dieser Stelle eine beliebte Szene aus Star Trek erinnern: Das Schiff ist kaputt und Captain Kirk fragt seinen Chefingenieur Scotty,
wie lange es dauern wird, bis die Systeme wiederhergestellt sind. Seine Antwort lautete: "Acht Wochen, Sir. Aber Sie haben keine acht Wochen,
also werde ich es für Sie in zwei Wochen erledigen." Daraufhin fragte Kirk, ob Scotty alle seine Schätzungen mit
vier multiplizieren würde. Dieser antwortet: "Natürlich. Wie sonst wäre ich in der Lage, meinem Ruf als Wundertäter gerecht zu werden?"
- Hier fühlte ich mich mit Scotty sehr verbunden, weshalb mir diese Szene im Gedächtnis blieb.-

Was würdet Ihr als Dienstleister tun, wenn Euer Kunde einige sehr anspruchsvolle Anforderungen hat und Ihr nicht das Glück besitzt, einen Scotty im
Maschinenraum zu haben? Die Lösung könnte ein weiterer "magic worker" genannt PureApplication System sein!

MAGIC WORKER -- PureApplication System


Für euer Hintergrundwissen hab ich ein paar Informationen gesammelt:
PureApplication System wurde entwickelt, um eine hohe Verfügbarkeit zu gewährleisten. Auf der Hardware-Ebene können geplante und unerwartete Ausfälle
durch Design minimiert werden. Wir können sehen, dass alle Komponenten redundant aufgebaut sind. Jeweils zwei Einheiten von Rechenknoten, Speichern,
Netzwerken, Stromversorgungen und Management-Knoten verhindern einen Single Point of Failure im System. Wenn eine dieser Komponenten ausfällt, kann sie
ohne Ausfallzeit ersetzt werden. Das System erkennt neue Einheiten und bereitet deren Nutzung automatisch vor.

Geplante Ausfallzeiten, aufgrund von Wartungsarbeiten am System und Code-Updates, sind mit PureApplication System kürzer und weniger riskant. Der Grund
dafür ist, dass es nicht mehrere Korrekturen für einzelne Teile sind. Sie erhalten immer ein Update für das gesamte System. Stellt Euch vor, wie viel Zeit
und Geld für regelmäßige Wartung eingespart werden könnten, wenn es nur einen Patch für die gesamte Infrastruktur gäbe.

Durch Virtualisierung ist das System in der Lage, Scale-out-Anwendungen dynamisch und on-demand zu bearbeiten. Wenn der Anwendungsserver maximal ausgelastet
ist, werden zusätzliche Instanzen automatisch gestartet, um einen Engpass auf der Hardware-oder Middleware-Ebene zu vermeiden. Die Bereitstellung einer hohen
Elastizität ist nicht neu, aber im PureApplication System bereits integriert und extrem einfach anzuwenden.

Scotty hätte sich sicher über das uns zur Verfügung stehende System gefreut und damit seine eigenen Wunder noch beeindruckender wirken lassen.