Condividi tramite

Configurazioni e operazioni dell'infrastruttura SAP HANA in Azure

  • Articolo

Questa guida contiene le indicazioni necessarie per configurare l'infrastruttura di Azure e gestire i sistemi SAP HANA distribuiti in macchine virtuali native di Azure. Il documento include anche informazioni sulla configurazione per lo scale-out di SAP HANA per lo SKU di VM M128s. Questo documento non è destinato a sostituire la documentazione standard di SAP, che include i contenuti seguenti:

Prerequisiti

Per usare questa guida sono necessarie conoscenze di base dei componenti di Azure seguenti:

Per altre informazioni su SAP NetWeaver e altri componenti SAP in Azure, vedere la sezione SAP della documentazione di Azure.

Considerazioni di base sulla configurazione

Le sezioni seguenti offrono considerazioni di base sulla configurazione per la distribuzione di sistemi SAP HANA in macchine virtuali di Azure.

Connettersi nelle macchine virtuali di Azure

Come illustrato nella Guida alla pianificazione di macchine virtuali di Azure, sono disponibili due metodi di base per la connessione nelle macchine virtuali di Azure:

  • Connessione tramite Internet ed endpoint pubblici in una macchina virtuale di collegamento o in una macchina virtuale che esegue SAP HANA.
  • Connessione tramite una rete VPN o Azure ExpressRoute.

Per gli scenari di produzione è necessaria la connettività da sito a sito tramite VPN o ExpressRoute. Questo tipo di connessione è necessario anche per gli scenari non di produzione che si inseriscono negli scenari di produzione in cui viene usato il software SAP. La figura seguente mostra un esempio di connettività intersito:

Connettività intersito

Scegliere i tipi di macchine virtuali di Azure

SAP indica quali tipi di macchina virtuale di Azure è possibile usare per gli scenari di produzione. Per gli scenari non di produzione è disponibile una gamma più ampia di macchine virtuali native di Azure.

Nota

Per gli scenari non di produzione, usare i tipi di macchine virtuali elencati nella nota di SAP #1928533. Per l'utilizzo di macchine virtuali di Azure per gli scenari di produzione, scegliere macchine virtuali con certificazione SAP HANA nell'elenco di piattaforme IaaS certificate pubblicato da SAP.

Per distribuire le macchine virtuali in Azure, usare:

  • Il portale di Azure.
  • cmdlet di Azure PowerShell.
  • Interfaccia della riga di comando di Azure.

Importante

Per usare le macchine virtuali M208xx_v2, è necessario prestare attenzione quando si seleziona l'immagine Linux. Per altre informazioni, vedere Dimensioni delle macchine virtuali ottimizzate per la memoria.

Configurazione dell'archiviazione per SAP HANA

Per le configurazioni dell'archiviazione e i tipi di archiviazione da usare con SAP HANA in Azure, leggere il documento Configurazioni dell'archiviazione di macchine virtuali di Azure in SAP HANA

Configurare le reti virtuali di Azure

Dopo aver stabilito la connettività da sito a sito in Azure tramite VPN o ExpressRoute, è necessario avere almeno una rete virtuale di Azure che sia connessa tramite un gateway virtuale al circuito VPN o ExpressRoute. Nelle distribuzioni semplici il gateway virtuale può essere distribuito in una subnet della rete virtuale di Azure che ospita anche le istanze di SAP HANA. Per installare SAP HANA, creare altre due subnet all'interno della rete virtuale di Azure. Una subnet ospita le macchine virtuali necessarie per eseguire le istanze di SAP HANA, mentre l'altra esegue macchine virtuali Jumpbox o di gestione per ospitare SAP HANA Studio, altro software di gestione o il software dell'applicazione.

Importante

