Modifica

Eseguire SAP HANA per macchine virtuali Linux in un'architettura con scalabilità verticale in Azure

Azure
Macchine virtuali di Azure

Questa architettura di riferimento illustra un set di procedure comprovate per l'esecuzione di SAP HANA in un ambiente a disponibilità elevata e scalabilità orizzontale che supporta il ripristino di emergenza in Azure. Questa implementazione è incentrata solo sul livello del database.

Architettura

Questa architettura di riferimento descrive un sistema di produzione comune. È possibile scegliere le dimensioni delle macchine virtuali per soddisfare le esigenze dell'organizzazione. Questa configurazione può anche essere ridotta a una macchina virtuale, a seconda dei requisiti aziendali.

Il diagramma seguente illustra un'architettura di riferimento per SAP HANA in Azure:

Diagramma che mostra un'architettura di distribuzione a livello di area.

Scaricare un file di Visio contenente i diagrammi in questo articolo.

Nota

Per distribuire questa architettura di riferimento, sono necessarie le licenze appropriate dei prodotti SAP e di altre tecnologie non Microsoft.

Workflow

Questa architettura di riferimento descrive un tipico database SAP HANA in esecuzione in Azure, in una distribuzione a disponibilità elevata per ottimizzare la disponibilità del sistema. L'architettura e i relativi componenti possono essere personalizzati in base ai requisiti aziendali (RTO, RPO, aspettative del tempo di attività, ruolo del sistema) e potenzialmente ridotti a una singola macchina virtuale. Il layout di rete è semplificato per illustrare le entità architetturali di tale ambiente SAP e non intende descrivere una rete aziendale completa.

Rete

Reti virtuali. Il servizio Azure Rete virtuale connette le risorse di Azure tra loro con sicurezza avanzata. In questa architettura la rete virtuale si connette a un ambiente locale tramite un gateway ExpressRoute distribuito nell'hub di una topologia hub-spoke. Il database SAP HANA è contenuto nella propria rete virtuale spoke. Le reti virtuali spoke contengono una subnet per le macchine virtuali di database.

Se le applicazioni che si connettono a SAP HANA sono in esecuzione nelle macchine virtuali, le macchine virtuali dell'applicazione devono trovarsi nella stessa rete virtuale, ma all'interno di una subnet dell'applicazione dedicata. In alternativa, se la connessione SAP HANA non è il database primario, le macchine virtuali dell'applicazione possono trovarsi in altre reti virtuali. La separazione in subnet per carico di lavoro consente di abilitare più facilmente i gruppi di sicurezza di rete (NSG) per impostare le regole di sicurezza applicabili solo alle macchine virtuali SAP HANA.

Gateway con ridondanza della zona. Un gateway connette reti distinte, estendendo la rete locale alla rete virtuale di Azure. È consigliabile usare ExpressRoute per creare connessioni private che non passano tramite Internet pubblico. È anche possibile usare una connessione da sito a sito . I gateway VPN o ExpressRoute di Azure possono essere distribuiti tra zone per proteggersi dagli errori della zona. Vedere Gateway di rete virtuale con ridondanza della zona per comprendere le differenze tra una distribuzione di zona e una distribuzione con ridondanza della zona. Gli indirizzi IP usati devono essere sku Standard per una distribuzione di zona dei gateway.

Gruppi di sicurezza di rete (NSG). Per limitare il traffico di rete in ingresso e in uscita della rete virtuale, creare gruppi di sicurezza di rete, che a loro volta vengono assegnati a subnet specifiche. Le subnet del database e dell'applicazione sono protette con gruppi di sicurezza di rete specifici del carico di lavoro.

Gruppi di sicurezza delle applicazioni (ASG). Per definire criteri di sicurezza di rete con granularità fine all'interno dei gruppi di sicurezza di rete in base ai carichi di lavoro incentrati sulle applicazioni, usare gruppi di sicurezza delle applicazioni anziché indirizzi IP espliciti. Consentono di raggruppare le interfacce di rete delle macchine virtuali in base al nome e di proteggere le applicazioni filtrando il traffico da segmenti attendibili della rete.

