yoshitaka272 - Fotolia
SD-WAN: Warum interne SLAs eine kluge Sache sind
IT-Teams können mit SD-WAN die Netzwerk-Performance beobachten. Interne SLAs, die geschäftlichen Anforderungen besser widerspiegeln, lassen sich so einfacher gestalten.
Ein Service Level Agreement, kurz: SLA, ist eine geschäftliche Vereinbarung, typischerweise zwischen einem Dienstleister und einem Kunden, die auf spezifischen Betriebsparametern basiert. Zwar sollten IT-Teams, die WAN-Konnektivitätsdienste kaufen, SLA-Angaben zu festen Reaktionszeiten, Latenz und Uptime berücksichtigen, doch im Zentrum jeder Kaufentscheidung sollte die praxisrelevante Traffic Performance stehen.
Ein internes SLA wiederum ist eine Vereinbarung zwischen Abteilungen eines Unternehmens, die verschiedene Parameter bietet, die spezieller auf die jeweiligen betrieblichen Gegebenheiten zugeschnitten sind, etwa Anwendungsfluss und Benutzeranforderungen. Diese Parameter beschreiben keine potenziellen Konsequenzen für einen unzureichenden Service, liefern aber die Serviceanforderungen auf Geschäftsebene, die notwendig sind, um negative Effekte wie Einnahmeverluste, zu verhindern.
WAN-Services enthalten nun SD-WAN-Technologie (Software-defined WAN), so dass Unternehmen die entsprechenden Anforderungen einbeziehen müssen. SD-WAN wird häufig als Internet-VPN-Technologie (Virtual Private Network) vermarktet, mit der sich Kosteneinsparungen erzielen und Nutzeranforderungen nach Zugang zu öffentlichen Cloud-basierten Services erfüllen lassen. In der Realität allerdings kann SD-WAN jeden Konnektivitätstyp ersetzen – und, nachfolgend, die vorhandenen SLAs – von Internet-Services über Layer-3-MPLS bis hin zu Layer-2-VPLS (Virtual Private LAN Service).
Wenn Unternehmen SD-WAN basierend auf der Internetkonnektivität einführen, kann ein internes SLA dazu beitragen, die Anforderungen an ihre SD-WAN-Provider in Standard-SLAs festzulegen. Sehen wir uns einmal an, was Unternehmen bei SLAs für SD-WAN Services und bei internen SLAs beachten sollten.
Traditionelle VPN-SLAs versus SD-WAN-Optionen
Ein Service Level Agreement für einen Internet-VPN-Service ist oft auf recht hohem Niveau. Die meisten Provider bieten einen Performance-Indikator als Durchschnitt für jeden beliebigen Monat. Beim Betrachten dieser Durchschnittswerte ist es wichtig, zu verstehen, dass die Ergebnisse ein konstantes Performance-Niveau suggerieren können, obwohl sie in Wahrheit zu bestimmten Zeiten Latenzspitzen enthalten. In einigen Bereichen könnte dies bei der Nutzung wichtiger Anwendungen zu Einnahmeverlusten führen. Erschwerend kommt hinzu, dass das SLA oft lediglich das Core-Netzwerk des Providers abdeckt und den Local Loop nicht berücksichtigt.
Außer der Latenz umfassen andere gängige SLA-Messwerte Paketverluste und die Netzwerk-Uptime, die Provider ebenfalls als Durchschnittswerte ausweisen. Obwohl Durchschnittsangaben häufig von geringem praktischem Nutzen sind, vermitteln sie zumindest eine ungefähre Vorstellung von der WAN-Performance. Aber wenn ein SLA einfach nur eine Angabe zur gewünschten Performance ist, oder bestenfalls eine geschäftliche Vereinbarung, wie gestaltet ein Unternehmen dann ein wirkungsvolles SLA?
SD-WAN ermöglicht es Firmen, ihre eigenen internen SLAs auf Grundlage der erforderlichen Geschäftsfaktoren, wie missionskritischen Traffic oder Anwendungen, zu erstellen. Falls ein Unternehmen beispielsweise Sprach-Traffic priorisieren muss, lässt sich per SD-WAN eine zugrunde liegende MPLS-Transportschicht nutzen, die eine bessere Quality of Service (QoS) im Netzwerk bietet.
Wenn ein Unternehmen Traffic über das Internet sendet, kommt es, verglichen mit MPLS, wahrscheinlich zu einem Verlust der Traffic-Kontrolle. Infolgedessen sollten Unternehmen nach verfügbaren Konnektivitätstypen und dazugehörigen praxisrelevanten Performance-Daten recherchieren, um sich für einen primären SD-WAN-Konnektivitätstyp zu entscheiden. Der Großteil der Provider wird wohl kaum reale Ping-Tests und Traceroutes bieten, doch es lohnt sich bestimmt, die Zahlen anzufordern.
Nachdem ein Unternehmen die primäre Konnektivität festgelegt hat, kann es den SD-WAN-Service konfigurieren, um die Priorisierung von Traffic und Anwendungen vorzunehmen. Falls zum Beispiel die Bandbreite eingeschränkt ist, können Anwendungen, die ein Unternehmen als wichtig einstuft, als erste auf die Route zugreifen.
Darüber hinaus unterscheidet sich SD-WAN durch das granulare Niveau, mit dem es die Priorisierung definieren kann. So wünscht ein Unternehmen vielleicht, dass nur eine bestimmte Gruppe von Usern in Zeiten von Netzwerküberlastung und Paketverlusten bevorzugt behandelt wird oder dass nur bestimmte Traffic-Typen und Nutzer Zugriff erhalten.
Mit Reporting-Funktionen interne SLAs für SD-WAN festlegen
Mit detailliertem Reporting kann ein Unternehmen sein eigenes internes SLA erstellen, das auf einer Konfiguration statt auf einer geschäftlichen Vereinbarung basiert. Durch die Verwendung von Berichtsstatistiken, die visualisieren, wie das Netzwerk genutzt wird, und durch das Erstellen eines Nutzerprofils, das auf mehr als nur einer IP-Adresse beruht, können IT-Teams wirklich untermauern, wie die Netzwerk-Performance aussieht.
Wenn ein Unternehmen seine WAN-Performance per SD-WAN besser kontrolliert, kann es damit beginnen, SLA-Faktoren für den internen Betrieb zu definieren. Dies unterscheidet sich grundlegend von allgemeinen WAN-SLAs, die einige Zeit erfordern, um Einblick in die Netzwerk-Performance zu generieren.
Anstatt Angaben zu Latenz und Jitter zu nutzen, können IT-Teams bestimmen, welche SLA-Faktoren am besten widerspiegeln, wie sich geschäftliche Anforderungen erfüllen lassen. Sie können interne SLAs basierend auf Faktoren wie Konnektivitätsquelle, -typ und -bedingungen erstellen. SD-WAN bietet IT-Teams zudem die einzigartige Möglichkeit, SLAs pro Anwendung, pro Abteilung oder sogar pro Nutzer zu gestalten. Da SD-WAN mehrere Konnektivitätstypen ersetzen kann, kommt dem internen SLA sogar eine noch größere Bedeutung zu, denn es eignet sich standardmäßig dazu, diverse Technologien und Disaster-Recovery-Situationen abzudecken.
Fehlen aussagekräftige Daten, ist das ursprüngliche Service-Provider-SLA die einzige Möglichkeit, einen grundlegenden Einblick in die Netzwerk-Performance zu erhalten. Noch einmal: Es ist möglich, echte Angaben zur Traffic Performance von potenziellen Providern anzufordern, doch ob deren Vertrieb die Informationen preisgibt, hängt von den jeweiligen internen Richtlinien ab.
WAN-SLAs verschwinden nicht – sie verändern sich nur
Es ist schwierig, ein SLA innerhalb einer Presales-Umgebung festzulegen. Das gilt insbesondere für globale Unternehmen, die mit mehreren Internet-Service-Providern (ISP) oder Network-to-Network Interfaces (NNI) arbeiten. Während Trends wie die Public Cloud dazu beitragen, Workflows effizienter zu gestalten, wächst gleichzeitig die Herausforderung, für eine zuverlässige Traffic Performance zu sorgen.
Das bedeutet, Unternehmen müssen mit dem arbeiten, was ihnen zur Verfügung steht. Außerdem müssen sie sich darauf konzentrieren, Fragen zu stellen, um Einblicke in typische SLA-Faktoren für Netzwerke zu erhalten. Dann sollten sie betrachten, wie ihre SD-WAN-Anbieter aufgestellt sind, um darauf basierend ihre eigenen internen SLAs zu formulieren.
Werden SLAs einfach verschwinden? Das SLA in seiner einfachsten Form ist kaum nützlich, wenn es um SD-WAN-Kaufentscheidungen geht. Aber wenn ein Unternehmen seine Geschäfts- und Netzwerkanforderungen kennt – und die Auswirkungen von schlechter Netzwerk-Performance –, ist es eher in der Lage, sein eigenes internes SLA festzulegen und Service-Providern detaillierte Fragen zu stellen, um sicherzustellen, dass der Service seine Bedürfnisse erfüllt.
Ein wenig Druck durch Stellen der richtigen Fragen sowie ein hervorragendes Netzwerk-Management und -Reporting kann Ihr IT-Team dabei unterstützen, die neue interne SLA-Vision mit SD-WAN zu erreichen.