Esaminare le procedure consigliate per la migrazione di database molto grandi

• 11 minuti

Le linee guida seguenti sono basate su progetti di clienti reali e sulle informazioni apprese da tali progetti. Le linee guida identificano scenari che sono risultati inefficaci in passato. Si consideri, ad esempio, il consiglio di non usare server UNIX o virtualizzati come server di esportazione R3load:

• Spesso, le prestazioni di esportazione sono un fattore vincolante in termini di inattività generale. Spesso l'hardware in uso ha più di 4-5 anni e il relativo aggiornamento ha costi proibitivi.
• È quindi importante ottenere le massime prestazioni di esportazione ragionevolmente possibili.
• Nei progetti precedenti sono state impiegate settimane o addirittura mesi per cercare di ottimizzare le prestazioni di esportazione R3load su piattaforme UNIX o virtualizzate, prima di rinunciare e usare i server Intel R3load.
• I server Intel dual-socket sono economici e offrono consistenti miglioramenti delle prestazioni, in alcuni casi di un ordine di grandezza superiore rispetto ai minimi miglioramenti di ottimizzazione che è possibile ottenere sui server UNIX o virtualizzati.
• I clienti hanno spesso farm di macchine virtuali, che tuttavia non supportano le moderne tecnologie di offload o SR-IOV. Spesso dispongono di una versione VMware obsoleta, priva di patch o non configurata per una velocità effettiva di rete molto elevata e una bassa latenza. I server di esportazione R3load richiedono prestazioni di thread veloci e una velocità effettiva di rete estremamente elevata. I server di esportazione R3load possono essere eseguiti per 10-15 ore a quasi il 100% della CPU e dell'utilizzo della rete. Questo non è il tipico caso d'uso della maggior parte delle farm VMware e quasi nessuna delle distribuzioni VMware è stata progettata per gestire un carico di lavoro come R3load.

Procedure consigliate