Schede di interfaccia di rete (NIC). Le schede di interfaccia di rete consentono tutte le comunicazioni tra macchine virtuali in una rete virtuale. Le tradizionali distribuzioni SAP locali implementano più schede di interfaccia di rete per ogni macchina per segregare il traffico amministrativo rispetto al traffico aziendale.

In Azure non è necessario usare più schede di interfaccia di rete per motivi di prestazioni. Più schede di interfaccia di rete condividono lo stesso limite di velocità effettiva di rete di una macchina virtuale. Tuttavia, se l'organizzazione deve separare il traffico, è possibile distribuire più schede di interfaccia di rete per macchina virtuale e connettere ogni scheda di interfaccia di rete a una subnet diversa. È quindi possibile usare i gruppi di sicurezza di rete per applicare criteri di controllo di accesso diversi in ogni subnet.

Le schede di interfaccia di rete di Azure supportano più indirizzi IP. Questo supporto è conforme alla procedura consigliata sap di usare i nomi host virtuali per le installazioni. Per una struttura completa, vedere la nota SAP 962955. Per accedere alle note SAP, è necessario un account SAP Service Marketplace.

Nota

Come specificato nella nota SAP 2731110, non inserire alcuna appliance virtuale di rete tra l'applicazione e i livelli di database per qualsiasi stack di applicazioni SAP. In questo modo vengono introdotti pacchetti di dati significativi in fase di elaborazione e le prestazioni dell'applicazione sono inaccettabili.

Macchine virtuali

Questa architettura usa macchine virtuali (VM). Azure offre scalabilità a nodo singolo fino a 23,5 Tebibyte (TiB) di memoria nelle macchine virtuali. La directory hardware SAP Certified e Supported SAP HANA elenca le macchine virtuali certificate per il database SAP HANA. Per informazioni dettagliate sul supporto SAP per i tipi di macchine virtuali e le metriche di velocità effettiva (S piattaforma di strumenti analitici), vedere Sap Note 1928533 - SAP Applications on Microsoft Azure: Supported Products and Azure VM types (Nota SAP 1928533 - Applicazioni SAP in Microsoft Azure: prodotti supportati e tipi di macchine virtuali di Azure). Per accedere a questa e ad altre note SAP, è necessario un account SAP Service Marketplace.

Microsoft e SAP certificano congiuntamente una gamma di dimensioni delle macchine virtuali per i carichi di lavoro SAP HANA. Ad esempio, le distribuzioni più piccole possono essere eseguite in una macchina virtuale Edsv4 o Edsv5 con 160 GiB o più di RAM. Per supportare le dimensioni di memoria di SAP HANA più grandi nelle macchine virtuali, fino a 23 TiB, è possibile usare macchine virtuali serie Mv2. I tipi di macchine virtuali M208 raggiungono circa 260.000 S piattaforma di strumenti analitici e i tipi di macchine virtuali M832ixs raggiungono circa 795.900 S piattaforma di strumenti analitici.

Macchine virtuali di seconda generazione (Gen2). Quando si distribuiscono macchine virtuali, è possibile usare macchine virtuali di prima o seconda generazione. Le macchine virtuali di seconda generazione supportano le funzionalità chiave che non sono disponibili per le macchine virtuali di prima generazione. Per SAP HANA, questo aspetto è particolarmente importante perché alcune famiglie di macchine virtuali, ad esempio Mv2 e Mdsv2, sono supportate solo come macchine virtuali gen2. Analogamente, la certificazione SAP in Azure per alcune macchine virtuali più recenti potrebbe richiedere che siano solo Gen2 per il supporto completo, anche se Azure consente entrambi. Vedere i dettagli in SAP Note 1928533 - SAP Applications on Microsoft Azure: Supported Products and Azure VM types (Nota SAP 1928533 - Applicazioni SAP in Microsoft Azure: prodotti supportati e tipi di macchine virtuali di Azure).

Poiché tutte le altre macchine virtuali che supportano SAP HANA consentono di scegliere solo Gen2 o Gen1+2 in modo selettivo, è consigliabile distribuire tutte le macchine virtuali SAP solo come Gen2. Questo vale anche per le macchine virtuali con requisiti di memoria insufficiente. Anche la macchina virtuale SAP HANA di 160 GiB più piccola può essere eseguita come VM Gen2 e, quando deallocata, può essere ridimensionata alla macchina virtuale più grande disponibile nell'area e nella sottoscrizione.

