AWS drs documentation change
Summary
Restructured troubleshooting documentation by removing detailed error resolution content and replacing it with section links to dedicated troubleshooting sub-pages (Agent Issues, Communication Errors, etc.). Added concise introduction and standardized navigation.
Security assessment
The changes reorganize existing troubleshooting content into linked sub-sections without introducing new security-related information. Removed content about port configurations/IAM was standard operational guidance rather than security vulnerability remediation. No evidence of addressing exploits or vulnerabilities.
Diff
diff --git a/drs/latest/userguide/troubleshooting.md b/drs/latest/userguide/troubleshooting.md index 9d1fcf54d..6e43c01a3 100644 --- a//drs/latest/userguide/troubleshooting.md +++ b//drs/latest/userguide/troubleshooting.md @@ -5,2 +4,0 @@ -Troubleshooting Failback ErrorsTroubleshooting Communication ErrorsTroubleshooting Agent IssuesCommon replication errorsOther troubleshooting topics - @@ -9,406 +7 @@ Troubleshooting Failback ErrorsTroubleshooting Communication ErrorsTroubleshooti -## Troubleshooting Failback Errors - -###### Topics - - * Error – Could not associate failback client to recovery instances - - * Error – Could not verify recovery instance connectivity to DRS - - * Error message: AWS Replication agent is not connected to DRS. Verify the agent is installed and running, and that it has connectivity to the service - - * Error message: botocore.exceptions.CredentialRetrievalError: Error when retrieving credentials from cert - - * Error message: Some Recovery instances could not be processed: recovery-instance-id - - - - -### Error – Could not associate failback client to recovery instances - -If you see the "Could not associate failback client to recovery instances" error when using the Failback Client, that may mean that you associated the incorrect credentials with your User. Ensure that you attach the **AWSElasticDisasterRecoveryFailbackInstallationPolicy** policy to the user or role and restart the failback process. [Learn more about Failback Client credentials.](./failback-performing.html#failback-performing-credentials) - -### Error – Could not verify recovery instance connectivity to DRS - -If you see the "Could not verify recovery instance connectivity to Elastic Disaster Recovery" error when using the Failback Client, you should troubleshoot potential connectivity issues: - - 1. Make sure that the agent on the recovery instance is activated and running. - - 2. A public IP must be set on the recovery instance in Amazon EC2. - - 3. TCP Port 443 outbound must be open on the recovery instance for the pairing to succeed. - - 4. Make sure that you don't have this error in your agent logs: Error – driver was compiled for a different kernel not loading. - - - - -### Error message: AWS Replication agent is not connected to DRS. Verify the agent is installed and running, and that it has connectivity to the service - -In certain cases, following an attempt to perform a reverse replication action, you will receive an error message indicating that the AWS Replication agent is not connected to AWS Elastic Disaster Recovery. In this case, verify that: - - 1. The agent is installed and running - - 2. The server is connected to the internet or the NAT gateway - - - - -If after performing the steps above you did not identify any agent or connectivity issues, reinstall the agent as recovery instance and try again. - -### Error message: botocore.exceptions.CredentialRetrievalError: Error when retrieving credentials from cert - -The Failback Client uses Amazon Linux 2 (AL2) and leverages certificate-based authentication to AWS Elastic Disaster Recovery endpoints for certain actions. AL2 assumes that the hardware clock time provided from the underlying hardware or hypervisor is UTC, which can result in time skew if it is not. Ensure that the time configured within the BIOS or EFI Shell of the failback target is set to UTC, and not LocalTime. - -### Error message: Some Recovery instances could not be processed: `recovery-instance-id` - -You may receive this error when attempting to start reverse replication in Elastic Disaster Recovery. The error occurs when: - - * The **Launch into source instance** setting is enabled in the source Region's default launch settings. - - * Source Amazon EC2 instance/A1 is missing the required tag `AWSDRS:AllowLaunchingIntoThisInstance`. - - - - -Resolve this issue by: - - * Disabling the **Launch into source instance** in the source Region's default launch settings. - - * Adding the `AWSDRS:AllowLaunchingIntoThisInstance` tag to the source Amazon EC2 instance/A1. - - - - -## Troubleshooting Communication Errors - -###### Topics - - * Solving Communication Problems over TCP Port 443 between the staging area and the Elastic Disaster Recovery Service Manager - - * Calculating the required bandwidth for TCP Port 1500 - - * Verifying Communication over Port 1500 - - * Solving Communication Problems over Port 1500 - - - - -### Solving Communication Problems over TCP Port 443 between the staging area and the Elastic Disaster Recovery Service Manager - - * **DHCP** – [Check the DHCP options set of the VPC of the staging area.](http://docs.aws.amazon.com/directoryservice/latest/admin-guide/dhcp_options_set.html) - -Ensure that the IPv4 CIDR, the DHCP options set, the Route table, and the Network ACL are correct. - - - - - * **DNS** – Ensure that you are allowing outbound DNS resolution and connectivity over TCP Port 443. - - - - - * **Route Rules** – the Route Rules on the Staging Area subnet may be inaccurately set. The Route Rules should allow outbound traffic to the Internet. - -To check and set the Route Rules on the staging area subnet: - - 1. Sign in to [AWS console](https://console.aws.amazon.com/), click on **Services** and select **VPC** under **Networking & Content Delivery**. - - - - 2. On the **VPC Dashboard** toolbar, select the **Route Tables** option. - - - - 3. On **Route Tables** page, check the box of the Route Table of your staging area. - - - - 4. This will open the details for your Route Table. Navigate to the **Routes** tab. - - - - 5. Within the **Target** column of the **Routes** tab, find the route you are using for the outbound communication to the Internet (either **igw** – Internet Gateway, vgw – **VPN** or **i** – EC2 instance). Verify that the address space in the Destination column is covering the AWS Elastic Disaster Recovery IPs and URLs. - -**Note** : AWS Elastic Disaster Recovery AWS-specific IPs and URLs include: 52.72.172.158, 52.53.92.136, s3.amazonaws.com, s3.us-west-1.amazonaws.com, s3.eu-west-1.amazonaws.com and outbound access to the [Amazon EC2 endpoint of the AWS Region. ](https://docs.aws.amazon.com/general/latest/gr/rande.html) - - - - 6. If the address is not **0.0.0.0/0** , you will need change it to **0.0.0.0/0.** - -Click the **Edit** button. - - - - 7. Input **0.0.0.0/0** into the Destination field for the correct **Target**. Click **Save**. - -**Note** : If you are using VPN, enter a specific IP address range in the **Destination** column. - - - - - * **Network ACL** – The network ACL on the staging area subnet may block the traffic. Verify that the ephemeral ports are open. - - - - -### Calculating the required bandwidth for TCP Port 1500 - -The required bandwidth for transferring the replicated data over TCP Port 1500 should be based on the write speed of the participating Source machines. The recommended bandwidth should be at least the sum of the average write speed of all replicated source machines. - -_Minimal bandwidth = the sum of the write speed of all Source machines_ - -For example, suppose you are replicating two Source machines. One has a write speed of 5 MBps (meaning it 5 megabytes of data every second), while the other has 7 MBps. In this case, the recommended bandwidth should be at least 12 MBps. - -#### Finding the Write Speed of Your source servers - -To calculate the required bandwidth for transferring replicated data over TCP Port 1500, you need to know the write speed of your source machines. Use the following tools to find the write speed of your source servers: - -##### Linux - -Use the iostat command-line utility, located in the systat package. The iostat utility monitors system input/output device loading and generates statistical reports. - -The iostat utility is installed with yum (RHEL/CentOS), via [apt-get ](https://www.howtoforge.com/tutorial/how-to-install-and-use-iostat-on-ubuntu-1604/) (Ubuntu), and via [zypper ](https://unix.stackexchange.com/questions/281094/install-iotop-iostat-via-zypper-or-anything-else-on-a-suse-sles-12-virual-ma?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa) (SUSE). - -To use iostat for checking the write speed of a Source machine, enter the following: iostat -x <interval> - - * -x - displays extended statistics. - - * <interval> – the number of seconds iostat waits between each report. Each subsequent report covers the time since the previous report. - - - - -For example, to check the write speed of a machine every 3 seconds, enter the following command: - -iostat -x 3 - -We recommend that you run the iostat utility for at least 24 hours, since the write speed to the disk changes during the day, and it will take 24 hours of runtime to identify the average running speed. - -##### Windows - -Install and use the DiskMon application. DiskMon logs and displays all hard disk activity on a Windows system. - -[Installing DiskMon ](https://docs.microsoft.com/en-us/sysinternals/downloads/diskmon) - -DiskMon presents read and write offsets are presented in terms of sectors (512 bytes). Events can be either timed for their duration (in microseconds), or stamped with the absolute time that they were initiated. - -### Verifying Communication over Port 1500 - -If there is a connection problem from the Source server to the Replication Servers or the Staging Area, use the following methods to check the connection. - -To verify the integrity of the connection from a Source server to the Staging Area over TCP Port 1500: