Architettura di riferimento: SAP S/4HANA su Google Cloud

Questa architettura di riferimento è rivolta a chi sta valutando Google Cloud come piattaforma per il deployment dei carichi di lavoro SAP S/4HANA. Include considerazioni durante la fase di pianificazione, modelli di implementazione e automazione, nonché procedure operative comuni come le attività di backup e RE.

Google Cloud offre costi contenuti, affidabili, sicuri e infrastruttura certificata SAP ad alte prestazioni per l'esecuzione di SAP S/4HANA su SAP HANA. Per un elenco completo delle soluzioni SAP supportate su Google Cloud, vedi SAP su Google Cloud.

Architettura

I seguenti diagrammi mostrano una visione generale di tre modelli di deployment comuni per SAP S/4HANA: centralizzato, distribuito e distribuite con disponibilità elevata.

Deployment centralizzato

In un deployment centralizzato, puoi installare SAP S/4HANA e SAP HANA sulla stessa istanza VM di Compute Engine. Lo consigliamo per ambienti non di produzione come sandbox e sviluppo ambienti cloud-native.

Il seguente diagramma mostra un'architettura di riferimento per SAP S/4HANA su SAP HANA in un deployment centralizzato. Tieni presente che SAP ASCS, PAS, WD e il database SAPHANA sono tutti installati sulla stessa istanza VM.

Diagramma dell'architettura di SAP S/4HANA su Google Cloud in un deployment centralizzato.

Deployment distribuito

In un deployment distribuito, puoi installare i diversi componenti su diverse istanze Compute Engine. Consigliamo questo approccio per gli ambienti di produzione o per quelli che richiedono molta potenza di calcolo per gestire carichi di transazioni elevati.

Il seguente diagramma mostra un'architettura di riferimento per SAP S/4HANA in un deployment distribuito. Tieni presente che SAP ASCS, PAS, WD e HANA sono tutti su istanze VM diverse.

Diagramma dell'architettura di SAP S/4HANA su Google Cloud in un deployment distribuito.

Deployment distribuito con alta disponibilità

In un deployment distribuito con disponibilità elevata, i cluster Linux vengono configurati tra zone diverse per evitare errori dei componenti in una data regione. Puoi esegui il deployment di un cluster Linux in più zone utilizzando una configurazione attiva/passiva o un attivo/attivo configurazione. In entrambi i casi, la prima cosa da fare è configurare due Compute Engine Istanze VM in zone separate per la massima ridondanza, ciascuna con il proprio SAP HANA. Il seguente diagramma mostra un'architettura SAP S/4HANA che utilizza un il cluster Linux per ottenere una disponibilità elevata sia nell'applicazione che in SAP. Lato database HANA:

Diagramma dell'architettura per SAP S/4HANA su Google Cloud in un deployment distribuito ad alta disponibilità. I seguenti diagrammi mostrano un database SAP HANA ad alta disponibilità sia durante il normale funzionamento sia durante un'operazione di takeover:

  • Funzionamento normale:

    Diagramma dell'architettura per l'alta disponibilità di SAP HANA su Google Cloud durante il normale funzionamento.

  • Operazione di takeover:

    Diagramma dell'architettura dell'alta disponibilità di SAP HANA su Google Cloud durante l'operazione di takeover.

Per combinare l'alta disponibilità e il ripristino di emergenza per il database, può utilizzare la replica di sistema SAP HANA. Il seguente diagramma mostra una combinazione di entrambi per ottenere la massima disponibilità e tolleranza di errore:

Diagramma di architettura di alto livello per SAP S/4HANA su Google Cloud con alta disponibilità e ripristino di emergenza.

Il cluster che gestisce l'alta disponibilità include le seguenti funzioni e funzionalità:

  • Due VM host, ciascuna con un'istanza di SAP HANA.
  • Replica del sistema SAP HANA sincrona.
  • Gestore delle risorse del cluster ad alta disponibilità Pacemaker.
  • Un meccanismo di isolamento che isola il nodo in cui si è verificato l'errore.
  • Riavvio automatico dell'istanza non riuscita come nuova istanza secondaria di Google.

L'architettura lato applicazione è simile. In questo caso, il cluster gestisce i servizi centrali ABAP SAP (ASCS) e il server di replica di coda o il replicatore di coda (ERS) utilizzati per fornire al sistema SAP S/4HANA una disponibilità elevata nel caso in cui si verifichi un problema con una delle istanze ASCS e ERS.

In base la versione SAP S/4HANA che utilizzi, vengono eseguiti il server di accodamento e il server di replica di accodamento / Replicatore di coda su un'altra versione:

  • S/4HANA 1709 e versioni precedenti: ENSA1 ed ERS.
  • S/4HANA 1809 o successive: ENSA2 ed ERS2.

Il seguente diagramma mostra un sistema SAP S/4HANA che utilizza un cluster Pacemaker per limitare i singoli punti di errore sia del Message Server sia dell'Enqueue Server:

Diagramma dell'architettura di SAP NetWeaver, con un database, in un deployment ad alta disponibilità su Google Cloud.

Dettagli sul deployment del sistema ad alta disponibilità e di Linux il clustering in più zone, verrà trattato più avanti in questo documento.

Una nota sul bilanciamento del carico

In un ambiente SAP S/4HANA distribuito, il bilanciamento del carico è obbligatorio. Puoi configurare il carico dell'applicazione utilizzando una combinazione di livelli di applicazione SAP Bilanciatori del carico di rete. Per ulteriori informazioni, consulta la sezione Implementazioni VIP del bilanciatore del carico di rete passthrough interno della guida alla pianificazione dell'alta disponibilità per SAP NetWeaver su Google Cloud.

Componenti del deployment

SAP S/4HANA è costituito dai seguenti componenti tecnici:

  • Database SAP HANA
  • ASCS: servizi centrali SAP ABAP
    • Contiene il server dei messaggi e il server di accodamento, richiesti in in qualsiasi sistema SAP ABAP.
    • Distribuito sulla propria istanza VM in deployment ad alta disponibilità oppure sull'istanza VM che ospita il PAS.
    • Nei deployment ad alta disponibilità, le risorse ASCS sono gestite da un cluster Linux come Pacemaker.
  • ERS: server di replica di accodamento o replicatore di accodamento
    • Distribuito in deployment ad alta disponibilità per mantenere una replica della tabella di blocco in caso succede qualcosa all'istanza ASCS.
    • Gestito da un gestore di risorse del cluster Linux, come Pacemaker.
  • PAS: server applicazione principale
    • Il primo o l'unico server di applicazioni per il sistema SAP.
  • AAS: Additional Application Server
    • Di solito viene implementato per il bilanciamento del carico a livello di applicazione. Puoi installare più istanze AAS per ottenere una maggiore disponibilità anche dal punto di vista del livello di applicazione. Se uno dei server delle applicazioni non funziona, tutti le sessioni utente connesse al server delle applicazioni vengono terminate, possono accedere nuovamente all'altro AAS nell'ambiente.
  • Gateway SAP NetWeaver
    • Eseguito il deployment come sistema autonomo o come parte del sistema SAP S/4HANA.
    • Consente al sistema di connettere dispositivi, ambienti e piattaforme a Sistemi SAP che utilizzano Open Data Protocol (OData).
  • Server front-end SAP Fiori
    • Eseguito il deployment come sistema autonomo o come parte del sistema SAP S/4HANA.
    • Il sistema SAP Netweaver ABAP viene utilizzato per ospitare le applicazioni SAP Fiori.
  • WD: Web Dispatcher (facoltativo)
    • Bilanciatore del carico software intelligente che distribuisce le richieste HTTP e HTTPS, in base al tipo di applicazione, a PAS e AAS.

