Search <book_title>...

Arctera Application Mobility Service Help

Last Published: 2025-01-27

Product(s): InfoScale & Storage Foundation (8.0.2, 7.4.2, 7.4.1, 1.0)

Platform: Linux

Frequently asked questions

Table: FAQs

Question	Answer
What browsers does Application Mobility Service support?	Application Mobility Service is compatible with Google Chrome and Mozilla Firefox. Arctera recommends not using Microsoft Internet Explorer and Microsoft Edge, as they do not render all information correctly.
What is a gateway and why do I need it?	The gateway nodes act as agents to connect your source and the target cluster to the Application Mobility portal. It is the interface for all secure communication between the Application Mobility portal and datacenters. Also, it provides an additional layer of security by not exposing InfoScale clusters directly to the portal or any other outside network.
How can I set up the gateway nodes?	Download the latest gateway node installer or RPM from the 'download' icon located at the upper right corner of the Application Mobility portal. Once you download it, follow the instructions that are noted in the Setting up and configuring the Gateway nodes section of this guide.
What technology do you use to perform application discovery in the source environment and configuration of the target environment?	Application Mobility Service uses integrated automation management tools to manage all the tasks that are executed in either the source (on-premises) or the target (cloud) environments.
Can I migrate the applications that are offline in the source environment?	No. Migration is only possible for the applications that are online in the source environment. Ensure that your applications are online in the source cluster(s) and rerun the discovery process before defining the migration plan.
Does the Application Mobility Service also manage the application configuration and data migration process?	No. Once Application Mobility Service provides the target configuration, the migration plan execution pauses so that you can manually install your applications and configure them as required. If the VVR option is not selected during in Migration Options, you are expected to migrate data manually and must ensure that your application service groups are offline in the source environment once data is fully synced to the target (cloud) environment. With VVR selected, Application Mobility Service takes care of data migration on its own. Once data is fully synced and the application service groups are offline in the source environment, you can then resume the migration plan in the Application Mobility Service portal and initiate the application switchover.
What operating systems are supported for the systems that are configured as gateway nodes?	For on-premises datacenter: RHEL version 7 or 8 For cloud datacenter: RHEL version 8.4, 8.6, and 8.8.
Do I need to install any packages in addition to the VRTSgateway RPM package?	No. The installation of VRTSgateway RPM package includes the installation of all the required dependencies. You can install the gateway RPM package using `yum localinstall`. For more information, refer to Setting up and configuring the Gateway nodes section.
Are there any additional steps or prerequisites that required for the AWS (cloud) gateway node?	Yes. To enable AWS infrastructure creation, you need to assign specific role or permissions to the EC2 instance that is used as the gateway node. Your gateway node should be in the same VPC that you intend to use as a migrate target for your on-premises applications. For more information, refer to Setting up and configuring the Gateway nodes section.
Are there any additional steps or prerequisites that required for the Azure (cloud) gateway node?	Yes. To enable Azure infrastructure creation, you need to assign specific role or permissions to the Azure Virtual Machine that is used as the gateway node. Your gateway node should be in the same VNet that you intend to use as a migrate target for your on-premises applications. For more information, refer to Setting up and configuring the Gateway nodes section.
Why do I need to update the `/etc/ansible/hosts` file?	Only the cluster nodes that added to the `/etc/ansible/hosts` file are included in discovery and migration workflows.
Why do I need to set up passwordless SSH communication between the gateway and the source cluster nodes?	The Application Mobility Service performs multiple tasks using integrated automation management tools to discover the source cluster configuration. For the automation playbooks to run successfully, and perform the required tasks, system access via SSH is required. To do so, provide the path to the SSH key, which is located on the gateway node. You do not need to share or upload key files to any other systems.
Do I need to rerun the discovery before defining and executing a migration plan?	Yes. It is highly recommended. Rerunning an application discovery before executing a migration plan ensures that you have the most current view of your discovered applications, which ensures an accurate recommended target (cloud) configuration. You can include any newly discovered applications in the migration plan if you created the plan before running the discovery operation.
Is it required to have a resource prefix that is unique across migration plans?	Yes. Ensure that you provide a unique resource prefix when defining your application migration plan. Resource prefix serves as a unique identifier for all the cloud resources created by the Application Mobility Service.
Why are Amazon Machine Images (AMIs) used to create the EC2 instances in the target cloud network?	A customized AMI that includes Arctera InfoScale is used to create the EC2 instances in the target cloud network (created as part of the migration process). The AMI is built using a Red Hat OS image that also has the InfoScale product stack installed. The AMIs are scanned using AWS' self-scanning tool to ensure there are no security vulnerabilities.
Why are Azure Machine Images used to create the Virtual Machines in the target cloud network?	A customized Azure Machine Image that includes Arctera InfoScale is used to create the virtual machines in the target cloud network (created as part of the migration process). The Azure Machine Image is built using a Red Hat OS image that also has the InfoScale product stack installed.
What is the difference between an instance and a machine image?	An instance is a virtual server running in cloud environment, while a machine image is a template for creating instances. A machine image contains the necessary information (operating system, software packages, and configurations) to launch a new instance.
Is the custom Machine Image feature eligible for both application migration and new deployments?	Yes. You can use custom machine images for application migration as well as new cluster deployment.
What if the assigned image disk space is less than 128 GB?	This may cause operation failure during migration or deployment use case. For smoother operation, Arctera recommends that the assigned image disk space should be 128 GB or more.
Why do I need to provide subnets for Eth1 and Eth2 network interface?	The InfoScale configuration requires an additional, private network interface that used for Low Latency Transport (LLT) communication. It is recommended to have LLT network interfaces in separate subnets for better resiliency and performance.
Why is an Elastic Load Balancer (ELB) and a target group that created as a part of the migration process?	Elastic Load Balancer (ELB) automatically distributes incoming application traffic across EC2 instances running an application. You must configure applications manually to listen on a given port, so that clients can connect to the application (running on an InfoScale cluster) The ELB target is the EC2 instance(s) provisioned by the Application Mobility Service.
Why is a Azure Load Balancer and a target group that created as a part of the migration process?	Azure Load Balancer automatically distributes incoming application traffic across virtual machines running an application. You must configure applications manually to listen on a given port, so that clients can connect to the application (running on an InfoScale cluster) The Azure Load Balancer target is the virtual machine(s) provisioned by the Application Mobility Service.
How can I verify if Application Mobility Service has created all the required cloud resources successfully?	Log on to the cloud service portal and search for the resources that have the resource prefix you defined in your migration plan.
Do you recommend sizing for EC2 instances and options for EBS volumes?	No. You are expected to select EC2 and EBS configuration options based on your application performance requirements. Refer to AWS documentation to identify the best suitable EC2 instance types and EBS volume types for your application.
Do you recommend sizing for virtual machines and options for data disks in Azure?	No. You are expected to select virtual machine and data disk configuration options based on your application performance requirements. Refer to Azure documentation to identify the best suitable virtual machine types and data disk types for your application.
Can I change the EBS volume type or provisioned IOPS after they have been created?	Yes. You can log on to the AWS portal and change the EBS type and provisioned IOPS as per application requirements. The Application Mobility Service supports provisioning of only a single type of EBS volume. If you have a requirement to provision different types of EBS volumes for different InfoScale volumes, you can log on to the AWS portal and change the EBS volume type and provisioned IOPS accordingly.
Can I change the data disk type or provisioned IOPS after they have been created?	Yes. You can log on to the Azure portal and change the virtual machine type and provisioned IOPS as per application requirements. The Application Mobility Service supports provisioning of only a single type of data disks. If you have a requirement to provision different types of data disks for different InfoScale volumes, you can log on to the Azure portal and change the data disk type and provisioned IOPS accordingly.
Can I change the EC2 instance type post the migration?	Yes. You can log on to the AWS portal, search for your EC2 instances using the resource prefix you defined and change its type. You can also choose to select less expensive EC2 instance types in an application migration plan. Once the target environment is provisioned and application configuration and data migration are complete, you can resize the EC2 instances (using the AWS portal) before switching over the application from the source to the target environment.
Can I change the virtual machine type post the migration?	Yes. You can log on to the Azure portal, search for your virtual machines using the resource prefix you defined and change its type. You can also choose to select less expensive virtual machine types in an application migration plan. Once the target environment is provisioned and application configuration and data migration are complete, you can resize the virtual machines (using the Azure portal) before switching over the application from the source to the target environment.
Do I need to manually delete or remove anything before re-executing a migration plan?	If you cancel a migration plan due to a failure, the Application Mobility Service manages the cleaning up process for all resources. However, it is recommended that you verify that all resources are removed and there are no 'stale' resources visible. Any 'stale' resource remained leads to the failure of migration plan execution on the next attempt as resources with the same name already exist.