Both Access Manager 1 and Access Manager 2 should be up and running before you begin this verification procedure.
As a root user, log in to the AccessManager–2 host machine.
Change to the bin directory.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/bin |
Stop Access Manager 2.
# ./stopserv |
Access http://LoadBalancer-3.example.com:7070/amserver/UI/Login from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Click the Sessions tab.
In the View field, select Access Manager-1.example.com:1080 from the drop down list.
Verify that only amadmin exists in the Sessions table.
In the View field, select Access Manager-2.example.com:1080 from the drop down list.
You will see an error message indicating the server is down.
Leave this browser window 1 open.
Start Access Manager 2.
# ./startserv |
As a root user, log in to the AccessManager–1 host machine.
Change to the bin directory.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/bin |
Stop Access Manager 1.
# ./stopserv |
Going back to the Access Manager console in browser window 1, under the Sessions tab, select Access Manager-1.example.com:1080 from the View drop down list.
You will see an error message indicating the server is down.
Now select Access Manager-2.example.com:1080 from the View drop down list.
Verify that only amadmin exists in the Sessions table. This indicates that although AccessManager–1 was stopped, the Access Manager LoadBalancer-3 directed the request to AccessManager–2 and a session for amadmin was successfully created in AccessManager–2. If session failover was not enabled, it would have resulted in a login page.