Arctera Application Mobility Service Help
Overview
The Arctera Application Mobility Service enables you to migrate applications running on InfoScale clusters hosted in on-premises environments to the cloud. This is primarily done through a migration plan which facilitates the migration of all applications in the datacenter.
The migration plan mainly consists of the following steps:
Target configuration
Application configuration (manual)
Data replication
Application switchover
Post migration operation
The following table gives you the summary of tasks involved in these steps.
Table: Steps involved in migration plan
Target cluster configuration | Application configuration (manual) | Data replication | Application switchover | Post migration operation |
|---|---|---|---|---|
Create and get cloud infrastructure (subnets, NSG, ENI, EC2/EBS, ELB) | Install application binaries | Configure SRL volume on primary | Offline service groups on source (Manual) | Offline the RVG service groups on target |
Configure InfoScale cluster | Configure application, with equivalent parameters as of source. For client connection, use port number and protocol provided during ELB creation. | Configure SRL volume on secondary | Check if source and target data is in sync (Manual) | Delete RVG service groups on source and target |
Get InfoScale storage/disks | Set up VVR primary | Wait and check if service groups are offline | Delete SRL volume on source | |
Configure InfoScale storage (disk group, volume, file system) | Set up VVR secondary | Online service groups on the target | Delete SRL volume on target | |
Configure VCS (service groups/resources) | Create VCS service groups/resources for RVG | Wait and verify if service groups are online | Delete EBS volume provisioned for SRL volume on the target | |
Bring DG/Mount resources under RVG | ||||
Online RVG service group | ||||
Keep checking if primary and secondary data are in sync |
Following are the abbreviations mentioned in the Table: Steps involved in migration plan:
NSG: Network Security Groups
ENI: Elastic Network Interfaces
EC2: Elastic Compute Cloud
EBS: Elastic Block Store
ELB: Elastic Load Balancing
VVR: Veritas Volume Replicator
RVG: Replication Volume group
SRL: Storage Replicator Log
VCS: Veritas Cluster Server
Note:
For more information about the above terms, refer the Glossary section of this guide.
Veritas Volume Replicator (VVR) uses the UDP and TCP transport protocols to communicate between the Primary and Secondary. The following tables list the default ports used by VVR.
Table: Default ports used by VVR for replicating data using UDP
| Port numbers | Description |
|---|---|
UDP 4145 | IANA-approved port for heartbeat communication between the Primary and Secondary. |
TCP 8199 | IANA-approved port for communication between the vradmind daemons on the Primary and the Secondary. |
TCP 8989 | Communication between the in.vxrsyncd daemons, which are used for difference-based synchronization. |
UDP Anonymous ports (OS dependent) | Ports used by each RLINK for data replication between the Primary and the Secondary. |
Table: Default ports used by VVR for replicating data using TCP
Port numbers | Description |
|---|---|
UDP 4145 | IANA-approved port for heartbeat communication between the Primary and Secondary. |
TCP 4145 | IANA-approved port for TCP Listener port. |
TCP 8199 | IANA approved port for communication between the vradmind daemons on the Primary and the Secondary. |
TCP 8989 | Communication between the in.vxrsyncd daemons, which are used for difference-based synchronization. |
UDP Anonymous ports | Ports used by each RLINK for replication on the Primary. |