OCS Hochverfügbarkeit

Diese Seite versucht einen ersten Einblick in die höhere Verfügbarkeit von OCS zu geben aber eine schlüsselfertige Lösung will und kann ich hier nicht anbieten.

Heute machen sich immer mehr Firmen Gedanken über die Verfügbarkeit ihrer Server. Durfte früher ein Mailserver auch mal einen Tag "offline" sein, so ist dies heute kaum noch zu tolerieren. Microsoft hat Exchange über die Jahre entsprechend weiter entwickelt. für OCS gilt dies natürlich auch. Ihre Anwender werden sehr schnell die Vorteile zu schätzen wissen und merken natürlich sofort, wenn der OCS-Server ausgefallen ist. Insbesondere, wenn die Funktion "Telefonie"  mit ins Spiel kommt, dann muss OCS natürlich eine vergleichbar gute Verfügbarkeit bereitstellen, wie die Anwender dies von einer Telefonanlage schon lange gewohnt sind.

Die wenigsten Firmen werden heute eine "redundante" Telefonanlage haben. Aber die meisten Telefonanlagen sind von sich aus z.B. modular ausgelegt, so das Defekte nur Teilbereiche berühren und viele TK-Firmen haben natürlich ein mehr oder weniger funktionierendes Vertriebs- und Servicenetz, um Fehler schnell zu beheben.

Aber auch Server und Netzwerke sind nicht erst seit gestern "kritisch" und müssen entsprechend Verfügbarkeit sein. Kaum eine Firma dürfte einen Ausfall ihrer IT-Systeme über mehrere Stunden schadlos überstehen. Allerdings sind TK-Anlagen bei all ihrer Funktionsvielfalt doch deutlich weniger Komplex als ein Computernetzwerk. TK-Anlagen können, abgesehen von ein paar Zusatzfunktionen, immer nur Gespräche vermitteln während ein Server je nach Konfiguration sehr viel unterschiedlicher eingesetzt werden kann. Hier muss sowohl bei der Hardware, der Konfiguration der verschiedenen Rollen und Funktionen als auch dem Betrieb Rücksicht genommen werden.

Redundanz in Hardware

Redundanz in Hardware ist der billigste und unter Strich einfachste Weg, um die Verfügbarkeit eines Servers anzuheben. Es sollte sich von selbst verstehen, dass sie hier nicht den kleinsten und billigsten Server kaufen sollten, sondern einen Mindeststandard nicht unterschreiten dürfen. Es macht einfach keinen Sinn, dass ein Server z.B. wegen einem Netzteil oder Lüfterdefekt einige Stunden ausfällt und sie nur für die Ersatzteilversorgung dann viel Geld in einen 4h Vor-Ort-Service investieren. Also

  • ECC Ram
    Damit triviale Bit-Fehler nicht per Bluescreen den Server ausfallen lassen und das Bios defekte Module nach einen Neustart Ausblenden kann
  • RAID
    Festplatten sind immer ausfallgefährdet und ohne RAID sollten Sie keinen Server betreiben
  • Redundante Netzteile an zwei Phasen (eines an einer uSV)
    Auch der Aufpreis für zwei Netzteile ist nicht mehr so groß in der Serverklasse, dass Sie darauf verzichten wollen.
  • Backup
    Eine Sicherung hilft nicht nur den ausgefallenen Server schnell wieder herzustellen, sondern auch eine alten Konfiguration wieder einzuspielen. Auch ein Export der Konfiguration per LCSCMD gehört hierzu
  • Netzwerk
    Oft wird übersehen, dass es ohne den Switch im LAN nicht geht. Ein Switch ist relativ günstig und sie sollten zumindest zwei Switche haben, so dass im Notfall die wichtigen Server weiter angeschlossen sein können

Das sind nur ein paar Grundregeln. Ausschlaggebend ist natürlich ihre persönliche Risikoabschätzung.

Redundante Frontend Server

