Cookie-basiertes "Sticky Request Routing" (6476922)

Wenn Access Manager-Server hinter einem Load Balancer bereitgestellt werden, verhindert das Cookie-basierte so genannte "Sticky Request Routing" (zähe Anforderungsweiterleitung), dass Client-Anfragen an einen falschen Access Manager-Server weitergeleitet werden (d. h., auf einen Server, der nicht der Host der Sitzung ist). Diese Funktion wurde in Access Manager 7 2005Q4-Patch 3 implementiert.

Das frühere Verhalten, ohne Cookie-basiertes Sticky Request Routing, führte häufig dazu, dass Anforderungen von nicht browserbasierten Clients (z. B. Richtlinienagenten und Clients, die das Remote-Access Manager Client SDK verwenden) fälschlicherweise an einen Access Manager, der nicht Host der Sitzung ist, weitergeleitet wurden. Um die Anforderung an den richtigen Server zu senden, musste der Access Manager-Server die Sitzung durch Kommunikation über einen Rückkanal überprüfen, was in den meisten Fällen zu Leistungseinbußen führte. Durch den Einsatz von Cookie-basiertem Sticky Request Routing wird diese Rückkanal-Kommunikation nicht benötigt und dadurch die Leistung von Access Manager verbessert.

Um Cookie-basiertes Request Routing zu implementieren, muss die Access Manager-Bereitstellung als Site konfiguriert sein. Weitere Informationen finden Sie unter Configuring an Access Manager Deployment as a Site in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.

So konfigurieren Sie Cookie-basiertes Sticky Request Routing

1. Um einen Cookie-Namen anzugeben, legen Sie die Eigenschaft com.iplanet.am.lbcookie.name in der Datei AMConfig.properties fest. Access Manager erzeugt anschließend unter Verwendung der 2-Byte-Server-ID (z. B. 01, 02 oder 03) den Cookie-Wert für den Load Balancer. Wenn Sie keinen Cookie-Namen angeben, erzeugt Access Manager das Cookie für den Load Balancer mit dem Standardnamen amlbcookie und der 2-Byte-Server-ID.

   Wenn Sie den Cookie-Namen auf dem Access Manager-Server festlegen, müssen Sie denselben Namen in der Datei AMAgent.properties für einen Richtlinienagenten verwenden. Ebenso müssen Sie denselben Cookie-Namen wie den vom Access Manager-Server verwendeten Namen verwenden, wenn Sie das Access Manager Client-SDK verwenden.

   Hinweis: Legen Sie nicht die Eigenschaft com.iplanet.am.lbcookie.value fest, da Access Manager den Cookie-Wert unter Verwendung der 2-Byte-Server-ID festlegt.

2. Konfigurieren Sie Ihren Load Balancer mit dem Cookie-Namen aus Schritt 1. Mit der Access Manager-Bereitstellung kann ein Hardware- oder Software-Lastenausgleichssystem verwendet werden.

3. Wenn Sitzungs-Failover implementiert ist, aktivieren Sie die Eigenschaft com.sun.identity.session.resetLBCookie für beide Richtlinienagenten und für den Access Manager-Server.

   • Fügen Sie für den Richtlinienagenten die Eigenschaft der Datei AMAgents.properties hinzu und aktivieren Sie sie.

   • Fügen Sie für Access Manager-Server die Eigenschaft der Datei AMConfig.properties hinzu und aktivieren Sie sie.

   Beispiel:

   com.sun.identity.session.resetLBCookie='true'

   Tritt eine Failover-Situation auf, wird die Sitzung an einen sekundären Access Manager-Server weitergeleitet und der Cookie-Wert des Load Balancer unter Verwendung der Server-ID des sekundären Access Manager-Servers festgelegt. Alle nachfolgenden Anforderungen für die Sitzung werden an den sekundären Access Manager-Server weitergeleitet.