We’ve been operating on a license triad for years with the benefits outweighing any detracting aspects.As others have noted, all three computers need to have excellent communication with each other so the guidelines suggest having them all on the same subnet. And yes, at least two of the three must be on for licenses to be served, otherwise you could easily beat the license count limit set in your license file.
Keep in mind you can have your client application look to multiple servers, triad or not or, or a mix of single node and triad. Typically the client just looks in a setup file or line in the startup file for the list of potential points to gain a license and goes down the list asking for a license. It doesn’t really care that it’s a triad, a single server, a bunch of single servers or a mix. With that you could list your three triad servers first and a single node server second (or vice versa).
If you are trying to keep users at a second site running when the link goes down between your site, where licenses are served, and the
remote site, you’ll have to have a license service running at their end. Even if you were able to successfully split the triad between locations, the location you want to keep always running would have to have at least two of the nodes, and the other site would be without licenses as soon as communication was lost. I would probably either split the licenses to separate single server services or separate triads. That or as Ben mentioned, keep a triad at the main location, splitting off a minimal number to a single node server at location two to keep the bare bones minimum number of people running there should the link go down. Just put that first in their startups so they exhaust their local licenses before going to the remote service – otherwise you could have licenses sitting there unused.
We have also experienced having to exit and restart when a license is lost (retry fails) but narrowed it down to how the license service handles add-on modules. For instance, if you have a regular seat of Pro/E (Creo Parametric) and designated it to startup with an AAX license that sits in a separate pool as an add-on (its own line item in your license file, not part of your feature set within the Pro/E license) weird things can happen. We used to have this setup and had more Pro/E licenses than we did AAX. If a user’s Pro/E session times out (call them user “A”), the whole set of licenses is returned to the pool including the AAX. If someone else (user “B”) starts and grabs a Pro/E license and that AAX license, which happens to be the last AAX add-on left, when user “A” goes active again it gains the Pro/E license back but not an AAX license, so it considers the whole session as failing to gain a license, forcing the user to exit. User A then restarts Pro/E and gets a license, but not for AAX and they are fine (provided they don’t need the functionality provided by AAX). This doesn’t seem to align with what some of you are describing as a triad related issue, but it’s worth checking.
Erik
