Condividi tramite

Considerazioni sulla distribuzione DBMS di macchine virtuali di Azure per un carico di lavoro SAP

  • Articolo

Questa guida fa parte della documentazione su come implementare e distribuire software SAP in Microsoft Azure. Prima di leggere questa guida, leggere la guida alla pianificazione e all'implementazione e gli articoli della guida alla pianificazione puntano all'utente. Questo documento illustra gli aspetti generici della distribuzione di sistemi DBMS correlati a SAP in macchine virtuali (VM) di Microsoft Azure tramite le funzionalità dell'infrastruttura distribuita come servizio (IaaS) di Azure.

Questo documento è complementare alla documentazione relativa all'installazione di SAP e alle note SAP, che rappresentano le risorse principali per le installazioni e le distribuzioni del software SAP su piattaforme specifiche.

Questo documento introduce considerazioni sull'esecuzione di sistemi DBMS correlati a SAP in macchine virtuali di Azure. In questo documento sono disponibili alcuni riferimenti a sistemi DBMS specifici. I sistemi DBMS specifici vengono invece gestiti in altri documenti specifici del sistema di database.

Risorse

Sono disponibili altri articoli sul carico di lavoro SAP in Azure. Iniziare con Carico di lavoro SAP in Azure: attività iniziali e quindi scegliere l'area di interesse.

Le note SAP seguenti sono correlate a SAP in Azure riguardo all'area coperta in questo documento.

Numero della nota Title
1928533 Applicazioni SAP in Azure: prodotti supportati e tipi di macchine virtuali di Azure
2015553 SAP in Microsoft Azure: Prerequisiti di supporto
1999351 Risoluzione dei problemi del monitoraggio avanzato di Azure per SAP
2178632 Metriche chiave del monitoraggio per SAP in Microsoft Azure
1409604 Virtualizzazione in Windows: monitoraggio avanzato
2191498 SAP in Linux con Azure: monitoraggio avanzato
2039619 Applicazioni SAP in Microsoft Azure che usano il database Oracle: prodotti supportati e relative versioni
2233094 DB6: Informazioni aggiuntive sulle applicazioni SAP in Azure che usano IBM DB2 per Linux, UNIX e Windows
2243692 Linux in una macchina virtuale di Microsoft Azure (IaaS): problemi delle licenze SAP
2578899 SUSE Linux Enterprise Server 15: note di installazione
1984787 SUSE LINUX Enterprise Server 12: note di installazione
2772999 Red Hat Enterprise Linux 8.x: Installazione e configurazione
2002167 Red Hat Enterprise Linux 7. x: installazione e aggiornamento
2069760 Installazione e aggiornamento di Oracle Linux 7.x SAP
1597355 Raccomandazione sullo spazio di scambio per Linux
2799900 Nota tecnica centrale per Oracle Database 19c
2171857 Oracle Database 12c: supporto per file system in Linux
1114181 Oracle Database 11g: supporto per file system in Linux
2969063 Convalida del microcodice non riuscita in HCMT in Azure
3246210 Azure - HCMT ha esito negativo durante alcuni test delle prestazioni del disco

Per informazioni su tutte le note SAP per Linux, vedere la Community WIKI SAP.

È necessaria una conoscenza pratica dell'architettura Microsoft Azure e di come le macchine virtuali di Microsoft Azure siano state distribuite e gestite. Per altre informazioni, vedere la documentazione di Azure.

In generale, l'installazione e la configurazione di Windows, Linux e DBMS sono sostanzialmente uguali a quanto avviene in qualsiasi macchina virtuale o computer bare metal installato in locale. Alcune decisioni relative all'architettura e all'implementazione della gestione del sistema presentano differenze in caso di tecnologia IaaS di Azure. Questo documento illustra le differenze specifiche relative all'architettura e alla gestione del sistema che è necessario conoscere quando si usa la tecnologia IaaS di Azure.

Struttura delle risorse di archiviazione di una VM per le distribuzioni RDBMS

Per seguire questo capitolo, leggere e comprendere le informazioni presentate in:

Per l'archiviazione a blocchi di Azure, l'uso dei dischi gestiti di Azure è obbligatorio. Per informazioni dettagliate sui dischi gestiti di Azure, vedere l'articolo Introduzione ai dischi gestiti per le macchine virtuali di Azure.

