Die Entwicklung (besser: Neuentwicklung) von Intune zu einem der führenden weltweiten Clouddienste

Mit dem folgenden Blogbeitrag weiche ich einmal von den Gepflogenheiten bei Microsoft ab und spreche über etwas, was eigentlich nur für interne Zwecke bestimmt war.

Eine erste Frage drängt sich auf: „Warum veröffentlicht Microsoft diese Informationen überhaupt?“

Ganz einfach: Während der Transformation zu einem digitalen Unternehmen berichten mir Kunden immer wieder von den Schwierigkeiten, die ihre IT-Teams (und IT-Leiter) bei der Skalierung von Infrastruktur oder Anwendungen haben – nicht nur in der Cloud, sondern auch auf dem Weg dorthin.

Diese Bedenken kann ich nur allzu gut nachvollziehen, weil ich selbst einmal in dieser Situation war.

In diesem Artikel erfahren die Leser, wie Microsoft seinen weltweiten Clouddienst aufgebaut hat. Wer weiß, vielleicht dienen die Informationen manchem Leser als Bauplan für die Umsetzung einer eigenen Cloudlösung.

Die Intune-Architektur wurde aus der Cloud und für die Cloud entwickelt. Das Ergebnis ist einer der weltweit führenden Mobilitätsdienste mit einzigartiger echter Cloudskalierung.

Mit dieser Architektur sind unsere Kunden bestens aufgestellt, um ihre Ziele zu erreichen sowie Daten und geistiges Eigentum zu schützen – bei gleichzeitig grenzenloser Produktivität und Skalierung.

Es ist schon eine außergewöhnliche Erfahrung, ein Projekt ganz einfach (sprichwörtlich mit Datei -> Neu) zu beginnen und zu einem hochgradig skalierbaren Clouddienst auszubauen, der jeden Tag Milliarden von Transaktionen verarbeitet.

Die Entwicklung von Intune war eine dieser seltenen und lohnenden Erfahrungen.

Diesen Blogbeitrag widme ich aber vor allem den Entwicklern, die mit ihrer Genialität zum Erfolg beigetragen haben. Treffender kann man es nicht sagen.  Wenn wir uns heute den großen (und wachsenden) Markt für Mobilitätsverwaltung ansehen, dann sticht Intune als echter Clouddienst heraus. Auch andere Hersteller beanspruchen für sich, dass sie ein Cloudmodell bieten, aber ihre Lösungen sind schlicht und einfach nicht als Clouddienst konzipiert.

Das Intune-Entwicklungsteam ist eines der Teams bei Microsoft, von dem viele wissen wollen, wie es Intune zu einem derart hochklassigen Clouddienst gebracht hat. Als wir mit Intune starteten, war Azure nicht mehr als eine aufkeimende Idee in den Köpfen einiger visionärer Entwickler. Deshalb basierte die Architektur zunächst nicht auf Azure. Das änderte sich mit den explodierenden Benutzerzahlen im Jahr 2015. Von da an wussten wir, dass wir Intune zu einem modernen Azure-Dienst umgestalten müssen, der auf einer cloudbasierten Microservice-Architektur basiert.

Dies erwies sich in der Folge als wegweisende Entscheidung.

Rückblickend gesehen, war diese Entscheidung absolut naheliegend:  Mit dem Anstieg vom zweistelligen auf den dreistelligen Millionenbereich und schließlich auf Milliarden von Geräten und Anwendungen schien eine cloudbasierte Architektur die einzige Lösung zu sein, die die erwartete Zuverlässigkeit, Skalierbarkeit und Qualität bieten konnte. Außerdem wären unsere Entwicklungsteams ohne eine cloudbasierte Architektur nicht in der Lage gewesen, schnell genug auf Kundenanforderungen zu reagieren.

Seit der Umstellung von Intune haben mich zahllose Kommentare von Kunden erreicht, die überrascht von der neuen Zuverlässigkeit und Leistung sowie der Geschwindigkeit sind, mit der wir innovative Funktionen bereitstellen.

All dies verdanken wir der Architektur.  Die Architektur ist das, worauf es wirklich ankommt.

