6 of 6 people found this helpful
You might aware that OSIsoft is not recommending PI AF Collective due to its cons.If you are planning to implement high availability then would request you to implement PI AF using cluster or NLB and you can take full advantage based on your hardward deployment.
4 of 4 people found this helpful
From a coding perspective, you need to be connected to the Primary AF Node in order to write - writes means changes to the meta data that AF stores. So you would need to check you are connected to the AF Primary node before doing updates.
If you have some satellite applications dotted around that only need read access to an AF model for processing some logic then AF Collectives are fine and work fine.
Generally, most use case I have seen don't need an AF Collective. What they need is a scale out of the Analysis Service not the meta data store.
Echoing previous responses, AF Collectives are not recommended any more. The linked KB article does a good job of going through the pros and cons of all the availability options.
With regards to your second question, secondary AF Collective members are (permanently) read only. They cannot be promoted (unlike Data Archive collective members).