Skip to main content
Pure Technical Services

Cloud Block Store Deployment and Configuration Guide for Azure

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

Pure Storage's Cloud Block Store (CBS) is a software defined storage solution powered by the Purity Operating Environment (POE), which uses the native resources of Microsoft Azure to enhance storage services with enterprise features. This document provides detailed procedures to successfully deploy a new Cloud Block Store managed application in your Azure Virtual Network (VNet). 

A Cloud Block Store deployment video is available as a supplement to help users deploy Cloud Block Store from the ground up, including all the Azure prerequisites.

Video here: https://www.youtube.com/watch?v=IVtcVC3cxYw 

Cloud Block Store's high-level architecture consists of two Azure virtual machines acting as controllers and Azure managed disks for the NVRAM and persistent storage. The Cloud Block Store controllers process data and provide enterprise data services such as data reduction, snapshots, encryption, and replication. Two Ultra SSD disks will be deployed for NVRAM and fourteen Ultra SSD disks for persistent storage. A Cloud Block Store instances can be non-disruptively upgraded (NDU) with additional capacity by upgrading the Ultra SSD disk sizes. All Cloud Block Store NDU's are performed by Pure Storage Support in an automated fashion which removes any additional effort from the customer.  

Note: Below architecture reflects Cloud Block Store versions 6.1.4 or higher which no longer deploys a public load balancer.

clipboard_e35bbdab60d649864befbfbefba652845.png

 

    

Requirements

 

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.

clipboard_e43760f1c9e641614e9d76dcaefcdfb13.png

 

 

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 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. 

clipboard_e50a36fd2a597f5eacd8c711da5c0bfd9.png

 

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

 

 

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 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 of 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.

clipboard_e7feeb70009400d7f6356a826c1336121.png

 

  • 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.

clipboard_e7d7baddf245e4481f5aef5c71641b528.png

 

  • Managed Application Contributor role of the subnet 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. 

clipboard_e1f4456d3c47eced82148af823e75aadb.png

 

clipboard_ed5cebece608e406a86c1951ff60f1bf6.png

 

 

Networking Requirements

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. 
    • Cloud Block Store also supports different subnets. 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.

     Network configuration option diagram: 

clipboard_ef7e85907a9d405167c00b1681166b2d7.png

 

 

 

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 E for steps to create and configure an Azure NAT gateway.

clipboard_e26735e266a9bbd7067406f55c41b5e38.png

 

 

  • Option 2: Azure Firewall (or 3rd party firewall software) - Many customers may already have network security controls in place to monitor and control network traffic flowing into or leaving their Azure networks. One method is to use an Azure firewall. If an Azure Firewall exists, it should be configured to allow the appropriate ports to access the internet. See the table below for Azure Firewall configuration settings of both your Network and Application rules. You should also ensure your subnet routes appropriately to the Azure Firewall, specifically the intended subnet for the Cloud Block Store System interface. This should be completed before you deploy Cloud Block Store. 

See Appendix F for detailed steps on configuring the Azure Firewall specifically for your Cloud Block Store managed application.

 

clipboard_e0d902b5d087c9e5cedf80944310c5ec1.png

 

Azure 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

 

Azure Firewall - Network rules:

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

 

 

  • Option 3: On-Premises - Many customers prefer 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.

 

 

 


Service Endpoints (Mandatory)

A 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

  • CosmosDB
  • Azure Key Vault

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

clipboard_ece7735d98bed094a4ce545b6ad70320d.png

 

CloudSnap - For cost-conscious customers who are looking for a lower cost DR 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 B for steps to add Service Endpoint to a subnet.

 

 

Replication  Network

Replication - When replicating from a FlashArray on-premises to a Cloud Block Store instance in an Azure VNet, ensure 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

 

 

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 the limit. 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.

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 available here: https://docs.microsoft.com/en-us/azure/azure-portal/supportability/per-vm-quota-requests.

 

 

 

Before You Begin (Deployment Checklist)

