Veritas InfoScale™ 7.4.2 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
- 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
- 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
DR across GCP regions or VPC networks - Linux
InfoScale Enterprise lets you use the global cluster option (GCO) for DR configurations. You can use a DR configuration to fail over applications across different regions or VPC networks in the Google Cloud. The cluster nodes can be in the same zone or in different zones.
The following information is required:
VPC peering between regions or VPC networks
The IP address to be used for cross-cluster communication:
Virtual private IP for cluster the nodes that exist in the same subnet
Overlay IP for cluster the nodes that exist in different subnets
The
oauth2clientand thegoogle-api-python-clientGCP Python modules. For details, see the Bundled Agents Reference Guide - Linux.
The following graphic depicts a sample DR configuration across GCP regions:
The sample configuration includes the following elements:
VPC network peering between Region A and Region B
The primary site has the following elements:
A VPC network, VPC1, is configured in Region A of the Google cloud.
An application is configured for HA using an InfoScale cluster that comprises two nodes, Node 1 and Node 2, which are VM instances.
Node 1 exists in Subnet 1 and Node 2 exists in Subnet 2.
The virtual private IP of a node to be failed over in a subnet within the same zone or across zones.
The secondary site has the following elements:
A VPC network, VPC2, is configured in Region B of the Google cloud.
The same application is configured for HA on Node 3 and Node 4, which exist in Subnet 3 and Subnet 4 respectively.
The virtual private IP of a node to be failed over in a subnet within the same zone or across zones.
The following snippet is a service group configuration from a sample VCS configuration file (main.cf) at the primary site (Region A):
include "types.cf"
cluster pri (
ClusterAddress = "10.209.0.11"
UseFence = SCSI3
HacliUserLevel = COMMANDROOT
)
remotecluster sec (
ClusterAddress = "10.247.0.11"
)
heartbeat Icmp (
ClusterList = { sec }
Arguments @sec = { "10.247.0.11" }
)
system cloud-vm1 (
)
system cloud-vm2 (
)
system cloud-vm3 (
)
group ClusterService (
SystemList = { cloud-vm1 = 0, cloud-vm2 = 1, cloud-vm3 = 2 }
AutoStartList = { cloud-vm1, cloud-vm2, cloud-vm3 }
OnlineRetryLimit = 3
OnlineRetryInterval = 120
)
Application wac (
StartProgram = "/opt/VRTSvcs/bin/wacstart"
StopProgram = "/opt/VRTSvcs/bin/wacstop"
MonitorProcesses = { "/opt/VRTSvcs/bin/wac" }
RestartLimit = 3
)
GoogleIP vipres1 (
PrivateIP = "10.209.0.11"
Device = eth0
)
IP pipres1 (
Device = eth0
Address = "10.209.0.11"
NetMask = "255.255.255.255"
)
NIC GoogleIP_Nic1 (
Device = eth0
)
pipres1 requires GoogleIP_Nic1
vipres1 requires pipres1
wac requires pipres1
// resource dependency tree
//
// group ClusterService
// {
// GoogleIP vipres1
// {
// IP pipres1
// {
// NIC GoogleIP_Nic1
// }
// }
// Application wac
// {
// IP pipres1
// {
// NIC GoogleIP_Nic1
// }
// }
// }The following snippet is a service group configuration from a sample VCS configuration file (main.cf) at the secondary site (Region B):
include "types.cf"
cluster sec (
ClusterAddress = "10.247.0.11"
HacliUserLevel = COMMANDROOT
)
remotecluster pri (
ClusterAddress = "10.209.0.11"
)
heartbeat Icmp (
ClusterList = { pri }
Arguments @pri = { "10.209.0.11" }
)
system rahul-pri-cloud-vm1 (
)
group ClusterService (
SystemList = { rahul-pri-cloud-vm1 = 0 }
AutoStartList = { rahul-pri-cloud-vm1 }
OnlineRetryLimit = 3
OnlineRetryInterval = 120
)
Application wac (
StartProgram = "/opt/VRTSvcs/bin/wacstart"
StopProgram = "/opt/VRTSvcs/bin/wacstop"
MonitorProcesses = { "/opt/VRTSvcs/bin/wac" }
RestartLimit = 3
)
GoogleIP vipres1 (
PrivateIP = "10.247.0.11"
Device = eth0
)
IP pipres1 (
Device = eth0
Address = "10.247.0.11"
NetMask = "255.255.255.255"
)
NIC GoogleIP_Nic1 (
Device = eth0
)
pipres1 requires GoogleIP_Nic1
vipres1 requires pipres1
wac requires pipres1
// resource dependency tree
//
// group ClusterService
// {
// GoogleIP vipres1
// {
// IP pipres1
// {
// NIC GoogleIP_Nic1
// }
// }
// Application wac
// {
// IP pipres1
// {
// NIC GoogleIP_Nic1
// }
// }
// }