Migrazione di SAP HANA da Azure Large Instance alle macchine virtuali su Azure

SAP HANA nelle Large Instances di Azure è un servizio di infrastruttura bare-metal dedicato che esegue carichi di lavoro SAP HANA al di fuori delle macchine virtuali di Azure. Poiché il servizio HLI è in fase di ritiro, è necessario eseguire la migrazione dei carichi di lavoro SAP HANA alle macchine virtuali di Azure per mantenere il supporto e sfruttare il più ampio ecosistema di Azure.

Questo articolo illustra come valutare lo scenario di distribuzione HLI corrente, pianificare la migrazione alle macchine virtuali di Azure e prepararsi a una transizione con tempi di inattività minimi.

Presupposti

L'articolo presuppone quanto segue:

• Questo articolo considera solo una migrazione omogenea del servizio di calcolo del database HANA da HANA Large Instance (HLI) a una macchina virtuale di Azure senza aggiornamenti software significativi o applicazione di patch. Questi aggiornamenti secondari includono l'uso di una versione del sistema operativo (OS) più recente o di una versione di HANA esplicitamente dichiarata come supportata dalle note SAP pertinenti.
• Tutte le attività di aggiornamento/aggiornamento vengono eseguite prima o dopo la migrazione. Ad esempio, la conversione di SAP HANA MCOS nella distribuzione MDC.
• L'approccio alla migrazione che offre il minor tempo di inattività è la replica di sistema SAP HANA. Altri metodi di migrazione non rientrano nell'ambito di questo articolo.
• Queste linee guida si applicano sia agli SKU Rev3 che Rev4 di HLI.
• L'architettura di distribuzione HANA rimane principalmente invariata durante la migrazione. Ovvero, un sistema con ripristino di emergenza a istanza singola rimane invariato nella destinazione.
• Il Service Level Agreement (SLA) dell'architettura futura viene esaminato e analizzato.
• I termini commerciali tra HLI e macchine virtuali sono diversi. Monitorare l'utilizzo delle macchine virtuali per la gestione dei costi.
• Si è compreso che HLI è una piattaforma di calcolo dedicata mentre le macchine virtuali vengono eseguite in un'infrastruttura condivisa ma isolata.
• Verificare che le macchine virtuali di destinazione supportino l'architettura desiderata. Per un elenco degli SKU di macchine virtuali supportati certificati per la distribuzione di SAP HANA, vedere la directory hardware di SAP HANA.
• Convalidi il progetto e il piano di migrazione.
• Pianificare una macchina virtuale di ripristino di emergenza insieme al sito primario. Non è possibile usare HLI come nodo di ripristino di emergenza per il sito primario in esecuzione nelle macchine virtuali dopo la migrazione.
• I file di backup necessari sono stati copiati nelle macchine virtuali di destinazione, in base ai requisiti di ripristino e conformità aziendali. I backup accessibili alle macchine virtuali consentono il ripristino temporizzato durante il periodo di transizione.
• Per la replica di sistema SAP HANA (HSR) con disponibilità elevata (HA), è necessario impostare e configurare il dispositivo di fencing in base alle guide di HA di SAP HANA per SLES e RHEL. Non è preconfigurato come il caso HLI.
• Questo approccio alla migrazione non copre gli SKU HLI con la configurazione Optane.

Scenari di distribuzione

È possibile eseguire la migrazione alle macchine virtuali di Azure per tutti gli scenari HLI. La tabella seguente riepiloga i modelli di distribuzione comuni per HLI. Per trarre vantaggio dai servizi di Azure complementari, potrebbe essere necessario apportare modifiche minime all'architettura.

Pianificazione della sorgente (HLI)

Quando hai eseguito l'onboarding del server HLI, tu e Microsoft Service Management avete pianificato l'elaborazione, la rete, l'archiviazione e le impostazioni specifiche del sistema operativo per l'esecuzione del database SAP HANA. È necessario eseguire una pianificazione simile per la migrazione a una macchina virtuale di Azure.

Manutenzione di SAP HANA

Come procedura operativa consigliata, riordinare il contenuto del database in modo che i dati indesiderati, i dati obsoleti o i log non aggiornati non vengono migrati nel nuovo database. La manutenzione comporta in genere l'eliminazione o l'archiviazione di dati obsoleti, scaduti o inattivi. Per convalidare la validità della pulizia dei dati prima dell'utilizzo in produzione, testare l'ottimizzazione dati nei sistemi non di produzione.

