Attach Multiple Volumes to Tiers
You can attach multiple volumes to all tier types in N-tier applications. For each volume, you must specify the size and can optionally configure the storage type for each root disk. While the storage type is optional, Workload Manager uses the default storage type if not configured.
There is no specific out-of-box storage type for clouds that are not listed in this section as most clouds support additional volumes. You can specify these details as follows:
The number of volumes and default volume size details in the Understand Application Tier Properties.
The storage type selection and the size of root/additional volume in the Deployment Environments form.
Node Restart Behavior
When you restart a node or deploy an application, the appropriate volumes (defined in the Topology Modeler > Properties tab) are attached. For example, if Node 1 has Volumes V1 and V2, and Node 2 has volumes V3 and V4, then on restart, the same volume combination (number of volumes, size, and type) are attached to the nodes.
Configurable Volume Attributes
The following table describes cloud-specific details for Volume attributes.
All clouds support the ability to specify the storage type for additional volumes.
Public Clouds: Use the out-of-box storage types.
Private Clouds and Datacenters: If you configure a storage type, then Workload Manager displays the configured storage type in the dropdown list at the time of Storage Type selection during a deployment.
Only AWS and VMware vCenter support the ability to specify the Root Disk Size – The Root Volume Size setting is part of the Volumes section – You can optionally provide the root disk size in this field for both these clouds.
Most Public Clouds supports specifying root disk storage type – Dimension Data APIs do not support this feature.
Size is a required attribute for Additional Volumes.
For clouds that don't support root disk resizing, this field is greyed out.
Type is an optional volume information attribute that only provides values for public cloud instances identified in this section. For other cloud instances, the default volume type is used.
For private cloud instances, you can add a type but the addition will only apply to calculate the storage cost.
AzureRM Type Nuances
Using Workload Manager's Managed Disks in Azure, you can select one of three pre-defined disk sizes during deployment.
The Number of Volumes field pre-populates the default volume size as specified in the UI Configuration Options section below.
Ensure that the Number of Volumes field does not display 0 (zero) if you need to assign a predefined type to an AzureRM-based deployment.
Azure cloud instances display one of the following values for the Type attribute:
Standard (Managed) = Default for non-government regions
Unmanaged = Default for government regions
AWS Type Nuances
AWS cloud instances display one of the following values for the Type attribute:
General Purpose (SSD) = Default
Provisioned IOPS (SSD)
Google Type Nuances
Google cloud instances display one of the following values for the Type attribute:
Standard Persistent Disk = Default
SSD Persistent Disk
Local SSD Scratch disk (the root disk cannot be used for temporary storage)
Input/Output Operations Per Second (IOPS) is an optional volume information attribute. This attribute is only applicable if the Type attribute displays the Provisioned IOPS (SSD) value (see the Submit Job API). The ratio of provisioned IOPS and the requested volume size can be a maximum of 30. That is, a volume with 3000 IOPS must be a minimum of 100 GB in size.
A Provisioned IOPS (SSD) volume can range in size from 4 GB to 16 TB and in IOPS from 100 to 20000.
UI Configuration Options
When modelling N-tier applications, specify the Number of Volumes to be attached to each tier and the Default Volume Size for each volume in the General Settings field for each application tier. > Properties > If the selected cloud doesn't have volume types, the default volume size is pre-populated when running this application, as shown in following screenshot.
When modelling an application, the default volume size is prepopulated in the Size field if the minimum size of the storage type selected is less than default volume size for the modeled application. By default, all services do not have any persistent volume disk attached out-of-the box. If required, you can change the default volume size at this point
The following table describes how the default volume size is prepopulated.
Default Volume Size from App Being Modeled Value Pre-populated in the Size field >= minimum size of the selected storage type The default volume size < minimum size of the selected storage type The minimum size for the selected storage type
You can delete the configured volumes at the time of deployment – if the preconfigured number of additional volumes are not required for your deployment. The following screenshot shows how to delete configured volumes.
The following screenshot shows storage type selection for AWS.
You can configure the root volume size for AWS deployments using either the UI or the Submit Job (v2) API.
The previous generation AWS instance types like the t1, m1 series do not support the resizing of root volume.
To provide a larger size for root volume for an AWS deployment, use the Workload Manager instance type. The storage is provided in addition to the instance store and must be larger than the Root Volume size in the AMI. If set to zero, then the Root Volume size in the AMI is used.
Root volume size = 0 (zero) value: Configure the root volume size as 0 for the older generation of instance types. This zero configuration, by default, uses the AMI's root volume size.
Root volume size = non-zero value:
The General Purpose SSD type option is automatically selected for the each root volume.
Be sure to configure the root volume size to be higher than the size specified in the AMI but less than the size supported by AWS for General Purpose SSDs.
Container-Specific Configuration Options
The following screenshot depicts the location where you can select the volume type for container deployments.
The container Type is a static list with the following options:
Persistent Volume Claim – see https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims for additional context.
Storage Class – see https://kubernetes.io/docs/concepts/storage/storage-classes/ for additional context.
Empty Dir – see https://kubernetes.io/docs/concepts/storage/volumes/#emptydir for additional context.
In a deployment flow you must choose one these three options and Kubernetes mounts the volume for this container application.
The Type Selection is a list of available storage classes as provided by cloud administrator:
The Access Mode is a static list as determined by the provider. See https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes for additional context.
To scale a Kubernetes deployment with volumes, be sure to configure the volume Access Mode as ReadWriteMany for deployments that use either scaling or multiple replicas.
API Configuration Options
See the volumeInfos and the rootVolumeSize attributes in the Submit Job APIs.
- No labels