Das Rollenmodell des jtel Systems

Ein jtel-System (jtel|ACD oder jtel|IVR oder die Kombination aus beidem) ist nach einem Rollenmodell organisiert. Folgende Rollen sind in einem solchen System definiert:

Rolle Datastore (STORE)

Die Rolle STORE ist im Prinzip ein File-Server, der eine zentral verfügbare Freigabe für alle vom System bereitzuhaltenden und zu speichernden Daten zur Verfügung stellt. Dies umfasst unter anderem:

• Das angepasste Skin (CSS und Logos) für das gesamte System und für die definierten Reseller
• Die Symbole der Elemente der Routingapplikationen
• Die mitgelieferten Systemansagen
• Die mitgelieferten Berichte (ab Version 3.06)
• Die Protokolldateien der Telefonie-Server
• Die hochgeladenen Ansagen der Mandanten
• Die Gesprächsmitschnitte der Mandanten
• Weitere applikations-abhängige Daten

Des Weiteren kann hier auch als zentrale Stelle die Software (R5-Applikationen) für die Telefonie-Server zur Verfügung gestellt werden (Meta-Rolle "Software"). Als Betriebsystem empfiehlt sich CentOS Linux 6.X.

Die Freigabe wird in der Regel mittels CIFS-Protokoll (Samba) zur Verfügung gestellt, damit sowohl Linux- als auch Windows-Maschinen gleichermaßen darauf zugreifen können.

Die Rolle STORE kann auch redundant ausgelegt werden. Hier bieten sich zwei Lösungen an:

1. Vollredundanz mittels GlusterFS mit Samba+CDDB+Gluster-VFS-Plugin: In dieser Lösung übernehmen zwei Maschinen die Rolle. Das Filesystem ist in Echtzeit vollrepliziert. Die Linux-Maschinen greifen mittels nativen FS-Mount auf das GlusterFS zu, die Windows Maschinen greifen mittels SMB/CIFS auf das verteilte FS zu. Diese Konfiguration erfordert eine sehr gute I/O Performance und eine exzellente Netzanbindung, bietet dafür ein hohes Maß an Zuverlässigkeit.
2. Teilredundanz mittels Unison Cron Job und virtueller IP: In dieser Lösung übernehmen zwei Maschinen die Rolle. Die Primäre Maschine ist aktiv und repliziert zyklisch (z.B. alle 5 Minuten) die geänderten Inhalte auf die Sekundärmaschine. Beide Maschinen stellen den File-Share zur Verfügung. Die Primäre Maschine stellt die virtuelle IP zur Verfügung. Bei Ausfall der primären Maschine, kann durch Migration der virtuellen IP die sekundäre Maschine die Rolle übernehmen. Diese Konfiguration ist einfacher einzurichten, erfordert allerdings händische Eingriffe, sowohl beim Failover, als auch bei der Rekonsolidierung.

Rolle Database (DATA)

Die Rolle DATA wird von einem oder mehreren Datenbankservern (zur Zeit nur MySQL Version 5.6) unter CentOS Linux 6.X eingenommen. Hier werden alle Prozeduren zur Business-Logik gespeichert und ausgeführt, die gesamten Konfigurationsdaten (Modellierung) der ACD bzw. IVR und alle Verkehrsdaten gespeichert. Diese Rolle kann (und sollte) auf verschiedenen Servern aufgeteilt werden:

• Primärer Datenbank Server: Auf diesem Server erfolgen sowohl schreibende wie lesende Zugriffe. Er wird sowohl von den Telefonie-Servern als auch von den Web Applikations-Server angesprochen. Dieser Server ist Mindestvoraussetzung und kann notfalls alle Aufgaben alleine Übernehmen.
• Reporting-Slave: Dieser Server erlaubt nur lesende Zugriffe und wird dediziert eingesetzt, um alle Berichte darauf auszuführen. Dies bezieht sich sowohl auf abonnierte als auch unmittelbar angeforderte Berichte. Der Einsatz einen solchen Servers ist optional aber dringend zu empfehlen, da die Queries die den Berichten zu Grunde liegen hoch komplex sind und sich (insbesondere wegen Dead-Locks) sehr negativ bis zu fatal auf die Anrufverteilung auswirken können. Der Einsatz ist praktisch zwingend, sobald bei einem Kunden regelmäßig Berichte während der Geschäftszeiten erfolgen. Der Reporting-Slave wird lediglich von den Webservern angesprochen. In sehr großen Anlagen kann es auch mehrere davon geben, die verschiedenen Gruppen an Webservern zugewiesen werden.
• Statistik-Slave: In sehr großen Anlagen ist es unter Umständen sinnvoll, auch alle Anfragen zur Bereitstellung der Echtzeitstatistiken (Supervisor und Wallboards) auf einem eigenen Datenbankserver auszulagern. Die Belastung daraus ist zwar nicht vergleichbar mit jener die sich aus den Berichten ergibt, aber bei sehr großen Anlagen sollte der primäre Server soweit wie möglich entlastet werden, da er einzig und alleine zuständig für die Anrufverteilung ist. Der Statistik-Slave wird lediglich von den Webservern angesprochen. Der Einsatz eines solchen Servers ist optional.
• Kunden-Slave: Es kommt schon mal vor, dass Kunden ihre eigenen Auswertungsroutinen schreiben. In einem solchen Fall, ist es extrem zu empfehlen, dafür einen dedizierten Slave zur Verfügung zu stellen, da das Risiko extrem hoch ist, dass derartige Anfragen ungewollte Nebeneffekte verursachen. Der Einsatz eines solchen Servers ist optional.