Um zu dieser Überzeugung zu gelangen, investierten wir Hunderte von Stunden in die Evaluierung anderer Lösungen, bevor wir uns für die Neugestaltung von Intune entschieden. Dabei analysierten und prüften wir eingehend verschiedene Konkurrenzlösungen, um herauszufinden, ob sich der Kauf lohnen würde. Allerdings war keine dieser Lösungen als Clouddienst konzipiert – nicht eine einzige. In allen Fällen handelte es sich um ein klassisches lokales Client-Server-Produkt, das in einem Rechenzentrum gehostet und lediglich als „Clouddienst“ bezeichnet wurde.

Dies konnte unmöglich der Weg zu einer Hyperscale-Architektur sein.

Das Vorhandensein der Versionsnummer liefert schnell die Antwort, ob es sich um ein Client-Server-Modell oder einen Clouddienst handelt. Wenn der Produktname etwa „Produkt X v8.3“ lautet, weiß man sofort, dass dies kein Clouddienst sein kann.  Ein Clouddienst – mit teilweise mehreren Updates täglich – hat niemals eine Versionsnummer.

Ich bin gespannt auf die Zukunft von Intune und damit auf einige Szenarien, die nur in Clouddiensten vorstellbar sind. Unser Intune-Entwicklungsteam bietet bereits heute Lösungen für Probleme, über die die Konkurrenz noch nicht einmal nachdenkt. Gleichzeitig baut unser Team sein Know-how immer weiter aus, um die Anforderungen von Kunden noch schneller vorherzusehen und zu erfüllen.

Als Entwicklungschef habe ich die unglaublich spannende Aufgabe, die Zukunft der Services und Werkzeuge in diesem Sinn mitzugestalten. Dabei geht es auch darum, wie wir neue Projekte und Herausforderungen unserer Kunden am besten unterstützen.

Falls Sie noch kein Intune-Kunde sind, nehmen Sie sich bitte einige Minuten Zeit, diesen Artikel zu lesen. Für Fragen stehen wir anschließend gerne zur Verfügung.

 


 

Der Weg von Intune zu einem hochgradig skalierbaren, weltweit verteilten Clouddienst

 

Die Erfolgsgeschichte von Intune, einer Komponente von Enterprise Mobility + Security (EMS), begann in der zweiten Jahreshälfte 2015 und machte Intune zum wachstumsstärksten Dienst in der Geschichte von Microsoft. Die ersten Anzeichen dieses schnellen Geschäftswachstums machten sich in einem ebenso rasanten Anstieg der Back-End-Vorgänge bemerkbar. Zur selben Zeit gestalteten wir außerdem mehrere Bereiche unseres Diensts innovativ um – direkt in Intune, in Azure sowie in weiteren verbundenen Lösungen. Für unser Intune-Projekt war es eine interessante und schwierige Herausforderung, Innovationen und schnelles Wachstum in kurzer Zeit ins Gleichgewicht zu bringen. Neben der Eindämmung von Risiken arbeiteten wir daran, der Konkurrenz in Sachen Skalierung und Leistung einen Schritt voraus zu sein. Gerade das schnelle Wachstum hat uns bestärkt, unsere ausgereiften und skalierbaren, global verteilten Clouddienste noch schneller zu entwickeln. In den Folgemonaten realisierten wir einige wichtige Veränderungen in der Architektur und im Betrieb unserer Dienste.

In dieser vierteiligen Blogreihe beschreiben wir die Wandlung der Intune-Clouddienste zu einem der am höchsten entwickelten und skalierbarsten Clouddienste unter Azure. Heute ist Intune einer der bestentwickelten und meistgenutzten Dienste, den wir in den Schlüsselbereichen Verfügbarkeit, Zuverlässigkeit, Leistung, Skalierbarkeit, Sicherheit und Agilität laufend verbessern.

