This deployment guide provides instructions for deploying PowerScale for Microsoft Azure with the Terraform module. It also guides post-deployment, including expanding a cluster and destroying a cluster. After you have deployed a cluster, see the PowerScale for Microsoft Azure Getting Started Guide on the Dell Technologies Support website for more details about OneFS.

Dell Technologies and the authors of this document welcome your feedback on this document. Contact the Dell Technologies team by email.

Author: Vincent Shen, Lieven Lin

Note: For links to other documentation for this topic, see the PowerScale Info Hub.

Azure and storage administrators can use this guide to automatically deploy the Azure infrastructure resources for deploying and configuring PowerScale for Microsoft Azure. To use this guide effectively, administrators should be familiar with the Azure cloud services, including virtual machine (VM), storage, and virtual networks/subnets. After you have deployed a cluster, see the PowerScale for Microsoft Azure Getting Started Guide on the Dell Technologies Support website for more details about OneFS.

The following conventions are adopted in this guide to represent the first and subsequent occurrences of frequently used terminology in a section:

Table 1.      Terminology

PowerScale for Microsoft Azure is a software-defined cloud file storage service that combines the power of the OneFS distributed file system with the flexibility and scalability of cloud infrastructure. It is a fully customer-managed service that is designed to meet the needs of enterprise-scale file workloads running on Azure. The architecture of PowerScale for Microsoft Azure is built on the OneFS distributed file system. This architecture uses multiple nodes to establish a single global namespace. Each node operates as an instance of the OneFS software, running on an Azure VM to deliver storage capacity and compute resources.

PowerScale for Microsoft Azure uses cloud-native technologies and leverages the elasticity of cloud infrastructure, so that you can easily scale the storage infrastructure as your business requirements grow. It can dynamically scale storage capacity and performance to meet changing demands by adding additional nodes without disruption, enabling the storage infrastructure to scale in a more cost-effective and efficient manner. To guarantee the durability and resiliency of data, PowerScale for Microsoft Azure distributes data across multiple nodes within the cluster. It also uses advanced data protection techniques, such as erasure coding, and provides features such as SyncIQ to ensure that data is replicated between sites. Even in the event of one or more node failures, the data remains accessible from the remaining cluster nodes.

Note: Refer to the PowerScale OneFS Administration Guide for the list of unsupported features.

Figure 1 shows the technical architecture of PowerScale for Microsoft Azure.

• Availability set and proximity placement group: PowerScale for Microsoft Azure is designed to run in an availability set, and the availability set is associated with a dedicated proximity placement group. In this way, PowerScale for Microsoft Azure can have better reliability, especially beneficial for backend network communication by improving the node-to-node latency.
• Virtual network: PowerScale for Microsoft Azure requires an Azure virtual network to provide network connectivity.
• Internal subnet: The nodes communicate with each other through the internal subnet. The internal subnet must be isolated from VMs that are not in the cluster. Therefore, a dedicated subnet is required for the internal network interfaces of nodes that do not share internal subnets with other Azure VMs.
• External subnet: The nodes communicate with clients through the external subnet by using different protocols, such as NFS, SMB, S3, and so on.

Note: The network bandwidth limit at the Azure VM level is shared between the cluster's internal network and the external network.

• Internal network interfaces: Azure network interface cards associated with the internal subnet.
• External network interfaces: Azure network interface cards associated with the external subnet.
• Network security group: The network security group applies to the cluster network interfaces, which allow/deny specific traffic to PowerScale for Microsoft Azure.
• Azure VMs: These VMs serve as nodes running the OneFS file system, backed by Azure managed disks. Each node within the cluster is strategically placed in an availability set and a proximity placement group. This configuration ensures that all nodes reside in separate fault domains, which enhances reliability and brings them physically closer together. See the Azure availability sets overview and Azure proximity placement groups documentation for more details.

Figure 1.   PowerScale for Microsoft Azure architecture

Overall, PowerScale for Microsoft Azure offers a powerful and flexible scale-out file storage solution that can help you improve data management, optimize costs, and achieve scalability and security in a cloud-based environment.

Terraform is an open-source infrastructure as code (IaC) tool developed by HashiCorp. It allows users to define and provision infrastructure in a declarative configuration language. Terraform uses providers to interact with different infrastructure platforms, such as AWS, Azure, and Google Cloud. Each provider is responsible for translating the Terraform configuration into API calls for a specific platform.