Consentire la connettività di rete per le nuove macchine virtuali e la rete virtuale

Nella distribuzione HLI la rete è stata configurata in base all'architettura di rete originale delle istanze Large di SAP HANA. Per informazioni sullo stato corrente di HLI e indicazioni sulla migrazione, vedere Rimozione delle autorizzazioni per istanze Large di SAP HANA.

• La nuova destinazione di migrazione della macchina virtuale è collocata nella rete virtuale esistente con intervalli di indirizzi IP già autorizzati a connettersi all'HLI? Non sono quindi necessari altri aggiornamenti della connettività.

• La nuova macchina virtuale di Azure viene inserita in una nuova rete virtuale di Azure, ad esempio in un'altra area, ed è stato eseguito il peering con la rete virtuale esistente? È quindi possibile usare la chiave del servizio ExpressRoute e l'ID risorsa del provisioning HLI originale per consentire l'accesso a questo nuovo intervallo ip di rete virtuale. Coordinarsi con Microsoft Service Management per abilitare la connettività HLI della rete virtuale.

  Nota

  Per ridurre al minimo la latenza di rete tra i livelli dell'applicazione e del database, i livelli dell'applicazione e del database devono trovarsi nella stessa rete virtuale.

Set di disponibilità esistente del livello dell'applicazione, zone di disponibilità e gruppo di posizionamento di prossimità (PPG)

Il modello di distribuzione corrente è progettato per soddisfare determinati obiettivi del livello di servizio. In questo passaggio, assicurarsi che l'infrastruttura di destinazione soddisfi o superi gli obiettivi. Nella maggior parte dei casi, i server applicazione SAP si trovano in un set di disponibilità. Se il livello di servizio corrente è soddisfacente, la macchina virtuale di destinazione può riutilizzare il nome host logico HLI. Aggiornare il record DNS in modo che punti all'indirizzo IP della macchina virtuale e non sono necessarie modifiche al profilo SAP.

• Se non si usa PPG, posizionare tutte le applicazioni e i server di database nella stessa zona per ridurre al minimo la latenza di rete.
• Se si usa PPG, vedere una sezione successiva di questo articolo, Set di disponibilità, zone di disponibilità e PPG.

Processo di interruzione della replica di archiviazione (se usato)

Se si è usata la replica di archiviazione come soluzione di ripristino di emergenza, terminarla dopo l'arresto dell'applicazione SAP. Prima di procedere, assicurarsi che gli ultimi backup dei dati, del file di log e del catalogo SAP HANA vengano replicati nei volumi di archiviazione HLI del ripristino di emergenza remoto. Questa replica è importante nel caso in cui si verifichi un'emergenza durante la transizione dal server fisico alla macchina virtuale di Azure.

Considerazioni sulla conservazione dei backup dei dati

Dopo la transizione a SAP HANA nella macchina virtuale di Azure, i backup dei log e dei dati basati su snapshot nell'HLI non sono facilmente accessibili o ripristinabili in una macchina virtuale. Eseguire backup e snapshot a livello di file su HLI anche settimane prima del cutover. Copiare questi backup in un account di archiviazione di Azure accessibile dalla nuova macchina virtuale SAP HANA. Nel periodo di transizione iniziale, prima che il backup basato su Azure crei una cronologia sufficiente per soddisfare i requisiti di ripristino temporizzato, eseguire backup a livello di file.

Il backup del contenuto HLI è fondamentale. È anche prudente disporre di backup completi del panorama applicativo SAP facilmente accessibile nel caso in cui sia necessario un rollback.

Regolazione del monitoraggio del sistema

È possibile usare molti strumenti diversi per monitorare e inviare notifiche di avviso per i sistemi all'interno dell'ambiente SAP. Incorporare le modifiche per il monitoraggio e aggiornare i destinatari delle notifiche di avviso in base alle esigenze.

Coinvolgimento del team di operazioni di Microsoft

Aprire un ticket dal portale di Azure in base all'istanza HLI esistente. Dopo aver creato il ticket di supporto, un tecnico del supporto contatta l'utente tramite posta elettronica.

Contattare il team dell'account Microsoft

Pianifica la migrazione vicino al periodo di rinnovo del tuo contratto HLI per ridurre al minimo le spese non necessarie per le risorse di calcolo. Per dismettere l'HLI, coordinare la terminazione del contratto e lo spegnimento dell'unità.