Die Rolle DATA kann auch redundant ausgelegt werden. Hier bieten sich verschiedene Lösungen an:

1. Active-Active mit zwei Server und zwei Rollen-Bezogene virtuelle IP Adressen: In dieser Konfiguration werden zwei Datenbankserver in einer Master-Master Replikation konfiguriert. Die virtuellen IP Adressen repräsentieren jeweils die Unterrollen "Primärer Datenbank Server" und "Reporting/Statistik Slave". Im Normalbetrieb sind die beiden virtuellen IP Adressen je einem der beiden Server zugewiesen, so dass nur auf einem der beiden Schreibzugriffe erfolgen, der andere hingegen die Reporting/Statistik-Funktionen ausführt, wie in einem klassischen Master-Slave Szenario. Fällt einer der Server aus, so wandert seine virtuelle IP Adresse zum anderen Server, der nun dadurch alle Rollen übernimmt. Dadurch leidet die Performance, aber das System läuft weiter.Failover und Isolation kann sowohl manuell als auch über Corosync/Pacemaker automatisch erfolgen. Die Rekonsolidierung muss zwangsweise manuell erfolgen, da die Konsistenz der Master-Master-Replikation wieder hergestellt werden muss. 
2. Active-Passive mit je zwei Server für jede eingeplante Rolle mit Rollen-Bezogenen virtuellen IP Adressen: In dieser Konfiguration werden zwei Datenbankserver in einer Master-Master Replikation für den Primären Datenbank-Server konfiguriert. An jedem dieser Server hängen als Slaves je eine Maschine für die geplanten Slave Rollen. Failover und Isolation der verschiedenen Rollen können sowohl manuell als auch über Corosync/Pacemaker automatisch erfolgen. Die Rekonsolidierung muss zwangsweise manuell erfolgen, da die Konsistenz der Master-Master-Replikation wieder hergestellt werden muss. Diese Konfiguration ist teuer und aufwendig, verursacht aber keine Performance-Einbußen im Falle eines Ausfalls.
3. Eine geschickte Kombination aus Lösung 1 und 2. Dies muss im Einzelfall je nach Bedarf geplant werden

Rolle Web Application Server (WEB)

Die Rolle WEB wird von einem oder mehreren CentOS Linux 6.X Server eingenommen. Der Dienst wird durch eine Java-Applikation unter einen modifizierten JBOSS-AS-7.1 zur Verfügung gestellt. Der Server greift schreibend und lesend sowohl auf die Rolle STORE als auch auf die Rolle DATA zu. Der Zugriff auf das jtel Portal und die jtel SOAP Schnittstellen wird mittels HTTP auf Port 8080 und 8081 (für durch den Proxy bereitgestellte HTTPS Zugriffe) zur Verfügung gestellt. Benutzer-Sitzungen auf das Portal sind an dem jeweiligen Web-Server gebunden. Dies gilt auch für die SOAP v1 Schnittstelle. Die neue SOAP v3 Schnittstelle, die ab Version 3.06 zur Verfügung steht, erlaubt hingegen das Ausführen der SOAP-Abfragen einer Sitzung auf beliebige Web Server.

Rolle Load Balancer (LB)

