Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Best practice per la configurazione

Questa sezione fornisce una descrizione dettagliata dello scenario più restrittivo, in cui tutte le comunicazioni avvengono solo sul canale privato, e include una spiegazione dettagliata dei requisiti e dei componenti corrispondenti da creare per ciascuna area.

Questa sezione descrive la configurazione per lo scenario più restrittivo (replica solo su reti private), come illustrato nel primo diagramma, sulla base delle considerazioni discusse in precedenza. È possibile configurare entrambi gli scenari ibridi ignorando alcune parti della configurazione più restrittiva:

Le sezioni seguenti presuppongono che la configurazione iniziale di MGN sia già completa, come descritto nei post del blog (Accelerare la migrazione con AWS Transform MGN e Come utilizzare le novità per le migrazioni). AWS Transform MGN Lift-and-Shift Questa discussione si concentra sui componenti specifici dello scenario restrittivo e presuppone una sottorete di staging privata priva di connettività a Internet.

Sottoreti e configurazioni di routing

Per lo scenario restrittivo, si configurano AWS le risorse richieste nella sottorete privata di un VPC di staging. Questa sottorete non dispone di connettività a Internet (non esiste un gateway Internet collegato alla tabella di routing come route predefinita). Utilizza invece un gateway virtuale associato a un AWS Site-to-Site VPNgateway (connesso tramite un tunnel IPSec a un gateway locale) oppure è connesso a un gateway di trasferimento o a Direct Connect servizi per fornire l'interconnettività privata ai data center locali.

Utilizzerai quella sottorete privata come sottorete di staging per le risorse relative alla replica gestite da Application Migration Service e configurerai tutti gli accessi alla rete richiesti tramite questa sottorete utilizzando gli endpoint VPC, come illustrato nella sezione successiva.

Configurazione degli endpoint VPC

Ora è necessario creare endpoint VPC nella sottorete di staging per fornire connettività ai server di replica e agli agenti MGN dalle sottoreti locali.

Ecco un elenco completo degli endpoint VPC di cui hai bisogno:

Le sezioni successive approfondiscono il funzionamento degli endpoint VPC. La tabella seguente elenca tutti gli endpoint creati per la sottorete privata di staging. (Tieni presente che l'endpoint gateway Amazon S3 non dispone di interfacce di rete, ma dispone di elenchi di prefissi specifici inseriti nella tabella di routing della sottorete, come verrà descritto più avanti in questa guida.)

È possibile creare endpoint VPC opzionali per consentire l'accesso alle istanze EC2 su sottoreti private isolate tramite, AWS Systems Manager come discusso nella sezione Creazione di endpoint VPC nella documentazione di Systems Manager.

Endpoint dell'interfaccia VPC

La creazione di un endpoint di interfaccia crea anche un'interfaccia elastica di rete specifica per ogni sottorete per cui viene fornito l'endpoint di interfaccia specificato. Ad esempio, l'endpoint dell'interfaccia Application Migration Service viene fornito in una sottorete privata nel VPC di staging con un'interfaccia di rete elastica associata all'indirizzo IP all'interno di quella sottorete e dispone inoltre di tre nomi DNS risolvibili dalla sottorete a questo indirizzo IP:

Ciò consente a qualsiasi istanza in esecuzione nella sottorete che utilizza la configurazione predefinita del set di opzioni DHCP (Dynamic Host Configuration Protocol) nel VPC e che ha sia gli attributi enableDnsHostnames DNS che abilitati, di: enableDnsSupport

Ciò corregge la connettività per tutte le istanze in esecuzione nella sottorete di staging (come il server di replica MGN o il server di conversione) per tutte Servizio AWS le istanze con endpoint di interfaccia forniti nella sottorete (come Amazon EC2, MGN, Systems Manager e così via). AWS KMS

Endpoint gateway VPC

Per servizi come Amazon S3, non è possibile fornire alcun nome DNS fisso perché ogni bucket ha il proprio nome DNS. Per questo scenario utilizzerai gli endpoint gateway VPC. 

La creazione di un endpoint gateway Amazon S3 crea anche un oggetto elenco di prefissi specifico con un elenco di destinazioni di sottorete (in notazione CIDR), che può essere aggiunto nella tabella di routing della sottorete. Pertanto, i nomi DNS dei bucket S3 risolti in indirizzi IP inclusi in questo elenco sarebbero accessibili tramite connettività interna. 

Quando effettui il provisioning di un endpoint gateway Amazon S3, puoi specificare le sottoreti nelle tabelle di routing che devono includere quell'elenco di prefissi ID (). PL-<id> La tabella di routing risultante per la sottorete privata di staging deve includere l'ID dell'elenco di prefissi, come in questo esempio di tabella di route:

Endpoint DNS resolver in entrata

La configurazione descritta nella sezione precedente è sufficiente per le istanze in esecuzione all'interno delle AWS sottoreti, poiché sono già configurate per utilizzare server DNS interni di Amazon Route 53. Tuttavia, i server di origine locali richiedono passaggi aggiuntivi per poter comunicare in privato. Servizi AWS In particolare, MGN Agent deve scaricare il programma di installazione da Amazon S3 e quindi comunicare con MGN utilizzando i nomi DNS forniti nella documentazione. On-premises i server utilizzano i propri server DNS predefiniti per risolvere questi nomi DNS, generando indirizzi IP pubblici. Le comunicazioni con questi indirizzi sulla HTTPS/TCP porta 443 vengono infine bloccate dai firewall aziendali.

Per evitare ciò, è necessario configurare i server di origine o i relativi server DNS predefiniti da utilizzare Amazon Route 53 Resolverper la risoluzione di questi nomi DNS specifici o di una zona di sottodominio (ovvero la zona completa). *.<region>.amazonaws.com Questo può essere configurato creando un endpoint in ingresso Route 53 Resolver che, come un endpoint con interfaccia VPC, dispone di un'interfaccia elastica di rete dedicata creata nella sottorete privata dedicata su AWS, ed è quindi in grado di inoltrare le richieste DNS a. Amazon Route 53 Resolver 

Gruppi di sicurezza con interfaccia di rete elastica

A ogni interfaccia di rete elastica è associato un gruppo di sicurezza dedicato, che deve consentire il traffico previsto per questa interfaccia di rete elastica e l'endpoint corrispondente. Pertanto, il gruppo di sicurezza dell'endpoint DNS resolver dovrebbe consentire la porta UDP 53 in entrata (e talvolta la porta TCP 53) per le richieste DNS, mentre i gruppi di sicurezza degli endpoint per la maggior parte degli altri servizi (MGN, Amazon EC2, Systems Manager e così via) devono abilitare la porta in ingresso 443. HTTPS/TCP

Installazione di MGN Agent sui server di origine

Per installare MGN Agent sui server di origine, è necessario fornire i nomi DNS degli endpoint di interfaccia MGN e Amazon S3 ai parametri della riga di comando dell'agente (vedere Installazione dell'agente su una rete protetta nella documentazione MGN). 