Wer OCS verfügbar betreiben will, muss bis OCS 2007 R2 die Enterprise Version der Server installieren, welche auf eine möglichst geclusterte SQL-Datenbank auf einem anderen Server zurückgreifen kann. Die OCS 2007 R2 Standard-Version (und früher) unterstützt immer nur eine lokale SQL-Express-Instanz. Wer also "hochverfügbare" Lösungen für OCS sucht. kommt heute nicht an einem Gespann aus vier Servern als Grundausstattung vorbei:

  • Server 1 + Server 2
    2x Windows Standard Server
    2x OCS Enterprise als Frontend Server
  • Server 3 und Server 4
    2x Windows Enterprise als Windows Cluster konfiguriert
    2x SQL-Cluster mit einer Shared Disk für die Datenbank

Nicht mitgerechnet sind hier natürlich die ebenfalls verfügbar vorgehaltenen Dienste wie Active Directory, Kerberos, DNS etc.) Auch die anderen OCS-Rollen sind noch einmal zusätzlich zu betrachten.

Redundante Standard Server

Nun wird es natürlich Firmen geben, die nicht gleich zwei Frontend Server, optionale Directoren und einen SQL Cluster installieren wollen. Alternativ können Sie natürlich den einen Standard Server betreiben und per Virtualisierung (nicht supportet) oder Standby Server die Ausfallzeit reduziere. Um hier eine gewisse Verfügbarkeit zu erreichen, können sie z.B. aber auch zwei Standard Server installieren, die sich die Arbeit teilen. 50% der Anwender sind auf einem Server und die andere Hälfte auf dem anderen Server. Fällt ein Server aus, ist aber jeder zweite Anwender "offline". Hier gib es nun zwei Szenarien:

Szenario Arbeit

Geplante Auszeit

Der Administrator kann vorher die Benutzer auf den anderen OCS-Server umziehen. Dies geht relativ schnell und die Kontaktliste wird sogar mit übertragen. Wenn es sich nicht gerade um zigtausend Anwender handelt, ist der umzug in wenigen Minuten erfolgt und die Anwender merken dies nicht einmal.

Ungeplanter Ausfall

Hier muss der Administrator dann entscheiden, ob der Ausfall länger dauert. Dann kann er Benutzer vom ausgefallenen Server auf den aktiven Server übertragen. Dabei bleiben natürlich die Kontakte in OCS erst einmal auf der Strecke, aber der Anwender sofort wieder weiter arbeiten.
Für diesen Fall kann eine Firma aber vorbeugen, indem Sie regelmäßig die Kontakte der Benutzer mit LCSCMD "sichert" und nach dem umzug im Fehlerfall umzieht

Sie sehen also, dass in einer Umgebung mit zwei normalen Standard Servern der Fall einer geplanten Ausfalls bis zu einer gewissen Anzahl an Anwendern noch bedient werden kann, ohne dass hierfür geclusterte SQL-Server auf Windows Enterprise Server mit SAN für die Shared Disks und OCS Enterprise Lizenzen für die Frontend Server installiert werden müssen.

Auf der anderen Seite eröffnet diese Zwei-Server-Konfiguration in Verbindung mit den ein oder anderen Skripten auch Möglichkeiten im Fehlerfall die Daten zu übertragen, indem Sie z.B. regelmäßig exportiert und bei Bedarf auf dem anderen Server importiert werden. Leider unterstützt OCS keine Replikation der SQL-Inhalte, wie z.B. eine Exchange 2010 DAG/CCR die Daten übertragen kann, so dass hier nur eine manuelle Lösung per Skript weiter helfen könnte.

REM Sicherung der OCS Konfiguration
lcscmd /config /action:export /level:global,pool 
	/configfile:C:\Backup\OCSOrgsettings.xml /poolname:[poolname]

REM Sicherung des Servers
lcscmd /config /action:export /level:machine /
	configfile:C:\Backup\OCSServersettings.xml /fqdn:[Servername]

Denkbar ist hier auch ein Script, welches die Einstellungen pro Benutzer exportiert und nach einem ungeplanten Failover in den neuen Server importiert, z.B. mit DBExImp:

REM Export Kontakte eines Benutzers
dbimpexp.exe /hrxmlfile:contacts.xml /user:<sip URL>

REM Import Kontakte eines Benutzers
dbimpexp.exe /import /hrxmlfile:contacts.xml /user:<sip URL>

Natürlich können Sie auch ihre eigenen Skripte auf Basis von PowerShell und WMI einsetzen

Redundanz mit PSTN-Anbindungen (Mediation/Gateway)

