Informatiker sind schon ein komisches Volk: Hyperaktiv, wenn es um kleinste Probleme geht und immer hilfsbereit – mitunter auch weit über die eigene Belastungsgrenze hinaus.
Man arbeitet schließlich an etwas, was einem Spaß macht.
Dennoch bereitet der Umstieg auf Cloudressourcen manch einem Informatiker ein ungutes Gefühl in der Bauchgegend. Es ist schließlich nicht mehr der eigene, selbst zusammengebaute Server auf dem das Unternehmen läuft, sondern ein System in einem Rechenzentrum mit „geteilten Ressourcen“ – Hardware zum Anfassen ist anders.
Oder?
Mit den aktuellen Veränderungen gerade in der IT fällt es vielen Informatikern schwer, sich in der neuen und „agilen“ Cloud ein solches „Nest“ wie im hauseigenen Rechenzentrum einzurichten.
Im eigenen Rechenzentrum hat man sich eingelebt: auf dem Hypervisor stehen die Images perfekt vorgefertigt bereit, sie enthalten genau die benötigte Konfiguration und beruhen auf jahrelanger Erfahrung.
In Cloud Umgebungen hingegen wirkt alles wie ein Shop. Vorgefertigte Images mit passender Konfiguration für die Cloud liegen bereits vor und das verleitet zur Faulheit. Das antrainierte Wissen kommt nicht mehr zum Zug. Denn in der Cloud Welt funktionieren manche Themen anders als bisher und dadurch kann allein die Recherche zum „WIE?“ ist in manchen Szenarien eine Mammutaufgabe sein.
Dazu kommt, dass diese Images aus dem Cloud-Shop nicht zwangsläufig gleichbleiben.
Diese Shop-Images werden gepatcht und umkonfiguriert. Auch der Shop und dessen Oberfläche wachsen und entwickeln sich weiter.
Aber das tut das Rechenzentrum ebenfalls. Nur musste man sich früher mit den Patches der Storage-Units, denen der Hypervisor, der Switches, der Router und allen anderen, ‚allein‘ rumschlagen.
Das hat auf der einen Seite viel Schweiß gekostet, auf der anderen Seite aber auch eine Bindung hergestellt.
Clusterkonfigurationen über mehrere Rechenzentren waren und sind eine hohe Kunst. Konfigurationsfehler entstehen bei händischer Arbeit viel zu leicht.
Da sind wir wieder am Anfang, bei der jahrelangen Erfahrung und der Arbeit, die in die Konfigurationen geflossen ist bis wir uns wohlfühlten, und bei vorgefertigten Images.
In der Cloud geht alles einfacher
Möchte man also beispielsweise ein Cluster aus mehreren identischen Hosts bereitstellen, dann braucht man einen Bauplan, wie diese auszusehen haben. Diese Konfiguration muss bis auf kleinste Parameter gleich sein.
Es bietet sich also nur bedingt an, diese aus Shop Images zu erstellen und dann zu konfigurieren.
Genauso wie der Hypervisor „zuhause“ bietet Azure aber beispielsweise ein Feature an, welches den fertigen Images einen Platz bietet und das Deployment von identischen Hosts vereinfacht:
Die Azure Shared Image Gallery
Auch Microsoft kocht bei der neuen Azure Cloud mit Wasser. Diese Images liegen auch in Azure auf unserem eigenen Speicher und somit vorerst nur in unserem Tenant.
Speicher in Azure heißt „Storageaccount“ – wir nennen ihn heute „Blob Storage“.
Da dieser die Images bereithält und eine Image-Gallery irgendwann zu einer großen Ansammlung an vorgefertigten Images wachsen soll, sind erste Überlegungen wichtig, allein um die Pflichtfelder der Azure Infrastruktur zu planen:
Fragenkatalog
Wie benennen wir die Ressourcengruppe in der die Images abgelegt werden?
Welche Region wählen wir, um unsere Images zu speichern?
Welche Synchronisationsoptionen nutzen wir?
Welche Namenskonventionen haben wir aktuell für Speicher und wie lassen sich diese auf Azure übertragen?
Wie bekomme ich meinen Speicher sicher?
(zu Role Based Access Control (RBAC) hat mein Kollege Dominic Iselt bereits einen Blogbeitrag verfasst)
Wie liegen Images im Rechenzentrum aktuell ab?
Eine Galerie daraus machen
Eine Image Gallery erstellen wir, wie jede Ressource in Azure, in eine Ressourcengruppe. Es bietet sich an, diese in derselben Ressourcengruppe zu kreieren wie auch den Blob und alle Images.
Danach sind die Imagedefinitionen zu erstellen, hier werden bereits erste Limits des Features sichtbar:
Innerhalb eines „Images“ (in der Gallery) werden dann die Versionen hinterlegt, damit auch diese sauber strukturiert und vor allem vom Administrator verwaltet und gepatcht werden können.
Der Name der Imageversion sollte dem Format Major(int).Minor(int).Patch(int) entsprechen. Zum Beispiel: 0.0.1, 1.5.13
Eine andere Versionssyntax lässt Azure hier nicht zu.
Ein Image erstellen kann man über den Punkt „Images“; hier werden dann nur noch die Blobs aus dem Storage Account verlinkt.
Ein Skript, um neue, generalisierte Images in den Storage Account zu übertragen, stellt Microsoft im Storage-Account Artikel bereit.
Alternativ: via GUI ist dies mit dem Storage Explorer möglich.
