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à.
Ondate di migrazione, server e database
I progetti di migrazione iniziano con il seguente elenco di domande aperte, che sono comuni ai tre scenari descritti nella sezione precedente:
-
Come si possono creare ondate di migrazione?
-
Come si raggruppano i server all'interno di ogni ondata?
-
I server di database devono essere migrati prima dei server delle applicazioni o insieme?
-
Quale strumento dobbiamo utilizzare per le migrazioni di database?
Tuttavia, per rispondere a queste domande, dobbiamo prima chiarire alcune definizioni. Questa sezione della guida si concentra sul termine database e sul suo significato nel contesto delle ondate migratorie. Questa definizione è importante, perché la comprensione di quel termine potrebbe modificare l'approccio generale alla migrazione per particolari ondate di migrazione o addirittura modificare le ondate di migrazione spostando i server tra diverse ondate.
Il termine database descrive un server che esegue il software DBMS o il punto di ingresso del database logico? Si riferisce a uno di più database sul medesimo server o su un cluster di server? A seconda del contesto, un database può corrispondere a ciascuna delle opzioni. Gli amministratori di database (DBAs) di solito considerano i database logici, non i server fisici. Tuttavia, nel contesto della migrazione, in particolare delle lift-and-shift migrazioni su larga scala, un database corrisponde in genere a un server fisico o a un cluster di server.
La migrazione di un database deve essere allineata e associata all'applicazione con cui funziona, perché il database logico fa sempre parte dell'applicazione e delle sue dipendenze. Tuttavia, la posizione fisica del database logico in questione potrebbe variare. Ad esempio, potrebbe trovarsi su:
-
Un server fisico autonomo, senza la presenza di altri database.
-
Un server fisico autonomo collocato in colocation con altri database logici.
-
Un cluster di server fisici, come singolo database logico o come parte di un set più ampio di database che servono altre applicazioni.
La creazione della mappatura delle dipendenze per le ondate di migrazione è complicata se non esiste una chiara one-to-one dipendenza tra l'applicazione e i server di database, specialmente quando più database logici di applicazioni diverse sono collocati sullo stesso server fisico. Tali sistemi di database richiedono un approccio di ripiattaforma che implica la scomposizione o il consolidamento dei database, il che complica le operazioni di migrazione su larga scala. lift-and-shift
È qui che possono essere utili gli strumenti di migrazione dei database (come gli strumenti nativi dei fornitori del motore di database o di terze parti). Questi strumenti funzionano a livello di database logico anziché sull'approccio di replica a livello di AWS Application Migration Service blocco e possono spostare i dati o i database a livello logico tra server fisici e sedi. Questi strumenti nativi di migrazione dei database possono aiutarti a consolidare i database logici su un singolo server fisico. Possono anche fare il contrario: possono scomporre i database logici tra vari server di database fisici, allinearli con diverse applicazioni e distribuirli tra diverse ondate di migrazione.