Wenn Sie OCS auch zum Telefonieren nach extern nutzen, dann haben Sie mindestens einen Mediation Server installiert, welcher die Audiodaten der OCS-Clients umsetzt und per SIP an ein Gateway oder einen SIP-Trunk weiter leitet. Ein Ausfall dieser Kette stört die wichtige Telefonfunktion. Wer daher OCS zur Telefonie (und nicht nur RemoteCallControl) nutzt, wird sich überlegen, wie dieser Single Point of failure ersetzt werden kann.

Mit OCS 2007 R2 können sie problemlos einen parallelen Weg einrichten. Sie benötigen einen zweiten Mediation Server, ein zweites Gateway und natürlich einen irgendwie gearteten zweiten Zugang zur Telefonie-Welt. Beide Wege können sogar parallel aktiv sein, so dass bei einem Ausfall dann nur weniger Leitungen zur Verfügung stehen. Die Verbindungen, die aber währen des Ausfalls über die betroffene Leitung gelaufen sind, brechen natürlich erst einmal ab.

So einfach dies sich anhört, so scheitert es in vielen Fällen an den Kosten für die Hardware und natürlich die doppelte Anbindung zur Telekom bzw. dem entsprechenden Provider.

Redundanz mit Edge

Der dritte große Punkt ist die Verbindung nach extern. Der hierzu erforderliche Edge-Server kann natürlich auch doppelt ausgelegt werden. Allerdings müssen Sie dann natürlich auch die Internet Anbindung und die Firewalls alle doppelt und redundant auslegen.

Beachten Sie aber, dass beim Einsatz mehrerer EDGE-Server diese Server nicht mehr per NAT hinter einer Firewall versteckt werden können. Zudem können sie nicht mit NLB die Zugriffe verteilen. Sie benötigen externe Load-Balancer sowohl für die Zugriffe von außen auf den Edge Server aber auch für die Verbindungen von innen.

Verfügbarkeit bei der Administration

Ebenso wichtig sind aber auch die "Soft-Skills". KonfigurationsÄnderungen an einer OCS-Installation müssen sauber geplant und umgesetzt werden und auch die Installation von Updates und Patches für OCS, Betriebssystem oder Gateways kann die Funktion stören und erfordert eine schnelle zielgerichtete Reaktion.

Wenn eine Störung auftritt, muss die Betriebsmannschaft natürlich auch schnell die Ursache finden und beheben, über die entsprechenden Hilfsmittel zur Analyse und Zugänge zu den Systemen verfügen. Bedenken Sie dabei auch, dass sie über entsprechende Eskalationsketten zu externen Dienstleistern mit FernwartungsMöglichkeiten etc. verfügen und das eigene Personal permanent weiter gebildet wird.

All dies sind aber keine OCS-spezifischen Aufgabenstellungen, sondern betreffen allgemein den Betrieb von Infrastrukturen.

TK-Fallback über Mobiltelefon oder Gateway

Selbst wenn alle Systeme hoch verfügbar sind, ist die kein Garant für 100%. Zugegeben, auch ein ISDN-Anschluss ist zwar sehr gut verfügbar aber auch hier gibt es Störungen und Ausfälle. Fällt also ihre eigene Infrastruktur einmal so aus, dass keine Funktion mehr gegeben ist, dann bieten viele Provider eine Lösung derart an, dass die Anrufe an einen nicht mehr aktiven Anschluss auf eine andere Rufnummer umgeleitet werden. Da die Verfügbarkeit von Mobiletelefonen und der Funkabdeckung zumindest in Deutschland flächendeckend ist, können Anbieter die Anrufe z.B.: auf vorgegebene Mobilfunknummern schalten. Umgekehrt können Sie bei einem größeren Ausfall natürlich immer noch über vorhandene Mobiltelefone bei Kunden anrufen.

Selbst bei Ausfall oder der Wartung eines Servers sind die für eine Anbindung zu PSTN installierten Gateways meist unabhängig davon. Einige Gateways erlauben z.B. den Anschluss klassischer Endgeräte über entsprechende Ports (z.B. Audiocodes Mediant 1000/200), die unabhängig von OCS funktionieren. Über diesen Weg haben wir bei Net at Work z.B. im Serverraum einfach in ISDN-Telefon an einen S0-Anschluss angeschlossen.

Weitere Links