Veritas InfoScale™ 7.4.1 Solutions in Cloud Environments
- Overview and preparation
- Overview of InfoScale solutions in cloud environments
- InfoScale agents for monitoring resources in cloud environments
- InfoScale feature for storage sharing in cloud environments
- About SmartIO in AWS environments
- Preparing for InfoScale installations in cloud environments
- Installing the AWS CLI package
- Configurations for Amazon Web Services - Linux
- Configurations for Amazon Web Services - Windows
- Replication configurations in AWS - Windows
- HA and DR configurations in AWS - Windows
- 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
- 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
- Troubleshooting issues in cloud deployments
About operations with Amazon Glacier
For all the supported cloud types except Glacier, the upload and retrieval operations are synchronous. For Glacier, the retrieval operation is asynchronous and the upload operation is synchronous.
An archive is a base unit of storage, similar to objects in Amazon S3 or Azure BLOB. A vault is a container for storing archives, similar to buckets in S3. An archive is created for each on-premises file, which means that there is a 1:1 mapping of archives and files. When a file is moved to Glacier, all the data in the file is written as one archive in a Glacier vault.
Retrieving an archive from Glacier is an asynchronous operation in which you first initiate a job, and then download the output after the job completes. When you initiate a job, Glacier returns a job ID in the response, and executes the job asynchronously. A new fscloudd daemon is added to poll for initiated jobs, and to check whether the job initialization is complete. When a retrieval from the Glacier tier is initiated, the fscloudd daemon is started internally, if it is not running already.
InfoScale supports the following types of retrievals from Glacier:
Expedited retrievals, which are typically made available within 1 - 5 minutes.
Standard retrievals, which typically complete within 3 - 5 hours. You can access any of your archives within several hours. When a retrieval option is not specified in a request, this option is used by default.
Bulk retrievals, which typically complete within 5 - 12 hours. This retrieval option costs the least, and you can use it to retrieve large amounts of data, even petabytes, in a day.
To specify a retrieval type, you provide flags in the policy.xml file.
In the following example, tier2 is a Glacier tier, which indicates relocation from Glacier.
<FROM Flags="expedited_retrieval">
<SOURCE>
<CLASS>tier2</CLASS>
</SOURCE>
</FROM>Flags for the other supported retrieval types are standard_retrieval and bulk_retrieval.
Relocation from Glacier is done asynchronously, and you can track it by using the fsppadm status command. For example:
#/opt/VRTS/bin/fsppadm status /mnt1 tier2 UX:vxfs fsppadm: INFO: V-3-20000: fsppadm: Download Processing for 5 files is remaining. #/opt/VRTS/bin/fsppadm status /mnt1 tier2 UX:vxfs fsppadm: INFO: V-3-20000: fsppadm: Download Processing for this tier is not in progress.