I seguenti servizi Google Cloud vengono utilizzati nel deployment di SAP S/4HANA:

Servizio Descrizione
Networking VPC

Connette le istanze VM tra loro e a internet.

Ogni istanza VM fa parte di una rete legacy con un un intervallo IP globale o una rete di subnet consigliata, in cui l'istanza VM un membro di una singola subnet che fa parte di una rete più grande.

Tieni presente che una rete Virtual Private Cloud (VPC) non può essere distribuita su più progetti Google Cloud, ma un progetto Google Cloud può avere più reti VPC.

Per connettere risorse di più progetti a una rete VPC comune, puoi utilizzare la VPC condivisa, in modo che le risorse possano comunicare tra loro in modo sicuro ed efficiente utilizzando gli indirizzi IP interni di quella rete. Per informazioni su come per eseguire il provisioning di un VPC condiviso, inclusi requisiti, configurazione passaggi e utilizzo, vedi Esegui il provisioning di un VPC condiviso.

Compute Engine Crea e gestisce le VM con il sistema operativo e il software che preferisci stack.
Persistent Disk e Hyperdisk

Puoi utilizzare Persistent Disk e Google Cloud Hyperdisk:

  • I volumi su disco permanente sono disponibili come unità disco rigido standard (HDD) o unità a stato solido (SSD). Per i dischi permanenti bilanciati e i dischi permanenti SSD, Replica asincrona del disco permanente fornisce la replica asincrona dei dati SAP tra due regioni Google Cloud.
  • I volumi Hyperdisk Extreme offrono opzioni di IOPS e throughput massimi superiori rispetto ai volumi dei dischi permanenti SSD.
  • Per impostazione predefinita, Compute Engine cripta i contenuti at-rest dei clienti, inclusi i contenuti all'interno dei volumi di dischi permanenti e Hyperdisk. Per ulteriori informazioni sulla crittografia del disco e sulle possibili opzioni di crittografia, consulta Informazioni sulla crittografia del disco.
Console Google Cloud

Uno strumento basato su browser per la gestione delle risorse Compute Engine.

Utilizza un modello per descrivere tutte le risorse Compute Engine e le istanze di cui hai bisogno. Non devi creare e configurare singolarmente le risorse o capire le dipendenze perché la console Google Cloud lo fa per te.
Cloud Storage Puoi archiviare i backup del database SAP in Cloud Storage per una maggiore durabilità e affidabilità, con la replica.
Cloud Monitoring

Offre visibilità su deployment, prestazioni, uptime e l'integrità dei dischi di Compute Engine, della rete e dell'archiviazione permanente.

Monitoring raccoglie metriche, eventi e metadati da Google Cloud e li utilizza per generare approfondimenti tramite dashboard, grafici e avvisi. Puoi monitorare le metriche di computing senza costi tramite Monitoraggio.
IAM

Fornisce un controllo unificato sulle autorizzazioni per le risorse Google Cloud.

IAM consente di controllare chi può eseguire il piano di controllo operazioni sulle tue VM, tra cui creazione, modifica ed eliminazione VM e dischi di archiviazione permanente e creazione e modifica delle reti.
Filestore

Archiviazione di file NFS completamente gestita ad alte prestazioni da Google Cloud.

Per i deployment multizonali ad alta disponibilità, ti consigliamo di utilizzare Filestore Enterprise con uno SLA (accordo sul livello del servizio) con disponibilità del 99,99%. Per informazioni sui livelli di servizio Filestore, consulta Livelli di servizio.
NetApp Cloud Volumes ONTAP

Una soluzione di archiviazione intelligente completa che puoi eseguire il deployment e gestire autonomamente su un'istanza VM Compute Engine.

Per ulteriori informazioni su NetApp Cloud Volumes ONTAP, consulta Panoramica di Cloud Volumes ONTAP.
Google Cloud NetApp Volumes

Una soluzione di archiviazione file NFS e SMB completamente gestita di Google Cloud, basata su NetApp Cloud Volumes ONTAP.

A seconda della regione, possono essere disponibili più livelli di servizio tra cui scegliere. Per ulteriori informazioni, vedi Servizio .

Note sul layout

Questa sezione fornisce indicazioni per aiutarti a utilizzare questa architettura di riferimento per: per sviluppare un'architettura che soddisfi i requisiti specifici della sicurezza, l'affidabilità, l'efficienza operativa, i costi e le prestazioni.

Networking

Esistono diversi modi per eseguire il deployment di un sistema SAP S/4HANA dal dal punto di vista del networking e il modo in cui esegui il deployment della rete ha un impatto significativo sulla sua disponibilità, resilienza e prestazioni. Come detto in precedenza, Il Virtual Private Cloud (VPC) è una rete privata sicura e isolata, ospitata all'interno in Google Cloud. I VPC sono globali in Google Cloud, quindi un singolo VPC può includere più regioni senza comunicare tramite internet.

Un tipico deployment SAP posiziona le istanze dei sistemi ad alta disponibilità in diverse zone nella stessa regione per garantire la resilienza e al contempo una bassa latenza. Le subnet possono in più zone grazie alle funzionalità di Google Cloud. Queste funzionalità semplificano anche il clustering SAP perché l'indirizzo IP virtuale (VIP) del cluster può essere nello stesso intervallo delle istanze dei sistemi HA. Questa configurazione protegge l'IP flottante utilizzando un bilanciatore del carico delle applicazioni interno ed è applicabile al clustering HA del livello di applicazione (ASCS ed ERS) e al livello del database SAP HANA (SAP HANA principale e secondario).

Esistono diversi modi per creare la tua rete e connettere la tua rete SAP S/4HANA con la tua infrastruttura:

  • Il peering di rete VPC connette due VPC in modo che le risorse in ogni rete possano comunicare tra loro. Le reti VPC possono essere ospitate nello stesso progetto Google Cloud, in progetti diversi della stessa organizzazione o anche in progetti diversi di organizzazioni diverse. Il peering di rete VPC stabilisce una connessione diretta tra due reti VPC, ciascuna con le proprie sottoreti, consentendo la comunicazione privata tra le risorse nei VPC in peering.

  • La VPC condivisa è una funzionalità di Google Cloud che consente a un'organizzazione di connettere risorse di più progetti a una rete VPC comune. I sistemi che utilizzano un VPC condiviso possono comunicare in modo efficiente e sicuro usando indirizzi IP interni. Puoi gestire centralmente e risorse di rete come subnet, route e firewall in un progetto host, e delega responsabilità amministrative per la creazione e la gestione le singole risorse ai progetti di servizio. Questa separazione dei problemi semplifica l'amministrazione della rete e applica criteri di sicurezza coerenti all'interno dell'organizzazione.

Per i sistemi SAP, in genere è consigliabile raggruppare le risorse in base al tipo di ambiente. Ad esempio, gli ambienti di produzione non devono condividere risorse di calcolo con gli ambienti non di produzione per garantire un isolamento adeguato, ma puoi utilizzare una VPC condivisa per un livello comune di connettività tra i tuoi progetti. Puoi anche utilizzare VPC indipendenti e il peering VPC per collegare i progetti.