Dell Technologies released an open-source Terraform module for the auto-deployment of Azure resources for PowerScale for Microsoft Azure. It is released and licensed under the MPL-2.0 license. Get the latest version from Terraform OneFS module for Azure.

The Terraform module provides the following features to help you manage PowerScale for Microsoft Azure:

• Provision necessary Azure resources for a single OneFS cluster, including virtual machines, storage disks, placement groups, network interface cards, and so on.
• Automatically form a cluster with all the Azure resources
• Expand PowerScale on Azure by provisioning additional Azure resources, including virtual machines, storage disks, and network interface cards.
• Destroy an instance of PowerScale on Azure.

See the section PowerScale for Microsoft Azure architecture for details about the architecture. PowerScale for Microsoft Azure deployment consists of four high-level steps:

• Plan your deployment: PowerScale for Microsoft Azure has some specific support configurations, including cluster size, cluster capacity, Azure virtual machine instance type, and Azure disk type. You must know about the supported configuration before you start to deploy the cluster. For details, see the section Supported cluster configuration.
• Prerequisites checklist: You must fulfill all the prerequisites before following this guide to deploy a cluster. For details, see the section Prerequisites.
• Deploy Azure resources: After you have planned your deployment and fulfilled the prerequisites, you can use the Terraform module to deploy Azure resources. For details, see the section Deploy.
• Set up the cluster: To add additional nodes to the cluster, connect to the first node of the cluster. For details, see the section Error! Reference source not found..

Supported cluster configuration

When setting up a new cluster, it is important to consider the type of storage configuration that is supported. Different configurations fulfill different requirements, depending on the intended use and the amount of data that needs to be stored. In general, a supported cluster configuration should be reliable, performant, and offer enough storage capacity to meet your needs.

For a single cluster of PowerScale for Microsoft Azure, all nodes in the cluster must use the same configuration, including Azure VM size, Azure managed disk type, and Azure managed disk size.

Table 2 shows the supported configuration for a OneFS cluster in Azure.

Table 2.      Supported configuration for a single cluster

Note: all criteria in this table must be met. Therefore, when using 16 TiB disk size, not all combinations of cluster size, disk count, and disk size are supported. For some combinations of cluster size, disk count, and disk size, the total cluster raw capacity may fall outside the maximum supported cluster raw capacity. For example, for an 18-node cluster, if each node contains 25 disks, and each disk size is P70 (16 TiB), the final total cluster raw capacity is 7200 TiB, which exceeds the maximum supported raw capacity. Therefore, this combination is not supported.

See Appendix A: supported cluster configuration details for all supported combinations.

File system journal

OneFS file system journal, which stores information about changes to the file system, is designed to enable fast consistent recoveries after system failures or crashes. The file system replays the journal entries after a node or cluster recovers from an outage.

Each Azure VM node contains local SSD storage, which is also known as a temporary disk. OneFS leverages one of the local SSDs as the journal storage for protecting uncommitted writes to the file system. When a node boots up, it checks its journal and selectively replays transactions to disk when the logic in the journaling system requires it.

OneFS protection level

The OneFS cluster is designed to withstand one or more simultaneous component failures while continuing to serve data. To achieve this, OneFS protects files with either erasure code-based protection, using Reed-Solomon error correction (N+M protection), or a mirroring system. Data protection is applied in software at the file level, enabling the system to focus on recovering only those files that are compromised by a failure, rather than having to check and repair an entire file set or volume. OneFS metadata and inodes are always protected by mirroring, rather than Reed-Solomon coding, and with at least the level of protection as the data they reference. For more technical details about OneFS protection levels, see OneFS Data Protection.

PowerScale for Microsoft Azure is set with a default protection level of +2n, capable of tolerating the failure of up to two drives or two nodes. We have chosen this +2n protection level for PowerScale for Microsoft Azure to ensure robust availability and reliability in the cloud environment. While the default setting prioritizes resilience, users have the option to adjust the protection level to +2d:1n for improved storage efficiency. However, it is essential to note that this configuration comes with certain capacity restrictions. The +2d:1n option can tolerate the failure of either two drives or one node.

For clarity on how different protection levels affect storage capacity, Table 3 outlines the maximum cluster raw capacity limits for using the +2d:1n protection level with various Azure managed disk sizes. If these capacity limits are exceeded, users must revert to the default +2n protection level when expanding the cluster to accommodate additional capacity needs. For example, if you have a 14-node cluster with +2d:1n protection level and each node has 15 disks using P50 Azure managed Prem SSD disks, the cluster raw capacity is 840 TiB. When you add more nodes into the cluster, the cluster raw capacity exceeds the limit of P50 using +2d:1n shown in Table 3. You must change to the default +2n protection level.

On deployment of a new cluster, the default protection scheme is set to +2n. All the files on the cluster inherit this level of protection. If the cluster only has a minimum number of nodes - 4, +2n protection means that the data on the cluster will remain protected even when two nodes of the cluster fail simultaneously. In the Azure environment, each of the OneFS virtual nodes within a cluster resides on different underlying physical hardware. Therefore, the chances of two nodes failing simultaneously are slim.

In the very unlikely event of two of the four nodes failing simultaneously, the cluster will only have two functional nodes and it loses quorum. Regardless of the cluster protection level, a cluster loses quorum when at least half the number of nodes in the cluster are unavailable. To protect the data, the cluster becomes un-responsive to client I/O. When at least one of the two failed nodes are back online in the cluster, the cluster will automatically become writeable. There will be data unavailability until at least one node is back online to bring back the quorum but there will not be data loss. If needed, some data will be re-built automatically. If there is a need for the cluster to remain available and writeable even if two nodes fail with +2n protection, increase the cluster size to five nodes.

Alternatively, deploying a new cluster that has only four nodes in it, one can change the protection level to +2d:1n, which will protect the data on the cluster against a one-node failure or a two-disk failure. If the protection scheme is set to +2d:1n, the cluster will remain writeable when one node in the cluster fails.

For comprehensive details about supported cluster configurations, see Appendix A: supported cluster configuration details. This includes information about various combinations of cluster node count, disk size, and disk count per node. The appendix also specifies whether the +2d:1n protection level is supported with specific configurations.

Table 3.      Cluster raw capacity restriction using +2d:1n

The protection overhead varies with cluster size. Table 4 shows the protection overhead of PowerScale for Microsoft Azure with different cluster sizes. File system efficiency increases as the cluster size grows, meanwhile, the storage efficiency gap between +2n and +2d:1n also gets smaller as the cluster size grows. Therefore, if capacity is your primary requirement, opting for +2d:1n in a small cluster can yield a higher usable cluster capacity. Conversely, using +2n in a large cluster ensures storage efficiency while maintaining superior resilience. Usable cluster capacity refers to the amount of storage capacity available for storing data after accounting for protection overhead. For the min and max usable capacity using different protection levels, see Appendix B: Cluster raw capacity and usable capacity.

Table 4.      Protection overhead

Note: The final effective capacity of a OneFS cluster depends on the characteristics of the data and on the file system features in use. For example, OneFS provides inline data reduction and small file efficiency features to help save storage capacity. Data capacity savings due to inline data reduction and small file efficiency greatly depend on the data and can vary considerably. This variance means that accurate rates of savings are not predictable without a comprehensive analysis of the dataset. The preceding usable cluster capacity estimation is for guidance only when implementing PowerScale for Microsoft Azure. For more details about storage efficiency, see the white paper Dell PowerScale OneFS: Data Reduction and Storage Efficiency.

Available Azure regions

PowerScale for Microsoft Azure is available in the following Azure regions:

• South Africa North
• East Asia
• South East Asia
• Australia Central
• Australia East
• Australia Southeast
• Brazil South
• Canada Central
• Canada East
• China East 2
• China North 2
• China North 3
• North Europe
• West Europe
• France Central
• Germany West Central
• Central India
• South India
• Japan East
• Japan West
• Korea Central
• Norway East
• Poland Central
• Qatar Central
• Sweden Central
• Switzerland North
• UAE North
• UK South
• UK West
• Central US
• East US
• East US 2
• North Central US
• South Central US
• West Central US
• West US
• West US 2
• West US 3

Planning cluster configuration details

After you have understood the supported cluster configurations and have analyzed your business requirements, you can start to plan your deployment details. Write down the configuration, including your OneFS cluster settings and Azure infrastructure information.

The following table contains an example. For this example, we will deploy a 4-node cluster with Azure Premier SSD disk type and D48ds_v5 instance type.

Table 5.      Cluster configuration example

This section describes the prerequisites that you should fulfill before using the Terraform module to deploy PowerScale for Microsoft Azure.

Prerequisites on Azure

Azure subscription

PowerScale for Microsoft Azure requires an Azure subscription. Users are required to provide their subscription. When a subscription has been created and configured to the user’s company policies, a user account is required. Dell Technologies recommends that this user account be added at least to a Contributor role.

