Questo documento illustra la configurazione e l'esecuzione del processo di migrazione del database, inclusi gli scenari di errore. Il presente documento è la parte 2 di due parti. La Parte 1 introduce concetti, principi e terminologia della migrazione dei database con tempi di inattività prossimi allo zero per i Cloud Architect che devono eseguire la migrazione dei database in Google Cloud da ambienti on-premise o da altri ambienti cloud.
Configurazione della migrazione del database
Questa sezione descrive le diverse fasi di una migrazione dei database. Per prima cosa, configura la migrazione. Quindi, dopo aver completato la migrazione e aver eseguito il passaggio dei client ai database di destinazione, rimuovi i database di origine o, se necessario, implementa un piano di fallback a causa di problemi con la migrazione dopo il passaggio. Un elemento di riserva aiuta a garantire la continuità aziendale.
Durante la migrazione, devi prestare particolare attenzione a eventuali modifiche allo schema o ai dati che potrebbero essere introdotte. Per ulteriori informazioni sull'impatto che queste modifiche possono avere, consulta Modifiche dinamiche durante la migrazione più avanti in questo documento.
Specifica dello schema target
Per ogni sistema di database di destinazione, devi definire e creare il relativo schema. Per migrazioni dei database omogenee, puoi creare questa specifica più rapidamente esportando lo schema del database di origine nel database di destinazione, creando così lo schema del database di destinazione.
Il nome che assegni allo schema è importante. Un'opzione è associare i nomi degli schemi di origine e di destinazione. Tuttavia, sebbene questo semplifichi il passaggio tra i client, questo approccio potrebbe confondere gli utenti se gli strumenti si connettono contemporaneamente agli schemi del database di origine e di destinazione, ad esempio per confrontare i dati. Se astrai il nome dello schema utilizzando un file di configurazione, assegnare agli schemi del database di destinazione nomi diversi dall'origine semplifica la differenziazione degli schemi.
Con le migrazioni di database eterogenee, devi creare ogni schema di database di destinazione. Questo processo di progettazione può richiedere diverse iterazioni. Prima di poter implementare la migrazione, potrebbe essere necessario modificare ulteriormente gli schemi per adeguarsi al processo di migrazione ed eventuali modifiche ai dati.
Poiché probabilmente creerai database di destinazione più volte quando testi ed esegui la migrazione, il processo di creazione dello schema deve essere ripetibile (preferibilmente tramite script di installazione). Puoi utilizzare un sistema di gestione del codice per controllare la versione degli script, garantire la coerenza e accedere alla cronologia delle modifiche degli script.
Sematica della migrazione e dell'esecuzione delle query
Alla fine, dovrai trasferire i client dall'accesso ai sistemi di database di origine a quello ai sistemi di database di destinazione. Nelle integrazioni omogene dei database, le query possono rimanere invariate se gli schemi non vengono modificati. Sebbene i client debbano essere testati sui sistemi di database di destinazione, non è necessario modificarli a causa delle query.
Per le migrazioni di database eterogenei in generale, devi modificare le query perché gli schemi tra i database di origine e quelli di destinazione sono diversi. La differenza potrebbe essere una mancata corrispondenza del tipo di dati tra i database di origine e quelli di destinazione. Inoltre, non tutte le funzionalità del linguaggio di query disponibili nei sistemi del database di origine potrebbero essere disponibili nei sistemi di database di destinazione o al contrario. In casi estremi, potrebbe essere necessario convertire una query da un sistema di database di origine in più query sul sistema di destinazione. In uno scenario inverso, in cui nel database di destinazione sono disponibili più funzionalità di linguaggio di query rispetto all'origine, potrebbe essere necessario combinare diverse query del database di origine in una singola query sul database di destinazione corrispondente.
Anche la semantica delle query può variare. Ad esempio, alcuni sistemi di database materializzano un aggiornamento all'interno di una transazione immediatamente all'interno di quella transazione; di conseguenza, quando viene letto lo stesso elemento di dati, viene recuperato il valore aggiornato. Altri sistemi non materializzano immediatamente un aggiornamento e attendono che venga eseguito il commit della transazione. Se la logica nel sistema di database di origine si basa sulla scrittura materializzata, la stessa logica nel database di destinazione può causare dati errati o persino errori.
Se devi eseguire la migrazione delle query, devi testare tutte le funzionalità per assicurarti che il comportamento dei client sia lo stesso prima e dopo la migrazione. Puoi anche eseguire test a livello di dati, ma non sostituiscono quelli a livello di client. I client eseguono le query dal punto di vista della logica di business e possono essere testati solo a livello di logica di business.
Processi di migrazione
Per le migrazioni di database eterogenei, i processi di migrazione specificano in che modo i dati estratti dai sistemi di database di origine vengono modificati e inseriti nei database di destinazione. Le modifiche ai dati, come quelle descritte nella sezione Modifiche ai dati di questo documento, vengono definite ed eseguite mentre gli elementi di dati vengono estratti dai database di origine e trasferiti nei database di destinazione.
Con le migrazioni dei database omogenei, quando gli schemi dei database di origine e di destinazione sono equivalenti, non è necessaria la modifica dei dati. I dati vengono inseriti nei database di destinazione così come estratti dai database di origine.
A seconda del sistema di migrazione del database, potrebbero essere necessarie diverse configurazioni. Ad esempio, devi specificare se i dati da modificare e trasferire devono essere archiviati a intermittenza nel sistema di migrazione del database. L'archiviazione dei dati potrebbe rallentare il processo di migrazione complessivo, ma accelerare notevolmente il ripristino in caso di errore. Potrebbe essere necessario specificare il tipo di verifica. Ad esempio, alcuni sistemi di migrazione dei database eseguono query sui sistemi di origine e di destinazione per stabilire l'equivalenza del set di dati di cui è stata eseguita la migrazione fino al momento della query. La gestione degli errori richiede di specificare un comportamento di ripristino da errori. Anche in questo caso, questo requisito dipende dal sistema di migrazione del database in uso.
Inutile dire che devi testare la migrazione dei dati in modo dettagliato e ripetuto. Idealmente, la migrazione viene testata per garantire che venga eseguita la migrazione di ogni elemento di dati noto, che non si verifichino errori di modifica dei dati, che le prestazioni e la velocità effettiva siano sufficienti e che sia possibile completare la migrazione.
Processi di fallback
Durante una migrazione, i database di origine rimangono operativi (a meno che la migrazione non preveda tempi di inattività pianificati). Se in qualsiasi momento la migrazione del database non va a buon fine, puoi (nel peggiore dei casi) interromperla e reimpostare il database di destinazione allo stato iniziale. Una volta risolti gli errori, puoi riavviare la migrazione del database. L'errore e la risoluzione non interessano i sistemi di database di origine operativi.
Se si verificano errori dopo il completamento della migrazione del database e il passaggio dei client ai database di destinazione, il processo di errore e risoluzione potrebbe interessare i client, impedendo loro di funzionare correttamente. Nella migliore delle ipotesi, l'errore viene risolto rapidamente e il tempo di inattività per i clienti è breve. Nel peggiore dei casi, l'errore non viene risolto o la risoluzione richiede molto tempo, pertanto devi riportare i client ai database di origine.
Per riportare i client ai database di origine, devi eseguire la migrazione di tutte le modifiche ai dati nei database di destinazione ai database di origine. Puoi configurare ed eseguire questo processo come migrazione separata e completa del database. Tuttavia, poiché a questo punto i client sono non operativi nei database di destinazione, si verificheranno tempi di inattività significativi.
Per evitare tempi di inattività del client in questo scenario, devi avviare i processi di migrazione immediatamente dopo il completamento della migrazione originale del database. Ogni modifica applicata ai sistemi di database di destinazione viene applicata immediatamente ai sistemi di database di origine. Seguendo questo approccio, avrai la certezza che i sistemi di database di destinazione e quelli di origine siano sempre sincronizzati.
La preparazione di un fallback dai database di destinazione ai database di origine richiede uno sforzo significativo. È fondamentale decidere se implementare e testare i processi di fallback o comprendere le conseguenze di un mancato intervento, ovvero i tempi di inattività significativi.
Esecuzione della migrazione del database
L'esecuzione di una migrazione del database prevede cinque fasi distinte, descritte in questa sezione. Una sesta fase è un fallback, ma un fallback è un caso estremo e considerato un'eccezione a una normale esecuzione di migrazione del database.
Il processo discusso in questa sezione è una migrazione del database eterogenea con tempi di inattività prossimi allo zero. Se riesci a causare tempi di inattività significativi, puoi combinare le prime tre fasi (caricamento iniziale, continua migrazione e svuotamento) in un'unica fase utilizzando l'approccio di backup e ripristino o esportazione e importazione.
Una migrazione omogenea del database rappresenta un caso speciale. Con questo tipo di migrazione, puoi utilizzare la funzionalità di replica del sistema di gestione dei database (per i sistemi che la supportano) che esegue la migrazione dei dati mentre i sistemi di database di origine rimangono operativi.
Le fasi discusse qui delineano un approccio che potrebbe essere necessario modificare in base ai requisiti del processo di migrazione del database.
Fase 1: caricamento iniziale
Il punto di partenza è eseguire la migrazione di tutti i dati specificati per la migrazione da tutti i database di origine. All'inizio della migrazione dei dati, i database di origine hanno uno stato specifico, che cambia durante la migrazione.
Un suggerimento per avviare una migrazione mentre le modifiche avvengono contemporaneamente è annotare l'ora del sistema del database subito prima dell'estrazione del primo elemento di dati. Con questo timestamp, puoi ricavare tutte le modifiche al database dal log delle transazioni a partire da quel momento. Inoltre, il caricamento iniziale deve leggere uno stato del database coerente tra tutti i dati. Potrebbe essere necessario un blocco di breve durata sul database per evitare la lettura di un set di dati incoerente.
Questa fase prevede quanto segue:
- Annotazione dell'ora del sistema del database immediatamente prima dell'inizio della migrazione del database.
- Esecuzione di un processo di migrazione iniziale del carico che esegue una query sul set di dati (completo o parziale) dai database di origine di cui è necessario eseguire la migrazione e di migrazione del set di dati. In un modello di database relazionale, i processi di migrazione iniziale del carico eseguono query come
SELECT *o query con selezione, proiezione o entrambe. Il processo di migrazione esegue la modifica dei dati, come specificato nel processo.
Durante l'esecuzione dei processi di migrazione iniziali, i client in genere apportano modifiche ai database di origine. Poiché registri l'ora del sistema del database all'inizio, puoi ricavare le modifiche dal log delle transazioni in un secondo momento.
Il risultato della fase di caricamento iniziale è la migrazione completa del set di dati iniziale dai sistemi di database di origine ai sistemi di database di destinazione. Tuttavia, i database di origine e di destinazione non sono ancora sincronizzati perché è probabile che i client abbiano modificato i database di origine durante la migrazione. La fase 2 prevede l'acquisizione e la migrazione di queste modifiche.
Fase 2: continua la migrazione
Proseguire la migrazione ha due scopi. Prima legge le modifiche apportate nei database di origine dopo l'avvio del caricamento. In secondo luogo, acquisisce e trasferisce le modifiche nei database di destinazione.
Questa fase prevede quanto segue:
- Avvio dei processi di migrazione continuati dalla data/ora del sistema di database registrata nella fase 1. La migrazione legge il log delle transazioni da quel momento e applica ogni modifica al sistema di database di destinazione.
- Esecuzione di qualsiasi modifica ai dati. Il processo di migrazione esegue questo passaggio come specificato.
A volte le modifiche registrate dopo l'orario del sistema del database vengono trasferite durante il caricamento iniziale. Pertanto, è possibile che queste modifiche possano essere applicate una seconda volta durante la migrazione. Devi definire i processi di migrazione per assicurarti che le modifiche non vengano applicate due volte, ad esempio utilizzando gli identificatori. Supponi che un elemento di dati modificato venga trasferito durante il caricamento iniziale e questo inserimento sia registrato nel log delle transazioni. Applicando un identificatore all'elemento di dati, il sistema di migrazione può determinare dal log delle transazioni che non è necessario un altro inserimento in quanto l'elemento di dati esiste già.
Il risultato della fase di migrazione continua è che i database di destinazione sono completamente sincronizzati o quasi completamente sincronizzati con i database di origine. Quando non viene eseguita la migrazione di una modifica in un sistema di database di origine, hai un database quasi sincronizzato.
A seconda di come configuri il sistema di migrazione del database, le discrepanze possono essere piccole o grandi. Ad esempio, per aumentare l'efficienza, non tutte le modifiche devono essere migrate immediatamente, altrimenti puoi creare un carico elevato sull'origine in caso di variazioni al picco dell'origine. In generale, le modifiche vengono raccolte e migrate in batch come operazioni collettive. Con i batch più piccoli, si verificano meno discrepanze tra l'origine e la destinazione, ma l'origine può comportare un carico maggiore se vengono apportate modifiche di frequente.
Se la dimensione del batch è configurata in modo dinamico, è preferibile sincronizzare i batch di grandi dimensioni inizialmente nella fase di migrazione continua, quindi sincronizzare i batch di dimensioni gradualmente ridotte quando i database sono quasi raggiunti. Questo approccio rende più efficiente il processo di individuazione e riduce la discrepanza tra i database di origine e quelli di destinazione in un secondo momento.
Fase 3: svuotamento
Per preparare il passaggio dei client dal database di origine a quello di destinazione, devi assicurarti che i database di origine e quelli di destinazione siano completamente sincronizzati. Lo svuotamento è il processo di migrazione delle modifiche rimanenti dai database di origine ai database di destinazione.
Questa fase prevede quanto segue:
- Chiusura dei sistemi di database di origine. Ciò significa che nel database di origine non può essere apportata alcuna modifica ai dati e che il log delle transazioni non riceve voci di modifica aggiuntive.
- In attesa della migrazione di tutte le modifiche ai database di destinazione. Questo processo è l'effettivo svuotamento delle modifiche.
- Dopo il completamento dello svuotamento, esegui il backup dei database di destinazione in modo da avere un punto di partenza definito per i futuri backup incrementali.
Il risultato della fase di svuotamento è che i sistemi di database di origine e i sistemi di database di destinazione sono sincronizzati e non verranno apportate modifiche ai dati.
Per garantire che lo svuotamento sia completato, è possibile scrivere un elemento di dati "ultimo inserimento" in un database di origine. Una volta che l'"ultimo inserimento" viene visualizzato nel database di destinazione corrispondente, la fase di svuotamento è completa.
Fase 4: passaggio
Al termine della fase di svuotamento, puoi trasferire i client dall'origine ai database di destinazione. Consigliamo le seguenti best practice:
- Prima di abilitare l'accesso al database di produzione, testa le funzionalità di base per assicurarti che i client siano operativi e si comportino come previsto. Il numero di scenari di test determina il tempo di inattività effettivo per il database di produzione.
- Esegui il backup dei database di destinazione prima di abilitare l'accesso client. Questa best practice assicura che lo stato iniziale dei database di destinazione sia recuperabile.
Al termine del passaggio, i client sono completamente operativi e iniziano ad accedere ai database di produzione (chiamati database di destinazione in questo documento fino a questo punto).
Fase 5: eliminazione del database di origine
Dopo aver completato il passaggio ai database di produzione, puoi eliminare i database di origine. È buona norma eseguire un backup finale di ogni database di origine in modo da avere uno stato finale definito e accessibile. Le normative sui dati potrebbero anche richiedere backup finali per motivi di conformità.
Fase 6: riserva
L'implementazione di un fallback, soprattutto per client di database altamente critici, può essere una buona protezione da problemi e problemi della migrazione. Un fallback è come una migrazione, ma al contrario. In altre parole, con un fallback configuri una migrazione dai database di destinazione ai database di origine. Con le migrazioni dei database eterogenee, il fallback è più complesso. Per questo motivo ti consigliamo di eseguire il passaggio solo dopo aver testato meticolosamente che il processo di migrazione del database e le tue applicazioni collegate al database di destinazione soddisfino i tuoi accordi sul livello del servizio (SLA).
Dopo aver svuotato i database di origine ed eseguito il backup di tutti i database, puoi abilitare i processi di migrazione che identificano le modifiche nei database di destinazione e migrarli nei database di origine prima del passaggio.
La creazione di questi processi di migrazione garantisce che, dopo che i client apportano modifiche ai database di destinazione, questi ultimi siano sincronizzati e il loro stato dei dati sia aggiornato. Potrebbero essere necessari giorni o settimane di riserva dopo il passaggio. Ad esempio, i client potrebbero accedere alla funzionalità per la prima volta ed essere bloccati a causa di funzionalità inaccessibili che non possono essere risolte rapidamente. In questo caso, i client possono tornare ad accedere ai database di origine. Prima che i client vengano ripristinati, tutte le modifiche ai database di destinazione devono essere svuotate nei database di origine.
Con questo approccio, alcune circostanze richiedono un'attenzione particolare:
- Devi progettare schemi di destinazione in modo che sia possibile una migrazione inversa (dai database di destinazione ai database di origine). Ad esempio, se il processo di migrazione iniziale (dall'origine alla destinazione) include join o aggregazioni, una migrazione inversa non è banale o addirittura impossibile. In tal caso, i singoli dati devono essere disponibili anche nei database di destinazione.
- Potrebbe sorgere un problema per cui i database di origine dispongono di log delle transazioni, ma i database di destinazione non forniscono una funzionalità non funzionante di questo tipo. In questo caso, una migrazione inversa (dalla destinazione all'origine) deve basarsi su query differenziali. Questa configurazione deve essere progettata e preparata negli schemi del database di destinazione.
- I client che gestivano originariamente sui database di origine devono essere mantenuti disponibili e operativi per poter essere attivati in un fallback. Eventuali modifiche funzionali apportate ai client che accedono ai database di destinazione devono essere apportate anche ai client che accedono al database di origine per garantire l'equivalente funzionale.
Mentre un fallback è l'ultima risorsa, l'implementazione di un fallback è essenziale e deve essere trattato come una migrazione completa del database, che include i test.
Modifiche dinamiche durante la migrazione
In generale, i database sono sistemi dinamici perché i valori di schema e dati possono cambiare. Gli schemi del database possono cambiare in base a fattori come i requisiti aziendali e i valori dei dati possono cambiare insieme o indipendentemente dalle modifiche allo schema. Le modifiche ai valori dei dati possono avvenire in modo dinamico in qualsiasi momento con le modifiche corrispondenti all'implementazione di un'applicazione. Le seguenti sezioni discutono di alcune delle possibili modifiche e delle relative implicazioni per una migrazione del database.
Modifiche allo schema
I database possono essere classificati in sistemi che richiedono uno schema predefinito o che sono senza schema. In generale, i sistemi che richiedono uno schema predefinito supportano operazioni di modifica dello schema, ad esempio l'aggiunta di attributi o colonne in un sistema relazionale.
In questi sistemi, puoi controllare le modifiche attraverso un processo di gestione dei cambiamenti. Un processo di gestione dei cambiamenti consente di apportare modifiche in modo controllato. Tutte le operazioni che dipendono dallo schema, come query o processi di migrazione dei dati, vengono modificate contemporaneamente per garantire una modifica complessiva coerente.
I sistemi di database che non richiedono uno schema predefinito possono essere modificati in qualsiasi momento. Una modifica allo schema non può essere apportata solo da un utente autorizzato, ma in alcuni casi è possibile in modo programmatico. In questi casi, una modifica dello schema può avvenire in qualsiasi momento. Le operazioni che dipendono dallo schema potrebbero non riuscire, ad esempio query o processi di migrazione dei dati. Per impedire modifiche incontrollate allo schema in questi sistemi di database, devi implementare un processo di gestione delle modifiche come convenzione e una regola accettata anziché l'applicazione del sistema.
Modifiche ai dati
In generale, gli schemi controllano i possibili valori dei dati per i vari attributi dei dati. I sistemi senza schema non hanno vincoli sui valori dei dati.
In entrambi i casi, possono essere visualizzati valori di dati che non sono stati archiviati in precedenza. Ad esempio, i tipi di enumerazione vengono spesso implementati come un insieme di stringhe nei sistemi di database. A livello di linguaggio di programmazione, questi tipi di enumerazione potrebbero essere implementati nei client come tipi di enumerazione reali, ma non necessariamente. È possibile che un client memorizzi quello che considera un valore di enumerazione valido che altri client non considerano valido. Inoltre, un processo di migrazione dei dati potrebbe toglierne la funzionalità ai valori di enumerazione. Se vengono visualizzati nuovi valori, il processo di migrazione dei dati potrebbe non riuscire.
Un altro esempio è l'archiviazione di strutture JSON. In molti casi le strutture JSON vengono archiviate in una stringa di tipo di dati, ma vengono interpretate come valori JSON al momento dell'accesso. Se la struttura JSON cambia, il sistema di database non lo rileva; i processi di migrazione dei dati che interpretano una stringa come valore JSON potrebbero non riuscire.
Modifiche al processo di migrazione
La gestione dei cambiamenti durante una migrazione continua del database è complessa e complessa e può portare a errori di migrazione o incoerenze nei dati. È ottimale che le modifiche richieste vengano ritardate fino alla fine della fase di svuotamento, a quel punto i sistemi di database di origine e di destinazione vengono sincronizzati. Le modifiche a questo punto vengono quindi limitate ai database di destinazione e ai relativi client (a meno che non venga implementato anche un elemento di riserva).
Se devi modificare il processo di migrazione durante una migrazione dei dati, ti consigliamo di mantenere le modifiche al minimo ed eventualmente di apportare diverse piccole modifiche anziché una più complessa. Inoltre, potresti valutare la possibilità di testare prima queste modifiche utilizzando istanze di test dei database di origine e di destinazione. Idealmente, dovresti caricare l'origine di test con dati di produzione di cui poi esegui la migrazione al target di test. Con questo approccio, puoi verificare le modifiche proposte senza che ciò influisca sulla migrazione in produzione. Dopo aver testato e verificato le modifiche, puoi applicare le modifiche al sistema di produzione.
Affinché sia possibile apportare modifiche durante una migrazione dei dati in corso, devi essere in grado di arrestare e riavviare il sistema di migrazione dei dati, possibilmente con processi di migrazione dei dati modificati. In tal caso, non devi partire da zero con una fase di caricamento iniziale dei dati. Se il sistema di migrazione dei dati supporta una funzionalità di esecuzione della migrazione di prova, puoi utilizzarla.
Ti consigliamo di evitare di modificare lo schema, i valori dei dati o i processi di migrazione dei dati durante una migrazione dei dati. Se devi apportare modifiche, ti consigliamo di riavviare la migrazione dei dati dall'inizio per assicurarti di avere uno stato iniziale definito. In ogni caso, è fondamentale eseguire il test utilizzando i dati di produzione ed eseguire il backup dei database prima di applicare le modifiche, in modo che, se necessario, sia possibile reimpostare lo stato generale del sistema su uno stato coerente.
Mitigazione degli errori di migrazione
Durante la migrazione del database possono verificarsi problemi imprevisti. Di seguito sono evidenziate alcune aree che possono richiedere una pianificazione preliminare:
- Velocità effettiva insufficiente. Un sistema di migrazione può non avere una velocità effettiva sufficiente nonostante i test di carico. Questo problema potrebbe avere molte cause, ad esempio un aumento imprevisto della frequenza delle modifiche al database di origine o una limitazione della rete. Puoi prepararti a questo caso preparando risorse aggiuntive per lo scale up dinamico o lo scale out di tutti i componenti coinvolti.
- Instabilità del database. I database di origine o di destinazione possono mostrare instabilità, il che può rallentare i processi di migrazione dei dati o impedire in modo intermittente l'accesso. I processi di migrazione dei dati potrebbero dover essere ripristinati di frequente. In questo caso, un passaggio intenzionale ad alta disponibilità o RE potrebbe risolvere il problema. Uno switch modifica l'ambiente non funzionale (macchine e archiviazione) e potrebbe mitigare il problema. In questo caso, devi testare il passaggio e i processi di recupero della migrazione del database per assicurarti che il passaggio non causi incoerenze nei dati nei database di destinazione.
- Esaurimento delle dimensioni del file di log delle transazioni. In alcuni casi, i log delle transazioni vengono archiviati in file con un limite massimo. È possibile che venga raggiunto questo limite superiore e che la migrazione del database abbia esito negativo. È importante comprendere quali parti di un sistema di database possono essere riconfigurate dinamicamente per risolvere i limiti delle risorse non appena si presentano. Se alcuni aspetti non possono essere configurati in modo dinamico, le dimensioni iniziali devono essere determinate con attenzione.
Più i test iniziali sono realistici e completi, più è probabile che vengano individuati potenziali problemi da risolvere in anticipo.
Passaggi successivi
- Consulta le seguenti risorse sulla migrazione dei database:
- Consulta Migrazione dei database per altre guide alla migrazione dei database.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.