Se non per motivi di funzionalità, ma più importante se non per motivi di prestazioni, non è supportato configurare appliance virtuali di rete di Azure nel percorso di comunicazione tra l'applicazione SAP e il livello DBMS di un sistema SAP basato su SAP NetWeaver, Hybris o S/4 HANA. La comunicazione tra il livello applicazione SAP e il livello DBMS deve essere diretta. La limitazione non include le regole Azure ASG e NSG, a condizione che queste regole ASG e NSG consentano la comunicazione diretta. Altri scenari in cui non sono supportate appliance virtuali di rete sono nei percorsi di comunicazione tra macchine virtuali di Azure che rappresentano i nodi del cluster Pacemaker di Linux e i dispositivi SBD, come descritto in Disponibilità elevata per SAP NetWeaver su macchine virtuali di Azure in SUSE Linux Enterprise Server for SAP applications. Oppure nei percorsi di comunicazione tra macchine virtuali di Azure e Windows Server SOFS configurati come descritto in Clustering di un'istanza ASCS/SCS di SAP in un cluster di failover Windows tramite una condivisione file in Azure. Le appliance virtuali di rete nei percorsi di comunicazione possono facilmente raddoppiare la latenza di rete tra due partner di comunicazione e possono limitare la velocità effettiva nei percorsi critici tra il livello applicazione SAP e il livello DBMS. In alcuni scenari esaminati con i clienti, le appliance virtuali di rete possono causare errori dei cluster Linux Pacemaker nei 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 peer. È 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 il consiglio e separare i due livelli in reti virtuali diverse, le due reti virtuali devono essere peer. Tenere presente che il traffico di rete tra due reti virtuali peer di Azure è soggetto a costi di trasferimento. Se il livello dell'applicazione SAP e il livello DBMS vengono separati tra due reti virtuali Azure peer, i grandi volumi di dati (dell'ordine di molti terabyte) scambiati tra il livello dell'applicazione SAP e il livello DBMS possono originare costi sostanziali.

Se sono state distribuite macchine virtuali Jumpbox o di gestione in subnet separate, è possibile definire più schede di interfaccia di rete virtuali (vNIC) per la macchina virtuale HANA, ognuna delle quali assegnata a una subnet diversa. Poiché possono essere presenti più vNIC, è possibile configurare la separazione del traffico di rete, se necessario. Ad esempio, il traffico del client può essere instradato attraverso la vNIC primaria e il traffico di amministrazione può essere instradato attraverso una vNIC secondaria.
Assegnare anche indirizzi IP privati statici che vengono distribuiti per entrambe le vNIC.

Nota

È consigliabile assegnare indirizzi IP statici tramite Azure alle singole schede di interfaccia di rete virtuali. Non è opportuno 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 sia impostata su DHCP e non su indirizzi IP statici. Vedere anche il documento Risolvere i problemi relativi al backup delle macchine virtuali di Azure. Se è necessario assegnare più indirizzi IP statici a una macchina virtuale, occorre assegnare più schede di interfaccia di rete virtuali a una macchina virtuale.

Per le distribuzioni permanenti, è tuttavia necessario creare un'architettura di rete del data center virtuale in Azure. Con questa architettura è consigliabile separare il gateway di rete virtuale di Azure che si connette all'ambiente locale in una rete virtuale di Azure distinta. Questa rete virtuale separata deve ospitare tutto il traffico diretto all'ambiente locale o a Internet. Questo approccio consente di distribuire il software per il controllo e la registrazione del traffico che entra nel data center virtuale in Azure in questa rete virtuale dell'hub separata. Si avrà quindi una rete virtuale che ospita tutte le soluzioni software e le configurazioni relative al traffico in ingresso e in uscita nella distribuzione di Azure.

Gli articoli Data center virtuale di Microsoft Azure: una prospettiva di rete e Data center virtuale di Azure e piano di controllo aziendale forniscono altre informazioni sull'approccio basato su data center virtuale e sulla struttura della rete virtuale di Azure correlata.

Nota

Il traffico trasmesso tra una rete virtuale dell'hub e la rete virtuale spoke con il peering reti virtuali di Azure è soggetto a costi aggiuntivi. In base a tali costi, potrebbe essere necessario valutare l'opportunità di un compromesso tra l'esecuzione di una struttura di rete hub-spoke rigorosa e l'esecuzione di più gateway di Azure ExpressRoute da connettere agli "spoke" per ignorare il peering reti virtuali. Anche i gateway di Azure ExpressRoute comportano tuttavia costi aggiuntivi. È anche possibile incorrere in costi aggiuntivi per il software di terze parti usato per la registrazione, il controllo e il monitoraggio del traffico di rete. A seconda dei costi per lo scambio di dati tramite il peering reti virtuali da un lato e dei costi creati dai gateway di Azure ExpressRoute aggiuntivi e dalle licenze software aggiuntive, è possibile decidere per la micro-segmentazione all'interno di una rete virtuale usando le subnet come unità di isolamento invece delle reti virtuali.

Per una panoramica dei diversi metodi per l'assegnazione di indirizzi IP, vedere Tipi di indirizzi IP e metodi di allocazione in Azure.

Per le macchine virtuali che eseguono SAP HANA, è consigliabile usare indirizzi IP statici assegnati, perché alcuni attributi di configurazione per HANA fanno riferimento a indirizzi IP.

I gruppi di sicurezza di rete di Azure vengono usati per indirizzare il traffico instradato all'istanza di SAP HANA o al jumpbox. I gruppi di sicurezza di rete ed eventualmente i gruppi di sicurezza delle applicazioni sono associati alla subnet di SAP HANA e alla subnet di gestione.

Per distribuire SAP HANA in Azure senza una connessione da sito a sito, è comunque necessario schermare l'istanza di SAP HANA da Internet pubblico e nasconderla dietro un proxy di inoltro. In questo scenario di base la distribuzione si basa su servizi DNS predefiniti di Azure per risolvere i nomi host. Questi servizi sono particolarmente importanti in distribuzioni più complesse in cui vengono usati indirizzi IP pubblici. Usare i gruppi di sicurezza di rete di Azure e le appliance virtuali di rete di Azure per controllare e monitorare il routing da Internet all'architettura di rete virtuale di Azure in Azure. L'immagine seguente mostra uno schema approssimativo per la distribuzione di SAP HANA senza connessione da sito a sito in un'architettura di rete virtuale hub-spoke:

Schema di distribuzione approssimativo per SAP HANA senza connessione da sito a sito

Per un'altra descrizione di come usare le appliance virtuali di rete di Azure per controllare e monitorare l'accesso da Internet senza l'architettura di rete virtuale hub-spoke, vedere l'articolo Distribuire appliance virtuali di rete con disponibilità elevata.

Opzioni di origine dell'orologio nelle macchine virtuali di Azure

Per funzionare in modo ottimale, SAP HANA richiede informazioni relative all'orario precise e affidabili. Le macchine virtuali di Azure in esecuzione nell'hypervisor di Azure hanno sempre usato solo la pagina TSC Hyper-V come origine dell'orologio predefinita. I progressi della tecnologia relativi all'hardware, al sistema operativo host e ai kernel del sistema operativo guest Linux hanno reso possibile fornire un "TSC invariante" come opzione di origine dell'orologio in alcuni SKU di macchine virtuali di Azure.

La pagina TSC Hyper-V (hyperv_clocksource_tsc_page) è supportata in tutte le macchine virtuali di Azure come origine dell'orologio. Se l'hardware sottostante, l'hypervisor e il kernel Linux del sistema operativo guest supportano il TSC invariante, nel sistema operativo guest delle macchine virtuali di Azure sarà disponibile e supportata anche l'opzione tsc come origine dell'orologio.

Configurazione dell'infrastruttura di Azure per lo scale-out di SAP HANA

Per individuare i tipi di macchina virtuale di Azure certificati per lo scale-out OLAP o lo scale-out S/4HANA, controllare la directory hardware di SAP HANA. Un segno di spunta nella colonna "Clustering" indica il supporto di scale-out. Il tipo di applicazione indica se è supportato lo scale-out OLAP o S/4HANA. Per informazioni dettagliate sui nodi certificati per l'operazione di scale-out, vedere la voce relativa allo SKU della macchina virtuale specifica disponibile nella directory hardware di SAP HANA.

Le versioni minime del sistema operativo per la distribuzione delle configurazioni con scale-out nelle macchine virtuali di Azure, vedere i dettagli delle voci nello SKU della VM specifica riportato nella directory hardware di SAP HANA. In una configurazione con scale-out OLAP a n nodi, un nodo funziona come nodo principale. Gli altri nodi fino al limite della certificazione agiscono da nodi di lavoro. Ulteriori nodi di standby non vengono contati nel numero di nodi certificati

Nota

Nelle macchine virtuali di Azure le distribuzioni con scale-out di SAP HANA con nodo di standby sono possibili solo usando l'archiviazione Azure NetApp Files. Nessun'altra archiviazione di Azure certificata SAP HANA consente la configurazione dei nodi di standby di SAP HANA