Durante la progettazione della rete, inizia con un progetto host contenente una o più reti VPC condivise. Puoi collegare progetti di servizio aggiuntivi a un progetto host, che consente ai progetti di servizio di partecipare VPC condiviso. A seconda delle tue esigenze, puoi eseguire il deployment di SAP S/4HANA in una singola VPC condiviso o più VPC condivisi. I due scenari differiscono in termini di controllo della rete, isolamento dell'ambiente SAP e ispezione della rete:

  • Scenario 1: deployment di SAP S/4HANA in un unico VPC condiviso. Questo semplifica il deployment e riduce i costi amministrativi a scapito a un minore isolamento tra le reti.
  • Scenario 2: deployment di SAP S/4HANA su più VPC condivise. Questo aumenta l'isolamento della rete e aggiunge la sicurezza a scapito dell'aumento della la complessità e l'overhead amministrativo.

È anche possibile utilizzare un approccio ibrido. Ad esempio, puoi utilizzare uno VPC condiviso per l'ambiente di produzione e un VPC condiviso per tutti i sistemi non di produzione. Per ulteriori informazioni, consulta la sezione "Networking" sezione nel Elenco di controllo generale per SAP su Google Cloud.

Single point of failure

Un sistema SAP S/4HANA presenta alcuni single point of failure comuni che possono influire sulla disponibilità del sistema:

  • Servizi centrali SAP come Message Server ed Enqueue Server
  • Server di applicazioni SAP
  • Database SAP HANA
  • SAP Web Dispatcher, se utilizzato come frontend per l'accesso HTTP/HTTPS al sistema
  • Spazio di archiviazione condiviso come NFS

Esistono più opzioni per ridurre l'impatto di questi singoli punti di errori, e queste opzioni prevedono il deployment del sistema ad alta disponibilità, servizi di replica o l'utilizzo di che proteggono il sistema da guasti. Quando pianifichi Sistema SAP S/4HANA ti consigliamo di studiare questi single point of failure e di pianificare di conseguenza. Per una panoramica delle soluzioni alternative che puoi utilizzare per gestire i singoli punti di défaillance, consulta le seguenti sezioni di questa guida:

Disponibilità e continuità

Durante la fase di pianificazione dell'implementazione di un sistema SAP S/4HANA, devi specificare i seguenti punti dati per definire la disponibilità e la continuità del sistema:

  • Obiettivi del livello di servizio (SLO): un valore target o un intervallo di valori per un che viene misurato mediante un indicatore del livello del servizio (SLI). Per ad esempio prestazioni, disponibilità e affidabilità.
  • Indicatori del livello del servizio (SLI): metriche, come la latenza, che consentono di a misurare le prestazioni di un servizio. È una misura quantitativa accuratamente definita relativa ad alcuni aspetti del livello del servizio fornito.
  • Accordo sul livello del servizio (SLA): un contratto di servizio tra due parti. (fornitore, cliente) che definisce un accordo sul servizio fornito termini misurabili chiamati obiettivi del livello di servizio (SLO).
  • RTO (Recovery Time Objective): la durata massima tollerabile tra un incidente di perdita di dati e la sua mitigazione.
  • Recovery Point Objective (RPO): il Recovery Point Objective (RPO) è la quantità massima di dati che può essere persa, misurata in tempo, senza causare danni significativi. In pratica, si tratta del punto nel tempo in cui lo stato dei dati interessati deve essere recuperato a seguito di un evento di perdita di dati.

A seconda dei punti dati e dei valori concordati tra tutti gli stakeholder, il sistema SAP S/4HANA si basa su funzionalità come l'alta disponibilità o ripristino di emergenza:

  • Disponibilità elevata (HA): la capacità di un sistema che supporta lo scopo della continuità aziendale garantendo al contempo la disponibilità di dati e servizi per gli utenti in caso di necessità. Il modo consueto per ottenere questa funzionalità è attivare la ridondanza, inclusa la ridondanza hardware, la ridondanza di rete e la ridondanza del data center.
  • Ripristino di emergenza (RE): la capacità di un sistema da proteggere di interruzioni non pianificate tramite metodi di ripristino affidabili e prevedibili hardware e/o luoghi fisici diversi.

L'alta disponibilità e il ripristino di emergenza sono compatibili, ma coprono casi e situazioni diverse. Ad esempio, una soluzione HA ti consente di continuare le tue operazioni se uno degli elementi del sistema presenta un tempo di riposo o un'interruzione imprevista senza causare interruzioni per gli utenti. Lo stesso può a proposito di una soluzione RE, con l'eccezione del fatto che dal momento dell'interruzione fino a quando la soluzione RE avvia la configurazione difettosa elementi del sistema in una posizione diversa.

Le sezioni seguenti forniscono una panoramica delle diverse opzioni a tua disposizione per pianificare e implementare il sistema SAP S/4HANA su Google Cloud.

Tipi di macchine supportati per SAP S/4HANA

Google Cloud offre tipi di istanze VM Compute Engine certificati da SAP per soddisfare i requisiti di dimensionamento durante il deployment di SAP S/4HANA. Per ulteriori informazioni sulla definizione delle dimensioni su Google Cloud e sui tipi di macchine supportati, consulta i seguenti documenti:

Anche i tipi di macchine personalizzate per SAP HANA su Google Cloud sono certificati da SAP. Puoi eseguire istanze SAP HANA con meno di 64 vCPU purché mantieni un rapporto vCPU/memoria di almeno 1:6,5.

Per visualizzare i numeri SAPS delle macchine virtuali Compute Engine certificate per le applicazioni SAP, consulta la nota SAP Nota SAP 2456432 - Applicazioni SAP su Google Cloud: prodotti supportati e tipi di macchine Google Cloud .

SAP fornisce un elenco certificato di configurazioni di Google Cloud per SAP HANA sul suo sito web. Per ulteriori informazioni, consulta la Directory dell'hardware SAP HANA certificato e supportato.

Pianificare regioni e zone

Quando esegui il deployment di una VM, devi scegliere una regione e una zona. Una regione è una località geografica specifica in cui puoi eseguire le tue risorse e corrisponde a una o più sedi di data center relativamente vicine tra loro. Ogni regione è composta da una o più zone con connettività, alimentazione e raffreddamento ridondanti.

Le risorse globali, come le immagini e gli snapshot dei dischi preconfigurati, possono essere accesse in regioni e zone diverse. Risorse regionali, ad esempio i feed statici a livello di regione indirizzi IP esterni, sono accessibili solo alle risorse che si trovano nella stessa regione. Le risorse di zona, come VM e dischi, sono accessibili solo di risorse che si trovano nella stessa zona. Per ulteriori informazioni, vedi Risorse globali, regionali e di zona.

regioni e zone di Google Cloud.

Quando scegli una regione e una zona per le tue VM, tieni presente quanto segue:

  • La posizione degli utenti e delle risorse interne, ad esempio il data center o la rete aziendale. Per ridurre la latenza, seleziona una località che si trova in vicinanza di utenti e risorse.
  • Le piattaforme CPU disponibili per quella regione e zona. Ad esempio, i processori Broadwell, Haswell, Skylake e Ice Lake di Intel sono supportati per i carichi di lavoro di SAP NetWeaver su Google Cloud.
  • Assicurati che il server di applicazioni SAP e il database si trovino nella stessa regione.

Opzioni di archiviazione per SAP S/4HANA

Di seguito sono riportate le opzioni di archiviazione offerte da Google Cloud, certificati da SAP per l'utilizzo con SAP S/4HANA e SAP HANA.

Per informazioni generali sulle opzioni di archiviazione in Google Cloud, consulta Opzioni di archiviazione.

