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
About identifying a temporary resource disk - Linux
Typically, a temporary resource disk is named as /dev/sdb and is mounted at /mnt. However, the location may change depending on whether or not it is utilized for swap space or is unmounted by a user.
To identify whether or not swap space is configured and a disk utilized for swap space
- Identify the swap space configuration and check the swap file:
# swapon
Following is the sample output of this command:
NAME TYPE SIZE USED PRIO /mnt/resource/swapfile file 2G 0B -1
Where, /mnt/resource is the default location where a temporary disk is mounted when used for swap space.
- Identify the disk used for swap space:
# mount | grep "/mnt/resource"
Following is the sample output of this command:
/dev/sdb on /mnt/resource type filesystem
Where /dev/sdb is the temporary disk.
- Identify a VxVM disk that corresponds to a temporary disk.
# vxdisk -e list | grep sdb (If sdb is the OS device name for temporary disk found in the earlier step)
Following is the sample output for the command:
10-0-15-6_disk_490 auto:none - - online invalid sdb -