In una configurazione di base, è consigliabile di solito usare una struttura di distribuzione in cui il sistema operativo, il sistema DBMS ed eventuali file binari SAP siano separati dai file di database. È consigliabile avere dischi di Azure separati per:

  • Sistema operativo (disco rigido virtuale di base o disco rigido virtuale del sistema operativo)
  • Sistema di gestione di database
  • Eseguibili SAP come /usr/sap
  • File di dati DBMS
  • File di log di rollforward dbMS

Una configurazione che separa questi componenti in cinque volumi diversi può comportare una maggiore resilienza perché l'utilizzo eccessivo in un volume non interferisce necessariamente con l'utilizzo di altri volumi purché non vengano superati i limiti e la quota di archiviazione delle macchine virtuali.

I dati DBMS e i file di log di transazione/rollforward vengono archiviati nell'archiviazione a blocchi supportata di Azure o in Azure NetApp Files. File di Azure o File Premium di Azure non è supportato come risorsa di archiviazione per i dati DBSM e/o i file di log di rollforward con carico di lavoro SAP. Vengono archiviati in dischi separati e collegati come dischi logici all'immagine della macchina virtuale del sistema operativo Azure originale. Per le distribuzioni linux, sono documentate raccomandazioni diverse. Leggere l'articolo Tipi di archiviazione di Azure per i carichi di lavoro SAP per le funzionalità e il supporto dei diversi tipi di archiviazione per lo scenario in uso. In particolare per SAP HANA iniziare con l'articolo Configurazioni di archiviazione delle macchine virtuali di Azure SAP HANA.

Quando si pianifica il layout del disco, è necessario trovare il migliore equilibrio tra gli elementi seguenti:

  • Numero di file di dati.
  • Numero di dischi contenenti i file.
  • Quote di operazioni di I/O al secondo di un singolo disco o condivisione NFS.
  • Velocità effettiva dei dati per disco o condivisione NFS.
  • Numero di dischi dati aggiuntivi possibili per dimensioni di VM.
  • La velocità effettiva complessiva di archiviazione o di rete che una macchina virtuale può fornire.
  • La latenza che i diversi tipi di Archiviazione di Azure possono offrire.
  • Quota di operazioni di I/O al secondo e velocità effettiva di archiviazione delle macchine virtuali.
  • Quota di rete della macchina virtuale nel caso in cui si usi NFS: il traffico verso le condivisioni NFS viene conteggiato rispetto alla quota di rete della macchina virtuale e NON la quota di archiviazione.
  • Contratti di servizio per macchine virtuali.

Azure applica una quota di operazioni di I/O al secondo per ogni disco dati o condivisione NFS. Queste quote sono diverse per i dischi ospitati nelle diverse soluzioni o condivisioni di archiviazione a blocchi di Azure. Anche la latenza di I/O è diversa tra questi diversi tipi di archiviazione.

A ognuno dei diversi tipi di macchine virtuali è possibile collegare un numero limitato di dischi dati. Un'altra restrizione consiste nel fatto che solo determinati tipi di macchine virtuali possono usare, ad esempio, l'archiviazione Premium. In genere, si decide di usare un determinato tipo di macchina virtuale in base ai requisiti di CPU e memoria. È anche necessario considerare i requisiti di IOPS, latenza e velocità effettiva del disco che in genere vengono dimensionati con il numero di dischi o il tipo di dischi di archiviazione Premium v1. Il numero di operazioni di I/O al secondo e la velocità effettiva che deve essere raggiunta da ogni disco possono determinare le dimensioni del disco, soprattutto con Archiviazione Premium. Con l'archiviazione Premium v2 o il disco Ultra, è possibile selezionare operazioni di I/O al secondo di cui è stato effettuato il provisioning e la velocità effettiva indipendentemente dalla capacità del disco.

Nota

Per le distribuzioni DBMS, è consigliabile usare Archiviazione Premium di Azure (v1 e v2), dischi Ultra o condivisioni NFS basate su Azure NetApp Files per qualsiasi file di dati, log delle transazioni o rollforward. Non è importante se si vuole distribuire sistemi di produzione o di non produzione. La latenza di UNITÀ SSD o HDD standard di Azure non è accettabile per qualsiasi tipo di sistema di produzione.

Nota

Per ottimizzare il contratto di servizio per macchine virtuali singole di Azure, tutti i dischi collegati devono essere Archiviazione Premium di Azure (v1 o v2) o tipo di disco Ultra di Azure, che include il disco rigido virtuale di base (Archiviazione Premium di Azure).

Nota