If users are unable to be added as a Contributor role, an administrator must create a role with the following permissions:

• Microsoft.Compute/availabilitySets/delete
• Microsoft.Compute/availabilitySets/read
• Microsoft.Compute/availabilitySets/write
• Microsoft.Compute/disks/delete
• Microsoft.Compute/disks/read
• Microsoft.Compute/disks/write
• Microsoft.Compute/images/read
• Microsoft.Compute/images/write
• Microsoft.Compute/proximityPlacementGroups/delete
• Microsoft.Compute/proximityPlacementGroups/read
• Microsoft.Compute/proximityPlacementGroups/write
• Microsoft.Compute/virtualMachines/delete
• Microsoft.Compute/virtualMachines/read
• Microsoft.Compute/virtualMachines/write
• Microsoft.Network/networkInterfaces/delete
• Microsoft.Network/networkInterfaces/read
• Microsoft.Network/networkInterfaces/write
• Microsoft.Network/networkSecurityGroups/delete
• Microsoft.Network/networkSecurityGroups/read
• Microsoft.Network/networkSecurityGroups/write
• Microsoft.Network/virtualNetworks/read
• Microsoft.Network/virtualNetworks/subnets/read
• Microsoft.Resources/subscriptions/resourceGroups/read
• Microsoft.Resources/subscriptions/resourceGroups/write

Azure Resource Group

Although PowerScale for Microsoft Azure can live in an existing resource group, it is recommended to create a resource group for management purposes. A resource group allows the cluster to be contained as a single resource and easily kept track of and disposed of when its use is no longer required.

To create a resource group, follow these steps:

1. Select your subscription and enter the home page of the subscription in the UI.
2. In the left panel, select resource groups.
3. Click the Create button in the menu bar.
4. Enter the subscription, resource group name, and Azure location for the new resource group, then click review and create, and finally create the resource group.

When you have created the resource group, you are ready to create Azure resources that the PowerScale for Microsoft Azure will use.

Azure Virtual Network and Subnets

PowerScale for Microsoft Azure requires two different Azure subnets which must be in the same Azure virtual network:

• A dedicated internal subnet for the cluster's internal network. The subnet is only used by backend communication between nodes and cannot be shared with other instances or services.
• An external subnet for the cluster’s external network.

To create an Azure virtual network and two subnets, follow these steps:

1. In the portal, search for and select Virtual networks.

2. On the Virtual networks page, select + Create.
3. On the Basics tab of Create virtual network, enter and select the information for Subscription, Resource group, Name, and Region.
4. In the IP Addresses tab, create one internal subset and one external subset.

Note: We recommend at least a /26 network mask for each Azure subnet.

5. Select Save.
6. Select Review + create at the bottom of the window. When validation passes, select Create.

Note: IPv6 is not currently supported.

Azure Network Security Groups

You should create two Azure Network Security Groups (NSG):

• Internal NSG for internal network interface cards only
• External NSG for external network interface cards

To create an Azure NSG, follow these steps:

1. In the search box at the top of the Azure portal, enter network security group. Select Network security groups in the search results.

2. Click + Create.
3. In the Create network security group page, under the Basics tab, enter or select the values for Subscription, Resource group, Network security group name and Region.
4. Select Review + create.
5. After you see the Validation passed message, select Create.

Note: Configuration on ports in Azure NSG relies on the feature you will use. See the white paper Network port usage - PowerScale OneFS Security Configuration Guide for more details.

Azure Managed Identity

If you intend to use OneFS SmartConnect, dynamic network pool, or other network failover features, you must first configure Azure Managed Identity.

Important: In the current release, we only support single user-managed identity. System-managed identity, multiple user-managed identity, or any combination are not supported. Make sure you have disabled system-managed identity on each node before you start to follow the steps below.

1. In the search box at the top of the Azure portal, enter identities. Select Managed Identities.

Figure 2.   Managed Identities

2. Click Create.

Figure 3.   Create Managed Identities

3. Choose your Subscription, Resource group, Region, and type Name.

Figure 4.   Create User Assigned Managed Identity

4. Click Review + create and then click Create.
5. In your subscription, click Access Control(IAM) in the left navigation bar.
6. Click Add, and choose Add custom role in the drop down menu.
7. Create a role with the following permissions

Microsoft.Network/networkInterfaces/read

Microsoft.Network/networkInterfaces/write

Microsoft.Network/virtualNetworks/subnets/join/action

Microsoft.Network/networkSecurityGroups/join/action

Microsoft.Compute/virtualMachines/vmSizes/read

Microsoft.Compute/virtualMachines/read

Figure 5.   Create a custom role with permissions

8. Click Review + create and then click Create.
9. After the custom role is created, bind the role to the managed identity by clicking Add and choosing Add role assignment.
10. In the Role tab, choose the custom role just created and click Next.

Figure 6.   Add role assignment - Role

11. In the Members tab, choose Managed identity in the Assign access to field. In the pop-up Select managed identities window, choose the identity created in the previous step. Click Select then, click Review + assign. Click Assign.

Figure 7.   Add role assignment

Prerequisites for the host machine

Overview

A host machine is used to run the Terraform script for provisioning, scale-out, and destroying.

This can be any machine that has access to the Azure portal. Make sure the following components are installed on this machine:

• Python 3.8 and above
• Azure CLI
• Terraform (1.3.6 and above)

Note: Administrator permission is required to install Azure CLI.

Deployment options.

PowerScale for Microsoft Azure supports two deployment options:

• Deployment from an Azure non-Marketplace image
• Deployment from an Azure Marketplace image

Deployment from an Azure non-Marketplace image

A OneFS image file and script files will be provided in this deployment option with the steps below. For the detailed deployment steps, refer to the chapter Deploy PowerScale for Microsoft Azure.

1. Go to the Github repository to download the most recent version of the Terraform module for PowerScale for Microsoft Azure.

2. Go to the Dell support site to download the OneFS image.

Note: PowerScale for Microsoft Azure supports the OneFS image from 9.8.0.0

Deployment from an Azure Marketplace image

If the end-user has already purchased PowerScale for Microsoft Azure, they can also directly use the image file in the Azure Marketplace. Follow the steps below:

1. Go to the Azure Marketplace.
2. Click PowerScale for Microsoft Azure – Customer Managed.
3. Click the link Get started which is beside Want to deploy programmatically?
4. Enable your Azure subscription for this offer.

After you have fulfilled the Prerequisites, you can start to deploy PowerScale for Microsoft Azure.

Azure CLI Login

Use the following steps to log in to the Azure CLI:

1. Open a Command Prompt and use the following command to log in to the Azure CLI:

Figure 8.   Azure CLI login

2. It will prompt a browser where you can pick your Azure account for login.

Figure 9.   Pick an account to log in

3. After you successfully log in with your Azure account, your subscriptions will appear in the Azure CLI output:

Figure 10.    Login output

Set a default Azure subscription

If you have multiple Azure subscriptions, ensure that the default subscription settings match where you want the deployment to occur. Use the following steps to set a default subscription:

1. At a Command Prompt, use the following command to set the default Azure subscription. Replace the subscription ID in the parameter with the one you want to use. You can easily find the ID in the login output shown in Figure 10.

>az account set --subscription=<your default subscription ID>

2. Use the following command to verify whether the target subscription has been set to default. You can find the field - isDefault is set to true.

>az account list

Figure 11.    Set default Azure Subscription

Note: If users intend to use the image in the Azure marketplace, they don’t need to upload the VHD manually. Refer to the section Deployment options. for more details.

To upload the VHD to Azure, follow these steps:

1. At a Command Prompt, go to the folder where the file OneFS-9.8.0.0_vhd.tgz is located.

2. To extract the VHD file, use the command: tar -xvzf ./OneFS-9.8.0.0_vhd.tgz

Note: Dell recommends you use tar command to extract the VHD file. Using other tools may cause unexpected errors.

3. To upload the VHD, refer to the Python script in Error! Reference source not found.. Use the following command to perform the conversion and replace the corresponding parameters with the location of the OneFS-9.8.0.0.vhd file and your Azure resource group name:

python make_img.py <Location of the OneFS-9.8.0.0.vhd> <Azure resource group name>

Note: Ensure that Python 3.8 or a newer version is available before continuing.

Figure 12.    Convert vhd file to Azure image

4. Usually, it will take several minutes to complete the conversion process and to copy the image to the Azure blob store. When it is finished, the output is similar to what appears in Figure 13. At the same time, in the Azure resource group, you can find that the image and its disk have been created as shown in Figure 14.

Figure 13.    Conversion output

Figure 14.    Image and disk

Overview

Before following the steps in this section, make sure you have met all the Prerequisites and fulfilled all the preparation work in the previous sections.

Prepare main.tf

The main.tf file is the main configuration file in a Terraform project and it invokes the OneFS module for deployment. Refer to the example in the Github.

Note: Make sure you have set the correct source and version of the module in the main.tf file. For the other parameters, you can leave them as default. The value of these parameters will be set in terraform.tfvars, which will be explained in the next section.

Prepare terraform.tfvars

The terraform.tfvars file is used in Terraform to assign values to input variables that are declared in other configuration files, such as variables.tf. It externalizes variable definitions, allowing users to set specific values for variables without modifying the main configuration file directly. When running Terraform commands, such as terraform apply, the values from terraform.tfvars will be automatically used.

The following is an example of the terraform.tfvars file, which is used to create a 3-node cluster. For a detailed explanation of all the variables, refer to the section - Prepare vm.json

Deploy from a non-Marketplace image

If you intend to deploy the cluster from a non-Marketplace image, and the image is uploaded to your Azure resource group with the steps described in the section Upload the image file to PowerScale for Microsoft Azure, there is no need to modify the vm.json file.

Deploy from an Azure Marketplace image

Note: Reach out to PowerScale.Azure@dell.com to get a modified version of vm.json to support your deployment from Azure Marketplace. The following section explains where the changes happens for different regions.

If you intend to deploy the cluster from an Azure Marketplace image for OneFS, the following parts should be updated in the file vm.json:

Figure 15.    Example of the vm.json file using OneFS image from the US Marketplace offer

In the Azure Marketplace, we have 3 offers for different regions:

• US
• Canada
• EISI (rest of the world)

Change the vm.json file according to the region of the Azure Marketplace offers you want to use.

Table 6.      Azure template parameters for different regions

Terraform input variables.

# Subscription

subscription_id = "d9338087-1c11-49bd-9f55-904a2e52b491"

# Resource Group

resource_group = "playground"

# Cluster OS Information

cluster_name           = "c1"

image_id               = "/subscriptions/d9338087-1c11-49bd-9f55-904a2e52b491/resourceGroups/playground/providers/Microsoft.Compute/images/ga"

# Hashed Password (Default)

hashed_root_passphrase= "$5$a1b2c3d4e5f6f7$dtfoem8FDBRPZpIY.vdU9NRxbSmWswJerIF3oQabRx."

# Cluster Scale

node_size     = "Standard_D32ds_v5"

cluster_nodes = 4

max_num_nodes = 18

# Networking Information

smartconnect_zone        = "foo.bar"

network_id               = "/subscriptions/d9338087-1c11-49bd-9f55-904a2e52b491/resourceGroups/playground/providers/Microsoft.Network/virtualNetworks/vnet"

addr_range_offset        = 5

external_subnet_name     = "frontendSubnet"

internal_subnet_name     = "backendSubnet"

data_disk_type           = "Premium_LRS"

# Network Security Group

internal_nsg_name = "nsg"

internal_nsg_resource_group = "playground"

external_nsg_name = "nsg"

external_nsg_resource_group = "playground"

# Storage Configuration

os_disk_type        = "Premium_LRS"

data_disk_size      = 1024

data_disks_per_node = 3

# Disk Encryption Configuration

use_disk_encryption                = true

disk_encryption_set_name           = "tmeDiskEncryptionSet"

disk_encryption_set_resource_group = "playground"

identity_list = ["/subscriptions/698d6dde-d358-40ee-b489-3d9900a3a157/resourceGroups/Thunder-cloud-rg /Microsoft.ManagedIdentity/userAssignedIdentities/demo-identity"]

Prepare vm.json

Deploy from a non-Marketplace image

If you intend to deploy the cluster from a non-Marketplace image, and the image is uploaded to your Azure resource group with the steps described in the section Upload the image file to PowerScale for Microsoft Azure, there is no need to modify the vm.json file.

Deploy from an Azure Marketplace image

Note: Reach out to PowerScale.Azure@dell.com to get a modified version of vm.json to support your deployment from Azure Marketplace. The following section explains where the changes happens for different regions.

If you intend to deploy the cluster from an Azure Marketplace image for OneFS, the following parts should be updated in the file vm.json:

Figure 16.    Example of the vm.json file using OneFS image from the US Marketplace offer

In the Azure Marketplace, we have 3 offers for different regions:

• US
• Canada
• EISI (rest of the world)

Change the vm.json file according to the region of the Azure Marketplace offers you want to use.

Table 7.      Azure template parameters for different regions

Terraform input variables

Terraform lets you customize Terraform modules without altering the module's own source code. The Terraform module for PowerScale for Microsoft Azure supports the input variables listed in Table 8.