Architektur, Hintergrund und unsere schnelle Maßnahmen zur Steigerung der Kundenzufriedenheit wirken sich positiv auf unser Unternehmenswachstum aus.

  1. Proaktive Maßnahmen und Aktionen von Microsoft, die den Weg zu schnellem Wachstum ebnen
  2. Maßnahmen zur Entwicklung eines hochverfügbaren und skalierbaren Diensts, der anderen erstklassigen, hochskalierbaren Diensten in nichts nachsteht
  3. Entwicklung eines zukunftsweisenden Diensts, der einen neuen Standard für diverse hochskalierbare Vorgänge in verteilten Systemen setzt

Neben einer Zusammenfassung unserer Erfahrungen enthält jeder der vier Blogs eine kurze Beschreibung des Themas. Das Thema des ersten Artikels aus der vierteiligen Reihe wird im nächsten Abschnitt vorgestellt. Die übrigen drei Themen werden in den kommenden Monaten in einem eigenen Beitrag behandelt.

Hintergrund und Architektur

Im Jahr 2015 bestand Intune aus zwei Arten von Diensten: 1) lokalen Diensten auf physischen Computern in einem privaten Rechenzentrum und 2) verteilten Azure-Diensten. Stand 2018 hatten wir alle Intune-Dienste zu Azure migriert. In diesem und zukünftigen Blogs beschäftigen wir uns ausschließlich mit verteilten Diensten unter Azure. Die Migration lokaler Dienste von physischen Computern zu Azure folgt einem ganz anderen Muster. Dies könnte Gegenstand eines zukünftigen Blogs sein. Im weiteren Verlauf dieses Abschnitts geht es um den Hintergrund und die Architektur im Jahr 2015.

Die globale Architektur

Die Intune-Clouddienste setzen auf der Azure Service Fabric (ASF) auf. Alle Dienste werden in einem ASF-Cluster bereitgestellt, der aus einer Gruppe von FE (Front-End)- und MT (Middle-Tier)-Knoten besteht. Die FE-Knoten werden auf A4 SKU (14 GB, 8 Kerne) und die MT-Knoten auf A7 SKU (56 GB, 8 Kerne) gehostet. Ein Cluster arbeitet vollständig isoliert und unabhängig von anderen Clustern. Der clusterübergreifende Zugriff ist ausgeschlossen, da die Cluster unter völlig unterschiedlichen Abonnements und in separaten Rechenzentren gehostet werden. Weltweit gibt es 18 solcher ASF-Cluster, die auf drei Regionen verteilt sind: Nordamerika (NA), Europa (EU) und Asien-Pazifikraum (AP). Auf jedem ASF-Cluster werden identische Dienste bereitgestellt und identische Funktionen ausgeführt. Es gibt zustandslose Dienste und partitionierte zustandsbehaftete Dienste. Abbildung 1 zeigt die globale Architektur.

Abbildung 1: Globale Intune-Cluster (auch bekannt als Azure Scale Unit, ASU) – Architekturansicht (2015) SKU (14 GB, 8 Kerne). Die MT-Knoten werden auf A7 SKU (56 GB, 8 Kerne) gehostet.

Aufschlüsselung der Clusterarchitektur

Jeder Cluster verfügt über mehr als 5.000 Dienste, die in Kombination mit ~80 Einzeltypen zustandsloser Microservices und ~40 Einzeltypen zustandsbehafteter Microservices ausgeführt werden. Bei zustandslosen Diensten werden mehrere Instanzen auf allen FE-Knoten ausgeführt, für die der Azure Load Balancer als Router fungiert. Zustandslose Dienste und einige wichtige zustandsbehaftete Dienste werden auf MT-Knoten ausgeführt. Zustandsbehaftete Dienste basieren auf einer In-Memory-Architektur, die wir intern als No-SQL-Datenbank umsetzen. (Zur Erinnerung: Wir sprechen hier über das Jahr 2015).