Non è possibile ospitare i file principali di database, ad esempio file di log e dati, dei database SAP su hardware di archiviazione situati in data center di terze parti con risorse condivise adiacenti ai data center di Azure. L'archiviazione fornita tramite appliance software ospitate nelle macchine virtuali di Azure non è supportata anche per questo caso d'uso. Per i carichi di lavoro DBMS SAP, solo l'archiviazione rappresentata come servizio nativo di Azure è supportata per i file di dati e di log delle transazioni dei database SAP in generale. DBMS diversi potrebbero supportare diversi tipi di archiviazione di Azure. Per altri dettagli, vedere l'articolo Tipi di archiviazione di Azure per i carichi di lavoro SAP

La posizione dei file di database, dei file di log e di rollforward e il tipo di archiviazione di Azure usati sono definiti in base ai requisiti di operazioni di I/O al secondo, latenza e velocità effettiva. In particolare per Archiviazione Premium di Azure v1, per ottenere un numero sufficiente di operazioni di I/O al secondo, potrebbe essere necessario usare più dischi o usare un disco di archiviazione Premium più grande. Se si usano più dischi, si creerebbe una striscia software tra i dischi che contengono i file di dati o i file registro e di rollforward. In questi casi, i contratti di servizio per le operazioni di I/O al secondo e la velocità effettiva dei dischi di archiviazione Premium sottostanti o il numero massimo raggiungibile di operazioni di I/O al secondo dei dischi di archiviazione Standard sono cumulativi per il set di striping risultante.

Se il requisito di operazioni di I/O al secondo supera quello che può fornire un singolo disco rigido virtuale, bilanciare le operazioni di I/O al secondo necessarie per i file di database in diversi dischi rigidi virtuali. Il modo più semplice per distribuire il carico delle operazioni di I/O al secondo tra più dischi consiste nel creare una striscia software su dischi diversi. Memorizzare quindi una serie di file di dati del sistema DBMS SAP nei LUN ricavati dalla striscia software. Il numero di dischi nella striscia si basa sulle richieste di operazioni di I/O al secondo, sulle richieste di velocità effettiva dei dischi e sulle richieste di volume.

Striping dell'archiviazione di Windows Windows

È consigliabile usare spazi di archiviazione di Windows per creare set di striping tra più dischi rigidi virtuali di Azure. Usare almeno Windows Server 2012 R2 o Windows Server 2016.

Striping dell'archiviazione Linux Linux

Per compilare un RAID software in Linux sono supportati solo MDADM e Logical Volume Manager (LVM). Per altre informazioni, vedi:

Per l'archiviazione Premium di Azure v2 e il disco Ultra, lo striping potrebbe non essere necessario perché è possibile definire operazioni di I/O al secondo e velocità effettiva del disco indipendentemente dalle dimensioni del disco.

Nota

Poiché Archiviazione di Azure conserva tre immagini dei dischi rigidi virtuali, non è utile configurare una ridondanza durante lo striping. È sufficiente configurare lo striping in modo che le operazioni di I/O vengano distribuite su dischi rigidi virtuali diversi.

Dischi gestiti o non gestiti

Un account di archiviazione di Azure è un costrutto amministrativo ed è anche soggetto a limitazioni. Per altre informazioni su funzionalità e limitazioni, vedere Obiettivi di scalabilità e prestazioni per Archiviazione di Azure. Per l'archiviazione Standard, tenere presente che è previsto un limite per il numero di operazioni di I/O al secondo per ogni account di archiviazione. Vedere la riga che contiene Total Request Rate (Frequenza di richiesta totale) nell'articolo Obiettivi di scalabilità e prestazioni per Archiviazione di Azure. Esiste inoltre un limite iniziale per il numero di account di archiviazione per ogni sottoscrizione di Azure. A partire dal 2017, Azure ha introdotto i concetti di Azure Managed Disks che consentono di occuparsi di qualsiasi amministrazione dell'account di archiviazione. L'uso di Azure Managed Disks è l'impostazione predefinita da distribuire per il carico di lavoro SAP in Azure.

Importante

Dati i vantaggi di Azure Managed Disks, è obbligatorio usare Azure Managed Disks per le distribuzioni DBMS e le distribuzioni SAP in generale.

Se si ha un carico di lavoro SAP che non usa ancora dischi gestiti, per eseguire la conversione da dischi non gestiti a dischi gestiti, vedere:

Caching per VM e dischi dati

Quando si montano dischi su macchina virtuale, è possibile scegliere se memorizzare nella cache il traffico di I/O tra la macchina virtuale e i dischi posizionati nella risorsa di archiviazione di Azure.