Table 8.      Supported input variables for PowerScale for Microsoft Azure

Parameter image_id and network_id

To get the value of the parameters image_id and network_id, navigate to the overview page of Azure image and virtual network:

Figure 17.    Overview page of image file for OneFS

Click the link JSON View, and click Copy to clipboard:

Figure 18.    Copy URI of image file for OneFS

Hashed admin or root password

To use different passwords for the root and admin, an end-user can specify  hashed_root_passphrase and hashed_admin_passphrase respectively.

To generate the hashed password, use the following command:

openssl passwd -5 -salt `head -c 8 /dev/random | xxd -p` "<replace-password-here>"

In the above command, head -c 8 /dev/random | xxd -p is used to generate an 8 byte random string in its hexadecimal representation which is used as the salt for producing the hashed output.

Disk Encryption

By enabling disk encryption via setting the use_disk_encryption input parameter to true, it is possible to use an existing disk encryption set in Azure to encrypt both the OS disks and data disks created by Terraform.

Note that the name of the existing disk encryption set and the resource group it is located in will need to be added to the disk_encryption_set_name and disk_encryption_set_resource_group input parameters respectively.

Initialize Terraform

Initialize the Terraform configuration, where it configures the backend, installs all required providers and modules used in the Terraform script, and creates a lock file if it does not already exist. To do that:

1. At a Command Prompt, change to the directory where the Terraform scripts are located.

2. Run the command:

>terraform.exe init

3. If everything goes fine, you will see the following message:

Figure 19.    Successful message

4. To validate your configuration, use the following command:

>terraform.exe validate

PowerScale for Microsoft Azure Deployment

To deploy an instance of PowerScale for Microsoft Azure, run the following commands:

Note: Before applying the Terraform code, run terraform plan for a quick dry run to validate all the changes.

1. Apply the configurations by running the following command.

# terraform apply

2. Enter yes after you have previewed and confirmed the changes.

Do you want to perform these actions?

  Terraform will perform the actions described above.

  Only 'yes' will be accepted to approve.

  Enter a value: yes

3. When the deployment is complete, output similar to the following appears:

Figure 20.    Terraform output after the success

Note: After the deployment completes, the nodes will not be immediately available, because they will undergo an automatic configuration process to form a cluster, which requires a few minutes.

4. In this example, you can use the IPs from ip_addresses in Figure 20 to connect to your PowerScale for Microsoft Azure.

Figure 21.    Cluster status for PowerScale for Microsoft Azure

Licensing

For details on how to apply the license for PowerScale for Microsoft Azure, refer to PowerScale OneFS Web Administration Guide.

Dell Technologies connectivity services, in some old OneFS versions, also known as SupportAssist, are designed to transmit logs, events, and telemetry to the Dell backend services. For details on configuration, refer to PowerScale OneFS Web Administration Guide.

Dell is responsible for supporting PowerScale OneFS only, and Microsoft Azure will be responsible for supporting the infrastructure.

The SWID is used to file a support ticket to Dell and is available in the OneFS web administration interface or the CLI.

In OneFS:

• Click Cluster Management > Licensing
• The OneFS license ID is the SWID for the cluster

From the command-line interface:

• Open an SSH connection on any node in the cluster and log in using the "root" account.
• Run the following command to get only the SWID: isi license list | grep -i "OneFS license"

You can scale out an existing cluster at any time to meet your business needs. This section shows how to add a node to an existing cluster.

1. Edit the terraform.tfvars file to change the cluster_nodes field to one higher.

Note: You can increase the value of cluster_nodes by any number, but it should not exceed the value of max_num_nodes which is defined in the same file. The maximum value for max_num_nodes is 18. In some scenarios, there are valid configurations that have a maximum node count of less than 18. Refer to Appendix A: supported cluster configuration details for more details.

2. Apply the changes and select ‘yes’ at the prompt:

> terraform.exe apply

3. The Terraform script will highlight the changes that apply to the cluster:

Figure 22.    Changes to the cluster

4. The new node will be available in a few minutes. After it has been successfully provisioned, you can check it in the Terraform output:

Figure 23.    Terraform output

5. To join the new node to the existing cluster, do the following:
   1. To log in to the serial console, access the new node’s management page in the Azure Portal and select Serial console from the Help portion of the management pane on the left-hand side.

Figure 24.    Azure serial console to join an existing cluster

Note: Only the Serial console will work. An SSH connection through Bastion will not.

2. In the configuration wizard, select option 2 to Join an existing cluster.
3. Type the cluster name to join. When it finishes, it prompts you to open the login window. Log in as root, then use the isi status command to verify the result.

To destroy an instance of PowerScale for Microsoft Azure provisioned by Terraform, follow these steps:

1. Navigate to the Terraform folder where you do the provisioning. The folder should contain your Terraform variable definitions file (.tfvars) and the state file (.tfstate).

2. Run the Terraform destroy command, similar to the following, to tear down all resources on Azure created by the Terraform script:

# terraform destroy

Important: Before starting to configure SmartConnect, make sure that you have followed the steps in the sections Azure Managed Identity and Prepare vm.json

Deploy from a non-Marketplace image

If you intend to deploy the cluster from a non-Marketplace image, and the image is uploaded to your Azure resource group with the steps described in the section Upload the image file to PowerScale for Microsoft Azure, there is no need to modify the vm.json file.

Deploy from an Azure Marketplace image

Note: Reach out to PowerScale.Azure@dell.com to get a modified version of vm.json to support your deployment from Azure Marketplace. The following section explains where the changes happens for different regions.

If you intend to deploy the cluster from an Azure Marketplace image for OneFS, the following parts should be updated in the file vm.json:

Figure 25.    Example of the vm.json file using OneFS image from the US Marketplace offer

In the Azure Marketplace, we have 3 offers for different regions:

• US
• Canada
• EISI (rest of the world)

Change the vm.json file according to the region of the Azure Marketplace offers you want to use.

Table 9.      Azure template parameters for different regions

Terraform input variables to deploy an instance of PowerScale for Microsoft Azure.

Important: SmartConnect relies on the Azure endpoint https://management.azure.com to request IP assignment or removal. Make sure your firewall unblock it from each node.

To configure SmartConnect:

1. SSH to any nodes using the frontend IP.

2. Run the following command to make sure that the SmartConnect Service IP is shown in the output. In the example, the SSIP is 10.0.0.5.

isi network interfaces list

Figure 26.    SSIP in the list

3. Run the following command to make sure that the SmartConnect zone FQDN is well configured. In this example, the SmartConnect zone name is demo.cell.com.

isi network pools view groupnet0.subnet0.pool0

Figure 27.    SmartConnect zone name

4. The next step is to configure the DNS delegation, the steps vary depending on the DNS you use. The following steps assume that you are using Azure DNS and that Azure DNS private resolver will be created and configured for this purpose.

In the Azure Marketplace, to create an Azure DNS private resolver, click Create.

Figure 28.    Create DNS private resolver

5. In the Basics tab, fill in all the fields. Make sure that you choose the same region where your virtual network is.

Figure 29.    Create a DNS private resolver – Basics

6. In the Outbound Endpoints tab, select Add an endpoint, and in the pop-up window – Add an outbound endpoint, give it a Name. You can also create a subnet dedicated for this endpoint. To do this, click the link Create new and enter the Name and Subnet address range.

Figure 30.    Add an outbound endpoint

Figure 31.    Create a new subnet for outbound endpoint

7. In the Ruleset tab, type the ruleset name, and select the endpoint created in the previous steps. In the Rules sections, click Add. In the Add Rule window, type the Rule Name and Domain Name, which is your SmartConnect zone name. Choose the Rule State to Enabled. For the Destination IP address, type the SSIP which in this example is 10.0.0.5.

Figure 32.    Create ruleset

Figure 33.    Add rule

8. Click Review + create and then Create to complete the configuration.

Based on the explanation in Table 3, Table 4, and chapter OneFS protection level. This appendix lists all supported cluster configurations for different disk types and sizes. It also indicates whether the +2d:1n OneFS protection level is supported in the specific configuration. Here are the quick reference links for the different disk sizes:

• Disk size 0.5 TiB: Cluster using P20 or E20
• Disk size 1 TiB: Cluster using P30 or E30
• Disk size 2 TiB: Cluster using P40, E40, or S40
• Disk size 4 TiB: Cluster using P50, E50, or S50
• Disk size 8 TiB: Cluster using P60, E60, or S60
• Disk size 16 TiB: Cluster using P70, E70, or S70

The following table shows the available combinations of cluster size and disk count, by using 0.5 TiB disk size with P20 or E20.

Table 10.  Supported configurations details – P20 or E20

The following table shows the available combinations of cluster size and disk count, by using 1 TiB disk size with P30 or E30.

Table 11.  Supported configurations details – P30 or E30