Microsoft Azure Ratatouille

Rezept:

• Tenants (Menge: je nach Geschmack)
• Management Group (Menge: je nach Geschmack)
• Subscriptions (Menge: je nach Geschmack)
• Ressouce Groups (Menge: je nach Geschmack)
• Licenses (Menge: je nach Geschmack)
• Accounts (Menge: je nach Geschmack)
  

Puh, das ist aber ein kompliziertes Rezept – mit sehr ungenauen Mengenangaben.
Viele die mich kennen, wissen, dass ich gerne gut esse 😊. Der Bezug zu einem Rezept ist also nicht weit hergeholt. Startet man heute mit der Azure Cloud, so muss man zuerst einmal die Suppe der Verwirrung auslöffeln. Da das ganze «organisch» gewachsen ist und nicht von Beginn an so strukturiert war, würden Böse Zungen behaupten, es sei «Wildwuchs» entstanden.

Tenants

Hups, schnell ist es passiert. Hat man Office 365, besitzt man bereits einen Tenant. Viele wissen das jedoch nicht und erstellen für Azure wieder einen neuen.
Der Tenant stellt die höchste Stufe der Administration im Azure-Versum dar. Der Tenant ist eng verbunden mit dem Azure Active Directory und so erstellt man beim Kreieren eines Tenants eine neue und unabhängige Kopie der Active Directory.

Ein Tenant (Besitzer) kann über mehrere Subscriptions verfügen. Eine Subscription wird einer Azure Active Directory zugewiesen und vertraut den «Identities» in dieser Azure Active Directory.

Man kann auch einen Tenant ohne Subscription erstellen. Man erhält so eine leere Azure Active Directory – Basic. Die Subscription braucht man aber für die Konsumation der Dienste – indirekt das Sammeln des Verbrauchs und somit auch der Rechnungsstellung.

PS: Nicht zu verwechseln mit dem aktuellen Film «Tenet».

Subscription

Theoretisch ein logisches Gebilde, welche es mir ermöglicht, Azure Ressourcen zu erstellen und zu konsumieren. Oft verglichen mit einer SIM-Aktivierung. Je nach Typ hat man eine «Free Subscription» z.B. Azure Pass, Pay-As-You-Go (Post-Paid) oder eine Pre-Paid mit einer Aufladung.

Ein Tenenat kann mehrere Subscriptions haben. Diese werden einer Azure Active Directory zugewiesen. Dabei kann eine Subscription nur einer Active Directory zur gleichen Zeit zugewiesen sein.

Haben wir jetzt eine Subscription mit einem definierten «Geld Limit» so werden alle Ressourcen unter dieser Subscription beim Erreichen des Limits «eingefroren/angehalten». Dies ist im Vergleich zu anderen Cloud-Providern eine «Spezialität» von Azure.

Das geschieht nicht bei «Post-Paid» Subscriptions wie «Pay-As-You-Go».

Wann erstelle ich mehrere Subscriptions?

Ich kann mehrere Subscriptions erstellen, wenn ich z.B. Länder, Abteilungen oder Projekte unabhängig voneinander gestalten möchte.
Es gibt auch Firmen, welche den DevOps Ansatz fahren und Subscriptions nach «Umgebung», z.B. Development, Testing und Produktion aufgliedern.

Für eine kleinere Firma ist es auch ein gangbarerer Weg, mit einem «Tenant» und mehreren Subscriptions pro Abteilung zu arbeiten. So erhalte ich einen genauen Überblick, welche Abteilung welche Kosten verursacht.

Moment kurz. Haben wir nicht eine Zutat vergessen? Was ist mit den Management Groups?

Management Groups

Die Management Groups kamen später in das Rezept, als das Azure Ratatouille über die Zeit verfeinert wurde.

Mit der Zeit hat man gemerkt, dass vor allem grössere Unternehmungen eine Vielzahl von Subscriptions erstellt hatten, jedoch gerne einfacher bestimmte allgemeine Richtlinien oder Berechtigungen übergreifend setzten wollten. Stellt euch also ein Gericht vor, das ihr z.B. an das lokale Schärfeempfinden des jeweiligen Landes anpassen wollt, ohne auf die Grundzutaten zu verzichten.

