PassPort clustering considerations

To install PassPort in a clustered architecture you use a shared file system and database, just as you do with B2Bi clusters. However, PassPort is different from the B2Bi in that it is installed in only one directory on the shared file system. It shares a configuration. PassPort functions are essentially database functions. PassPort does not have to synchronize local files across nodes as B2Bi does. In fact, the only file local to PassPort is its license key, which is host-specific. So on the shared file system, you often see three directories:

  • /b2bi1– Installation and configuration / log files for B2Bi node 1
  • /b2bi2 – Installation and configuration / log files for B2Bi node 2
  • /passport – Installation and configuration / log files for both PassPort nodes

For PassPort, log files are in the same logs folder, with one file for each server in the cluster. All log files are named with the hostname.

For B2Bi, you have to gather log files across both trees, as well as keep configuration files in synch across trees.

Example architectures

B2Bi and PassPort clustered on same machine

When you install PassPort and B2Bi on the same machine it reduces hardware requirements, but it creates an issue when the PassPort server becomes unresponsive: B2Bi does not automatically fail over to the other PassPort. Fail over can be enabled by manually modifying the Interchange database to point to the alternate PassPort IP. But typically, this configuration protects only against an entire server, or the B2Bi node being down. Because PassPort configuration is stored in a central database table, it must be the same on each B2Bi node. Thus we have to use “localhost” to tell B2Bi node 1 to point to PassPort node 1, and B2Bi node 2 to point to PassPort node 2.

B2Bi and PassPort in separate clusters

Installing B2Bi and PassPort on separate clusters offers more redundancy, and provides additional load balancing between B2Bi nodes and the PassPort cluster. This architecture is more costly, more complex, and introduces a little additional network latency on initial login. This setup is appropriate when more redundancy is required, and when other components (Sentinel, CFT, etc) are sharing the central PassPort cluster. The same servers can often be used for Sentinel or other governance components.

Related topics

Related Links