Ist Microsoft Azure überall?

Immer mehr Unternehmen verlagern geschäftskritische Kommunikationsinstrumente in cloudbasierte Umgebungen. Dies kann ein Rechenzentrum eines lokalen Partners oder eine öffentliche Cloud Umgebung sein. Die wichtigsten Entscheidungsfaktoren zwischen diesen beiden Optionen sind das Vertrauen in den Anbieter und die Kosten der Lösung. Vorfall- und Alarmreaktionssysteme wie beispielsweise Derdack Enterprise Alert, das Ihrer Infrastruktur ein anpassbares Alarmierungs- und Servicemanagement ermöglicht, sind prädestiniert dafür in eine dedizierte Azure Infrastruktur ausgelagert zu werden. Die Frage ist jedoch, wie ich eine solche Infrastruktur planen und dimensionieren soll.

Grundlegende Platzierung und Konfiguration

Azure Rechenzentren sind auf der ganzen Welt verfügbar. Logischerweise ist die priorisierte Platzierung das Rechenzentrum, welches dem Ort, an dem die Alerts erstellt werden sollen, am nächsten liegt. Hauptsächlich um die Latenzzeit zwischen der Ereignisquelle und der Ereignisreaktion zu minimieren. Bei Microsoft Azure ist diese Strategie jedoch nicht in jedem Fall die beste, da es zwei zu berücksichtigende Faktoren zur Platzierungs gibt. Erstens sind nicht alle erforderlichen Dienste in jedem Rechenzentrum verfügbar, weshalb eine vollständige Lösungsarchitektur einschließlich Informationen über VOIP-Kommunikation, SBC-Platzierung, IoT-Hubs verfügen muss, bevor Sie sich entscheiden können.

Der zweite Punkt ist die Anbindung. Alle Azure-Rechenzentren sind über das globale Azure Datalink-System verbunden. Dieses System verbindet jedes Azure-Rechenzentrum der Welt mit Fibrechannel-Leistung und einer maximalen Latenzzeit von 27 ms. Dieses Netzwerk kann jedoch nur über einige Verbindungspunkte in der Welt verbunden werden. Ausgehend vom lokalen Internet-Provider könnte es also besser sein, die Azure-Infrastruktur in einem Rechenzentrum in Amsterdam oder an der US-Ostküste zu platzieren, als dies regional zu tun. Um zu überprüfen, was für Sie am besten funktioniert, können Sie auf azurespeed.com einen Latenztest machen.

Nachdem Sie die Entscheidung über das Hauptrechenzentrum getroffen haben, führt Sie die Art und Weise, wie Sie Ihre Lösung gestalten, zum nächsten Entscheidungsfaktor. In dieser Hinsicht sind mehrere Aspekte wichtig, damit Sie die beste Leistung des Systems erreichen können.

Grundlegende Infrastruktur und Verfügbarkeit

Welche Art von VMs werden für die Infrastruktur benötigt? Die kostenoptimiertesten VM-Typen in Azure sind VMs der A-Kategorie, aber hier werden die Ressourcen gemeinsam genutzt. Sie eignen sich also gut für die Entwicklung und das Testen, sind aber für produktive Arbeitslasten nicht praktikabel.
Basierend auf den Enterprise Alert-Anforderungen ist eine VM der D-Serie oder E-Serie eine gute Praxis für eine solche Infrastruktur. Wichtig zu beachten ist, dass nur VMs der Version 3 verwendet werden sollten, da sie das beste Verhältnis von Prozessor und Speicher bieten. Und verwenden Sie nur VM-Typen mit SSD-Unterstützung, da Sie eine optimale Performance erreichen wollen und Enterprise Alert mit vielen lokalen Dateien und Diensten arbeitet. Eine SSD-Festplatte (Standard oder Premium) ist ein zusätzliches MUSS, damit die Software die beste Leistung erbringen kann.

Als Empfehlung gilt, dass jeder EA Server auf Microsoft Azure mindestens eine D2s V3 (2 vCPU 8 GB Speicher) VM mit einer E6 «Managed Disk» sein sollte. Die Systemfestplatte ist immer auf einer 128 GB Festplatte «Managed Disk». Verwenden Sie keine nicht verwalteten Platten, da die IOPS und die Wartungsplanung auf einem Speicherkonto zu viel sind.

In einem redundanten System benötigt die Infrastruktur zwei VMs in zwei Rechenzentren für die Anwendungsverfügbarkeit. Pro VM benötigen Sie zusätzlich eine Update-Domain und eine Fault-Domain. Die Konfiguration von drei Update-Domains und drei Fault-Domains pro VM bedeutet, dass das EA-System auf drei Racks im Azure-Rechenzentrum und auf drei Servern über die drei Racks repliziert wird. Dies ist genug Sicherheit, um das EA-System vor Hardware-Problemen und Virtualisierung-Host-Updates zu schützen.

Überwachung, Analytik und Systemverwaltung

Azure VMs werden überwacht, jedoch nur vom Virtualisierungssystem aus. Im Standard-VM-Monitoring von Azure gibt es nicht genügend Informationen oder Verfügbarkeitstestoptionen. Wenn Sie also eine EA-Infrastruktur auf Azure planen, müssen Sie einen Log Analytics Workspace und ein Automation Accounts einplanen.

Der Log Analytics Workspace sammelt die Logs des konfigurierten Systeme und ist bis zu 5 GB Logdaten pro Monat kostenlos. In einem redundanten Design mit zwei Servern und einer Datenbank können Kosten anfallen, da in diesem Fall Enterprise Alert eine Menge Logdaten in allen entsprechenden Servicekomponenten erzeugt. Für das Sammeln des EA-Protokolle in Log Analytics benötigen Sie benutzerdefinierte Pfade im Protokollsammelsystem. Weiter müssen die Interpreter-Einstellungen des Protocol Collectors mit Semikolontrennung konfiguriert werden. Andernfalls können die Protokolle Ihrer VoIP-Kanäle nicht für die Abfrage und Analyseberichte verwendet werden.

Für die Automatisierung von Aktualisierungen, Wartung und anderen Konfigurationen (könnte über Desired State Configuration erfolgen) ist ein Automatisierungskonto erforderlich. Einschließlich einer Grundkonfiguration von Aktualisierungswellen und Neustartszenarien. In einer redundanten Infrastruktur mit der Datenbank auf einer Azure SQL DB gibt es keine Ausfallzeit für die Wartung und keine Zeit, die Sie für die Wartung investieren müssen. Alles, was benötigt wird, ist die Testarbeit, die von Ihrem Kunden durchgeführt wird.

Für den Backup-Teil muss ein Recovery-Service-Vault für tägliche Backups des EA-Servers konfiguriert werden. Sie müssen einen RSV (Recovery Service Vault) pro Azure Region einplanen.

Netzwerk- und Datenbankdienste

Jedes Derdack Enterprise Alert-System benötigt eine Datenbank. Normalerweise befindet sich die Datenbank direkt auf der VM. SQL Express ist möglich, wird aber vom Hersteller nicht empfohlen. Auf der Azure-Infrastruktur ist es aus folgenden Gründen meine persönliche Empfehlung, eine Azure-SQL-Datenbank zu verwenden: Wenn der EA-Server ein Einzelsystem auf einem Azure-Abonnement ist, kann es geringe Auswirkungen haben, aber wenn Sie ein redundantes System haben, benötigen Sie normalerweise einen SQL-Server Standard oder eine zusätzliche VM. Weiter richten Sie in Azure-Infrastrukturen normalerweise ein System von HUB / Spoke VNET ein, was bedeutet, dass nicht alle VNETs Zugang zu allen anderen VNETs haben. Da wir eine Infrastruktur in zwei Rechenzentren oder über zwei Regionen hinweg planen, muss es ein HUB / Spoke-Design geben, um den EA Server zu sichern und Zugriffe von außen zu vermeiden. Mit dem Azure SQL Service haben wir die Möglichkeit, Endpunkte in getrennten VNET zu erstellen. Es spielt also keine Rolle, ob die Peerings in Hub/Spoke korrekt sind. Vom DB-Dienst aus richten wir einen klaren Endpunkt in jedem Server- VNET ein und die VM hat eine schnelle Netzwerklatenz, um sich mit dieser Datenbank zu verbinden.

Ein weiterer positiver Punkt ist, dass Sie keine Wartungsarbeiten durchführen müssen und die Datenbank direkt über SQL-Authentifizierung in einer sicheren Tenant Umgebung verbunden werden kann. Der Nachteil ist, dass Sie zuerst den Dienst erstellen und das EA-Installationsprogramm im erweiterten Modus verwenden müssen, um die Verbindung zur Datenbank herzustellen. Um die Kosten zu berechnen: Eine Azure SQL-Datenbank (im DTU-Modus) benötigt maximal eine S1 DTU-basierte DB. Das bedeutet, dass Sie bis zu 20 Datenbanktransaktionseinheiten und 250 GB Speicherplatz für Ihre Datenbank reservieren müssen. Bei dieser Einstellung betragen die Kosten etwa 25$ pro Monat. Zusätzliche SQL-Lizenz sind für die Verbindungserstellung nicht erforderlich. 25$ für eine vollständig verschlüsselte, gespeicherte und lizenzierte Datenbank ist nicht zu viel für die Planung Ihrer nächsten Infrastruktur.

Zusätzliche Dienste und VOIP-Integration

Basierend auf Ihren Anforderungen kann es eine Menge zusätzlicher Komponenten geben, die Sie verwenden könnten. Zum Beispiel ist es keine schlechte Idee, einen Azure Load Balancer zu verwenden, um den Verkehr zwischen einzelnen Servern auszugleichen. Wenn Sie nur reguläres LoadBalancing (IP- und Port-basiert) verwenden, so sollten Sie mindestens den Traffic-Manager-Dienst einbeziehen. Denn alle Dienste innerhalb von Enterprise Alert, mit Ausnahme von VOIP-Diensten, sind webbasiert oder haben ein Protokoll zum Streaming via HTTP/HTTPS zur Verfügen.

