Prerequisites | Pure CBS on Azure

Supported Regions

Please refer to the Cloud Block Store Support Matrix for Azure for the latest support regions.

► For deploying CBS version 6.5.0 and below - click here

Microsoft Entra ID Premium 2 License (MANDATORY for CBS 6.5.0 and below)

Cloud Block Store on Azure requires the usage of Just-in-Time (JIT) access, which enables Pure to provide live support and perform non-disruptive upgrades for customers. JIT allows customers the ability to approve requests from Pure Support to perform support functions. The JIT approval capability requires customers to have an Microsoft Entra ID P2 (former Azure Active Directory P2) license. The cost is nominal since only a single user license is needed for the Azure tenant and it does not need to be assigned to any particular Azure user for the JIT approval function to work. For pricing details, see Microsoft Entra ID pricing.

To view your subscription license type, navigate to the Azure Active Directory window.

PS Azure:\> Get-AzVMUsage -Location west-us2
cmdlet Get-AzVMUsage at command pipeline position 1
Supply values for the following parameters:
(Type !? for Help.)
Location: west-us2

Name                              Current Value Limit  Unit
----                              ------------- -----  ----
Availability Sets                             0  2500 Count
Total Regional vCPUs                          2  1126 Count
Virtual Machines                              1 25000 Count
.
.
Standard DSv3 Family vCPUs                    0   128 Count
.

Security:  Azure IAM Roles (Mandatory)

In order to deploy Cloud Block Store, a user must have the necessary roles and permissions. The simplest option is to have the Contributor role for the subscription in which they want to deploy the Cloud Block Store instance. If that is not possible, a user can still deploy Cloud Block Store as long as they have the minimum three roles below:

• Managed Application Contributor role of the Subscription.

• Managed Application Contributor role of the Resource Group for which you want to deploy the Cloud Block Store manage application.
  • Note: This will be inherited from having Managed Application Contributor role on the subscription.

• Managed Application Contributor role of the subnets which you would like Cloud Block Store managed application to use.
  • Note: This will be inherited from having Managed Application Contributor role on the subscription. In addition, many users may already have this role since it is used to create basic VMs. 

Network:  Interfaces

Cloud Block Store deploys with the following four network interfaces on each controller VM:

1. System
2. iSCSI
3. Management
4. Replication

During deployment, users will be asked to select the desired Virtual Network (VNet) and subnet for each of the four Cloud Block Store network interfaces.

• Prior to a Cloud Block Store deployment, customers should have existing VNets and subnets for which they wish to deploy Cloud Block Store. Creating new VNets and/or subnets during the Cloud Block Store deployment is not supported, and will result in a failed deployment. 
• All network interfaces must be in the same VNet since these interfaces are all attached to the same controller VM. This is a fundamental Azure requirement.
• The network interfaces can reside on the same subnet or separate subnets. There are two typical network configurations:
  • The simplest topology is to place all Cloud Block Store interfaces (system, iSCSI, management, replication) onto a single subnet.  This topology is recommended for POC or exploratory CBS deployments only. 
  • Cloud Block Store also supports different subnets for each networking role. This network topology offers an optimal solution because it allows traffic isolation. In addition, we recommend this network topology when replicating between a Cloud Block Store instances and/or FlashArrays on-premises that are on different networks via Site-to-Site VPN gateway or VNet peering. This minimizes the chances of having a network overlap when different networks are connected. See the following network configurations diagram for an example of this topology.
• Ensure the subnet for the System interface has internet access; see the Internet access section below.

     Network configuration option diagram: 

Network:  Internet Access (Mandatory)

A Cloud Block Store managed application will have four network interfaces which include iSCSI, management, replication, and system. When you deploy a Cloud Block Store managed application, you will be given a choice to select the desired subnet for each interface. The subnet for the system interface must have internet access prior to deploying your Cloud Block Store managed application. Internet access ensures that the Cloud Block Store managed application can phone home to Pure1, providing logs, alerts, and additional cloud management services. Before you deploy Cloud Block Store, please ensure that the intended subnet for which the System network interface will reside has appropriate routing to the internet.

