I have deployed Cisco HA Advanced, using Single VIP.
1st Failover to Slave server is automatic. And Revert back to regional states is manual procedure.
I need to know;
(1) Can we make revert back procedure automatic? Once Master server is restored, it should know automatically; sync database by making itself slave and sync from current Master, once DB is synced, it take over as master....
(2) For example if we have some power outage on both server at the same time; how would we know which server has active database? Can NSO automatically recover back to its original state before it was ?
In tailf-hcc (all versions ti date), the ability to 'auto' failback to the original master-slave config following a master->slave failover is not possible. This was done to ensure that the user manually determines which CBD, the slave or master following failover, is the most recent prior to failing back.
With tailf-hcc, there are situations in which the Slave node will claim mastership (and create a VIP interface), but the original Master node will still think that it is master (with a VIP interface) - yes a split brain situation. The slave has claimed mastership since its 'pings' to the master fail because it can no longer connect/communicate with the master. In cases where the Master server dies or the NSO server crashes, this is great and slave is the sole master. However, in cases where only the network failure between the nodes is blocking the 'pings' (the master server and NSO are still operational) the slave claims master and cannot communicate with the master to inform it of the failover - thus both are masters.
In this case if your northbound client is issuing NSO requests to the VIP it's likely it will continue to update the original master - or in some northbound/network designs it may connect to the VIP on the failed over Slave.
It needs to be determined which CDB is being updated after the failover event - in todays tailf-hcc this needs to be done manually.
Enhancement requests have been made for 'auto-failback'. Currently, NSO HA is getting a rework to provide simpler configuration including the ability for 'auto-failback' targeted for NSO 5.4 I believe.
SW upgrade or migration is something you never can escape from so it's better to make it part of your process. The remaining challenge is to determine when to give up what has been working to secure your future needs. Martin and the NSO team will guide y...
There is not a single golden tool that fits all purposes simply because development processes and needs are different. Instead, pick the tooling you need from the Smörgåsbord and build your environment to suit your needs. Shashidhar will guide you throug...
How Verizon Streamlined NSO Development with Continuous Integration
This is a customer success story of how Verizon ITNUC builds a CI chain to streamline the NSO development process. The containerized NSO makes testing several NSO packages in para...
It is best practice to avoid storing your secrets (e.g., passwords and shared keys) in plain text, either on NSO or on the device. In NSO, we support multiple encrypted data types that are encrypted using a local key. Similarly, many devices such as Cisco...