Come posso risolvere i ritardi di replica o un backlog nel mio server di origine Linux utilizzando il Servizio di migrazione delle applicazioni?
Sono presenti ritardi o backlog nel mio server di origine Linux durante la replica dei dati utilizzando il Servizio di migrazione delle applicazioni AWS.
Breve descrizione
Di seguito sono riportati i fattori che contribuiscono al ritardo e al backlog della replica durante il processo di replica dei dati da un server di origine a un server di destinazione:
- Velocità di uplink di rete e disponibilità della larghezza di banda: La velocità della connessione di rete tra il server di origine e il server di replica potrebbe avere un impatto significativo sulle prestazioni di replica. Le connessioni lente potrebbero impedire il completamento del processo di replica. Inoltre, la larghezza di banda limitata limita la quantità di dati che è possibile replicare in un determinato momento.
- Modifiche al disco durante la replica: Durante il processo di replica, il server di origine potrebbe continuare a scrivere nuovi dati sui propri dischi. Se si registra un’elevata quantità di dati durante il processo di scrittura del server di origine, i dati si accumulano causando un backlog significativo. L'agente di replica AWS deve inviare questo backlog con la sincronizzazione iniziale. Maggiore è il backlog, maggiore è il tempo necessario per completare la replica dei dati.
- Velocità I/O dei dischi di archiviazione: Durante il processo di replica, l’agente di replica AWS legge i blocchi di archiviazione dei dischi e trasmette i dati al server di replica. Tuttavia, un'elevata latenza di lettura sui dischi del server di origine potrebbe influire sulla velocità e sull'efficienza della replica dei dati. I dischi lenti causano ritardi e i dischi veloci migliorano la velocità di replica.
- Caricamento sul server di origine: La disputa di risorse sul server di origine potrebbe comportare un elevato utilizzo della CPU, un consumo di memoria, tempi di attesa I/O o altri vincoli di risorse. Ad esempio, un elevato utilizzo della CPU potrebbe causare rallentamenti nella replica. Questo perché il sistema fatica ad allocare le risorse CPU tra l’agente di replica AWS e altri processi. Analogamente, un elevato consumo di memoria potrebbe indurre il sistema a sostituire le pagine di memoria su disco. Ciò comporta un aumento dell'attesa I/O e un rallentamento del processo di replica.
- Risorse di replica insufficienti: Lo staging di volumi Amazon Elastic Block Store (Amazon EBS) con velocità di trasmissione e IOPS inferiori potrebbe causare un'elevata latenza di lettura e scrittura e un'elevata lunghezza della coda. Tutti questi problemi influiscono sulle prestazioni di replica. Inoltre, un tipo di istanza di server di replica con una velocità di trasmissione di rete ridotta e una larghezza di banda Amazon EBS comporta problemi di prestazioni di replica.
Risoluzione
Per determinare il motivo alla base del ritardo, esegui innanzitutto dei controlli sul server di origine. Quindi, esegui i controlli sull'area di sosta.
Controlli del server di origine
Verificare che il server di origine sia avviato e funzionante
Assicurati che il server di origine per la migrazione sia avviato e funzionante.
Verificare che il server di origine sia in grado di stabilire una connessione SSL con l'endpoint API regionale del Servizio di migrazione delle applicazioni e il server di replica
Assicurati che i certificati SSL non vengano intercettati e modificati in nessun momento tra il server di origine e l'endpoint API del Servizio di migrazione delle applicazioni. Inoltre, assicurati che i certificati SSL non vengano intercettati e modificati tra il server di origine e il server di replica. Per fare ciò, esegui il seguente comando:
# echo -n | openssl s_client -connect mgn.<region>.amazonaws.com:443 # echo -n | openssl s_client -connect <replication server IP>:1500
Nota:Utilizza il comando elencato nella seguente sezione Verifica connessioni TCP attive per trovare l'indirizzo IP del server di replica.
Verifica che tutti i processi dell’agente di replica AWS siano in esecuzione
Esegui il seguente comando per elencare i servizi dell’agente di replica AWS in esecuzione:
# ps -u aws-replication
L'output seguente mostra i processi dell’agente di replica AWS che devono essere in esecuzione:
PID TTY TIME CMD 30878 ? 00:00:00 update_onprem_v 30879 ? 00:00:00 run_linux_migra 30880 ? 00:00:00 tailer 30881 ? 00:04:45 java 30902 ? 00:00:01 tailer 30904 ? 00:00:00 run_linux_migra 30905 ? 00:00:10 update_onprem_v 31023 ? 00:00:00 tail
Verifica le connessioni TCP attive
Esegui il comando seguente per verificare che vi siano cinque connessioni TCP attive stabilite con il server di replica sulla porta TCP 1500.
# sudo netstat -anp | awk '$5 ~ /:1500$/ {print}'
Controlla l'output del comando per le connessioni attive:
tcp6 0 0 172.31.1.39:54814 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54828 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54832 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54812 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54800 172.31.0.82:1500 ESTABLISHED 30881/java
Verifica l'utilizzo della CPU sul core della CPU dove è in esecuzione l’agente di replica AWS
L'agente di replica AWS è un processo a thread singolo che opera su un core della CPU alla volta. Se l'utilizzo della CPU è elevato nel core dove è in esecuzione l’agente di replica AWS, la replica dei dati rallenta.
1. Esegui i seguenti comandi, quindi rivedi l'output per determinare quanto segue:
- L'ID del processo di AWS Replication Agent.
- Il core della CPU (indicato da** psr**) su cui è in esecuzione.
# ps --pid $(pidof /var/lib/aws-replication-agent/jre/bin/java) -o psr,pid,comm # mpstat -P <psr column value> 3
2. Quindi, controlla l'utilizzo della CPU del core identificativo della CPU.
Verifica le prestazioni del disco sul server di origine
Se la velocità di lettura (RMB/s) è bassa sui dischi di origine, vengono letti e replicati meno dati. Prendi nota di qualsiasi aumento delle metriche di profondità I/O (avgqu-sz) e di attesa I/O. È possibile utilizzare gli strumenti** sar** o** iostat** per misurare la velocità di lettura del disco:
# iostat -myx 3 # sar -dp 2
Verificare che il server di origine non presenti un dato di picco nelle operazioni di write
Un picco nelle operazioni di write nel server di origine potrebbe causare un aumento del ritardo di replica. Questa crescita continua fino a quando l’agente di replica AWS non scarica tutti i dati scritti sul server di replica. Esegui periodicamente il test** iostat** per determinare qual è il carico I/O quando cambia il carico di lavoro. Se la velocità di scrittura (WMB/s) supera la velocità di rete disponibile, si verifica un ritardo di replica.
**Nota:**Per calcolare la larghezza di banda richiesta dal server di origine al server di replica, vedere Calcolo della larghezza di banda richiesta per la porta TCP 1500.
Verifica la velocità di replica e la larghezza di banda disponibile dal server di origine alla sottorete dell'area di staging
1. Nella regione AWS di destinazione, avvia un'istanza di prova di Amazon Elastic Compute Cloud (Amazon EC2) utilizzando l'AMI CE-SSL-SpeedTest di pubblicazione. L'istanza EC2 deve essere dello stesso tipo di istanza del server di replica.
2. Seleziona la stessa sottorete utilizzata nelle impostazioni di replica del server di origine.
3. Assicurati che il gruppo di sicurezza consenta l'accesso in ingresso alla porta TCP 1500.
4. Sul server di origine, configura la CLI SpeedTest come mostrato nell'esempio seguente:
# cd /tmp # git clone https://github.com/librespeed/speedtest-cli.git # cd speedtest-cli/ # ls -l # ./build.sh # cat << EOF >> ./servers.json [ { "id": 1, "name": "PHP Backend", "server": "https://<test server private IP>:1500/speedtest/", "dlURL": "/garbage.php", "ulURL": "/empty.php", "pingURL": "/empty.php" } ] EOF
Nota:Nell'esempio precedente, assicurati di sostituire l'indirizzo IP del server di test. Se utilizzi l'IP pubblico del server di test per un test di velocità, includi “getIPurl”: "/getIP.php" dopo la riga** “pingURL”**.
5. Esegui la CLI di LibreSpeed come mostrato nell'esempio seguente per testare la velocità di replica:
# ./out/librespeed-cli-linux-amd64 —local-json ./servers.json —server 1 —no-icmp —skip-cert-verify —simple Ping: 11.00 ms Jitter: 0.00 ms Download rate: 503.84 Mbps Upload rate: 493.56 Mbps
Verifica la presenza di un server di origine che è stato chiuso senza garanzie
Se un server di origine viene chiuso in modo non corretto, l’agente di replica AWS esegue nuovamente la scansione di tutti i dischi dopo il riavvio del server. L’agente di replica AWS rilegge i dischi e il ritardo continua ad aumentare fino al completamento della nuova scansione. Per ulteriori informazioni, vedi Quali sistemi operativi Windows e Linux supportano il no-rescan al riavvio?
Verifica la presenza di un aggiornamento del kernel
Se il kernel viene aggiornato sul server di origine e il server viene riavviato, l'agente di replica AWS non viene eseguito. La versione del kernel in esecuzione corrisponde alla versione del kernel per cui è stato compilato il driver agente di replica AWS durante l'installazione dell'agente.
Esegui i seguenti comandi per verificare che la versione del kernel in esecuzione corrisponda alla versione del kernel per cui è stato compilato il driver agente di replica AWS:
$ uname -r $ modinfo -F vermagic /var/lib/aws-replication-agent/aws-replication-driver.ko
Nota:** vermagic** viene utilizzato per verificare in quale versione del kernel è stato compilato il driver del kernel.
Verifica che la porta TCP 1500 non sia bloccata in uscita
Assicurati che la porta TCP 1500 non sia bloccata in uscita dal server di origine al server di replica.
Esamina i registri dell'agente MGN
Ispeziona i log dell'agente MGN per eventuali problemi di connettività con il server di replica sulla porta TCP 1500. Inoltre, verifica la presenza di irregolarità nella replica che indicano una frequente perdita di connessione. Dopo aver identificato questi problemi, esamina la topologia di rete per approfondire ulteriormente.
Verifica che i dispositivi intermedi non abbiano un MTU inferiore
Verificare che nessuno dei dispositivi intermedi nel percorso di replica abbia un MTU inferiore. Un MTU inferiore riduce la velocità di replica e causa ritardi nel processo. È consigliabile mantenere una dimensione MTU costante durante tutto il percorso di replica. Se durante il processo un dispositivo ha un MTU inferiore, aggiornalo o sostituiscilo con un dispositivo MTU con valore più alto.
**Nota:**Se esegui la replica su Internet pubblico, assicurati che la dimensione MTU sia di 1500. 1500 è l’MTU più grande supportato da gateway Internet, peering e VPN. I frame Jumbo funzionano solo all'interno di Amazon Virtual Private Cloud (Amazon VPC) o AWS Direct Connect e hanno i propri limiti. Per ulteriori informazioni, consulta quanto segue:
Verificare che il limite di larghezza di banda di rete sia disattivata nelle impostazioni di replica sul server di origine
Il limite di larghezza di banda deve essere disattivato nelle impostazioni di replica del server di origine.
L'attivazione dei limiti di larghezza di banda nel server di origine limita la velocità di trasferimento dati di AWS Replication Agent. Ciò potrebbe comportare un ritardo costante o stagnante in caso di backlog sul server di origine. Per mantenere una larghezza di banda costante e limitata per il trasferimento dati, attiva la limitazione della larghezza di banda di rete.
Per verificare la limitazione della larghezza di banda, completa i seguenti passaggi:
1. Apri la console Servizio di migrazione delle applicazioni.
2. Scegli Server di origine, quindi seleziona il server di origine.
3. Scegli la scheda Impostazioni di replica.
3. Se la limitazione di banda ** è attivata, assicurati che il valore limitato sia uguale o superiore alla larghezza di banda richiesta per la replica dei dati. Per ulteriori informazioni, vedere la nota nella sezione precedente, Verificare che il server di origine non presenti un picco nelle operazioni di write**.
Controlli delle risorse dell'area di sosta
Verifica che la porta TCP 1500 non sia bloccata in ingresso
Assicurati che la porta TCP 1500 non sia bloccata in ingresso nei gruppi di sicurezza del server di replica.
**Nota:**È necessario completare i seguenti passaggi nella console Amazon Elastic Compute Cloud (Amazon EC2).
1. Apri la console Amazon EC2.
2. Seleziona il gruppo di sicurezza collegato all'istanza del replicatore.
3. Verificare che la porta TCP 1500 in ingresso sia consentita nel gruppo di sicurezza collegato.
Controlla la metrica NetworkIn CloudWatch
Se la metrica** NetworkIn** Amazon CloudWatch per il server di replica si avvicina al limite di larghezza di banda, potrebbe verificarsi una limitazione. La limitazione comporta una velocità di replica più lenta e un aumento del ritardo. Prendi in considerazione l'aggiornamento a un tipo di istanza più grande in grado di gestire la larghezza di banda richiesta.
Verifica il la velocità di trasmissione aggregata e gli IOPS dei volumi EBS del server di replica
Le prestazioni del server di replica potrebbero essere limitate se la velocità di trasmissione aggregata e gli IOPS dei volumi Amazon Elastic Block Store (Amazon EBS) superano i limiti. Se si verifica una limitazione, passa a un tipo di istanza del server di replica che soddisfi le tue esigenze di replica e mantenga le prestazioni senza limitazioni. È consigliabile utilizzare un tipo di istanza ottimizzato per EBS di attuale generazione per i server di replica. Nelle istanze senza supporto per la velocità effettiva ottimizzata per EBS, il traffico di rete si scontra con il traffico tra l'istanza e i volumi EBS. Nelle istanze ottimizzate per EBS, i due tipi di traffico vengono mantenuti separati. Monitora la rete del server di replica e le metriche di EBS CloudWatch. Per ulteriori informazioni, consulta quanto segue:
Monitora le metriche per tutti i volumi EBS di replica
Il ritado e il backlog si accumulano quando la velocità di scrittura del volume del server di replica non può corrispondere alla velocità di variazione sul server di origine. Per evitare ritardi nella replica, utilizza un tipo di volume più veloce con IOPS e larghezza di banda più elevati. Per prestazioni ottimali, prestazioni dei volumi EBS, è consigliabile monitorare le metriche di CloudWatch per ogni volume EBS di replica.
Verifica i volumi EBS creati da un'istantanea
I server di replica con volumi EBS creati da un'istantanea potrebbero avere una maggiore latenza delle operazioni di I/O al primo accesso a ciascun blocco. Questa latenza potrebbe causare un aumento o una stagnazione del ritardo fino al completamento del processo di nuova scansione. Per ulteriori informazioni, consulta Attenzione alla riduzione delle prestazioni durante l'inizializzazione dei volumi dalle istantanee.
Verifica la quota di istantanee nella regione di destinazione
Assicurati che il tuo account AWS non abbia raggiunto i limiti di quota di snapshot nella regione AWS in cui stai replicando i server di origine. Utilizza i seguenti comandi AWS Command Line Interface (AWS CLI) per verificare se hai raggiunto la quota di snapshot nella regione. Nell'esempio seguente, sostituisci la** regione** con la tua regione AWS di destinazione:
# aws service-quotas get-service-quota --service-code ebs --quota-code L-309BACF6 --region region --query "Quota.Value" # aws ec2 describe-snapshots --owner-ids self --region region --query "length(Snapshots)"
**Nota:**Se ricevi errori durante l'esecuzione dei comandi dell'interfaccia a riga di comando di AWS, assicurati di utilizzare la versione più recente dell'interfaccia a riga di comando di AWS.
Informazioni correlate
Contenuto pertinente
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata un anno fa