Resource Groups

Vor den Management Groups (2018) hatte man schon die Resource Groups. Diese wurde mit dem «ARM» Modell eingeführt. Mehr dazu und was der Unterschied ist zum alten «ASM» Modell folgt später.

Diese Einheit ist unter einer Subscription und kann dazu genutzt werden, mehrerer Ressourcen zu gruppieren. Dies kann dazu genutzt werden, um später ein Filter auf dem Billing zu erstellen und zu sehen wie viele Kosten durch eine Ressource Group konsumiert wurden. Bitte nicht falsch verstehen. Die Rechnung wird immer noch auf die gesamte Subscription erstellt. Es ist mir nu möglich auf eine Resource Group zu filtern.

Oft werden Ressourcen Gruppen aber dazu gebraucht, Berechtigungen auf die unterliegenden Objekte zu vergeben.

Wenn ich mir so eine Ressourcen Gruppe anschaue in Azure, dann hat Sie ja eine «Location»

Was wichtig zu verstehen ist, dass die Location nur definiert, wo die Metadaten der Ressourcen Gruppe abgelegt werden. Ressourcen können immer noch in anderen «Locations» erstellt werden.

Wie man auf dem folgenden Bild sieht.

Setzten wir jetzt alle Teile des bisherigen Gerichtes zusammen:

Azure Service Manager (ASM) vs ARM (Azure Ressource Manager)

Im ASM Modell war jede Ressource eigenständig für sich. Was dazu führte, dass man ganz genau Buch führen musste, auf welchem Storage man die VM Disks ablegt und wo und wie man die virtual Networks erstellt. Bei grossen Umgebungen endete das in einem Chaos.

Die Übersicht zu behalten, war der reinste Horror. Man musste schauen:

• welche VM’s man z.B. auf welchem «Storage Accounts» abgelegt hatte
• ob man die IOPs Limits von Storage Account erreicht hatte
• etc.

Ein Soufflé backen war dagegen, wie Wasser aus dem Wasserhahn auffüllen.

Die VM wurde in einen «Cloud Service» umhüllt. Dieser war notwendig für den Betrieb einer virtuellen Maschine. Die Instanz erhielt automatisch eine NIC und eine Azure definierte IP Adresse. Weiter wurde automatisch ein Loadbalancer und eine Public IP mit Standard Endpunkten für RDP; PowerShell oder SSH erstellt.

Das Virtuelle Netz, welches wie ein «Anhängsel» war, ermöglichte uns, eine Subnetz Struktur zu erstellen.

Azure Classic ist theoretisch nicht mehr existent. Es war über das alte Portal «manage.windowsazure.com» verfügbar.

Heute wird man auf das neue Portal «portal.azure.com» umgeleitet. Man sieht noch einige Überbleibsel im neuen Portal – falls man solche Ressourcen in der Vergangenheit erstellt hat.

Kurz gesagt, das ARM Modell welches 2014 ins Leben gerufen wurde, ist heute der Standard. Nicht zu verwechseln mit der Prozessor Technologie 😊. Er hat uns die neuen Möglichkeiten von Ressoucengruppen und Management gebracht, welche hier beschrieben sind. Die Möglichkeiten Role Based Access Control auf verschiedenen Ebenen schöner und gezielter zu applizieren, vor allem für grössere Unternehmen.

Eine Übersicht von Compute, Network und Storage Ressourcen, welche über den Ressource Manager deployed wurden:

• SRP: Storage Resouce Provider
• CRP: Compute Resouce Provider
• NRP: Network Resource Provider

Wie man hier sieht, sind alle Ressourcen in einer «Resource Group»
Die virtuelle Maschine referenziert auf einen Storage Account, welcher vom SRP verwaltet wird.

Das Netzwerk wird vom Network Resource Provider zur Verfügung gestellt, ist somit flexibler und nicht fest verdrahtet mit der VM wie beim alten Modell.

Was ist jetzt mit den Lizenzen und Office 365 und Dynamics? Wie verhält sich das? Gerne erkläre ich das in meiner nächsten Kochsendung.

Nützliche Links

Management Groups – Details

Azure Deployment Models (ARM vs ASM)