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. Al termine della distribuzione, le modifiche semplici nell'infrastruttura di Azure distribuita o nelle versioni software SAP 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 riprogezionare 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 periodicamente l'elenco di controllo per assicurarsi di conoscere le nuove funzionalità nella 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, il contenuto di tutte le schede deve essere considerato e non solo 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 di vestito/test di accettazione utente/mock cut-over/controlli go-live
Fase di go-live.
Produzione cut-over e go-live
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 guida 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 di componenti e applicazioni SAP e un 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.
Architettura di rete per connettersi dall'ambiente locale ad Azure. Iniziare a acquisire familiarità con il concetto di zona di destinazione su scala aziendale di Azure.
Principi di sicurezza per l'esecuzione di dati aziendali ad alto impatto in Azure. Per informazioni sulla sicurezza dei dati, iniziare con la documentazione sulla sicurezza di Azure.
Archiviazione strategia per coprire i dispositivi in blocchi (Managed Disk) 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 di continuità aziendale e 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. Lo stesso vale per le versioni 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 SAP e supporto tecnico di Azure. È necessario disporre di combinazioni di versione supportate da SAP e Azure per ottenere il supporto completo da SAP e Microsoft. Se necessario, è necessario pianificare l'aggiornamento di alcuni componenti software. Altri dettagli sul software SAP, os e DBMS supportati sono documentati qui:
Nota SAP 2039619. Questa nota definisce la matrice di supporto 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.
Layout e dimensioni del volume SMB e/o NFS, punti di montaggio, se applicabile
Architettura di disponibilità elevata, backup e ripristino di emergenza
In base a RTO e RPO, definire l'aspetto dell'architettura di disponibilità elevata e ripristino di emergenza.
Comprendere l'uso di diversi tipi di distribuzione per una protezione ottimale.
Considerazioni sulla distribuzione di DBMS Macchine virtuali di Azure per carichi 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 di esse supporta la replica asincrona o il log shipping.
Per il livello dell'applicazione SAP, determinare se verranno eseguiti i sistemi di test di regressione aziendale, che idealmente 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.
Esaminare Azure Site Recovery come metodo per replicare il livello dell'applicazione SAP nell'area di ripristino di emergenza di Azure. Per altre informazioni, vedere un ripristino di emergenza configurato per una distribuzione di app SAP NetWeaver multilivello.
Per i progetti necessari per rimanere in una singola area per motivi di conformità, prendere in considerazione una configurazione HADR combinata usando Azure zone di disponibilità.
Inventario di tutte le interfacce SAP e dei sistemi connessi (SAP e non SAP).
Progettazione dei servizi di base. Questa progettazione deve includere gli elementi seguenti, molti dei quali sono coperti dall'acceleratore di zona di destinazione per SAP:
Topologia di rete all'interno di Azure e assegnazione di un ambiente SAP diverso
Progettazione di Active Directory e DNS.
Soluzione di gestione delle identità per utenti finali e amministrazione
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.
Riduzione dei dati e piano di 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 Automazione della distribuzione di Azure, uno strumento di orchestrazione open source per la distribuzione e la gestione degli ambienti SAP
Nota
Definire una regolare cadenza di progettazione e revisione della distribuzione tra il cliente, l'integratore di sistemi, Microsoft e altre parti interessate.
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 di 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
Convalida 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 derivare la S piattaforma di strumenti analitici necessaria dall'infrastruttura usata e dalla pagina Web del benchmark SAP e confrontarla con i numeri S piattaforma di strumenti analitici elencati nella nota SAP 1928533. Tenere presente anche questo articolo sulle valutazioni di S piattaforma di strumenti analitici.
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 di 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, Azure Compute Gallery consente di usare immagini di licenza personalizzate. Per altre immagini del sistema operativo, il supporto è incluso nel prezzo quotato 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 del 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. supporto tecnico di Azure entrambi Macchine virtuali hyper-V di prima e 2 generazione. Alcune famiglie di macchine virtuali sono disponibili solo come generazione 2, alcune famiglie di macchine virtuali sono certificate per l'uso SAP solo come generazione 2 (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.
Usare almeno l'archiviazione SSD standard di Azure per le macchine virtuali che rappresentano i livelli dell'applicazione SAP e per la distribuzione di DBMS che non sono sensibili alle prestazioni. Tenere presente che i diversi tipi di archiviazione di Azure influisce sul contratto di servizio per la disponibilità delle singole macchine virtuali.
In generale, non è consigliabile usare dischi HDD Standard di Azure per SAP.
Per i diversi tipi DBMS, vedere la documentazione DBMS correlata a SAP generica e la documentazione specifica di DBMS a cui punta il primo documento. 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.
Per una configurazione di archiviazione ottimale con SAP HANA, vedere Configurazioni di archiviazione delle macchine virtuali di Azure sap HANA.
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.
Funzionalità di rete
Testare e valutare l'infrastruttura di rete virtuale e la distribuzione delle applicazioni SAP tra o all'interno delle diverse reti virtuali di Azure.
Valutare l'approccio dell'architettura della rete virtuale hub-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 centrale e controllo del traffico di rete tra l'ambiente locale, il mondo esterno e il data center virtuale incorporato 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.
Il posizionamento del livello dell'applicazione SAP e di SAP DBMS in reti virtuali di Azure diverse che non sono sottoposte a peering non è supportato.
È possibile usare le regole del gruppo di sicurezza delle applicazioni e del gruppo di sicurezza di rete per proteggere i percorsi di comunicazione da e verso il livello dell'applicazione SAP e il livello SAP DBMS.
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 nell'intervallo moderato o valido.
Ottimizzare la velocità effettiva di rete in macchine virtuali vCPU elevate, in genere usate per i server di database. Particolarmente importante per la scalabilità orizzontale 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 a disponibilità elevata e 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 questi due parametri del Registro di sistema:
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 dell'interfaccia utente grafica GRAFICA tra le interfacce GUI SAP locali e i livelli dell'applicazione SAP distribuiti in Azure, verificare se questi parametri sono impostati nel file default.pfl o nel profilo dell'istanza:
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 del cluster di failover di Windows, assicurarsi che il tempo necessario per reagire nei nodi non reattivi sia impostato correttamente per Azure. L'articolo Ottimizzazione delle soglie di rete del cluster di failover elenca i parametri e il modo in cui influiscono sulle sensibilità al 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 di disponibilità elevata e 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 SU edizione Standard Linux, usare i dispositivi SBD anziché l'agente di Isolamento di Azure per velocizzare il failover.
Per SAP HANA, se il ricaricamento dei dati richiede troppo tempo, prendere in considerazione il provisioning di una 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. Assicurarsi che i tempi di ripristino si trovino nei contratti di servizio RTO ovunque l'RTO si basi su un processo di ripristino di database o 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. La separazione dei compiti richiede di separare e limitare l'accesso e le autorizzazioni di team diversi. Ad esempio, i membri del team SAP Basis devono essere in grado di distribuire le macchine virtuali e assegnare dischi da Archiviazione di Azure in una determinata macchina virtuale di Azure. Tuttavia, il team SAP Basis non deve essere in grado di creare le proprie reti virtuali o di modificare le impostazioni delle 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. Né i membri di questo team possono modificare gli attributi delle macchine virtuali o persino eliminare macchine virtuali o dischi.
Verificare che le regole del gruppo di sicurezza di rete e del gruppo di sicurezza di rete funzionino come previsto e schermate le risorse protette.
Assicurarsi che tutte le risorse che devono essere crittografate lo siano effettivamente. Definire e implementare processi per eseguire il backup di 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 (S edizione Standard-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 lato server basata su host non deve essere abilitata per motivi di prestazioni nelle macchine virtuali Linux della famiglia M.
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 S edizione Standard.
I test delle prestazioni in SAP, in base alla traccia e alle misurazioni SAP, effettuano questi confronti:Performance testing In SAP, based on SAP tracing and measurements, make these comparisons:
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. Concentrarsi sulle interfacce in cui si sa che il trasferimento si sta spostando tra posizioni diverse, ad esempio dall'ambiente locale ad Azure.
Fase non di produzione
In questa fase si presuppone che, dopo un progetto pilota o un modello di verifica riuscito, 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 sistemi di sviluppo, sistemi di testing unità e sistemi di test di regressione aziendale in Azure. È consigliabile che almeno un sistema non di produzione in una riga dell'applicazione SAP abbia la configurazione a disponibilità elevata completa che il sistema di produzione futuro avrà. Ecco alcune attività da completare durante questa fase:
Prima di spostare i sistemi dalla piattaforma precedente ad Azure, raccogliere dati sull'utilizzo delle risorse, ad esempio utilizzo della CPU, velocità effettiva di archiviazione e dati di I/O al secondo. In particolare, raccogliere questi dati dalle unità di livello DBMS, ma anche raccoglierli dalle unità 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 modelli di tempo di utilizzo della disponibilità dei sistemi. L'obiettivo è determinare se i sistemi non di produzione devono essere disponibili tutti i giorni, ogni giorno o se sono presenti sistemi non di produzione che possono essere arrestati durante determinate fasi 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.
Vedere le note SAP correlate ad Azure, come si noti 1928533, per i nuovi SKU di MACCHINE virtuali e le versioni di sistema operativo e DBMS appena 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 nell'intervallo moderato o valido. 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 scalabilità orizzontale 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. Modificare il ridimensionamento delle macchine virtuali delle distribuzioni future se si noterà che sono presenti grandi differenze. 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 è semplificare la copia di un sistema di sviluppo o di un sistema di test, in modo che i team di progetto possano ottenere rapidamente 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.
Esercizio, test e documentazione di procedure di disponibilità elevata e ripristino di emergenza per consentire al personale di eseguire queste attività. Identificare le carenze e adattare nuove funzionalità di Azure integrate nelle 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.
Completare gli aggiornamenti delle versioni SAP necessari dei sistemi di produzione prima di passare ad Azure.
Accettare i proprietari dell'azienda sui test funzionali e aziendali che devono essere eseguiti dopo la migrazione del sistema di produzione.
Assicurarsi che questi test siano 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 metodi DBMS come backup/ripristino in combinazione con SQL Server Always On, replica di sistema HANA o log shipping per eseguire il seeding e sincronizzare il contenuto del database in Azure.
Usare il backup/ripristino per database più piccoli.
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 passare a HANA. Tenere presente che non tutte le combinazioni di DBMS di origine e DBMS di destinazione sono supportate. Per altre informazioni, vedere le note specifiche sul supporto SAP per le diverse versioni di DMO. Ad esempio, Opzione di migrazione del database (DMO) di SUM 2.0 SP15.
Verificare se la velocità effettiva del trasferimento dei dati è migliore tramite Internet o tramite ExpressRoute, nel caso in cui sia necessario spostare i backup o i file di esportazione 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à di livello DBMS, ma anche raccoglierli dalle unità 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 testati e praticati. Non accettare modifiche dell'ultimo minuto nelle configurazioni e nei processi. Completare anche questi 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 quando si hanno risultati per i sistemi di origine originali.
Controllare se le interfacce funzionano e se altre applicazioni possono comunicare con i nuovi sistemi di produzione distribuiti.
Controllare il sistema di trasporto e correzione tramite STMS delle transazioni SAP.
Eseguire backup del database dopo il rilascio del sistema per l'ambiente di produzione.
Eseguire i backup delle macchine virtuali per le macchine virtuali del livello applicazione SAP dopo il rilascio del sistema per la produzione.
Per i sistemi SAP che non fanno parte della fase go-live corrente, ma che comunicano con i sistemi SAP spostati in Azure durante questa fase go-live, è necessario reimpostare il buffer dei nomi host in SM51. In questo modo verranno rimossi gli indirizzi IP memorizzati nella cache precedenti associati ai nomi delle istanze dell'applicazione spostate in Azure.
Post-produzione
Questa fase riguarda il monitoraggio, il funzionamento e l'amministrazione del sistema. Da un punto di vista SAP, si applicano le normali attività da completare nella posizione di hosting precedente. Completare anche queste attività specifiche di Azure:
Esaminare le fatture di Azure per i sistemi ad alta ricarica. Installare le impostazioni cultura di finOps e creare una funzionalità di ottimizzazione dei costi di Azure nell'organizzazione.
Ottimizzare l'efficienza dei prezzi/prestazioni sul lato macchina virtuale e sul lato di archiviazione.
Una volta stabilizzato SAP in Azure, l'attenzione deve passare 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 aggiornato, dbMS e versione kernel SAP e patch e il sistema operativo, il database e l'uniform kernel SAP 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 sono state distribuite in un set di scalabilità flessibile con FD=1 tra zone di disponibilità o in un set di disponibilità.
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
I dischi gestiti di Azure o i volumi NFS di Azure NetApp Files vengono usati esclusivamente per le macchine virtuali DBMS.
Per Azure NetApp Files, vengono usate le opzioni di montaggio corrette e i volumi vengono ridimensionati in modo appropriato nel livello di archiviazione corretto.
Uso di servizi di Azure, 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 nell'intervallo moderato o valido.
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 altre applicazioni possono connettersi all'infrastruttura appena distribuita.
Controlli e informazioni dettagliate automatizzati nel panorama applicativo SAP
Diversi controlli precedenti vengono controllati in modo automatico con SAP in Azure Quality Check Tool. 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:
Azure Well-Architected Framework esaminare 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à.