Le raccomandazioni seguenti presuppongono queste caratteristiche di I/O per il sistema DBMS standard:

  • Si tratta principalmente di un carico di lavoro di lettura su file di dati di un database. Queste operazioni di lettura sono cruciali per le prestazioni per il sistema DBMS.
  • La scrittura sui file di dati si verifica in burst in base ai checkpoint o a un flusso costante. In media in un giorno, si verificano meno operazioni di scrittura rispetto alle operazioni di lettura. Al contrario delle operazioni di lettura da file di dati, queste operazioni di scrittura sono asincrone e non contengono transazioni utente.
  • Esistono pochissime operazioni di lettura dal file registro transazioni e dal file di rollforward. Fanno eccezione le operazioni di I/O di grandi dimensioni quando si eseguono i backup del log delle transazioni.
  • Il carico principale nei file registro transazioni e di rollforward è costituito da operazioni di scrittura. A seconda della natura del carico di lavoro, è possibile che le operazioni di I/O siano di piccole dimensioni, ad esempio 4 kB o, in altri casi, di almeno 1 MB.
  • Tutte le scritture devono essere salvate in modo permanente su un disco in modo affidabile.

Per Archiviazione Premium di Azure v1 sono disponibili le opzioni di memorizzazione nella cache seguenti:

  • None
  • Lettura
  • Lettura/scrittura
  • Nessuna + Acceleratore di scrittura, disponibile solo per macchine virtuali serie M di Azure
  • Lettura + Acceleratore di scrittura, disponibile solo per macchine virtuali serie M di Azure

Per l'archiviazione Premium v1, è consigliabile usare la Memorizzazione nella cache di lettura per i file di dati del database SAP e scegliere Nessuna memorizzazione nella cache per i dischi dei file di log.

Nota

Con alcuni dei nuovi tipi di VM M(b)v3, l'uso dell'archiviazione PREMIUM SSD v1 in lettura memorizzata nella cache potrebbe comportare una velocità di I/O al secondo di lettura e scrittura inferiore rispetto a quella che si otterrebbe se non si usa la cache di lettura.

Per le distribuzioni di serie M, è consigliabile usare l'acceleratore di scrittura di Azure solo per i dischi dei file di log. Per i dettagli, le limitazioni e la distribuzione dell'acceleratore di scrittura di Azure, vedere Abilitare l'acceleratore di scrittura.

Per l'archiviazione Premium v2, disco Ultra e Azure NetApp Files, non sono disponibili opzioni di memorizzazione nella cache.

Dischi non persistenti di Azure

Le macchine virtuali di Azure offrono dischi non persistenti dopo la distribuzione di una macchina virtuale. Se una macchina virtuale viene riavviata, è possibile cancellare tutto il contenuto in tali unità. È un dato di fatto che i file di dati, i file registro e di rollforward dei database non devono mai essere posizionati in tali unità non persistenti. Potrebbero esserci delle eccezioni per alcuni database, dove queste unità non persistenti potrebbero essere adatte per gli spazi di tabella di tempdb e temp.

Per altre informazioni, vedere Informazioni sull'unità temporanea per le macchine virtuali Windows in Azure.

Disco non persistente di Windows Windows

L'unità D in una macchina virtuale di Azure è un'unità non persistente supportata da alcuni dischi locali nel nodo di calcolo di Azure. Poiché non è persistente, tutte le modifiche apportate al contenuto nell'unità D andranno perse al riavvio della macchina virtuale. Le modifiche includono i file archiviati, le directory create e le applicazioni installate.

Disco linuxnonpersisted Linux

Nelle macchine virtuali Linux di Azure viene montata automaticamente in /mnt/resource un'unità non persistente supportata da dischi locali nel nodo di calcolo di Azure. Poiché non è persistente, tutte le modifiche apportate al contenuto in /mnt/resource andranno perse al riavvio della macchina virtuale. Le modifiche includono i file archiviati, le directory create e le applicazioni installate.

Resilienza di Archiviazione di Microsoft Azure

Archiviazione di Microsoft Azure archivia il disco rigido virtuale di base con il sistema operativo e i dischi collegati o i BLOB in almeno tre nodi di archiviazione separati. Questo tipo di archiviazione è denominato archiviazione con ridondanza locale (LRS). L'archiviazione con ridondanza locale è l'impostazione predefinita per tutti i tipi di archiviazione in Azure.

