1 Reply Latest reply on Mar 7, 2014 12:33 PM by Marcos Vainer Loeff

    PItoPI failover configuration - PI SDK member




      Have thrown this question to techsupport many times but haven't found a reasonable answer. I need to unerstand the best practice in order to configure PItoPI interfaces in a failover mode having both source PI and detsination PI configured as collectives.


      For a destination PI server ---> "PI SDK Member field" in General Tab :


      The primary interface field is configured with the "Primary PI server" node while the backup Interface is configured with the "Secondary PI server node". May I know what would be the consequences if both the interfaces point to the "primary server only"? What are the advantages or purpose of configuring each failover instance pointing to different member in a collective?


      Similarly for Source PI :


      What are the advantages of selecting different members in a collective for each failover interface or is it not? Question raised because we also have source level failover node wherein the secondary node can be mentioned.


      So basically what are the best practices for source and destination servers in a failover interfaces with this kind of architecture.

        • Re: PItoPI failover configuration - PI SDK member
          Marcos Vainer Loeff

          Hello Mansi,


          I will shed some light with you my opinion but probably there are other reasons to complete my answer.


          Concerning the destination PI server, I believe the main reason for setting up the way you have described is to lower the chances of losing data when the interfaces start.  If a PItoPI interface is not configured with Disconnected Startup, it will not be able to start and get the PI Point list unless it connects to the member of the PI Server of the interface batch file (/host parameter).  Therefore, if both interfaces instances have the primary PI Server member selected on ICU, they won’t be able to start in case the primary PI Server is not available, even if a secondary PI Server is. In this case, there will be data loss. Nevertheless, if the /host parameter of one interface instance is a secondary PI Server,  in case the primary PI Server is not available, the interface will get the PI Point list from the secondary PI Server,it will assume the role of primary and it will send the data to both members of the collective. The other instance won’t be able to send data until the primary PI Server gets available.


          Concerning the source PI Server, I don’t see any major advantage unless to better distribute the load (including network, CPU, memory) between the two PI Server members of the collective.


          Hope this helps you!