Best Of

With larger environments, it’s important to consider the implications of different architectures and system types when building a ProfileUnity Console cluster. Some of the key things to note are how many geographic locations will be home to machines running the ProfileUnity Client Tools and what type of environment is being delivered. For example, single-user Desktop OSes or multi-user Server OSes with the RDSH Server Role enabled.

ProfileUnity Cluster notes to keep in mind:

1. ProfileUnity uses MongoDB for the database back end and RabbitMQ for the license fabric - both are clustered automatically when you build a ProfileUnity Console cluster.
2. MongoDB requires a cluster containing an odd-number of nodes under a 100% node-up scenario. This ensures a tiebreaker for cluster operations. Generally, this means 3, 5 or 7 nodes.
3. MongoDB, while clustered, always requires at least 2 running nodes, hence the minimum node-count of 3.

Architecture examples:

1. If you have a single site you likely only need a 3-node cluster. This would spread the load out among all nodes and allow for a single node to fail while maintaining normal operations. An example benefit would be a rolling Windows Update/reboot cycle or even a ProfileUnity Console version upgrade without service interruption. 
2. If you have 3 geographic regions and want to make sure that you have license and FlexDisk redundancy at each location, you might deploy a 7-node cluster. Site 1 would have 3 nodes while sites 2 and 3 would each have 2 nodes. In this configuration, the MongoDB cluster would span all 3 sites while the RabbitMQ license/FlexDisk fabric would be isolated within each site. This would allow for a single node at each site to be rebooted for maintenance, while maintaining normal operations at all sites. It would also allow for 2 of 3 sites to go dark and not interrupt ProfileUnity license or FlexDisk operations at the remaining site.

ProfileUnity Cluster sizing considerations:

1. Environments with a majority of Desktop OSes, or Server OSes without the RDSH role acting as single-user desktops, can require a cluster with higher CPU requirements and lower memory requirements. The main reason is that the Liquidware Client License Service in the Client Tools only connects to the fabric to make a license "consume" or "release" request and then immediately disconnects.
2. Environments running a majority of Server OSes with the RDSH role enabled will require both CPU and additional memory as the number of client machines increases. In this situation, because the server will be making many license "consume" and "release" requests throughout the day, the Liquidware Client License Service connects to make the first license "consume" request and remains connected until rebooted. These open connections require the ProfileUnity Console cluster to have a higher memory requirement.

 For cluster sizing suggestions, please refer to this KB article: https://liquidwarelabs.zendesk.com/hc/en-us/articles/360039686092-ProfileUnity-Cluster-Sizing-Suggestions

Nice work @Adam, this will now be part of the 6.8.3 default templates shipping next month. Customer's can just enable the rule if they dont have hardware GPU's and get performance back!