Cloud: Planen der Anbindung

Eine Dienstleistung in einer Cloud ist innerhalb von Minuten bereitgestellt und dank Internet sofort  nutzbar. Aber selbst für einen Piloten oder eine Validierung wäre es mehr als leichtsinnig erst danach die Frage der Anbindung zu überlegen. Hier geht es um diese Grundlagen.

Das Risiko

Wenn Sie die Planung nicht von Anfang an auf der Agenda haben, dann werden Sie gleich mehrfach überholt. Hier ein paar Beispiele:

  • Wenige EvaluierungsUser machen viel mehr Traffic und stören
    Denken Sie mal daran, wenn jemand ein paar Testkonten mit Office 365 betreibt und "nur mal so zum Test" ein OneDrive mit einigen Gigabyte gefüllt. Wenn ihr Netzwerk darauf nicht vorbereitet ist, werden andere Dienste leiden und/oder die Evaluierung liefert gar keine aussagekräftigen Werte.
  • Schnelle Adoption
    Es wäre nicht das erste Mal, dass der Einkauf im Rahmen einer Vertragsverhandlung schon mal alles auf E3/E5 umstellt und eigentlich die Lizenzen dennoch für den Betrieb On-Premises genutzt werden und dann jemand sagt: "Wenn wir die Lizenzen schon mal haben, dann sollten wir sie auch nutzen". Und schon kommt eine Eigendynamik auf, bei der Sie als "Netzwerkbereitsteller" mit dem Rücken zur Wand stehen.
  • Netzwerk als "Bremser"
    Wir wissen alle, dass die Betreiber des Netzwerks liebend gerne noch dickere Bandbreiten bereitstellen würden aber sie natürlich die Kosten rechtfertigen müssen. Meist scheitert es doch daran, dass die zukünftigen Nutzer sich schwer tun das Volumen und die Anforderungen zu beschreiben. Aber danach immer nur gemeckert wird.
  • Lange Zeiten für Änderungen"
    Anders als Software Updates sind WAN-Links in der Regel nicht mal eben erweitert. Oft sind neue Router aufzubauen oder sogar Leitungen zu beantragen. Das kann auch schnell mal mehrere Wochen dauern. Auch dann sind aktive Komponenten an die Bandbreiten anzupassen, aas mit weiteren Kosten, Aufwendungen und Verzögerungen verbunden sein kann.
  • Änderung von Security-Policies
    Viele Firmen haben Richtlinien, wie ein Zugriff auf Dienste im Internet erfolgen muss, z.B. immer authentifiziert, über einen HTTP-Proxy mit SSL-Inspection und den zentralen Internet Breakout. Mit Cloud-Angeboten ist es ratsam, diese Vorgaben ggfls. anzupassen. Aus Sicht der Information Security wird es gerne als ein "Aufweichen" oder "Lockern" gesehen. Hier ist Diskussionsbedarf.

Vermeiden Sie also durch frühzeitige Planung und Konzeption, dass Sie in diese oder andere Fallen laufen. Eine Firma sollte sehr früh die Anbindung an den Cloud-Anbieter berücksichtigen.

Ich teile dazu diesen Prozess in mehrere Phasen ein, die parallel zu einer Office 365 Einführung oder andere Cloud-Lösung zu bearbeiten sind.

Planen

Dienste bei einem Cloud Anbieter nutzen eine Verbindung zu diesem Anbieter. Also müssen Sie schon für die Evaluierung und Pilot-Phase aber auch später für die Einführung einige Fakten Klären wie:

  • Breakouts, Proxy, Routing und Protokolle
    Welchen Weg gehen die Daten vom Client zum Anbieter und welche Protokolle kommen zum Einsatz? Fast alle Dienste nutzen HTTPS und würden einfach den HTTP-Proxy nutzen. Ist das aber sinnvoll oder muss es sogar geändert werden? Ideal wäre, wenn der Client möglichst vor Ort per NAT über das Internet zum nächten Eingang von Office 365 kommt. Da gibt es aber sicher erst mal ein Veto der Security und oftmals gibt es gar keine dezentralen Ausgänge. Wie gehen Sie mit Protokollen wie RTP um, die vielleicht besser nicht erst in HTTPS eingepackt werden?
  • Namensauflösung
    Klingt trivial aber was passiert, wenn ihr Proxy nicht den DNS-Server ihres Providers sondern z.B. Google-DNS (8.8.8.8, 8.8.8.4) fragt?. Microsoft sieht eine Anfrage von Google und liefert den "nächsten" Zugang ...  von für das Google Subnetz. Das ist vielleicht nicht der beste weg von ihrem Anschluss aus.
  • Sizing, QoS und Drosselung
    Sie wollen Cloud evaluieren oder gar Pilotieren. Dann sollten Sie nicht nur wissen, wie viel Bandbreite die Anwendungen brauchen sondern sie müssen auf einer Seite sicherstellen, dass die Anwendungen die erforderliche Bandbreite "haben" aber auch, dass die Messwerte auch den späteren Produktivbetrieb wiedergeben.
  • Monitoring und Accounting
    Schon früh sollten Sie auch ihr Monitoring anpassen, damit sie die Office 365 Verkehre sehen und erfassen können. nur wer vom ersten Moment an mit protokolliert kann Wachstum und Veränderungen aber auch Ausfälle und Engpässe erkennen.

