IBM Support

Disk communication and SSP resiliency in Shared storage pool

General Page

Shared storage pool concept is storage virtualization using IBM Server. In todays cloud era reliability is utmost important. Cluster always use network interfaces in order to communicate among the nodes. So once network is up it will keep on communicating with other nodes using the network. There are many situations where n/w of nodes might go down.

1) N/W or switch maintenance
2) Server maintenance
In such a situation, node might be down and the communication between clients and nodes break. There could be situation that some workload/Application of client could be running, and node gets down, which will be one of the major disaster things happen in the cluster. So, to have better reliability, IBM SSP technology introduced one of the techniques that keeps the clients running may be with degraded performance, but the application will keep on running without any issue.

SSP is storage virtualization technique using the server. DPCOM is single point of failover from the storage point of view. DPCOM is one special disk need to define in the cluster and it could be of any size. When the cluster is up, the nodes keep on communicating using the repo disk. Repo disk only works when the network is up. When network is down, the meta data which is copied from the repo disk to the dpcom disk and node start communicating using the dpcom disk and client will keep on running the workload.

The dpcom interface is only used when all other network interface is considered down. Once any of network interface is up, the node/client will start communicating with that source and dpcom interface is no longer being used. A node is considered to be in degraded mode when it is using disk communication for the primary interface.

This will avoid the down time for the clients running mission critical workload.

#How to add dpcom disk to the cluster

#cluster -addcompvs <PhysicalVolume>

The disk should be part of cluster.

(0) padmin @ tarv1: /home/padmin

$ lspv

NAME             PVID                                 VG               STATUS

hdisk24          00c04c370fd97e31                     comdisk_vg       active

This will show how it looks like in the above output. VG-> comdisk_vg.

When network is down, the node will automatically failover to dpcom and start using the communication over the disk. If disk communication is active and we detected that TCP/IP connection is online then we select the TCP/IP connection.

To remove comm disk from the cluster.

cluster -rmcompvs <hdisk#>

How to utilize it.

# netstat -in

Name   Mtu   Network     Address                 Ipkts     Ierrs        Opkts     Oerrs  Coll

en4    1500  link#2      5c.f3.fc.ea.8e.9a          5288935     0          2583875     0     0

en4    1500  9.3.49      9.3.49.46                 5288935     0          2583875     0     0

lo0    16896 link#1                                 402518     0           402518     0     0

lo0    16896 127         127.0.0.1                  402518     0           402518     0     0

lo0    16896 ::1%1                                  402518     0           402518     0     0

#ifconfig en4 down.

After making n/w down , this will start using dpcom i.e start communicating through dpcom.

# pooladm dump cnxs

ClusterName=tar-tulp  MyNodeName=tarv1.isst.aus.stglabs.ibm.com:

CONNECTIONS WITH SERVERS:

Server: name=tulpvm3v2.isst.aus.stglabs.ibm.com nodeId=0xE4DFC896BF4E11EA:80295CF3FCEA8E9B lease state=VALID

        lease phase=FIRST ip=10.33.16.12 (LEADER)

 Net     [0]: Lease state=VALID phase=FIRST cnx=ACTIVE IPAddr=10.33.16.12 (PrimaryIP)

             Lease renew=27697 LRSent=27671 LRAcked=27671

             MsgSent=26 MsgRcvd=55378 avgRespTime: 0 sec 0 nsec

             avgDeliverTime: 0 sec 346070 nsec maxDeliverTime: 0 sec 8997844 nsec

             ConnSwitchMsg sent=0 ackd=0 markDlvrd=0 lastAckedTxnIdByServer=0 CSServerNo=0

             cnxCheckPending=0

 

DiskCom [1]: Lease state=VALID phase=FIRST cnx=STANDBY    -dpcom mode

             Lease renew=5239 LRSent=5239 LRAcked=5239

             MsgSent=0 MsgRcvd=10480 avgRespTime: 0 sec 0 nsec

             avgDeliverTime: 0 sec 0 nsec maxDeliverTime: 0 sec 0 nsec

             ConnSwitchMsg sent=0 ackd=0 markDlvrd=0 lastAckedTxnIdByServer=0 CSServerNo=0

             cnxCheckPending=0

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSPHKW","label":"PowerVM Virtual I\/O Server"},"ARM Category":[{"code":"a8m50000000L0aLAAS","label":"PowerVM VIOS-\u003EShared Storage Pool {SSP}-\u003EVIOS {SVIOS}-\u003ESHARED STORAGE POOL (SSP)"},{"code":"a8m50000000L0aBAAS","label":"PowerVM VIOS-\u003EShared Storage Pool {SSP}-\u003Epoolfs {SPLFS}"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)","Line of Business":{"code":"LOB57","label":"Power"}}]

Document Information

Modified date:
03 June 2021

UID

ibm16245332

Page Feedback