Veritas InfoScale™ 8.0.2 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
Replication within an Azure region - Linux
In an Azure cloud environment, in a single region, you can provision your setup across virtual networks (VNets) or within a VNet.
The following diagram illustrates the sample configuration for setting up replication between the same VNet:
The following diagram illustrates the sample configuration for setting up replication across VNets:
Perform the following steps to set up replication in the same VNet, within the same region
- Enable the ports that are used for inbound and outbound communication.
For a list of required ports and services, refer to, Veritas InfoScale Replication Administrator's Guide - Linux.
- Using Microsoft Azure portal, create a VNet and specify an IP address space for the VNet.
- Create a subnet in the VNet created.
For details about creating a VNet, specifying an IP address space, and creating a subnet, refer to Microsoft documentation.
- Create two virtual machines within the subnets and provision storage.
- Install the appropriate InfoScale product on both the virtual machines.
- Create VxVM disk groups, VxVM volumes, Storage Replicator Log (SRL), Replicated Volume Group (RVG), and RLinks.
For details refer to, Storage Foundation Cluster File System High Availability Administrator's Guide.
Note:
In Azure environment, by default, in addition to the storage disks that you have attached, every virtual machine that is provisioned contains a temporary resource disk, that serves as an ephemeral storage. Do not use the temporary resource as a data disk (VxVM disk) to store persistent data. The disk may change after a machine is redeployed or is restarted, and the data will be lost. For more information about how Azure uses a temporary disk, see Microsoft documentation.
For details about how to identify a temporary resource disk:
- Flush the iptables on both the virtual machines.
# iptable -F
- Set up replication between the virtual machines using the private IP address or the virtual IP address.
For details about setting up replication see Setting up replication in the Veritas InfoScale Replication Administrator's Guide - Linux.
- Verify the replication status.
# vradmin -g dg_name repstatus rvg_name
Ensure that the replication status shows:
Replication status: replicating (connected)
Perform the following steps to set up replication across the VNets, within the same region
- Using Microsoft Azure portal, create two VNets and specify an IP address space for each VNet.
- Set up VNet Peering between the two VNets.
- Create a subnet in each VNet.
- Create a virtual machine in each subnet and provision storage.
- Install the appropriate InfoScale product on both the virtual machines.
- Create VxVM disk groups, VxVM volumes, Storage Replicator Log (SRL), Replicated Volume Group (RVG), and RLinks.
For details refer to, Storage Foundation Cluster File System High Availability Administrator's Guide.
Note:
In Azure environment, by default, in addition to the storage disks that you have attached, every virtual machine that is provisioned contains a temporary resource disk, that serves as an ephemeral storage. Do not use the temporary resource as a data disk (VxVM disk) to store persistent data. The disk may change after a machine is redeployed or is restarted, and the data will be lost. For more information about how Azure uses a temporary disk, see Microsoft documentation.
For details about how to identify a temporary resource disk:
- Flush the iptables on both the virtual machines.
# iptable -F
- Set up replication between the virtual machines using the private IP address or the virtual IP address.
For details about setting up replication see Setting up replication in the Veritas InfoScale Replication Administrator's Guide - Linux.
- Verify the replication status.
# vradmin -g dg_name repstatus rvg_name
Ensure that the replication status shows:
Replication status: replicating (connected)