Per /hana/shared, è consigliabile utilizzare Azure NetApp Files o File di Azure.

Una tipica architettura di base per un nodo singolo in una configurazione scale-out, con la directory /hana/shared distribuita in Azure NetApp Files, sarà simile alla seguente:

Diagramma che illustra una tipica architettura di base per un nodo singolo in una configurazione scale-out.

La configurazione di base di un nodo di macchina virtuale per lo scale-out di SAP HANA è simile alla seguente:

  • Per /hana/shared usare il servizio NFS nativo disponibile tramite Azure NetApp Files o File di Azure.
  • Tutti gli altri volumi di dischi non vengono condivisi tra i diversi nodi e non sono basati su NFS. Le configurazioni e le procedure per le installazioni di HANA con scale-out con /hana/data e /hana/log non condivisi sono illustrate più avanti in questo documento. Per l'archiviazione con certificazione HANA che è possibile usare, vedere l'articolo Configurazioni dell'archiviazione di macchine virtuali di Azure in SAP HANA.

Se si ridimensionano i volumi o i dischi, è necessario consultare il documento sui requisiti di archiviazione TDI di SAP HANA, per le dimensioni richieste in base al numero di nodi di lavoro. Nel documento è indicata una formula che deve essere applicata per ottenere la capacità necessaria del volume

L'altro criterio di progettazione visualizzato nelle immagini della configurazione a nodo singolo per una VM SAP HANA con scale-out è la configurazione della rete virtuale, o meglio delle subnet. SAP consiglia di separare il traffico destinato ai client o alle applicazioni dalle comunicazioni tra i nodi HANA. Come illustrato nelle immagini, questo obiettivo viene raggiunto con due diverse schede di interfaccia di rete virtuale collegate alla VM. Le due schede di interfaccia di rete virtuale si trovano in subnet diverse e hanno due indirizzi IP diversi. È quindi possibile controllare il flusso del traffico con regole di routing che usano gruppi di sicurezza di rete o route definite dall'utente.

In particolare in Azure non esistono mezzi e metodi per applicare Qualità del servizio (QoS) e quote in schede di interfaccia di rete virtuale specifiche. Di conseguenza, la separazione delle comunicazioni all'interno del nodo e verso il client o l'applicazione non consente in alcun modo di assegnare la priorità a un flusso di traffico rispetto a un altro. La separazione rimane invece una misura di sicurezza per proteggere le comunicazioni tra i nodi delle configurazioni con scale-out.

Nota

SAP consiglia di separare il traffico di rete destinato ai client o alle applicazioni e il traffico tra i nodi, come descritto in questo documento. È quindi consigliabile adottare un'architettura come quella illustrata nelle ultime immagini. Consultare anche il team addetto alla sicurezza e alla conformità per i requisiti che deviano dalla raccomandazione

Per quanto riguarda la rete, l'architettura minima richiesta sarà simile alla seguente:

Nozioni di base sullo scale-out di un singolo nodo

Installazione dello scale-out SAP HANA in Azure

Per installare una configurazione SAP con scale-out, è necessario eseguire i passaggi generali seguenti:

  • Distribuzione di una nuova infrastruttura di rete virtuale di Azure o adattamento di un'infrastruttura esistente
  • Distribuzione di nuove macchine virtuali con Archiviazione Premium gestita di Azure, volumi su dischi Ultra e/o volumi NFS basati su ANF
    • Adattare il routing di rete per assicurarsi ad esempio che la comunicazione all'interno di un nodo tra le macchine virtuali non venga instradata tramite un'appliance virtuale di rete.
  • Installare il nodo principale SAP HANA.
  • Adattare i parametri di configurazione del nodo principale SAP HANA.
  • Continuare l'installazione dei nodi di lavoro SAP HANA

Installazione di SAP HANA nella configurazione con scale-out