Den zustandsbehafteten In-Memory-Speicher haben wir als Kombination aus AVL-Strukturen und Hashsets implementiert, um extrem schnelle Schreib- und Abrufvorgänge, Tabellenscans und Sekundärindexsuchen zu ermöglichen. Diese zustandsbehafteten Dienste sind für die horizontale Skalierung partitioniert. Jede Partition verfügt über fünf Replikate zur Gewährleistung hoher Verfügbarkeit. Eines dieser fünf Replikate fungiert als primäres Replikat, in dem alle Anforderungen verarbeitet werden. Die übrigen vier Replikate sind sekundäre Replikate, die vom primären Replikat repliziert werden. Einige unserer Dienste setzen eine hohe Konsistenz bei Datenvorgängen voraus. Deshalb muss ein Quorum von Replikaten gegeben sein, um Schreibvorgänge ausführen zu können. In diesen Szenarien hat CP (Datenkonsistenz) im CAP-Theorem Vorrang vor AP (Hochverfügbarkeit). Wenn also kein Quorum von Replikaten zustande kommt, können keine Schreibvorgänge ausgeführt werden, was zur Nichtverfügbarkeit führt. Bei einigen unserer Szenarien ist eine mögliche Konsistenz ausreichend, sodass AP Vorteile gegenüber CP hat. Aus Gründen der Einfachheit ist die Architektur aller unserer Diensten jedoch auf hohe Konsistenz ausgelegt. Die CP-Anforderungen sind also umfänglich erfüllt.

ASF bietet in vielerlei Hinsicht eine solide Grundlage, z. B. beim Packaging von Services im Cluster. In der Regel werden auf jedem MT-Knoten zwischen 30 und 50 Prozesse ausgeführt, die mehrere zustandsbehaftete Replikate hosten. Außerdem steuert ASF die komplexe Verwaltung und Orchestrierung von Failoverplänen und Datenverschiebungen zwischen Replikaten. Hinzu kommen rollierende Upgrades für alle unsere Servicebereitstellungen und der Lastenausgleich im Cluster. Wenn das primäre Replikat nicht mehr existiert, stuft ASF ein sekundäres Replikat automatisch zum primären Replikat hoch. Außerdem wird ein neues sekundäres Replikat erstellt, um die erforderlichen fünf Replikate bereitzustellen. Durch das neue sekundäre Replikat wird eine vollständige Speicher-zu-Speicher-Datenübertragung vom primären zum sekundären Replikat initiiert und durchgeführt. Außerdem sichern wir Daten regelmäßig in einer externen persistenten Azure-Tabelle bzw. persistentem BLOB Storage. Die RPO für die Wiederherstellung von Systemen, in denen alle Replikate von einem Notfall oder Partitionsverlust betroffen sind, beträgt 10 Minuten. Abbildung 2 zeigt eine Darstellung des Clusters. Abbildung 2 zeigt eine Darstellung des Clusters.

Abbildung 2: Azure Scale Unit von Intune (auch bekannt als Cluster oder ASU). Architektur: Stand 2015.RPO zur Wiederherstellung von Systemen, in denen alle Replikate von einem Notfall oder Partitionsverlust betroffen sind. Abbildung 2 zeigt eine Darstellung des Clusters. Abbildung 2 zeigt eine Darstellung des Clusters.

Probleme

Wie oben erwähnt, verzeichneten wir zeitgleich mit dem rasanten Anstieg der Nutzung (von etwa drei Mrd. Transaktionen auf sieben Mrd. Transaktionen pro Tag) zwischen Ende 2015 und Anfang 2016 eine deutliche Zunahme des Datenverkehrs bei unseren Back-End-Services. Aus diesem Grund konzentrierten wir uns auf taktische Lösungen, um Soforthilfemaßnahmen für die damit einhergehenden Probleme einzuleiten.

Problem Nr. 1

Als Erstes wurde uns klar, dass wir aussagefähige Telemetriedaten und ein Warnsystem benötigten. Der Umfang der benötigten Telemetriedaten änderte sich jedoch ständig aufgrund der zugrunde liegenden Azure-Infrastruktur. Und auch die sofortige Nutzung der Telemetriedaten wurde durch Fristen für allgemeine Verfügbarkeit und weitere Faktoren erschwert. Aus taktischer Sicht mussten wir deshalb sehr schnell einige Instrumentierungs-/Diagnoselösungen einführen, um genügend Daten für die Risikominderung zur Hand zu haben. Sobald die richtige Telemetrielösung verfügbar war, begannen wir mit der Erhebung von Daten, um die kritischsten Probleme zu beseitigen.

