Skip to main content
Pure Technical Services

Replication User Guide | Pure CBS on Azure

Currently viewing public documentation. Please login to access the full scope of documentation.

KP_Ext_Announcement.png

Introduction 

This guide provides a guideline on how to prepare Azure cloud network infrastructure for establishing communication between two Cloud Block Store instances. It also provides step-by-step instructions on how to configure and enable synchronous and asynchronous replication for various supported topologies.  

Pure Replication technology are built-in features into Purity Operating Environment that require minimal configuration effort to implement. Similar to FlashArray, Cloud Block Store can leverage the different replication features, enabling data mobility between on-premises arrays to the cloud, or between different availability zones, regions, and clouds (from Azure to AWS, and vice versa). 

As any other Pure feature and capability, enabling replication on Cloud Block Store does not require any additional plug-ins to be installed, nor advanced license bundles to be purchased. All the feature set are already included.

Replication Features

It is important to understand the appropriate replication technology suitable for your use case before getting into how to configure and implement it. This section provides an overview for all the replication features supported by Pure Cloud Block Store. It also covers a comparison between the features in terms of configuration complexity as well as performance and cost. 

ActiveCluster

ActiveClusterPure Storage® Purity ActiveCluster is a fully symmetric active-active bidirectional replication solution that provides synchronous replication which provides RPO/RTO zero capability at the storage layer. ActiveCluster can be set up within or across multiple sites, enabling clustered hosts and applications to be deployed into resilient active-active datacenter configurations.

ActiveDR

ActiveDRActiveDR delivers continuous, or near synchronous, replication between two FlashArrays (or Pure Cloud Block Stores) within or across disparate data centers. ActiveDR enables a near-zero Recovery Point Objective (RPO) that is much lower than traditional asynchronous replication based on periodic snapshot differencing. A lower RPO means failover to a disaster recovery site will incur only a minimal amount of data loss.

Asynchronous AsynchronousPure Storage provides Asynchronous replication: a license-free, array based, data reduction-aware asynchronous replication solution that’s simple to configure and manage while providing robust capabilities for enterprise workloads. Asynchronous replication is a snapshot-based asynchronous replication solution that leverages space efficient snapshots to replicate point-in-time consistent copies of multiple LUNs.
CloudSnap Cloudsnap.pngPurity CloudSnap™ provides simple, built-in, "self-backup to cloud" protection for FlashArray arrays (including Cloud Block Store), using Pure's portable snapshot technology. The portable snapshot technology encapsulates metadata along with data into the snapshot, making the snapshot portable, so it can be offloaded from a Pure to the cloud in a format that is recoverable to any Pure Array (FlashArray or Pure Cloud Block Store).

In order to help understand what each replication feature means for Cloud Block Store, the below table walks through a couple of the replication feature's essential characteristics. 

Feature

Setup Complexity 

Recovery Complexity

Performance

Total Cost

Objective

CloudSnap

Low

High
 

Low

$ (Azure Blob /AWSS3)
No CBS running

- Long-term Archive

- Cold DR Site

Async Replication

Low

Medium

High

$$ / $$$ 
1 or 2 CBS running

 

- Warm DR site

- Remote snapshot protection

ActiveDR 

Medium

Medium
 

High

$$$
1 or 2 CBS running

- Near-zero RPO

- Easily automated failover

ActiveCluster

High

Low

Highest

$$$$
2x CBS running
 

- Zero RPO/RTO

- Automatic and Transparent failover

For the purpose of selecting the replication solution that matches your business need. The below diagram helps illustrate the time to recover from an incident "Recovery Time Objective" (RTO), and how often data is being backed up or protected "Recovery Point Objective" (RPO).

clipboard_e6b0d989bb608f24217dbfdc99598f814.png


Replication Topology 

Pure replication enables seamless data mobility and ensures workload resilience. Pure Cloud Block Store in Azure can be configured to replicate data between other arrays (FlashArray and Cloud Block Store) in various topologies. 