Quando viene distribuita l'infrastruttura di VM di Azure e vengono eseguite tutte le altre operazioni di preparazione, è necessario installare le configurazioni con scale-out di SAP HANA seguendo questi passaggi:

  • Installare il nodo principale SAP HANA in base alla documentazione di SAP.
  • Quando si usa Archiviazione Premium di Azure o Archiviazione su disco Ultra con dischi non condivisi di /hana/data e /hana/log, aggiungere il parametro basepath_shared = no al file global.ini. Questo parametro consente di eseguire SAP HANA in modalità scale-out senza i volumi /hana/data e /hana/log condivisi tra i nodi. Informazioni dettagliate sono fornite nella nota SAP n. 2080991. Se si usano volumi NFS basati su ANF per /hana/data e /hana/log, non è necessario apportare questa modifica
  • Dopo aver apportato l'eventuale modifica al parametro global.ini, riavviare l'istanza di SAP HANA
  • Aggiungere altri nodi di lavoro. Per ulteriori informazioni, vedere Aggiungere host tramite l'interfaccia della riga di comando. Specificare la rete interna per la comunicazione tra nodi di SAP HANA durante l'installazione o in seguito usando, ad esempio, hdblcm locale. Per una documentazione più dettagliata, vedere la nota SAP n. 2183363.

Per configurare un sistema scale-out SAP HANA con un nodo di standby, vedere le istruzioni per la distribuzione di SUSE Linux o le istruzioni per la distribuzione di Red Hat.

SAP HANA Dynamic Tiering 2.0 per macchine virtuali di Azure

Oltre alle certificazioni di SAP HANA nelle macchine virtuali serie M di Azure, in Microsoft Azure è supportato anche SAP HANA Dynamic Tiering 2.0. Per altre informazioni, vedere i collegamenti alla documentazione di DT 2.0. Non c'è alcuna differenza nell'installazione o nel funzionamento del prodotto. Ad esempio, è possibile installare SAP HANA Cockpit in una macchina virtuale di Azure. Esistono tuttavia alcuni requisiti obbligatori, descritti nella sezione seguente, per il supporto ufficiale in Azure. Nel resto di questo articolo verrà usata l'abbreviazione "DT 2.0" invece del nome completo Dynamic Tiering 2.0.

SAP HANA Dynamic Tiering 2.0 non è supportato da SAP BW o S4HANA. I casi d'uso principali sono attualmente le applicazioni HANA native.

Panoramica

La figura seguente offre una panoramica del supporto di DT 2.0 in Microsoft Azure. Per garantire la conformità alla certificazione ufficiale, esiste un set di requisiti obbligatori, che devono essere soddisfatti:

  • DT 2.0 deve essere installato in una VM di Azure dedicata. Non può essere eseguito nella stessa VM in cui viene eseguito SAP HANA
  • Le VM SAP HANA e DT 2.0 devono essere distribuite nella stessa rete virtuale di Azure
  • Le VM SAP HANA e DT 2.0 devono essere distribuite con la rete accelerata di Azure abilitata
  • Il tipo di archiviazione per le VM DT 2.0 deve essere Archiviazione premium di Azure
  • Alla VM DT 2.0 devono essere collegati più dischi di Azure
  • È necessario creare un volume RAID/con striping software (tramite lvm o mdadm) usando lo striping tra i dischi di Azure

Altri dettagli verranno illustrati nelle sezioni seguenti.

Panoramica dell'architettura di SAP HANA DT 2.0

VM di Azure dedicata per SAP HANA DT 2.0

In IaaS di Azure DT 2.0 è supportato solo in una VM dedicata. Non è consentito eseguire DT 2.0 nella stessa macchina virtuale di Azure in cui è in esecuzione l'istanza di HANA. Inizialmente si possono usare due tipi di macchina virtuale per eseguire SAP HANA DT 2.0:

  • M64-32ms
  • E32sv3

Per altre informazioni sulla descrizione del tipo di macchina virtuale, vedere Dimensioni delle macchine virtuali di Azure - Memoria

Considerata l'idea alla base di DT 2.0, ovvero l'offloading dei dati ad accesso frequente per risparmiare sui costi, la scelta migliore è usare dimensioni di VM corrispondenti. Non esistono regole rigide riguardanti le possibili combinazioni. Tutto dipende dal carico di lavoro del cliente specifico.

Le configurazioni consigliate sono:

Tipo di VM SAP HANA Tipo di VM DT 2.0
M128ms M64-32ms
M128s M64-32ms
M64ms E32sv3
M64s E32sv3

Sono possibili tutte le combinazioni di macchine virtuali della serie M certificate per SAP HANA con macchine virtuali DT 2.0 supportate (M64-32ms e E32sv3).