Persistent Disk

  • Disco permanente standard (pd-standard): archiviazione a blocchi efficiente ed economica supportata da unità disco rigido (HDD) standard per la gestione di operazioni di lettura/scrittura sequenziali, ma non ottimizzata per gestire elevati tassi di operazioni di input/output casuali al secondo (IOPS).
  • Disco permanente SSD (pd-ssd): fornisce blocchi affidabili e ad alte prestazioni di archiviazione supportato unità a stato solido (SSD).
  • Disco permanente bilanciato (pd-balanced): fornisce archiviazione a blocchi basata su SSD affidabile e conveniente.
  • Disco permanente estremo (pd-extreme): basato su SSD; offre opzioni di IOPS e throughput massimi superiori rispetto a pd-ssd per i tipi di macchine Compute Engine più grandi. Per ulteriori informazioni, consulta Dischi permanenti Extreme.

Hyperdisk

  • Hyperdisk Extreme (hyperdisk-extreme): offre opzioni di IOPS e throughput massimi superiori rispetto ai volumi di dischi permanenti basati su SSD. Puoi selezionare le prestazioni necessarie eseguendo il provisioning delle IOPS, che determina e la velocità effettiva effettiva. Il suo utilizzo migliore è per ospitare le directory /hana/data e /hana/log. Per ulteriori informazioni, vedi Informazioni su Google Cloud Hyperdisk.

  • Hyperdisk bilanciato (hyperdisk-balanced): la soluzione migliore per la maggior parte dei carichi di lavoro. Consigliamo di utilizzare questa opzione con database che non richiedono le prestazioni di Hyperdisk Extreme. Seleziona le prestazioni di cui hai bisogno eseguendo il provisioning di IOPS e throughput. Puoi utilizzare la modalità Volumi bilanciati Hyperdisk per ospitare /hana/data e /hana/log directory. Per ulteriori informazioni, consulta Informazioni su Hyperdisk di Google Cloud.

I dischi permanenti e Hyperdisk sono progettati per garantire un'elevata durabilità. I dati vengono archiviati in maniera ridondante per assicurarne l'integrità. Ogni volume del disco permanente può memorizzare fino a 64 TB, quindi puoi creare volumi logici di grandi dimensioni senza gestire array di dischi. I volumi Hyperdisk consentono inoltre fino a 64 TB di spazio di archiviazione, a seconda del tipo utilizzato. Una funzionalità chiave è che i volumi di dischi permanenti e Hyperdisk vengono criptati automaticamente per proteggere i dati.

Al momento della creazione, un'istanza VM di Compute Engine alloca una singola radice Persistent Disk o Hyperdisk per impostazione predefinita che contiene un intero sistema operativo. Puoi aggiungere altre opzioni di archiviazione all'istanza VM obbligatorio.

Per le implementazioni SAP, consulta le opzioni di archiviazione consigliate nella struttura della directory SAP e le opzioni di archiviazione.

Soluzioni di condivisione di file

Su Google Cloud sono disponibili diverse soluzioni di condivisione dei file, tra cui:

  • Filestore: archiviazione di file NFS completamente gestita e ad alte prestazioni di Google Cloud con disponibilità a livello di regione.
  • Google Cloud NetApp Volumes: una soluzione di archiviazione file NFS o SMB completamente gestita di Google Cloud.
  • NetApp Cloud Volumes ONTAP: una soluzione di archiviazione intelligente e completa di cui esegui il deployment e gestirli su una VM di Compute Engine.
  • NetApp Cloud Volumes Service per Google Cloud: una soluzione di archiviazione file completamente gestita e ad alte prestazioni da NetApp di cui puoi eseguire il deployment dalla console Google Cloud.

Per ulteriori informazioni sulle soluzioni di condivisione file per SAP S/4HANA su Google Cloud, consulta Soluzioni di condivisione file per SAP su Google Cloud.

Cloud Storage per l'archiviazione di oggetti

Cloud Storage è un archivio di oggetti per file di qualsiasi tipo o formato; questo elemento dispone di uno spazio di archiviazione praticamente illimitato e non devi preoccuparti del provisioning o l'aggiunta di ulteriore capacità. Un oggetto in Cloud Storage contiene i dati del file e i relativi metadati associati e può avere dimensioni fino a 5 TB. Un bucket Cloud Storage può archiviare un numero qualsiasi di oggetti.

È pratica comune utilizzare Cloud Storage per archiviare i file di backup per qualsiasi scopo. Ad esempio, Cloud Storage è un buon posto per archiviare i backup del database SAP HANA. Per informazioni sulla pianificazione del backup del database, consulta Backup e recupero del database. Puoi anche utilizzare Cloud Storage come parte processo di migrazione.

Inoltre, puoi utilizzare il servizio di backup e RE come soluzione centralizzata per le operazioni di backup e RE. Questo servizio supporta un ampio spettro di database, tra cui SAP HANA. Per saperne di più, consulta Soluzioni di backup e ripristino di emergenza con Google Cloud.

Scegli l'opzione Cloud Storage in base alla frequenza con cui devi eseguire per accedere ai dati. Per gli accessi frequenti, ad esempio più volte al mese, seleziona la classe di archiviazione Standard. Per gli accessi non frequenti, seleziona Nearline o Coldline Storage. Per i dati archiviati a cui non prevedi di accedere, seleziona Archivia dati.

Struttura della directory SAP e opzioni di archiviazione

Le seguenti tabelle descrivono le strutture di directory Linux per SAP HANA e istanze SAP ABAP su Google Cloud.

  • Opzioni di archiviazione consigliate per la struttura di directory Linux su SAP HANA:

    Directory SAP HANA Opzione di archiviazione consigliata in Google Cloud
    /usr/sap Disco permanente bilanciato
    /hana/data Persistent Disk o Hyperdisk basato su SSD
    /hana/log Disco permanente o Hyperdisk basato su SSD
    /hana/shared* Disco permanente bilanciato
    /hanabackup* Disco permanente bilanciato

    Nei deployment distribuiti, /hana/shared e Puoi anche montare /hanabackup come file system di rete utilizzando una soluzione NFS come Filestore.

    Per informazioni sullo spazio di archiviazione su disco permanente certificato da SAP per l'utilizzo con SAP HANA, Archiviazione su disco permanente per SAP HANA.

  • Opzioni di archiviazione consigliate per la struttura di directory Linux su SAP ABAP istanza:

    Directory Opzione di archiviazione consigliata in Google Cloud
    /sapmnt† Disco permanente bilanciato
    /usr/sap Disco permanente bilanciato

    Nei deployment distribuiti, /sapmnt può essere montato anche come file system di rete utilizzando una soluzione NFS come Filestore.

    Per informazioni sullo spazio di archiviazione su disco permanente certificato da SAP per l'utilizzo con le istanze SAP ABAP, Archiviazione su disco permanente per applicazioni SAP.

Supporto dei sistemi operativi per SAP S/4HANA

Quando si sceglie un sistema operativo per SAP NetWeaver su Google Cloud, oltre a confermare che la versione del sistema operativo è certificata da SAP, devi per confermare che tutte e tre le aziende, SAP, il fornitore del sistema operativo e Google Cloud, supporta ancora la versione del sistema operativo.

La decisione deve prendere in considerazione anche i seguenti aspetti:

  • Indica se una determinata versione del sistema operativo è disponibile in Google Cloud. Le immagini del sistema operativo fornite da Compute Engine sono configurate per funzionare con Google Cloud. Se non è disponibile un sistema operativo Google Cloud, puoi utilizzare il modello BYOI (Bring your own device, Porta la tua immagine del sistema operativo) e una licenza. Le immagini del sistema operativo BYOI sono indicate da Compute Engine come immagini personalizzate.
  • Le opzioni di licenza disponibili per una determinata versione del sistema operativo. Verifica se il sistema operativo ha un'opzione di licenza on demand o se devi BYOS (Bring Your Own Subscription) del fornitore del sistema operativo.
  • Indica se le funzionalità di alta disponibilità integrate di una determinata versione del sistema operativo sono abilitate per Google Cloud.
  • L'opzione di sconto per impegno di utilizzo per immagini SLES for SAP e RHEL for SAP.