• Esaminare e inventariare l'infrastruttura SAP corrente. Identificare i livelli di Support Pack SAP e determinare se è necessaria l'applicazione di patch per supportare il sistema di gestione di database di destinazione. In generale, la compatibilità del sistema operativo è determinata dal kernel SAP e la compatibilità del sistema di gestione di database è determinata dal livello di patch SAP_BASIS.
• Creare un elenco di note OSS SAP che devono essere applicate nel sistema di origine, ad esempio gli aggiornamenti per SMIGR_CREATE_DDL. È consigliabile aggiornare i kernel SAP nei sistemi di origine per evitare una modifica consistente durante la migrazione ad Azure. Se ad esempio un sistema esegue un kernel 7.41, effettuare l'aggiornamento alla versione 7.45 più recente nel sistema di origine per evitare di apportare una modifica consistente durante la migrazione.
• Sviluppare e documentare la soluzione di disponibilità elevata e ripristino di emergenza. Nella documentazione, la soluzione dovrebbe essere suddivisa in livello DB, livello ASCS e livello server applicazioni SAP. Potrebbe essere necessario separare le soluzioni in caso di soluzioni autonome, ad esempio TREX o Livecache.
• Sviluppare un documento di ridimensionamento e configurazione contenente i dettagli relativi ai tipi di macchine virtuali di Azure e alla configurazione delle risorse di archiviazione. numero di dischi Premium, quantità di file di dati, distribuzione dei file di dati sui dischi, utilizzo degli spazi di archiviazione, dimensione del formato NTFS = 64 kB. Documentare inoltre la configurazione del backup/ripristino e del sistema di gestione di database, ad esempio impostazioni di memoria, massimo grado di parallelismo e flag di traccia.
• Sviluppare un documento di progettazione della rete, contenente la rete virtuale, la subnet, il gruppo di sicurezza di rete e la configurazione delle route definite dall'utente.
• Documentare e implementare il concetto di sicurezza e protezione avanzata. Rimuovere Internet Explorer, creare un contenitore di Active Directory per gli account e i server del servizio SAP e applicare criteri del firewall per bloccare tutto, tranne un numero limitato di porte necessarie.
• Creare un documento di progettazione della migrazione di sistema operativo/database che illustra in dettaglio il concetto di suddivisione di pacchetti e tabelle, il numero di R3load, i flag di traccia di SQL Server, l'impostazione RowID di Oracle, le impostazioni SMIGR_CREATE_DDL, i contatori di perfmon (ad esempio il numero di righe BCP al secondo e la velocità effettiva BCP in kB al secondo, la CPU, la memoria), le impostazioni RSS, le impostazioni di rete accelerate, la configurazione del file di log, le impostazioni BPE e la configurazione TDE.
• Creare un grafico di programmazione che mostra lo stato di avanzamento dell'esportazione/importazione R3load in ogni ciclo di test. In questo modo, il team dedicato alla migrazione può verificare se le ottimizzazioni e le modifiche migliorano le prestazioni di esportazione o importazione R3load. Sull'asse X è riportato il numero di pacchetti completati e sull'asse Y è indicato il tempo trascorso. Questo grafico di programmazione è fondamentale anche durante la migrazione di produzione in modo che lo stato di avanzamento pianificato possa essere confrontato con lo stato effettivo e con gli eventuali problemi identificati in anticipo.
• Creare un piano di test delle prestazioni. Identificare i 20 report online, processi batch e interfacce più importanti. Documentare i parametri di input (ad esempio, intervallo di date, ufficio vendite, impianto, codice società e così via) e i runtime sul sistema di origine. Confrontarli con il runtime in Azure. In caso di differenze di prestazioni, eseguire SAT, ST05 e altri strumenti SAP per identificare istruzioni inefficienti.
• Controllare la distribuzione e la configurazione e assicurarsi che i timeout del cluster, i kernel, le impostazioni di rete e la dimensione del formato NTFS siano tutti coerenti con i documenti di progettazione. Impostare i contatori di perfmon nei server importanti per registrare i parametri di integrità di base ogni 90 secondi. Verificare che i server SAP si trovino in un contenitore AD separato e che al contenitore siano applicati criteri di gruppo con configurazione del firewall.
• Verificare che il principale consulente della migrazione del sistema operativo o del database sia autorizzato. Richiedere il nome del consulente, l'ID s-user e la data di certificazione. Aprire un messaggio OSS a BC-INS-MIG e chiedere a SAP di confermare che il consulente sia attivo e autorizzato.
• Se possibile, fare in modo che l'intero team di progetto sia associato al progetto di migrazione del database di dimensioni molto estese in una singola località e che non sia geograficamente disperso in diversi continenti e fusi orari.
• Verificare che sia stato definito un piano di fallback appropriato nell'ambito della pianificazione complessiva.
• Selezionare modelli di CPU Intel con conteggio rapido dei thread per i server di esportazione R3load. Non usare i modelli di CPU con risparmio energia poiché hanno prestazioni inferiori e non usano server a 4 socket. Un buon esempio è offerto da Intel Xeon E5 Platinum 8158.

Procedure consigliate per evitare problemi

• Non affidare l'esportazione a un'organizzazione di consulenza e l'importazione a un'altra organizzazione. Può accadere che il sistema di origine sia esternalizzato e gestito da una determinata organizzazione di consulenza o da un partner e che il cliente desideri eseguire la migrazione ad Azure e passare a un altro partner. Considerata la stretta relazione tra esportazione e importazione in termini di ottimizzazione e configurazione, è improbabile che assegnare queste attività a organizzazioni diverse possa produrre un buon risultato.
• Non risparmiare sulle risorse hardware di Azure durante le fasi di migrazione e di passaggio alla modalità operativa. Le macchine virtuali di Azure vengono addebitate al minuto e le relative dimensioni possono essere ridotte facilmente. Durante una migrazione VLDB, usare la macchina virtuale più potente disponibile. I clienti sono riusciti a passare con successo alla modalità operativa su sistemi sovradimensionati del 200-250% e quindi a stabilizzarsi eseguendo sistemi sovradimensionati. Dopo aver monitorato l'utilizzo del sistema per 4-6 settimane, le macchine virtuali con capacità in eccesso subiscono una riduzione delle dimensioni o vengono arrestate per limitare i costi.