Deployment may fail if all the requirements are not met. Before deploying Cloud Block Store, go through the following checklist:

  1. Does your tenant have an Azure Active Directory Premium 2 license? See Azure Active Directory Premium 2 License section for details.
  2. Ensure you have the proper IAM roles for your user account. See the Azure IAM Roles section for details.
  3. Ensure there is internet access from the subnet used for the System interface. See the Internet Access section for details.
  4. Is there a Service Endpoint for CosmoDB and KeyVault for the subnet used by the System interface. See Service Endpoint section for details.
  5. Ensure that your max vCPU limits can accommodate Cloud Block Store instances. See Azure VM instance vCPU limits section for details.
  6. Have you retrieved your Pure-As-A-Service license from Pure1? Steps to retrieve license are here. (Note: make sure you are logged into https://support.purestorage.com to view this page).
    1. Note: - If you have not purchased a license, there are two options to obtain a license key:
      1. Working with Pure Storage sales teams and Pure Storage partners to obtain a Pure as-a-Service subscription.
      2. Going directly to the Azure Marketplace to sign up for a subscription service.
  7. Have you added your Azure subscription ID to Pure1? This is security feature to ensure only user approved Azure subscriptions are allowed to deploy Cloud Block Store. Instructions to register and whitelist Azure subscriptions are provide here. (Note: make sure you are logged into https://support.purestorage.com to view this page) 
  8. If the above requirements have been met, proceed and deploy Cloud Block Store.

 

 

Deploying Cloud Block Store 

The following steps will provide guidance on deploying a Cloud Block Store managed application using the the Azure Portal GUI.

To deploy Cloud Block Store using the Azure CLI, see steps in the Cloud Block Store Deployment and Configuration Guide for Azure using Azure CLI document.

Note: The followings steps reflects deployment of Cloud Block Store versions 6.1.4 or higher which no longer deploys a public load balancer. Therefore it is mandatory that there is internet access for the Cloud Block Store system network interface in order to successfully deploy. See Internet Access section.

 

Deploy Cloud Block Store from the Azure Marketplace.

  1. Log into the Azure portal. Search and select “Marketplace”.

 

  1. In the Marketplace search bar, search for “cloud block store”.

 

  1. Click on the Pure Cloud Block Store (Product Deployment) tile.

clipboard_e604ce037c741c7f79b201cfdefc8df79.png
 

  1. Click Create.

clipboard_ea9fb38e8055f06c14ca15ddb41955580.png

  1. Complete the required fields. An example screenshot is provided for additional guidance below.

a. Select the desired Subscription.

b. Select the desired Resource group in which you want the Cloud Block Store managed application to reside. 

Note: Some zones may not have Ultra SSDs available, which is required for Cloud Block Store. To find out which zone in your specific Azure subscription has Ultra SSDs, run the following PowerShell command from the Azure CloudShell:

Get-AzComputeResourceSku | where {$_.ResourceType -eq “disks” -and $_.Name -eq “UltraSSD_LRS”}

f.  Enter desired Array Name for the Cloud Block Store VM instance.

g. Enter your Company Domain Name. This can be changed later. 

Example: purestorage.com

h. Enter the Cloud Block Store License key

g. (Optional) Enter comma separated email addresses of recipients who wish to receive Purity alerts.

h. (Optional) If you wish to log in via SSH with the default pureuser username, an SSH public key can be provided here.

Note: Alternatively, after deployment you can also log into the Cloud Block Store GUI (HTTPS) and manually add the SSH key to the desired user login. 

i. Enter the desired Application Name of your Cloud Block Store managed application. 

j. (Optional) You can change the name of the Managed Resource Group if desired. 

 

  1. Click Next: Network.
  2. Complete the Network fields. Cloud Block Store has four network interfaces (system, management, iSCSI, replication) and will need a Virtual Network (VNet) and subnet assigned. 

    Note: 
    • You must select the same VNet for all four interface. However, the interfaces can reside in the same or different subnet within the VNET. See Networking section for network option diagrams.
    • Ensure the subnet you select for the System interface has internet access. Example via NAT Gateway or Azure Firewall. See network Internet Access section for  options to configure internet access.

 

clipboard_eb7e4a441475e8e3333e63123b2b3937d.png

 

 

  1. Click Next: Tags.

  2. Add any desired tags for this deployment.

  3. Click Next: JIT Configuration.

  4. Ensure the you select Yes to enable Just in Time (JIT) remote access. (MANDATORY) 

​​​​​​        ​clipboard_eeec11f2419adfd573d614b862cb0b915.png

 

  1. Click on the Customized JIT configuration button. This option allows you to select users who can approve Just in Time (JIT) requests from Pure Support.

clipboard_ebbddc0dda3abe5dbc46fd4c4f492f0d8.png

  1. Select Manual mode
  2. Click Add Approver

clipboard_e4c8d21119e8ca9fd79bd2caed248024e.png

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

clipboard_efb3a16d5f282dddb4a953d86728fdbf2.png

  1. Click Save.

clipboard_e62680c85b59f4e04f8e21cc9e106b74b.png

 

See Appendix C for more details about JIT.

  1. Click Next: Review + create.

  2. Read and check the box to acknowledge the terms and conditions.

  1. Review your parameters and click Create.

  1. Cloud Block Store will now be deployed into your desired resource group, VNet, and subnets. The deployment should be completed in 20 minutes depending on the region.

Note: It may take a few minutes after deployment for the Cloud Block Store to initialize and be ready.

 

 

 

 

Managing Cloud Block Store

Viewing Cloud Block Store Deployment

  1. Once the deployment completes, you can view the Cloud Block Store managed app by navigating to your resource group. 

clipboard_e8d1b8b5319e3c85302a96a3fd41b409d.png

 

  1. You can also view the underlying resources of your Cloud Block Store managed app by going to the managed resource group, which was automatically created as part of the deployment. Click on the Cloud Block Store managed application icon.

  1. Click on the managed resource group.

 

You will notice the underlying resources include Azure VMs, Network interfaces, Managed disks, etc.

clipboard_e57dd20d2a09930d45e8c75407d7fdd4e.png

 


 

Viewing the Cloud Block Store IP Addresses in Azure Portal

You can view the IP addresses of the Cloud Block Store instance from multiple locations.

  1. In the your resource group where you deployed the Cloud Block Store managed app, click on the Cloud Block Store managed app icon.

  1. In your Cloud Block Store managed application, you can view various properties of the managed application. To view the Cloud Block Store managed application's IP addresses, click on Parameters and Outputs.
  2. Scroll down to the Output section. You will notice floating management, management, iSCSI, and replication IP addresses for your Cloud Block Store deployment.

Note: Notice there are two IP addresses for each interface type (management, iSCSI, replication), one from each controller. For management, you can connect to the floating IP address which is an internal Load Balancer which will always redirect you to the primary controller's management interface.

clipboard_eee5283eb7dbbb51f973aa160bfeaec27.png

You can also view the same corresponding IP address information by logging onto the Cloud Block Store instance's GUI using the management IP address.

In the GUI, you can click Settings and select the Network tab to view the IP addresses.

clipboard_ee711d0a7e3710ba756d31ae4a9e2218c.png

 

 

 Logging onto Cloud Block Store

Via GUI

  1. Log onto a Windows or Linux host (for example, a jump host) that has access to the management network of the Cloud Block Store instance. 

Make sure your subnet route tables, firewalls, and network security groups allow your host network access to the Cloud Block Store instance's management interface.

  1. Open a browser and enter the management load balancer IP using https://. See Viewing the Cloud Block Store IP Addresses in Azure Portal section for the location of your management or load balancer IP addresses. 

https://<CBS management load balancer IP address>

Note: You need to specify https:// for else the browser may not connect correctly. 

 

  1. Enter the username and password:
  • Default username: pureuser
  • Default password: pureuser
  1. The Cloud Block Store's Dashboard displays high-level storage usage and performance metrics. From the Dashboard, you can navigate to the various tabs on the left to view the detailed storage usage, performance analysis, health, and other settings.

clipboard_eb92d0b68f74920d0d072e51874403b43.png

 

 

Via CLI

As a security measure, using the default pureuser login to access Cloud Block Store via SSH requires an SSH public key. You could have entered the SSH public key during deployment (see Deploying Cloud Block Store section), or you can manually add by logging into the GUI. See Appendix A for steps to apply an SSH public key.

In order to SSH into your Cloud Block Store managed application, you must first use the GUI to create a new user.

  1. Log onto a Windows or Linux host that has access to the management network of the Cloud Block Store instance.
  2. Open a browser and enter the management IP address. See Viewing the Cloud Block Store IP Addresses in Azure Portal section for the location of your management IP addresses. 
  3. Enter the username and password.

Default username: pureuser

Default password: pureuser

  1. Navigate to the Setting section.
  2. Click on the Access tab.
  3. Click on the ellipsis icon (three dots) and select Create User.

clipboard_ebd9488a2d06ef310cf2ef0e5e473dfaf.png

  1. Enter the desired user login name and password.
  2. Once a user is created, you can SSH with this new login name.

 

 

Creating Volumes 

The following example provides steps for the GUI. For CLI users, SSH into the management port and run: purevol create --size <size> <vol name>

  1. Using the Cloud Block Store's GUI: 
    1. In the left navigation pane, click Storage.
    2. Click Volumes.
    3. Click the + icon to add a new volume.

CBS22.JPG

  1. Enter the name and desired size of the volume and click Create.
  2. You can see the new volume in the list of volumes.

CBS23.JPG

 

 

 

Creating Hosts

You must create a host with corresponding IQN before you can attach a volume to it.

The following example provides steps using the GUI. For CLI users, SSH into the management port and run:purehost create  --iqnlist <Host IQN number> <host name> 

Using the Cloud Block Store's GUI:

  1. On the left navigation pane, click Storage.
  2. Click Hosts.
  3. Click the + icon to add a new host.

CBS24.JPG

  1. Enter the desired name for the host and click Create.
  2. Once created, the host is displayed in the list of available hosts. Click on the new host.

CBS26.JPG

  1. In the Host Ports box:
    1. Click the ellipsis (three dots) icon.
    2. Select Configure IQNs.

CBS27.JPG

  1. Enter the IQN name of the iSCSI host. 

CBS28.JPG

Locate the host's IQN number by running the following commands on the respective OS. Ensure iSCSI service has started on the host.

Windows PowerShell (Run as Administrator):

(Get-InitiatorPort).NodeAddress

Linux:

cat /etc/iscsi/initiatorname.iscsi

Solaris:

iscsiadm list initiator-node

 

 

 

 

Connecting iSCSI Host to Cloud Block Store volumes

The following example provides steps for the GUI. For CLI users, SSH into the management port and run:purevol connect --host <host name> <vol name>

Using the Cloud Block Store's GUI: 

  1. On the left navigation pane, click Storage.
  2. Click Volumes.

cbs35.JPG

  1. Select the desired volume.

cbs36.JPG

  1. In the Connected Host box, click the ellipsis icon (three dots) and select Connect.

cbs38.JPG

  1. Select the desired host(s) and click Connect.

Ensure appropriate clustering software on your hosts is installed if you wish to connect the same volume to multiple hosts.

cbs39.JPG

 

 

 

 

Mounting a volume on iSCSI host

The following steps provide an example of how to connect a Windows and an Ubuntu Linux VM to a Cloud Block Store instance.

Prerequisites:
  • The host VM must have an iSCSI initiator client software. Most modern operating systems already have them pre-installed. 

  • The host VM must have network access to the iSCSI subnet of the Cloud Block Store instance. If the host VM's network interfaces and the Cloud Block Store instance's iSCSI interfaces are in different subnets, you must have route table entries allowing them to communicate. Ensure that Network Security Groups and firewalls are not preventing connectivity.

  • Ensure that you've followed the previous sections to create the host and create the volumes on Cloud Block Store. Also ensure you've made the volume connection to the host in Cloud Block Store as well.

 

 

 

 

Windows host

Setting up multipathing with Microsoft MPIO 

To protect against a single point of failure, this procedure allows multiple paths from the application host to the Cloud Block Store instance. You only need to perform this procedure once on your Windows application host. 

  1. Log onto the Windows host.
  2. To check if Microsoft MPIO is installed on the system, open an elevated PowerShell terminal (Run as administrator) and run:
PS C:\> Get-WindowsFeature -Name 'Multipath-IO'
Display Name                                            Name         Install State
------------                                            ----         -------------
[ ] Multipath I/O                                       Multipath-IO Available
  1. If it shows the install state as ‘Available’, follow the next steps to install Microsoft MPIO. If it shows as 'Installed', move on to step 7.

  2. In the same PowerShell terminal, run:

PS C:\> Add-WindowsFeature -Name 'Multipath-IO'
Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    Yes       SuccessRest...     {Multipath I/O}
WARNING: You must restart this server to finish the installation process.
  1. Reboot the Windows host.
  2. When the Windows host boots back up, verify that Microsoft MPIO is installed.

PS C:\> Get-WindowsFeature -Name 'Multipath-IO'
Display Name                                            Name         Install State
------------                                            ----         -------------
[X] Multipath I/O                                       Multipath-IO Installed
  1. In the same PowerShell terminal, run the following command to start the iSCSI service.

PS C:\> Start-Service -Name msiscsi
  1. Set the iSCSI service to start on boot, run:
PS C:\> Set-Service -Name msiscsi -StartupType Automatic
  1. Add Pure FlashArray as an MPIO vendor. In the same PowerShell terminal, run:

PS C:\> New-MSDSMSupportedHw -VendorId PURE -ProductId FlashArray
VendorId ProductId
--------       ---------
PURE        FlashArray
  1. Enable iSCSI support by Microsoft MPIO. In the same PowerShell terminal, run:

PS C:\> Enable-MSDSMAutomaticClaim -BusType iSCSI
VendorId ProductId
-------- ---------
MSFT2005 iSCSIBusType_0x9
False
  1. Set default MPIO path policy to Lowest Queue Depth.

PS C:\> Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy LQD
  1. Set MPIO Timer Values. In the same PowerShell terminal, run:

PS C:\> Set-MPIOSetting -NewPathRecoveryInterval 20 -CustomPathRecovery Enabled -NewPDORemovePeriod 120 -NewDiskTimeout 60 -NewPathVerificationState Enabled
  1. If prompted by the above commands, reboot the Windows host.

MPIO setup is now complete. 

 

Mounting a volume on Windows iSCSI host

Follow the next steps (1-7) to establish iSCSI connections. These steps only need to be performed once on each Windows host. Once you make a connection, subsequent volumes connected from Cloud Block Store to this host appear in Disk Management.

To complete the following steps, you need the IP addresses of both Cloud Block Store controller iSCSI interfaces. See Viewing the Cloud Block Store IP Addresses in Azure Portal section to obtain the iSCSI IP addresses. Keep the iSCSI IP addresses handy.

  1. (Run as administrator) On the Windows host, open an elevated PowerShell terminal and run the following command to gather the IP address of your Windows instance. The following example shows  10.0.1.118
PS C:\> ipconfig
Windows IP Configuration


Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : nkb53slgco0urbhag0lvo3pldf.xx.internal.cloudapp.net
   Link-local IPv6 Address . . . . . : fe80::ad14:4dc2:e367:6c7a%24
   IPv4 Address. . . . . . . . . . . : 10.0.1.118
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . : 10.0.0.1

  1. In the same PowerShell window, run the following command to create a new Target Portal connection between your Windows host and your Cloud Block Store instance.
PS C:\> New-IscsiTargetPortal -TargetPortalAddress <CBS iSCSI IP address>

        where

<CBS iSCSI IP address>  is the IP address of the iSCSI port on Cloud Block controller 0 or controller 1. You only need to enter one.

 

 

  1. In the same PowerShell window, run the following command to create an iSCSI session to Cloud Block Store controller 0.
PS C:\> Get-IscsiTarget | Connect-IscsiTarget -InitiatorPortalAddress <Windows IP address> -IsMultipathEnabled $true -IsPersistent $true -TargetPortalAddress <CBS iSCSI interface IP address CT0>

where

<Windows IP address> is the Windows host IP address obtained in step one.

<CBS iSCSI IP address CT0> is the iSCSI IP address of Cloud Block Store controller 0.

See the following screenshot as an example. 

clipboard_ee3937fdd6d0a13d5367f60aade7bf974.png 

  1. (Optional) For additional performance throughput, you may add additional iSCSI sessions. Repeat the same command for each additional iSCSI session you would like to add to controller 0. You can add up to 32 iSCSI sessions to each controller.

See Appendix D for more information about performance considerations for Cloud Block Store.

  1. In the same PowerShell window, run the same command to create iSCSI sessions to Cloud Block Store controller 1.
PS C:\> Get-IscsiTarget | Connect-IscsiTarget -InitiatorPortalAddress <Windows IP address> -IsMultipathEnabled $true -IsPersistent $true -TargetPortalAddress <CBS iSCSI interface IP address CT1>

where

<Windows IP address> is the Windows host IP address obtained in step two.

<CBS iSCSI IP address CT1> is the iSCSI IP address of Cloud Block Store controller 1

  1. (Optional) For additional performance throughput, you may add additional iSCSI sessions. Repeat the same command for each additional iSCSI session you would like to add to controller 1. You can add up to 32 iSCSI sessions to each controller.

See Appendix D for more information about performance considerations for Cloud Block Store.

  1. To confirm the total number of sessions, run:  
PS C:\> Get-IscsiSession | measure

Example:

clipboard_e5658addc9bde44c5a213ed6d74df8cac.png 

  1. Go to Disk Management and perform a rescan to confirm the new volume is present. 

cbs79.JPG

  1. Bring the volume online and format with the desired file system. Any subsequent volume you create and connect to this host in the Cloud Block Store UI (CLI/GUI/REST) displays automatically in Disk Management after a rescan.

You have successfully connected and mounted a Cloud Block Store volume to your host. 

 

 

Linux Host   

This example walks you through connecting Cloud Block Store volumes to an Ubuntu 18.04 Linux host. Some steps might be repeated from steps seen earlier in this guide.

The steps include:

  • Configuring the Linux host for iSCSI and MPIO with Cloud Block Store
  • Host and volume creation on Cloud Block Store
  • Connecting and mounting Cloud Block Store volumes to Linux host
Configuring iSCSI on Linux host initiator with Cloud Block Store
On Linux Host
  1. SSH into Linux Ubuntu VM instance for which you wish to provision Cloud Block Store storage.

  2. Install iscsi initiator utils as root:

  1. Install lsscs

  1. Install multi-path tools.

  1. Start iscsi services

  1. Start iSCSI daemon service:

    sudo /etc/init.d/open-iscsi restart

  1. Run command below.

    sudo sed -i 's/^\(node\.session\.nr_sessions\s*=\s*\).*$/\132/' /etc/iscsi/iscsid.conf

    Note: This step is optional and increases the total bandwidth performance by allowing the application host to create 32 iSCSI sessions per iSCSI connection. This command edits the /etc/iscsi/iscsid.conf file and change the node.session.nr_sessions field to 32. See Appendix D for detailed information about iscsi sessions.

  2. Edit the /etc/iscsi/iscsid.conf file to enable automatic iSCSI login by changing the following parameter: 

    node.startup = automatic

Example:

 

  1. Create (or edit) /etc/multipath.conf file with the following contents:

 

  1. Restart multipathd service to get the multipath.conf changes to take effect.

    sudo service multipathd restart
  2. Retrieve the Initiator IQN on Ubuntu VM:

    sudo cat /etc/iscsi/initiatorname.iscsi

Example:

user@MyUbuntuVM:~$ sudo cat /etc/iscsi/initiatorname.iscsi
## DO NOT EDIT OR REMOVE THIS FILE!
## If you remove this file, the iSCSI daemon will not start.
## If you change the InitiatorName, existing access control lists
## may reject this initiator.  The InitiatorName must be unique
## for each iSCSI initiator.  Do NOT duplicate iSCSI InitiatorNames.
InitiatorName=iqn.1993-08.org.debian:01:756ae638fabb

 

On Cloud Block Store Instance

  1. Log onto the Pure Storage Cloud Block Store instance via SSH using the Cloud Block Store Management IP address. 

  2. Create a hostname on the Cloud Block Store instance and associate it with the Linux Ubuntu initiator IQN in previous step:

     purehost create --iqnlist <IQN number> <hostname>

     where

   <IQN number> is the initiator IQN number gathered in step 11.

     <hostname> is the desired hostname for your existing Ubuntu VM in Azure.

Example:

pureuser@MyCBS> purehost create --iqnlist iqn.1994-05.com.redhat:361dfc3de387 MyUbuntuVM
Name       WWN  IQN                                  NQN  Host Group
MyUbuntuVM  -    iqn.1994-05.com.redhat:361dfc3de387  -    -
  1. Create volume on Pure.

     purevol create <vol name> --size <volume size>

    where

    <vol name> is the desired name of the Cloud Block Store volume.

    <volume size> is the volume size (ex: 50M, 50G, 10T).

This example shows the creation of a 2 TB volume:

pureuser@MyCBS> purevol create vol1 --size 2TB
Name  Size  Source  Created                  Serial
vol1  2T    -       2019-09-09 11:41:55 PDT  2B60622E2B014A2200011010 
  1. Connect volume to the Ubuntu host VM

     purevol connect <vol name> --host <hostname>

     where

     <vol name> is the name of the Cloud Block Store volume.

    <hostname> is the name of your Ubuntu VM.

Example: 

pureuser@MyCBS> purevol connect vol1 --host MyUbuntuVM
Name  Host Group  Host       LUN
vol1  -           MyUbuntuVM  1

    To check the connection between your volumes and hosts, run:

     purevol list --connect

  1. Collect the IP addresses of each controller and the IQN number for Cloud Block Store. The IQN is identical for both iSCSI interfaces.

     pureport list

Example

pureuser@MyCBS> pureport list
Name      WWN  Portal              IQN                                                     NQN  Failover
CT0.ETH2  -    172.16.180.8:3260   iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8  -    -
CT1.ETH2  -    172.16.180.11:3260  iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8  -    -
vphan@CBSwestus2van>
iSCSI login 

On Linux host: 

  1. Create a new iSCSI interface on the Linux host initiator. 

sudo iscsiadm -m iface -I iscsi0 -o new

Example:

user@MyUbuntuVM:~$ sudo iscsiadm -m iface -I iscsi0 -o new
New interface iscsi0 added
  1. Discover target iSCSI portals using iSCSI interface IP.

sudo iscsiadm -m discovery -t st -p <CBS iSCSI IP>:3260

where

<CBS iSCSI IP>  is the iSCSI IP address of the Cloud Block controller 1 or controller 2, collected in step 16. You only need to enter one iSCSI IP address.

Example: It will discover iSCSI IP's from both CBS controllers.

user@MyUbuntuVM:~$ sudo iscsiadm -m discovery -t st -p 172.16.180.8:3260
172.16.180.8:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8
172.16.180.11:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8
  1.  Connect the Linux host to the Cloud Block Store instance.

sudo iscsiadm -m node --login

Example: You will notice there will be 64 logins (32 iSCSi session login per CBS controller)

user@MyUbuntuVM:~$ sudo iscsiadm -m node --login
Logging in to [iface: iscsi0, target: iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8, portal: 172.16.180.8:3260] (multiple)
Logging in to [iface: iscsi0, target: iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8, portal: 172.16.180.8:3260] (multiple)
.
.
.
Logging in to [iface: iscsi0, target: iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8, portal: 172.16.180.11:3260] (multiple)
Logging in to [iface: iscsi0, target: iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8, portal: 172.16.180.11:3260] (multiple)
Login to [iface: iscsi0, target: iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8, portal: 172.16.180.8:3260] successful.
Login to [iface: iscsi0, target: iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8, portal: 172.16.180.8:3260] successful.
.
.
.
Login to [iface: iscsi0, target: iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8, portal: 172.16.180.11:3260] successful.
Login to [iface: iscsi0, target: iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8, portal: 172.16.180.11:3260] successful.

  1. Confirm the number of iSCSI sessions. There should be 64 entries (32 iSCSi sessions per CBS controller)

iscsiadm --mode session

Example: There should be 64 entries (32 iSCSI sessions per CBS controller)

user@MyUbuntuVM:~$ iscsiadm --mode session
tcp: [1] 172.16.180.8:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8 (non-flash)
tcp: [10] 172.16.180.8:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8 (non-flash)
tcp: [11] 172.16.180.8:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8 (non-flash)
tcp: [12] 172.16.180.8:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8 (non-flash)
tcp: [13] 172.16.180.8:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8 (non-flash)
.
.
.
tcp: [63] 172.16.180.11:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8a (non-flash)
tcp: [64] 172.16.180.11:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8 (non-flash)
tcp: [7] 172.16.180.11:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8 (non-flash)
tcp: [8] 172.16.180.11:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8 (non-flash)
tcp: [9] 172.16.180.11:3260,1 iqn.2010-06.com.purestorage:flasharray.81ce503fd81d0c8 (non-flash) 
  1. Confirm that each volume has 64 entries, each representing a virtual device path.

lsscsi -d

Example: There should be 64 entries per CBS volume connected to this Linux host.

user@MyUbuntuVM:~$ lsscsi -d
[0:0:0:0]    disk    Msft     Virtual Disk     1.0   /dev/sda [8:0]
[1:0:1:0]    disk    Msft     Virtual Disk     1.0   /dev/sdb [8:16]
[5:0:0:0]    cd/dvd  Msft     Virtual CD/ROM   1.0   /dev/sr0 [11:0]
[6:0:0:1]    disk    PURE     FlashArray       8888  /dev/sdc [8:32]
[7:0:0:1]    disk    PURE     FlashArray       8888  /dev/sdb [8:16]
[8:0:0:1]    disk    PURE     FlashArray       8888  /dev/sda [8:0]
.
.
.
[67:0:0:1]   disk    PURE     FlashArray       8888  /dev/sdar[66:176]
[68:0:0:1]   disk    PURE     FlashArray       8888  /dev/sdbe[67:128]
[69:0:0:1]   disk    PURE     FlashArray       8888  /dev/sdbj[67:208]
  1. Run the multipath command below to confirm each Cloud Block Store volume has multiple paths. A multipathed Cloud Block Store volume should be represented by a device-mapped ID, as seen in green in the example below. Verify the paths are divided into two priority groups, as seen in orange in the following example. 

sudo multipath -ll

Example: Each Cloud Block Store volumes are represented by a device-mapped IDs in green. 

user@MyUbuntuVM:~$ sudo multipath -ll
3624a93702b60622e2b014a2200011011 dm-0 PURE    ,FlashArray
size=2.0T features='0' hwhandler='1 alua' wp=rw
|-+- policy='queue-length 0' prio=50 status=active
| |- 2:0:0:2 sdb  8:16  active ready running
| |- 3:0:0:2 sdf  8:80  active ready running
| |- 4:0:0:2 sdl  8:176 active ready running
| `- 5:0:0:2 sdk  8:160 active ready running
.
.
.
.
`-+- policy='queue-length 0' prio=10 status=enabled
  |- 6:0:0:2 sdd  8:48  active ready running
  |- 7:0:0:2 sdh  8:112 active ready running
  |- 8:0:0:2 sdp  8:240 active ready running
  `- 9:0:0:2 sdo  8:224 active ready running
.
.
.

26. Create mount points on the initiator.

sudo mkdir /mnt/store0

27. Create the desired file system on each Cloud Block Store volume using the device-mapped IDs, and then mount each volume to the mount point.

sudo mkfs.ext4 /dev/mapper/<device-mapped ID>

where

<device-mapped ID> is the device-mapped ID from step 25 in green.

The following example uses filesystem ext4 for the Cloud Block Store volume

dm-0

user@MyUbuntuVM:~$ sudo mkfs.ext4 /dev/mapper/3624a93702b60622e2b014a2200011011
mke2fs 1.42.9 (28-Dec-2013)
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=1024 blocks
134217728 inodes, 536870912 blocks
26843545 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2684354560
16384 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000, 214990848, 512000000

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

28. Mount Cloud Block Store volume onto mount point.

sudo mount /dev/mapper/<device-mapped ID> <mount point>

where

<device-mapped ID> is the device-mapped ID collected from step 25.

<mount point> is the mount point created in step 26.

user@MyUbuntuVM:~$ sudo mount /dev/mapper/3624a93702b60622e2b014a2200011011 /mnt/store0

29. The mount points now report 2TB, and block storage can be consumed.

user@MyUbuntuVM:~$ df -h
Filesystem                                     Size  Used Avail Use% Mounted on
/dev/mapper/3624a93702b60622e2b014a2200011010  2.0T   81M  1.9T   1% /mnt/store0

On Cloud Block Store

  • (Optional Check) I/O should only flow to the primary controller instance. Run I/O on your Linux host and confirm on your Cloud Block Store instance with the following command:

purehost monitor --balance --interval 3

Example:

pureuser@CBS> purehost monitor --balance --interval 3
Name       Time                     Initiator WWN  Initiator IQN                        Initiator NQN  Target       Target WWN  Failover  I/O Count  I/O Relative to Max
MyUbuntuVM  2019-08-26 10:31:32 PDT  -             iqn.1994-05.com.redhat:b9ddc64322ef  -              (primary)    -           -         1626       100%
                                                   iqn.1994-05.com.redhat:b9ddc64322ef                 (secondary)              -         0          0%
                                                  

 

 

 

Adding More Volumes

You can add more volume using CLI or GUI. 

  1. To create subsequent Cloud Block Store volumes, you can use the purevol create CLI command to create the the volume.

purevol create <vol name> --size <volume size>

  1. Use the purevol connect command to connect the volume to the desired host.

purevol connect <vol name> --host <hostname>

  1. Rescan the host to see the additional storage.
  • On Windows, go to Disk Management and perform a rescan to confirm the new volume is present. 
  • On Linux use the sudo iscsiadm -m session --rescan command.

Example:

user@MyUbuntuVM:~$ sudo iscsiadm -m session --rescan
Rescanning session [sid: 2, target: iqn.2010-06.com.purestorage:flasharray.666667d86130ec06, portal: 172.16.180.8:3260]
Rescanning session [sid: 3, target: iqn.2010-06.com.purestorage:flasharray.666667d86130ec06, portal: 172.16.180.8:3260]
Rescanning session [sid: 4, target: iqn.2010-06.com.purestorage:flasharray.666667d86130ec06, portal: 172.16.180.8:3260]
Rescanning session [sid: 1, target: iqn.2010-06.com.purestorage:flasharray.666667d86130ec06, portal: 172.16.180.8:3260]
Rescanning session [sid: 5, target: iqn.2010-06.com.purestorage:flasharray.666667d86130ec06, portal: 172.16.180.8:3260]
Rescanning session [sid: 6, target: iqn.2010-06.com.purestorage:flasharray.666667d86130ec06, portal: 172.16.180.8:3260]
Rescanning session [sid: 8, target: iqn.2010-06.com.purestorage:flasharray.666667d86130ec06, portal: 172.16.180.8:3260]
Rescanning session [sid: 7, target: iqn.2010-06.com.purestorage:flasharray.666667d86130ec06, portal: 172.16.180.8:3260]

 

 

Removing Cloud Block Store 

To properly terminate and remove a Cloud Block Store instance, run the two CLI commands provided below. The proper steps will ensure that the Cloud Block Store instance removal is reflected accurately and accounted for in the Pure-as-a-Service subscription on Pure1.

Prerequisites:

  • All Cloud Block Store volumes and snapshots must be deleted and eradicated prior to termination of a Cloud Block Store instance. This includes Protection Group snapshots.
  • All connected arrays and targets must be disconnected from any type of Purity replication.
  • Cloud Block Store instance must able to phone home. This ensures the Cloud Block Store instance is properly de-registered in the Pure-as-a-Service subscription.

Once the prerequisite array state has been achieved, the following steps will terminate and remove the Cloud Block Store instance.

  1. Using SSH, log into the Cloud Block Store instance management port. 

Note: See the Viewing the Cloud Block Store IP Addresses in Azure Portal section for the management port IP address.

  1. Run the following command:

purearray factory-reset-token create

Example

purearray factory-reset-token create
Name               Token
MyCloudBlockStore  4109498 
  1. A token will be provided in the output. Make a note of the token value.
  2. Run the following command with the token from the previous command.

purearray erase --factory-reset-token <token> --eradicate-all-data

This allows the Cloud Block Store instance to communicate with Pure1 prior to deleting itself.

Example

purearray erase --factory-reset-token 4109498 --eradicate-all-data
Name
MyCloudBlockStore

 

  1. Important: Wait about 5 minutes and proceed delete the Cloud Block Store managed application.

Note: Cloud Block Store manage application deletion takes about 10-15 minutes to completely remove all the underlying resources. 

clipboard_e1b5e14e20f9306b81e5ce18ccc56ec78.png

Customer Support

Customers can contact Pure Storage Support for any issue or questions relating to Cloud Block Store.

Pure Storage Support also performs all non-disruptive upgrades (NDU) for Cloud Block Store instances, Purity code upgrades, as well as capacity upgrades. 

 

 

 

 


 

 

 

Appendix A

Adding SSH Public key

  1. To add an SSH public key to pureuser or other user accounts, log on to the CBS GUI and navigate to the Setting section.
    1. Click on the Access tab.
    2. Click on the ellipsis (three dots) icon and select Edit User.

clipboard_ed538361e3beb6ac00fa54df98f800345.png

  1. Complete the fields for new password. Select Overwrite. Paste the contents of your SSH public key.

clipboard_e0efa5bd3f14ce2ecda26b87b79f722b5.png

  1. Click Save.

 

 

Appendix B

Service Endpoints

CosmosDB and Key Vault

Communication between Cloud Block Store and Azure CosmoDB will occur over the Cloud Block Store system interface. Therefore, the service endpoint should be configured on the correlating subnet used the system interface.

  1. Log into the Azure Portal.
  2. Navigate to the subnet upon which the Cloud Block Store system interface resides

Note: You can locate the subnet used by the Cloud Block system interface by viewing the Parameters and Output tab on your Cloud Block Store managed application.

clipboard_ee1d0a07fa28b257411c5ba03ad0d3238.png

  1. Set the appropriate CosmosDB and Key Vault service endpoints.
    1. Click on Subnets
    2. Click on the subnet used by the Cloud Block Store system interface
    3. An Azure menu will appear on the right hand side. Select Microsoft.AzureCosmosDB and Microsoft.KeyVault service

clipboard_e8b24dc59669047916028994fb27402b7.png

  1. Click OK.

 

Endpoint Azure Blob Storage for CloudSnap

To enable Service Endpoints for Cloudsnap and Azure Blob Storage, navigate to the subnet where the CBS replication interface resides, and set the service endpoint called Microsoft.Storage

clipboard_e0c2ee42bb6ac6dbe5be88bed59004679.png

 

 

 

 

Appendix C

JIT Configuration

What is a Managed Resource Group?

Before we describe JIT, let's describe a managed resource group. A managed resource group is just like any other Azure resource group within a customers' Azure subscription, except it is managed by Pure Storage. It contains only Cloud Block Store resources (VMs, managed disks, network interfaces, Network security groups, etc). Since it is managed by Pure Storage, Pure Support personnel does have access into the Cloud Block Store manage resource group. However, with JIT, customers are given control on when and whether Pure can access the managed resource group.  

What is JIT?

Just-in-Time (JIT) is an Azure feature that allows customers to control and approve Pure Support personnel to remotely access the Cloud Block Store managed resource group. For example, if a non-disruptive capacity upgrade is requested, Pure Support would need access into the Cloud Block Store managed resource group to perform the capacity upgrade. Pure will not have access to any other customer resources outside of the managed resource group.

Cloud Block Store requires Just-in-Time (JIT) to be enabled when it is deployed. It is a requirement and will not be supported if JIT was disabled. Furthermore, once JIT is disabled at deployment, it is irreversible.

With JIT enabled, customers have two options : Manual or Automatic.

  • Manual mode - This option allows customer to selectively approve when a request is made by Pure Support to access the Azure resources residing in the Cloud Block Store managed resource group. Customers can also pre-select who in their organization can approve JIT request from Pure Support. Once approved, Pure Support will only have access to the managed resource group where the Cloud Block Store resources reside. Pure Storage strongly recommends customers choose Manual mode.
  • Automatic mode - This option will automatically approve any JIT requests made by Pure without requiring any manual approvals by the customer. For security conscious customers, Pure recommends not using Automatic mode. 

The Manual or Automatic mode options can be configured during deployment or anytime after deployment completes. 

How do I set to manual approval mode after the Cloud Block Store managed application has been deployed?

  1. Navigate to the Cloud Block Store managed application in the Azure portal. Click on JIT Configuration.

clipboard_e7346fa7bd4face068cc45a8355ddffbf.png

  1. Select Manual mode
  2. Click Add Approver

clipboard_e65fe4ca5eded4ce7861fda045db7efb1.png

 

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

clipboard_e30d90a74b3f13fa1045b35f77d3ebf72.png

  1. Click Save.

clipboard_ee6b23a9f100b573738802d4517df384a.png

How is JIT Approved?

Once Pure Support requests JIT access, customers can approve by going to the Cloud Block Store managed application window and select the JIT Access tab.

From this window, customers can approve request and also select how long Pure has access into the managed resource group.

clipboard_eb95cea92a9b16d0a3b1fca7870a68e2a.png

 

 

 

Appendix D

Performance Considerations

  • iSCSI Sessions:

It is important to note that Azure has bandwidth limits on each TCP connection. Since a single iSCSI session equates to a single TCP connection, each iSCSI session is also limited on throughput.  For applications that need higher throughput, it is advised to increase the number of iSCSI sessions on the Azure VM host. Pure recommends 2 to 32 iSCSI sessions per iSCSI connection. The Windows and Linux examples above already includes steps to set these values.                                    

clipboard_eb968100250fcaa2b7634dd7634b953d9.png

  • MPIO Settings

I/O should only flow to the primary controller. Ensure you followed the steps to appropriately set MPIO parameters for Windows and Linux hosts to ensure IO's are sent to the primary controller.

To confirm, run I/O on your host and run the following command on your Cloud Block Store instance:

purehost monitor --balance --interval 3

Example: Notice I/O Count should only show for the primary controller.

pureuser@CBS> purehost monitor --balance --interval 3
Name       Time                     Initiator WWN  Initiator IQN                        Initiator NQN  Target       Target WWN  Failover  I/O Count  I/O Relative to Max
MyUbuntuVM  2019-08-26 10:31:32 PDT  -             iqn.1994-05.com.redhat:b9ddc64322ef  -              (primary)    -           -         1626       100%
                                                   iqn.1994-05.com.redhat:b9ddc64322ef                 (secondary)              -         0          0%
                                                  
  • Application VM Network Bandwidth Limits

Keep in mind that each Azure VM instance type has a network bandwidth limits. See Azure VM sizes for details on network bandwidth of the various VM types. When running performance load testing with a Cloud Block Store instance, ensure the VM that the application is running on has enough network bandwidth. For example, a Cloud Block Store V20MU-R1 instance uses D64s_v3 types for the controllers which has up to 30 Gb/s of bandwidth. Therefore the application host should use a single VM type with matching network limits (ex: 1 x D64s_v3), or multiple smaller VMs with networks that add up to the 30 Gb/s limit. This ensures that the application is not the bottle neck.

 

 

 

 

Appendix E

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.

clipboard_eae3ce78270acb5de95ab99ae7de6b854.png

  1. Click Create.

clipboard_eec31f384915a5cd69f4993d2b4287439.png

  1. Complete the desired parameters for your NAT gateway.

clipboard_e7ef2edc36155ad0c1664c677f49a7141.png

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

clipboard_ede3ecfd1d6913ee91cf305e52b7ce219.png

  1. Click Next: Subnet.
  2. 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.  

clipboard_ef4d87d4a4a22955eb63c6d9e9b839241.png

  1. Click Next: Tags.
  2. Apply desired tags as needed.
  3. Click Next: Review + Create.
  4. Click Create. 

clipboard_e244c953be8f029e190d7034a72da64dc.png

 

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

 

 

Appendix F

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.

clipboard_ec5d6cc7c42abcae9d4b34d834284b2c8.png

 

  1. 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.

clipboard_e385e00ebee4a430514071b16ab54a758.png

 

  1. 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.

clipboard_e10813fecb41b129fed82443e973e254b.png

 

  1. 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

clipboard_e296ba7a7665f54c06ceb4db777654bed.png

 

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

clipboard_e2a08ee95ccaa225f0cf8cd826ac14fcd.png

  1. 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.

clipboard_ea1b0005f145f6d0c0957579859eb73d1.png

 

  1. 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.

clipboard_e9adf1f56741fb932115d380f030af5a1.png

  1. 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.

clipboard_e162f690e787f04191973a14ac64af3b6.png

 

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

clipboard_e2a08ee95ccaa225f0cf8cd826ac14fcd.png

 

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.

clipboard_ece8112490d2b2459705e5a41a0a748ba.png

 

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

clipboard_e4890180a42d984cd1d1ad98e8de08d43.png

 

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

clipboard_e4fd7e245cca8fa30f39b0f705c97737e.png

  1. 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> 

clipboard_e6def9d4f7ecd1976c75fa011ce25dad1.png

 

  1. Click OK.

 

Route CBS Subnet to Azure Firewall

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

clipboard_e96015469f4d3bd541a873f4c01249878.png

 

  1. 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.

clipboard_ebe279160a046d2e48247813ecad37bdc.png

 

  1. 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

clipboard_e6dab3a3a68ae051d74d4407d2ebe20b7.png

  1. 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.