...
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 "Database" 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 : gespeichertzur 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 "Database" kann auch redundant ausgelegt werden. Hier bieten sich verschiedene Lösungen an:
- 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.
- 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.
- Eine geschickte Kombination aus Lösung 1 und 2. Dies muss im Einzelfall je nach Bedarf geplant werden
Rolle Web Application Server
Die Rolle "Web Application Server" wird von einem oder mehreren CentOS Linux 6.X Server eingenommen.
Rolle Load Balancer
Die Rolle "Load Balancer" wird von einem CentOS Linux 6.X Server eingenommen. Hier werden alle
Rolle Telephony Application Server
Die Rolle "Telephony Application Server" wird von einem oder mehreren (noch) Windows Server 2012R2 Maschinen eingenommen. Hier werden alle
Meta-Rolle Software
Die Rolle "Database" wird von einem oder mehreren Datenbankservern (zur Zeit nur MySQL Version 5.6) eingenommen. Hier werden alle