Schnelle Investitionen in Telemetrie haben sich also in großem Stil ausgezahlt. Außerdem waren wir in der Lage, taktische Lösungen genauer zu beleuchten und in einem schnellen iterativen Prozess zu entwickeln. Diese kurzfristigen, aber sehr sinnvollen Investitionen in Telemetrie führten auch zur Entschärfung der übrigen Probleme.

Problem Nr. 2

Durch die Telemetrie erkannten wir, dass einige Partitionen große Datenmengen bewältigen mussten. In einer einzigen Partition sind manchmal Millionen von Objekten gespeichert, und die clusterübergreifenden Transaktionsraten belaufen sich täglich auf bis zu 6 Mrd. Transaktionen. Mehr Daten bedeuten jedoch auch einen erhöhten Datenverkehr, insbesondere wenn sekundäre Replikate aufgrund der Löschung oder des Lastenausgleichs vorhandener primärer/sekundärer Replikate hinzukommen. Je größer das Datenvolumen, desto länger dauert die Erstellung des sekundären Replikats und desto höher sind die damit verbundenen Speicher- und CPU-Kosten.

Ein Großteil dieser Zeit wird für die Serialisierung/Deserialisierung von Daten aufgewendet, die während des Rebuildvorgangs zwischen den Replikaten übertragen werden müssen. Da ein Datenvertragsserialisierer zum Einsatz kam, evaluierten wir die Leistung mehrerer Serialisierer und entschieden uns am Ende für die Lösung von Avro. Mit Avro konnten wir den Durchsatz und die CPU-Leistung um 50 % steigern und die Rebuildzeit drastisch verringern. Bei der Übertragung von 4 GB Daten waren unsere Rebuilds, die früher bis zu 35 Minuten dauerten, beispielsweise schon in <= 20 Minuten abgeschlossen. Dieses Ergebnis war zwar noch nicht optimal, erfüllte für Sofortmaßnahmen jedoch seinen Zweck. In meinem nächsten Blogartikel werde ich beschreiben, wie wir den Zeitaufwand auf unter 20 Minuten senken konnten.

Problem Nr. 3

Mit der Ausweitung der Nutzung kamen auch neue Datenverkehrs- und Suchmuster für unsere Algorithmen hinzu, die nicht auf höchste Effizienz (CPU/Arbeitsspeicher) ausgelegt waren. Auf der Basis von AVL-Strukturen entwickelten wir effiziente Sekundärindexsuchen, die bei einigen Suchmustern jedoch noch ausbaufähig waren. Wir gingen davon aus, dass die Sekundärindexstrukturen in der Regel viel kleiner als die Hauptstrukturen sind, die für vollständige Tabellenscans verwendet werden, und deshalb allen unseren Anforderungen genügen. Bei einigen Problemen mit der CPU-Auslastung fiel uns ein Datenverkehrsmuster auf, das die CPU zeitweise bei bestimmten Sekundärindexsuchen blockierte. Weitere Analysen zeigten, dass Paging- und Order-By-Suchen in einem Sekundärindex mit Millionen von Objekten zu extrem hoher CPU-Auslastung führen können und sich auf alle Dienste in diesem Knoten auswirken.

Aufgrund dieser wichtigen Erkenntnis entwickelten wir sofort einen alternativen Algorithmus. Für Paging- und Order-By-Suchen haben wir einen MaxHeap-Ansatz entwickelt und implementiert, der die AVL-Struktur ersetzt. Die Zeitkomplexität für Einfügungen und Suchen ist bei MaxHeap um eine Größenordnung besser. Bei der Einfügung von 1 Mio. Objekten verringerte sich die Zeit von 5 Sekunden auf 250 Millisekunden und bei Order-By-Befehlen (also der Sortierung) erzielten wir bei 1 Mio. Objekten eine Verbesserung von 5 auf 1,5 Sekunden. Aufgrund der Anzahl von Suchabfragen, bei denen diese Vorgänge eine Rolle spielen, erzielten wir durch diese Verbesserung erhebliche Einsparungen bei der Speicher- und CPU-Nutzung im Cluster.

Problem Nr. 4

Die größten Auswirkungen auf das Wachstum beobachteten wir bei Bereitstellungen/Upgrades. Diese Effekte haben sich weiter verstärkt, als unsere FE- und MT-Knoten im Rahmen des planmäßigen Betriebssystem-Patchings von Azure neu gestartet wurden. Die Knoten wurden Upgradedomäne für Upgradedomäne (UD) neu gestartet. Eine UD hatte 20 Minuten Zeit, ihren ordnungsgemäßen Betrieb aufzunehmen. Danach ging es mit dem Upgrade der nächsten UD weiter.

In Zusammenhang mit Upgrades beobachteten wir zwei Problemkategorien:

  • Die Replikatanzahl für zustandsbehaftete Dienste war gleich der Anzahl von UDs (in beiden Fällen 5). Beim Upgrade einer UD musste ASF alle Replikate dieser UD auf eine der vier übrigen UDs umlagern. Gleichzeitig mussten verschiedene Bedingungen erfüllt werden: z. B. die ordnungsgemäße Verteilung bei der Platzierung von Replikaten in Fehlerdomänen, die Bereitstellung primärer/sekundärer Replikate auf getrennten Knoten und vieles mehr. So kam es bei Upgrades zu ziemlich vielen Replikatverschiebungen und einer hohen Replikatdichte. Wie unter Problem Nr. 2 oben erwähnt, dauern einige Rebuilds bis zu 20 Minuten. Manche sekundären Replikate sind also möglicherweise noch nicht vollständig betriebsbereit, wenn das nächste UD-Upgrade ansteht. Dies führte am Ende zu einem Quorumsverlust, weil während der Upgrades keine ausreichende Anzahl von Replikaten aktiv war, um die Schreibanforderungen auszuführen. Abbildung 3 zeigt, wie sich Änderungen in der Replikatdichte beim Upgrade auswirken. Der steile Anstieg von ~350 auf ~1.000 Replikate, den wir bei einem unserer Dienste beobachteten, veranschaulicht das Ausmaß an Rebuildaktivitäten. Unsere sofortige Überlegung war, die SKU für die Knoten zu erweitern, aber die zugrunde liegende Plattform unterstützte keine direkten Upgrades der SKU.  Dazu wäre ein Failover auf einen neuen Cluster (d. h. eine Datenmigration) erforderlich gewesen. Da dies jedoch eine sehr komplexe Angelegenheit ist, verwarfen wir die Idee wieder. In einem meiner nächsten Blogartikel beschreibe ich, wie wir mit dieser Einschränkung umgingen.
  • Die Intune- und ASF-Teams beschäftigten sich eingehend mit diesem Problem und ermittelten zusammen mit dem ASF-Team die optimale Konfiguration. Diese bestand aus vier Replikaten mit fünf UDs, sodass eine UD immer verfügbar ist, um zusätzliche Replikate aufzunehmen, und um übermäßige Replikatverschiebungen zu vermeiden. Dies machte sich in einem deutlichen Anstieg unserer Clusterstabilität und in einem Rückgang der Replikatdichte (3x Delta) um 50–75 % bei Upgrades bemerkbar.

 

Abbildung 3: Auswirkungen von Replikatanzahl und Replikatdichte beim Upgrade

 

Schließlich stellten wir fest, dass wir eine bessere Balance zwischen der Replikatanzahl und der Speichernutzung in unserem Cluster erzielen könnten. Einige Knoten hatten eine hohe Auslastung, während andere nahezu inaktiv waren. Logischerweise führte dies bei Spitzenlasten oder Upgrades zu einer übermäßigen Belastung der stark beanspruchten Knoten. Unsere Lösung bestand darin, Kennzahlen, Berichte und Konfigurationsoptionen für den Lastenausgleich in unseren Clustern zu implementieren. Die Auswirkungen lassen sich am besten in den Abbildungen 4 und 5 erkennen. Die blauen Linien zeigen den Stand nach unseren Verbesserungen, und die X-Achse enthält die Knotennamen.

 

Abbildung 4: Replikatanzahl pro Knoten vor und nach der Optimierung des Lastenausgleichs

 

Abbildung 5: Speicherauslastung pro Knoten vor und nach der Optimierung des Lastenausgleichs

 

Unsere Erfahrungen

  • Aus diesem Projekt nehmen wir vier wichtige Erfahrungen mit, die meiner Ansicht nach auf jeden größeren Clouddienst übertragbar sind:
  • Telemetrie und ein Warnsystem haben eine Schlüsselrolle in jedem Servicedesign. Überwachen Sie Telemetriedaten und Warnmeldungen, und nehmen Sie iterative Verbesserungen in einer Testumgebung vor, bevor Sie die Funktion Ihren Kunden zugänglich machen.
  • Analysieren Sie Abhängigkeiten. Wenn Sie Ihre Skalierungslösung nicht auf die abhängige Plattform abstimmen, kann für nichts garantiert werden. Wenn Ihre Lösung beispielsweise horizontal von 10 auf 500 Knoten skaliert werden soll, muss diese Erweiterung auch von der abhängigen Plattform (Azure, AWS usw.) unterstützt werden. Das Gleiche gilt für die erforderliche Dauer. Wenn Ihre Lösung jeweils nur um wenige Knoten erweitert werden kann, müssen Sie Ihre Reaktionsmechanismen (Warnungen usw.) anpassen, um sie auf die Verzögerung abzustimmen. Ein ähnliches Prinzip gilt für die vertikale Skalierung. Wenn Sie in diesem Fall ein SKU-Upgrade planen, muss die abhängige Plattform ein direktes Upgrade von der vorhandenen, weniger effizienten SKU auf eine leistungsfähigere SKU unterstützen.
  • Überprüfen Sie regelmäßig, ob Ihre Annahmen noch stimmen. Viele Dienste und Plattformen in der Cloud befinden sich noch in der Entwicklung. Manche Annahmen, die vor wenigen Monaten noch richtig waren, können aus verschiedenen Gründen längst nicht mehr gültig sein. Dazu zählen das Design/die Architektur der abhängigen Plattform, bessere/optimierte Alternativlösungen, veraltete Funktionen und vieles mehr. Es empfiehlt sich daher, wichtige Codepfade auf Änderungen in Datenverkehrsmustern zu überwachen, um sicherzustellen, dass Design, Algorithmen oder Implementierung noch ihren Zweck erfüllen. Nutzungsmuster für den Datenverkehr in Clouddiensten können und werden sich ändern. Deshalb müssen auch wenige Monate alte Lösungen überprüft und ggf. durch eine effizientere Lösung ersetzt werden.
  • Legen Sie den Schwerpunkt auf Kapazitätsplanung. Führen Sie vorausschauende Kapazitätsanalysen durch, und prüfen Sie die Ergebnisse in regelmäßigen Abständen. Dies macht bei Skalierungsproblemen, die sich auf den Kunden auswirken, den Unterschied zwischen reaktivem und proaktivem Handeln aus.

Fazit

Die Implementierung und das Rollout aller oben beschriebenen Lösungen dauerte etwa drei bis vier Monate. Bereits im April 2016 waren wir sehr optimistisch, weil wir in der Stabilität, Verfügbarkeit und Zuverlässigkeit von Clustern bereits große Verbesserungen erzielt hatten. Dies zeigte sich auch in den Reaktionen unserer Kunden, die sich sehr positiv über unsere Fortschritte in puncto Zuverlässigkeit und Stabilität äußerten. Der erste vielversprechende Schritt war geschafft. Nun mussten wir die gewonnenen Erkenntnisse in weitere Erfolge und Verbesserungen umwandeln. Der Weg zu einem hochentwickelten und skalierbaren verteilten Clouddienst hatte erst begonnen.

Die in diesen Blogartikeln beschriebenen Merkmale und Funktionen können je nach Markt unterschiedlich sein. Ausführliche Informationen zu den Produktangeboten für Ihren Markt finden Sie unter Microsoft 365, Office 365, Windows 10 oder Enterprise Mobility + Security.
Die mit diesen Beiträgen verlinkten Inhalte stehen möglicherweise nicht in Ihrer Sprache zur Verfügung.