Per l'endpoint MGN, puoi utilizzare uno qualsiasi dei nomi DNS ad esso associati, un campo DNS privato () o un nome DNS (mgn.<region>.amazonaws.com), e fornire un argomento:. VPC-specific vpce-<VPC-id>-<suffix>.mgn.<region>.vpce.amazonaws.com --endpoint <FQDN> In effetti, se si ignora questo argomento, l'agente utilizza il nome specificato Regione AWS per ricostruire il nome di dominio completo DNS predefinito (mgn.<region>.amazonaws.com) e utilizza il nome di dominio completo per accedere al piano di controllo dell'Application Migration Service. Nella maggior parte dei casi, questo comportamento predefinito dovrebbe essere sufficiente, a condizione che il nome di dominio completo venga risolto correttamente dal server di origine all'indirizzo IP privato dell'interfaccia di rete elastica per l'endpoint VPC MGN creato nella sottorete di staging. 

L'endpoint dell'interfaccia Amazon S3 non avrà un solo nome DNS privato (perché ogni bucket S3 avrà il proprio), quindi questa opzione non è supportata. Tuttavia, a un endpoint di interfaccia Amazon S3 è ancora associata un'interfaccia di rete elastica. Dispone inoltre di un IP privato specifico e di nomi DNS wildcard (nel formato o. .vpce-<VPC-ID>-<suffix>.s3.<region>.vpce.amazonaws.com Region-specific vpce-<VPC-ID>-<suffix>-<region>.s3.<region>.vpce.amazonaws.com) che sono risolvibili su questo IP privato.

Quel nome DNS con caratteri jolly può essere usato per l'--s3-endpointargomento, come nel seguente:

aws-replication-installer-init.py --region <region> --aws-access-key-id <MGN_IAM_ACCESS_KEY>  --aws-secret-access-key <MGN_IAM_SECRET> --no-prompt \
   --endpoint vpce-<VPC-id>-<suffix>.mgn.<region>.vpce.amazonaws.com --s3-endpoint vpce-<VPC-ID>-<suffix>-<region>.s3.<region>.vpce.amazonaws.com

La sezione successiva fornisce un esempio di configurazione di MGN, inclusi tutti gli endpoint VPC richiesti, e di distribuzione degli agenti utilizzando gli endpoint VPC su server di origine Windows e Linux. La sezione riguarda sia la distribuzione manuale che quella automatizzata.