that is not correct. It will be always locally written if possible. The data from the seconday site will only cross ones the connection. But yes you will have a latency by additional meta data over the line if you write on the non preferred site. Much better than Hyperswap. There is a new redbook https://www.redbooks.ibm.com/abstracts/sg248569.html .
Original Message:
Sent: Fri August 09, 2024 06:11 AM
From: Sebbo
Subject: HyperSwap vs Policy Based HA whats the diffference
Hi Evelyn,
i totally agree. But within Hyperswap i could define the primary site for the volume ( each volume )
In PBHA the primary site is defined by the Management System. If a Host writes then to the peer System i have 4 hops on the DWDM
- Hop to Flashsystem holding the Primary site
- Hop from there going to the secondary
- Hop back to confirm write
- Hop back to Flashsystem in peer site
Ack
Within the primary site its
hop to Secondary System
hop back to confirme write
so having PBHA might add for writes 2x more DWDM latency
------------------------------
Sebbo
Original Message:
Sent: Fri August 09, 2024 05:57 AM
From: Evelyn Perez
Subject: HyperSwap vs Policy Based HA whats the diffference
The volumes live across the entire partition.
In order for the local access for Reads you Need to set the location on the hosts. (otherwise everything is forwarded to the primary). Volume Management is always only from one site, that is the nature of PBHA, you treat the volumes as one volume, but with 8.7.0 (and you must be on 8.7.0) you can set a site location for local reads.
Because this is a syncronous replication all writes MUST be done to both sites before we can return, that is true of all syncronous (otherwise you wouldn't have data on both sites.
This was true of hyperswap, stretched cluster, whatever. For a write me must forward and complete it on both sides of the HA before we return to the host. If we didn't do this your data would not be mirrored and you could not failover without data loss.
The locality is about reads. This was ALSO true for Hyperswap.
------------------------------
Evelyn Perez
IBM Senior Technical Staff Member
IBM Storage Virtualize Software Architect for SVC and FlashSystem
Original Message:
Sent: Thu August 08, 2024 03:00 PM
From: Sebbo
Subject: HyperSwap vs Policy Based HA whats the diffference
Hi sure,
But the management site will hold all the volumes.
I could prove it with iometer and switching the management site added the delay of 2*dwdm for all writes /:
So basically the management site is always primary. Having active volumes in the secondary side will always have higher latency this was the reason for two partitions...but having a host in two is not possible?! Correct?
------------------------------
Sebbo
Original Message:
Sent: Thu August 08, 2024 01:19 PM
From: Nezih Boyacioglu
Subject: HyperSwap vs Policy Based HA whats the diffference
Hi Sebbo,
Only one partition is enough, site definitions will help hosts to use their local boxes as primary.
------------------------------
Nezih Boyacioglu
Original Message:
Sent: Thu August 08, 2024 12:38 PM
From: Sebbo
Subject: HyperSwap vs Policy Based HA whats the diffference
Hi Evelyn,
i am currently setting up Policy based HA in Actice-Active mode. I want to have the following setup as i have stetched VMWare clusters.
Host A in DC1 and Host B in DC2
VMs on Host A should run in DC1 storage partion ( to keep DWDM hops as low as possible )
VMs on Host B should run in DC2 storage partition ( to keep DWDM hops as low as possible )
but Hosts should be connected to both storage partitions
So my assumption is to create a Storage partition DC1 and another one DC2 now i wanted to add Host A to both Storage partitions which is not possible.
Am i'm missing something or can a Host be only in one Storage Partition where eg DC1 is the primary site.
thanks a lot
------------------------------
Sebbo
Original Message:
Sent: Mon June 24, 2024 07:58 AM
From: Evelyn Perez
Subject: HyperSwap vs Policy Based HA whats the diffference
Hey Thiago - You are actually describing something known as Non-uniform topology in VMware terms. This feature was in fact added in 8.7.0 as per
https://www.ibm.com/docs/en/flashsystem-9x00/8.7.x?topic=availability-solution-overview and https://www.ibm.com/docs/en/flashsystem-9x00/8.7.x?topic=guide-whats-new-in-870 (and for people who like to get these in a blog, it's on Barry's blog too: https://barrywhytestorage.blog/2024/06/11/ibm-storage-virtualize-8-7-0-including-flash-grid/)
Partitions allow to you set a preferred system or site for management in 8.7.0 - so you have a single place to send configuration commands or check on status of a partition. As of 8.7.0 we allow you to configure host locations or sites to direct preferred traffic, and we allow active paths for local reads.
Here is a good set of pictures to describe this:
Uniform Deployment - all work travels to a single site and hosts need to be visible/pathed to both sites.

Starting in 8.7.0 we also support non-uniform topologies, which allow for local reads (please note writes are still synced between sites as this is syncronous replication and not forwarding to the partner site would not...well, sync your copies!)

In order to make user of this new feature you will need to upgrade your system to 8.7.0 and then set locations on the hosts of interest in your partition as per the documentation (see updates to mkhost, chhost and lshost).
I hope that helps!
------------------------------
Evelyn Perez
IBM Senior Technical Staff Member
IBM Storage Virtualize Software Architect for SVC and FlashSystem
Original Message:
Sent: Fri June 21, 2024 01:37 AM
From: Thiago Lucas
Subject: HyperSwap vs Policy Based HA whats the diffference
Edit: I got a pleasant response in another thread clarifying the question below - Host location settings would apply (multi)path definitions, hence "local" (near to host) copy of the HA volume will be used for R/W. Isn't it pretty much like SVC ESC would work?
------
Hi Evelyn! Not trying to hijack Sebbo's thread, but more in the way to add to the discussion, if you won`t mind clarify:
Consider a ISL attached PBHA scenario where a single VMware vSphere cluster "stretches" between locations, hence hosts from both sites are/must be added to a single storage partition, so all hosts within that cluster can access the same volumes; Hosts are split 50/50 between locations and sized so half cluster can handle 100% VM workload.
As stated PBHA hosts/volumes(groups) have their "preferred system" (or site) handled by policy at the storage partition level; If I got it correctly, in the said cluster setup half of the cluster will always access volumes cross-ISL for both reads and writes, is that right? Or there's granular host/volume affinity that could be setup within the storage partition?
Thanks.
------------------------------
Thiago Lucas
Original Message:
Sent: Mon February 05, 2024 12:19 PM
From: Evelyn Perez
Subject: HyperSwap vs Policy Based HA whats the diffference
Hi Sebbo, to add to Nezih's excellent post:
PBHA is the replacement technology for Hyperswap and differs in many ways from an implementation and a few key ways from a deployment perspective:
Hyperswap is set up within a single system and was limited by our existing Remote copy architecture, meaning it had performance, volume and Bandwidth limits of that code architecture. The Single System is one slightly nice in that you are only dealing with one cluster for things like upgrade, but has the disadvantage that you are still sharing the same cluster state machine across all node, so a code failure there impacts the system. It also means that for any local volumes (e.g. not replicated) a problem with the link could mean that you lose local access as the entire cluster has to see volumes for them to be active.
PBHA is between two independent systems and has more robustness in that you can have local and remote partitions set up on the system machine. Loss of access to the replication partner only results in access to the remote partitions on one site. You will have to upgrade the systems separately, however, advances in our management interfaces means you only have to do the initial configuration of the partnership and then all objects in that partition are only managed/created/changed on one site so it gives you the advantage of a single system management within a partition, but the high availability of two distinct systems.
there are also very large performance deltas as the new PBHA is using our new replication technology that scales a lot closer to non replicated traffic. I recommend trying it out as Nezih recommends or trialling a proof of concept. I think you will find the management much easier along with the other (performance) benefits PBHA offers.
------------------------------
Evelyn Perez
IBM Senior Technical Staff Member
IBM Storage Virtualize Software Architect for SVC and FlashSystem
Original Message:
Sent: Fri February 02, 2024 05:48 AM
From: Sebbo
Subject: HyperSwap vs Policy Based HA whats the diffference
Hi Team,
please help me understanding the difference between Policy Based HA and Hyperswap
As of today we are running Hyperwap beween two Flashsystems. Both Systems serve preferred path IOs and providing non-preferred path IOs in case the preferred path is gone. Access to the Volume is given through both Systems the same time. Some primary volumes reside on site a and some on site b.
Will this be the same situation with Policy Based HA and all the pathes can be used or only in case of a failover?
Within Hyperswap a volume resides on a primary site which can be choosen during creation of the volume. This is important as write IOs will be handeld throuth the primary site.

Will this be the same situation on Policy based HA ?
If yes will the "primary" Pool then be coresponding to the primary site?
thanks
------------------------------
Sebbo
------------------------------