Uso del riavvio delle macchine virtuali dell'infrastruttura di Azure per ottenere una "maggiore disponibilità" di un sistema SAP
Questa sezione si applica a:
Windows e
Linux
Se si decide di non usare funzionalità come Windows Server Failover Clustering (WSFC) o Pacemaker in Linux (attualmente supportato solo per SUSE Linux Enterprise Server [SLES] 12 e versioni successive), viene usato il riavvio delle macchine virtuali di Azure. Questa funzionalità protegge i sistemi SAP da tempi di inattività pianificati e non pianificati dell'infrastruttura di server fisici di Azure e della piattaforma Azure sottostante nel suo complesso.
Nota
Il riavvio delle VM di Azure protegge principalmente le VM e non le applicazioni. Anche se il riavvio delle macchine virtuali non offre una disponibilità elevata per le applicazioni SAP, offre un certo livello di disponibilità dell'infrastruttura e offre indirettamente una "disponibilità più elevata" dei sistemi SAP. Inoltre, non è disponibile alcun contratto di servizio relativo al tempo che sarà necessario per il riavvio di una VM dopo un'interruzione dell'host pianificata o non pianificata quindi questo metodo di disponibilità elevata non è adatto per i componenti critici di un sistema SAP. Un esempio potrebbe essere un'istanza di ASCS/SCS o un sistema di gestione di database (DBMS).
Un altro elemento importante dell'infrastruttura per la disponibilità elevata è l'archiviazione. Ad esempio, il contratto di servizio di archiviazione di Azure prevede una disponibilità del 99,9%. Se si effettua la distribuzione di tutte le VM con i relativi dischi in un singolo account di archiviazione di Azure, la potenziale indisponibilità di Archiviazione di Azure causerà l'indisponibilità di tutte le VM presenti in tale account di archiviazione e anche di tutti i componenti SAP in esecuzione all'interno delle VM.
Anziché inserire tutte le VM virtuali in un singolo account di archiviazione di Azure, è possibile anche usare account di archiviazione dedicati per ogni VM. Usando più account di archiviazione di Azure indipendenti, è possibile aumentare la disponibilità complessiva delle VM e delle applicazioni SAP.
I dischi gestiti di Azure sono collocati automaticamente nel dominio di errore della macchina virtuale alla quale sono collegati. Se si collocano due macchine virtuali in un set di disponibilità e si utilizzano i dischi gestiti, la piattaforma si occupa anche della distribuzione dei dischi gestiti in diversi domini di errore. Per utilizzare l'account di archiviazione Premium, è consigliabile utilizzare i dischi gestiti.
Un'architettura di esempio di un sistema SAP NetWeaver che usa la disponibilità elevata dell'infrastruttura di Azure e gli account di archiviazione potrebbe avere un aspetto simile al seguente:
Un'architettura di esempio di un sistema SAP NetWeaver che usa la disponibilità elevata dell'infrastruttura di Azure e i dischi gestiti potrebbe avere un aspetto simile al seguente:
Per i componenti SAP critici sono stati ottenuti fino a questo momento i risultati seguenti:
Disponibilità elevata di server applicazioni SAP
Le istanze dei server applicazioni SAP sono componenti ridondanti. Ogni istanza dei server applicazioni SAP viene distribuita nella relativa macchina virtuale, che è in esecuzione in un dominio di errore e di aggiornamento di Azure diverso. Per altre informazioni, vedere le sezioni Domini di errore e Domini di aggiornamento .
È possibile verificare questa configurazione usando i set di disponibilità di Azure. Per altre informazioni, vedere la sezione Set di disponibilità di Azure.
La potenziale indisponibilità pianificata o non pianificata di un dominio di errore o di aggiornamento di Azure causerà l'indisponibilità di un numero limitato di VM con le relative istanze dei server applicazioni SAP.
Ogni istanza dei server applicazioni SAP è posizionata nel relativo account di archiviazione di Azure. La potenziale indisponibilità di un account di archiviazione di Azure causa l'indisponibilità di una sola macchina virtuale con la relativa istanza dei server applicazioni SAP. Tenere presente, tuttavia, che esiste un limite al numero di account di archiviazione di Azure che è possibile avere all'interno di una sottoscrizione di Azure. Per garantire l'avvio automatico di un'istanza di ASCS/SCS dopo il riavvio della macchina virtuale, impostare il parametro di avvio automatico nel profilo di avvio dell'istanza di ASCS/SCS.
Per altre informazioni, vedere Disponibilità elevata per i server applicazioni SAP.
Anche se si utilizzano i dischi gestiti, i dischi vengono archiviati anche sull’account di archiviazione di Azure e possono essere non disponibili in caso di disservizio della risorsa di archiviazione.
Disponibilità più elevata delle istanze di SAP ASCS/SCS
In questo scenario il riavvio delle VM di Azure viene usato per proteggere la VM con l'istanza di SAP ASCS/SCS installata. Nel caso di inattività pianificata o non pianificata dei server di Azure, le VM vengono riavviate in un altro server disponibile. Come accennato in precedenza, il riavvio delle VM di Azure protegge principalmente le VM e non le applicazioni, in questo casto l'istanza di ASCS/SCS. Con il riavvio delle macchine virtuali si otterrà indirettamente una disponibilità più elevata dell'istanza di SAP ASCS/SCS.
Per garantire l'avvio automatico dell'istanza di ASCS/SCS dopo il riavvio della macchina virtuale, impostare il parametro di avvio automatico nel profilo di avvio dell'istanza di ASCS/SCS. Questa impostazione significa che l'istanza di ASCS/SCS come singolo punto di errore (SPOF) in esecuzione in una singola VM determinerà la disponibilità dell'intero panorama applicativo SAP.
Disponibilità più elevata del server DBMS
Analogamente al caso d'uso dell'istanza di SAP ASCS/SCS, il riavvio delle macchine virtuali di Azure viene usato per proteggere la macchina virtuale con il software DBMS installato e si ottiene una disponibilità più elevata del software DBMS.
Un DBMS in esecuzione in una singola VM è anche uno SPOF ed è il fattore determinante per la disponibilità dell'intero panorama applicativo SAP.
Uso dell'avvio automatico per le istanze di SAP
SAP offre un'impostazione che consente di avviare le istanze di SAP immediatamente dopo l'avvio del sistema operativo nella VM. Le istruzioni sono documentate nell'articolo della Knowledge Base SAP 1909114. Tuttavia, SAP sconsiglia di continuare a usare questa impostazione perché non offre alcun controllo sull'ordine dei riavvii delle istanze, supponendo che siano interessate più di una VM o vengano eseguite più istanze per ogni VM.
Presupponendo uno scenario tipico di Azure di un'istanza del server applicazioni SAP in una VM e di una singola VM che viene alla fine riavviata, l'avvio automatico non è critico, ma è possibile abilitarlo aggiungendo il parametro seguente nel profilo di avvio dell'istanza Advanced Business Application Programming (ASCS) di SAP o Java:
Autostart = 1
Nota
Il parametro di avvio automatico può presentare anche alcuni inconvenienti. Nello specifico, il parametro attiva l'avvio di un'istanza di SAP ABAP o di Java quando viene avviato il servizio di dell'istanza Windows o Linux correlato. Questa sequenza si verifica sicuramente all'avvio dei sistemi operativi. Tuttavia, i riavvii dei servizi SAP sono errori comuni anche per la funzionalità di gestione del ciclo di vita di SAP come Software Update Manager (SUM) o altri aggiornamenti. Queste funzionalità non prevedono il riavvio automatico di un'istanza. Quindi, il parametro di avvio automatico deve essere disabilitato prima di eseguire tali attività. Inoltre, il parametro di avvio automatico non deve essere usato per le istanze di SAP in cluster, ad esempio ASCS/SCS/CI.
Per altre informazioni sull'avvio automatico per le istanze di SAP, vedere gli articoli seguenti:
- Avviare o arrestare SAP con l'avvio/l'arresto del server Unix
- Avviare e arrestare gli agenti di gestione di SAP NetWeaver
Passaggi successivi
Per informazioni sulla disponibilità elevata completa con riconoscimento dell'applicazione SAP NetWeaver, vedere Disponibilità elevata delle applicazioni SAP su IaaS di Azure.