Die Rolle LB wird von einem CentOS Linux 6.X Server eingenommen. Dieser Server stellt eine zentrale Adresse für den Zugang zum Portal und zu den SOAP Schnittstellen zur Verfügung. Hier erfolgt dann die Verteilung der Anfragen auf die zur Verfügung stehenden Web Application Server unter Berücksichtigung einer gleichmäßigen Lastverteilung, des möglichen Ausfalls einer oder mehrerer Web Server und der Dienst-Spezifischen Einschränkungen. Des Weiteren übernimmt diese Rolle auch das Bereitstellen der mittels TLS verschlüsselten Verbindung über HTTPS. Der Dienst kann sowohl auf HTTP (Port 80) und HTTPS (Port 443) angeboten werden. Eine automatische Umleitung zu HTTPS bzw. spezieller URLs kann hier auch realisiert werden (Beispiele: https://acd.example.com wird umgeleitet zu https://acd.example.com/CarrierPortal/login/reseller/client oder https://acd.exaple.com/admin wird umgeleitet zu https://acd.exaple.com/CarrierPortal/sysadmin/login ) 

Rolle Telephony Application Server (TEL)

Die Rolle TEL wird von einem oder mehreren (noch) Windows Server 2012 R2 Maschinen eingenommen. Diese Server führen folgende Aufgaben aus:

1. Ausführung der Call-Flow-Applikationen (R5-Applikationen ausgeführt vom 8Server) die die Media-Server Komponente ansteuern die die Telekommunikationsfunktionen ausführt. Diese Komponenten können:
   1. In Form der Software "Aculab Prosody S" (SIP oder h323) als Software auf der Maschine jeweils mit installiert sein (Standard-Installation bei den meisten Kunden)
   2. In Form der Software "Aculab Prosody S" (SIP oder h323) als Software auf eine separate Maschine (Linux oder Windows) installiert sein (bis Heute noch nirgendwo realisiert)
   3. In Form von Hardware-Boxen "Aculab Prosody X" (S2M/PRI Schnittstellen mit SS7 oder QSig bzw. SIP oder h323) bereit gestellt (Beispiel Kunden dtms bzw. Weinmann und Schanz)
   4. In Form eine speziell konfigurierten Asterisk Software auf einer separaten Linux-Maschine (bis Heute noch nirgendwo realisiert da noch in Entwicklung)
2. Ausführung von zentralen Verwaltungs- und Steuerfunktionen (R5-Applikationen ausgeführt vom 8Server) wie z.B. Anrufverteilung, Logfile-Cleaning/Moving, Event-Processing, Autologout, Notification, usw.
3. Ausführung von Softwarekomponenten, die zur Zeit nur für Windows zur Verfügung stehen, wie z.B. Innovaphone-Connector, Starface-Connector, TAPI-Connector, E-Mail Connector.

Von diesen drei Aufgaben kann die erste redundant ausgelegt werden, wobei das Zuführen der Telekommunikation (SIP oder POTS) jeweils dafür speziell eingerichtet werden muss. Das Migrieren der zentralen Verwaltungs- und Steuerfunktionen (Punkt 2) muss hingegen manuell erfolgen. Alternativ kann dafür auch ein separater Windows Server eingerichtet werden (genannt Daemon Server). Ist dies mit Windows Server Enterprise Edition erfolgt, so kann mittels zwei solcher Server ein Active/Passive Cluster aufgebaut werden. In der Praxis hat das aber noch niemand gemacht, also liegen hier keine Erfahrungen vor. Dies gilt auch für alle Aufgaben unter Punkt 3.

Genau so wie die Rolle WEB, greift die Rolle TEL lesend und schreibend auf die Rollen STORE und DATA zu. Im Gegensatz zur Rolle WEB ist hier jedoch nur Kontakt zum primären Datenbank Server erforderlich. 

Meta-Rolle Software

Alle Applikationen, die von der Rolle TEL ausgeführt werden, können auf diesen Maschinen lokal installiert werden. Dies hat Vorteile in Bezug auf Performance und Netzwerklast. Es muss dann allerdings zwingend sicher gestellt werden, dass die jeweiligen R5-Applikationen auf allen Maschinen der Rolle TEL den gleichen Stand haben und gleichermaßen vorhanden sind.

Alternativ können diese Applikationen auch zentral bereit gestellt werden. Dies erfolgt in der Regel dadurch, dass die Software auf die Rolle STORE abgelegt wird, was in den meisten Fällen die üblich ist. Dies vereinfacht die Aktualisierung der Software, verursacht jedoch zusätzlichen Netzwerkverkehr und hat Auswirkungen auf die Gesamtperformance.

Referenzen:

• Plattformunabhängige Software zum Bearbeiten der originalen Diagramm-Datei: yEd Graph Editor
• Originale Diagramm Datei (yEd Format)