I seguenti sistemi operativi sono certificati da SAP per l'utilizzo con SAP NetWeaver su Google Cloud:

Puoi trovare ulteriori informazioni su versioni specifiche del sistema operativo e sulla loro compatibilità sia con SAP S/4HANA sia con SAP HANA nelle seguenti guide:

Opzione Fast Restart di SAP HANA

Per SAP HANA 2.0 SP04 e versioni successive, Google consiglia vivamente la classe Opzione di riavvio rapido di SAP HANA.

Questa opzione viene attivata automaticamente quando esegui il deployment di SAP HANA utilizzando i seguenti moduli Terraform forniti da Google Cloud: modulo sap_hana o sap_hana_ha, versione 202309280828 o successiva. Per informazioni su come attivare manualmente il riavvio rapido di SAP HANA, consulta Attivare il riavvio rapido di SAP HANA.

Il riavvio rapido di SAP HANA riduce il tempo di riavvio nel caso in cui SAP HANA si arresti, ma il sistema operativo rimanga in esecuzione. Per ridurre il tempo di riavvio, SAP HANA sfrutta la funzionalità di memoria persistente di SAP HANA per preservare i frammenti di datiMAIN delle tabelle del magazzino delle colonne nella DRAM mappata al file systemtmpfs.

Inoltre, sulle VM delle famiglie M2 e M3 di Compute Engine di macchine ottimizzate per la memoria, il riavvio rapido di SAP HANA migliora i tempi di recupero se e gli errori non correggibili si verificano in memoria. Per ulteriori informazioni, vedi Opzione di riavvio rapido di SAP HANA.

Architettura di deployment per SAP HANA

SAP HANA è un componente fondamentale di qualsiasi sistema SAP S/4HANA perché come database per il sistema. Esistono due possibili architetture da utilizzare per il deployment del database SAP HANA: scale-up e con lo scale out.

Architettura di scalabilità verticale

Il seguente diagramma mostra un'architettura di scalabilità per SAP HANA su Google Cloud. Nel diagramma, noterai che sia il deployment Google Cloud e il layout del disco. Puoi utilizzare Cloud Storage per eseguire il backup dei backup locali disponibili in /hanabackup. Questo supporto deve avere le dimensioni necessarie uguale o superiore al montaggio dei dati.

Diagramma dell'architettura per il deployment di un sistema SAP HANA con scalabilità verticale su Google Cloud.

Architettura di scale out

L'architettura di scalabilità per SAP HANA è composta da un host master, da un numero di host worker e, facoltativamente, da uno o più host di riserva. Gli host sono interconnessi tramite una rete che supporta l'invio di dati tra host a velocità fino a 32 Gbps o fino a 100 Gbps su tipi di macchine selezionate utilizzando la networking ad alta larghezza di banda.

Con l'aumento della domanda di carico di lavoro, in particolare quando si utilizza l'elaborazione analitica online (OLAP), un'architettura di scalabilità in più host può distribuire il carico su tutti gli host.

Il seguente diagramma mostra un'architettura di scalabilità per SAP HANA su Google Cloud:

Diagramma dell'architettura per il deployment di un sistema SAP HANA scalabile su Google Cloud.

Architettura di deployment per SAP S/4HANA

Come accennato nella sezione Architettura, esistono più architetture di deployment che puoi utilizzare per eseguire il deployment di SAP S/4HANA su Google Cloud.

Architettura a due livelli

Questa architettura viene presentata nel deployment centralizzato. Il seguente diagramma mostra alcuni dettagli di un'architettura a due livelli per SAP S/4HANA in esecuzione su una VM Compute Engine:

Architettura a due livelli per SAP S/4HANA su una VM Compute Engine su Google Cloud.

Architettura a tre livelli

Questa architettura viene presentata nel deployment distribuito. Puoi utilizzare questa architettura per eseguire il deployment di sistemi SAP S/4HANA ad alta disponibilità. La il seguente diagramma mostra alcuni dettagli di un'architettura a tre livelli SAP S/4HANA in esecuzione su VM di Compute Engine:

Architettura a tre livelli per SAP S/4HANA su VM Compute Engine su Google Cloud.

In questa architettura, il sistema SAP S/4HANA distribuisce il lavoro tra più server delle applicazioni NetWeaver (AS), ciascuno ospitato su una VM separata. Tutti i nodi NetWeaver AS condividono lo stesso database, che è ospitato su una VM distinta. Tutti i nodi NetWeaver AS montano e accedono a un file system condiviso che ospita i profili SAP NetWeaver. Questo file system condiviso è ospitato su una Volume del Persistent Disk condiviso tra tutti i nodi o su un soluzione di condivisione file.

Sicurezza, privacy e conformità

Questa sezione fornisce informazioni su sicurezza, privacy e conformità per con SAP S/4HANA su Google Cloud.

Conformità e controlli di sovranità

Se vuoi che il tuo carico di lavoro SAP venga eseguito in conformità con i requisiti di residenza dei dati, controllo dell'accesso, personale di assistenza o normativi, devi pianificare l'utilizzo di Assured Workloads, un servizio che ti aiuta a eseguire carichi di lavoro sicuri e conformi su Google Cloud senza compromettere la qualità della tua esperienza cloud. Per ulteriori informazioni, consulta la sezione Controlli di conformità e sovranità per SAP su Google Cloud.

Networking e sicurezza di rete

Prendi in considerazione le informazioni riportate nelle sezioni seguenti quando pianifichi il networking sicurezza di rete.

Modello di privilegio minimo

Una delle prime linee di difesa è limitare chi può raggiungere la tua rete e le tue VM. Per farlo, utilizzi Regole firewall VPC. Per impostazione predefinita, tutto il traffico verso le VM, anche da altre VM, viene bloccato dal firewall, a meno che non crei regole per consentire l'accesso. L'eccezione è la rete predefinita che viene creata automaticamente con ogni progetto e ha regole firewall predefinite.

Creando regole firewall VPC, puoi limitare tutto il traffico su una di porte a specifici indirizzi IP di origine. Per limitare l'accesso al indirizzi IP, protocolli e porte specifici che richiedono l'accesso, devono rispettare le regole minime un modello di privilegio. Ad esempio, imposta sempre bastion host e consenti l'accesso tramite SSH le comunicazioni al tuo sistema SAP NetWeaver solo da quell'host.

Reti personalizzate e regole firewall

Puoi utilizzare una rete per definire un IP gateway e l'intervallo di rete per le VM collegato a quella rete. Tutte le reti Compute Engine utilizzano il protocollo IPv4. Ogni evento Nel progetto Google Cloud è fornita una rete predefinita con configurazioni e regole firewall, ma ti consigliamo di aggiungere una subnet e aggiungi regole firewall basate su modello di privilegio minimo. Per impostazione predefinita, una nuova quando la rete non ha regole firewall e quindi non ha accesso alla rete.

Potresti voler aggiungere più di una subnet per isolare parti di alla tua rete o soddisfare altri requisiti. Per ulteriori informazioni, vedi Reti e subnet.