Pianificazione della destinazione

Un'attenta pianificazione è essenziale quando si distribuisce una nuova infrastruttura per sostituire una esistente. Assicurarsi che la nuova aggiunta soddisfi i requisiti generali. Ecco alcuni punti chiave da considerare.

Disponibilità delle risorse nell'area di destinazione

L'area di distribuzione dei server applicazioni SAP corrente è in genere vicina alle HLI associate. Tuttavia, le HLI sono disponibili in meno località rispetto alle aree di Azure. Quando si esegue la migrazione dell'HLI fisico a una macchina virtuale di Azure, è anche consigliabile ottimizzare la distanza di prossimità di tutti i servizi correlati per l'ottimizzazione delle prestazioni. Assicurarsi anche che l'area scelta disponga di tutte le risorse necessarie. Ad esempio, controllare la disponibilità di una determinata famiglia di macchine virtuali o delle zone di disponibilità che offrono una configurazione a disponibilità elevata.

Rete virtuale

Vuoi eseguire il nuovo database HANA in una rete virtuale esistente o crearne una nuova? Il fattore di scelta principale è il layout di rete corrente per il panorama applicativo SAP. Inoltre, quando l'infrastruttura passa da una zona a una distribuzione a due zone e usa PPG, impone una modifica dell'architettura. Per altre informazioni, vedere l'articolo Azure PPG per una latenza di rete ottimale con l'applicazione SAP.

Sicurezza

Indipendentemente dal fatto che la nuova macchina virtuale SAP HANA venga eseguita in una rete virtuale o una subnet nuova o esistente, è un nuovo servizio critico per l'azienda che richiede misure di sicurezza appropriate. Assicurarsi che il controllo di accesso sia conforme ai criteri di sicurezza dell'azienda.

Raccomandazione per il ridimensionamento delle macchine virtuali

Questa migrazione è anche un'opportunità per ridimensionare correttamente il motore di calcolo HANA. È possibile usare le viste di sistema HANA con HANA Studio per comprendere l'utilizzo delle risorse di sistema, che consente il dimensionamento corretto per migliorare l'efficienza di spesa.

Immagazzinamento

Le prestazioni di archiviazione sono uno dei fattori che influiscono sull'esperienza utente dell'applicazione SAP. Microsoft pubblica layout di archiviazione minimi per SKU di macchine virtuali specifici. Per altre informazioni, vedere Configurazioni di archiviazione delle macchine virtuali di Azure sap HANA. Per garantire una capacità e prestazioni di I/O adeguate per la nuova macchina virtuale HANA, esaminare queste specifiche e confrontarle con le statistiche del sistema HLI esistenti.

È necessario configurare il PPG per la nuova macchina virtuale HANA e i server associati? Inviare quindi un ticket di supporto per controllare e verificare la condivisione della risorsa di archiviazione e della macchina virtuale. Poiché la soluzione di backup potrebbe dover cambiare, rivedere anche il costo di archiviazione per evitare sorprese di spesa operativa.

Replica di archiviazione per il ripristino di emergenza

Con HLI, la replica di archiviazione è l'opzione predefinita per il ripristino di emergenza. Questa funzionalità non è l'opzione predefinita per SAP HANA nella macchina virtuale di Azure. Prendere in considerazione HSR, backup/ripristino o altre soluzioni supportate che soddisfano le esigenze aziendali.

Set di disponibilità, zone di disponibilità e PPG

È possibile abbreviare la distanza tra il livello dell'applicazione e SAP HANA per mantenere la latenza di rete almeno. Inserire la nuova macchina virtuale di database e i server applicazioni SAP correnti in un PPG. Per ulteriori informazioni sul funzionamento del set di disponibilità di Azure e delle zone di disponibilità con PPG per le distribuzioni SAP, vedere Gruppo di posizionamento di prossimità.

Se i membri del sistema HANA vengono distribuiti in più zone di disponibilità, tenere presente il profilo di latenza delle zone scelte. Posizionare i componenti di sistema SAP per ridurre al minimo la distanza tra l'applicazione SAP e il database. Lo strumento di test della latenza della zona di disponibilità del dominio pubblico semplifica la misurazione.

Strategia di backup