Rete di Azure e SAP HANA DT 2.0

Per installare DT 2.0 in una VM dedicata, è necessaria una velocità effettiva di rete tra la VM DT 2.0 e la VM SAP HANA di almeno 10 GB. È quindi obbligatorio inserire tutte le VM nella stessa rete virtuale di Azure e abilitare la rete accelerata di Azure.

Per altre informazioni sulla rete accelerata di Azure, vedere Creare una macchina virtuale di Azure con rete accelerata usando l'interfaccia della riga di comando di Azure

Risorse di archiviazione delle macchine virtuali per SAP HANA DT 2.0

In base alle indicazioni sulle procedure consigliate di DT 2.0, la velocità effettiva di I/O dei dischi deve essere almeno di 50 MB/sec per ogni core fisico.

In base alle specifiche per i due tipi di macchina virtuale di Azure supportati per DT 2.0, il limite massimo della velocità effettiva di I/O dei dischi per la macchina virtuale sarà il seguente:

  • E32sv3: 768 MB/sec (senza memorizzazione nella cache), ovvero 48 MB/sec per ogni core fisico
  • M64-32ms: 1000 MB/sec (senza memorizzazione nella cache), ovvero 62,5 MB/sec per ogni core fisico

Per raggiungere il limite massimo della velocità effettiva del disco per ogni macchina virtuale, è necessario collegare più dischi di Azure alla macchina virtuale DT 2.0 e creare un volume RAID (striping) software a livello di sistema operativo. A questo proposito, un singolo disco di Azure non può fornire la velocità effettiva necessaria per raggiungere il limite massimo per la macchina virtuale. Archiviazione Premium di Azure è obbligatorio per eseguire DT 2.0.

A seconda dei requisiti delle dimensioni, sono disponibili diverse opzioni per raggiungere la velocità effettiva massima di una VM. Di seguito sono elencate le possibili configurazioni dei dischi volume di dati per ogni tipo di VM DT 2.0 per raggiungere il limite massimo di velocità effettiva della VM. La VM E32sv3 deve essere considerata come base per i carichi di lavoro più piccoli. Se non dovesse risultare abbastanza veloce, potrebbe essere necessario ridimensionare la VM a M64-32ms. Poiché la VM M64-32ms ha una quantità elevata di memoria, il carico di I/O potrebbe non raggiungere il limite soprattutto per i carichi di lavoro che eseguono un'intensa attività di lettura. Un numero inferiore di dischi nel set di striping potrebbe quindi essere sufficiente a seconda del carico di lavoro specifico del cliente, ma, per sicurezza, le configurazioni dei dischi seguenti sono state scelte per garantire la velocità effettiva massima:

SKU di VM Configurazione disco 1 Configurazione disco 2 Configurazione disco 3 Configurazione disco 4 Configurazione disco 5
M64-32ms 4 P50 -> 16 TB 4 P40 -> 8 TB 5 P30 -> 5 TB 7 P20 -> 3,5 TB 8 P15 -> 2 TB
E32sv3 3 P50 -> 12 TB 3 P40 -> 6 TB 4 P30 -> 4 TB 5 P20 -> 2,5 TB 6 P15 -> 1,5 TB

Soprattutto in caso di intensa attività di lettura del carico di lavoro, per incrementare le prestazioni di I/O, è possibile attivare la cache host di Azure "di sola lettura" consigliata per i volumi di dati del software del database. Per il log delle transazioni invece, la cache del disco host di Azure deve essere "nessuna".

Per quanto riguarda le dimensioni del volume di log, è consigliabile iniziare con un 15% euristico delle dimensioni dei dati. La creazione del volume di log può essere eseguita usando tipi diversi di dischi di Azure a seconda del costo e dei requisiti di velocità effettiva. Per il volume di log è richiesta una velocità effettiva di I/O elevata.

Quando si usa il tipo di macchina virtuale M64-32ms, è necessario abilitare l'acceleratore di scrittura. L'acceleratore di scrittura di Azure offre la latenza di scrittura su disco ottimale per il log delle transazioni (disponibile solo per la serie M). Esistono tuttavia alcuni elementi da considerare, ad esempio, il numero massimo di dischi per tipo di VM. Per informazioni dettagliate sull'acceleratore di scrittura, vedere la pagina Acceleratore di scrittura di Azure

