I have deployed two Senhasegura PAM virtual machines, version 3.33.3. I wanted to initiate a cluster and add my two virtual machines there. So I enabled the replication in the Orbit Server Manager > Replication > Settings I got no errors whatsoever, but, in the status, I see that neither of my nodes are primary, in other words, they both have the “Non-Primary” in their status:
I tried clicking “Assume as primary” on my main node, but it doesn’t work.
I tried to make nodes ping each other, and it didn’t work, 100% packet loss.
I checked the orbit firewall status, it didn’t return any IP addresses in the “currently blocked hosts”. I also made sure that icmp is enabled by running “orbit firewall icmp enable” for both nodes. Still, no success. I am not able to make nodes ping each other, neither can I ping any of the nodes from my host machine. I believe that was the case even before I initiated my cluster.
I am using NFR license with all possible modules included. Can someone please help, how can I resolve this issue?
Thank you for reaching out to the Segura® community!
To configure one of your instances as the primary node in the cluster, you can run the following command directly on the instance that you want to designate as primary:
orbit app master
This will promote that specific node to primary within the replication cluster.
Regarding the network issue and the inability to ping between nodes (or from your host machine), we suggest reviewing the following community article:
I was able to configure my senhasegura instances to receive pings and after that successfully promote my main node to master. I checked, the replication worked fine.
However, I decided to test the failover, and shut down my Master node, just to see, how slave node (non-primary) will become a master node. Unfortunately, I ran into another problem.
After my virtual machine rebooted, as I saw services starting, when I got to the login prompt, immediately after that there were more services messages, which wasn’t the case before:
What you’re observing with the services stopping and restarting right after the reboot is expected behavior.
For more information on high availability, failover behavior, and recommended configurations, we suggest reviewing the following documentation: High Availability and Disaster Recovery
However, since your environment is facing persistent issues after shutdown (e.g., services not fully stabilizing and the application being inaccessible), we recommend opening a ticket with our official support team to allow for a more in-depth analysis, as this case may require investigation specific to your deployment setup.