Wenn es keine aktive IP- und Port-basierte Verbindung zum EA-Server gibt, die einen Lastausgleich erfordert, sollten Sie besser den Azure Web Application Proxy Service verwenden. Warum ist das besser? Weil Sie bei diesem Service das WAP-Gerät als Ihre Haustür verwenden und den EA-Server vor unerwünschter, direkter und webbasierter Kommunikation schützen können. Dies ermöglicht eine sehr sichere EA-Einrichtung und Sie können von zusätzlichen Optionen wie SSL-Filterung und individuellen SSL-Zertifikaten profitieren. Im Wesentlichen kommunizieren Server und WAP-Gerät mit spezifischen, vom System generierten Zertifikaten, während öffentliche Websites öffentliche Zertifikate haben. Dies kann Ihre Kosten auf der Grundlage Ihrer Sicherheitsanforderungen minimieren.

Tools wie IOT-Hub, Event-HUB oder Service-Queue können integriert und direkt zu Ihrem massgeschneiderten VNET hinzugefügt werden. Für weitere Einzelheiten über die Integration dieser Dienste werde ich einen weiteren Artikel schreiben.

Für einen Erfahrungsaustausch auf der VOIP-Seite des Hauses: Einer meiner Kunden hat ein wirklich grosses VOIP-Szenario. Er möchte alles mit VOIP und Bereitschaftskonfiguration machen. Gewöhnlich wollen Provider nicht zu viele Leitungen, die auf einem Rechner terminieren. Denn sie könnten sehen, dass die Kapazität des EA-Servers knapp wird, weil so viele verschiedene SIP- und VOIP-Trunks/Verbindungen erforderlich sind.

In diesem Fall benötigen Sie lediglich einen dedizierten SBC (Session Boarder Controller). Bei dieser Komponente handelt es sich um eine dedizierte VOIP-Schnittstelle zur Handhabung einzelner SIP-Trunks. Sie wird mit Optionen wie Reaktionsgruppen, Gruppenrufe oder Teams Integration geliefert. Sie kann übrigens direkt in Ihrem Abonnement auf Azure eingerichtet werden. Zum Beispiel bietet Ihnen die Lösung von AudioCodes die Möglichkeit, Ihren eigenen SBC in der Nähe des EA-Servers einzusetzen, unterstützt Ihr Redundanzmodell und erlaubt Ihnen, jeden Oncall-Person-Connector als Endpunkt zu behandeln (anstelle eines VOIP-Servicemodells). Dies erhöht Ihre Leistung erheblich.

All dies wird Sie bei Ihren grundlegenden Scoping- und Projektinformationen unterstützen, damit Sie Ihre EA-Infrastruktur auf Azure bringen können. Um die Dinge etwas besser für Sie zu visualisieren, füge ich das untenstehende Funktionsdiagramm bei, wie Sie Ihre Architektur planen können.

Bitte denken Sie daran, dass sich die Azure Services sehr schnell bewegen und verändern. Um sicherzustellen, dass Sie jede Komponente, ihre Funktionen und Einschränkungen kennen, müssen Sie ein Team haben, das in Vollzeit an der Planung der Azure-Dienste arbeitet. Ausserdem benötigen Sie ein hochautomatisiertes Framework in Ihrem Hinterhof, um für eine hochautomatisierte Infrastruktur zu sorgen. Die Überwachung, Optimierung und Kostenoptimierung erfordern Zeit und Erfahrung, sonst werden Sie nicht die gewünschten Ergebnisse erzielen. Nur um Ihnen ein Beispiel zu geben: Wenn Sie für Ihre Dienste die falschen Festplatten in der falschen Region planen und dann feststellen, dass die IOPs für das, was Sie benötigen, nicht ausreicht, können Sie keine weitere Platten zur Kombination weiterer IOPs hinzufügen, weil Sie das falsche Storage-Konto haben. Ihr EA Server wird also langsam und Ihre Reaktionszeit schlecht sein.

Ein weiterer Punkt ist der gesamte Bereich der Benutzerverwaltung. Microsoft Azure hat einige Einschränkungen, wie zum Beispiel, dass Sie kein Azure Active Directory als Benutzerinformationszentrum für Ihre LDAP-Verbindung verwenden können. Sie benötigen z.B. einen Azure AD DS, um die Schnittstelle zum EA-Server bereitzustellen.

«Azure as a Service» MCP (Managed Cloud Platform) von SmartIT

Als Derdack-Partner und aktiver Teil der Derdack-Community unterstützen wir andere Partner beim Scoping, Einsatz und Management von EA-Infrastrukturen auf Azure. Unsere Beratungsleistungen können direkt für alle Derdack-Partner in Anspruch genommen werden. Als Microsoft CSP Tier 1 Provider haben wir auch die Möglichkeit, Ihnen direkt Subscriptionen, Tenants und Lizenzen für Ihr Kundenprojekt zur Verfügung zu stellen. Dadurch schaffen Sie zusätzlichen Mehrwert für das Enterprise Alert-Setup Ihres Kunden.

Über den Autor

Patrick Fontana
Consultant | Project Manager | Team Lead Azure @ SmartIT Services AG
Beitrag im SmartIT Blog lesen