Ecco alcuni esempi di dimensioni del volume di log:

dimensioni volume dati e tipo di disco configurazione volume di log e tipo di disco 1 configurazione volume di log e tipo di disco 2
4 P50 -> 16 TB 5 P20 -> 2,5 TB 3 x P30 -> 3 TB
6 P15 -> 1,5 TB 4 x P6 -> 256 GB 1 x P15 -> 256 GB

Come per lo scale-out di SAP HANA, la directory /hana/shared deve essere condivisa tra la VM SAP HANA e la VM DT 2.0. È consigliabile la stessa architettura dello scale-out di SAP HANA con VM dedicate, che fungono da server NFS a disponibilità elevata. Per fornire un volume di backup condiviso, si può usare la medesima progettazione, Ma sarà il cliente a decidere se è necessaria la disponibilità elevata o se è sufficiente usare una macchina virtuale dedicata con capacità di archiviazione sufficiente per fungere da server di backup.

Operazioni per la distribuzione di SAP HANA in macchine virtuali di Azure

Le sezioni seguenti descrivono alcune delle operazioni correlate alla distribuzione di sistemi SAP HANA in macchine virtuali di Azure.

Operazioni di backup e ripristino nelle macchine virtuali di Azure

I documenti seguenti descrivono come eseguire il backup e il ripristino della distribuzione di SAP HANA:

Avviare e riavviare le macchine virtuali che contengono SAP HANA

Una delle principali caratteristiche del cloud pubblico di Azure è che i costi vengono addebitati solo in base ai minuti di calcolo. Ad esempio, quando si arresta una macchina virtuale che esegue SAP HANA, durante l'intervallo di calcolo vengono fatturati solo i costi di archiviazione. Un'altra caratteristica si presenta quando si specificano gli indirizzi IP statici per le macchine virtuali nella distribuzione iniziale. Quando si riavvia una macchina virtuale con SAP HANA, la macchina viene riavviata con l'indirizzo IP precedente.

Usare SAProuter per il supporto remoto SAP

Se esiste una connessione da sito a sito tra le sedi locali e Azure e si eseguono componenti SAP, è probabile che SAProuter sia già in esecuzione. In questo caso, completare le attività seguenti per il supporto remoto:

  • Gestire l'indirizzo IP privato e statico della macchina virtuale che ospita SAP HANA nella configurazione di SAProuter.
  • Configurare il gruppo di sicurezza di rete della subnet che ospita la macchina virtuale HANA per consentire il traffico attraverso la porta TCP/IP 3299.

Se ci si connette ad Azure tramite Internet senza avere a disposizione un router SAP per la macchina virtuale con SAP HANA, è necessario installare il componente. Installare SAProuter in una macchina virtuale separata nella subnet di gestione. L'immagine seguente mostra uno schema approssimativo per la distribuzione di SAP HANA senza connessione da sito a sito e con SAProuter:

Schema di distribuzione approssimativo per SAP HANA senza connessione da sito a sito e con SAProuter

Installare SAProuter in una macchina virtuale separata e non nella macchina virtuale Jumpbox. La macchina virtuale separata deve avere un indirizzo IP statico. Per connettere la propria istanza di SAProuter all'istanza di SAProuter ospitata da SAP, contattare SAP per chiedere un indirizzo IP. L'istanza di SAProuter ospitata da SAP è la controparte dell'istanza di SAProuter installata nella macchina virtuale. Usare l'indirizzo IP fornito da SAP per configurare l'istanza di SAProuter. Nelle impostazioni di configurazione l'unica porta necessaria è la porta TCP 3299.

Per altre informazioni su come configurare e gestire le connessioni di supporto remoto tramite SAProuter, vedere la documentazione di SAP.

Disponibilità elevata con SAP HANA in macchine virtuali native di Azure

Se si esegue SUSE Linux Enterprise Server o Red Hat, è possibile definire un cluster Pacemaker con dispositivi di isolamento. È possibile usare i dispositivi per impostare una configurazione di SAP HANA che usi la replica sincrona con la replica di sistema HANA e il failover automatico. Per altre informazioni, vedere la sezione Passaggi successivi.

Passaggi successivi

Acquisire familiarità con gli articoli elencati