Load-Balancing über Back-End-Server

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Apigee Edge verbessert die Verfügbarkeit Ihrer API durch integrierte Unterstützung für Lasten und Failover über mehrere Back-End-Serverinstanzen hinweg.

Zielserver-Konfigurationen entkoppeln konkrete Endpunkt-URLs von TargetEndpoint Konfigurationen. Auf jeden TargetServer wird mit seinem Namen in einem TargetEndpoint verwiesen. HTTPConnection übergeben. Anstatt eine konkrete URL in der Konfiguration festzulegen, können Sie eine oder mehr benannte Zielserver, wie im Abschnitt beschrieben TargetEndpoint (Zielendpunkt).

Eine TargetServer-Definition besteht aus einem Namen, einem Host und einem Port sowie einem geben an, ob der TargetServer aktiviert oder deaktiviert ist.

Videos

In den folgenden Videos erfahren Sie mehr über API-Routing und Load-Balancing mithilfe von Zielservern.

Beispielkonfiguration für Zielserver

Mit dem folgenden Code wird ein Zielserver definiert:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

Zielserver-Konfigurationselemente

In der folgenden Tabelle werden die Elemente beschrieben, die zum Erstellen und Konfigurieren eines TargetServers verwendet werden:

Zielserver über die Benutzeroberfläche verwalten

Verwalten Sie Zielserver wie unten beschrieben.

Zielserver mit der API verwalten

Sie können die Edge API verwenden, um Zielserver zu erstellen, zu löschen, zu aktualisieren, abzurufen und aufzulisten. Für Weitere Informationen finden Sie unter TargetServers.

Verwenden Sie den folgenden API-Aufruf, um einen Zielserver zu erstellen:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Beispielantwort:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

Nachdem Sie den ersten TargetServer erstellt haben, verwenden Sie den folgenden API-Aufruf, um einen zweiten TargetServer zu erstellen. Indem Sie zwei TargetServer definieren, stellen Sie zwei URLs bereit, die ein TargetEndpoint für das Load-Balancing verwenden kann:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Beispielantwort:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

Verwenden Sie den folgenden API-Aufruf, um eine Liste der Zielserver in einer Umgebung abzurufen:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Beispielantwort:

[ "target2", "target1" ]

Es sind jetzt zwei Zielserver verfügbar, die von im Test bereitgestellten API-Proxys verwendet werden können zu verbessern. Für das Verteilen des Traffics via Load-Balancing auf diese TargetServers konfigurieren Sie die HTTP-Verbindung im Zielendpunkt eines API-Proxys für die Verwendung der TargetServers.

Es gibt ein Limit von 500 Zielservern pro Umgebung, die im Thema Limits dokumentiert sind.

TargetEndpoint für das Load-Balancing über benannte TargetServers hinweg konfigurieren

Da jetzt zwei TargetServers verfügbar sind, können Sie die TargetEndpoint-HTTP-Verbindungseinstellung so ändern, dass auf die zwei TargetServer anhand des Namens verwiesen wird:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Die obige Konfiguration stellt die einfachste mögliche Load-Balancing-Konfiguration dar. Der Load-Balancer unterstützt drei Load-Balancing-Algorithmen: Round Robin, Weighted und Least Connection. Round Robin ist der Standardalgorithmus. Da in der Konfiguration oben kein Algorithmus angegeben ist, werden ausgehende Anfragen vom API-Proxy an die Back-End-Server abwechselnd nacheinander zwischen Ziel 1 und Ziel 2.

Das Element <Path> bildet den Basispfad des TargetEndpoint-URI für alle Zielserver. Es wird nur verwendet, wenn <LoadBalancer> verwendet wird. Andernfalls wird es ignoriert. Im Beispiel oben bedeutet eine Anfrage, die bei "target1" erreicht wurde. wird http://target1/test usw. für andere Zielserver.

Load-Balancer-Optionen festlegen

Sie können die Verfügbarkeit mithilfe von Optionen für Load-Balancing und Failover bei der Last abstimmen. Balancer- und TargetServer-Ebene. In diesem Abschnitt werden diese Optionen beschrieben.

Algorithmus

Legt den von <LoadBalancer> verwendeten Algorithmus fest. Die verfügbaren Algorithmen sind RoundRobin, Weighted und LeastConnections, die jeweils unten dokumentiert sind.

Round-Robin

Der Standardalgorithmus Round Robin leitet eine Anfrage an jeden TargetServer in der Reihenfolge weiter, in der die Server in der HTTP-Verbindung des Zielendpunkts aufgeführt sind. Beispiele:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Gewichtet

Der gewichtete Load-Balancing-Algorithmus ermöglicht die Konfiguration proportionaler Traffic-Lasten für Ihre Zielserver. Der gewichtete LoadBalancer verteilt die Anfrage direkt an Ihre Zielserver. proportional zur Gewichtung jedes TargetServers. Daher muss beim gewichteten Algorithmus für jeden TargetServer ein weight-Attribut festgelegt werden. Beispiel:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

