Planning for Microsoft Azure cloud

1. Create a service principle by using the az ad sp create-for-rbac command.
   To consult the credentials, issue the following command:

   az ad sp create-for-rbac --query "{ client_id: appId, client_secret: password, tenant_id: tenant }"

   The following output is an example of the previous command:

   { 
       "client_id": "00000000-0000-0000-0000-34XXXXXXX", 
       "client_secret": "00000000-0000-0000-0000-50XXXXXXX", 
       "tenant_id": "00000000-0000-0000-0000-40XXXXXXX", 
   } 

   To authenticate on Azure, you also need to obtain your Azure subscription ID. Issue the az account show command to consult this ID:

   az account show --query "{ subscription_id: id }"

   The following output is an example of the previous command:

   { 
       "subscription_id": "00000000-aea2-4177-a0f1-7117aXXXX" 
   } 

   Remember: Make a note of the next values because they are required during the configuration operations of cloudkit:

   • client_id
   • client_secret
   • tenant_id
   • subscription_id
2. Make sure to configure at least the Contributor role. These roles are required for the Azure service principle to run cloudkit.
3. Verify the Azure quota limits and make sure that enough quotas exist for the Azure instance types that you intend to deploy. To consult the quota limits of the Azure instance, see Azure Quotas documentation.
4. Prepare the installer node where the cloudkit is meant to run. For more information, see Preparing the installer node.
5. Optionally, create a resource group that holds all Azure resources that are specific for IBM Storage Scale cluster. For more information, see Create resource groups.

? VPC Mode:[Use arrows to move, type to filter]
> New
Existing

• Deploy IBM Storage Scale into a new VNET with a single availability zone

  This option builds a new Azure environment that consists of the VNET, private and public subnets, network security groups, application security groups, security rules, bastion hosts, and other infrastructure components; then, it deploys IBM Storage Scale into this new VNET with a single availability zone.

• Deploy IBM Storage Scale into an existing VNET

  This option provisions IBM Storage Scale in your existing Azure infrastructure.

• This is a mandatory step. Private subnets (with allocatable IP address range) in the availability region (minimum 1 private subnet per availability region).
• This is an optional step. A public subnet is only required if either of the following cases is met:
  1. Where the cluster is planned to be accessed through a jump host. For more information, see Other considerations.
  2. If there is a need to precreate an IBM Storage Scale VM image. For more information, see Planning for Microsoft Azure by precreating a VM image of IBM Storage Scale.
• This is an optional step. A cloud NAT attached to the private subnet is only required when the IBM Storage Scale instances need access to the internet (for operating system updates and security patches, and so on).
• If you configured an Azure Private DNS, you must provide the Azure Private DNS information during the cluster deployment..

  ? Do you wish to use Azure Cloud DNS:  Yes

• Make sure to select the appropriate resource group that is aimed to deploy the IBM Storage Scale cluster.

? Do you wish to use an existing DNS zone:  (y/N)

E: No existing DNS zones found. In order to configure, use 'cloudkit create dns'.

? Bastion OS:  RHEL-HA | RedHat | 8_8-gen2 | 8.8.2023121916 | azureuser
? Bastion instance type:  Standard_B2s    | vCPU(2) | RAM (4.0 GB)
? Do you wish to continue by creation of jumphost ssh key pair:  Yes
I: Bastion instance(s) private key path: /user/clouduser/bastion_ssh_keys/id_rsa
? Bastion CIDR allow list:  xxx.xxx.xxx.20/32

Standard_B2s    | vCPU(2) | RAM (4.0 GB)
Standard_B2s_v2 | vCPU(2) | RAM (8.0 GB)
Standard_B4s_v2 | vCPU(4) | RAM (16.0 GB)

• A Red Hat version that is supported by IBM Storage Scale.
• This is an optional step. For any customer applications already preinstalled, the cloudkit create image command installs all required IBM Storage Scale packages on top of the existing image.
• Up to two virtual machine images.
• An image that is a logical volume management (LVM) partition.

• Combined-compute-storage

  A unified IBM Storage Scale cluster with both storage and compute nodes. It is recommended that any customer workload runs only on the compute nodes.

• Compute-only

  An IBM Storage Scale cluster that consists only of compute nodes. This cluster does not have any local file system and therefore must remote mount the file system from an IBM Storage Scale storage cluster.

• Storage-only

  This IBM Storage Scale cluster consists only of storage nodes that have access to storage where the file system is created. This file system is remotely mounted to any number of compute-only IBM Storage Scale clusters.

? IBM Storage Scale deployment model: Storage-only
? Deployment purpose: [Use arrows to move, type to filter]
Non-Production
> Production

• Throughput-Performance-Persistent-Storage

  This profile uses a single availability zone with persistent storage, which means that the file system device retains data after the instance is stopped. In this mode, cloudkit calculates the number of storage nodes based on the provided file system capacity. The number of storage instances is limited to 64; compute instances are limited to 65.

  Important: When you choose this profile, the file system is configured in such manner that the data is not replicated, only the metadata gets replicated across the instances.

• Throughput-Performance-Scratch-Storage

  This profile uses a single availability zone and a proximity placement group, which means that it packs instances close together inside an availability zone. This strategy enables workloads to achieve the low-latency network performance necessary for tightly coupled node-to-node communication that is typical of high-performance computing (HPC) applications, with instance or temporary storage, meaning that the file system device loses data after the instance is stopped.

  In this mode, the number of storage instances is limited to 10 and compute instances is limited to 65.

  Important: This profile uses temporary storage (NVMe), which offers high performance and low latency for data-intensive workloads. However, the data that is stored in this mode is volatile and can be lost if the instance is stopped or terminated. Therefore, it is recommended to take frequent backups.

  This profile must not be used for long-term storage or if the data is not backed up elsewhere.

• Throughput-Advance-Persistent-Storage

  This profile uses a single availability zone with persistent storage, which means that the file system device retains data after the instance is stopped. This mode is meant for storage capacity rather performance; the number of storage instances are limited to 64; compute instances are limited to 65. This profile offers these disk types to choose from: Standard_LRS, StandardSSD_LRS, Premium_LRS, and PremiumV2_LRS.

  Important: When you choose this profile, the file system is configured in such manner that the data is not replicated, only the metadata gets replicated across the instances.

• Balanced

  This profile uses multiple (3) availability zones to deploy the IBM Storage Scale cluster into. In this mode, the number of storage instances is limited to 64. It offers a choice of disk types Standard_LRS, StandardSSD_LRS, Premium_LRS, and PremiumV2_LRS.

  Important: The IBM Storage Scale file system is configured in such a way that data and metadata are replicated across availability zones.

  Instances are spread across the first two availability zones that are specified in the selection, and the tie-breaker instance gets provisioned in the three availability zones that are specified during the selection.

  ? Tuning profile: [Use arrows to move, type to filter, ? for more help]
    Throughput-Performance-Scratch-Storage
  > Throughput-Performance-Persistent-Storage
    Throughput-Advance-Persistent-Storage 
    Balanced

• For Throughput-Performance-Persistent-Storage and Balanced profiles, the next VM instance types are supported.

  Standard_F8s_v2  | vCPU(8)  | RAM (16.0 GB)   | Max network bandwidth (12500   Mbps) 
  Standard_F16s_v2 | vCPU(16) | RAM (32.0 GB)   | Max network bandwidth (12500  Mbps) 
  Standard_F32s_v2 | vCPU(32) | RAM (64.0 GB)   | Max network bandwidth (16000  Mbps) 

• For Throughput-Performance-Scratch-Storage profile, the next VM instance types are supported.

  Standard_L8s_v3  | vCPU(8)  | RAM (64)  | Instance Storage (1 x 1.92  TB NVMe Disk) | Expected network bandwidth (12500 Mbps) 
  Standard_L16s_v3 | vCPU(16) | RAM (128) | Instance Storage (2 x 1.92  TB NVMe Disk) | Expected network bandwidth (12500 Mbps) 
  Standard_L32s_v3 | vCPU(32) | RAM (256) | Instance Storage (4 x 1.92  TB NVMe Disk) | Expected network bandwidth (16000 Mbps) 
  Standard_L48s_v3 | vCPU(48) | RAM (384) | Instance Storage (6 x 1.92  TB NVMe Disk) | Expected network bandwidth (24000 Mbps) 
  Standard_L64s_v3 | vCPU(64) | RAM (512) | Instance Storage (8 x 1.92  TB NVMe Disk) | Expected network bandwidth (30000 Mbps) 
  Standard_L80s_v3 | vCPU(80) | RAM (640) | Instance Storage (10 x 1.92 TB NVMe Disk) | Expected network bandwidth (32000 Mbps) 

• For Throughput-Advance-Persistent-Storage profile, the next VM instance types are supported.

  Standard_F8s_v2  | vCPU(8)  | RAM (16.0 GB) | Max network bandwidth (12500 Mbps) 
  Standard_F16s_v2 | vCPU(16) | RAM (32.0 GB) | Max network bandwidth (12500 Mbps) 
  Standard_F32s_v2 | vCPU(32) | RAM (64.0 GB) | Max network bandwidth (16000 Mbps) 

? Disk type: [Use arrows to move, type to filter, ? for more help]
> Standard_LRS
StandardSSD_LRS
Premium_LRS
PremiumV2_LRS

• Platform-managed encryption key. No configuration is required. By default disks are automatically encrypted-at-rest with platform-managed keys
• Customer-managed encryption key (CMEK). Managed through Azure Key Vault.

• Azure virtual machines for deployment
• Azure Resource Manager for template deployment
• Azure Disk Encryption for volume encryption

? Data stored in boot and data disk(s) are encrypted automatically. Select an encryption key management solution: [Use arrows to move, type to filter] 
> Platform-managed-encryption-key  
  Customer-managed-encryption-key 

• In these prompts, input a key name for the Azure Key Vault:

  ? Data stored in boot and data disk(s) are encrypted automatically. Select an encryption key management solution: Customer-managed-encryption-key
  ? Cloud Vault Name:  scalettest1
  ? Customer-managed encryption key (CMEK):  scalekey1

• Both boot and data-related volumes are encrypted.
• All data and boot volumes are encrypted by using a single key.
• Temporary disks or scratch storage disks are not encrypted when Customer-managed-encryption-key is used.
• The Azure Key Vault must use the same resource group that is used for IBM Storage Scale cluster creation.
• You cannot use the cloudkit command in the Azure Cloud VM.