Volume Shadowing

One of the key features to OpenVMS is the ability to span from High Availability to Disaster Tolerance all the way to Disaster Recovery with the same operating system with minimal overhead (cost or manpower) to manage the environment.HP’s Host Based Volume Shadowing (HBVS) for OpenVMS is a key component to the resiliency within a OpenVMS environment. V8.4 will allow you to extend the capabilities of HBVS to meet new and complex demands that face your environment.

For example, with V8.4, you can implement two shadowset members per site in a three site OpenVMS cluster. So, even if you have to drop one member, you will still have a second member that is local. This is incredibly important as more customers implement split-site OpenVMS clusters.

But the improvements are not limited to that. You can pause updates on demand. This will allow you, under program control, pause all I/O requests to the shadow set to perform maintenance activities. For example, you could pause all database activity, then pause I/O activity to the shadowset member, perform a snapshot, restart shadowset member I/O activity, and resume the database activity. The pause of I/O activity to the database is the new feature.

Why is this important? It allows you to create a “crash consistent” view of the database, no matter how complex the transactions. A transaction might consist of multiple records across multiple databases across multiple volumes. With this feature you can quiesce all activity to an OpenVMS shadowset member.

Another new feature is the ability to “Divide and Conquer!”. Okay, that might sound odd, but in fact, by default, OpenVMS does not always readily divide the I/O workload to maximize performance. By default OpenVMS will send read requests to one member and then another and then another. This “round-robin” operations helps reduce the I/O requests to each member. However, if a large sequential read stream wades through the volume, such as what a large SQL job might create, then the arrays presenting the shadowset members never see the sequential read stream. Let’s take the example of a read stream where we:

• Read Record 1 from Member A
• Read Record 2 from Member B
• Read Record 3 from Member A
• Read Record 4 from Member B

and so on…

Though the job reads sequentially through the database, the arrays see a random workload. But if we divide and conquer the workload, then the arrays will see a sequential workload the the LBNs that they serve. The arrays will then prefetch data into cache, which means the read request operates at cache memory speeds, instead of at physical device speeds. Performance boosts, but the load on any specific member is not increased.

By default, with this new feature enabled, the first set of LBNs (the range of which can be set) comes from the first member, the second set of LBNs (also settable) comes from the second member, and so on.

Finally, OpenVMS V8.4 makes it possible to have multiple mini-copy bitmaps. Why is this essential? At the moment, if you dismount a volume with a write bitmap, then if the system where the volume is dismounted crashes before that volume can be remounted, you loose that write bitmap. This adds the resiliency needed in a production environment to the mini-copy bitmaps.

So, can you teach a old dog new tricks. OpenVMS once again comes through and shows it provides extraordinary features for your production environment.