Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 3 Nächste Version anzeigen »

Vorwort

Die Verfügbarkeit von Kommunikationsdiensten ist für viele Unternehmen von höchster Priorität. Mit dem Wandel der Kommunikationsnetze von TDM zu IP-basierten Next Generation Networks (NGN) und der Möglichkeit, die Kommunikationsdienste virtualisiert – in Form gewöhnlicher Serverdienste – bereitzustellen, ergeben sich neue Möglichkeiten der Hochverfügbarkeit und Skalierbarkeit.

Wurden bisher meist Aktiv/Passiv-Gerätekonfigurationen verwendet um den Ausfall eines Primärgeräts abzusichern, stehen heute verschiedene Redundanzszenarien zur Verfügung, die die unterschiedlichen Anforderungen an Service-Level und eventuelle Wiederherstellungszeiten im Disaster Recovery-Fall abdecken.

Die Bereitstellung von Kommunikationsdiensten in Form von IT-Diensten, ist deshalb nicht nur der logische Schluß aus der Konvergenz der Daten- und Kommunikationsnetze, sondern auch das Mittel der Wahl, um hohe Verfügbarkeit und einfaches bzw. einheitliches Management zu garantieren.

Ein virtualisiertes Kommunikationssystem skaliert nicht nur mit den zur Verfügung gestellten Ressourcen, sondern läßt sich auch in vorhandene Backup- oder Disaster-Recovery-Strategien integrieren: Backups, Snapshots, Replikationen, Fault Tolerance und weitere Technologien erlauben es unter Abwägung von Ressourceneinsatz und Komplexität, die geforderte Verfügbarkeit zu erreichen. Dabei lassen sich bereits etablierte Strategien, Richtlinien und Notfallkonzepte unmittelbar auf den Kommunikationsdienst anwenden, was die Komplexität und damit Anwenderfehler reduziert und im Fall der Fälle eine schnelle Wiederherstellung der unternehmenskritischen Anwendung ermöglicht.

Im vorliegenden Konzept gehen wir von einem typischen Mittelstandsunternehmen mit mehreren hundert Mitarbeitern und mehreren Standorten aus, die alle über schnelle Netzwerkverbindungen und eine moderne Serverlandschaft mit VMware-Virtualisierung verfügen. Die Mitarbeiter 

STARFACE VM-Edition


Das STARFACE Kommunikationssystem basiert auf einem CentOS Linux System, auf dem unter anderem der STARFACE Applikationsserver, HylaFax und der CallHandler Asterisk Business Edition arbeiten. Die VM-Edition enthält Integrationstreiber für VMware und Hyper-V und ist ansonsten identisch mit der auf Appliances installierten STARFACE Software.

Eine Kombination aus VM-Edition und physikalischer Appliance ist genauso möglich, wie das Verschieben oder Kopieren einer Instanz in eine STARFACE Cloud (kopiert werden hierbei lediglich die Konfiguration, Datenbankinhalte sowie Faxe und Voicemails – was in Summe nur wenige Megabyte Daten ausmacht und somit sehr schnell vonstatten geht). Auf diese Weise lassen sich sogar mögliche Ausfälle der eigenen Virtualisierungslandschaft berücksichtigen.

Redundanz-/HA-Konzepte

Die Bereitstellung der verschiedenen Redundanzfunktionen fällt bevorzugt in den Aufgabenbereich des Hypervisors. Es handelt sich hierbei nicht um besondere Funktionen des STARFACE Kommunikationssystems.

Im vorliegenden Fall gehen wir von einer zentralen STARFACE VM-Edition aus, was sich aus administrativer Sicht sowie mit Blick auf die Lizenzkosten als vorteilhaft erweist. Außerdem sieht das Konzept die Ergänzung der primären VM-Edition um eine physikalische Appliance vor, um so auch einen Ausfall der Virtualisierungsinfrastruktur mit einer Wiederherstellungszeit von wenigen Minuten abzubilden.

Für die Standorte Frankfurt (FRA), Tettnang (TET) und Bukarest (BUH) wird angenommen, dass die zur Verfügung gestellte virtualisierte Hardware identisch ist (gleiche Art und Anzahl der virtuellen CPU-Kerne). Desweiteren wird angenommen, dass VMware vSphere mit vCenter Server und Site Recovery Manager (SRM) in einem HA-Cluster zum Einsatz kommt.

Lokale Redundanz

Die lokale Redundanz wird über VMware Fault Tolerance (FT) erreicht. Hierbei wird eine identische STARFACE-Instanz synchron innerhalb des VMware-Clusters ausgeführt (Active Secondary). Der Ausfall eines physikalischen Hosts wird automatisch und unterbrechungsfrei kompensiert.

Geo-Redundanz

Bei der geografischen Redundanz, soll primär der Standort Frankfurt, sekundär der Standort Tettnang und tertiär der Standort Bukarest den Betrieb des STARFACE Kommunikationssystems sicherstellen.

Hierfür kommen die Funktionen des VMware Site Recovery Managers (SRM) zum Einsatz: Im Falle eines Ausfalls des primären Standorts, werden Replikate der STARFACE VM-Edition am sekundären oder tertiären
Standort gestartet.

Ein Failover auf geo-redundanter Basis ist in der Regel nicht unterbrechungsfrei, sondern geht meist mit einem Abbruch laufender Gespräche und einem Ausfall der Telefoniefunktion im Bereich von Sekunden bis wenigen Minuten einher. Die Ausfallzeit wird hauptsächlich durch die Konvergenz des jeweils eingesetzten IP-Routingprotokolls bestimmt. Auf Router-Ebene müssen die Verbindungen der Endgeräte/Clients und Mediengateways zur sekundären oder tertiären STARFACE VM (mit identischer IP-Adresse) an einem anderen Standort geroutet werden. Bei Einsatz von OSPF mit BFD können die Konvergenzzeiten jedoch stark reduziert werden.


  • Keine Stichwörter