Unterstützung für mehrere Gateways
Letztes Änderungsdatum des Themas: 2012-01-25
Eine neue Funktion des Vermittlungsservers in Lync Server 2010 ist, dass ein einzelner Vermittlungsserver mehrere Gateways steuern kann. In früheren Versionen konnte ein Vermittlungsserver nur jeweils einem Gateway zugeordnet werden. Ein Gateway kann mehreren Anrufrouten zugewiesen und einem Vermittlungsserver oder einem Vermittlungsserverpool zugeordnet werden. Mehrere Gateways können entweder einem einzelnen Vermittlungsserver oder einem Vermittlungsserverpool zugeordnet werden. In dieser Version richtet sich die Anzahl von Gateways, die ein Vermittlungsserver steuern kann, nach der Verarbeitungskapazität des Servers zu Spitzenzeiten. Wenn Sie einen Vermittlungsserver auf Hardware bereitstellen, die die Mindestanforderungen für Hardware für Lync Server 2010 überschreitet (siehe Unterstützte Hardware in der Unterstützungsdokumentation), kann ein eigenständiger Vermittlungsserver etwa 1.000 aktive Anrufe verarbeiten. Bei der Bereitstellung auf Hardware mit diesen Spezifikationen führt der Vermittlungsserver eine Transcodierung durch, routet jedoch weiterhin Anrufe für mehrere Gateways, auch wenn die Gateways keine Medienumgehung unterstützen.
Wenn Sie eine Anrufroute definieren, geben Sie die Gateways an, die dieser Route zugeordnet sind. Sie geben jedoch nicht an, welche Vermittlungsserver dieser Route zugeordnet sind. Stattdessen verwenden Sie den Topologie-Generator zum Zuordnen von Gateways (und damit Routen) zu Vermittlungsservern. Anders ausgedrückt: Das Routing legt das für einen Anruf zu verwendende Gateway fest, und der diesem Gateway zugeordnete Vermittlungsserver verarbeitet den Anruf.
Eine weitere neue Fähigkeit von Lync Server 2010 ist die Bereitstellung eines Vermittlungsservers als Pool; dieser Pool kann gemeinsam mit einem Front-End-Pool ausgeführt oder als eigenständiger Pool bereitgestellt werden. Wird ein Vermittlungsserver gemeinsam mit einem Front-End-Pool ausgeführt, kann die Poolgröße höchstens 10 sein (die Größenbegrenzung für den Registrierungspool). Diese neuen Fähigkeiten erhöhen die Zuverlässigkeit und Flexibilität der Bereitstellung für Vermittlungsserver, erfordern jedoch entsprechende Funktionen der folgenden Peerentitäten:
PSTN-Gateway. Ein für Lync Server 2010 qualifiziertes Gateway muss einen DNS-Lastenausgleich implementieren, wodurch ein qualifiziertes PSTN-Gateway als Gerät zum Lastenausgleich für einen Pool von Vermittlungsservern fungieren und Anrufe im Pool verteilen kann.
Session Border Controller (SBC). Bei einem SIP-Trunk ist die Peerentität ein SCB (Session Border Controller) beim Anbieter von Internettelefoniediensten (Internet Telephony Service Provider, ITSP). In Richtung vom Vermittlungsserverpool zum SBC kann der SBC Verbindungen von jedem Vermittlungsserver im Pool empfangen. In Richtung vom SBC zum Pool kann der Datenverkehr an jeden Vermittlungsserver im Pool gesendet werden. Dies lässt sich z. B. über den DNS-Lastenausgleich erreichen, wenn dieser vom Dienstanbieter und SBC unterstützt wird. Alternativ können dem Dienstanbieter die IP-Adressen aller Vermittlungsserver im Pool übermittelt werden. Der Dienstanbieter kann diese dann im SBC als separaten SIP-Trunk für jeden Vermittlungsserver bereitstellen. In diesem Fall übernimmt der Dienstanbieter den Lastenausgleich für die eigenen Server. Eventuell unterstützen nicht alle Dienstanbieter oder SBCs diese Funktionen. Darüber hinaus erhebt der Dienstanbieter möglicherweise eine zusätzliche Gebühr für diese Funktion. In der Regel fällt für jeden SIP-Trunk zum SBC eine monatliche Gebühr an.
Alternativ kann der Dienstanbieter einen einzelnen SIP-Trunk zu Ihrem Standort konfigurieren, und Sie können ein Hardwaregerät zum Lastenausgleich zwischen dem SBC und dem Vermittlungsserverpool (oder den im Front-End-Pool verbundenen Vermittlungsservern) bereitstellen. Wenn Sie in dieser Konfiguration einen neuen Vermittlungsserver hinzufügen, muss die Konfiguration des Dienstanbieters nicht geändert werden. (SBC-Redundanz könnte erreicht werden, wenn es sich bei der IP-Adresse des SBC um eine virtuelle IP-Adresse [VIP] handelt, die an verschiedenen physischen SBCs terminiert werden kann. In diesem Fall gibt es einen Wiederherstellungsmechanismus, falls der SBC nicht mehr verfügbar ist.)
IP-Nebenstellenanlage. In Richtung vom Vermittlungsserverpool zum SIP-Endpunkt der IP-Nebenstellenanlage kann die IP-Nebenstellenanlage Verbindungen von jedem Vermittlungsserver im Pool empfangen. In Richtung von der IP-Nebenstellenanlage zum Pool kann der Datenverkehr an jeden Vermittlungsserver im Pool gesendet werden. Da die meisten IP-Nebenstellenanlagen keinen DNS-Lastenausgleich unterstützen, wird empfohlen, einzelne direkte SIP-Verbindungen von der IP-Nebenstellenanlage zu jedem Vermittlungsserver im Pool zu definieren. In diesem Fall führt die IP-Nebenstellenanlage den eigenen Lastenausgleich durch, indem der Datenverkehr über die gesamte Trunkgruppe verteilt wird. Dabei wird davon ausgegangen, dass für die IP-Nebenstellenanlage ein konsistenter Satz an Routingregeln für die Trunkgruppe definiert wurde. Ob eine bestimmte IP-Nebenstellenanlage dieses Konzept für Trunkgruppen unterstützt und wie dieses mit der eigenen Redundanz-/Clusteringarchitektur der IP-Nebenstellenanlage funktioniert, muss ermittelt werden, bevor Sie entscheiden, ob ein Vermittlungsservercluster ordnungsgemäß mit der IP-Nebenstellenanlage interagieren kann.
Ein Vermittlungsserverpool erfordert eine einheitliche Sicht des Peergateways für die Interaktion. Das bedeutet, dass alle Mitglieder des Pools über den Konfigurationsspeicher Zugriff auf dieselbe Definition des Peergateways erhalten und dass für alle Mitglieder die gleiche Wahrscheinlichkeit einer Interaktion mit dem Gateway für ausgehende Anrufe besteht. Demzufolge kann der Pool nicht in Segmente aufgeteilt werden, sodass einige Vermittlungsserver bei ausgehenden Anrufen nur mit bestimmten Gatewaypeers kommunizieren. Falls die Notwendigkeit einer solchen Segmentierung besteht, muss ein separater Vermittlungsserverpool verwendet werden. Dies wäre z. B. der Fall, wenn die entsprechenden Funktionen zur Interaktion von PSTN-Gateways, SIP-Trunks oder IP-Nebenstellenanlagen mit einem Pool (wie zuvor in diesem Thema besprochen) nicht verfügbar sind.
Bei einer Lync Server 2010-Bereitstellung wird davon ausgegangen, dass ein bestimmtes PSTN-Gateway, eine IP-Nebenstellenanlage oder ein SIP-Trunkpeer nur von einem einzigen Vermittlungsserverpool abhängt. Anrufe werden vom Lync Server 2010-Front-End-Pool an diesen Pool geroutet, um zu diesem Gatewaypeer weitergeleitet zu werden.
Bei SIP-Trunks, IP-Nebenstellenanlagen und PSTN-Gateways, bei denen ein separater Vermittlungsserverpool verwendet werden muss, kann Redundanz mithilfe des folgenden Schemas erreicht werden:
Zur Auflösung mehrerer Vermittlungsserver, die mit derselben Gatewaypeerentität interagieren, müssen Sie mehrere virtuelle Gateways konfigurieren. Jedem Gateway wird ein anderer FQDN zugeordnet, dessen DNS-Name in dieselbe IP-Adresse aufgelöst wird.
Hierzu wird ein einzelner eigenständiger Vermittlungsserver (z. B. ein Pool mit einem einzigen Vermittlungsserver) verwendet und ein Trunk von einem Vermittlungsserver zu einem virtuellen Gateway definiert. Jeder redundante Vermittlungsserver ist dann für eine Trunkverbindung mit einem anderen virtuellen Gateway zuständig.
Damit dieses Schema für Gatewaypeers mit Unterstützung von TLS funktioniert, muss der FQDN für jedes virtuelle Gateway im Abschnitt für Antragstellernamen oder alternativen Antragstellernamen des Zertifikats enthalten sein, das vom Gatewaypeer bereitgestellt wird.
Die zur Interaktion mit dem Gatewaypeer angewendete Richtlinie ist die Richtlinie, die dem ersten übereinstimmenden Gatewayobjekt im Konfigurationsspeicher zugeordnet ist. Dies sollte kein Problem darstellen, da allen virtuellen Gateways dieselbe Richtlinie zugeordnet wird. (Die virtuellen Gateways sind alle mit derselben physischen Hardwarekomponente verknüpft.)
Lync Server 2010-Routen nutzen verschiedene virtuelle Gateways. Jedes virtuelle Gateway stützt sich auf einen anderen Vermittlungsserver.
Die Anzahl von Gateways, die ein bestimmter Vermittlungsserverpool steuern kann, hängt von der Anzahl von Anrufen ab, die die Medienumgehung verwenden. Wenn die Medienumgehung für eine große Anzahl von Anrufen verwendet wird, kann ein Vermittlungsserver im Pool sehr viel mehr Anrufe verarbeiten, da nur eine Verarbeitung auf Signalebene erforderlich ist.