Sie können natürlich schon bestimmte Vorarbeiten zu Office 365 durchführen wie z.B. das Bereinigen des Active Directory, Festlegungen der zu replizierenden Objekte, Das Beantragen des Tenants und eintragen der Domänen und z.B. die Umstellung des UPN für die spätere Anmeldung des Anwenders. Sie können auch schon Demo-Anwender (Cloud-Only) anlegen und die generelle Eignung

Evaluieren und Anpassen

Wenn die Plattform vorbereitet ist, dann ist der richtige Zeitpunkt gekommen um mit Office 365 oder einem anderen Cloud Angebot zu starten. Bei Office 365 können Sie dann das Office 365 Identity Management und die Authentifizierung implementieren.

Schon diese Verbindungen sollten Sie natürlich im Monitoring (Bandbreite und Firewall-Logs) sehen und entsprechend reglementieren. Mit den ersten Testbenutzern sehen Sie dann auch eine Zunahme des Datenverkehrs und wenn ihre Überwachungslösung gut ist, dann kann Sie neben den aktuell benutzten Bandbreiten (Stichwort NetFlow) auch die Latenzzeiten messen und Engpässe, Unterbrechungen etc. melden.

Sobald ihre Pilot-Umgebung eine gewisse Grundlast hat, können Sie auch Veränderungen an ihrer Netzwerkumgebung (z.B. Proxy umgehen, lokale Internet Breakouts, etc.) umsetzen und die Auswirkungen analysiere.

Das funktioniert natürlich nur, wenn Sie die Bandbreite entsprechend künstlich drosseln. Wenn Sie 10.000 Anwender haben und 100 Piloten mit Office 365 arbeiten, dann belegen Sie nur 1% der Leitung. Um die spätere Produktion realistisch abzubilden, sollten diese Benutzer nicht die komplette Bandbreite nutzen dürfen. Ansonsten ist alles "viel zu schnell und die Realität wird später deutlich schlechter aussehen.

Bestimmte Dienste wie Teams und Skype for Business benötigen nicht nur Bandbreite sondern vor allem schnelle Laufzeiten. Die sind auf "wenig belasteten Leitungen" viel einfacher möglich als auf vollen Leitungen. Siehe dazu auch meine Erfahrungen mit PSTN-Calling Germany)

Wichtig ist zu dem Zeitpunkt auch die Bestätigung der geschätzten Bandbreiten und Kapazitäten. Noch ist niemand "produktiv" und noch können Design-Fehler relativ günstig korrigiert werden. Das kann sogar bis zum Stop des Projekts führen, wenn absehbar ist, dass die Leitungskapazität nicht reichen kann oder Funktionen im Pilot nicht die Anforderungen erfüllen. Es kann aber auch bedeuten, dass vor der Einführung noch kräftige Umbaumaßnahmen und Investitionen erforderlich werden und das Projektkalkulation angepasst werden muss.

Das geht alles noch in einer Pilot und Evaluierungsphase, an deren Ende dann klar ist, wie denn die Einführung und der Betrieb zu erfolgen hat.

Einführen und Betreiben

Das Rollout der Cloud-Nutzung ist natürlich auch noch mal ein gewichtiger Aspekt der Netzwerkanbindung. Je mehr Anwender die Dienste nutzen, desto höher ist die Belastung auf der Leitung. Die Zunahme muss über das hoffentlich schon lange etablierte Monitoring und Verkehrsmanagement beobachtet werden.

Hinzu kommt bei der Einführung natürlich auch die Migrationsdatenmenge, welche von On-Prem in die Cloud übertragen wird und entsprechend zusätzliche Übertragungskapazitäten belegt.

Selbst wenn die Migration abgeschlossen ist und die Anwender ihre Dienste aus der Cloud beziehen gibt es immer neue Herausforderungen, die zu bewältigen sind. In Office 365 gibt es immer neue Möglichkeiten und Anwender werden sicher einige davon auch nutzen ohne sich Gedanken über die Auswirkungen auf die Bandbreite zu machen. So stellt Microsoft Teams andere Anforderungen als Skype for Business und vielleicht nutzt ihre Schulungsabteilung demnächst Office 365 Video (https://products.office.com/en/business/explore-office-365-video)

Gerade die "Netzwerkabteilung" bekommt dadurch immer erst etwas mit, wenn Anwender sich beschweren. Diese "Feedback-Loop" müssen sie effektiver gestalten. Das frühere "Lokale LAN" hatte fest immer ausreichend Reserven und nur im eigenen WAN war offensichtlich, dass es mal langsamer sein konnte. Dass das früher lokal vorgehaltene Postfach nun aber unbemerkt in die Cloud verlagert wurde, weiß der normale Mitarbeiter nicht und will es auch nicht wissen. Er wird sich aber beschweren, wenn die Reaktionszeit nicht passt.

Das sind nur ein paar Anregungen sich auch über die Betriebskonzepte von Office 365 hinsichtlich der LAN/WAN-Verbindung, Firewalls, Proxy-Server und Leitwegen Gedanken zu machen. Am Anfang ist Office 365 ein bequemer Weg komplexe Dienste über die Cloud einfach bereit zu stellen. Interessant wird es mit einem Horizont von mehreren Jahren die Qualität hoch zu halten.

Weitere Links