Lastenausgleich und Fehlertoleranz für Transportserver
Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Letztes Änderungsdatum des Themas: 2007-10-22
In diesem Thema werden die Lastenausgleichsmechanismen und die Fehlertoleranzoptionen für das Nachrichtenrouting mit Microsoft Exchange Server 2007-Transportservern beschrieben. In Exchange 2007 werden die Lastenausgleichsmechanismen und Fehlertoleranzoptionen für Nachrichtenrouting automatisch ausgeführt, um die Verfügbarkeit von Transportservern für effiziente Nachrichtenübermittlung und -zustellung in der Exchange-Organisation zu erhöhen.
Das Exchange 2007-Routing verwendet deterministische Algorithmen zum Auswählen des kostengünstigsten Routingpfads, über den Nachrichten an Active Directory-Remotestandorte, Sendeconnectors und Remoteroutinggruppen weitergeleitet werden. Weitere Informationen dazu, wie der kostengünstigste Routingpfad berechnet wird, finden Sie unter Informationen zum auf Active Directory-Standorten basierenden Routing.
Nachdem der kostengünstigste Routingpfad zu einem Ziel ausgewählt wurde, eignen sich Lastenausgleichs- und Fehlertoleranzmechanismen für verschiedene Nachrichtenroutingszenarien. Alle Nachrichtenroutingszenarien, in denen Exchange 2007 Lastenausgleich und Fehlertoleranz bereitstellt, verfolgen einen gemeinsamen Ansatz. Wenn mehrere Transportserver verfügbar sind, wird Roundrobin-Lastenausgleich verwendet. Wenn z. B. mehrere Hub-Transport-Server an einem Active Directory-Remotestandort vorhanden sind, bestimmt Roundrobin-Lastenausgleich den Routingpfad. Die Fehlertoleranz wird erreicht, indem eine Verbindung mit dem nächsten verfügbaren Server anhand einer mit Prioritäten versehenen Liste von Servern hergestellt wird, wenn der ausgewählte Server nicht verfügbar ist.
Hinweis
Wenn mehrere Routingpfade zu den gleichen Gesamtkosten führen, führt Exchange 2007 keinen Lastenausgleich in diesen Pfaden aus. Exchange 2007 wählt immer einen Routingpfad aus und leitet alle Nachrichten in diesem Routingpfad weiter. Dieses konsistente deterministische Routing vereinfacht die Problembehandlung von Nachrichtenübermittlungsproblemen.
Nachrichtenroutingszenarien, die Lastenausgleich und Fehlertoleranz unterstützen
In diesem Abschnitt werden die folgenden Nachrichtenroutingszenarien beschrieben, in denen das Exchange 2007-Routing Lastenausgleich und Fehlertoleranz bereitstellt:
Nachrichtenrelay – mehrere Quelltransportserver werden für einen Sendeconnector am gleichen Active Directory-Standort angegeben.
Nachrichtenrelay von einem Hub-Transport-Server an einen Edge-Transport-Server.
Nachrichtenrelay von einem Edge-Transport-Server an einen Hub-Transport-Server.
Nachrichtenrelay an einen Active Directory-Remotestandort.
Nachrichtenrelay von einem Postfachserver an einen Hub-Transport-Server.
Nachrichtenrelay von einem Hub-Transport-Server über einen Microsoft Exchange Server 2003-Routinggruppenconnector.
Nachrichtenrelay an SMTP-Server (Simple Mail Transfer Protocol) eines Drittanbieters.
Hinweis
Exchange 2007 führt niemals Lastenausgleich für verschiedene Routingpfade aus, wobei ein Routingpfad aus IP-Standortlinks, Connectors und Routinggruppenconnectors besteht. Exchange 2007 führt jedoch mit einigen Ausnahmen in den meisten Fällen Lastenausgleich für verschiedene Quellserver oder Zielserver von Connectors und Routinggruppenconnectors aus. Exchange 2007 führt z. B. keinen Lastenausgleich aus, wenn sich die Quellserver für einen Sendeconnector an verschiedenen Active Directory-Standorten befinden.
Nachrichtenrelay, wenn mehrere Quelltransportserver für einen Sendeconnector am gleichen Active Directory-Standort angegeben werden
Der Lastenausgleichsmechanismus, der in diesem Abschnitt beschrieben wird, gilt für alle Arten von Connectors, die für ausgehende Nachrichten auf Edge-Transport-Servern und Hub-Transport-Servern konfiguriert sind, z. B. SMTP-Connectors, fremde Connectors und Routinggruppenconnectors.
Wenn Sie mehrere Quelltransportserver für einen Connector angeben, wird der Lastenausgleich durch Roundrobin erzielt, indem Verbindungen über die Quellserver verteilt werden. Fehlertoleranz wird durch Failover auf den nächsten alternativen Quellserver erreicht, wenn der zuvor versuchte Quellserver für diesen Connector nicht verfügbar ist.
In den folgenden Abbildung ist Sendeconnector C1 für die Verwendung von Hub-Transport-Server A und Hub-Transport-Server B als Quellserver konfiguriert. Wenn der Hub-Transport-Server C Nachrichten an Sendeconnector C1 weiterleitet, wird für die Nachrichtenverteilung Lastenausgleich zwischen dem Hub-Transport-Server A und dem Hub-Transport-Server B ausgeführt.
Mehrere Quelltransportserver für einen Sendeconnector am gleichen Active Directory-Standort
.gif "Zahlreiche Quelltransportserver auf Sendeconnector")
Es erfolgt kein Lastenausgleich, wenn der Server, der Nachrichten mittels Relay weiterleitet, auch als Quelltransportserver für den ausgewählten Connector konfiguriert ist. In solchen Fällen besitzt die Nähe des lokale Servers Vorrang vor der Nähe des lokalen Active Directory-Standorts, und Nachrichten werden immer mithilfe des lokalen Servers weitergeleitet. In dieser Abbildung werden Nachrichten vom Hub-Transport-Server C mittels Relay über den Sendeconnector C1 weitergeleitet, wenn der Hub-Transport-Server C auch als Quelltransportserver für den Sendeconnector C1 konfiguriert ist, anstatt mittels Lastenausgleich die Hub-Transport-Server A und B zu durchlaufen.
Nachrichtenrelay von einem Hub-Transport-Server an einen Edge-Transport-Server
Wenn mehrere Edge-Transport-Server einen Active Directory-Standort abonniert haben, werden alle Edge-Transport-Server als Quellserver einem einzigen Sendeconnector für eingehende Nachrichten auf den Edge-Transport-Servern hinzugefügt. Der Lastenausgleich zwischen den Edge-Transport-Servern wird auf ähnliche Weise wie zwischen mehreren Hub-Transport-Servern für den gleichen Sendeconnector erzielt.
Für das Internet bestimmte Nachrichten werden zuerst an den Active Directory-Standort weitergeleitet, den die Edge-Transport-Server abonniert haben. Der empfangende Hub-Transport-Server an diesem Standort leitet die Nachrichten dann mittels Relay an einen der Edge-Transport-Server weiter, die als Quelltransportserver für den Sendeconnector aufgelistet werden, der für die Verwendung von DNS-Adressauflösung konfiguriert ist. Für Verbindungsanforderungen wird zwischen den abonnierten Edge-Transport-Servern Lastenausgleich durchgeführt. Wenn der ausgewählte Server nicht verfügbar ist, wird ein erneuter Verbindungsversuch mit dem nächsten Edge-Transport-Server unternommen, auf dem der Sendeconnector ausgeführt wird, der für die Verwendung von DNS-Adressauflösung konfiguriert ist.
Hinweis
Das Relay zwischen Standorten findet immer zwischen Hub-Transport-Servern statt. Hub-Transport-Server an Active Directory-Remotestandorten führen kein direktes Relay an den Edge-Transport-Server durch, der einen anderen Active Directory-Standort abonniert hat.
Manuelles Failover eines Edge-Transport-Servers
Es wird empfohlen, mehrere Edge-Transport-Server für einen Active Directory-Standort zu abonnieren, um automatische Fehlertoleranz und Failover bereitzustellen, wenn einer der Edge-Transport-Server offline ist. Wenn Sie nur einen Edge-Transport-Server für einen Active Directory-Standort abonnieren können, müssen Sie eingreifen und die für das Internet bestimmten Nachrichten manuell über einen anderen Active Directory-Standort weiterleiten, wenn der Edge-Transport-Server offline ist.
Wie die folgende Abbildung zeigt, können Sie den * Connector manuell deaktivieren, der auf dem Edge-Transport-Server 1 im Active Directory-Verzeichnisdienst für Standort 1 konfiguriert ist, wenn der Edge-Transport-Server 1 offline ist. E-Mail-Nachrichten, die an Standort 1 für den Edge-Transport-Server 1 in Warteschlangen gespeichert werden, werden mithilfe des Connectorauswahlalgorithmus über einen der anderen Active Directory-Standorte, an denen ein Edge-Transport-Server abonniert ist, automatisch erneut übermittelt, kategorisiert und dann über eine andere Route weitergleitet.
In dieser Abbildung werden die Nachrichten an den Active Directory-Standort 2 umgeleitet, um dann den Edge-Transport-Server 2 zu durchlaufen. Wenn der Edge-Transport-Server 1 erneut verfügbar wird, müssen Sie dessen * Connector am Active Directory-Standort 1 erneut aktivieren, damit die für das Internet bestimmte E-Mail an Standort 1 über den Edge-Transport-Server 1 weitergeleitet werden kann.
Manuelles Failover eines Edge-Transport-Servers
.gif "Manuelles Edge-Failover")
Nachrichtenrelay von einem Edge-Transport-Server an einen Hub-Transport-Server
Wenn eine Edge-Transport-Server an einem Active Directory-Standort abonniert ist, wird automatisch für den Edge-Transport-Server ein Sendeconnector erstellt und konfiguriert. Dieser Sendeconnector sendet Nachrichten an die Hub-Transport-Server am Active Directory-Standort, an dem der Edge-Transport-Server abonniert ist. Dieser Sendeconnector ist für die Verwendung eines Platzhalters -- im Adressraum konfiguriert. Der Platzhalter -- im Adressraum für den Sendeconnector für eingehende Nachrichten stellt die autorisierenden und internen relayakzeptierten Domänen für die Exchange-Organisation dar. Die Hub-Transport-Server, die am Active Directory-Standort zu dem Zeitpunkt bereitgestellt werden, zu dem das Edge-Abonnement erstellt wird, werden als Smarthosts für den Connector aufgelistet. Lastenausgleich und Fehlertoleranz werden für die Hub-Transport-Server erzielt, die sich in der Liste der Smarthosts für den Sendeconnector für eingehende Nachrichten befinden.
Hinweis
Wenn zusätzliche Hub-Transport-Server am Active Directory-Standort bereitgestellt werden, nachdem das Edge-Abonnement erstellt wurde, nehmen diese Hub-Transport-Server nicht am Edge-Synchronisierungsprozess teil. Die neuen Hub-Transport-Server werden jedoch der Liste der Smarthosts für den Sendeconnector für eingehende Nachrichten hinzugefügt. Weitere Informationen finden Sie unter EdgeSync und Sendeconnectors.
Nachrichtenrelay an einen Active Directory-Remotestandort
Wenn mehrere Hub-Transport-Server an einem einzigen Active Directory-Standort bereitgestellt werden, wird die Priorität der Verbindungen mit diesen Hub-Transport-Servern von anderen Active Directory-Standorten mithilfe von Roundrobin bestimmt. Wenn ein Hub-Transport-Server an einem Active Directory-Standort den Speicherort eines Empfängers in einen Postfachserver an einem anderen Active Directory-Standort auflöst, wird eine mit Prioritäten versehene Liste der Hub-Transport-Server am Remotestandort zurückgegeben. Wenn ein Hub-Transport-Server an einem Active Directory-Standort nicht verfügbar ist, werden Verbindungsversuche mit den anderen Hub-Transport-Servern auf der mit Prioritäten versehenen Liste unternommen. Auf diese Weise wird Fehlertoleranz an einem Active Directory-Standort erreicht.
Wenn der Hub-Transport-Server A am Active Directory-Standort z. B. eine Nachricht mittels Relay an einem Postfachserver am Active Directory-Standort B sendet, empfängt der Hub-Transport-Server A eine mit Prioritäten versehene Liste mit Hub-Transport-Servern (z. B. Hub-Transport-Server 1, Hub-Transport-Server 2 und Hub-Transport-Server 3) vom Active Directory-Standort B. Wenn der Hub-Transport-Server A keine Verbindung mit dem Hub-Transport-Server 1 herstellen kann, versucht der Hub-Transport-Server A, eine Verbindung mit dem Hub-Transport-Server 2 herzustellen. Wenn keine Verbindung mit dem Hub-Transport-Server 2 hergestellt werden kann, wird versucht, eine Verbindung mit dem Hub-Transport-Server 3 herzustellen usw.
Wenn der Hub-Transport-Server B am Active Directory-Standort A ebenfalls Nachrichten mittels Relay an den Active Directory-Standort B senden muss, wird die mit Prioritäten versehene Liste der Hub-Transport-Server so angepasst, dass die Server berücksichtigt werden, die sich am Active Directory-Standort B befinden. Die mit Prioritäten versehene Lists der Hub-Transport-Server für den Hub-Transport-Server B kann z. B. die Reihenfolge Hub-Transport-Server 2, Hub-Transport-Server 3 und Hub-Transport-Server 1 am Active Directory-Remotestandort B aufweisen. Solche Anpassungen werden vorgenommen, um die Last zwischen allen Hub-Transport-Servern an dem Standort immer dann auszugleichen, wenn zusätzliche Verbindungen eingerichtet werden.
Nachrichtenrelay vom Postfachserver zum Hub-Transport-Server
In diesem Szenario werden mehrere Hub-Transport-Server an einem Active Directory-Standort bereitgestellt. Wenn sich ein Hub-Transport-Server am gleichen Ort wie der Postfachserver befindet, besitzt dieser Hub-Transport-Server immer Vorrang vor den anderen Hub-Transport-Servern am gleichen Standort. Dies bedeutet, dass der Microsoft Exchange-Mailübergabedienst immer den lokalen Hub-Transport-Server benachrichtigt. Wenn sich kein Hub-Transport-Server am gleichen Ort wie der Postfachserver befindet oder der Hub-Transport-Server für den lokalen Postfachserver nicht verfügbar ist, werden die anderen Hub-Transport-Server am gleichen Active Directory-Standort mithilfe von Roundrobin verwendet.
Nachrichtenrelay von einem Hub-Transport-Server über einen Exchange 2003-Routinggruppenconnector
Wenn ein Routinggruppenconnector für die Verwendung mehrerer Exchange-Zieltransportserver konfiguriert ist, verwendet das Exchange 2007-Routing die lokalen Lastenausgleichs- und Fehlertoleranzmechanismen, die im Abschnitt "Nachrichtenrelay, wenn mehrere Quelltransportserver für einen Sendeconnector am gleichen Active Directory-Standort angegeben werden" weiter oben in diesem Thema beschrieben werden.
Nachrichtenrelay an SMTP-Server von Drittanbietern
Wenn ein SMTP-Sendeconnector für die Verwendung mehrerer Smarthosts konfiguriert ist, findet für Verbindungsanforderungen Lastenausgleich auf den Smarthosts statt. Wenn ein Smarthost nicht verfügbar ist, wird Fehlertoleranz durch einen Verbindungsversuch mit einem anderen Smarthost bereitgestellt, der für den Connector konfiguriert ist.
Szenarien, in denen Lastenausgleich und Fehlertoleranz nicht bereitgestellt werden
In diesem Abschnitt werden die folgenden Nachrichtenroutingszenarien beschrieben, in denen Exchange 2007-Transportserver keine Unterstützung für Lastenausgleich und Fehlertoleranz bereitstellen:
Quelltransportserver an verschiedenen Active Directory-Standorten
Mehrere Connectors mit identischen Kosten
Server für die Aufgliederung der Verteilergruppe
Redundante kostengünstige Routingpfade oder Hubstandorte
Quelltransportserver an verschiedenen Active Directory-Standorten
Wenn sich die Quelltransportserver des Sendeconnectors, der zum Weiterleiten von E-Mail-Nachrichten verwendet wird, an verschiedenen Active Directory-Remotestandorten befinden, findet kein Lastenausgleich für Nachrichten zwischen diesen Active Directory-Standorten statt. Stattdessen wird ein Active Directory-Standort ausgewählt, und Nachrichten werden mittels Relay an diesen Standort gesendet. Der Active Directory-Standort mit den geringsten Kosten wird bevorzugt. Wenn alle Active Directory-Standorte die gleichen Kosten aufweisen, wird der Active Directory-Standort des Quelltransportservers ausgewählt, der zuerst in der Liste der Quelltransportserver aufgelistet wird.
Die folgende Abbildung zeigt das Nachrichtenroutingverhalten, wenn Quelltransportserver aus mehreren Active Directory-Standorten für einen Sendeconnector konfiguriert sind. In dieser Abbildung wird eine Nachricht vom Active Directory-Standort 3 an einen externen Empfänger weitergeleitet. Der Connector C1 wird als der Connector mit dem am besten passenden Adressraum ausgewählt. Die Quelltransportserver für den Connector C1 sind die Hub-Transport-Server am Active Directory-Standort 1 und am Active Directory-Standort 2. Wenn sich der erste Quelltransportserver, der aufgelistet wird, am Active Directory-Standort 1 befindet, werden alle Nachrichten vom Active Directory-Standort 3 an den Active Directory-Standort 1 weitergeleitet. Jeder Hub-Transport-Server am Active Directory-Standort 1 kann die Nachricht empfangen und dann den Lastenausgleich des lokalen Active Directory-Standorts verwenden, um die Nachricht für das Relay zwischen dem Hub-Transport-Server A und dem Hub-Transport-Server B zu verteilen.
Für einen Sendeconnector konfigurierte Quelltransportserver aus verschiedenen Active Directory-Standorten
.gif "Quelltransportserver an verschiedenen AD-Standorten")
Lastenausgleich über Active Directory-Standorte hinweg wird nicht unterstützt, weil Exchange 2007 immer deterministisches Routing verwendet und immer nur einen Active Directory-Standort für das Nachrichtenrouting auswählt.
Mehrere Connectors mit identischen Kosten
Wenn mehrere Connectors mit identischen Kosten für die Weiterleitung von Nachrichten vorhanden sind, findet kein Lastenausgleich für Nachrichten zwischen diesen Connectors statt. Das Exchange 2007-Routing wählt deterministisch einen Connector mithilfe der Auswahlalgorithmen aus, die unter Informationen zum auf Active Directory-Standorten basierenden Routing beschrieben werden.
Server für die Aufgliederung von Verteilergruppen
Die können eine Verteilergruppe für die Verwendung eines bestimmten Servers für die Aufgliederung von Verteilergruppen konfigurieren. Wenn Sie einen Server für die Aufgliederung von Verteilergruppen angeben, werden alle Nachrichten an die Verteilergruppe an den angegebenen Server für die Aufgliederung von Verteilergruppen weitergeleitet. Der Server für die Aufgliederung von Verteilergruppen gliedert die Gruppenmitgliedschaft auf, löst jeden Empfänger auf und leitet die Nachrichten dann weiter. Lastenausgleich über mehrere Server für die Aufgliederung von Verteilergruppen wird nicht unterstützt. Wenn der Server für die Aufgliederung von Verteilergruppen nicht verfügbar ist, werden die Nachrichten am Fehlerpunkt in einer Nachrichtenwarteschlange gespeichert, und die Warteschlange besitzt den Zustand "Wiederholen".
Redundante kostengünstige Routingpfade oder Hubstandorte
Nachdem das Exchange 2007-Routing den kostengünstigsten Routingpfad berechnet und eine Routingpfadauswahl basierend auf den unter Informationen zum auf Active Directory-Standorten basierenden Routing beschriebenen Kriterien getroffen hat, berechnet das Exchange 2007-Routing den Routingpfad nur dann erneut, wenn sich die Konfigurationsdaten ändern. Wenn mithilfe dieses deterministischen Routingpfads keine Verbindung hergestellt werden kann, versucht das Exchange 2007-Routing nicht, einen alternativen Routingpfad zu berechnen. In diesem Fall werden die Nachrichten am Fehlerpunkt in Warteschlangen gespeichert und erneut weitergeleitet.
Die folgende Abbildung zeigt, wie das Nachrichtenrouting in diesem Szenario in einer Active Directory-Standorttopologie stattfindet.
Für eine Nachricht, die vom Active Directory-Standort 1 an den Active Directory-Standort 4 gesendet wird, sind zwei Pfade verfügbar, die beide die gleichen Kosten aufweisen. Der Pfad "Standort 1 - Standort 2 - Standort 4" wird jedoch ausgewählt, weil der Active Directory-Standort 2 alphanumerisch kleiner als der Active Directory-Standort 3 ist.
Redundante kostengünstige Routingpfade oder Hubstandorte
.gif "Redundante kostengünstige Pfade oder Hubstandorte")
In dieser Topologie ist der Active Directory-Standort 2 ebenfalls als Hub-Transport-Serverstandort konfiguriert. In dieser Konfiguration wird die Nachrichtenzustellung mittels Relay durch diesen Standort erzwungen, weil er im ausgewählten kostengünstigsten Routingpfad vorhanden ist. Wenn Nachrichten, die vom Standort 1 an den Standort 4 gesendet werden, aus beliebigen Gründen nicht mittels Relay vom Standort 1 an den Standort 2 gesendet werden können (z. B. durch einen Netzwerkverbindungsfehler zwischen dem Standort 1 und dem Standort 2), werden alle Nachrichten am Standort 1 in Warteschlangen gespeichert.
Wenn es sich bei Standort 2 nicht um einen Hub-Transport-Serverstandort handelt, werden Nachrichten direkt vom Standort 1 an den Standort 4 zugestellt. Direktes Relay ist durch die fehlende Netzwerkverbindung zwischen dem Standort 1 und dem Standort 2 nicht betroffen. Direktes Relay funktioniert, solange eine Route der Netzwerkschicht vom Standort 1 zum Standort 4 vorhanden ist. Die Netzwerkschicht der Exchange-Topologie zwischen den Standorten definiert den Pfad, den die Computer zum Senden von Daten untereinander verwenden. In dieser Abbildung müssen jedoch alle Nachrichten vom Standort 1 an den Standort 4 mittels Relay über den Standort 2 gesendet werden, weil der Standort 2 einen Hub-Transport-Server aufweist. In diesem Szenario unterstützt Exchange 2007 nicht den Wechsel in einen alternativen Routingpfad mit identischen Kosten, sondern verwendet die Redundanz und Fehlertoleranz der IP-Netzwerkschicht zwischen den Standorten für das Nachrichtenrelay. Von der Netzwerkschicht wird angenommen, dass sie vor physikalischen Verbindungsfehlern geschützt ist und redundante Alternativpfade zu einem Ziel bereitstellt.
SMTP-Verbindungsverwaltung
In diesem Abschnitt wird die SMTP-Verbindungsverwaltung im Kontext des Lastenausgleichs und der Fehlertoleranz für Exchange 2007 erläutert. Der Hub-Transport-Server sendet mithilfe von SMTP Verbindungsanforderungen an Remoteserver. Der Remoteserver kann ein Hub-Transport-Server an einem anderen Active Directory-Standort, ein Smarthost oder ein Edge-Transport-Server sein.
Wenn z. B. 60 Nachrichten für das Relay an einen Active Directory-Remotestandort in einer Warteschlange gespeichert sind und dieser Standort über drei Hub-Transport-Server verfügt, verteilt die Exchange-Transportkomponente, die die Verbindung herstellt, die Last für das Nachrichtenrelay auf alle Server. Mit jedem Server wird eine Verbindung hergestellt, und jede dieser Verbindungen wird zum Übertragen von ungefähr 20 Nachrichten verwendet. Die Übertragungsrate hängt von der Netzwerkbandbreite und der Größe der Nachrichten ab.
Die Anzahl der von jeder Verbindung übertragenen Nachrichten ist nicht konfigurierbar. Die maximale Anzahl von Verbindungen pro Warteschlange kann jedoch durch zwei Konfigurationseinstellungen auf dem Transportserver beschränkt werden: MaxPerDomainOutboundConnections und MaxOutboundConnections. MaxPerDomainOutboundConnections beschränkt die Anzahl der Verbindungen, die pro Warteschlange hergestellt werden können. MaxOutboundConnections beschränkt die Gesamtanzahl ausgehender Verbindungen, die der Server herstellen kann. Sie können diese Einstellungen mithilfe des Cmdlets Set-TransportServer in der Exchange-Verwaltungsshell oder mithilfe der Eigenschaftenseiten des Transportservers in der Exchange-Verwaltungskonsole konfigurieren.
Weitere Informationen hierzu finden Sie unter den folgenden Themen:
Weitere Informationen
Weitere Informationen hierzu finden Sie in den folgenden Ressourcen: