SAP NetWeaver design considerations

HA and storage fencing (that is, Quorum-based) considerations

Cluster environments typically use IPMI-based components for the “fencing of cluster nodes” to ensure a quorum. Due to enterprise security in the IBM Cloud Classic Infrastructure environment, network-based access to remote management devices through the Intelligent Platform Management Interface (IPMI) isn’t available. Although IPMI is still used to manage the physical device if necessary.

In the absence of an IPMI-enabled device, shared storage devices are used.

In an IBM Cloud environment, shared storage devices are implemented by deploying an iSCSI LUN to your servers as a quorum device.

For example, a File Share Witness (FSW) on a Microsoft Cluster, and for storage-based death (SDB) for Linux Pacemaker's Stonith.

• Click here for more information on Linux High Availability Cluster Concepts.
• Click here for more information on configuring and managing quorum servers for Windows Server 2012 and Windows Server 2012 R2.

IBM Cloud Block Storage has built-in HA capabilities, so a single shared iSCSI LUN does not introduce a Single Point Of Failure (SPOF) because your network layout is redundant. However, the specifics of your cluster product might require multiple quorum devices.

HA and network considerations

An IBM Cloud Classic Infrastructure environment-based installation comes with one of the following network configurations:

• Private network
• Public network
• Public and private networks
• Two private networks (on special request, dependent on the server type and physical hardware components configuration)

Like on-premises installations, extra network adapters can be ordered depending on the physical restrictions of the hardware. The restriction is the same for on-premises installations, how many NIC cards can fit into the Bare Metal.

Ordering redundant network adapters during hardware deployments helps prevent single point of failures (SPOF) across your network topology.

Redundant adapters for Bare Metals are set up in a failover configuration with Link Aggregation Control Protocol (LACP). For Linux, the setup uses bonding interfaces, and teaming adapters are used for Microsoft Windows. Doing so will create a logical interface for redundancy and increased bandwidth.

When using IBM Cloud for VMware Solutions, redundant adapters for VMware are set up by the VMware vSphere Distributed Switch (VDS) using either VDS on NSX-V or VDS on NSX-T, in accordance with current VMware best practices for SDDC. While subject to change, redundancy is configured by setting every Distributed Switch with the Route Based on Originating Virtual Port load balancing algorithm, with all contained Port Groups using Teaming across 2 uplinks (Active: 0,1). When using IBM Bare Metal with VMware vSphere for a manual installation using vSwitch, LACP bonding of the physical NIC adapters could be used. This configuration choice depends on the need for increased throughput (e.g. bonding) versus redundant stability (e.g. load balancing with teaming).

The NIC adapters are connected to redundant Switches on, so no additional SPOFs are introduced. The redundant infrastructure can be used by the ordered VLANs.

For some network requirements, such as DR setup replication scenarios, you must check the location of the connected devices and any new network requirements specific to the software/application in question. In some cases, the IBM Cloud Classic Infrastructure's File or Block Storage with snapshot backups might fulfill your requirements. Check with IBM Cloud Support to determine which solution works best for your business needs.