Molti clienti usano già soluzioni di backup di terze parti per SAP HANA in HLI. In tal caso, è sufficiente configurare le macchine virtuali protette aggiunte e i database HANA. È possibile annullare lo scheduling dei processi di backup HLI attivi se il computer viene dismesso dopo la migrazione.

Backup di Azure per SAP HANA nella macchina virtuale è ora disponibile a livello generale. Per altre informazioni sul backup di SAP HANA nelle macchine virtuali di Azure, vedere Backup, ripristino e gestione.

Strategia di ripristino di emergenza

Se gli obiettivi del livello di servizio supportano un tempo di ripristino più lungo, un approccio basato su backup potrebbe essere sufficiente. Un backup su archiviazione BLOB e il ripristino sul posto o il ripristino in una nuova VM è la strategia di ripristino di emergenza più semplice e meno costosa.

Nella piattaforma di istanze di grandi dimensioni, il disaster recovery di HANA tipicamente utilizza HSR. In una macchina virtuale di Azure, HSR è anche la soluzione di ripristino di emergenza SAP HANA più naturale e nativa. Indipendentemente dal fatto che la distribuzione di origine sia a istanza singola o in cluster, è necessaria una replica dell'infrastruttura di origine nell'area del ripristino di emergenza. Configurare questa replica di DR dopo aver completato la migrazione della HLI primaria alla macchina virtuale. Il database DR HANA si registra in SAP HANA primario nell'istanza della macchina virtuale come sito di replica secondario.

Modifica della destinazione della connettività del server applicazioni SAP

La migrazione HSR comporta un nuovo host di database HANA e anche un nuovo nome host del database per il livello applicazione. Modificare i profili SAP in modo che riflettano il nuovo nome host. Se si usa la risoluzione dei nomi per mantenere il nome host, non è necessaria alcuna modifica del profilo.

Sistema operativo

Le immagini del sistema operativo per HLI e VM, nonostante siano nello stesso livello di rilascio (ad esempio SLES 12 SP4), non sono identiche. Convalidare i pacchetti, gli hotfix, le patch, il kernel e le correzioni di sicurezza necessarie nell'HLI. Installare quindi gli stessi pacchetti nella destinazione. È possibile usare HSR per eseguire la replica da un sistema operativo precedente in una macchina virtuale con una versione più recente del sistema operativo. Verificare le versioni supportate esaminando la nota SAP 2763388.

Nuova richiesta di licenza SAP

Richiedere una nuova licenza SAP per il nuovo sistema HANA dopo la migrazione alle macchine virtuali.

Differenze SLA

Si noti la differenza nel contratto di servizio di disponibilità tra HLI e vm di Azure. Ad esempio, le coppie di disponibilità elevata HLI raggruppate offrono il 99,99% di disponibilità. Per ottenere lo stesso SLA (livello di servizio), distribuire le macchine virtuali nelle zone di disponibilità. Il contratto di servizio per le macchine virtuali descrive la disponibilità per varie configurazioni di macchine virtuali in modo da poter pianificare l'infrastruttura di destinazione.

Strategia di migrazione

Questo articolo illustra l'approccio alla replica di sistema HANA per la migrazione da HLI a macchina virtuale di Azure. A seconda della soluzione di archiviazione di destinazione distribuita, il processo è leggermente diverso. Le sezioni seguenti descrivono i passaggi generali.

VM con dischi Premium o Ultra per i dati

Per le macchine virtuali distribuite con dischi Premium o Ultra, la configurazione di replica di sistema SAP HANA standard si applica quando si configura HSR. Per una panoramica dei passaggi per configurare la replica del sistema, vedere l'articolo della Guida di SAP. L'articolo illustra anche l'acquisizione di un sistema secondario, il failback al database primario e la disabilitazione della replica di sistema. Per la migrazione, è necessaria solo la configurazione, l'acquisizione e la disabilitazione dei passaggi di replica.

VM con ANF per volumi di dati e log

A livello generale, copiare gli snapshot di archiviazione HLI più recenti dei volumi completi di dati e log nell'archiviazione di Azure. La macchina virtuale HANA di destinazione può quindi accedervi e recuperarle. È possibile usare qualsiasi strumento di copia linux nativo per il processo di copia.

Conversione da MCOS a MDC

Alcuni clienti HLI hanno usato il modello di distribuzione Multiple Components in One System (MCOS). Questo approccio ha aggirato la limitazione dello snapshot di archiviazione MDC (Multiple Databases Container) delle versioni precedenti di SAP HANA. Nel modello MCOS, diverse istanze indipendenti di SAP HANA sono raggruppate in un'Istanza Grande HANA. L'uso di HSR per la migrazione funziona correttamente, ma comporta più macchine virtuali HANA con un database tenant ciascuno. Questo stato finale crea un panorama più complesso di quanto si preferisca. La distribuzione predefinita per SAP HANA 2.0 è MDC. Un'alternativa consiste nell'eseguire lo spostamento del tenant HANA dopo la migrazione di HSR. Lo spostamento del tenant HANA combina questi database HANA indipendenti in cotenant in un unico contenitore HANA.

Considerazioni sul livello applicazione

Il server di database è il centro di un sistema SAP. Tutti i server applicazioni devono trovarsi vicino al database SAP HANA. In alcuni casi, quando si vuole usare un nuovo PPG, potrebbe essere necessario spostare i server applicazioni esistenti nel PPG in cui viene eseguita la macchina virtuale HANA. La creazione di nuovi server applicazioni potrebbe risultare più semplice se si dispone già di modelli di distribuzione.

Individuare i server applicazioni esistenti e la nuova macchina virtuale HANA in modo ottimale. Non è quindi necessario creare nuovi server applicazioni, a meno che non si desideri una capacità maggiore.

Quando si crea una nuova infrastruttura per migliorare la disponibilità del servizio, i server applicazioni esistenti potrebbero non essere necessari. È possibile arrestarli ed eliminarli. Se il nome host della macchina virtuale di destinazione cambia e differisce dal nome host HLI, modificare i profili del server applicazioni SAP in modo che puntino al nuovo host. Se è stato modificato solo l'indirizzo IP del database HANA, aggiornare il record DNS per indirizzare le connessioni in ingresso alla nuova macchina virtuale HANA.

Test di accettazione

La migrazione da HLI a macchina virtuale non apporta modifiche materiali al contenuto del database rispetto a una migrazione eterogenea. Verificare comunque le prestazioni della nuova configurazione.

Piano di migrazione

Anche se questa migrazione è semplice, comporta la disattivazione di un database esistente. Un'attenta pianificazione per mantenere il sistema di origine con il contenuto e le immagini di backup è fondamentale nel caso in cui sia necessario eseguire il fallback. Una buona pianificazione offre un'inversione più veloce.

Dopo la migrazione

Il processo di migrazione non viene eseguito fino a quando non si separano in modo sicuro i servizi dipendenti da HLI e la connettività per garantire l'integrità dei dati. Disattivare anche i servizi non necessari. In questa sezione vengono evidenziati alcuni degli elementi più importanti.

Rimozione dell'HLI

Dopo aver eseguito correttamente la migrazione del database HANA a una macchina virtuale di Azure, assicurarsi che non vengano eseguite transazioni aziendali nel database HLI. Tuttavia, mantenere l'HLI in esecuzione per la finestra di conservazione dei backup locale garantisce un ripristino più rapido, se necessario. Solo dopo che la finestra di conservazione del backup locale è scaduta, dovresti dismettere l'istanza Large di HANA. Concludere quindi gli impegni contrattuali HLI con Microsoft contattando i rappresentanti Microsoft.

Rimuovere qualsiasi proxy configurato per HLI

Se si usa un servizio proxy come iptables per instradare il traffico locale da e verso HLI, non è necessario dopo la migrazione a una macchina virtuale. Tuttavia, mantenere questo servizio di connettività per tutto il tempo in cui HLI è in standby. Arrestare il servizio solo dopo aver completato la rimozione di HLI. Gli esempi includono iptables e BIGIP.

Rimuovere copertura globale per HLI

Global Reach viene usato per connettere il gateway ExpressRoute con il gateway HLI ExpressRoute. Consente al traffico locale di raggiungere direttamente il tenant HLI senza usare un servizio proxy. Questa connessione non è più necessaria dopo la rimozione dell'unità HLI dopo la migrazione. Tuttavia, come il servizio proxy iptables, mantenere la Copertura globale finché HLI non viene completamente rimosso.

Sottoscrizione del sistema operativo (spostamento/riutilizzo)

Quando si distribuiscono i server vm e si rimuove l'HLI, è possibile sostituire o riutilizzare le sottoscrizioni del sistema operativo. Non è necessario pagare il doppio per le licenze del sistema operativo.

Passaggi successivi

Pianificare la distribuzione SAP.