In diesem Beispiel werden für jede an target1 weitergeleitete Anfrage zwei Anfragen an target2 weitergeleitet.

Mindestverbindung

LoadBalancer, die für die Verwendung des Mindestverbindungsalgorithmus konfiguriert sind, leiten ausgehende Anfragen an den TargetServer mit den wenigsten offenen HTTP-Verbindungen weiter. Beispiele:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Maximale Fehlschläge

Die maximale Anzahl fehlgeschlagener Anfragen vom API-Proxy an den TargetServer, die dazu führen, dass die Anfrage an einen anderen TargetServer weitergeleitet wird.

Ein Antwortfehler bedeutet, dass Apigee keine Antwort von einem Zielserver empfängt. In diesem Fall wird der Fehlerzähler um eins erhöht.

Wenn Apigee jedoch eine Antwort von einem Ziel erhält, selbst wenn es sich bei der Antwort um einen HTTP-Fehler (z. B. 500) handelt, wird dies als Antwort von Zielserver und der Fehlerzähler wird zurückgesetzt. Um sicherzustellen, dass ungültige HTTP-Antworten (z. B. 500) erhöhen auch den Fehlerzähler, um einen fehlerhaften Server auszuschalten der Load-Balancing-Rotation so bald wie möglich ist, können Sie <ServerUnhealthyResponse>-Element mit <ResponseCode> untergeordneten Elementen zu Ihrer Load-Balancer-Konfiguration hinzu. Edge zählt auch Antworten mit diesen als Fehler.

Im folgenden Beispiel wird target1 nach 5 Tagen aus der Rotation entfernt fehlgeschlagene Anfragen, einschließlich einiger 5XX-Antworten vom Zielserver.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Der Standardwert von MaxFailures ist 0. Das bedeutet, dass Edge immer versucht, eine Verbindung zum Ziel für jede Anfrage herstellen und den Zielserver niemals aus der Rotation entfernen.

Es empfiehlt sich, MaxFailures > 0 mit einem HealthMonitor zu verwenden. Wenn Sie „MaxFailures“ konfigurieren > 0, wird der TargetServer aus der Rotation entfernt. wenn das Ziel die von Ihnen angegebene Anzahl an Fehlschlägen aufweist. Wenn ein HealthMonitor eingerichtet wurde, platziert Apigee automatisch den TargetServer wieder in Rotation, sobald das Ziel wieder einsatzbereit ist, gemäß der Konfiguration dieses HealthMonitors. Siehe Statusüberwachung .

Wenn Sie hingegen MaxFailures > 0 konfigurieren und keinen HealthMonitor konfigurieren, fügt Apigee den TargetServer nicht automatisch wieder in die Rotation ein, nachdem Apigee einen Fehler erkannt hat. In diesem Fall müssen Sie den API-Proxy noch einmal bereitstellen, bevor Apigee den TargetServer wieder in Rotation setzt. Siehe API-Proxy bereitstellen.

Wiederholen

Wenn „Wiederholen” aktiviert ist, wird eine Anfrage wiederholt, wenn ein Antwortfehler (E/A-Fehler oder HTTP-Zeitüberschreitung) auftritt oder die empfangene Antwort mit einem Wert übereinstimmt, der durch <ServerUnhealthyResponse> festgelegt wurde. Weitere Informationen zum Festlegen von <ServerUnhealthyResponse> finden Sie oben unter Maximale Fehler.

Standardmäßig ist <RetryEnabled> auf true festgelegt. Setzen Sie diesen Wert auf false, um die Wiederholung zu deaktivieren. Beispiel:

<RetryEnabled>false</RetryEnabled>

IsFallback

Ein (und nur ein) TargetServer kann als „Fallback”-Server festgelegt werden. Der Fallback-TargetServer ist erst in den Load-Balancing-Routinen enthalten, bis alle anderen TargetServer als vom Load-Balancer als nicht verfügbar gekennzeichnet sind. Wenn der Load-Balancer feststellt, dass alle TargetServer nicht verfügbar sind, wird der gesamte Traffic zum Fallback-Server weitergeleitet. Beispiel:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Die obige Konfiguration führt zu einem Round-Robin-Load-Balancing zwischen den Zielen 1 und 2, bis beide Ziele 1 und 2 nicht verfügbar sind. Wenn die Ziele 1 und 2 nicht verfügbar sind, wird der gesamte Traffic an Ziel 3 weitergeleitet.

Pfad

Der Pfad definiert ein URI-Fragment, das an alle Anfragen vom TargetServer an den Backend-Server angehängt wird.