Gruppi di posizionamento di prossimità (PPG). Per ottimizzare la latenza di rete, è possibile usare gruppi di posizionamento di prossimità, che favoriscono la collocazione, vale a dire che le macchine virtuali si trovano nello stesso data center per ridurre al minimo la latenza tra SAP HANA e connettere le macchine virtuali dell'applicazione. Per l'architettura SAP HANA stessa, non sono necessari ppg, ma è solo un'opzione che individua SAP HANA con macchine virtuali livello applicazione. A causa di potenziali restrizioni con i ppg, l'aggiunta del database AvSet al PPG del sistema SAP deve essere eseguita in modo sparse e solo quando necessario per la latenza tra l'applicazione SAP e il traffico del database. Per altre informazioni sugli scenari di utilizzo dei gruppi di disponibilità, vedere la documentazione collegata. Poiché i gruppi di disponibilità limitano i carichi di lavoro a un singolo data center, un PPG non può estendersi su più zone di disponibilità.

Componenti

Considerazioni

Questa sezione descrive le considerazioni principali per l'esecuzione di SAP HANA in Azure.

Scalabilità

Questa architettura esegue SAP HANA in macchine virtuali con scalabilità fino a 23 TiB in un'istanza.

Se il carico di lavoro supera le dimensioni massime della macchina virtuale, è consigliabile usare configurazioni HANA multinodo. Per le applicazioni OLTP (Online Transaction Processing), la capacità totale di memoria con scalabilità orizzontale può essere pari a 4 x 23 TiB. Per le applicazioni OLAP (Online Analytical Processing), la capacità di memoria con scalabilità orizzontale può essere pari a 16 x 7,6 TiB. Ad esempio, è possibile distribuire SAP HANA in una configurazione con scalabilità orizzontale con standby nelle macchine virtuali, che eseguono Red Hat Enterprise Linux o SU edizione Standard Linux Enterprise Server, usando Azure NetApp Files per i volumi di archiviazione condivisi.

Storage

Questa architettura usa i dischi gestiti di Azure per l'archiviazione nelle macchine virtuali o in Azure NetApp Files. Le linee guida per la distribuzione dell'archiviazione con dischi gestiti sono contenute nel documento configurazioni di archiviazione delle macchine virtuali di Azure SAP HANA. In alternativa ai dischi gestiti, i volumi NFS di Azure NetApp Files possono essere usati come soluzione di archiviazione per SAP HANA.

Per ottenere operazioni di input/output elevate al secondo (IOPS) e velocità effettiva di archiviazione su disco, le procedure comuni nell'ottimizzazione delle prestazioni del volume di archiviazione si applicano anche al layout di archiviazione di Azure. Ad esempio, la combinazione di più dischi con LVM per creare un volume disco con striping migliora le prestazioni di I/O. La memorizzazione nella cache dei dischi di Azure svolge anche un ruolo significativo per ottenere le prestazioni di I/O necessarie.

Per i dischi di log SAP HANA eseguiti in SSD Premium di Azure v1, usare una delle tecnologie seguenti in posizioni che contengono /hana/log per la produzione:

Queste tecnologie sono necessarie per soddisfare in modo coerente la latenza di archiviazione necessaria di meno di 1 ms.

Ssd Premium di Azure v2 è progettato per carichi di lavoro critici per le prestazioni, ad esempio SAP. L'acceleratore di scrittura non è necessario quando /hana/log è in esecuzione su SSD Premium v2. Per informazioni sui vantaggi e sulle limitazioni correnti di questa soluzione di archiviazione, vedere Distribuire un'unità SSD Premium v2.

Per informazioni dettagliate sui requisiti di prestazioni di SAP HANA, vedere SAP Note 1943937 - Hardware Configuration Check Tool.For details about SAP HANA performance requirements, see SAP Note 1943937 - Hardware Configuration Check Tool.

  • Progettazione dello spazio di archiviazione consapevole dei costi per sistemi non di produzione. Per gli ambienti SAP HANA che non richiedono prestazioni di archiviazione massime in tutte le situazioni, è possibile usare un'architettura di archiviazione ottimizzata per i costi. Questa scelta di ottimizzazione dell'archiviazione può essere applicata a sistemi di produzione poco usati o ad alcuni ambienti SAP HANA non di produzione. L'opzione di archiviazione ottimizzata per i costi usa una combinazione di UNITÀ SSD Standard anziché ssd Premium o Ultra usate per gli ambienti di produzione. Combina anche /hana/data e /hana/log file system in un singolo set di dischi. Sono disponibili linee guida e procedure consigliate per la maggior parte delle dimensioni delle macchine virtuali. Se si usa Azure NetApp Files per SAP HANA, è possibile usare volumi ridotti di dimensioni per raggiungere lo stesso obiettivo.

  • Ridimensionamento dell'archiviazione durante l'aumento delle prestazioni. Quando si ridimensiona una macchina virtuale a causa di esigenze aziendali modificate o a causa di dimensioni crescenti del database, la configurazione di archiviazione può cambiare. supporto tecnico di Azure l'espansione del disco online, senza interruzioni del servizio. Con un'installazione del disco con striping, come usato per SAP HANA, un'operazione di ridimensionamento deve essere eseguita allo stesso modo per tutti i dischi del gruppo di volumi. L'aggiunta di più dischi a un gruppo di volumi può potenzialmente sbilanciare i dati con striping. Se si aggiungono altri dischi a una configurazione di archiviazione, è preferibile creare un nuovo volume di archiviazione su nuovi dischi. Copiare quindi il contenuto durante il tempo di inattività e modificare i punti di montaggio. Eliminare infine il gruppo di volumi precedente e i dischi sottostanti.

  • Gruppo di volumi dell'applicazione Azure NetApp Files. Per le distribuzioni con file SAP HANA contenuti nei volumi NFS di Azure NetApp Files, i gruppi di volumi delle applicazioni consentono di distribuire tutti i volumi in base alle procedure consigliate. Questo processo garantisce anche prestazioni ottimali per il database SAP HANA. Sono disponibili informazioni dettagliate su come procedere con questo processo. Richiede un intervento manuale. Attendere del tempo per la creazione.

Disponibilità elevata

L'architettura precedente illustra una distribuzione a disponibilità elevata, con SAP HANA contenuto in due o più macchine virtuali. Vengono usati i componenti seguenti.

Servizi di bilanciamento del carico.Azure Load Balancer viene usato per distribuire il traffico alle macchine virtuali SAP HANA. Quando si incorpora Azure Load Balancer in una distribuzione di zona di SAP, assicurarsi di selezionare il servizio di bilanciamento del carico dello SKU Standard. Il servizio di bilanciamento dello SKU Basic non supporta la ridondanza di zona. In questa architettura Load Balancer funge da indirizzo IP virtuale per SAP HANA. Il traffico di rete viene inviato alla macchina virtuale attiva in cui viene eseguita l'istanza del database primario. L'architettura attiva/in lettura di SAP HANA è disponibile (SLES/RHEL) in cui viene usato un secondo indirizzo IP virtuale nel servizio di bilanciamento del carico per indirizzare il traffico di rete all'istanza secondaria di SAP HANA in altre macchine virtuali per carichi di lavoro con intensa attività di lettura.

Il Load Balancer Standard fornisce un livello di sicurezza per impostazione predefinita. Le macchine virtuali che si trovano dietro il Load Balancer Standard non hanno connettività Internet in uscita. Per abilitare Internet in uscita in queste macchine virtuali, è necessario aggiornare la configurazione Load Balancer Standard. È anche possibile usare un gateway NAT di Azure per ottenere la connettività in uscita.

Per i cluster di database SAP HANA, è necessario abilitare Direct Server Return (DSR), noto anche come INDIRIZZO IP mobile. Questa funzionalità consente al server di rispondere all'indirizzo IP del front-end del servizio di bilanciamento del carico. Questa connessione diretta impedisce al servizio di bilanciamento del carico di diventare il collo di bottiglia nel percorso della trasmissione dei dati.

Opzioni di distribuzione. In Azure, la distribuzione del carico di lavoro SAP può essere a livello di area o di zona, a seconda dei requisiti di disponibilità e resilienza delle applicazioni SAP. Azure offre diverse opzioni di distribuzione, ad esempio set di scalabilità di macchine virtuali con orchestrazione flessibile (FD=1), zone di disponibilità e set di disponibilità, per migliorare la disponibilità delle risorse. Per comprendere in modo completo le opzioni di distribuzione disponibili e la relativa applicabilità in aree di Azure diverse (incluse le zone, all'interno di una singola zona o in un'area senza zone), vedere Architettura e scenari a disponibilità elevata per SAP NetWeaver.

SAP HANA. Per la disponibilità elevata, SAP HANA viene eseguito in due o più macchine virtuali Linux. La replica di sistema SAP HANA (HSR) viene usata per replicare i dati tra i sistemi SAP HANA primario e secondario (replica). HSR viene usato anche per il ripristino di emergenza tra aree o tra zone. A seconda della latenza nella comunicazione tra le macchine virtuali, la replica sincrona può essere usata all'interno di un'area. HSR tra aree per il ripristino di emergenza verrà eseguito nella maggior parte dei casi in modo asincrono.

Per il cluster Linux Pacemaker, è necessario decidere quale meccanismo di isolamento del cluster usare. L'isolamento del cluster è il processo di isolamento di una macchina virtuale non riuscita dal cluster e del riavvio. Per RedHat Enterprise Linux (RHEL), l'unico meccanismo di isolamento supportato per Pacemaker in Azure è l'agente di isolamento di Azure. Per SU edizione Standard Linux Enterprise Server (SLES), è possibile usare l'agente di isolamento di Azure o STONITH Block Device (SBD). Confrontare i tempi di failover per ogni soluzione e, se esiste una differenza, scegliere una soluzione in base ai requisiti aziendali per l'obiettivo del tempo di ripristino (RTO).

Agente di isolamento di Azure. Questo metodo di isolamento si basa sull'API arm di Azure, con Pacemaker che esegue query sull'API ARM sullo stato di entrambe le macchine virtuali SAP HANA nel cluster. In caso di errore di una macchina virtuale, ad esempio l'arresto anomalo del sistema operativo o l'arresto anomalo della macchina virtuale, gestione cluster usa nuovamente l'API ARM per riavviare la macchina virtuale e, se necessario, non riesce il database SAP HANA all'altro nodo attivo. A questo scopo, un'entità nome servizio (SPN) con un ruolo personalizzato per eseguire query e riavviare le macchine virtuali viene usata per autorizzare l'API arm. Non sono necessarie altre infrastrutture, le macchine virtuali SBD nei disegni dell'architettura non vengono distribuite nel caso in cui venga usato l'agente di isolamento di Azure.

SBD. STONITH Block Device (SBD) usa un disco a cui si accede come dispositivo in blocchi (non elaborato, senza file system) da gestione cluster. Questo disco, o disco se multiplo, funge da voto. Ognuno dei due nodi del cluster che eseguono SAP HANA accede periodicamente ai dischi SDB e alle operazioni di lettura/scrittura in bit piccoli di informazioni sullo stato. Di conseguenza, ogni nodo del cluster conosce lo stato dell'altro senza dipendere solo dalla rete tra le macchine virtuali.

Preferibilmente tre macchine virtuali di piccole dimensioni vengono distribuite in un set di disponibilità o in una configurazione della zona di disponibilità. Ogni macchina virtuale che esporta piccole parti di un disco come dispositivo a blocchi a cui accedono i due nodi del cluster SAP HANA. Tre macchine virtuali SBD assicurano che siano disponibili membri di voto sufficienti in caso di tempi di inattività pianificati o non pianificati per una macchina virtuale SBD.

In alternativa all'uso di macchine virtuali SBD, è possibile usare il disco condiviso di Azure. I nodi del cluster SAP HANA accedono quindi al singolo disco condiviso. Il disco condiviso può essere con ridondanza locale (LRS) o zonally (ZRS), se l'archiviazione con ridondanza della zona è disponibile nell'area di Azure.

Ripristino di emergenza

L'architettura seguente illustra un ambiente HANA di produzione in Azure che fornisce il ripristino di emergenza. L'architettura incorpora le zone di disponibilità.

Diagramma che mostra un'architettura con il ripristino di emergenza.

Per informazioni dettagliate sulle strategie di ripristino di emergenza e sull'implementazione, vedere Panoramica del ripristino di emergenza e linee guida sull'infrastruttura per il carico di lavoro SAP e le linee guida per il ripristino di emergenza per l'applicazione SAP.

Nota

Se si verifica un'emergenza a livello di area che causa un evento di failover di grandi dimensioni per molti clienti di Azure in un'area, la capacità delle risorse dell'area di destinazione non è garantita. Analogamente a tutti i servizi di Azure, Azure Site Recovery continua ad aggiungere funzionalità e funzionalità. Per le informazioni più recenti sulla replica da Azure ad Azure, vedere la matrice di supporto.

Oltre a un'implementazione locale a disponibilità elevata a due nodi, HSR supporta la replica multilime e multitarget . HSR supporta quindi la replica tra zone e inter-area. La replica multitarget è disponibile per SAP HANA 2.0 SPS 03 e versioni successive.

Assicurarsi di verificare la capacità delle risorse dell'area di destinazione.

Azure NetApp Files. Come opzione, Azure NetApp Files può essere usato per offrire una soluzione di archiviazione scalabile e ad alte prestazioni per i file di dati e di log DI SAP HANA. Azure NetApp Files supporta gli snapshot per il backup rapido, il ripristino e la replica locale. Per la replica del contenuto tra aree, è possibile usare la replica tra più aree di Azure NetApp Files per replicare i dati dello snapshot tra due aree. Sono disponibili informazioni dettagliate sulla replica tra aree e un white paper che descrive tutti gli aspetti per il ripristino di emergenza con Azure NetApp Files.

Backup

È possibile eseguire il backup dei dati SAP HANA in molti modi. Dopo la migrazione ad Azure, è possibile continuare a usare tutte le soluzioni di backup dei partner esistenti già disponibili. Azure offre due approcci nativi: backup a livello di file SAP HANA e Backup di Azure per SAP HANA tramite l'interfaccia Backint.

Per il backup a livello di file di SAP HANA, è possibile usare lo strumento preferito, ad esempio hdbsql o SAP HANA Studio, e archiviare i file di backup in un volume del disco locale. Un punto di montaggio comune per questo volume di backup è /hana/backup. I criteri di backup definiranno il periodo di conservazione dei dati nel volume. Non appena viene eseguito il backup, un'attività pianificata deve copiare i file di backup nell'archivio BLOB di Azure per garantire la sicurezza. I file di backup locali vengono conservati per il ripristino rapido.

Backup di Azure offre una soluzione semplice di livello aziendale per i carichi di lavoro in esecuzione nelle macchine virtuali. Backup di Azure per SAP HANA offre l'integrazione completa con il catalogo di backup di SAP HANA e garantisce ripristini temporizzato, completi o coerenti con il database. Backup di Azure è BackInt certificato da SAP. Vedere anche la matrice di domande frequenti e supporto Backup di Azure.

Azure NetApp Files offre il supporto per i backup basati su snapshot. L'integrazione con SAP HANA per gli snapshot coerenti con l'applicazione avviene tramite lo strumento snapshot coerente app Azure cation (AzAcSnap). Gli snapshot creati possono essere usati per il ripristino in un nuovo volume per il ripristino di sistema o la copia del database SAP HANA. Gli snapshot creati possono essere usati per il ripristino di emergenza, in cui funge da punto di ripristino con i log di SAP HANA salvati in un volume NFS diverso.

Monitoraggio

Per monitorare i carichi di lavoro in Azure, Monitoraggio di Azure consente di raccogliere, analizzare e agire in modo completo sui dati di telemetria dagli ambienti cloud e locali.

Per le applicazioni SAP eseguite in SAP HANA e altre soluzioni di database principali, vedere Monitoraggio di Azure per soluzioni SAP per informazioni su come Monitoraggio di Azure per SAP può aiutare a gestire la disponibilità e le prestazioni dei servizi SAP.

Sicurezza

Molte misure di sicurezza vengono usate per proteggere la riservatezza, l'integrità e la disponibilità di un panorama SAP. Per proteggere l'accesso degli utenti, ad esempio, SAP ha il proprio motore di gestione utenti (UME) per controllare l'accesso e l'autorizzazione in base al ruolo all'interno dell'applicazione e dei database SAP. Per altre informazioni, vedere Sicurezza di SAP HANA - Panoramica.

Per i dati inattivi, le diverse funzionalità di crittografia offrono la sicurezza come indicato di seguito:

  • Oltre alla tecnologia di crittografia nativa SAP HANA, prendere in considerazione l'uso di una soluzione di crittografia di un partner che supporta le chiavi gestite dal cliente.

  • Per crittografare i dischi delle macchine virtuali, è possibile usare le funzionalità descritte in Panoramica di Crittografia dischi.

  • Server di database SAP: usare Transparent Data Encryption offerto dal provider DBMS (ad esempio, la tecnologia di crittografia nativa SAP HANA) per proteggere i file di dati e di log e per garantire che i backup siano crittografati.

  • I dati nell'archiviazione fisica di Azure (Crittografia lato server) vengono crittografati automaticamente inattivi con una chiave gestita di Azure. È anche possibile scegliere una chiave gestita dal cliente (CMK) anziché la chiave gestita di Azure.

  • Per informazioni sul supporto di Crittografia dischi di Azure in distribuzioni, versioni e immagini linux specifiche, vedere Crittografia dischi di Azure per le macchine virtuali Linux.

Nota

Non combinare la tecnologia di crittografia nativa di SAP HANA con Crittografia dischi di Azure o crittografia basata su host nello stesso volume di archiviazione. Inoltre, i dischi di avvio del sistema operativo per le macchine virtuali Linux non supportano Crittografia dischi di Azure. Al contrario, quando si usa la crittografia nativa SAP HANA, combinarla con la crittografia lato server, che viene abilitata automaticamente. Tenere presente che l'utilizzo delle chiavi gestite dal cliente potrebbe influire sulla velocità effettiva di archiviazione.

Per la sicurezza di rete, usare gruppi di sicurezza di rete (NSG) e Firewall di Azure o un'appliance virtuale di rete come indicato di seguito:

  • Usare gruppi di sicurezza di rete per proteggere e controllare il traffico tra subnet e livelli di applicazione/database. Applicare solo gruppi di sicurezza di rete alle subnet. I gruppi di sicurezza di rete applicati sia alla scheda di interfaccia di rete che alla subnet spesso comportano problemi durante la risoluzione dei problemi e devono essere usati raramente se mai.

  • Usare Firewall di Azure o appliance virtuale di rete di Azure per controllare e controllare il routing del traffico dalla rete virtuale hub alla rete virtuale spoke in cui si trovano le applicazioni SAP e controllare anche la connettività Internet in uscita.

Per Utente e autorizzazione, implementare il controllo degli accessi in base al ruolo e i blocchi delle risorse come indicato di seguito:

  • Seguire il principio dei privilegi minimi, usando il controllo degli accessi in base al ruolo per assegnare privilegi amministrativi alle risorse A livello IaaS che ospitano la soluzione SAP in Azure. Lo scopo fondamentale del controllo degli accessi in base al ruolo è la separazione e il controllo dei compiti per gli utenti/gruppi. Il controllo degli accessi in base al ruolo è progettato per concedere solo la quantità di accesso alle risorse necessarie per consentire agli utenti di svolgere il proprio lavoro.

  • Usare i blocchi delle risorse per evitare modifiche accidentali o dannose. I blocchi delle risorse consentono di impedire agli amministratori di eliminare o modificare le risorse di Azure critiche in cui si trova la soluzione SAP.

Altre raccomandazioni sulla sicurezza sono disponibili in questi articoli microsoft e SAP .

Community

Le community possono rispondere alle domande ed essere utili per configurare correttamente la distribuzione. Considerare le community seguenti:

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Altre informazioni sulle tecnologie dei componenti:

Esplorare le architetture correlate: