About

PhenixID Authentication Services can be used in clustering/high availability scenarios. When used like this, the internal database can not be used, an external database must be used.

When to cluster

Typically clustering is used when high availability is required. Also when traffic needs to be spread across multiple nodes due to heavy load. In those cases an external load balancer is required since load balancing is not handled internally. Depending on the configuration, clustering may also allows for "rolling upgrades", meaning that one node can be taken off line for upgrade while a second node can handle the work.

What you get

A PhenixID server cluster consist of two separate services, authentication and persistent layer. This differs from when running a non-cluster where all services are handled by the same processes.

The service that handles the actual authentication takes care of clustering the configuration and session data, making sure that data is available to all connected nodes in the cluster. The second service, the database, is in charge of storing data that is important long term but is not configuration data. This would be tokens, lockout status etc.

The image below shows the architectural lay out. Note that database and authentication service does not have to be located on the same servers. It is perfectly fine to separate database and authentication onto their own servers if desired.

flowchart LR
    subgraph Cluster
        direction TB
        subgraph Server1[Server #1]
            direction LR
            Sessions1[Sessions]
            Configuration1[Configuration]
            OneTouch1[OneTouch]
            Tokens1[Tokens]
            Hazelcast1[Hazelcast]
            Sessions1 --> Hazelcast1
            Configuration1 --> Hazelcast1
        end
        subgraph Server2[Server #2]
            direction LR
            Sessions2[Sessions]
            Configuration2[Configuration]
            OneTouch2[OneTouch]
            Tokens2[Tokens]
            Hazelcast2[Hazelcast]
            Sessions2 --> Hazelcast2
            Configuration2 --> Hazelcast2
        end
        subgraph Server3[Server #3]
            direction LR
            Sessions3[Sessions]
            Configuration3[Configuration]
            OneTouch3[OneTouch]
            Tokens3[Tokens]
            Hazelcast3[Hazelcast]
            Sessions3 --> Hazelcast3
            Configuration3 --> Hazelcast3
        end
    end
    subgraph Db[External database]
        direction LR
        MSSQL[MS SQL]
        MariaDB[Maria DB/MySQL]
    end
    Hazelcast1 <--> Hazelcast2
    Hazelcast2 <--> Hazelcast3
    Hazelcast3 <--> Hazelcast1
    OneTouch1 --> Db
    OneTouch2 --> Db
    OneTouch3 --> Db
    Tokens1 --> Db
    Tokens2 --> Db
    Tokens3 --> Db

Ensuring HA and fault tolerant the database it needs to be externalized. This means the responsibility of the persistent layer is put somewhere else rather than in the PAS it self. PAS will act as client to the external datasource.

Tags

Cluster