Replication between Cloud Block Store instances or using CloudSnap can greatly minimize customer cloud spend on ingress/egress charges since snapshots are deduped, compressed and the same bits are not sent twice.

Intra Azure

Organizations that built or migrated their critical workload(s) to Azure and are looking to protect those applications against Availability Zones or regional outages can use the following topologies:

Intra region: Same VNet - Different AZ

This topology does not require any Azure network configuration. All communications are routed in the same isolated Virtual Network. 

Note: Make sure that the subnets network security group (NSG) allow management and replication traffic between both CBSs. Refer to Intra-Subnet traffic.

 

clipboard_ee929e8feb7f7a44bab9793d98ecf2b47.png

Intra region: Different VNet- Different AZ

This topology establishes replication between two CBSs that reside in different VNet by leveraging VNet Peering. Both Async and Sync connectivity types are supported with this topology. Refer to the Interoperability table for more info.

clipboard_ec76b40eb405cc55a4a6c8ee2f76c4a15.png

Inter-region

Similar to the Intra region between two different VNet. VNet Peering capabilities can be used for connecting two VNet in different regions. 

clipboard_e7ea1ab352c18de4a2480eae349f1cc48.png

- Peering virtual network will incur ingress and egress traffic is charged at both ends of the peered networks. Check pricing page for more information.

- VNet Peering can be also be configured between two VNets in different Azure subscription. 

Multi Cloud: Azure to AWS

There are various options to establish communication between two cloud providers. These options differ in speed, latency, reliability, service-level agreements (SLAs), complexity, and costs. The common and easiest way is to use Site-to-Site VPN Gateway. It is the fastest deployment option, but won't provide a high throughput and low latency compared to Azure ExpressRoute. Read more about design guidelines in the following section. 

Replication CBS - MultiCLoud.png

Hybrid Cloud: On-premises to Azure

Providing the network connectivity between a physical datacenter (FlashArray) and Azure infrastructure (Cloud Block Store) can be achieved in a number of ways, including Azure ExpressRoute or a Site-to-Site-VPN connection. Read more about design guidelines in the following section. 

Replication CBS - Page 9.png


Replication Interoperability

For full Purity replication interoperability matrix, please refer to this document here.

Peer Array Type / Replication Feature

Async Replication ActiveDR  ActiveCluster

Active-Active Async

FlashArray <> Cloud Block Store

Yes
 

Yes No Yes*

Cloud Block Store <> Cloud Block Store

Yes Yes Yes Yes

* Active-Active Async is only supported for Cloud Block Store configured as the Async target array.

 


Networking Configuration 

This section covers Azure network configuration required to establish communication between FlashArray on-premises and Cloud Block Store Instances running in Azure or AWS. It is important to point out that none of the replication features Async nor Sync would work unless both arrays can see each other via replication and management interface ports. This rule is not applicable for CloudSnap, since it is an array to cloud object storage (Azure Blob/ Amazon S3) relationship. 

It is highly not recommended to use public IP assigned to replication interfaces for connecting arrays over the internet. Secure tunnels or internal Azure connection are the main solutions for replication network routing. The most common network services are VNet Peering for Azure to Azure, and Site-to-Site VPN or ExpressRoute for Azure to on-prem or other cloud providers.  

clipboard_eb2286d62db3482fce0443871b58b6b79.png

VNet Peering

VNet stands for Azure Virtual Network, which is the building block for implementing Cloud Block Store underlying Azure resources. It enables Azure resources (CBS Controller VMs) to securely communicate with each other over a low-latency, high-bandwidth connection using Azure backbone network. This communication can be extended to other VNets using VNet Peering service, whether the VNet is in the same or different Azure region (also known as Global VNet Peering).

When replicating between two Cloud Block Store instances running in Azure, network connectivity can be achieved using VNet Peering. This works by establishing an internal connection through Azure backbone network to connect CBS A located in VNet A to VNet B where the second CBS B resides. 

VNet Peering is not required to configure replication between CBS instances residing within the same VNet. Running two CBS in the same VNet is a possible deployment topology for protecting against AZ outages. For more information, refer to the previous section. 

Prerequisites

  1. Deploy Two CBS, in two different Availability Zone or regions.

    1. Select a supported region

    2. Follow the implementation guide, prepare the prerequisites, and deploy.

Locate Virtual Networks

  1. In the search box at the top of the Azure portal, look for the first CBS Managed Application, When it appears in the search results, select it. Alternatively, you can access the managed application from the Resource Group. 
    clipboard_e0896be78648dc0d3548dc93441a3ffe1.png
  2. From the left-side panel, click on Parameter and Outputs.
    clipboard_e75d7faf24c029175c67a39bffad8a05a.png
  3. Under Parameters, you can find CBS VNet (as highlighted in the screenshot below). Take a note of the parameter fileds. 
    clipboard_ef4911e46ea644bfadeaeb210881e88c8.png
  4. Repeat the above steps 1-3 for the second Cloud Block Store.  

 

Peer Virtual Networks

  1. In the search box at the top of the Azure portal, search for the noted VNet of one of the Cloud Block Store. Once it appears in the search, select it. 
    clipboard_e40e70c808f204248fe4375c1d0565709.png
  2. From the left-side panel, select Peerings, and then select + Add. 
    clipboard_ed407f7dfacbb4076ef021f11dd3d61eb.png
  3. Under Add peering, enter the following, then select Add.
    1. This virtual network: Enter Peering link name, then keep the default for the other settings. 
    2. Remote virtual network: Enter or select the second Cloud Block Store VNet retrieved from previous section. Also there is an option to select another different subscription.
      clipboard_e765eb5f0ad3d63568f50c2ec93bb0aa7.png
  4. In the Peerings page, wait until the Peering status is Connected.

Note: If you are using Network security groups on the subnet level, make sure to allow management and replication ports for Intra-Subnet traffic.

Site-to-Site VPN

For secure hybrid connectivity, extending on-premises networks to Azure. Azure site-to-site VPN gateways are an easy and fast deployment option to configure. It can help connect your datacenter infrastructure (FlashArrays) to your VNets (i.e. where Cloud Block Store resides) securely. 

Similarly, you can use Azure site-to-site VPN to connect to other cloud providers for multi-cloud connectivity. An example is provided in the above section for Azure to AWS replication topology, where two Cloud Block Store instances can be connected. 

Prerequisites

  • Cloud Block Store is deployed on Azure. If not, follow the implementation guide, prepare the prerequisites, and deploy.
  • For Hybrid only: 
    • FlashArray is implemented, and replication interfaces are configured. Check configure replication requirements. 
    • Check if VPN devices in your datacenter are valid. For information about compatible VPN devices and device configuration, see About VPN Devices.
    • Verify that you have an externally facing public IPv4 address for your VPN device 
  • For MultiCloud: Cloud Block Store is deployed on AWS. See Cloud Block Store Implementation guide on AWS.
  • Make sure private IP address space (CIDR) of the Azure VNet is not overlapping with the on-premises network subnet or AWS VPC CIDR block. 

Design Recommendation 

  • One of the recommended architectures of secure hybrid networks is to establish Hub and Spoke topology, which works by implementing a perimeter network (DMZ). For more information, refer to this reference architecture
  • In case, the cross-connectivity requirements are bandwidth and latency specific and are based on service-level agreements (SLAs). ExpressRoute might be a better option. It requires more dedicated circuits and complex setup than VPN gateway. However, it provides communication over a private network, higher throughput, and lower latency. The figure below is referenced from an Azure cloud adaptation framework documentation that can help you to decide which option to consider.

Diagram of cross-cloud connectivity flow chart

Configuration

The following are high level configuration steps, more details are linked in each step that refers to Pure and Microsoft documentation.

Purity Configuration

From Purity configuration prospective. Configuring replication on Cloud Block Store is the exact same procedure as on FlashArray. Each of the following sections provides links to follow for the complete details on each replication configuration steps.

Async Replication

ActiveDR

ActiveCluster

CloudSnap