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
Failover across Azure subnets using overlay IP - Linux
InfoScale clusters let you fail over IPs - and thereby, the application configured for HA - between different subnets in the same VNet.
The following information is required:
The IP address outside VNet to be used for failover
The device to which the IP should be plumbed
Azure does not allow the private IP of one subnet to be failed over to a different subnet. To overcome this limitation, provide an overlay IP, which is outside the VNet level, so that it can be used across subnets.
The following graphic depicts a sample failover configuration across subnets within the same VNet using an overlay IP:
The sample configuration includes the following elements:
A Azure virtual network (VNet) is configured in Region A of the Azure cloud
An application is configured for HA using a cluster that comprises two nodes, Node1 and Node2, which are Azure virtual machines
Node 1 exists in Subnet 1 and Node 2 exists in Subnet 2.
An overlay IP is configured to allow redirecting IP address traffic to another cluster node belonging to different subnet within the same VNet as a part of the failover or the failback operations
The following snippet is a service group configuration from a sample VCS configuration file (main.cf):
group AzureAuthGrp (
SystemList = { azureVM1 = 0, azureVM2 = 1 }
Parallel = 1
)
AzureAuth azurauth (
SubscriptionId = 6940a326-abg6-40dd-b628-c1e9bbdf1d63
ClientId = 8c891a8c-xyz2-473b-bigc-035bd50fb896
SecretKey = gsiOssRooSpsPotQkmOmmQpuNoiQioNsjQlqHovUosQsrMt
TenantId = 96dcasae-0448-4308-b503-6667d61dd0e3
)
Phantom phres (
)
group AzureOverlayIP (
SystemList = { azureVM1 = 0, azureVM2 = 1 }
AutoStartList = { azureVM1, azureVM2 }
)
AzureIP overlayipres (
NICDevice = eth0
VMResourceGroup = ShilRG
OverlayIP = "192.168.99.99"
RouteTableResourceIds = {
"/subscriptions/6940a326-abg6-40dd-b628-c1e9bbdf1d63/
resourceGroups/ShilRG/providers/Microsoft.Network/
routeTables/shilroute",
"/subscriptions/6940a326-abg6-40dd-b628-c1e9bbdf1d63/
resourceGroups/SHILRG1/providers/Microsoft.Network/
routeTables/shilroute_eastUS2" }
AzureAuthResName = azurauth
)
IP ipres (
Device = eth0
Address = "192.168.99.99"
NetMask = "255.255.255.255"
)
NIC nicres (
Device = eth0
)
ipres requires overlayipres
ipres requires nicres