Spätestens wenn geschäftskritische Anwendungen nicht mehr funktionieren oder länger ausfallen, wird die Frage nach dem Service Level Agreement (SLA) lauter. Doch wie funktioniert das SLA bei Microsoft Azure? Wo finde ich die SLA-Beschreibungen? Wie berechne ich ein SLA, wenn ich mehrere Services nutze? Wer überprüft das SLA? Was wird oft vergessen? In diesem Blog findest Du die wichtigsten Aspekte zum Thema Azure Service Level Agreement.
Microsoft definiert in den Service Level Agreements (SLA) seiner Online Services (inkl. Azure Services) mit welcher Verfügbarkeit und Konnektivität die Services betrieben werden. Dies wird in einem SLA zusammengefasst, das auf monatlicher Basis berechnet und abgerechnet wird. Hierzu veröffentlicht Microsoft auf seiner Website ein Word Dokument in verschiedenen Sprachen, in dem jeder Online Service wie folgt beschrieben wird:
- Ausfallzeit (Downtime; Definiert, wann ein Ausfall vorliegt)
- Betriebszeitprozentsatz (Uptime Percentage; Formel zur Berechnung der Verfügbarkeit)
- Servicegutschriften (Service Credit; Prozentsatz der Servicegutschrift aufgrund einer geringeren Verfügbarkeit)
Es gibt Ausnahmen, in denen die SLAs nicht gelten. Microsoft listet 13 Punkte auf, bei denen Leistungs- oder Verfügbarkeitsprobleme nicht unter die SLAs fallen (z.B. Naturkatastrophen, Kriege, Terroranschläge, Aufstände, staatliche Maßnahmen).
Eine grafische Übersicht der SLAs wurde von Alexey Polkovnikov (Microsoft Cloud Solution Architect) auf dieser Website veröffentlicht. Daraus ist ersichtlich, welche Verfügbarkeit die entsprechenden Azure Services haben, wann die letzte Revision der SLAs stattgefunden hat und eine kurze Info über deren Release Notes. Derzeit ist der Azure Service «Azure DNS» der einzige Service, der mit einer Verfügbarkeit von 100% definiert ist. Danach folgen die Azure Services Apache Cassandra MI, Cosmos DB und Redis Cache mit einem SLA von 99,999%. Danach folgen Azure Services mit einem SLA von 99.995%, 99.99%, 99.95% und 99.9%. Es gibt auch einige Services, die kein SLA haben (z. Bsp.: Cost Management).
Composite SLA
Wenn eine Applikation aus mehreren Azure Services besteht und ein SLA für die Applikation berechnet werden soll, spricht man von einem «Composite SLA». Die Berechnung ist in der Theorie einfach, je komplexer die Applikation und je mehr Azure Services verwendet werden, desto aufwendiger ist die Berechnung des «Composite SLA». Bei seriell verbundenen Services ist das «Composite SLA» kleiner als das kleinste SLA eines einzelnen Azure Services. Ein wichtiger Aspekt bei der Berechnung des «Composite SLA» ist die Netzwerkanbindung von Azure. Wenn deine Verbindung über das Internet läuft, ist keine SLA-Berechnung möglich. Es nützt also nichts, deine Applikation in Microsoft Azure hochredundant auszulegen, wenn die Verbindung über das Internet läuft und die Nutzung nur intern erfolgt. Du brauchst also Services mit einem SLA für die Netzwerkanbindung. Mit Azure Express Route und einem entsprechenden Hub and Spoke Design ist dies möglich. Diese Services haben einen definierten SLA Wert und können im «Composite SLA» mit berechnet werden.
Gerne verlinke ich hier ein Youtube Video, das die Berechnung eines «Composite SLA» sehr gut erklärt. John Savill geht ebenfalls darauf ein, wie ein SLA mit weiteren Instanzen in anderen Verfügbarkeitszonen erhöht werden kann.
Wer überwacht SLAs?
Microsoft veröffentlicht über die Webseite Service Health Status aktuelle Ausfälle in Microsoft Azure, Power Platform und Microsoft 365. Möchte der Kunde Servicegutschriften, ist er für die Überwachung der SLAs verantwortlich. Sollte der Fall eintreten, dass ein SLA nicht eingehalten wurde, muss dies Microsoft mittels eines Supporttickets gemeldet werden. In diesem Ticket muss beschrieben werden, welcher Dienst aus welchem Grund nicht ordnungsgemäß funktioniert hat und die Zeitspanne des Ausfalls. Microsoft wird dies prüfen und gegebenenfalls eine entsprechende Servicegutschrift in einer der nächsten Abrechnungsperioden vergüten.
Fazit
Service Level Agreements sind grundsätzlich kein neues Thema in der Cloud. Es ist jedoch wichtig, die Bedingungen von Microsoft zu kennen, um «Composite SLAs» zu berechnen und die SLAs überwachen zu können. Letztlich müssen die SLAs optimal mit dem Business (Verfügbarkeit vs. Kosten) abgestimmt werden. Je höher die Verfügbarkeit einer Applikation in Azure sein soll, desto mehr Services laufen parallel und desto teurer wird die gesamte Applikation werden.
