We have one requirement for installing one of the software on two nodes by using shared file system (block). However, as we are running SLES 12.x VMs on Azure platform, we don't have option of using centralized shared storage system like iSCSI SAN or FC.
However, there were discussions going...
We have 2 Network Adapters (each vm) assigned with the same subnet IP addresses on Azure SLES 12.x on two VMs, as this is requriement by client application team. However, we were facing some network communications issues (unable to reach) between two servers. Communication is fine if we disabled...
Today we have observed few more things
We have observed few things from the today testing. Following are the steps:
Step 1: When we create kernel panic (on Node01) with the command “echo 'b' > /proc/sysrq-trigger” or “echo 'c' > /proc/sysrq-trigger” on the node where the resources are running...
OS and Pacemaker Versions:
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP4" CPE_NAME="cpe:/o:suse:sles_sap:12:sp4"
pacemakerd --version
Pacemaker 1.1.19+20181105.ccd6b5b10-3.16.1
corosync -v
Corosync Cluster Engine, version '2.3.6'
When cluster resources are running on glbgvldbies01...
We are using SLES 12. We have a custom application which doesn't have daemon / Resource Agent.
To Start the Application
runuser -l bnp -c 'start_biom'
To Stop the Application
runuser -l bnp -c 'stop_biom'
To Monitor the Application
ps -ef | grep biom
Scenario:
Customer recently Migrated Clustered HANA DB Servers to Azure Cloud Platform but these are Physical Servers on Azure (Offering: Azure HLI). Usually these HLIs (HANA DB Servers) in Azure cannot be accessible directly, even not from Azure VNETs. In other Words, HLIs cannot access...