Condividi tramite

Migrazione di SAP HANA in istanze Large di Azure ad Azure Macchine virtuali

  • Articolo

Questo articolo descrive i possibili scenari di distribuzione di istanze Large di Azure e offre un approccio di pianificazione e migrazione con tempi di inattività ridotti alla transizione.

Panoramica

Le istanze Large di Azure per SAP HANA (HLI) sono state annunciate per la prima volta nel settembre 2016. Da allora, molti hanno adottato questo hardware come servizio per la piattaforma di calcolo in memoria. Negli ultimi anni, tuttavia, l'estensione delle dimensioni della macchina virtuale di Azure e il supporto della distribuzione con scalabilità orizzontale ha superato la maggior parte della domanda di capacità del database ERP dei clienti aziendali. Molti stanno esprimendo interesse per la migrazione del carico di lavoro SAP HANA dai server fisici alle macchine virtuali di Azure.

Questo articolo non è un documento di configurazione dettagliato. Descrive i modelli di distribuzione comuni e offre consigli per la pianificazione e la migrazione. L'intento è quello di richiamare le considerazioni necessarie per la preparazione per ridurre al minimo i tempi di inattività della transizione.

Presupposti

L'articolo presuppone quanto segue:

  • Si considererà 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 o patch significativi. 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/aggiornamenti verranno 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 fanno parte dell'ambito di questo documento.
  • Queste indicazioni sono applicabili sia per gli 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 rimarrà invariato nella destinazione.
  • È stato esaminato e compreso il Contratto di servizio (SLA) dell'architettura di destinazione (da usare).
  • 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.
  • È stata convalidata che le macchine virtuali di destinazione supportano 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.
  • Il piano di progettazione e migrazione è stato convalidato.
  • Pianificare la 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. Con i backup accessibili alle macchine virtuali, consente il ripristino temporizzato durante il periodo di transizione.
  • Per la disponibilità elevata (HSR) della replica di sistema SAP HANA, è necessario configurare e configurare il dispositivo di isolamento per sap HANA HA GUIDE 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. I modelli di distribuzione comuni per HLI sono riepilogati nella tabella seguente. Per trarre vantaggio dai servizi di Azure complementari, potrebbe essere necessario apportare modifiche minime all'architettura.

ID scenario HLI Scenario Eseguire la migrazione alla macchina virtuale verbatim? Commento
1 Nodo singolo con un SID Sì -
2 Nodo singolo con più componenti in un sistema (MCOS) Sì -
3 Nodo singolo con ripristino di emergenza tramite la replica di archiviazione No La replica di archiviazione non è disponibile con la piattaforma virtuale di Azure; modificare la soluzione di ripristino di emergenza corrente in HSR o backup/ripristino.
4 Nodo singolo con ripristino di emergenza (multiuso) tramite la replica di archiviazione No La replica di archiviazione non è disponibile con la piattaforma virtuale di Azure; modificare la soluzione di ripristino di emergenza corrente in HSR o backup/ripristino.
5 HSR con isolamento per la disponibilità elevata Sì Nessun SBD preconfigurato per le macchine virtuali di destinazione. Selezionare e distribuire una soluzione di isolamento. Opzioni possibili: Azure Fencing Agent (supportato sia per RHEL, SLES e SBD.
6 Disponibilità elevata con HSR, ripristino di emergenza con replica di archiviazione No Sostituire la replica di archiviazione per le esigenze di ripristino di emergenza con HSR o backup/ripristino.
7 Failover automatico dell'host (1+1) Sì Usare Azure NetApp Files (ANF) per l'archiviazione condivisa con macchine virtuali di Azure.
8 Aumento del numero di istanze con standby Sì BW/4HANA con M128s, M416s, macchine virtuali M416ms che usano ANF solo per l'archiviazione.
9 Aumento del numero di istanze senza standby Sì BW/4HANA con M128s, M416s, macchine virtuali M416ms (con o senza usare ANF per l'archiviazione).
10 Scalabilità orizzontale con ripristino di emergenza tramite la replica di archiviazione No Sostituire la replica di archiviazione per le esigenze di ripristino di emergenza con HSR o backup/ripristino.
11 Nodo singolo con ripristino di emergenza con HSR Sì -
12 Da HSR a nodo singolo al ripristino di emergenza (ottimizzato per i costi) Sì -
13 disponibilità elevata e ripristino di emergenza con HSR Sì -
14 Disponibilità elevata e ripristino di emergenza con HSR (ottimizzato per i costi) Sì -
15 Scalabilità orizzontale con ripristino di emergenza con HSR Sì BW/4HANA con M128s. Macchine virtuali M416s, M416ms (con o senza usare ANF per l'archiviazione).

Pianificazione dell'origine (HLI)

Durante l'onboarding del server HLI, l'utente e la gestione dei servizi Microsoft hanno eseguito la pianificazione delle impostazioni di calcolo, rete, archiviazione e specifiche del sistema operativo per l'esecuzione del database SAP HANA. È necessario eseguire una pianificazione simile per la migrazione alla macchina virtuale di Azure.

Manutenzione di SAP HANA

È consigliabile riordinare il contenuto del database in modo che i dati indesiderati, obsoleti o i log non aggiornati non siano migrati al nuovo database. La manutenzione comporta in genere l'eliminazione o l'archiviazione di dati obsoleti, scaduti o inattivi. Questa "igiene dei dati" deve essere testata nei sistemi non di produzione per convalidare la validità del taglio dei dati prima dell'utilizzo 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 alle informazioni descritte nell'articolo Architettura di rete SAP HANA (istanze Large). Inoltre, il routing del traffico di rete viene eseguito nel modo descritto nella sezione Routing in Azure.

  • La nuova destinazione di migrazione della macchina virtuale viene inserita nella rete virtuale esistente con intervalli di indirizzi IP già autorizzati a connettersi all'HLI? Non è quindi necessario un ulteriore aggiornamento della connettività.
  • La nuova macchina virtuale di Azure viene inserita in una nuova Rete virtuale di Microsoft 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à a livello di app esistente, zone di disponibilità e gruppo di posizionamento di prossimità (PPG)

Il modello di distribuzione corrente è stato progettato per soddisfare determinati obiettivi a livello di servizio. In questo passaggio assicurarsi che l'infrastruttura di destinazione soddisfi o superi gli obiettivi impostati.
Molto probabilmente, i server applicazioni SAP vengono inseriti in un set di disponibilità. Se il livello di servizio di distribuzione corrente è soddisfacente e se la macchina virtuale di destinazione presuppone il nome host del nome logico HLI, l'aggiornamento della risoluzione degli indirizzi DNS (Domain Name Service) che punta all'INDIRIZZO IP della macchina virtuale funzionerà senza aggiornare alcun profilo SAP.

  • Se non si usa PPG, assicurarsi di posizionare tutti i server dell'applicazione e del database nella stessa zona per ridurre al minimo la latenza di rete.
  • Se si usa PPG, fare riferimento a una sezione successiva di questo articolo, set di disponibilità, zone di disponibilità e gruppi di posizionamento di prossimità.

Processo di interruzione della replica di archiviazione (se usato)

Se è stata usata la replica di archiviazione come soluzione di ripristino di emergenza, terminarla dopo l'arresto dell'applicazione SAP. Prima di eseguire questa operazione, assicurarsi che gli ultimi backup di catalogo, file di log e dati di SAP HANA vengano replicati nei volumi di archiviazione HLI di ripristino di emergenza remoti. 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 saranno facilmente accessibili o ripristinabili in una macchina virtuale. È consigliabile eseguire backup e snapshot a livello di file nell'HLI anche settimane prima del cut-over. Dopo aver copiato questi backup in un account Archiviazione di Azure accessibile dalla nuova macchina virtuale SAP HANA. Anche 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 sap facilmente accessibile nel caso in cui sia necessario un ripristino dello stato precedente.

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. Ricordarsi di intervenire in modo appropriato per incorporare le modifiche per il monitoraggio e aggiornare i destinatari delle notifiche di avviso, se necessario.

Coinvolgimento del team operativo 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 ti contatterà tramite posta elettronica.

Contattare il team dell'account Microsoft

Pianificare la migrazione vicino all'ora di rinnovo dell'anniversario del contratto HLI per ridurre al minimo le spese non necessarie per la risorsa di calcolo. Per rimuovere l'HLI, coordinare la terminazione del contratto e arrestare l'unità.

Pianificazione della destinazione

Un'attenta pianificazione è essenziale per distribuire una nuova infrastruttura al posto di una esistente. Assicurati che la nuova aggiunta soddisfi le tue esigenze nel più ampio schema di cose. 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 vengono offerte in meno località rispetto alle aree di Azure disponibili. 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. In questo modo, assicurarsi che l'area scelta disponga di tutte le risorse necessarie. Ad esempio, è possibile verificare la disponibilità di una determinata famiglia di macchine virtuali o delle zone di Azure che offrono la configurazione a disponibilità elevata.

Rete virtuale

Eseguire il nuovo database HANA in una rete virtuale esistente o crearne uno nuovo? Il fattore di scelta principale è il layout di rete corrente per il panorama applicativo SAP. Inoltre, quando l'infrastruttura passa dalla distribuzione di una zona 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/subnet nuova o esistente, è un nuovo servizio fondamentale per l'azienda. Merita la tutela. 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, consentendo il ridimensionamento corretto per favorire l'efficienza di spesa.

Storage

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

Si configurerà PPG per la nuova macchina virtuale HANA e i relativi sever associati? Inviare quindi un ticket di supporto per controllare e verificare la co-posizione dell'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 gruppi di posizionamento di prossimità

È 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 altre informazioni sul funzionamento del set di disponibilità di Azure e delle zone di disponibilità con PPG per le distribuzioni SAP, vedere Proximity Placement Group( Gruppo di posizionamento di prossimità).

Se i membri del sistema HANA vengono distribuiti in più di una zona di Azure, è necessario conoscere il profilo di latenza delle zone scelte. Posizionare i componenti di sistema SAP per ridurre 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 dei nostri clienti usano già soluzioni di backup di terze parti per SAP HANA in HLI. In caso affermativo, è necessario configurare solo i database di MACCHINE virtuali e HANA protetti. I processi di backup HLI in corso possono essere annullati se il computer viene rimosso dopo la migrazione.

Il 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, il backup può essere semplice. Un backup nell'archiviazione BLOB e il ripristino sul posto o il ripristino in una nuova macchina virtuale è la strategia di ripristino di emergenza più semplice e meno costosa.

Nella piattaforma di istanze large il ripristino di emergenza haNA viene in genere eseguito con 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 di ripristino di emergenza. Questa replica di ripristino di emergenza verrà configurata al termine della migrazione da HLI primaria alla macchina virtuale. Il database HANA di ripristino di emergenza verrà registrato nell'istanza primaria di SAP HANA nella 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 il passaggio viene eseguito dalla risoluzione dei nomi mantenendo 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 necessari, correzioni ad accesso frequente, patch, kernel e correzioni di sicurezza 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

Semplice call-out per richiedere una nuova licenza SAP per il nuovo sistema HANA ora che è stata eseguita la migrazione alle macchine virtuali.

Differenze del contratto di servizio

Gli autori vogliono chiamare la differenza del contratto di servizio di disponibilità tra HLI e macchina virtuale di Azure. Ad esempio, le coppie a disponibilità elevata HLIs raggruppate offrono disponibilità del 99,99%. Per ottenere lo stesso contratto di servizio, è necessario distribuire le macchine virtuali nelle zone di disponibilità. Il contratto di servizio per Macchine virtuali descrive la disponibilità per varie configurazioni di macchine virtuali in modo che i clienti possano pianificare l'infrastruttura di destinazione.

Strategia di migrazione

In questo documento viene illustrato solo l'approccio alla replica di sistema HANA per la migrazione da HLI a macchina virtuale di Azure. Dipende dalla soluzione di archiviazione di destinazione distribuita, il processo è leggermente diverso. I passaggi generali sono descritti di seguito.

VM con dischi Premium/Ultra per i dati

Per le macchine virtuali distribuite con dischi Premium o Ultra, la configurazione di replica di sistema SAP HANA standard è applicabile per la configurazione di HSR. Per una panoramica dei passaggi per la configurazione della replica di 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, sarà 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, gli snapshot di archiviazione HLI più recenti dei volumi di dati e log completi devono essere copiati nell'archiviazione di Azure. Da qui sono accessibili e recuperabili dalla macchina virtuale HANA di destinazione. Il processo di copia può essere eseguito con qualsiasi strumento di copia Linux nativo.

Importante

La copia e il trasferimento dei dati possono richiedere ore a seconda delle dimensioni del database HANA e della larghezza di banda di rete. La maggior parte del processo di copia deve essere eseguita prima del tempo di inattività primario del database HANA.

Conversione da MCOS a MDC

Il modello di distribuzione Multiple Components in One System (MCOS) è stato usato da alcuni dei nostri clienti HLI. La motivazione era aggirare 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 vengono sovrapposte in un'istanza Large di HANA. L'uso di HSR per la migrazione funziona correttamente, ma comporta più macchine virtuali HANA con un database tenant ciascuno. Questo modello crea un panorama più affollato rispetto a quello che si potrebbe preferire. 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 cotenants in un singolo contenitore HANA.

Considerazioni sul livello applicazione

Il server di database viene visualizzato come 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 si trova la macchina virtuale HANA. La creazione di nuovi server applicazioni può essere considerata più semplice se sono già pronti i modelli di distribuzione.

Individuare i server applicazioni esistenti e la nuova macchina virtuale HANA in modo ottimale. Non sarà 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. Possono essere arrestati ed eliminati. Se il nome host della macchina virtuale di destinazione è cambiato e differisce dal nome host HLI, modificare i profili del server applicazioni SAP in modo che puntino al nuovo host. Se solo l'indirizzo IP del database HANA è stato modificato, 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. È comunque consigliabile controllare le prestazioni della nuova configurazione.

Piano di cutover

Anche se questa migrazione è semplice, comporta la rimozione delle autorizzazioni 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 il fallback. Una buona pianificazione offre un'inversione più veloce.

Dopo la migrazione

Il processo di migrazione non viene eseguito fino a quando non è stata disaccoppiata in modo sicuro tutti i servizi dipendenti da HLI e la connettività per garantire l'integrità dei dati. È anche consigliabile arrestare i servizi non necessari. Questa sezione descrive 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 il periodo di tempo della finestra di conservazione dei backup locale garantisce un ripristino più rapido, se necessario. Solo quando la finestra di conservazione dei backup locale è passata, è necessario rimuovere le autorizzazioni per l'istanza Large di HANA. Concludere quindi gli impegni contrattuali HLI con Microsoft contattando i propri rappresentanti Microsoft.

Rimuovere qualsiasi proxy (ad esempio, Iptables, BIGIP) configurato per HLI

Se un servizio proxy come ipTables viene usato per instradare il traffico locale da e verso HLI, non è necessario dopo la corretta migrazione alla macchina virtuale. Tuttavia, questo servizio di connettività deve essere mantenuto per tutto il tempo in cui l'HLI è in piedi. Arrestare il servizio solo dopo la rimozione completa dell'HLI.

Rimuovere copertura globale per HLI

Copertura globale viene usata per connettere il gateway ExpressRoute dei clienti con il gateway ExpressRoute HLI. Consente al traffico locale dei clienti di raggiungere direttamente il tenant HLI senza l'uso di un servizio proxy. Questa connessione non è più necessaria in assenza dell'unità HLI dopo la migrazione. Tuttavia, come il servizio proxy IPTables, GlobalReach deve essere mantenuto anche fino a quando HLI non viene completamente rimosso.

Sottoscrizione del sistema operativo : spostamento/riutilizzo

Man mano che i server vm vengono distribuiti e le HLI vengono rimosse, le sottoscrizioni del sistema operativo possono essere sostituite o riutilizzate. Non è necessario pagare il doppio per le licenze del sistema operativo.

Passaggi successivi

Pianificare la distribuzione SAP.

Carichi di lavoro SAP in Azure: elenco di controllo per la pianificazione e la distribuzione