Sono disponibili altri metodi di ridondanza. Per altre informazioni, vedere Replica di Archiviazione di Azure.

Nota

Archiviazione Premium di Azure v1 e v2, disco Ultra e Azure NetApp Files sono il tipo di archiviazione consigliato per macchine virtuali e dischi DBMS che archiviano file di database e log e rollforward. Ad eccezione di Archiviazione Premium v1, l'unico metodo di ridondanza disponibile per questi tipi di archiviazione è LRS. Di conseguenza, è necessario configurare i metodi di database per abilitare la replica dei dati di database in un'altra area di Azure o in un'altra zona di disponibilità. I metodi di database includono SQL Server Always On, Oracle Data Guard e replica di sistema HANA.

Resilienza del nodo della VM

Azure offre molti contratti di servizio per macchine virtuali. Per altre informazioni, vedere la versione più recente del Contratto di Servizio per Macchine virtuali. Poiché il livello DBMS è fondamentale per la disponibilità in un sistema SAP, è necessario comprendere i diversi tipi di distribuzione ed eventi di manutenzione. Per altre informazioni su questi concetti, vedere Gestire la disponibilità delle macchine virtuali in Azure.

La raccomandazione di base per gli scenari DBMS di produzione con un carico di lavoro SAP è di:

  • Distribuire due macchine virtuali usando il tipo di distribuzione scelto nella stessa area di Azure.
  • Eseguire queste due macchine virtuali nella stessa rete virtuale di Azure e disporre di schede di interfaccia di rete collegate fuori dalle stesse subnet.
  • Usare i metodi di database per mantenere un hot standby con la seconda macchina virtuale. I metodi possono essere SQL Server Always On, Oracle Data Guard o replica di sistema HANA.

È anche possibile distribuire una terza macchina virtuale in un'altra area di Azure e usare gli stessi metodi di database per offrire una replica asincrona in un'altra area di Azure.

Considerazioni sulla rete di Azure

Nelle distribuzioni di SAP su larga scala, usare il progetto di data center virtuale di Azure. È possibile usarlo per la configurazione della rete virtuale e le autorizzazioni e le assegnazioni di ruolo a diverse parti della propria organizzazione.

Queste procedure consigliate sono il risultato di migliaia di distribuzioni dei clienti:

  • Le reti virtuali in cui viene distribuita l'applicazione SAP non hanno accesso a Internet.
  • Le macchine virtuali di database vengono eseguite nella stessa rete virtuale del livello applicazione, separate in una subnet diversa dal livello applicazione SAP.
  • Le macchine virtuali all'interno della rete virtuale hanno un'allocazione statica dell'indirizzo IP privato. Per altre informazioni, vedere Tipi di indirizzi IP e metodi di allocazione in Azure.
  • Le restrizioni di routing da e verso le macchine virtuali DBMS non sono impostate con i firewall installati nelle macchine virtuali DBMS locali. Il routing del traffico viene invece definito con i Gruppi di sicurezza di rete (NSG).
  • Per separare e isolare il traffico verso la macchina virtuale DBMS, assegnare schede di interfaccia di rete diverse alla macchina virtuale. Ogni scheda di interfaccia di rete riceve un indirizzo IP diverso e viene assegnata a una subnet rete virtuale diversa. Ogni subnet ha regole NSG diverse. L'isolamento o la separazione del traffico di rete è una misura per il routing. Non consente di impostare quote per la velocità effettiva della rete.

Nota

Assegnare indirizzi IP statici tramite Azure significa assegnarli alle singole schede di interfaccia di rete virtuali. Non assegnare indirizzi IP statici all'interno del sistema operativo guest a una scheda di interfaccia di rete virtuale. Alcuni servizi di Azure come Backup di Azure si basano sul fatto che almeno la scheda di interfaccia di rete virtuale primaria nel sistema operativo guest sia impostata su DHCP e non su indirizzi IP statici. Per altre informazioni, vedere Risolvere i problemi relativi al backup delle macchine virtuali di Azure. Per assegnare più indirizzi IP statici a una macchina virtuale, occorre assegnare più schede di interfaccia di rete virtuali a una macchina virtuale.

Avviso