Le regole firewall si applicano all'intera rete e a tutte le VM al suo interno. Puoi aggiungere una regola firewall che consenta il traffico tra le VM nella stessa rete e tra subnet. Puoi anche configurare i firewall in modo che vengano applicati a VM di destinazione specifiche utilizzando i tag di rete.

SAP richiede l'accesso a determinate porte, quindi aggiungi regole firewall per consentire l'accesso alle porte indicate da SAP.

Route

Le route sono risorse globali collegate a una singola rete. Le route create dall'utente si applicano a tutte le VM di una rete. Ciò significa che puoi aggiungere un percorso che inoltra il traffico da una VM all'altra all'interno della stessa rete e tra le subnet senza richiedere indirizzi IP esterni.

Per l'accesso esterno alle risorse internet, avvia una VM senza IP esterno e configurare un'altra VM come gateway NAT. Questa configurazione richiede di aggiungere il gateway NAT come route per l'istanza SAP.

Host bastioni e gateway NAT

Se i tuoi criteri di sicurezza richiedono VM veramente interne, devi configurare manualmente un proxy NAT sulla tua rete e una route corrispondente in modo che le VM possano raggiungere internet. È importante notare che non puoi connetterti direttamente a un'istanza VM completamente interna utilizzando SSH.

Per connetterti a queste macchine interne, devi configurare un'istanza bastion con un indirizzo IP esterno e poi eseguire il tunnel. Quando le VM non hanno indirizzi IP esterni, possono essere raggiunti solo da altre VM sulla rete oppure attraverso un gateway VPN gestito. Puoi eseguire il provisioning delle VM nella tua rete relè attendibili per le connessioni in entrata, denominati bastion host, o in uscita, chiamati gateway NAT. Per una connettività più trasparente senza impostare per configurare queste connessioni, puoi utilizzare una risorsa gateway VPN gestito.

Bastion host per le connessioni in entrata

Bastion host fornire un punto di ingresso rivolto all'esterno di una rete delle VM con rete privata. Questo padrone di casa può fornire un singolo punto di fortificazione e può essere avviato e arrestato per abilitare o disabilitare l'SSH in entrata la comunicazione da internet.

Visualizzazione del bastion host nello scenario SSH.

L'accesso SSH alle VM che non hanno un indirizzo IP esterno può essere ottenuto che si connette prima a un bastion host. L'applicazione completa di misure di hardening a un host bastione esula dall'ambito di questo documento, ma alcuni passaggi iniziali possono includere:

  • Limita l'intervallo CIDR degli IP di origine che possono comunicare con il bastion.
  • Configura le regole del firewall per consentire il traffico SSH alle VM private solo dal bastion host.

Per impostazione predefinita, SSH sulle VM è configurato in modo da utilizzare chiavi private per l'autenticazione. Quando utilizzi un bastion host, accedi prima al bastion host e poi alla VM privata di destinazione. A causa di questo accesso in due passaggi, ti consigliamo di utilizzare il forwarding dell'agente SSH per raggiungere la VM di destinazione anziché memorizzare la chiave privata della VM di destinazione sull'host bastion. Devi eseguire questa operazione anche se utilizzi lo stesso sia per il bastion che per le VM di destinazione, perché il bastion ha solo alla metà pubblica della coppia di chiavi.

Gateway NAT per il trasferimento di dati in uscita

Quando una VM non ha un indirizzo IP esterno assegnato, non può effettuare collegamenti diretti a servizi esterni, inclusi altri servizi Google Cloud. Per consentire a queste VM di raggiungere i servizi su internet, puoi impostare e configurare un gateway NAT. Il gateway NAT è una VM che può indirizzare il traffico per conto di qualsiasi altra VM sulla rete. Utilizza un gateway NAT per in ogni rete. Un gateway NAT a VM singola non è ad alta disponibilità e non può supportare e la velocità effettiva del traffico per più VM. Per informazioni su come configurare una VM fungere da gateway NAT, consulta la guida al deployment per il tuo sistema operativo:

Cloud VPN

Puoi connettere in sicurezza la tua rete esistente a Google Cloud tramite una connessione VPN che utilizza IPsec utilizzando Cloud VPN. Il traffico tra le due reti viene criptato da un gateway VPN, quindi viene decriptato dall'altro gateway VPN. In questo modo mentre vengono trasferiti su internet. Puoi controllare dinamicamente quali VM possono inviare traffico tramite la VPN utilizzando i tag istanza sulle route. Cloud VPN tunnel sono fatturati a una tariffa mensile statica più addebiti standard per i servizi in uscita trasferimento di dati. Tieni presente che la connessione di due reti nello stesso progetto comporta comunque gli addebiti standard per il trasferimento di dati in uscita. Per ulteriori informazioni, vedi:

Sicurezza per i bucket Cloud Storage

Se utilizzi Cloud Storage per ospitare i backup dei tuoi dati e dei tuoi log, assicurati di utilizzare TLS (HTTPS) durante l'invio di dati a Cloud Storage dalle tue VM per proteggere i dati in transito.

Cloud Storage cripta automaticamente i dati at-rest, specificare le tue chiavi di crittografia, se disponi di sistemi di gestione di un sistema operativo completo.

Limiti per le notifiche via email

Per contribuire a proteggere i tuoi sistemi e quelli di Google da comportamenti illeciti, Google Cloud applica limitazioni per l'invio di email da Compute Engine. Ciò ha implicazioni per la transazione SCOT sui sistemi SAP NetWeaver ABAP perché richiede una configurazione specifica rispetto ai sistemi on-premise.

Per ulteriori informazioni, incluse quelle sulla configurazione di SCOT, consulta: Invio di email da un'istanza.

Per ulteriori informazioni sulle risorse di sicurezza per il tuo ambiente SAP su Google Cloud, consulta quanto segue:

Affidabilità

Questa sezione fornisce informazioni sugli aspetti relativi all'affidabilità con SAP S/4HANA su Google Cloud.

Alta disponibilità e ripristino di emergenza

L'alta disponibilità (HA) e il ripristino di emergenza (RE) sono insiemi di tecniche, e dei principi di progettazione per garantire la continuità aziendale in caso di errori. Questi approcci funzionano eliminando i singoli punti di errore e offrendo la possibilità di riprendere rapidamente le operazioni dopo un'interruzione del sistema o del componente con interruzioni minime dell'attività. Il recupero dai guasti è il processo di ripristino e ripristino delle operazioni dopo un'interruzione a causa di un componente in errore.

Ad esempio, di seguito sono riportati alcuni strumenti di alta disponibilità e RE che puoi utilizzare:

Di seguito sono riportati ulteriori dettagli su alcuni di questi strumenti:

  • Cluster Linux tra zone. Configurazione del cluster Linux su Le zone aiutano a prevenire errori dei componenti in di una determinata regione.

    Nel livello di applicazione SAP NetWeaver, puoi implementare un cluster Linux in più zone per ridurre l'impatto di un errore sull'ASCS e renderlo altamente disponibile su entrambi i nodi in zone diverse. Il cluster Linux viene quindi sposta l'ASCS nel nodo di standby nel caso in cui il nodo primario presenti problemi oppure manutenzione in corso. Inoltre, puoi utilizzare un server di replica di coda per replicare i contenuti della tabella di coda in modo che il server di coda mantenga i contenuti della tabella di coda sul nodo di standby nel caso in cui il processo venga promosso da principale a standby.

    Nel livello di database SAP HANA, puoi eseguire il deployment di un cluster Linux in più zone utilizzando una configurazione attiva/passiva o configurazione. In entrambi i casi, inizia con la configurazione di due istanze Compute Engine in zone separate, ciascuna con il proprio database SAP HANA.

    • Configurazione attiva/passiva: configura un'istanza come nodo principale (attivo) del cluster e l'altra come nodo secondario (passivo). Utilizza la replica del sistema SAP HANA (SR) per configurare il nodo secondario in modo che assuma il ruolo di principale in caso di guasto del nodo principale. Per ulteriori informazioni su come configurare e configurare HANA SR, consulta Replica del sistema HANA.
    • Configurazione attiva/attiva (abilitata alla lettura): configura entrambe le istanze in modo che siano attive, ma il nodo secondario come di sola lettura. Questa configurazione si basa sul recupero continuo dei log. L'IP virtuale (VIP) è configurato in modo da puntare allo nodo di lettura/scrittura attuale. Per ulteriori informazioni, vedi Attivo/Attivo (Lettura abilitata).

    Inoltre, è possibile utilizzare la replica di sistema SAP HANA come disastro soluzione di ripristino. Il database principale replica i suoi contenuti nel database standby, che può essere utilizzato nel caso in cui quello principale non sia disponibile, consentendo al sistema SAP di continuare a funzionare fino al ripristino del servizio nel database principale. In questo caso, la promozione del nodo secondario non avviene automaticamente. questo elemento deve essere eseguita manualmente. Puoi anche combinare HA e RE lato SAP HANA per aumentare la resilienza e la disponibilità. Per ulteriori informazioni, vedi:

  • Migrazione live: Compute Engine offre la migrazione live per mantenere in esecuzione le istanze VM anche quando si verifica un evento del sistema host, ad esempio un aggiornamento hardware o software. In questo caso, Compute Engine esegue una migrazione live della tua istanza in esecuzione a un altro host nella stessa zona, anziché richiedere il riavvio dell'istanza. Il meccanismo replica l'originale quindi, quando viene visualizzata la nuova istanza, ha già memoria dell'istanza originale precaricata.

    Nel raro caso in cui la migrazione live non venga eseguita, l'istanza virtuale viene riavviata automaticamente con il nuovo hardware all'interno della stessa zona. Per ulteriori informazioni, consulta la sezione Procedura di migrazione live durante gli eventi di manutenzione.

Ottimizzazione dei costi

Questa sezione fornisce informazioni su licenze, sconti e stima delle dimensioni del carico di lavoro.

Licenze

Se sei un cliente SAP, puoi utilizzare la tua licenza esistente per eseguire il deployment di SAP S/4HANA su Google Cloud in base a un modello Bring Your Own License (BYOL). Google Cloud supporta il modello BYOL sia per i casi d'uso di produzione sia per quelli non di produzione. Le licenze del sistema operativo sono incluse prezzi di Compute Engine.

In alternativa, puoi utilizzare anche la tua immagine del sistema operativo e le tue licenze. Per maggiori informazioni informazioni, consulta Immagini del sistema operativo personalizzate.

Sconti

Con il modello di prezzi con pagamento a consumo di Google Cloud, paghi solo per i servizi che utilizzi. Non c'è alcun bisogno di impegnarsi per una dimensione particolare service; puoi modificare o interrompere l'utilizzo in base alle tue esigenze. Per i carichi di lavoro prevedibili, Compute Engine fornisce sconti per impegno di utilizzo (CUD) che contribuiscono a ridurre il costo dell'infrastruttura impegnandosi a rispettare un contratto in cambio di prezzi molto scontati per l'utilizzo delle VM.

Google Cloud offre questi sconti in cambio dell'acquisto per impegno di utilizzo. noti anche come commitments. Quando acquisti un impegno, impegnarsi a utilizzare una quantità minima di utilizzo delle risorse o a un importo minimo di spesa per un determinato periodo di uno o tre anni. Questi sconti ti consentono di ridurre la fattura mensile per le risorse utilizzate dal tuo sistema SAP S/4HANA. Per maggiori informazioni, consulta la pagina relativa agli sconti per impegno di utilizzo (CUD).

Stime delle dimensioni

Le seguenti risorse forniscono informazioni su come eseguire stime delle dimensioni per i sistemi SAP prima di eseguirne la migrazione a Google Cloud:

Efficienza operativa

Questa sezione fornisce informazioni su come ottimizzare le risorse efficienza di SAP S/4HANA su Google Cloud.

Backup e ripristino

Crea regolarmente backup del server di applicazioni e del database in modo da poter recuperare i dati in caso di arresto anomalo del sistema, danneggiamento dei dati o qualsiasi altro problema.

Hai a disposizione diverse opzioni per eseguire il backup dei dati SAP HANA su Google Cloud, tra cui:

Backup in Cloud Storage

A partire dalla versione 3.0, l'agente per SAP di Google Cloud supporta la funzionalità Backint, che consente a SAP HANA di eseguire il backup e il recupero dei backup del database direttamente da Cloud Storage. Questa nuova funzionalità è disponibile per le istanze SAP HANA in esecuzione su istanze VM di Compute Engine e su server Bare Metal Solution, on-premise o su altre piattaforme cloud, in modo da poter eseguire il backup e da Cloud Storage, senza la necessità di spazio di archiviazione su disco permanente backup. Per ulteriori informazioni, consulta Guida alle operazioni di SAP HANA.

Per informazioni sulla certificazione SAP di questa funzionalità dell'agente, consulta la nota SAP 2031547 - Panoramica degli strumenti di backup di terze parti certificati SAP e della procedura di assistenza associata.

Il seguente diagramma mostra il flusso dei backup quando utilizzi la funzionalità Backint dell'agente Google Cloud per SAP:

Diagramma che mostra il backup di dati SAP HANA in Cloud Storage mediante l'agente di Google Cloud per SAP.

Eseguire il backup sui dischi

Puoi utilizzare la funzione nativa di backup e ripristino di SAP HANA con per i volumi dei dischi permanenti di Compute Engine e Bucket Cloud Storage per l'archiviazione a lungo termine dei backup.

Durante il normale funzionamento, SAP HANA salva automaticamente i dati dalla memoria sul disco in punti di salvataggio regolari. Inoltre, tutte le modifiche ai dati vengono acquisite in Ripeti log le voci corrispondenti. Una voce del log di ripristino viene scritta sul disco dopo ogni transazione del database confermata.

A partire da SAP HANA 2.0 e versioni successive, utilizza SAP HANA Cockpit per creare i backup di SAP HANA.

Il seguente diagramma mostra il flusso della funzionalità di backup per SAP HANA:

Diagramma che mostra il backup dei dati SAP HANA su un disco di archiviazione permanente.

Eseguire il backup dei dischi utilizzando gli snapshot

Un'altra opzione che puoi aggiungere alla tua strategia di backup è acquisire snapshot di interi dischi utilizzando la funzionalità di snapshot del disco di Compute Engine. Ad esempio, puoi acquisire snapshot pianificati del disco che ospita la tua directory /hanabackup per utilizzarli in scenari di ripristino di emergenza. È anche possibile utilizzare gli snapshot dei dischi per eseguire il backup e Volume di dati SAP HANA. Per garantire la coerenza dell'applicazione, acquisisci snapshot quando non vengono apportate modifiche al volume di destinazione. Gli snapshot si verificano a livello di blocco.

Dopo il primo snapshot, ogni snapshot successivo è incrementale e memorizza solo le modifiche incrementali dei blocchi, come mostrato nel seguente diagramma.

Quando utilizzi la versione 3.0 o successiva dell'agente di Google Cloud per SAP, puoi: Creare backup ed eseguire il ripristino per SAP HANA utilizzando lo snapshot del disco dell'agente funzionalità. Per ulteriori informazioni, consulta Backup e recupero per SAP HANA mediante snapshot dei dischi.

