Azure: Basiswissen für Administratoren

Subscription Design

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Kein Unternehmen kommt beim Einsatz von Azure mit nur einer Subscription aus. In der Regel nutzt man mindestens zwei Subscriptions – eine zu Testzwecken und eine produktive. Grundsätzlich bezahlt man Azure nach dem Prinzip "pay-as-you-go" oder man schließt ein Enterprise Agreement mit Microsoft ab.
11:19

Transkript

Um Azure Services benutzen zu können, brauche ich zu allererst eine sogenannte Subscription. Das bedeutet, es reicht nicht, im Azure Active Directory ein Konto zu haben, , sondern ich muss auch, um Ressourcen erzeugen zu können, Zugriff auf eine bestimmte Subscription haben. Diese Subscriptions werden im Azure Portal beheimatet, innerhalb der sogenannten Abonnement-Übersicht. Dieses Symbol ist übrigens bis vor kurzem noch ein kleines Schlüsselsymbol gewesen. Auch hier sehen wir ein schönes Beispiel dafür, dass sich auf der Azure Plattform sehr schnell, sehr viel verändert. Und wir sehen hier mein aktuell genutztes Abonnement in Form meiner MSDN-Subscription, die ich privat und für Testzwecke benutze. Und darüber wird jeder Cloud-Service abgerechnet unabhängig davon, ob er tatsächlich Kosten verursacht oder ob er das nicht tut. So kann ich jetzt hier transparent nachvollziehen, welche Services mich bestimmte Beträge gekostet haben. Ein Abonnement ist also eine Instanz, auf die ich meine Cloud-Services buchen kann, damit die dadurch entstehenden Kosten im Laufe des Betriebs entsprechend verbucht werden können. Auf der Ebene einer Subscription kann ich allerdings schon deutlich mehr einstellen als das. Ich kann beispielsweise bestimmte Richtlinien zuweisen auf der Ebene einer Subscription, wo ich beispielsweise die Storage account encryption erzwingen kann oder ich kann das Verwenden von sogenanntem Text erzwingen, so dass jede Dienstinstanz, die in meinem Azure-Mandanten erstellt wird, einem Wert zugewiesen werden muss, um zum Beispiel die Kostenstelle anzuhängen beziehungsweise zu kennzeichnen, ob eine Dienstinstanz testweise angelegt worden ist zu Quality Assurance-Zwecken oder ob das produktiv ist. Natürlich kann man zu der vorhandenen Subscription noch weitere Subscriptions anlegen. Das passiert entweder nach dem herkömmlichen pay-as-you-go-Verfahren, sprich, es wird nach Monatsende das abgerechnet, was tatsächlich an Betriebskosten für Ihre Azure Services entstanden ist, oder Sie treffen mit Microsoft ein sogenanntes Enterprise Agreement, worauf wir am Ende des Videos noch einmal zu sprechen kommen. Die zentrale Frage in diesem Video zielt auf das sogenannte Subscription Design ab, also wie viele Abonnements benötigen Sie für Ihr Unternehmen, um Azure effektiv nutzen zu können. Das hängt in erster Linie an der Größe Ihres Unternehmens beziehungsweise hängt von der Struktur Ihres Unternehmens ab. Eine hilfreiche Quelle sind die Richtlinien für Azure Abonnements, wie sie in dem Fall in der offiziellen Dokumentation von Microsoft Azure zu finden sind. Wenn wir etwas weiter hinunterscrollen, sehen wir ein paar Beispiele. Hier sehen wir die Firma Contoso, die ein Enterprise Agreement mit der Firma Microsoft abgeschlossen hat, die verteilt ist auf unterschiedliche Kontinente und unterteilt ist in unterschiedliche Business Units beziehungsweise Abteilungen, die jeweils eine eigene Subscription haben. Rein von der Logik her kann man sich eine Subscription vorstellen als ein eigenes virtuelles Datacenter innerhalb der Microsoft Azure Cloud. Grundsätzlich muss es natürlich immer mindestens ein Konto geben, welches die Ownership auf eine bestimmte Subscription inne hat beziehungsweise die Subscription besitzt, um diese konfigurieren zu können, so wie wir das vorhin gesehen haben. Wichtig ist zu begreifen, dass diese Konten beziehungsweise Accounts immer im Azure Active Directory beherbergt sind und dass diese Konten auf Basis von einer bestimmten Domain laufen, das heißt, wenn Sie in das Azure Active Directory hineingehen und dann einen Blick in die Benutzerverwaltung werfen, können Sie das sehr schön beobachten, dass jeder Account auf Basis von einer Domain läuft, weil wir sind hier ja im Internet. Dementsprechend ist es wichtig, dass Sie Standarddomain, in dem Fall ist das kukonfigpoint.onmicrosoft.com, an diesen Konten dran lassen und möglichst auch Konten benutzen, die personell übertragbar sind. In dem Fall würden wir also nicht Max Mustermann oder Thomas Müller @kukonfigpoint.onmicrosoft.com verwenden. Das sind die Richtlinien, die hier im Sinne von Übertragbarkeit eingehalten werden sollten. Das Thema Ausfallsicherheit spielt natürlich auch eine Rolle. Wenn ich hier eine Custom Domäne wie zum Beispiel konfig.de einsetzen würde und diese Domäne zerbricht beziehungsweise die Validierung geht kaputt, dann kann es im schlimmsten Fall passieren, dass der Subscription-Account beziehungsweise das Konto, was diese Subscription besitzt, sich nicht mehr im Portal einloggen kann. Wenn ich jetzt also eine Dienstinstanz, zum Beispiel, für eine virtuelle Maschine erzeugen möchte, werde ich hier relativ frühzeitig nach der Subscription gefragt. Das heißt, wir nehmen uns jetzt einen Windows-Server vom Typ Windows-Server 2012 r2 Datacenter, und hier sehen wir gleich in einem der ersten sogenannten Blades die Frage nach dem Abonnement, auf das wir diesen virtuellen Server denn gerne buchen möchten. Und natürlich ist auch jede bestehende virtuelle Maschine einem Abonnement zugeordnet, sowie wir das hier in dieser Tabelle sehen können. Positivierweise sind wir in Azure mittlerweile in der Lage, uns eine sogenannte Ressourcengruppe herauszugreifen, die die virtuelle Maschine beheimatet, als sozusagen logischer Container oder als eine Art Ordner, so kann man sich das vorstellen. Und dann hat man hier die Möglichkeit, eine Ressourcengruppe in ein anderes Abonnement zu verschieben. Das Ganze passiert beziehungsweise ist auch möglich auf der Ebene der eigentlichen Dienstinstanz. Auch hier gibt es die Möglichkeit, beispielsweise eine virtuelle Maschine in ein anderes Abonnement zu verschieben, sofern ein zweites Abonnement existiert. Obwohl wir, wie gezeigt, in der Lage sind, einen Cloud-Service beziehungsweise eine virtuelle Maschine von einem Abonnement in ein anderes Abonnement zu verschieben, ist in Azure, Planung durchaus ein wichtiger Aspekt, denn es kann passieren, dass Sie eine Cloud-Infrastruktur aufbauen und Sie hinterher wieder abreißen müssen, weil Sie gemerkt haben, dass Sie nicht gut genug geplant haben. Es gibt bestimmte Parameter und Eigenschaften an Cloud-Services, die sich nachträglich verändern oder verschieben lassen. Das gilt aber nicht für alle Eigenschaften. Man sieht das am Beispiel der New Azure Infrastructure Services implementation Guidelines. Hier sehen wir ein paar Beispiele, wie das aussehen kann. Als Erstes sollte man eine Naming Convention für den Workload, also für den jeweiligen Cloud-Service wie beispielsweise den Storage beziehungsweise die virtuelle Maschine einhalten. Zum Thema Azure naming conventions gibt es noch einmal einen separaten Blogartikel, der einige Beispiele enthält, was Sie über die Suchmaschine Ihres Vertrauens sehr einfach finden können. Als Nächstes wählt man eine Subscription aus, auf die der Service gebucht werden soll. Und anschließend macht man sich, daran einen Storage-Account hochzuziehen, weil ja Daten anfallen. Dieser Storage-Account hat eine bestimmte Redundanzeinstellung, die sich teilweise modifizieren, teilweise nicht modifizieren lässt. Typisches Beispiel ist das Aktivieren der sogenannten Zonenredundanz innerhalb einer Azure Region. Wenn ich das einmal aktiviert habe, kann ich das nicht mehr abschalten. Das ist ein Beispiel für die Planung des Storage-Account-Designs. Dann haben wir das Design des Virtual Networks. Hier müssen wir innerhalb eines Virtual Networks einen Adressbereich festlegen. Wenn dieser sich nachträglich als zu klein erweist, können wir auch das nachträglich nicht mehr ändern. Dementsprechend nehmen Sie einen Adressbereich, der im Zweifel lieber zu groß als zu klein ist. Die sogenannten Cloud-Services gibt es nur noch im sogenannten Classic Azure Portal. Im neuen Azure Portal, dem sogenannten Azure Ressource Manager, gibt es diese nicht mehr. Dementsprechend können wir diesen Punkt überspringen. Und im sechsten Punkt geht es um sogenannte Availability Sets. Availability Sets sind logische Einheiten, die gleichartige Server nach dem Drei-Tier-Prinzip miteinander verbinden, um für eine Hochverfügbarkeit zu sorgen, wenn man beispielsweise einen Web FrontEnd-Server oder einen Applikationsserver durchpatchen möchte, um dafür zu sorgen, dass noch ein zweiter gleichartiger Server vorhanden ist, um die eigentliche Webanwendung oder die Applikation in dem Status Up and running also verfügbar zu halten. Dieses Availability Set hier ist für produktive Server innerhalb von Azure obligatorisch. Das heißt, wenn Sie diese Availability Sets nicht verwenden, verweigert Microsoft Ihnen für diese Server den SLA, das heißt, bei produktiven Servern in Azure müssen Sie diese Availability Sets verwenden. Die einzige Vermeidungsmöglichkeit von Availability Sets ist das Aufbauen der VMs auf sogenanntem Azure Premium Storage. Falls Sie Availability Sets verwenden, ist es wichtig, zu wissen, dass Sie das Zuweisen einer VM zu einem Availability Set nur zum Zeitpunkt des Erstellens der Dienstinstanz zuweisen können. Nachträglich kann das auch hier nicht mehr geändert werden. Im Anschluss vergeben Sie der virtuellen Maschine einen Namen und können beginnen, die Services zu nutzen. Abschließend haben wir noch einen Artikel zum Thema Enterprise Agreement, sprich, eine Möglichkeit, als größeres Unternehmen mit Microsoft eine entsprechende Abmachung über mehrere Abonnements beziehungsweise Subscriptions schließen zu können. Das Ganze umfasst natürlich einen sehr attraktiven SLA. Aber Achtung! Diese SLA ist, wie wir das vorhin besprochen haben, an Bedingungen geknüpft. Sie müssen Ihre Cloud-Services auf eine bestimmte Art und Weise aufbauen, damit dieser vom SLA abgedeckt ist. Grundsätzlich, sehen wir hier, ist Microsoft eine offene Cloud. Das merkt man an den unterschiedlichen sogenannten STKs, die es für alle möglichen Plattformen gibt, um beispielsweise auf dem iPhone oder auf einem Android-Gerät oder auf der Java-Entwicklungsplattform Lösungen bauen zu können, die mit Azure kommunizieren. Last but not least, wird hier geworben mit Server und Speicher unbegrenzt. Grundsätzlich ist es aber wichtig, sich die technischen Limitationen und die sogenannten Limits and Quotas aus Azure in der Dokumentation anzuschauen, was wir im Rahmen dieses Video-Trainings noch tun werden.

Azure: Basiswissen für Administratoren

Lernen Sie das Wichtigste, was Sie als IT-Adminstrator über die Möglichkeiten von Azure wissen müssen.

4 Std. 2 min (31 Videos)
Derzeit sind keine Feedbacks vorhanden...
Hersteller:
Software:
Exklusiv für Abo-Kunden
Ihr(e) Trainer:
Erscheinungsdatum:07.09.2017
Laufzeit:4 Std. 2 min (31 Videos)

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!