La configurazione di appliance virtuali di rete di Azure nel percorso di comunicazione tra il livello applicazione SAP e il livello DBMS di un sistema SAP NetWeaver, Hybris o basato su S/4HANA non è supportata. Questa restrizione si applica per motivi di funzionalità e prestazioni. Il percorso di comunicazione tra il livello dell'applicazione SAP e il livello DBMS deve essere diretto. La restrizione non include le regole del gruppo di sicurezza delle applicazioni e NSG se queste regole consentono un percorso di comunicazione diretta. Ciò include anche il traffico verso condivisioni NFS che ospitano i file di log e i dati DBMS.

Altri scenari in cui le appliance virtuali di rete non sono supportate sono:

Le appliance virtuali di rete nei percorsi di comunicazione possono facilmente raddoppiare la latenza di rete tra due partner di comunicazione. Possono anche limitare la velocità effettiva nei percorsi critici tra il livello dell'applicazione SAP e il livello DBMS. In alcuni scenari dei clienti, le appliance virtuali di rete possono causare errori dei cluster Linux Pacemaker. Si tratta di casi in cui le comunicazioni tra i nodi del cluster Linux Pacemaker e il relativo dispositivo SBD avvengono tramite un'appliance virtuale di rete.

Importante

Un'altra struttura non supportata è la separazione del livello dell'applicazione SAP e del livello DBMS in reti virtuali Azure diverse non connesse tramite peering. È consigliabile separare il livello dell'applicazione SAP e il livello DBMS usando subnet all'interno di una rete virtuale di Azure, anziché usare reti virtuali di Azure diverse.

Se si decide di non seguire la raccomandazione e separare i due livelli in reti virtuali diverse, le due reti virtuali devono essere connesse tramite peering.

Tenere presente che il traffico di rete tra due reti virtuali di Azure connesse tramite peering è soggetto a costi di trasferimento. Grandi volumi di dati dell'ordine di molti terabyte vengono scambiati tra il livello dell'applicazione SAP e il livello DBMS. Si possono originare costi sostanziali se il livello dell'applicazione SAP e il livello DBMS sono separati tra due reti virtuali di Azure connesse tramite peering.

Usare Azure Load Balancer per reindirizzare il traffico

L'uso di indirizzi IP virtuali privati usati in funzionalità quali SQL Server Always On o replica di sistema HANA richiede la configurazione di un'istanza di Azure Load Balancer. Il servizio di bilanciamento del carico usa le porte probe per determinare il nodo DBMS attivo e instradare il traffico esclusivamente verso quel nodo del database attivo.

Se si verifica un failover del nodo del database, non è necessario riconfigurare l'applicazione SAP. Le architetture delle applicazioni SAP più comuni invece si riconnettono all'indirizzo IP virtuale privato. Nel frattempo, il servizio di bilanciamento del carico reagisce al failover del nodo reindirizzando il traffico nell'indirizzo IP virtuale privato verso il secondo nodo.

Azure offre due diversi SKU di bilanciamento del carico: SKU Basic e SKU Standard. In base ai vantaggi della configurazione e delle funzionalità, è consigliabile usare lo SKU Standard del servizio di bilanciamento del carico di Azure. Uno dei grandi vantaggi della versione Standard del servizio di bilanciamento del carico è che il traffico dei dati non viene instradato attraverso il servizio di bilanciamento del carico stesso.

Un esempio di come configurare un servizio di bilanciamento del carico interno è disponibile nell'articolo Esercitazione: Configurare un gruppo di disponibilità di SQL Server in macchine virtuali di Azure manualmente

Nota

Esistono differenze nel comportamento dello SKU Basic e Standard correlato all'accesso degli indirizzi IP pubblici. Il modo in cui risolvere le restrizioni dello SKU Standard per accedere agli indirizzi IP pubblici è descritto nel documento Connettività degli endpoint pubblici per le macchine virtuali usando Azure Load Balancer Standard in scenari a disponibilità elevata SAP

Distribuzione del monitoraggio host

Per un uso in ambiente di produzione delle applicazioni SAP in macchine virtuali di Azure, SAP deve poter recuperare i dati di monitoraggio host dagli host fisici che eseguono le macchine virtuali di Azure. È necessario un livello di patch dell'agente host SAP specifico che abilita questa funzionalità in SAPOSCOL e nell'agente host SAP. L'esatto livello di patch è documentato nella nota SAP 1409604.

Per altre informazioni sulla distribuzione dei componenti che forniscono dati host a SAPOSCOL e all'agente host SAP e alla gestione del ciclo di vita di tali componenti, iniziare con l'articolo Implementare l'estensione macchina virtuale di Azure per soluzioni SAP.

Passaggi successivi

Per altre informazioni su un particolare DBMS, vedere: