Esplorare la fase pilota

  • 20 minuti

La fase pilota può essere eseguita in parallelo alla pianificazione e alla preparazione del progetto. Questa fase può essere usata anche per testare le opzioni identificate nella fase di pianificazione e preparazione. Come parte della fase pilota, è consigliabile configurare e convalidare una soluzione di disponibilità elevata/ripristino di emergenza completa, nonché la progettazione della sicurezza. In alcuni casi, è possibile usare questa fase anche per eseguire test di scalabilità o distribuire sistemi sandbox SAP. Per eseguire una fase pilota, i clienti devono iniziare identificando un sistema non critico di cui vogliono eseguire la migrazione in Azure e continuare eseguendo queste attività:

1. Ottimizzare il trasferimento dati in Azure

L'approccio e il risultato sono altamente dipendenti dalla connettività del cliente ad Azure. A seconda della quantità di dati, può essere possibile usare a questo scopo ExpressRoute, una VPN da sito a sito o servizi di trasferimento dei dati offline, ad esempio Azure Data Box o Importazione/Esportazione di Azure.

2. Migrazione della piattaforma eterogenea SAP

In caso di migrazione di piattaforme SAP eterogenee, che implica un'esportazione e un'importazione dei dati del database, testare e ottimizzare le fasi di esportazione e importazione. Per migrazioni eterogenee di grandi dimensioni destinate a SQL Server, vedere Migrazione del sistema operativo/database SAP a SQL Server - Domande frequenti. È possibile usare Migration Monitor/SWPM se non è necessario combinare la migrazione con un aggiornamento della versione o con l'opzione SAP DMO (Database Migration Option). Per informazioni dettagliate, vedere Opzione di migrazione del database (DMO) di SUM - Introduzione. In entrambi i casi, completare questi passaggi:

  • Misurare il tempo necessario per esportare il contenuto dall'origine, caricare il contenuto esportato in Azure ed eseguire l'importazione. Ottimizzare la sovrapposizione tra esportazione e importazione.
  • Usare il confronto tra i database di origine e di destinazione per dimensionare correttamente l'infrastruttura di destinazione.
  • Convalidare e ottimizzare le tempistiche.

3. Eseguire la convalida tecnica

Tipi di macchine virtuali

  • Fare riferimento alle note di supporto SAP, alla directory hardware SAP HANA e alla matrice di disponibilità dei prodotti SAP per verificare l'accuratezza delle informazioni relative agli SKU di macchine virtuali di Azure supportati, alle versioni del sistema operativo supportate per questi SKU e alle versioni di SAP e DBMS supportate.
  • Convalidare le dimensioni dei componenti dell'infrastruttura e delle applicazioni distribuiti in Azure. Quando si esegue la migrazione di applicazioni esistenti, si dovrebbe essere in grado di ottenere gli standard SAP necessari in base ai dati di telemetria esistenti. Recuperare il benchmark SAP e confrontarlo con i valori degli standard SAP elencati nella nota SAP n. 1928533. Inoltre, fare riferimento alle informazioni in Classificazioni SAPS in Macchine virtuali di Azure: dove cercare e potenziali fonti di confusione.
  • Valutare e testare il dimensionamento di Macchine virtuali di Azure per quanto riguarda la velocità effettiva di archiviazione massima e la velocità effettiva di rete dei diversi tipi di macchine virtuali scelti nella fase di pianificazione. Questi dati sono disponibili in Dimensioni delle macchine virtuali in Azure. Quando il sistema operativo guest di Macchina virtuale di Azure è Windows, è importante considerare la velocità effettiva massima del disco non memorizzato nella cache per il dimensionamento. Anche nel caso di Linux è importante considerare la velocità effettiva massima del disco non nella cache per il dimensionamento.

Storage

  • Usare l'archiviazione su unità SSD Standard di Azure come requisito minimo per le macchine virtuali che rappresentano i livelli di applicazione SAP e per la distribuzione di sistemi DBMS non sensibili alle prestazioni e usare Archiviazione Premium di Azure per le macchine virtuali DBMS sensibili alle prestazioni.
  • Evitare l'uso di dischi HDD Standard di Azure.
  • Usare i dischi gestiti di Azure.
  • Abilitare l'acceleratore di scrittura di Azure per le unità di log DBMS con Macchine virtuali di Azure serie M. Tenere presenti i limiti e le restrizioni di utilizzo documentati per l'acceleratore di scrittura.
  • Per informazioni sull'archiviazione relative a DBMS, vedere Considerazioni sulla distribuzione DBMS di macchine virtuali di Azure per un carico di lavoro SAP e la documentazione specifica per DBMS citata in tale documento.
  • Per le distribuzioni SAP HANA, vedere Configurazioni e operazioni dell'infrastruttura SAP HANA in Azure.
  • Non montare mai dischi dati di Azure in una macchina virtuale Linux di Azure usando l'ID dispositivo. Usare invece l'identificatore univoco universale (UUID). Prestare attenzione quando si usano strumenti grafici per montare un disco dati di Azure. Controllare attentamente le voci in /etc/fstab per verificare che i dischi siano stati montati usando l'UUID. Per altre informazioni, vedere Connettersi alla macchina virtuale Linux per montare il nuovo disco.

Rete

Testare e valutare l'infrastruttura di rete virtuale e la distribuzione delle applicazioni SAP tra reti virtuali di Azure o al loro interno.

  1. Valutare l'approccio dell'architettura di rete virtuale hub-spoke o la microsegmentazione all'interno di una singola rete virtuale di Azure in base ai criteri seguenti:

    • Costi riferiti allo scambio di dati tra reti virtuali di Azure sottoposte a peering (per informazioni dettagliate, vedere Prezzi di Rete virtuale di Azure.
    • Confronto tra la possibilità di terminare il peering tra reti virtuali di Azure e l'uso di NSG per isolare le subnet all'interno di una rete virtuale nei casi in cui le applicazioni o le macchine virtuali ospitate in una subnet della rete virtuale rappresentano un rischio per la sicurezza.
    • Registrazione e controllo centrali del traffico di rete tra l'ambiente locale, Internet e il data center virtuale di Azure.

  2. Valutare e testare il percorso dei dati tra il livello applicazione SAP e il livello DBMS SAP. Nell'ambito della valutazione, tenere presente quanto segue:

    • L'inserimento di appliance virtuali di rete nel percorso di comunicazione tra l'applicazione SAP e il livello DBMS di un sistema SAP basato su SAP NetWeaver, Hybris o S/4HANA non è supportato.
    • L’inserimento del livello dell’applicazione SAP e del sistema SAP DBMS in reti virtuali di Azure diverse non sottoposte a peering non è supportata.
    • È possibile usare gruppi di sicurezza delle applicazioni e gruppi di sicurezza di rete di Azure per controllare il flusso del traffico tra il livello applicazione SAP e il livello DBMS SAP.

  3. Assicurarsi che la funzionalità Rete accelerata di Azure sia abilitata nelle macchine virtuali usate nel livello dell’applicazione SAP e nel livello del sistema SAP DBMS. Tenere presenti i requisiti del sistema operativo per il supporto di Rete accelerata in Azure:

    • Windows Server 2012 R2 o versioni successive
    • SUSE Linux 12 SP3 o versioni successive
    • RHEL 7.4 o versioni successive
    • Oracle Linux 7.5. Il kernel RHCKL richiede la versione 3.10.0-862.13.1.el7. Il kernel Oracle UEK richiede la versione 5.

  4. Testare e valutare la latenza di rete tra la macchina virtuale del livello dell’applicazione SAP e la macchina virtuale DBMS in base alla nota SAP #500235 e alla nota SAP #1100926. Valutare i risultati rispetto alle indicazioni sulla latenza di rete della nota SAP 1100926. La latenza di rete deve essere da moderata a buona.

  5. Verificare che le distribuzioni del servizio di bilanciamento del carico interno di Azure siano configurate per l'uso di Direct Server Return. Questa impostazione riduce la latenza nei casi in cui vengono usati servizi di bilanciamento del carico interno per configurazioni a disponibilità elevata nel livello DBMS.

  6. Se si usa Azure Load Balancer insieme a sistemi operativi guest Linux, verificare che il parametro di rete Linux net.ipv4.tcp_timestamps sia impostato su 0. Si noti che ciò contraddice le raccomandazioni generali della nota SAP n. 2382421. La nota SAP è stata aggiornata in modo da riflettere il fatto che il parametro deve essere impostato su 0 per funzionare in combinazione con i servizi di bilanciamento del carico di Azure.

Distribuzioni per disponibilità elevata e ripristino di emergenza

  • Se si distribuisce il livello dell’applicazione SAP senza scegliere come destinazione zone di disponibilità di Azure specifiche, assicurarsi che tutte le macchine virtuali che eseguono l'istanza di dialogo SAP o istanze middleware dello stesso sistema SAP vengano distribuite nello stesso set di disponibilità.

    • Nel caso in cui non sia necessaria la disponibilità elevata per SAP Central Services e DBMS, queste macchine virtuali possono essere distribuite nello stesso set di disponibilità del livello dell'applicazione SAP.

  • Se è necessario proteggere SAP Central Services e il livello DBMS per la disponibilità elevata con repliche passive, distribuire i due nodi per SAP Central Services in un set di disponibilità e i due nodi DBMS in un altro set di disponibilità.

  • Se si esegue la distribuzione in zone di disponibilità di Azure, non è possibile usare i set di disponibilità. È invece necessario assicurarsi di distribuire i nodi Central Services attivi e passivi in due zone di disponibilità diverse, per ottenere la latenza più bassa tra zone.

  • Tenere presente che è necessario usare Azure Load Balancer Standard nel caso in cui si creino cluster di failover basati su Windows Server o Pacemaker per i livelli DBMS e SAP Central Services tra zone di disponibilità. Il servizio di bilanciamento del carico Basic non supporta distribuzioni di zona.

Impostazioni di timeout

  • Controllare le tracce di sviluppo SAP NetWeaver per le istanze SAP e assicurarsi che non vi siano interruzioni di connessione tra il server di accodamento e i processi di lavoro SAP. Le interruzioni di connessione possono essere evitate impostando questi due parametri del Registro di sistema.

    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Per informazioni dettagliate, vedere KeepAliveTime.
    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Per informazioni dettagliate, vedere KeepAliveInterval.

  • Per evitare timeout tra le interfacce utente grafiche di SAP in locale e dei livelli applicazione SAP distribuiti in Azure, impostare i parametri seguenti nel file default.pfl o nel profilo dell'istanza:

    • rdisp/keepalive_timeout = 3600
    • rdisp/keepalive = 20

  • Se si usa la funzionalità Clustering di failover di Windows, assicurarsi che i parametri che determinano il failover attivato da nodi che non rispondono siano impostati correttamente. L'articolo della Microsoft Tech Community Ottimizzazione delle soglie di rete dei cluster di failover elenca i parametri e descrive il loro impatto sul comportamento di failover. Ad esempio, supponendo che i nodi del cluster si trovino nella stessa subnet, assicurarsi di configurare i parametri di failover nel modo seguente:

    • SameSubNetDelay = 2000

    • SameSubNetThreshold = 15

    • RoutingHistorylength = 30

    • Testare le procedure per la disponibilità elevata e il ripristino di emergenza:

      • Simulare il failover arrestando le macchine virtuali di Azure (sistema operativo guest Windows) o attivando la modalità di errore grave nei sistemi operativi (sistema operativo guest Linux).

      • Misurare il tempo necessario per completare i 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, provare a migliorare le prestazioni di archiviazione.

      • Testare la sequenza di backup/ripristino e ottimizzarla, se necessario. Assicurarsi che non solo i tempi di backup siano sufficienti. Testare anche la procedura di ripristino per verificare che i tempi Assicurarsi che i tempi di ripristino siano in linea con il valore RTO previsto dai contratti di servizio, calcolato in base a un processo di ripristino di un database o di una macchina virtuale.

      • Testare l'architettura e la funzionalità per il ripristino di emergenza.

4. Eseguire controlli di sicurezza

  • Testare la validità dell'approccio al controllo degli accessi in base al ruolo implementato. L'obiettivo è separare e limitare l'accesso e le autorizzazioni delegati a team diversi. Ad esempio, i membri del team di SAP Basis devono essere in grado di distribuire macchine virtuali di Azure in una rete virtuale di Azure e assegnare dischi a queste macchine virtuali. Tuttavia, il team di SAP Basis non deve poter creare nuove reti virtuali o modificare le impostazioni delle reti virtuali esistenti. D'altro canto, i membri del team di rete non devono essere in grado di distribuire macchine virtuali di Azure in reti virtuali in cui sono in esecuzione macchine virtuali delle applicazioni SAP e DBMS. Allo stesso modo, i membri del team di rete non devono poter modificare gli attributi delle macchine virtuali né eliminare le macchine virtuali e i rispettivi dischi.
  • Verificare che le regole NSG funzionino come previsto e proteggano le risorse.
  • Verificare la crittografia dei dati inattivi e in transito. Definire e implementare processi per il backup, l'archiviazione e l'accesso ai certificati, nonché per convalidare il processo di ripristino delle entità crittografate.
  • Usare Crittografia dischi di Azure per i dischi del sistema operativo.
  • Prendere in considerazione un approccio pragmatico nel decidere se implementare un meccanismo di crittografia. Valutare, ad esempio, se sia necessario applicare Crittografia dischi di Azure e Transparent Database Encryption per DBMS.

5. Testare le prestazioni

Negli scenari di migrazione sfruttare l'analisi e le misurazioni di SAP per confrontare la fase pilota con l'implementazione corrente in base agli elementi seguenti:

  • Primi 10 report online
  • Primi 10 processi batch
  • Trasferimenti dei dati tramite le interfacce nel sistema SAP, con particolare attenzione al traffico tra ambienti locali