Cloud Block Store on Azure Prerequisites

Supported Regions

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

Azure Active Directory Premium 2 License (Mandatory)

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 Azure Active Directory Premium 2 (AAD 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 Azure Active Directory pricing.

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

Enable Just-in-Time (Mandatory)

During the Cloud Block Store managed application deployment, users will see a setting called Enable JIT access for their Cloud Block Store managed application. The default value is set to Yes. It is mandatory that customers keep default setting as Yes which enables Just-in-Time (JIT). Without Just-in-Time, Pure Support will have full access into the customer's Cloud Block Store managed resource group. Enabling JIT allows the customer to approve and control any type of access into the managed resource group by Pure Support. This setting is irreversible once Cloud Block Store is deployed. 

For more details on Just-in-Time, see Appendix A.

Reserve Instances (Strongly Recommended)

A Cloud Block Store instance is composed of various underlying Azure resources including Azure VM instances. Azure provides customers the option to pay for the VM instances on an On-demand basis or through a pre-committed purchase of VM instances called Azure Reserved VM Instances (RIs). Paying for On-Demand VMs instances allows customers to only get charged for the VMs when it is powered on. It is more expensive on a per-hour basis when turned on compared to Reserve Instances. Reserved Instances are heavily discounted and are much more inexpensive per hour, but customers are committed to paying for them regardless if the VM instance is powered on or off.  More information can be found on the Azure Reserved Instance page.

Azure VM Instance vCPU Limits

By default, Azure places a default quota limit in every customer Azure subscription for every region. To view the existing limits, run the Get-AzVMUsage PowerShell cmdlet for your region. PowerShell can easily be accessed via the Azure Cloud Shell from the Azure portal.

Ensure that your count for Total Regional vCPUs and Standard DSv3 Family vCPUs have not reached their respective limits. Each Cloud Block Store instance you deploy will need to have a certain number of available vCPUs. See following table for exact vCPUs required for each CBS instance type.

Cloud Block Store Type	Total vCPUs Required
//V10MU-R1	64
//V20MU-R1	128

 

Example output of Get-AzVMUsage command where the current Standard DSv3 Limit = 128:

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
.

If you do not have enough vCPUs, you can request a quota increase. Details to do so are available here: https://docs.microsoft.com/en-us/azure/azure-portal/supportability/per-vm-quota-requests.

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:

Azure Rule/Action	Protocol:Port	Target FQDN
Allow	https:443	*.purestorage.com
Allow	https:443	purestorage.com
Allow	https:443	management.azure.com
Allow	https:443	*.microsoftonline.com
Allow	https:443	vault.azure.net
Allow*	https:443	*.blob.core.windows.net

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

Azure Firewall - Network rules:

Azure Rule/Action	Protocol	Destination IP Addresses	Destination Ports
Allow	TCP	52.40.255.224/27	443

 

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.

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.

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.

Service Type	Port
Management interfaces	443
Replication interfaces	8117 443 (if using CloudSnap)

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 Group	Inbound	Outbound
System		443
Replication	8117	8117 443 (if using CloudSnap)
iSCSI	3260
Mgmt	22, 80, 443, 8084	443

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