Internet access can be achieved in several ways. There is no preferred method as long as Cloud Block Store can reach Pure1 through the public internet. Below are three example options. There are other options as well that are not specifically documented here.

• Option 1: NAT Gateway - A simple way to allow internet access for a Cloud Block Store managed application is to add an Azure NAT gateway to the subnet which the Cloud Block Store System interface will reside. This should be completed before you deploy Cloud Block Store.

Note: The NAT Gateway must be directly on the subnet of the Cloud Block Store System interface. Using a NAT GW tied to a remote VNet through a peered link or VPN gateway will not work since Azure does not support NAT Gateway access through cross VNET connections.  

See Appendix B for steps to create and configure an Azure NAT gateway.

• Option 2: On-Premises - Many customers have a requirement to route network traffic back through their physical datacenter. This is also supported as long as the appropriate routes are in place to allow traffic from the Cloud Block Store System Interface to reach Pure1. Ensure all the appropriate ports are open through all the relevant firewalls. The required ports, destination IP addresses, and destination FQDN are seen above in the Azure Firewall rules tables.

Network:  Firewall Rules (Azure or 3rd party firewall)

Many customers already have network security controls in place to monitor and control network traffic flowing into or leaving their Azure networks. If an Azure or other 3rd party firewall is not in use, this section can be skipped. If a firewall does exist, it must be configured to allow the appropriate ports to access the internet. See the table below for general firewall port configuration settings of both your Network and Application rules. You should also ensure your subnet routes appropriately to the firewall, specifically the intended subnet for the Cloud Block Store System interface. This must be completed before you deploy Cloud Block Store. 

See Appendix C for example detailed steps on configuring the Azure Firewall for your Cloud Block Store managed application.  The below sample diagram shows Azure Firewall, however, any 3rd party firewall in use can be substituted as well.

Firewall - Application rules:

*Only required if using Azure blob as a snapshot offload target

Azure Firewall - Network rules:

Network:  Service Endpoints (Mandatory)

Cloud Block Store managed application uses CosmosDB to store metadata information pertaining to the Cloud Block Store configuration and underlying resources. It is important to ensure this traffic stays within the Azure network rather than traverse over the public internet. The below endpoints should be created for the subnet that is used for your Cloud Block Store managed application's System network interfaces. It is important to note that the combination of  Service Endpoints and Network Security Groups must be configured  

• CosmosDB
• Azure Key Vault

See Appendix D for steps to add Service Endpoint to a subnet.

CloudSnap - For customers who are looking for a lower cost Disaster Recovery alternative to replication, CloudSnap is a viable option. FlashArray customers can use CloudSnap to send snapshots of their volumes to Azure Blob store or Amazon S3. The snapshots are self-contained with the meta-data needed to restore onto any other FlashArray or Cloud Block Store instance. For the DR use case, customers can periodically send CloudSnap snapshots to Azure Blob storage or Amazon S3. In a DR event where the primary site is inaccessible, customers can deploy a new Cloud Block Store instance on-demand and restore their CloudSnap snapshots. Once the CloudSnap snapshots are fully restored on the Cloud Block Store instance, customers can attach the volumes to the application VMs and resume application services. This DR alternative provides a lower cost option for customers who have a higher RTO/RPO tolerance. Since volumes are being restored from Azure Blob storage (or Amazon S3), the RTO will largely depend on the amount of data that has to be restored. 

If you expect to use CloudSnap with Azure Blob Store, ensure the Replication network interfaces have service endpoints to:

• Microsoft Storage

See Appendix D for steps to add Service Endpoint to a subnet.

Network:  Network Security Group Rules

For customers who have a security requirement to allow list all outbound traffic from their Azure Resource Groups, some outbound security rules must be added to the Network Security Groups in order for Cloud Block Store to function properly.  Customers who allow all outbound traffic for port 443 can skip this section.

See Appendix E for steps to configure and use Subnet-level Network Security Group.

Network:  Replication

Replication - When replicating from a FlashArray on-premises to a Cloud Block Store instance in an Azure VNet, confirm that there is network connectivity between the respective sites. Similarly, replication between multiple Cloud Block Store instances requires network connectivity between the instances. In order to replicate between a Cloud Block Store instance and a physical FlashArray, the management ports between the Cloud Block Store instance and the FlashArray must be able to communicate. Likewise, the replication ports between the two appliances must communicate. Configure any applicable network security groups (NSG), firewalls, and routing tables to allow traffic between the two sites for the respective management and replication ports.

When replicating between a physical datacenter and the Azure VNet, you can achieve network connectivity in a number of ways, including Azure ExpressRoute or a Site-to-Site-VPN gateway.

For additional details on replication requirements and limits, see the Purity Replication Requirements and Interoperability Matrix.

ActiveCluster - ActiveCluster allows customers to synchronously replicate their Cloud Block Store volumes between two different Availability Zones. This protects customers from a full Availability Zone outage. 

In order to use the ActiveCluster feature, it must first be enabled by Pure Storage Support. 

Once ActiveCluster is enabled, steps to configure ActiveCluster can be found in the  ActiveCluster Quick Start Guide.

CloudSnap  

If you expect to use CloudSnap with Amazon S3 buckets, ensure you allow https traffic (port 443) on your replication interface (firewalls, NSGs, etc) to the internet. 

The following table provides the port number for each interface.

Network:  Security Groups

During deployment, network security groups will be automatically created with different security rules for each Cloud Block Store interface. 

• The network security groups are automatically created during deployment and applied to the individual Cloud Block Store network interfaces.
• There is no action needed by the user except to ensure internet access from the Cloud Block Store system interface has been allowed; see the Internet access section.
• Below are the TCP ports numbers used for the different Cloud Block Store interfaces.

Security: User Managed Identity (Mandatory)

Every Cloud Block Store deployment has multiple components, including Azure Key Vault and Cosmos DB. Those two Azure services are part of the managed application resources and are accessed by the CBS Controller VMs via Service Endpoints attached to the CBS System Subnet (You can learn more about networking in the previous sections).

By default, CosmosDB and Azure Key Vault are created with public network access enabled.  In order to limit access to the network where the System CBS service is running, CosmosDB and Key Vault firewall roles can be automatically configured during deployment by the CBS itself.  This is accomplished by using a user managed Identity that has privileges to modify the CosmosDB and Key Vault configuration. 

The User Managed Identity is a prerequisite that needs to be done prior to CBS deployment. See Appendix F for steps to create and assign User Managed Identity over a vNet that CBS will utilize.

JIT Configuration

1. Select Manual mode
2. Click Add Approver

On the right hand side, search and select user(s) whom you wish to be approvers for JIT requests from Pure Support.

Click Save.

Creating and Configuring NAT Gateway for Cloud Block Store

Prior to deploying a Cloud Block Store managed application, you must ensure outbound traffic is allowed to the internet. A simple way is to create a NAT gateway and apply it to the desired subnet of the Cloud Block Store's system interface. 

Create NAT gateway:

1. Log onto the Azure Portal and search for Nat gateway.

Click Create.

3. Complete the desired parameters for your NAT gateway.

4. Click Next:Outbound IP.
5. Select existing or create a new Public IP address for your NAT gateway.

6. Click Next: Subnet.
7. Select the VNet and subnet to which you want your NAT gateway applied. This should be the VNet subnet for which you expect your Cloud Block Store's System network interface to reside.  

8. Click Next: Tags.
9. Apply desired tags as needed.
10. Click Next: Review + Create.
11. Click Create. 

Your desired VNet/subnet now has internet access via the NAT Gateway.

Configuring Azure Firewall for Cloud Block Store

This section will walk you through configuring your Azure Firewall to allow traffic to the internet from the subnet where Cloud Block Store resides. This section will also guide you through routing the appropriate subnet to your Azure Firewall. The assumption is that an Azure firewall already exists in your VNet. For steps on creating an Azure firewall, refer to Azure's firewall tutorial.

Configuring Azure Firewall

1. Log onto the Azure Portal and navigate to your Azure Firewall.
2. Click on Rules.

Note: The steps in this section refer to Firewall Rules (classic). The same concepts apply if you are using Firewall Policy for your firewall rules.

3. Select Application rule collection and click on + Add application rule collection.

Note: These set of Application rules will allow for the Cloud Block Store managed application to call home to Pure1, validate license, and initialize.

4. Complete the field as follows:
   1. Provide your desired name for this rule. Example: CBSoutboundrules
   2. Enter a priority for this rule.
   3. Set action to Allow.

5. Add Target FQDN rule to allow traffic to Pure1 with the following parameters:
   1. Name: <Provide your desired name> (Ex: CBS)
   2. Source type: IP Address
   3. Source: <CIDR range of the subnet for which you expect to deploy Cloud Block Store's system interface>
   4. Protocol: https, http
   5. Target FQDN: *.purestorage.com, purestorage.com, management.azure.com, *.microsoftonline.com

Click Add and wait for the firewall to successfully update. This may take a few minutes to complete.

7. When the Application Rules have updated, select Network rule collection and click on + Add network rule collection.

Note: These next set of rules will allow for Pure Support to perform Remote Assist functions on your Cloud Block Store managed application.

8. Complete the field as follows:
   1. Provide your desired name for this rule. Example: CBSRemoteAssist
   2. Enter a priority for this rule.
   3. Set action to Allow.

9. Add rule to allow traffic to IP addresses associated with Pure1 using the following parameters:
   1. Name: <Provide your desired name> (Ex: CBS Remote Assist)
   2. Protocol: TCP
   3. Source type: IP address
   4. Source: <CIDR range of the subnet for which you expect to deploy Cloud Block Store's system interface>
   5. Destination type: 
   6. Destination IP Addresses: *
   7. Destination Ports: 443

Note: If you have tighter security rules and need to specify the Destination IP Addresses, refer to the Azure Network Firewall rules in the Internet Access section above for the IP range.

Click Add and wait for the firewall to successfully update. This may take a few minutes to complete.

You have configured your Azure Firewall to allow Cloud Block Store traffic to call home and reach Pure1. The next step is to route the subnet for which you intend to deploy your Cloud Block Store managed application, to your Azure Firewall.

Create Route Table

1. Log onto the Azure Portal and navigate to Route tables.
2. Click Add.

Complete the fields for which you want to deploy your Cloud Block Store managed application.

4. Click Next:Tags.
5. Add Tags as needed.
6. Click Review + Create.
7. Click Create.
8. In your newly created Route Table, select Routes and click Add.

9. Fill in the parameters as below:
   1. Route name: <Provide your desired name>
   2. Address prefix: 0.0.0.0/0
   3. Next hop type: Virtual Appliance
   4. Next hop address: <Private IP address of your Azure Firewall> 

 10.  Click OK.

Route CBS Subnet to Azure Firewall

1. Log onto the Azure Portal and navigate to your VNet.
2. Click on Subnets.

3. Click the subnet for which you want deploy your Cloud Block Store managed application.

Note: If you plan on separating out the four interface types (iSCSI, Management, Replication, System) onto different subnets, then select the subnet you expect to use for the Cloud Block Store System interface.

In this example, we will be deploying all four of Cloud Block Store's network interfaces onto the single default subnet.

4. A window will open which will allow you to set subnet parameters.
   1. In the Route table field, select the route table you created in the previous steps.
   2. In the Services field, select
      1. Microsoft.AzureCosmosDB
      2. Microsoft.KeyVault

5. Click Save.

You have now completed the route configuration for your subnet to allow Cloud Block Store's internet-bound traffic to flow through your Azure Firewall.

Service Endpoints

Configure Network Security Groups 

To begin, open up the Network Security Group (NSG) in the Resource Group that CBS will be deployed in that has been created to control network traffic.  Select Outbound security rules under Settings.

Click on the + Add button at the top.

Below the next screenshot shows details for each of the fields that need to be filled in for the Outbound security rule.  Note that this process needs to be done a total of 3 times to create an outbound rule for each of the 3 Azure services required.

1. Source:  Set this to IP Addresses.
2. Source IP Addresses/CIDR Range:  Enter the subnet CIDR that you will use for the Cloud Block Store System interface.  Instructions on how to create this are shown earlier in this page.
3. Destination:  Select Service Tag from the drop down menu.
4. Destination Service Tag:  In this example we select the AzureCosmosDB tag.  Note that this tag, the AzureResourceManager and AzureKeyVault tags each need to be defined in a unique outbound security rule.
5. Service:  Pick https from the drop-down menu.
6. Action:  Ensure this is set to Allow.
7. Priority:  Pick a unique value.  Your existing NSG security rules will help dicate the priority selection made.
8. Name:  Provide a unique Outbound Rule name and optionally provide a description below.
9. Click on the Add button to create the rule.

The above process must be repeated 2 more times to create a total of 3 Outbound security rules.  For the 2 additional rules, step 4 needs to include the AzureResourceManager and AzureKeyVault tags while fields 7 and 8 need to be unique values.

After the 3 outbound security rules have been created, review them to make certain they are correct.

Next, we need to associate the system subnet with the network security group if it hasn't previously been added.

To do so, click on the Subnets button on the NSG.

Next, click on the Associate button.

Select the VNet you will deploy CBS into and then the system subnet.

Confirm that the subnet has been successfully associated.

Create User Managed Identity 

To create a new User Managed Identity, follow the below steps:

1. In Azure portal, search for Managed Identities, then click +Create. 
   
2. Select Subscription, Resource Group, Region, and Name. Ideally, select the same resource group where CBS Virtual Network is created. 
   
3. Optionally add Tags, then finalize with clicking Create. 
4. Once created navigate to the resource, then from the left-panel click on Properties.
5. Copy Resource Id, which will be required during deployment. 
   

Create a Custom Role 

Instructions on how to create a custom role in Azure can be found here. 

Step 4 of that article shows you how to specify permissions for your custom role. Please ensure that your custom role has the following permission: 

Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action

To minimize the permissions that the CBS Array has over external resources, we recommend you create a new role which has only that permission. Alternatively, you can use the Built-in role "Cosmos DB Operator", which has the required permission alongside other unneeded permissions.

Step 5 of that article describes assignable scope. Your assignable scope could be the subscription where your Virtual Network (VNet) for CBS will be deployed in. Ideally, you can limit the scope to the Resource Group for the VNet. The next section covers how to grant the Custom Role to the User Managed Identity created previously.

Grant Role Assignment 

This section is for granting permissions and roles to the CBS Array Managed Identity: 

CBS Custom Role over CBS Virtual Network

1. First, navigate to the VNet which will be used for deploying CBS. Then from the left-panel click on Access Control (IAM). 
   
2. Click + Add, then from the drop-down list choose Add role assignment. 
   
3. Under Role > Job Function roles, search for Custom Role created in the previous section. 
   
4. Under Members, Select Managed Identities, then search for the created Managed Identity in the previous section. 
   
5. Next tap is to review and assign.
6. You can verify the role assignment by navigating back to the managed identity resource and clicking on Azure Role Assignment.