InfoScale™ 9.0 Solutions in Cloud Environments
- Overview and preparation
- Overview of InfoScale solutions in cloud environments
- InfoScale agents for monitoring resources in cloud environments
- InfoScale FSS feature for storage sharing in cloud environments
- InfoScale non-FSS feature for storage sharing in cloud environments
- About SmartIO in AWS environments
- Preparing for InfoScale installations in cloud environments
- Installing the AWS CLI package
- VPC security groups example
- Configurations for Amazon Web Services - Linux
- Configurations for Amazon Web Services - Windows
- Replication configurations in AWS - Windows
- HA and DR configurations in AWS - Windows
- EBS Multi-Attach feature support with InfoScale Enterprise in AWS cloud
- InfoScale service group configuration wizards support for EBS Multi-Attach
- Failover within a subnet of an AWS AZ using virtual private IP - Windows
- Failover across AWS subnets using overlay IP - Windows
- Public access to InfoScale cluster nodes in AWS using Elastic IP - Windows
- DR from on-premises to AWS and across AWS regions or VPCs - Windows
- DR from on-premises to AWS - Windows
- Configurations for Microsoft Azure - Linux
- Configurations for Microsoft Azure - Windows
- Replication configurations in Azure - Windows
- HA and DR configurations in Azure - Windows
- Shared disk support in Azure cloud and InfoScale service group configuration using wizards
- Failover within an Azure subnet using private IP - Windows
- Failover across Azure subnets using overlay IP - Windows
- Public access to cluster nodes in Azure using public IP - Windows
- DR from on-premises to Azure and across Azure regions or VNets - Windows
- Configurations for Google Cloud Platform- Linux
- Configurations for Google Cloud Platform - Windows
- Replication to and across cloud environments
- Migrating files to the cloud using Cloud Connectors
- About cloud connectors
- About InfoScale support for cloud connectors
- How InfoScale migrates data using cloud connectors
- Limitations for file-level tiering
- About operations with Amazon Glacier
- Migrating data from on-premise to cloud storage
- Reclaiming object storage space
- Removing a cloud volume
- Examining in-cloud storage usage
- Sample policy file
- Replication support with cloud tiering
- Configuration for Load Balancer for AWS and Azure - Linux
- Troubleshooting issues in cloud deployments
In an Azure environment, you may encounter failures when exporting non-shared disks for FSS
For Flexible Storage Sharing (FSS), you must first export all the non-shared disks for network sharing.
If your deployment setup involves JBODs, you may encounter the following failures while exporting the non-shared disks:
The disk export operation fails as described in the following example:
# vxdisk export DiskName
VxVM vxdisk ERROR V-5-1-531 Device DiskName: export failed: Disk not supported for FSS operations
The checkfss command fails as described in the following example:
# vxddladm checkfss DiskName
VxVM vxddladm INFO V-5-1-18714 DiskName is not a valid disk for FSS operation
This issue occurs if a JBOD definition is not added to the disks.
Workaround:
Before exporting a disk for network sharing, add a JBOD definition on the disk.
Note:
You can add a JBOD definition to a disk only if its SCSI inquiry supports a unique serial number. If the SCSI inquiry is unable to locate a unique serial number, you cannot export the disk for network sharing.
To add a JBOD definition to a disk, perform the following steps:
- Run a query on the standard disk pages (0, 0x80, and 0x83) to find the available unique serial number.
For page 0:
# /etc/vx/diag.d/vxscsiinq -d /dev/vx/rdmp/DiskName
For page 0x80:
# /etc/vx/diag.d/vxscsiinq -d -e 1 -p 0x80 /dev/vx/rdmp/DiskName
For page 0x83:
# /etc/vx/diag.d/vxscsiinq -d -e 1 -p 0x83 /dev/vx/rdmp/DiskName
Sample output of the command for page number 0x83 that contains the unique serial number:
------- Identifier Descriptor 1 ------- ID type : 0x1 (T10 vendor ID based) Protocol Identifier : 0x0 Code set : 0x1 PIV : 0x0 Association : 0x0 Length : 0x18 Data : 4d5346542020202069c0ae2f82ab294b834866ff... /dev/vx/rdmp/DiskName: Raw data size 32 Bytes: 0 - 7 0x00 0x83 0x00 0x1c 0x01 0x01 0x00 0x18 ........ Bytes: 8 - 15 0x4d 0x53 0x46 0x54 0x20 0x20 0x20 0x20 MSFT Bytes: 16 - 23 0x69 0xc0 0xae 0x2f 0x82 0xab 0x29 0x4b i../..)K Bytes: 24 - 31 0x83 0x48 0x66 0xff 0x1d 0xd3 0xf5 0xcb .Hf..... - Note the following values from the command output in step 1:
opcode = 0x12 (18)
This is a standard opcode.
pagecode = page number that contains the unique serial number
For example, 083.
offset = byte offset where the serial number starts
For example, in the output here, the offset value is 8.
length = length of the unique serial number that is provided in the Length field
For example, 24 or 0x18.
- Add the JBOD definition.
# vxddladm addjbod vid=vendorid serialnum=opcode/pagecode/offset/length
For example:
# vxddladm addjbod vid=MSFT serialnum=18/0x83/8/24
- Scan the disks.
# vxdisk scandisks
- Verify whether the JBOD definition has been added sucessfully.
# vxddladm checkfss DiskName
The command output displays a confirmation message.