Dieses Element akzeptiert einen Stringliteralpfad oder eine Nachrichtenvorlage. Mit einer Nachrichtenvorlage können Sie zur Laufzeit eine variable Stringsubstitution durchführen. In der folgenden Zielendpunktdefinition wird beispielsweise der Wert von {mypath} für den Pfad verwendet:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Konfigurieren eines Zielservers für TLS/SSL

Wenn Sie den Backend-Dienst mit einem TargetServer definieren und der Backend-Dienst erfordert, dass die Verbindung das HTTPS-Protokoll verwendet, müssen Sie TLS/SSL in der TargetServer-Definition aktivieren. Dies ist erforderlich, da das Verbindungsprotokoll mit dem Tag <Host> nicht angegeben werden kann. Unten sehen Sie die TargetServer-Definition für Einbahnstraßen. TLS/SSL, wobei Edge HTTPS-Anfragen an den Back-End-Dienst stellt:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

Wenn der Backend-Dienst bidirektionales oder gegenseitiges TLS/SSL erfordert, konfigurieren Sie den TargetServer mit denselben Konfigurationseinstellungen für TLS/SSL wie TargetEndpoints:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

Informationen zu den <SSLInfo>-Attributen wie z. B. <Ciphers> und <ClientAuthEnabled>, siehe Informationen zum Festlegen dieser Eigenschaften für einen virtuellen Host finden Sie unter TLS-Zugriff auf eine API konfigurieren für die Private Cloud.

Eine vollständige Anleitung zum Konfigurieren von ausgehenden TLS/SSL-Verbindungen finden Sie unter TLS/SSL konfigurieren vom Edge zum Back-End (Cloud und Private Cloud).

TargetServer-Schema

Das Schema für TargetServer und andere Entitäten finden Sie auf GitHub.

Statusüberwachung

Mit Statusüberwachung können Sie die Load-Balancing-Konfigurationen optimieren, indem Sie aktiv die in den TargetServer-Konfigurationen definierten Backend-Dienst-URLs abfragen. Bei aktiviertem Statusüberwachung wird ein fehlgeschlagener TargetServer automatisch wieder in die Rotation zurückgeführt, wenn HealthMonitor feststellt, dass der TargetServer aktiv ist.

Das Status-Monitoring funktioniert mit <MaxFailures>. Ist das Monitoring von Systemdiagnosen nicht aktiviert, gibt <MaxFailures> die Anzahl der fehlgeschlagenen Anfragen vom API-Proxy an den TargetServer an, bei dem die Anfrage an einen anderen TargetServer weitergeleitet wird. Der ausgefallene TargetServer wird dann aus der Rotation genommen, bis Sie den Proxy noch einmal bereitstellen.

Bei aktiviertem Statusüberwachung wird ein fehlgeschlagener TargetServer automatisch wieder in die Rotation gesetzt und es sind keine erneuten Proxy-Bereitstellungen erforderlich.

HealthMonitor fungiert als einfacher Client, der einen Backend-Dienst über TCP oder HTTP aufruft:

• Ein TCP-Client stellt lediglich sicher, dass ein Socket geöffnet werden kann.
• Sie konfigurieren den HTTP-Client so, dass er eine gültige HTTP-Anfrage an den Backend-Dienst sendet. Sie können HTTP GET-, PUT-, POST- oder DELETE-Vorgänge definieren. Die Antwort des HTTP-Monitoring-Aufrufs muss mit den konfigurierten Einstellungen im Block <SuccessResponse> übereinstimmen.

Erfolge und Fehler

Wenn Sie die Zustandsüberwachung aktivieren, beginnt Edge, Systemdiagnosen an Ihr Ziel zu senden Server. Eine Systemdiagnose ist eine an den Zielserver gesendete Anfrage, um festzustellen, ob der ob der Zielserver fehlerfrei ist oder nicht.

Eine Systemdiagnose kann eines von zwei möglichen Ergebnissen haben:

• Erfolg: Der Zielserver wird bei einer erfolgreichen Systemdiagnose als fehlerfrei erachtet. Dies ist in der Regel das Ergebnis eines oder mehrerer der Folgenden:
  • Der Zielserver akzeptiert eine neue Verbindung zum angegebenen Port, antwortet auf eine Anfrage an diesem Port und schließt den Port innerhalb des angegebenen Zeitraums. Die Antwort des Zielservers enthält „Connection: Close“.
  • Der Zielserver antwortet auf eine Systemdiagnoseanfrage mit dem HTTP-Statuscode 200 (OK) oder einem anderen HTTP-Statuscode, der von Ihnen als akzeptabel eingestuft wird.
  • Der Zielserver antwortet auf eine Systemdiagnoseanfrage mit einem Nachrichtentext, der dem erwarteten Nachrichtentext entspricht.

  Wenn Edge feststellt, dass ein Server fehlerfrei ist, fährt Edge fort oder fährt mit dem Senden von Anfragen an ihn fort.

• Fehler: Die Systemdiagnose des Zielservers kann je nach Diagnosetyp auf unterschiedliche Weise fehlschlagen. Ein Fehler kann protokolliert werden, wenn der Zielserver:
  • Weist eine Verbindung von Edge zum Port der Systemdiagnose ab.
  • Nicht auf eine Systemdiagnoseanfrage innerhalb eines bestimmten Zeitraums antwortet.
  • Einen unerwarteten HTTP-Statuscode zurückgibt.
  • Mit einem Nachrichtentext antwortet, der nicht dem erwarteten Nachrichtentext entspricht.

  Wenn ein Zielserver eine Systemdiagnose nicht besteht, erhöht Edge die Fehleranzahl dieses Servers. Wenn Die Anzahl der Ausfälle für diesen Server erreicht oder überschreitet einen vordefinierten Schwellenwert (<MaxFailures>), beendet Edge das Senden von Anfragen an diesen Server.

HealthMonitor aktivieren

Zum Erstellen eines HealthMonitors fügen Sie das Element <HealthMonitor> der HTTPConnection-Konfiguration des TargetEndpoints für einen Proxy hinzu. Auf der UI ist das nicht möglich. Stattdessen erstellen Sie eine Proxy-Konfiguration und als ZIP-Datei in Edge hochladen. Eine Proxykonfiguration ist eine strukturierte Beschreibung aller Aspekte eines API-Proxys. Proxykonfigurationen bestehen aus XML-Dateien in einer vordefinierten Verzeichnisstruktur. Weitere Informationen finden Sie unter Referenz zur API-Proxy-Konfiguration.

Mit einem einfachen HealthMonitor wird ein IntervalInSec definiert, das entweder mit ein TCPMonitor oder mit ein HTTPMonitor kombiniert wird. Das <MaxFailures>-Element gibt die maximale Anzahl fehlgeschlagener Anfragen vom API-Proxy an den TargetServer an, die bewirkt, dass die Anfrage an einen anderen TargetServer weitergeleitet wird. Standardmäßig ist <MaxFailures> 0, was bedeutet, Edge führt keine Korrekturaktion aus. Achten Sie beim Konfigurieren einer HealthMonitor darauf, dass Sie <MaxFailures> im Tag <HTTPTargetConnection> des Tags <TargetEndpoint> auf einen Wert ungleich null setzen.

TCPMonitor

Die folgende Konfiguration definiert einen HealthMonitor, das jeden TargetServer abfragt, indem alle fünf Sekunden eine Verbindung zu Port 80 hergestellt wird. (Port ist optional. Wenn nicht angegeben, ist der TCPMonitor-Port der TargetServer-Port.)

• Wenn die Verbindung fehlschlägt oder die Verbindung länger als zehn Sekunden zum verbinden braucht, erhöht sich der Fehlerzähler für diesen TargetServer um 1.
• Ist die Verbindung erfolgreich, wird der Fehlerzähler für den TargetServer auf 0 zurückgesetzt.

Sie können ein HealthMonitor als untergeordnetes Element des HTTPTargetConnection-Elements des TargetEndpoint hinzufügen, wie unten gezeigt:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

HealthMonitor mit TCPMonitor-Konfigurationselementen

In der folgenden Tabelle werden die TCPMonitor-Konfigurationselemente beschrieben:

HTTPMonitor

Ein HealthMonitor-Beispiel, der einen HTTPMonitor verwendet, sendet eine GET-Anfrage an das Back-End. alle fünf Sekunden ausgeführt. Das folgende Beispiel fügt der Anfrage einen HTTP-Basisauthentifizierungs-Header hinzu. Die Antwortkonfiguration definiert Einstellungen, die mit der tatsächlichen Antwort vom Backend-Dienst verglichen werden. Im folgenden Beispiel ist die erwartete Antwort ein HTTP-Antwortcode 200 und ein benutzerdefinierter HTTP-Header ImOK, dessen Wert YourOK ist. Wenn die Antwort nicht übereinstimmt, wird die Anfrage von der Konfiguration des Load-Balancers als Fehler behandelt.

HTTPMonitor unterstützt Backend-Dienste, die für die Verwendung von HTTP- und One-Way-HTTPS-Protokollen konfiguriert sind. Folgendes wird jedoch nicht unterstützt:

• Bidirektionales HTTPS (auch als bidirektionales TLS/SSL bezeichnet)
• selbst signierte Zertifikate

Beachten Sie, dass alle Einstellungen für Anfragen und Antworten in einem HTTPMonitor spezifisch für den Backend-Dienst sind, der aufgerufen werden muss.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HealthMonitor mit HTTPMonitor-Konfigurationselementen

In der folgenden Tabelle werden die HTTPMonitor-Konfigurationselemente beschrieben: