Carichi di lavoro SAP in Azure: elenco di controllo per la pianificazione e la distribuzione
Articolo
Questo elenco di controllo è progettato per i clienti che spostano le applicazioni SAP nell'infrastruttura distribuita come servizio di Azure. Le applicazioni SAP in questo documento rappresentano i prodotti SAP che eseguono il kernel SAP, tra cui SAP NetWeaver, S/4HANA, BW e BW/4 e altri. Per tutta la durata del progetto, un cliente e/o un partner SAP deve esaminare l'elenco di controllo. È importante notare che molti controlli vengono completati all'inizio del progetto e durante la fase di pianificazione. Dopo la distribuzione, modifiche semplici all'infrastruttura di Azure o alle versioni di software SAP distribuite possono diventare complesse.
Esaminare l'elenco di controllo in corrispondenza delle attività cardine principali durante il progetto. In questo modo sarà possibile rilevare piccoli problemi prima che diventino problemi di grandi dimensioni. Si avrà anche tempo sufficiente per riprogettare e testare le modifiche necessarie. Non considerare l'elenco di controllo completo. A seconda della situazione, potrebbe essere necessario eseguire ulteriori controlli.
L'elenco di controllo non include attività indipendenti da Azure. Ad esempio, le interfacce dell'applicazione SAP cambiano durante un passaggio alla piattaforma Azure o a un provider di hosting. La documentazione SAP e le note sul supporto conterranno anche altre attività, che non sono specifiche di Azure, ma devono far parte dell'elenco di controllo generale per la pianificazione.
Questo elenco di controllo può essere usato anche per i sistemi già distribuiti. Le nuove funzionalità o le raccomandazioni modificate potrebbero essere valide per l'ambiente in uso. È utile esaminare l'elenco di controllo periodicamente per essere sicuri di essere a conoscenza delle nuove funzionalità della piattaforma Azure.
Il contenuto principale di questo documento è organizzato in schede, in ordine cronologico di un progetto tipico. Vedere il contenuto di ogni scheda e prendere in considerazione ogni scheda successiva per la compilazione sulle azioni eseguite e sugli apprendimento ottenuti nella fase precedente. Per la migrazione di produzione, è necessario considerare il contenuto di tutte le schede e non solo della scheda di produzione. Per eseguire il mapping delle fasi tipiche del progetto con la definizione di fase usata in questo articolo, vedere la tabella seguente.
Fasi dell'elenco di controllo della distribuzione
Fasi o attività cardine del progetto di esempio
Fase di preparazione e pianificazione
Fase di avvio/progettazione e definizione del progetto
Fase pilota
Convalida anticipata/modello di verifica/progetto pilota
Fase non di produzione
Completamento della fase di progettazione dettagliata/compilazione dell'ambiente non di produzione/fase di test
Fase di preparazione alla produzione
Prove generali / test di accettazione utente / simulazione di cut-over / controlli go-live
Fase di go-live.
Cut-over e go-live della produzione
Fase di post-produzione
Hypercare/transizione all'azienda come di consueto
Fase di preparazione e pianificazione del progetto
Durante questa fase si pianifica la migrazione del carico di lavoro SAP alla piattaforma Azure. Documenti come la guida alla pianificazione per SAP in Azure e Cloud Adoption Framework per SAP illustrano molti argomenti e indicazioni come informazioni nella preparazione. Durante questa fase è necessario creare almeno i documenti seguenti, definire e discutere gli elementi seguenti della migrazione:
Documento di progettazione generale
Questo documento deve contenere:
L'inventario corrente dei componenti e delle applicazioni SAP e l'inventario delle applicazioni di destinazione per Azure.
Matrice di assegnazione delle responsabilità (RACI) che definisce le responsabilità e le assegnazioni delle parti coinvolte. Iniziare a livello generale e lavorare a livelli più granulari durante la pianificazione e le prime distribuzioni.
Architettura generale della soluzione. È consigliabile consultare le procedure consigliate e le architetture di esempio del Centro architetture di Azure.
Principi di sicurezza per l'esecuzione di dati con impatto aziendale elevato in Azure. Per informazioni sulla sicurezza dei dati, iniziare con la documentazione sulla sicurezza di Azure.
Strategia di archiviazione per coprire i dispositivi in blocchi (Disco gestito) e i file system condivisi (ad esempio File di Azure o Azure NetApp Files) che devono essere ulteriormente perfezionati in base alle dimensioni e ai layout del file system nel documento di progettazione tecnica.
Documento di progettazione tecnica
Questo documento deve contenere:
Diagramma a blocchi per la soluzione che mostra le applicazioni e i servizi SAP e non SAP
Progetto Quicksizer SAP basato su volumi di documenti aziendali. L'output di Quicksizer viene quindi mappato ai componenti di calcolo, archiviazione e rete in Azure. In alternativa a SAP Quicksizer, dimensionamento diligente in base al carico di lavoro corrente dei sistemi SAP di origine. Tenendo conto delle informazioni disponibili, ad esempio report del carico di lavoro DBMS, report SAP EarlyWatch, indicatori di prestazioni di calcolo e archiviazione.
Architettura per la continuità aziendale e il ripristino di emergenza.
Informazioni dettagliate sulle versioni del sistema operativo, del database, del kernel e del pacchetto di supporto SAP. Non è necessariamente vero che ogni versione del sistema operativo supportata da SAP NetWeaver o S/4HANA è supportata nelle macchine virtuali di Azure. La stessa considerazione vale per le versioni del sistema DBMS. Controllare le origini seguenti per allineare e, se necessario, aggiornare le versioni SAP, le versioni DBMS e le versioni del sistema operativo per garantire il supporto di SAP e Azure. È necessario disporre di combinazioni di versione supportate da SAP e Azure per ottenere il supporto completo da SAP e Microsoft. Se necessario, pianificare l'aggiornamento di alcuni dei componenti software. Altri dettagli sul software SAP, OS e DBMS supportati sono documentati qui:
Nota SAP 2039619. La nota definisce la matrice di supporto di Oracle per Azure. Oracle supporta solo Windows e Oracle Linux come sistemi operativi guest in Azure per carichi di lavoro SAP. Questa istruzione di supporto si applica anche per il livello applicazione SAP che esegue istanze SAP, purché contengano Oracle Client.
Le macchine virtuali di Azure supportate da SAP HANA sono elencate nel sito Web SAP. I dettagli per ogni voce contengono specifiche e requisiti, inclusa la versione del sistema operativo supportata. Questo potrebbe non corrispondere alla versione più recente del sistema operativo in base alla nota SAP 2235581.
Considerazioni sulla distribuzione DBMS di macchine virtuali di Azure per un carico di lavoro SAP e documenti correlati. In Azure, l'uso di una configurazione del disco condiviso per il livello DBMS, ad esempio, descritto per SQL Server, non è supportato. Usare invece soluzioni come:
Per il ripristino di emergenza tra aree di Azure, esaminare le soluzioni offerte da diversi fornitori DBMS. La maggior parte dei fornitori supporta la replica asincrona o il log shipping.
Per il livello applicazione SAP, definire se eseguire i sistemi di test di regressione disponibili in azienda, che teoricamente sono repliche delle distribuzioni di produzione, nella stessa area di Azure o nell'area di ripristino di emergenza. Nel secondo caso, è possibile specificare come destinazione il sistema di regressione aziendale come destinazione di ripristino di emergenza per le distribuzioni di produzione.
Per i progetti necessari per rimanere in una singola area per motivi di conformità, prendere in considerazione una configurazione HADR combinata usando le zone di disponibilità di Azure.
Inventario di tutte le interfacce SAP e dei sistemi connessi (SAP e non SAP).
Operazioni di sicurezza per risorse e carichi di lavoro di Azure all'interno
Concetto di sicurezza per la protezione del carico di lavoro SAP. Questo deve includere tutti gli aspetti, ovvero il monitoraggio di rete e perimetrale, la sicurezza delle applicazioni e del database, la protezione dei sistemi operativi e le eventuali misure dell'infrastruttura necessarie, ad esempio la crittografia. Identificare i requisiti con i team di conformità e sicurezza.
Microsoft consiglia il contratto Professional Direct, Premier o Unified Support. Identificare i percorsi di escalation e i contatti per il supporto con Microsoft. Per i requisiti di supporto SAP, vedere la nota SAP 2015553.
Piano di riduzione e migrazione dei dati per la migrazione dei dati SAP in Azure. Per i sistemi SAP NetWeaver, SAP include linee guida su come limitare il volume di grandi quantità di dati. Vedere questa guida SAP sulla gestione dei dati nei sistemi SAP ERP. Alcuni contenuti si applicano anche ai sistemi NetWeaver e S/4HANA in generale.
Un approccio di distribuzione automatizzato. Molti clienti iniziano con gli script, usando una combinazione di PowerShell, interfaccia della riga di comando, Ansible e Terraform.
Microsoft ha sviluppato soluzioni per l'automazione della distribuzione SAP:
SAP in Azure Deployment Automation uno strumento di orchestrazione open source per la distribuzione e la manutenzione degli ambienti SAP
Nota
Definire un piano per verificare con frequenza regolare la progettazione e la distribuzione insieme al cliente, all'integratore di sistemi, a Microsoft e a eventuali altre parti coinvolte.
Fase pilota (fortemente consigliata)
È possibile eseguire un progetto pilota prima o durante la pianificazione e la preparazione del progetto. È anche possibile usare la fase pilota per testare gli approcci e le progettazioni effettuate durante la fase di pianificazione e preparazione. Ed è possibile espandere la fase pilota per renderla un modello di verifica reale.
È consigliabile configurare e convalidare una soluzione HADR completa e una progettazione della sicurezza durante una distribuzione pilota. Alcuni clienti eseguono test di scalabilità durante questa fase. Altri clienti usano le distribuzioni dei sistemi sandbox SAP come fase pilota. Si presuppone che sia già stato identificato un sistema di cui si vuole eseguire la migrazione ad Azure per il progetto pilota.
Ottimizzare il trasferimento dei dati in Azure. La scelta ottimale dipende molto dallo scenario specifico. Se è necessaria la connettività privata per la replica del database, Azure ExpressRoute è più veloce se il circuito ExpressRoute ha una larghezza di banda sufficiente. In qualsiasi altro scenario, il trasferimento tramite Internet è più veloce. Facoltativamente, usare una VPN di migrazione dedicata per la connettività privata ad Azure. Qualsiasi percorso di rete di migrazione durante la fase pilota deve rispecchiare l'uso per i sistemi di produzione futuri, eliminando qualsiasi impatto sui carichi di lavoro, SAP o non SAP, già in esecuzione in Azure.
Per una migrazione SAP eterogenea che prevede un'esportazione e un'importazione di dati, testare e ottimizzare le fasi di esportazione e importazione. Per la migrazione di ambienti SAP di grandi dimensioni, seguire le procedure consigliate disponibili. Usare lo strumento appropriato per lo scenario di migrazione, a seconda delle versioni SAP di origine e di destinazione, DBMS e se si combina la migrazione con altre attività, ad esempio l'aggiornamento della versione o anche la conversione Unicode o S/4HANA. SAP fornisce Monitoraggio migrazione/SWPM, SAP DMO o DMO con lo spostamento del sistema, oltre ad altri approcci per ridurre al minimo i tempi di inattività disponibili come servizio separato da SAP. Nelle versioni più recenti di SAP DMO con spostamento del sistema, è supportato anche l'uso di AzCopy per il trasferimento dei dati tramite Internet, abilitando il percorso di rete più rapido in modo nativo.
Eseguire la migrazione di database di grandi dimensioni (VLDB) ad Azure per SAP
Verifica tecnica
Tipi di calcolo/VM
Esaminare le risorse nelle note sul supporto SAP, nella directory hardware di SAP HANA e di nuovo in SAP PAM. Assicurarsi di corrispondere alle macchine virtuali supportate per Azure, alle versioni del sistema operativo supportate per tali tipi di VM e alle versioni SAP e DBMS supportate.
Verificare nuovamente il dimensionamento dell'applicazione e dell'infrastruttura distribuite in Azure. Se si spostano applicazioni esistenti, è spesso possibile ricavare i valori SAPS necessari dall'infrastruttura in uso e dalla pagina Web dei benchmark SAP e confrontarli con i valori SAPS elencati nella nota SAP 1928533. Tenere presente anche questo articolo sulle valutazioni SAPS.
Valutare e testare il dimensionamento delle macchine virtuali di Azure per ottenere la velocità effettiva massima di archiviazione e rete dei tipi di VM scelti durante la fase di pianificazione. Sono disponibili dettagli sui limiti sulle prestazioni delle macchine virtuali; per l'archiviazione è importante considerare il limite di velocità effettiva massima del disco non memorizzato nella cache per il dimensionamento. Valutare attentamente le dimensioni e gli effetti temporanei del bursting a livello di disco e macchina virtuale.
Testare e determinare se si vogliono creare immagini del sistema operativo personalizzate per le macchine virtuali in Azure o se si vuole usare un'immagine dalla raccolta di calcolo di Azure (in precedenza nota come raccolta di immagini condivise). Se si usa un'immagine dalla raccolta di calcolo di Azure, assicurarsi di usare un'immagine che rifletta il contratto di supporto con il fornitore del sistema operativo. Per alcuni fornitori di sistemi operativi,Raccolta di calcolo di Azure consente di usare immagini di licenza personalizzate. Per altre immagini di sistema operativo, il supporto è incluso nel prezzo offerto da Azure.
L'uso di immagini del sistema operativo consente di archiviare le dipendenze aziendali necessarie, ad esempio agenti di sicurezza, protezione avanzata e personalizzazioni direttamente nell'immagine. In questo modo vengono distribuiti immediatamente con ogni macchina virtuale. Se si decide di creare immagini di sistema operativo personalizzate, è possibile trovare la documentazione in questi articoli:
Se si usano immagini Linux dalla raccolta di calcolo di Azure e si aggiunge la protezione avanzata come parte della pipeline di distribuzione, è necessario usare le immagini adatte per SAP fornito dai fornitori Linux.
La scelta di un'immagine del sistema operativo determina il tipo di generazione della macchina virtuale di Azure. Azure supporta le macchine virtuali Hyper-V di prima e seconda generazione. Alcune famiglie di macchine virtuali sono disponibili solo come seconda generazione, alcune famiglie di macchine virtuali sono certificate per l'uso SAP solo come seconda generazione (nota SAP 1928533) anche se Azure consente entrambe le generazioni. È consigliabile usare la macchina virtuale di seconda generazione per ogni macchina virtuale del panorama SAP.
Per i diversi tipi di sistemi DBMS, vedere la documentazione generica sui sistemi DBMS correlati a SAP e la documentazione specifica di DBMS a cui fa riferimento la documentazione generica. Usare lo striping del disco su più dischi con archiviazione Premium (v1 o v2) per i dati del database e l'area di log. Verificare che lo striping del disco lvm sia attivo e con dimensioni di striping corrette con il comando 'lvs -a -o+lv_layout,lv_role,strips,stripe_size,devices' in Linux, vedere proprietà degli spazi di archiviazione in Windows.
Usare LVM per tutti i dischi in macchine virtuali Linux, in quanto consente una gestione più semplice e un'espansione online. Sono inclusi i volumi su dischi singoli, ad esempio /usr/sap.
Networking
Testare e valutare l'infrastruttura di rete virtuale e la distribuzione delle applicazioni SAP attraverso o all'interno delle diverse reti virtuali di Azure.
Valutare l'approccio dell'architettura della rete virtuale hub-and-spoke o della rete WAN virtuale con spoke di rete virtuale discreti per il carico di lavoro SAP. Per una scala più piccola, l'approccio di micro-segmentazione all'interno di una singola rete virtuale di Azure. Basare questa valutazione su:
Vantaggi di una disconnessione rapida del peering tra reti virtuali di Azure anziché modificare il gruppo di sicurezza di rete per isolare una subnet all'interno di una rete virtuale. Questa valutazione è per i casi in cui le applicazioni o le macchine virtuali ospitate in una subnet della rete virtuale diventano un rischio per la sicurezza.
Registrazione e controllo del traffico di rete in maniera centralizzata tra l'ambiente locale, il mondo esterno e il data center virtuale creato in Azure.
Valutare e testare il percorso dei dati tra il livello dell'applicazione SAP e il livello DBMS SAP.
Il posizionamento di appliance virtuali di rete di Azure nel percorso di comunicazione tra l'applicazione SAP e il livello DBMS dei sistemi SAP che eseguono il kernel SAP non è supportato.
L'inserimento del livello applicazione SAP e del sistema di gestione di database (DBMS) in reti virtuali di Azure diverse senza peering non è supportato.
Assicurarsi che la rete accelerata sia abilitata in ogni macchina virtuale usata per SAP.
Testare e valutare la latenza di rete tra le macchine virtuali del livello applicazione SAP e le macchine virtuali DBMS in base alle note SAP 500235 e 1100926. Oltre al niping di SAP, è possibile usare strumenti come sockperf o ethr per la misurazione della latenza TCP. Valutare i risultati rispetto alle indicazioni sulla latenza di rete nella nota SAP 1100926. La latenza di rete deve essere compresa nell'intervallo da moderata a buona.
Ottimizzare la velocità effettiva di rete in macchine virtuali vCPU elevate, in genere usate per i server di database. Particolarmente importante per lo scale-out di HANA e per qualsiasi sistema SAP di grandi dimensioni. Seguire le raccomandazioni in questo articolo per l'ottimizzazione.
Per una latenza di rete ottimale, è consigliabile seguire le indicazioni riportate negli scenari di posizionamento di prossimità dell'articolo. Nessun utilizzo dei gruppi di posizionamento di prossimità per i modelli di distribuzione di zona o tra zone.
Verificare la disponibilità, il routing e l'accesso sicuro dal panorama SAP a qualsiasi endpoint Internet necessario, ad esempio repository patch del sistema operativo, strumenti di distribuzione o endpoint di servizio. Analogamente, se l'ambiente SAP fornisce un servizio accessibile pubblicamente, ad esempio SAP Fiori o SAProuter, verificare che sia raggiungibile e protetto.
Distribuzioni per la disponibilità elevata e il ripristino di emergenza
Usare sempre il servizio di bilanciamento del carico standard per gli ambienti in cluster. Il servizio di bilanciamento del carico Basic verrà ritirato.
Selezionare le opzioni di distribuzione appropriate a seconda della configurazione del sistema preferita all'interno di un'area di Azure, indipendentemente dal fatto che si tratti di estendersi tra zone, che si trovano all'interno di una singola zona o che operano in un'area senza zona.
Nella distribuzione a livello di area, per proteggere i servizi centrali SAP e i livelli DBMS per la disponibilità elevata usando la replica passiva, posizionare i due nodi per SAP Central Services in un set di disponibilità separato e i due nodi DBMS in un altro set di disponibilità. Non combinare i ruoli della macchina virtuale dell'applicazione all'interno di un set di disponibilità.
Per la distribuzione tra zone, configurare il sistema usando un set di scalabilità flessibile con FD=1 e distribuire i nodi dei servizi centrali attivi e passivi e il livello DBMS in due diverse zone di disponibilità. Usare due zone di disponibilità con la latenza più bassa tra di esse.
Per la distribuzione tra zone, è consigliabile usare un set di scalabilità flessibile con FD=1 rispetto alla distribuzione della zona di disponibilità standard.
Se si usa Azure Load Balancer insieme ai sistemi operativi guest Linux, verificare che il parametro di rete Linux net.ipv4.tcp_timestamps sia impostato su 0. Questa raccomandazione è in conflitto con le raccomandazioni nelle versioni precedenti della nota SAP 2382421. La nota SAP viene ora aggiornata per indicare che questo parametro deve essere impostato su 0 per l'uso con i servizi di bilanciamento del carico di Azure.
Impostazioni di timeout
Controllare le tracce degli sviluppatori SAP NetWeaver delle istanze SAP per assicurarsi che non siano presenti interruzioni di connessione tra il server di accodamento e i processi di lavoro SAP. È possibile evitare queste interruzioni di connessione impostando i due parametri del Registro di sistema seguenti:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Per altre informazioni, vedere KeepAliveTime.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Per altre informazioni, vedere KeepAliveInterval.
Per evitare timeout tra le interfacce utente grafiche di SAP distribuite in locale e i livelli applicazione SAP distribuiti in Azure, verificare se in default.pfl o nel profilo dell'istanza sono impostati questi parametri:
rdisp/keepalive_timeout = 3600
rdisp/keepalive = 20
Per evitare interruzioni delle connessioni stabilite tra il processo di accodamento SAP e i processi di lavoro SAP, è necessario impostare il parametro enque/encni/set_so_keepalive su TRUE. Vedere anche la nota SAP 2743751.
Se si usa una configurazione di cluster di failover Windows, assicurarsi che il tempo necessario per reagire in caso di mancata risposta dei nodi sia impostato correttamente per Azure. L'articolo Tuning Failover Cluster Network Thresholds (Ottimizzazione delle soglie di rete dei cluster di failover) include l'elenco dei parametri e descrive come questi influiscono sulla sensibilità del failover. Supponendo che i nodi del cluster si trovino nella stessa subnet, è necessario modificare questi parametri:
SameSubNetDelay = 2000 (numero di millisecondi tra "heartbeat")
SameSubNetThreshold = 15 (numero massimo di heartbeat mancati consecutivi)
Per l'esecuzione di HANA in SAP, leggere queste note e documentazione, oltre alla documentazione non specifica di SAP e ad altre note sul supporto:
Note SAP specifiche di Azure collegate ai componenti di supporto SAP BC-OP-NT-AZR o BC-OP-LNX-AZR. Esaminare le note in dettaglio in quanto contengono soluzioni aggiornate
Testare le procedure per la disponibilità elevata e il ripristino di emergenza
Simulare situazioni di failover usando uno strumento come NotMyFault (Windows) o inserendo i sistemi operativi in modalità panic o disabilitando l'interfaccia di rete con ifdown (Linux). Questo passaggio consente di determinare se le configurazioni di failover funzionano come previsto.
Misurare il tempo necessario per eseguire un failover. Se il tempo è eccessivo, valutare se eseguire queste operazioni:
Per SUSE Linux, usare i dispositivi SBD anziché l'agente di isolamento di Azure per accelerare il failover.
Per SAP HANA, se è necessario troppo tempo per ricaricare i dati, valutare l'opportunità di effettuare il provisioning di maggiore larghezza di banda di archiviazione.
Testare la sequenza di backup/ripristino e la tempistica e apportare correzioni se necessario. Assicurarsi che i tempi di backup siano sufficienti. È anche necessario testare le attività di ripristino e ripristino in tempo. Accertarsi che i tempi di ripristino siano compresi nei contratti di servizio relativi all'obiettivo del tempo di ripristino, in cui quest'ultimo viene calcolato in base a un processo di ripristino di un database o di una macchina virtuale.
Testare la funzionalità e l'architettura del ripristino di emergenza tra aree, verificare che RPO e RTO corrispondano alle aspettative
Controlli di sicurezza
Testare la validità dell'architettura del controllo degli accessi in base al ruolo di Azure (Azure RBAC). La separazione dei compiti richiede di separare e limitare l'accesso e le autorizzazioni di team diversi. Ad esempio, i membri del team di SAP Basis devono essere in grado di distribuire macchine virtuali e assegnare dischi dall'Archiviazione di Azure a una determinata macchina virtuale di Azure. Tuttavia, il team SAP Basis non deve essere in grado di creare proprie reti virtuali o modificare le impostazioni di reti virtuali esistenti. I membri del team di rete non devono essere in grado di distribuire le macchine virtuali in reti virtuali in cui sono in esecuzione le macchine virtuali SAP e DBMS. Inoltre, i membri non di questo team non devono essere in grado di modificare gli attributi delle macchine virtuali o addirittura eliminare macchine virtuali o dischi.
Assicurarsi che tutte le risorse che devono essere crittografate lo siano effettivamente. Definire ed attuare processi per eseguire il backup dei certificati, archiviare e accedere a tali certificati e ripristinare le entità crittografate.
Per la crittografia dell'archiviazione, la crittografia lato server con chiave gestita dalla piattaforma (SSE-PMK) è abilitata per ogni servizio di archiviazione usato per SAP in Azure per impostazione predefinita, inclusi dischi gestiti, File di Azure e Azure NetApp Files. La gestione delle chiavi con chiavi gestite dal cliente può essere considerata, se necessario per la rotazione delle chiavi di proprietà del cliente.
La crittografia nativa del database viene distribuita dalla maggior parte dei clienti SAP in Azure per proteggere i dati e i backup DBMS. Transparent Data Encryption (TDE) in genere non presenta un notevole sovraccarico delle prestazioni, aumenta notevolmente la sicurezza e deve essere considerato. La gestione e la posizione delle chiavi di crittografia devono essere protette. La crittografia del database si verifica all'interno della macchina virtuale ed è indipendente da qualsiasi crittografia di archiviazione, ad esempio SSE.
I test delle prestazioni in SAP, in base alla traccia e alle misurazioni SAP, effettuano questi confronti:
Inventario e baseline del sistema locale corrente.
Report SAR/perfmon.
Traccia STAT primi 10 report online.
Raccogliere la cronologia dei processi batch.
Test incentrati sulla verifica delle prestazioni dei processi aziendali. Non confrontare gli indicatori KPI hardware inizialmente e in un vuoto, solo durante la risoluzione di eventuali differenze di prestazioni.
Se applicabile, confrontare i primi 10 report online con l'implementazione corrente.
Se applicabile, confrontare i primi 10 processi batch con l'implementazione corrente.
Confrontare i trasferimenti di dati tramite interfacce nel sistema SAP. Prestare particolare attenzione alle interfacce in cui è noto che il trasferimento avvenga tra posizioni diverse, ad esempio dal sistema locale ad Azure.
Fase non di produzione
In questa fase si presuppone che, dopo l'esito positivo di un progetto pilota o di un modello di verifica (POC), si inizi a distribuire sistemi SAP non di produzione in Azure. Incorporare tutti gli elementi appresi e sperimentati durante il modello di verifica per questa distribuzione. Tutti i criteri e i passaggi elencati per i POC si applicano anche a questa distribuzione.
Durante questa fase, in genere si distribuiscono in Azure i sistemi di sviluppo, i sistemi di unit test e i sistemi di test di regressione aziendali. È consigliabile configurare per la disponibilità elevata almeno un sistema non di produzione in una linea applicativa SAP poiché il futuro sistema di produzione avrà questo tipo di configurazione. Ecco alcune attività da completare durante questa fase:
Prima di spostare i sistemi dalla piattaforma precedente ad Azure, raccogliere i dati sull'utilizzo delle risorse, come l'utilizzo della CPU, la velocità effettiva di archiviazione e le operazioni di I/O al secondo. In particolare, raccogliere questi dati dalle unità del livello DBMS, ma anche dalle unità del livello applicazione. Misurare anche la latenza di rete e di archiviazione. Adattare il ridimensionamento e la progettazione con i dati acquisiti. È consigliabile usare strumenti come syststat, KSAR, nmon e nmon analyzer per Excel per acquisire e presentare l'utilizzo delle risorse nei periodi di picco.
Registrare i ritmi temporali di utilizzo della disponibilità dei sistemi. L'obiettivo è di determinare se i sistemi non di produzione devono essere disponibili tutto il giorno tutti i giorni, o se alcuni sistemi non di produzione possono essere arrestati durante alcuni periodi di una settimana o di un mese.
Rivalutare la scelta dell'immagine del sistema operativo, la generazione di macchine virtuali (generazione 2 nel panorama applicativo SAP) e la strategia di patch del sistema operativo.
Assicurarsi di soddisfare i requisiti di supporto SAP per i contratti di supporto Microsoft. Vedere la nota SAP 2015553.
Controllare le note SAP correlate ad Azure, ad esempio la nota 1928533 per nuovi SKU di macchine virtuali o nuove versioni del sistema operativo o DBMS supportate. Confrontare i prezzi dei nuovi tipi di VM rispetto a quelli dei tipi di VM meno recenti, in modo da poter distribuire le macchine virtuali con il miglior rapporto prezzo/prestazioni.
Controllare di nuovo le note sul supporto SAP, la directory hardware di SAP HANA e SAP PAM. Assicurarsi che non siano state apportate modifiche alle macchine virtuali supportate per Azure, alle versioni del sistema operativo supportate in tali macchine virtuali e alle versioni SAP e DBMS supportate.
Controllare il sito Web SAP per i nuovi SKU certificati HANA in Azure. Confrontare i prezzi dei nuovi SKU con quelli che si prevede di usare. Infine, apportare le modifiche necessarie per usare quelle con il miglior rapporto prezzo/prestazioni.
Adattare l'automazione della distribuzione per usare nuovi tipi di VM e incorporare nuove funzionalità di Azure da usare.
Dopo la distribuzione dell'infrastruttura, testare e valutare la latenza di rete tra le macchine virtuali del livello applicazione SAP e le macchine virtuali DBMS, in base alle note SAP 500235. Valutare i risultati rispetto alle indicazioni sulla latenza di rete nella nota SAP 1100926. La latenza di rete deve essere compresa nell'intervallo da moderata a buona. Oltre a usare strumenti come niping, sockperf o ethr, usare lo strumento HCMT di SAP per le misurazioni di rete tra macchine virtuali HANA per la replica di scale-out o di sistema.
Se viene visualizzata una latenza superiore al previsto tra le macchine virtuali, prendere in considerazione le indicazioni riportate negli scenari di posizionamento di prossimità dell'articolo.
Eseguire tutti gli altri controlli elencati per la fase di verifica prima di applicare il carico di lavoro.
Come si applica il carico di lavoro, registrare l'utilizzo delle risorse dei sistemi in Azure. Confrontare questo consumo con i record della piattaforma precedente. Se si notano differenze significative, regolare il dimensionamento delle macchine virtuali per le future distribuzioni. Tenere presente che quando si riducono le dimensioni, l'archiviazione e la larghezza di banda di rete delle macchine virtuali verranno ridotte.
Sperimentare le funzionalità e i processi di copia del sistema. L'obiettivo è di semplificare la copia di un sistema di sviluppo o di test in modo che i team di progetto possano ottenere rapidamente i nuovi sistemi.
Ottimizzare e affinare l'accesso, le autorizzazioni e i processi in base al ruolo di Azure del team per assicurarsi di avere la separazione dei compiti. Allo stesso tempo, assicurarsi che tutti i team possano eseguire le attività nell'infrastruttura di Azure.
Provare, testare e documentare le procedure per la disponibilità elevata e il ripristino di emergenza per consentire al personale di eseguire tali attività. Identificare i punti deboli e adattare le nuove funzionalità di Azure che si è deciso di integrare nelle proprie distribuzioni.
Fase di preparazione alla produzione
In questa fase, raccogliere ciò che si è appreso durante le distribuzioni non di produzione e applicarlo alle future distribuzioni di produzione.
Prima di andare ad Azure, eseguire tutti gli aggiornamenti delle versioni SAP necessari per i sistemi di produzione.
Accordarsi con i proprietari dell'azienda riguardo ai test funzionali e aziendali da eseguire dopo la migrazione del sistema di produzione.
Verificare che questi test vengano completati con i sistemi di origine nella posizione di hosting corrente. Evitare di eseguire test per la prima volta dopo che il sistema viene spostato in Azure.
Testare il processo di migrazione dei sistemi di produzione ad Azure. Se non si spostano tutti i sistemi di produzione in Azure nello stesso intervallo di tempo, creare gruppi di sistemi di produzione che devono trovarsi nella stessa posizione di hosting. Testare la migrazione dei dati, incluse le applicazioni e le interfacce non SAP connesse.
Ecco alcuni metodi comuni:
Usare i metodi DBMS, ad esempio backup e ripristino in combinazione con SQL Server AlwaysOn, HANA System Replication o Log shipping per effettuare il seeding del contenuto di database e sincronizzarlo in Azure.
Usare Backup/Ripristino per i database di dimensioni ridotte.
Usare il processo SAP DMO per gli scenari supportati per spostare o se è necessario combinare la migrazione con un aggiornamento della versione SAP e/o andare a HANA. Tenere presente che non tutte le combinazioni di DBMS di origine e di destinazione sono supportate. Per altre informazioni, vedere le note di supporto SAP specifiche per le diverse versioni di DMO. Ad esempio, Database Migration Option (DMO) di SUM 2.0 SP15.
Verificare se il trasferimento dei dati è migliore attraverso Internet o tramite ExpressRoute in termini di velocità effettiva nel caso in cui sia necessario spostare i backup o file di esportazione di SAP. Se si spostano dati tramite Internet, potrebbe essere necessario modificare alcune delle regole del gruppo di sicurezza di rete o del gruppo di sicurezza delle applicazioni necessarie per i sistemi di produzione futuri.
Prima di spostare i sistemi dalla piattaforma precedente ad Azure, raccogliere i dati sull'utilizzo delle risorse. I dati utili includono l'utilizzo della CPU, la velocità effettiva di archiviazione e i dati delle operazioni di I/O al secondo. In particolare, raccogliere questi dati dalle unità del livello DBMS, ma anche dalle unità del livello applicazione. Misurare anche la latenza di rete e di archiviazione.
Controllare di nuovo le note SAP e le impostazioni del sistema operativo necessarie, la directory hardware SAP HANA e SAP PAM. Assicurarsi che non siano state apportate modifiche alle macchine virtuali supportate per Azure, alle versioni del sistema operativo supportate in tali macchine virtuali e alle versioni SAP e DBMS supportate.
Aggiornare l'automazione della distribuzione per prendere in considerazione le decisioni più recenti prese sui tipi di VM e sulle funzionalità di Azure.
Creare un playbook per reagire agli eventi di manutenzione pianificata di Azure. Determinare l'ordine in cui i sistemi e le macchine virtuali devono essere riavviati per la manutenzione pianificata.
Esercizio, test e documentazione di procedure di disponibilità elevata e ripristino di emergenza per consentire al personale di eseguire queste attività durante la migrazione e immediatamente dopo la decisione in tempo reale.
Fase di go-live.
Durante la fase go-live, assicurarsi di seguire i playbook sviluppati durante le fasi precedenti. Eseguire i passaggi sottoposti a test e praticati. Non accettare modifiche dell'ultimo minuto alle configurazioni e ai processi. Completare inoltre i seguenti passaggi:
Verificare il corretto funzionamento del monitoraggio del portale di Azure e di altri strumenti di monitoraggio. Usare strumenti di Azure come Monitoraggio di Azure per il monitoraggio dell'infrastruttura. Monitoraggio di Azure per SAP per una combinazione di indicatori KPI del sistema operativo e dell'applicazione, che consente di integrare tutti in un unico dashboard per la visibilità durante e dopo il passaggio in tempo reale.
Per gli indicatori di prestazioni chiave del sistema operativo:
In Linux assicurarsi che lo strumento sysstat sia installato e acquisisca i dettagli a intervalli regolari
Dopo la migrazione dei dati, eseguire tutti i test di convalida concordati con i proprietari dell'azienda. Accettare i risultati dei test di convalida solo se i risultati riguardano i sistemi di origine originali.
Controllare se le interfacce funzionano e se altre applicazioni possono comunicare con i nuovi sistemi di produzione distribuiti.
Verificare il sistema di trasporto e correzione tramite STMS transazione SAP.
Eseguire i backup dei database dopo che il sistema è stato rilasciato per la produzione.
Eseguire i backup delle macchine virtuali del livello applicazione SAP dopo che il sistema è stato rilasciato per la produzione.
Per i sistemi SAP che non fanno parte della fase operativa corrente, ma che comunicano con i sistemi SAP di cui è stata eseguita la migrazione in Azure in questa fase operativa, è necessario reimpostare il buffer dei nomi host in SM51. In tal modo si elimineranno i precedenti indirizzi IP memorizzati nella cache associati ai nomi delle istanze di applicazione che sono state spostate in Azure.
Post-produzione
Questa fase riguarda il monitoraggio, il funzionamento e l'amministrazione del sistema. Da un punto di vista SAP, sono previste le normali attività che era necessario eseguire nella precedente posizione di hosting. Completare anche queste attività specifiche di Azure:
Rivedere le fatture di Azure per i sistemi con tariffazione elevata. Installare le impostazioni cultura di finOps e creare una funzionalità di ottimizzazione dei costi di Azure nell'organizzazione.
Ottimizzare il rapporto prezzo/prestazioni sul lato macchine virtuali e sul lato archiviazione.
Una volta stabilizzato SAP in Azure, l'attenzione deve andare a una cultura delle revisioni continue del ridimensionamento e della capacità. A differenza dell'ambiente locale, in cui le dimensioni per un lungo periodo di ridimensionamento sono un vantaggio fondamentale per l'esecuzione di SAP nel carico di lavoro di Azure e la pianificazione della capacità diligente sarà fondamentale.
Ottimizzare i tempi in cui è possibile arrestare i sistemi.
Una volta stabilizzata la soluzione in Azure, è consigliabile allontanarsi da un modello commerciale con pagamento in base al consumo e sfruttare le istanze riservate di Azure.
Pianificare ed eseguire normali esercitazioni sul ripristino di emergenza.
Definire e implementare la strategia relativa al "ever-greeneing", per allineare la propria roadmap con la roadmap di Microsoft SAP on Azure per trarre vantaggio dal progresso della tecnologia.
Elenco di controllo per SAP nell'infrastruttura di Azure
Dopo aver distribuito l'infrastruttura e le applicazioni e prima dell'avvio di ogni migrazione, verificare che:
Sono stati distribuiti i tipi di macchina virtuale corretti, con gli attributi e la configurazione di archiviazione corretti.
Le macchine virtuali si trovano in un sistema operativo, DBMS e versione kernel SAP e patch aggiornati e il sistema operativo, il database e il kernel SAP sono uniformi in tutto il panorama orizzontale
Le macchine virtuali sono protette e protette in base alle esigenze e in modo uniforme nel rispettivo ambiente.
Le macchine virtuali di seconda generazione sono state distribuite. Le macchine virtuali di seconda generazione non devono essere usate per le nuove distribuzioni.
Assicurarsi che, all'interno delle macchine virtuali, degli spazi di archiviazione o dei set di striping siano stati compilati correttamente nei file system che richiedono più dischi, ad esempio le aree di dati e log DBMS.
Vengono usate le dimensioni di striping corrette e i blocchi del file system, se annotati nelle rispettive guide DBMS
L'archiviazione e la memorizzazione nella cache delle macchine virtuali di Azure vengono usate in modo appropriato
Assicurarsi che solo i dischi che contengono i log online DBMS siano memorizzati nella cache con l'acceleratore di scrittura none+.
Altri dischi con archiviazione Premium usano le impostazioni della cache none o ReadOnly, a seconda dell'uso
Uso dei servizi di Azure, Ovvero File di Azure o Azure NetApp Files, per qualsiasi volume o condivisione SMB o NFS. I volumi NFS o le condivisioni SMB sono raggiungibili dal rispettivo ambiente SAP o dai singoli sistemi SAP. Il routing di rete al server NFS/SMB passa attraverso lo spazio di indirizzi di rete privato, usando l'endpoint privato, se necessario.
La rete accelerata di Azure è abilitata in ogni interfaccia di rete per tutte le macchine virtuali SAP.
Nessuna appliance virtuale di rete si trova nel percorso di comunicazione tra l'applicazione SAP e il livello DBMS dei sistemi SAP basati su SAP NetWeaver o ABAP Platform.
Tutti i servizi di bilanciamento del carico per i componenti SAP a disponibilità elevata usano il servizio di bilanciamento del carico standard con porte a disponibilità elevata e IP mobile abilitate.
Le macchine virtuali SAP e DBMS vengono posizionate nella stessa subnet o in subnet diverse di una rete virtuale o in reti virtuali con peering diretto.
Le regole del gruppo di sicurezza di rete e dell'applicazione consentono la comunicazione in base alle esigenze e pianificate e bloccano la comunicazione, se necessario.
Le impostazioni di timeout vengono impostate correttamente, come descritto in precedenza.
Se si usano gruppi di posizionamento di prossimità, verificare se i set di disponibilità e le macchine virtuali vengono distribuiti nel PPG corretto.
La latenza di rete tra macchine virtuali a livello di applicazione SAP e macchine virtuali DBMS viene testata e convalidata come descritto nelle note SAP 500235 e 1100926. Valutare i risultati rispetto alle indicazioni sulla latenza di rete nella nota SAP 1100926. La latenza di rete deve essere compresa nell'intervallo da moderata a buona.
La crittografia è stata implementata se necessario e con il metodo di crittografia appropriato.
Le proprie chiavi di crittografia sono protette da perdita, distruzione o uso dannoso.
Le interfacce e le altre applicazioni possono connettersi alla nuova infrastruttura distribuita.
Controlli e informazioni dettagliate automatizzati nel panorama applicativo SAP
Diversi controlli precedenti vengono controllati in modo automatico con lo Strumento di verifica della qualità SAP in Azure. Questi controlli possono essere eseguiti automaticamente con il progetto open source fornito. Anche se non viene eseguita alcuna correzione automatica dei problemi rilevati, lo strumento avvisa la configurazione rispetto alle raccomandazioni Microsoft.
Sono disponibili altri strumenti per semplificare i controlli di distribuzione e documentare i risultati, pianificare i passaggi di correzione successivi e in genere ottimizzare SAP nel panorama di Azure:
Revisione di Azure Well-Architected Framework Una valutazione del carico di lavoro incentrato sui cinque pilastri principali dell'affidabilità, della sicurezza, dell'ottimizzazione dei costi, dell'eccellenza operativa e dell'efficienza delle prestazioni. Supporta i carichi di lavoro SAP e consiglia di eseguire una revisione all'avvio e dopo ogni fase del progetto.
Controlli inventario di Azure per SAP Una cartella di lavoro open source di Monitoraggio di Azure, che mostra l'inventario di Azure con intelligenza per evidenziare la deriva della configurazione e migliorare la qualità.