Diagramma che mostra il backup dei dati SAP HANA tramite snapshot dei dischi.

Recupero

Gli strumenti di recupero di SAP HANA possono eseguire il ripristino fino all'ultimo momento o in un momento specifico ed è possibile utilizzare questi strumenti per il ripristino nel nuovo sistema o creare una copia del database. A differenza dei backup, che puoi eseguire mentre il database è operativo, puoi utilizzare gli strumenti di recupero solo quando il database è inattivo. Puoi scegliere un'opzione appropriata tra le seguenti:

  • Ripristina lo stato più recente utilizzando una delle seguenti risorse:
    • Backup completo o snapshot
    • Esegui i backup dei log
    • Ripeti le voci di log ancora disponibili
  • Ripristina un momento passato nel passato.
  • Ripristina un backup completo specificato.

Monitoraggio

Per monitorare e fornire assistenza per i carichi di lavoro SAP in esecuzione su istanze VM Compute Engine e server Bare Metal Solution, Google Cloud fornisce l'Agent for SAP.

Come stabilito da SAP, per ricevere assistenza da SAP e consentire a SAP di rispettare i suoi contratti di livello del servizio (SLA), devi installare l'agente di Google Cloud per SAP su tutte le istanze VM Compute Engine e sui server Bare Metal Solution che eseguono qualsiasi sistema SAP. Per ulteriori informazioni sui prerequisiti per l'assistenza, consulta la nota SAP Nota SAP 2456406 - SAP on Google Cloud Platform: Support Prerequisites .

Oltre alla raccolta obbligatoria delle metriche di SAP Host Agent, su Linux, L'agente Google Cloud per SAP include funzionalità facoltative come la raccolta Metriche di monitoraggio dei processi e valutazione del Gestore carichi di lavoro metriche di valutazione. Puoi attivare queste funzionalità che consentono di utilizzare prodotti e servizi come la gestione dei carichi di lavoro per i tuoi carichi di lavoro SAP.

Ottimizzazione delle prestazioni

Questa sezione fornisce informazioni sull'ottimizzazione del rendimento Carichi di lavoro SAP S/4HANA tramite dimensionamento e configurazione di rete.

Dimensionamento

Sono disponibili diverse opzioni di dimensionamento in base al tipo di implementazione. Per implementazioni greenfield, consigliamo di usare lo strumento SAP Quick Sizer. Per per informazioni dettagliate, vedi SAP Taglie . SAP fornisce anche guide T-shirt per soluzioni e strumenti specifici per la migrazione delle attuali soluzioni on-premise a Google Cloud. Ad esempio, consulta la directory dell'hardware SAP HANA certificato e supportato e la nota SAP Nota SAP 2456432 - Applicazioni SAP su Google Cloud: prodotti supportati e tipi di macchine Google Cloud. SAP e Google Cloud utilizzano unità diverse per misurare le IOPS (operazioni di input/output al secondo). Rivolgiti al tuo partner SI (Systems Integrator) per convertire i requisiti di dimensionamento di SAP in un'infrastruttura Google Cloud di dimensioni adeguate.

Prima di eseguire la migrazione dei sistemi esistenti da SAP ECC a S/4HANA, SAP consiglia di eseguire il report /SDF/HDB_SIZING, come descritto nella nota SAP 1872170 - ABAP on HANA sizing report (S/4HANA, Suite on HANA...). Questo report di dimensionamento analizza le attuali esigenze di memoria e elaborazione del sistema di origine e fornisce informazioni sui requisiti per il passaggio a S/4HANA.

Configurazione di rete

Le funzionalità di rete della VM Compute Engine sono determinate dalla famiglia di macchine e non dall'interfaccia di rete (NIC) o dall'indirizzo IP.

In base al tipo di macchina, l'istanza VM è in grado di supportare un throughput di rete da 2 a 32 Gbps. Alcuni tipi di macchine supportano anche throughput fino a 100 Gbps, il che richiede l'utilizzo del tipo di interfaccia gVNIC (Google Virtual NIC) con una configurazione di rete Tier_1. La possibilità di raggiungere queste velocità in termini di throughput dipende inoltre dalla direzione del traffico e dal tipo di indirizzo IP di destinazione.

Le interfacce di rete delle VM Compute Engine sono supportate da un'infrastruttura di rete ridondante e resiliente che utilizza componenti di rete fisici e software-defined. Queste interfacce ereditano la ridondanza e la resilienza la piattaforma sottostante. È possibile usare più NIC virtuali per la separazione del traffico, ma ciò non offre ulteriori vantaggi in termini di resilienza o prestazioni.

Un singolo NIC fornisce le prestazioni necessarie Deployment SAP HANA on in Compute Engine. Il tuo caso d'uso specifico, i requisiti di sicurezza o le tue preferenze potrebbero richiedere anche interfacce aggiuntive per separare il traffico, ad esempio il traffico internet, il traffico interno della replica del sistema SAP HANA o altri flussi che potrebbero trarre vantaggio da regole specifiche dei criteri di rete. Ti consigliamo di utilizzare la crittografia del traffico offerta dall'applicazione e di proteggere l'accesso alla rete seguendo un criterio di firewall con privilegi minimi per limitare l'accesso.

Considera la necessità di separare il traffico fin dalle prime fasi nella progettazione della rete, e allocano NIC aggiuntive quando esegui il deployment delle VM. Devi collegare ogni interfaccia di rete a una rete VPC diversa. La scelta del numero di interfacce di rete dipende dal livello di isolamento richiesto, con un massimo di 8 interfacce consentite per le VM con almeno 8 vCPU.

Ad esempio, puoi definire una rete VPC per i client di applicazioni SAP HANA SQL, come i server delle applicazioni SAP NetWeaver e le applicazioni personalizzate, e una rete VPC separata per il traffico tra server, come la replica di sistema SAP HANA. Tieni presente che troppi segmenti potrebbero complicare la gestione e la risoluzione dei problemi di rete. Se modifichi in un secondo momento, puoi utilizzare Compute Engine immagini macchina per ricreare l'istanza VM conservando al contempo la configurazione, i metadati e i dati associati.

Per ulteriori informazioni, vedi:

Deployment

Questa sezione fornisce informazioni relative al deployment di SAP S/4HANA su Google Cloud.

Note importanti su SAP pre-deployment

Prima di iniziare a eseguire il deployment di un sistema SAP S/4HANA su Google Cloud, leggi le seguenti note su SAP. Inoltre, prima di iniziare un'implementazione SAP, consultate il SAP Marketplace per consultare le guide e le note aggiornate per l'installazione dei prodotti.

Automazione del deployment

Per installare SAP S/4HANA su Google Cloud, puoi utilizzare le seguenti opzioni di deployment:

  • Per automatizzare il deployment di un'infrastruttura di disponibilità (HA), puoi utilizzare lo strumento di automazione del deployment guidato in Gestore carichi di lavoro. Questo strumento consente di configurare per i carichi di lavoro SAP supportati direttamente dalla console Google Cloud scarica il codice Terraform e Ansible equivalente. Per ulteriori informazioni, consulta la sezione Informazioni sull'automazione dell'implementazione guidata.
  • Per automatizzare il deployment di un sistema SAP HANA centralizzato o distribuito, puoi utilizzare le configurazioni Terraform fornite da Google Cloud. Per maggiori informazioni consulta la guida all'implementazione SAP HANA .

Passaggi successivi