New user sign up using AWS Builder ID
New user sign up using AWS Builder ID is currently unavailable on re:Post. To sign up, please use the AWS Management Console instead.
Accelerate VMware Migrations using Amazon Q Developer with Application Discovery Service Agentless Collector
Quick guide on how to deploy the Agentless Collector to enable automatic application grouping and migration waves planning for Amazon Q-assisted VMware migrations
In this post, we explore how to utilize the Application Discovery Service Agentless Collector to enable automatic application discovery and migration waves planning, using the Amazon Q Developer transformation capabilities for VMware workloads.
Amazon Q Developer is an AI-powered assistant for software development that takes the undifferentiated heavy-lifting out of complex and time-consuming application migration and modernization projects. Specifically, Amazon Q Developer transformation capabilities for VMware enables customers to easily migrate on-premises VMware workloads to cloud-native architecture and expedite cloud migrations.
The AWS Application Discovery Service Agentless Collector (Agentless Collector) is a tool that gathers information about your on-premises servers, network configurations and flow data, database engines and schema details etc. It is deployed as a lightweight virtual appliance within your on-premises VMware environment, making it possible to capture application inventory and dependencies via vCenter without needing to install agents on every workload.
Furthermore, using the Agentless Collector enables Amazon Q to perform automatic application discovery and grouping that accelerates the migration process for VMware workloads.
This guide will cover how to deploy and configure the Agentless Collector within your on-premises VMware environment. I will also demonstrate how to leverage Agentless Collector captured workload information for automatic application grouping and waves planning, through a VMware migration workflow example using the Amazon Q Developer.
Pre-requisites
-
An Amazon Q Developer Pro Tier Subscription to use Amazon Q Developer.
-
A working setup of AWS Identity and Access Management (IAM) Identity Center to federate into the new web experience.
-
A working setup of AWS Organizations.
-
Administrator access to an on-premises VMware vCenter environment (vSphere 6.7+)
-
Create an IAM user with the relevant IAM policies for the Agentless Collector as specified here.
-
(Optional): create a S3 bucket within the home Region of your Migration Hub for Agentless Collector database data collection module (this topic will not be covered in this post)
Deploy the Agentless Collector
Within the AWS console, navigate to Migration Hub > Discover > Tools , where you’ll find a link to download the OVA file of the Application Discovery Service Agentless Collector.
Once the file is downloaded, log into your vCenter and deploy it using the Deploy OVF Template option.
Next, we’ll need to configure an IP address for the Collector so it can communicate to the vCenter for data collection. Follow this guide to configure a static IP address for the Collector based on your on-premises network environment.
Now open a browser page and navigate to https://<agentless-collector-ip-address>/
to access the Collector console.
To activate the Agentless Collector, we’ll need to supply the AWS access-key and AWS secret-key from the Application Discovery Service IAM user as specified in the pre-requisites.
This will initialize the Collector and it will automatically connect to your Migration Hub's home Region within a minute.
We can also verify the Collector status from the Migration Hub > Discover > Data collectors > Agentless Collectors:
Set up the Agentless Collector
Within the Agentless Collector console, navigate to VMware vCenter section to enter your vCenter server management URL and credentials.
You should see the vCenter Data collection status changed to “Collecting” within a minute.
We can also verify the data collection status at the Migration Hub within the AWS console. Within 5~10 mins the Agentless Collector should start populating the discovered server list (Migration Hub > Discover > Servers).
We’ll now configure the network data module to start collecting TCP/IP flow information among discovered servers, which will enable Amazon Q Developer to build the application profiles for migration grouping and waves planning.
Within the Agentless Collector console, navigate to Network Data Collection and click “set up network connections”.
We’ll need to supply the SNMPv3 (Linux) and/or WinRM (Windows) monitoring account credentials for all workloads in migration scope. Note there are specific requirements for setting these SNMPv3 or WinRM accounts, as defined here.
You can then verify the SNMP/WinRM collection status for each server, and (if required) to troubleshoot accordingly.
To verify that the application flow data is being captured correctly, we can utilize the Network visualization tool under the Migration Hub > Servers > Network.
Use the search box to select a group of servers and verify their application flow data captured by the Agentless Collector. You can also check the inbound/listening ports for a specific sever.
At this stage, we have completed the basic configuration of the Agentless Collector. Ideally you should leave the collector running for at least a week to collect enough data before proceeding to the Q Transform for migrations planning.
Leverage Agentless Collector data for Amazon Q VMware Migration Planning
Once you are ready to kick off the migration workflow, follow this awesome blog post to setup an Amazon Q Developer: Transform workspace and create a VMware migration job.
We’ll first need to connect to a source AWS account to collect your on-premises discovery data, and this is the same account where the Agentless Collector is connected to.
After the source account connection is established, you should see the following message indicating you are ready to send Agentless Collector discovered data to Amazon Q for automatic application grouping and migration wave planning. (NOTE: Here you also have the option to upload a RVtools import. However, Amazon Q won't be able to provide automatic application grouping and waves planning since RVtools doesn't include live network connection data).
Next, click “Send to Q” to import the ADS collected data to Amazon Q for analysis.
However, if you are getting the below message indicating missing network-connection data, you’ll need to check the Agentless Collector network data module configuration, and collection status for those discovered servers. If everything looks fine you might just need to let the collector run for a longer period to collect more connection data.
Once Amazon Q has received imported data, we'll get a quick summary including how many servers are ready for application grouping, or how many are missing connection data etc. We can also download the full report as CSV exports.
Based on the summary, we have the option to send the existing data to finalize analysis, or to re-evaluate if we need to troubleshoot the Agentless Collector, or wait for it to collect more data and try again.
After the existing data is sent to Q, we'll soon receive the recommendations for application grouping and wave planning.
Download the recommendation file (CSV format), review and then update it as per your migration planning requirement:
In my example:
- Q Transform was able to pick up the 3x demo apps (a mixture of LAMP and WISA stacks), and automatically group them into 3x migration waves. (No action is required here but I've renamed the application waves to Wave1/2/3 for illustration purposes)
- Server 7 to 10 do not belong to a typical application stack (i.e. a Kubernetes cluster), and I can update the CSV file to provide an application name and place them into a separate application wave.
- Server 11 to 13 are on-premises management appliances (including the Agentless Collector itself). These workloads will not be migrated so I will simply delete them from the list.
I then upload the updated CSV file and send it back to Amazon Q to finalize the application groups and waves planning. These data will also be sent to and processed at the Migration Hub.
Navigate back to Migration Hub > Applications, we can see the 10x in-scope workloads are now grouped into 4x applications and waves as per our migration planning.
We are now ready to move onto the next phase of the Amazon Q migration workflow (i.e. build VPC configurations in the target account, and execute migration waves via AWS Application Migration Service (MGN)).
Refer to this blog post for further details to complete your migration workflow.
Clean Up
If you are running the Amazon Q Migration workflow within a test/demo environment, you might need to clean up the discovered data within the Migration Hub.
- Remove the Agentless Collector: Before you can clean up the server list, first stop data collection or simply power off the Agentless Collector appliance. This will stop the collector from continually feeding live data to your account. After that, use the AWS CLI tool to remove the Agentless Collector from your Migration Hub:
aws discovery batch-delete-agents --delete-agents agentId="agentless-collector-id",force=TRUE
- Remove Servers: To remove discovered servers from Migration Hub, you can use this AWS sample tool: ads-cleanup-resoruces. First, tag the servers in Migration Hub with a key/value pair (e.g “delete:yes”), and then use the tool to remove them:
cleanup-ads-resources python3 cleanupads.py -k delete -v yes
- Remove Applications: simply navigate to Migration Hub > Applications, select the Applications and click Action > Remove application.
Conclusion
This post walked through an example of deploying the Application Discovery Service Agentless Collector, which enables Amazon Q to perform automatic application discovery and waves planning for accelerating VMware migrations.
To learn more, refer to these additional resources:
Relevant content
- asked 2 years agolg...
- asked a year agolg...
- Accepted Answerasked 2 years agolg...
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 7 months ago
- AWS OFFICIALUpdated 6 months ago
- AWS OFFICIALUpdated 2 years ago