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à.
# Attività 2: definizione dei processi per l'identificazione, la raccolta e l'archiviazione dei metadati
Nell'attività precedente, avete convalidato i dati di discovery iniziali, le strategie di migrazione e i modelli di migrazione per una migrazione su larga scala. In questa attività, identifichi quali metadati sono necessari e decidi come raccoglierli. Questa attività prevede i seguenti passaggi:
+ [Fase 1: Definizione dei metadati richiesti](#metadata-1)
+ [Fase 2: Creazione dei processi di archiviazione e raccolta dei metadati](#metadata-2)
+ [Fase 3: Documenta i requisiti dei metadati e i processi di raccolta in un runbook](#metadata-3)
Durante il completamento dei passaggi di questa sezione, considera l'intero ciclo di migrazione dal punto di vista dei metadati. Prendi in considerazione la valutazione del portafoglio, la pianificazione ondata, la migrazione, i test e le attività post-cutover, quindi analizza tutti i possibili casi d'uso e i casi d'uso correlati. Pensare alle informazioni necessarie per completare l'intero processo di migrazione aiuta a identificare tutti i metadati relativi a quel modello.
## Fase 1: Definizione dei metadati richiesti
Prima di poter determinare gli attributi dei metadati richiesti, è necessario comprendere il modello di migrazione. Ad esempio, sono necessari metadati diversi per la migrazione di un server su Amazon EC2 e per la migrazione di un database su Amazon RDS. La maggior parte dei modelli è costituita da molte piccole attività. Per eseguire il modello di migrazione, è necessario conoscere gli attributi dei metadati richiesti e quindi raccogliere i metadati per quell'applicazione. È necessario determinare e raccogliere i metadati richiesti nella fase di inizializzazione in modo da poter eseguire la migrazione in modo efficiente e senza ritardi nella fase di implementazione.
La persona o il team che definisce gli attributi dei metadati inizia definendo i passaggi e le attività necessari per eseguire il modello di migrazione. Le attività determinano quali metadati sono necessari, quindi l'elaborazione di ciascuna attività crea una raccolta completa dei metadati richiesti. La persona che determina quali metadati sono necessari in genere deve avere una comprensione completa di come completare il modello di migrazione. Potrebbe essere necessario il coordinamento con la persona che redige il manuale sulla migrazione. Per ulteriori informazioni, consulta il [manuale sulla migrazione per migrazioni di AWS grandi dimensioni](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/).
Durante una migrazione su larga scala, ci sono molti processi distribuiti su tutti i flussi di lavoro che dipendono dai metadati. La disponibilità di metadati tempestivi e accurati ha un impatto ampio e significativo sul successo di una migrazione su vasta scala.
In questo passaggio, si definisce il modello o l'attività e quindi si utilizza la definizione per identificare i metadati richiesti.
### Identifica i componenti chiave dei modelli di migrazione e delle attività di supporto
In questo passaggio, per ogni modello di migrazione o attività di supporto, si definiscono i componenti chiave, come l'azione, l'oggetto di origine, l'oggetto di destinazione e gli strumenti utilizzati. Quindi assegnate un nome al modello o all'attività in base alle vostre risposte.
Le *attività di supporto* includono le attività operative che il portfolio e i flussi di lavoro di migrazione devono svolgere durante la migrazione, come la pianificazione delle fasi, la prioritizzazione delle applicazioni, l'analisi delle dipendenze, la governance, il disaster recovery, i test delle prestazioni o i test di accettazione da parte degli utenti. Poiché sono necessari metadati per supportare queste attività, è necessario eseguire questi passaggi sia per i modelli di migrazione che per le attività di supporto.
1. **Azione**: identifica la strategia di migrazione o l'attività di supporto. Ricorda che a un'azione potrebbero essere associate altre azioni. Ad esempio, potresti voler definire le operazioni per la migrazione. Le azioni di esempio includono:
+ Strategia di migrazione, come il rehosting, la ripiattaforma o il trasferimento
+ Pianificazione delle ondate
+ Prioritizzazione delle applicazioni e analisi delle dipendenze
+ Operation
+ Governance
+ Ripristino di emergenza
+ Test, ad esempio test delle prestazioni o test di accettazione degli utenti (UAT)
1. **Oggetto di origine**: identifica l'oggetto di origine su cui verrà eseguita l'azione. Gli oggetti di origine di esempio includono:
+ Onde
+ Server
+ Database
+ Condivisione di file
+ Applicazione
1. **Strumenti**: identifica i servizi o gli strumenti utilizzati per eseguire l'azione. È possibile utilizzare più di uno strumento o servizio. Gli strumenti di esempio includono:
+ AWS Application Migration Service
+ AWS DataSync
+ AWS Database Migration Service (AWS DMS)
+ AWS Backup
+ Strumenti di monitoraggio delle prestazioni
1. **Oggetto di destinazione**: identifica l'oggetto, il servizio o la posizione di destinazione in cui risiederà l'origine al termine dell'azione. Gli oggetti, i servizi o le posizioni di esempio includono:
+ Amazon Elastic Compute Cloud (Amazon EC2)
+ Amazon Relational Database Service (Amazon RDS)
+ Amazon Elastic File System (Amazon EFS)
+ Amazon Elastic Container Service (Amazon ECS)
+ Piano ondulatorio
1. **Nome del pattern**: combina le risposte ai passaggi precedenti come segue:
on/to utilizzando
Di seguito vengono mostrati gli esempi:
+ Reospita onde, applicazioni o server (oggetto di origine) su Amazon EC2 (oggetto di destinazione) utilizzando Application Migration Service o Cloud Migration Factory (strumenti)
+ Ripiattaforma (azione) delle condivisioni di file (oggetto di origine) su Amazon EFS (oggetto di destinazione) utilizzando DataSync (strumento)
+ Ripiattaforma (azione) dei database (oggetto di origine) su Amazon RDS (oggetto di destinazione) utilizzando AWS DMS (strumento)
+ Monitoraggio delle prestazioni (azione) delle applicazioni (oggetto di origine) su Amazon EC2 (oggetto di destinazione) utilizzando Amazon CloudWatch (strumento)
+ Server di backup (azione) (oggetto di origine) su Amazon EC2 (oggetto di destinazione) utilizzando AWS Backup (strumenti) dopo la migrazione
+ Ondate di pianificazione ondulatoria (azione), applicazioni o server (oggetto di origine) per creare un piano d'onda (oggetto di destinazione)
Di seguito è riportato un esempio di come è possibile registrare *Pattern 1: Rehost su Amazon EC2 utilizzando Application Migration Service o Cloud Migration Factory dalla tabella* [dei modelli di migrazione](discovery.md#migration-patterns).
****
| | |
| --- |--- |
| **Pattern ID** | 1 |
| **Pattern name** | Rehosting su Amazon EC2 utilizzando Application Migration Service o Cloud Migration Factory |
| **Action** | Rehost della migrazione |
| **Source object** | Waves, applicazioni o server |
| **Tools** | Servizio di migrazione delle applicazioni o Cloud Migration Factory |
| **Target object** | Amazon EC2 |
### Determina i metadati richiesti per ogni modello o attività
Dopo aver definito lo schema o l'attività, è possibile determinare i metadati necessari per l'oggetto di origine, l'oggetto di destinazione, gli strumenti e altre informazioni aziendali. Per spiegare questo processo, questo playbook utilizza *Pattern 1: Rehost to Amazon EC2 utilizzando Application Migration Service o Cloud Migration* Factory dalla tabella [dei modelli di migrazione](discovery.md#migration-patterns) come esempio. Tieni presente che per alcuni modelli o attività, alcuni passaggi potrebbero non essere applicabili.
1. **Analizza l'oggetto di destinazione**: partendo dall'oggetto di destinazione a ritroso, crea manualmente l'oggetto e identifica i metadati necessari per supportarlo. Acquisite i metadati come illustrato nella tabella seguente.
Ad esempio, quando crei un'istanza EC2, devi scegliere un tipo di istanza, tipo di archiviazione, dimensione di archiviazione, sottorete, gruppo di sicurezza e tag. La tabella seguente include esempi di attributi di metadati che potrebbero essere necessari se l'oggetto di destinazione è un'istanza EC2.
****
[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)
1. **Analizza gli strumenti**: utilizza lo strumento per creare un oggetto target e verificare le differenze. Acquisite i metadati specifici dello strumento come illustrato nella tabella seguente e rimuovete gli attributi dalla tabella precedente se non sono supportati dallo strumento di migrazione. Ad esempio, non è possibile personalizzare il tipo di sistema operativo e le dimensioni di archiviazione per Application Migration Service perché lo strumento di migrazione rehost lo è. like-for-like Pertanto, è possibile rimuovere il sistema operativo di destinazione e la dimensione del disco di destinazione se questi attributi fossero inclusi nella tabella precedente. Nella tabella di esempio precedente, tutti gli attributi sono supportati dallo strumento, quindi non è richiesta alcuna azione.
La tabella seguente include esempi di metadati che potrebbero essere necessari per gli strumenti.
****
[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)
1. **Analizza l'oggetto di origine**: determina i metadati richiesti per l'oggetto di origine valutando le azioni come segue:
+ Per migrare i server, è necessario conoscere il nome del server di origine e il nome di dominio completo (FQDN) per connettersi al server.
+ Per migrare le applicazioni insieme ai relativi server, è necessario conoscere il nome dell'applicazione, l'ambiente dell'applicazione e la mappatura. application-to-server
+ Per eseguire una valutazione del portafoglio, assegnare priorità alle applicazioni o definire un gruppo di trasferimento, è necessario conoscere la mappatura, la application-to-server mappatura e le dipendenze. application-to-database application-to-application
+ Per gestire le onde, è necessario conoscere l'ID dell'onda e gli orari di inizio e fine dell'onda.
La tabella seguente include esempi di metadati che potrebbero essere necessari per l'oggetto di origine.
****
[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)
1. Prendi in **considerazione altri attributi**: oltre all'azione principale, considera altre azioni e attributi relativi all'oggetto o all'applicazione di destinazione. Per il pattern di esempio, *Pattern 1: Rehost to Amazon EC2 utilizzando Application Migration Service o Cloud Migration* Factory, l'azione è rehost e l'oggetto di destinazione è Amazon EC2. Altre azioni correlate per questo oggetto di destinazione potrebbero includere il backup su Amazon EC2, il monitoraggio dell'istanza EC2 dopo la migrazione e l'utilizzo di tag per gestire i costi associati all'istanza EC2. Potresti anche prendere in considerazione altri attributi dell'applicazione che ti aiutano a gestire la migrazione, ad esempio il proprietario dell'applicazione, che potresti dover contattare per domande o per ulteriori informazioni.
La tabella seguente include esempi di metadati aggiuntivi di uso comune. Questa tabella include i tag per l'istanza EC2 di destinazione. Per ulteriori informazioni sui tag e su come utilizzarli, consulta [Etichettare le risorse Amazon EC2 nella documentazione](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) di Amazon EC2.
****
[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)
1. **Crea una tabella**: combina tutti i metadati identificati nei passaggi precedenti in un'unica tabella.
****
[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)
1. **Ripeti**: ripeti questo processo finché non hai documentato i metadati richiesti per ogni pattern.
## Fase 2: Creazione dei processi di archiviazione e raccolta dei metadati
Nel passaggio precedente, hai definito i metadati necessari per supportare la migrazione. In questo passaggio, si crea un processo per la raccolta e l'archiviazione dei metadati. Questo passaggio consiste in due attività:
1. Analizza i metadati richiesti nel passaggio precedente e identifica la fonte.
1. Definite un processo per archiviare e raccogliere i metadati in modo efficiente.
### Analizza le fonti di metadati
Esistono molte fonti di metadati comuni. Di solito, la prima cosa a cui si può accedere è un inventario degli asset di alto livello, che viene in genere esportato da un database di gestione della configurazione (CMDB) o da un altro strumento esistente. Tuttavia, è necessario raccogliere i metadati anche da altre fonti, utilizzando processi automatici e manuali.
La tabella seguente contiene le fonti comuni, il processo di raccolta standard per quella fonte e i tipi di metadati comuni che puoi aspettarti di trovare da quella fonte.
****
| Fonte di metadati | Tipo di raccolta | Tipo di metadati |
| --- | --- | --- |
| Strumenti di scoperta | Automatizzato | Server di origine |
| CMDB | Automatizzato | Server di origine |
| Inventario di altri strumenti, ad esempio [RVTools](https://www.robware.net/)per VMware vSphere | Automatizzato | Server di origine |
| Questionario per il proprietario dell'applicazione | Manuale | Server di origine, server di destinazione, wave |
| Intervista al proprietario dell'applicazione | Manuale | Server di origine, server di destinazione, wave |
| Documentazione sulla progettazione dell'applicazione | Manuale | Server di destinazione |
| Documentazione sulla progettazione della zona di atter | Manuale | Server di destinazione, strumenti |
Dopo aver elencato tutte le possibili fonti dei metadati, analizzi il tipo di metadati e mappi ciascuna fonte agli attributi dei metadati identificati nel passaggio precedente.
1. Ottieni un elenco completo degli attributi dei metadati da. [Fase 1: Definizione dei metadati richiesti](#metadata-1)
1. Analizza ogni tipo di metadati e determina quali tipi non possono essere recuperati utilizzando un processo automatizzato. Si tratta in genere dei **metadati del server di destinazione** e dei tipi di **metadati wave**, poiché richiedono decisioni da parte dei proprietari delle applicazioni. Ad esempio, quale sottorete e gruppo di sicurezza utilizzerai per le istanze EC2 di destinazione?
1. Analizza ogni attributo di metadati e mappalo a una fonte di metadati nella tabella precedente. È comune avere una combinazione di più fonti. È possibile utilizzare gli strumenti di rilevamento per raccogliere alcuni metadati del server di origine. Per informazioni sull'utilizzo degli strumenti di rilevamento per raccogliere i metadati, consulta la Guida [introduttiva alla scoperta automatica dei portafogli](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/get-started-with-automated-portfolio-discovery.html) sul sito Web di AWS Prescriptive Guidance.
1. Crea una tabella per mappare l'attributo dei metadati al tipo e alla fonte. La tabella seguente è un esempio.
****
[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)
### Definisci un unico archivio di metadati
Dopo aver mappato ogni attributo di metadati alla relativa origine, definite dove archiviare i metadati. Indipendentemente da come e dove archiviate i metadati, dovete scegliere un solo repository. In questo modo avrete la certezza di disporre di un'unica fonte di verità. L'archiviazione dei metadati in più posizioni è un errore comune nelle migrazioni di grandi dimensioni.
#### Opzione 1: archivia i metadati in un foglio di calcolo in un archivio condiviso
Sebbene questa opzione possa sembrare un processo molto manuale, è l'archivio dati più comune per le migrazioni di grandi dimensioni. È inoltre comune archiviare il foglio di calcolo in un archivio condiviso, ad esempio un sito Microsoft. SharePoint
Un foglio di calcolo Microsoft Excel è facile da personalizzare e non richiede molto tempo per essere creato. Gli svantaggi sono che diventerà molto complesso se si dispone di molti metadati e che può essere difficile gestire le relazioni tra le risorse, ad esempio tra server, applicazione e database. L'altra sfida è la gestione delle versioni. È necessario limitare l'accesso in scrittura solo a poche persone oppure utilizzare un processo automatizzato per aggiornare il foglio di calcolo.
Nei [modelli di portfolio playbook](samples/portfolio-playbook-templates.zip), puoi utilizzare il *modello Dashboard per la pianificazione e la migrazione delle ondate* (formato Excel) come punto di partenza per creare il tuo foglio di calcolo per il tuo archivio dati.
#### Opzione 2: archivia i metadati in uno strumento appositamente progettato
È possibile utilizzare uno strumento predefinito, come [TDS Transition Manager](https://www.transitionaldata.com/software/) (sito Web TDS), per archiviare i dati oppure creare uno strumento personalizzato. Quando crei il tuo strumento, hai bisogno di tabelle di database proprio come le schede dei fogli di calcolo di Excel nell'opzione 1. Esempio:
+ Tabella del server
+ Tabella delle applicazioni
+ Tabella del database
+ Application-to-server e tabella di application-to-database mappatura
+ tabella di pianificazione delle onde
+ Tabella dei questionari per il proprietario dell'applicazione
### Definire i processi di raccolta dei metadati
Nei passaggi precedenti, avete mappato i metadati alla relativa origine e definito un data store in cui raccogliere i metadati. In questo passaggio, creerai processi per raccogliere efficacemente i metadati. È necessario ridurre al minimo il copy-and-paste processo manuale e utilizzare l'automazione per raccogliere i metadati da ciascuna fonte. Esistono tre passaggi:
1. Crea uno script di estrazione, trasformazione e caricamento (ETL) per ogni fonte di metadati in base alla tabella di mappatura dei metadati.
1. Crea un'attività pianificata che importi automaticamente i metadati da ciascuna fonte su base regolare.
1. Crea un processo di esportazione o fornisci l'accesso tramite API (Application Programming Interface) ai metadati archiviati nel repository.
La tabella seguente è un esempio degli attributi dei metadati raccolti da ogni script ETL. I metadati vengono archiviati nella posizione definita nella sezione precedente, ad esempio un foglio di calcolo o uno strumento appositamente creato.
****
| Attributo Metadata | Tipo di metadati | Fonte di metadati | Processo di raccolta |
| --- | --- | --- | --- |
| `app_name` | Applicazione di origine | CMDB | Script ETL — CMDB |
| `app_owner` | Applicazione di origine | CMDB | Script ETL — CMDB |
| `app_to_server_mapping` | Applicazione di origine | CMDB | Script ETL — CMDB |
| `app_to_DB_mapping` | Applicazione di origine | CMDB | Script ETL — CMDB |
| `app_to_app_dependencies` | Applicazione di origine | Strumento di scoperta | Script ETL: strumento di scoperta |
| `server_name` | Server di origine | CMDB | Script ETL — CMDB |
| `server_FQDN` | Server di origine | CMDB | Script ETL — CMDB |
| `server_OS_family` | Server di origine | CMDB | Script ETL — CMDB |
| `server_OS_version` | Server di origine | CMDB | Script ETL — CMDB |
| `disk_size` | Server di origine | Strumento di scoperta | Script ETL: strumento di scoperta |
| `instance_type` | Server di destinazione | Strumento di scoperta | Script ETL: strumento di scoperta |
| `target_subnet` | Server di destinazione | Questionario per il proprietario dell'applicazione | Script ETL: proprietario dell'applicazione |
| `target_security_group` | Server di destinazione | Questionario per il proprietario dell'applicazione | Script ETL: proprietario dell'applicazione |
| `AWS_Region` | Server di destinazione | Questionario per il proprietario dell'applicazione | Script ETL: proprietario dell'applicazione |
| `AWS_account_ID` | Server di destinazione | Questionario per il proprietario dell'applicazione | Script ETL: proprietario dell'applicazione |
| `Name` | Server di destinazione (tag) | Questionario per il proprietario dell'applicazione | Script ETL: proprietario dell'applicazione |
| `business_unit` | Server di destinazione (tag) | Questionario per il proprietario dell'applicazione | Script ETL: proprietario dell'applicazione |
| `cost_center` | Server di destinazione (tag) | Questionario per il proprietario dell'applicazione | Script ETL: proprietario dell'applicazione |
| `wave_ID` | Pianificazione delle onde | Questionario per il proprietario dell'applicazione | Script ETL: proprietario dell'applicazione |
| `wave_start_date` | Pianificazione delle onde | Questionario per il proprietario dell'applicazione | Script ETL: proprietario dell'applicazione |
| `wave_cutover_date` | Pianificazione delle onde | Questionario per il proprietario dell'applicazione | Script ETL: proprietario dell'applicazione |
## Fase 3: Documenta i requisiti dei metadati e i processi di raccolta in un runbook
In questa attività, documentate le vostre decisioni in un runbook di gestione *dei metadati*. Durante la migrazione, il flusso di lavoro del portfolio aderisce a questo runbook come procedura standard per la raccolta e l'archiviazione dei metadati.
1. Nei [modelli di playbook del portfolio](samples/portfolio-playbook-templates.zip), apri il *modello Runbook per la gestione dei metadati (formato* Microsoft Word). Questo serve come punto di partenza per creare il proprio runbook.
1. Nella sezione *Attributi dei metadati*, create una tabella degli attributi dei metadati per ogni modello di migrazione e compilate le tabelle con gli attributi dei metadati identificati in. [Fase 1: Definizione dei metadati richiesti](#metadata-1)
1. Nella sezione *Posizioni di origine*, documenta le fonti in cui ti sei identificato. [Analizza le fonti di metadati](#metadata-2-source)
1. Nella sezione *Istruzioni di accesso alla posizione di origine*, documenta i passaggi che un utente deve seguire per accedere alle posizioni delle fonti dei metadati.
1. Nella sezione *Archivio metadati*, documenta i passaggi che un utente dovrebbe seguire per accedere all'archivio di metadati in cui hai creato. [Definisci un unico archivio di metadati](#metadata-2-store)
1. Nella sezione *Tipi di raccolta dati*, identifica il processo di raccolta dei dati che utilizzerai per ciascuna fonte di metadati. Idealmente, dovresti automatizzare tutta la raccolta di metadati utilizzando script di automazione.
1. Nella sezione *Raccolta dati tramite attributo di metadati, per ogni attributo* di metadati, identifica quanto segue in base alle istruzioni contenute in: [Definire i processi di raccolta dei metadati](#metadata-2-collection)
1. Tipo di metadati
1. Fonte di metadati
1. Archivio di metadati
1. Tipo di raccolta
1. Nella sezione *Raccogli metadati*, aggiorna il processo in base alle esigenze del tuo caso d'uso. Questo è il processo seguito da Portfolio Workstream nella fase di implementazione, quando raccoglie i metadati per le ondate.
1. Verifica che il runbook sia completo e accurato. Questo runbook dovrebbe essere una fonte di verità durante la migrazione.
1. Condividi il manuale di gestione dei metadati con il team affinché lo riveda.
## Criteri di uscita dall'attività
Passa all'attività successiva dopo aver completato quanto segue:
+ Hai preparato un unico repository per archiviare i metadati raccolti.
+ Nel tuo runbook di gestione dei metadati, hai definito e documentato quanto segue:
+ Gli attributi dei metadati richiesti per ogni modello di migrazione
+ Fonti di metadati e istruzioni dettagliate su come accedere a ciascuna fonte
+ L'archivio dei metadati e istruzioni dettagliate su come accedervi
+ I processi utilizzati per raccogliere i metadati
+ Una tabella di mappatura che mappa gli attributi dei metadati alle fonti di metadati e ai processi di raccolta