Guida alla pianificazione dell'alta disponibilità SAP HANA

Questa guida fornisce una panoramica delle opzioni, dei consigli e concetti generali che devi conoscere prima di eseguire il deployment sistema SAP HANA ad alta disponibilità su Google Cloud.

Questa guida presuppone che tu abbia già compreso i concetti e pratiche generalmente richiesti per implementare una soluzione SAP HANA ad alta disponibilità. Pertanto, la guida si concentra principalmente su ciò che per implementare questo sistema su Google Cloud.

Per saperne di più sui concetti e le pratiche generali che sono richiesti per implementare un sistema SAP HANA HA, consulta:

Questa guida alla pianificazione si concentra esclusivamente sull'alta disponibilità per SAP HANA e non copre l'alta disponibilità per i sistemi applicativi. Per informazioni sull'alta disponibilità per SAP NetWeaver, consulta la guida alla pianificazione dell'alta disponibilità per SAP NetWeaver su Google Cloud.

Questa guida non sostituisce alcuna documentazione fornita da SAP.

Opzioni ad alta disponibilità per SAP HANA su Google Cloud

Puoi utilizzare una combinazione di funzionalità di Google Cloud e SAP progettazione di una configurazione ad alta disponibilità per SAP HANA in grado di gestire a livello di infrastruttura o software. La tabella seguente descrive le funzionalità SAP e Google Cloud utilizzate per fornire la disponibilità del servizio.

Funzionalità Descrizione
Migrazione live di Compute Engine

Compute Engine monitora lo stato dell'infrastruttura sottostante ed esegue automaticamente la migrazione dell'istanza da un'infrastruttura di manutenzione. Non è richiesto alcun intervento da parte dell'utente.

Compute Engine mantiene l'istanza in esecuzione durante la migrazione se possibile. In caso di gravi interruzioni, potrebbe verificarsi un leggero ritardo tra il momento in cui l'istanza non è disponibile e il momento in cui è disponibile.

Nei sistemi multi-host, i volumi condivisi, ad esempio "/hana/shared" volume utilizzato nelle guida all'implementazione, sono dischi permanenti collegati alla VM che ospita il master. e sono montati su NFS sugli host worker. Il volume NFS è inaccessibile per alcuni secondi nel caso in cui l'istanza migrazione live. Dopo il riavvio dell'host master, il volume NFS su tutti gli host e il normale funzionamento riprende automaticamente.

Un'istanza recuperata è identica all'istanza originale, inclusi l'ID istanza, l'indirizzo IP privato e tutti i metadati dell'istanza archiviazione. Per impostazione predefinita, le istanze standard sono impostate sulla migrazione live. Me ti consigliamo di non modificare questa impostazione.

Per ulteriori informazioni, vedi Migrazione live.
Riavvio automatico di Compute Engine

Se l'istanza è impostata per terminare in caso di manutenzione o se l'istanza ha un arresto anomalo a causa di un hardware sottostante puoi configurare Compute Engine per il riavvio automatico l'istanza.

Per impostazione predefinita, le istanze sono impostate per il riavvio automatico. Ti consigliamo di non modificare questa impostazione.
Riavvio automatico del servizio SAP HANA

Il riavvio automatico del servizio SAP HANA è una soluzione di ripristino degli errori fornita di SAP.

SAP HANA ha molti servizi configurati in esecuzione costantemente per varie attività. Quando uno di questi servizi viene disattivato a causa di un errore del software o un errore umano, il servizio SAP HANA si riavvia automaticamente funzione watchdog lo riavvia automaticamente. Quando il servizio viene riavviata, carica di nuovo tutti i dati necessari in memoria che riprende l'operazione.
Backup SAP HANA

I backup SAP HANA creano copie dei dati dal tuo database che possono per ricostruire il database in un momento specifico.

Per ulteriori informazioni sull'utilizzo dei backup SAP HANA su Google Cloud, consulta Guida alle operazioni di SAP HANA.
Replica di archiviazione SAP HANA

La replica dell'archiviazione SAP HANA fornisce un'emergenza a livello di archiviazione il supporto per il ripristino tramite determinati partner per l'hardware. Archiviazione SAP HANA non è supportata su Google Cloud. Puoi prendere in considerazione l'utilizzo puoi creare snapshot di disco permanente di Compute Engine.

Per ulteriori informazioni sull'uso di snapshot di disco permanente per il backup per i sistemi SAP HANA su Google Cloud, consulta Guida alle operazioni di SAP HANA.
Failover automatico dell'host SAP HANA

Il failover automatico dell'host SAP HANA è una soluzione locale per il ripristino dei guasti che richiede uno o più host SAP HANA in standby in un sistema a scalabilità orizzontale. In caso di errore in uno degli host principali, il failover automatico dell'host porta automaticamente l'host in standby e riavvia host che non ha funzionato come host in standby.

Per ulteriori informazioni, vedi:
Replica di sistema SAP HANA

La replica di sistema SAP HANA consente di configurare una o più per sostituire il sistema principale in alta disponibilità scenari di ripristino di emergenza. Puoi ottimizzare la replica in base alle tue esigenze in termini di prestazioni e tempo di failover.
Opzione di riavvio rapido di SAP HANA (consigliata)

Il riavvio rapido SAP HANA riduce i tempi di riavvio nel caso in cui SAP HANA termina, ma il sistema operativo rimane in esecuzione. SAP HANA riduce il tempo di riavvio sfruttando la memoria permanente SAP HANA per conservare i frammenti di dati PRINCIPALI delle tabelle di archiviazione a colonne nella DRAM mappata al file system tmpfs.

Per ulteriori informazioni sull'utilizzo dell'opzione di riavvio rapido di SAP HANA, consulta consulta le guide al deployment per l'alta disponibilità:
Hook del provider HA/RE SAP HANA (consigliati)

Gli hook del provider HA/RE SAP HANA consentono a SAP HANA di inviare notifiche per determinati eventi al cluster Pacemaker, migliorando così il rilevamento dei guasti. Gli hook del provider HA/RE SAP HANA richiedono SAP HANA 2.0 SPS 03 o una versione successiva.

Per ulteriori informazioni sull'utilizzo degli hook dei provider HA/RE SAP HANA, consulta le guide al deployment per l'alta disponibilità:

Cluster ad alta disponibilità nativi del sistema operativo per SAP HANA su Google Cloud

Il clustering del sistema operativo Linux fornisce consapevolezza delle applicazioni e degli ospiti per lo stato della tua applicazione e automatizza le azioni di ripristino in caso di errore.

Sebbene i principi dei cluster ad alta disponibilità che si applicano ambienti non cloud generalmente si applicano a Google Cloud, le differenze nel modo in cui vengono implementate alcune cose, come la recinzione e gli IP virtuali.

Puoi utilizzare le distribuzioni Linux ad alta disponibilità Red Hat o SUSE per il tuo cluster ad alta disponibilità per SAP HANA su Google Cloud.

Per istruzioni su come eseguire il deployment e configurare manualmente un cluster ad alta disponibilità Google Cloud per SAP HANA: scopri:

Per le opzioni di deployment automatizzato fornite da Google Cloud, consulta Opzioni di deployment automatico per le configurazioni ad alta disponibilità SAP HANA.

Agenti di risorse cluster

Sia Red Hat che SUSE forniscono agli agenti di risorse per Google Cloud i propri implementazioni ad alta disponibilità del software del cluster Pacemaker. La per Google Cloud gestiscono le recinzioni, i VIP che implementato con route o IP alias e azioni.

Per fornire aggiornamenti non ancora inclusi negli agenti di risorse del sistema operativo di base, Google Cloud fornisce periodicamente agenti complementari per l'alta disponibilità cluster per SAP. Quando sono richiesti questi agenti di risorsa companion, Le procedure di deployment di Google Cloud includono un passaggio per scaricarle.

Agenti di recinzioni

Scherma nel contesto del clustering del sistema operativo di Google Cloud Compute Engine, sotto forma di STONITH che fornisce a ogni membro di un cluster a due nodi la possibilità di riavviare a un altro nodo.

Google Cloud fornisce due agenti di scherma da utilizzare con SAP su Linux sistemi operativi, l'agente fence_gce incluso nella certificazione Red Hat e SUSE Linux, nonché l'agente gcpstonith legacy, che puoi eseguire anche il download per l'utilizzo con le distribuzioni Linux che non includono il Agente fence_gce. Ti consigliamo di utilizzare l'agente fence_gce, se disponibili.

Autorizzazioni IAM richieste per gli agenti di fencing

Gli agenti di scherma riavviano le VM mediante una chiamata di reimpostazione alla l'API Compute Engine. Per l'autenticazione e l'autorizzazione ad accedere l'API, gli agenti fence usano l'account di servizio della VM. Il servizio utilizzato da un agente di recinzione deve disporre di un ruolo che includa le seguenti autorizzazioni:

  • compute.instances.get
  • compute.instances.list
  • compute.instances.reset
  • compute.instances.start
  • compute.instances.stop
  • compute.zoneOperations.get
  • logging.logEntries.create
  • compute.zoneOperations.list

Il ruolo Amministratore istanze Compute predefinito contiene tutte le autorizzazioni richieste.

a limitare l'ambito dell'autorizzazione di riavvio dell'agente alla destinazione. puoi eseguire il deployment e configurare l'accesso basato sulle risorse. Per ulteriori informazioni, consulta Configurazione basato sulle risorse.

Indirizzo IP virtuale

I cluster ad alta disponibilità per SAP su Google Cloud utilizzano un'istanza virtuale un indirizzo IP mobile (VIP) per reindirizzare il traffico di rete da un host a un altro in caso di failover.

I tipici deployment non cloud utilizzano un protocollo di risoluzione degli indirizzi gratuito (ARP) richiesta di annuncio del movimento e della riassegnazione di un VIP a un nuovo MAC .

Su Google Cloud, invece di utilizzare richieste ARP gratuite, utilizza uno dei diversi metodi per spostare e riallocare un VIP in un cluster ad alta disponibilità. La il metodo consigliato è utilizzare un bilanciatore del carico TCP/UDP interno, ma, a seconda in base alle tue esigenze, puoi anche utilizzare l'implementazione VIP basata su route o implementazione VIP basata su IP alias.

Per saperne di più sull'implementazione di VIP su Google Cloud, consulta Implementazione di IP virtuali su Google Cloud.

Archiviazione e replica

La configurazione di un cluster ad alta disponibilità SAP HANA utilizza SAP HANA sincrona Replica del sistema per mantenere i database SAP HANA primari e secondari sincronizzati. Gli agenti standard forniti dal sistema operativo per SAP HANA gestiscono di replicare il sistema durante un failover, con avvio e arresto replicare e cambiare le istanze che fungono da istanza le istanze attive e in standby nel processo di replica.

Se hai bisogno di uno spazio di archiviazione condiviso per i file, i filer basati su NFS o SMB possono le funzionalità richieste.

Per una soluzione di archiviazione condivisa ad alta disponibilità, puoi utilizzare Filestore o una terza parte di condivisione di file come NetApp Cloud Volumes Service for Google Cloud. Il livello Enterprise di Filestore può essere utilizzato per ambienti e il livello Base di Filestore può essere usato deployment a zona singola.

I dischi permanenti a livello di regione di Compute Engine offrono in modo sincrono l'archiviazione a blocchi replicata tra le zone. Anche se i dischi permanenti a livello di regione non sono supportati per l'archiviazione dei database nei sistemi SAP ad alta disponibilità, puoi usarli con i file server NFS.

Per ulteriori informazioni sulle opzioni di archiviazione disponibili su Google Cloud, consulta:

Impostazioni di configurazione per i cluster ad alta disponibilità su Google Cloud

Google Cloud consiglia di modificare i valori predefiniti di determinati cluster di configurazione in valori più adatti ai sistemi SAP nell'ambiente Google Cloud. Se utilizzi gli script di automazione sono forniti da Google Cloud, i valori consigliati sono impostati per te.

Considera i valori consigliati come punto di partenza per Impostazioni Corosync nel cluster ad alta disponibilità. Devi confermare che la sensibilità del rilevamento di errori e dell'attivazione del failover sia appropriata per i tuoi sistemi e carichi di lavoro nell'ambiente Google Cloud.

Valori parametro di configurazione Corosync

Nelle guide alla configurazione dei cluster ad alta disponibilità per SAP HANA, Google Cloud consiglia i valori per diversi parametri nella sezione totem del file di configurazione di corosync.conf che sono diversi dai valori predefiniti impostati da Corosync o dal tuo account distributore.

La tabella seguente mostra i parametri totem per cui Google Cloud consiglia i valori e l'impatto della loro modifica. Per i valori predefiniti di questi parametri, che possono differire tra le distribuzioni Linux, consulta la documentazione per la tua distribuzione Linux.
Parametro Valore consigliato Impatto della modifica del valore
secauth off Disattiva l'autenticazione e la crittografia di tutti i messaggi totem.
join 60 (ms) Aumenta il tempo di attesa del nodo per join messaggi nel protocollo di appartenenza.
max_messages 20 Aumenta il numero massimo di messaggi che possono essere inviati da nel nodo dopo aver ricevuto il token.
token 20.000 (ms)

Aumenta il tempo di attesa del nodo per un token di protocollo totem prima dichiara una perdita di token, presuppone un errore del nodo e inizia prendere provvedimenti.

Aumentando il valore del parametro token, più tollerante nei confronti di eventi temporanei dell'infrastruttura, come una migrazione live. Tuttavia, il cluster può richiedere più tempo per rilevare e recuperare un errore del nodo.

Anche il valore del parametro token determina il valore predefinito del parametro consensus, che controlla per quanto tempo un nodo attende il raggiungimento di un consenso prima di tentare ristabilire l'appartenenza alla configurazione.

consensus N/D

Specifica, in millisecondi, il tempo di attesa per ottenere un consenso prima di iniziare un nuovo ciclo di configurazione dell'abbonamento.

Consigliamo di omettere questo parametro. Quando consensus non viene specificato, Corosync imposta il suo valore a 1,2 volte il valore il parametro token. Se utilizzi il parametro token valore consigliato di 20000, poi consesus è impostato con il valore 24000.

Se specifichi esplicitamente un valore per consensus, assicurati che il valore sia 24000 o 1.2*token, a seconda di quale sia il numero maggiore.

token_retransmits_before_loss_const 10 Aumenta il numero di ritrasmissioni di token effettuate dal nodo prima di concludere che il nodo del destinatario non funziona e che esegue un'azione.
transport
  • Per SLES: udpu
  • Per RHEL 8 o versioni successive: knet
  • Per RHEL 7: udpu
 Specifica il meccanismo di trasporto utilizzato da corosync.

Per ulteriori informazioni sulla configurazione del file corosync.conf, vedi la guida alla configurazione per la tua distribuzione Linux:

Impostazioni di timeout e intervalli per le risorse del cluster

Quando definisci una risorsa del cluster, imposti interval e timeout, in secondi, per varie operazioni delle risorse (op). Ad esempio:

primitive rsc_SAPHanaTopology_HA1_HDB00 ocf:suse:SAPHanaTopology \
 operations \$id="rsc_sap2_HA1_HDB00-operations" \
 op monitor interval="10" timeout="600" \
 op start interval="0" timeout="600" \
 op stop interval="0" timeout="300" \
 params SID="HA1" InstanceNumber="00"

clone cln_SAPHanaTopology_HA1_HDB00 rsc_SAPHanaTopology_HA1_HDB00 \
 meta is-managed="true" clone-node-max="1" target-role="Started" interleave="true"

I valori timeout influiscono in modo diverso su ciascuna operazione delle risorse, poiché sono illustrati nella tabella seguente.

Operazione risorsa Azione di timeout
monitor Se il timeout viene superato, lo stato del monitoraggio solitamente i report come non riusciti e la risorsa associata viene considerata non riuscito. Il cluster tenta le opzioni di recupero, che possono include un failover. Il cluster non riprova a eseguire un monitoraggio non riuscito operativa.
start Se una risorsa non viene avviata prima del raggiungimento del timeout, il cluster tenta di riavviare la risorsa. Il comportamento è dettato dall'azione in caso di errore associato a una risorsa.
stop Se una risorsa non risponde a un'operazione di arresto prima del viene raggiunto il timeout, viene attivato un evento di fencing.

Insieme ad altre impostazioni di configurazione del cluster, interval e timeout le impostazioni delle risorse del cluster influiscono sulla velocità del software del cluster rileva un errore e attiva un failover.

I valori timeout e interval suggeriti da Google Cloud in le guide alla configurazione dei cluster per l'account SAP HANA per Compute Engine Migrazione live di manutenzione.

Indipendentemente dai valori timeout e interval che utilizzi, devi: Valutare i valori quando testi il cluster, in particolare durante le live dei test di migrazione, poiché la durata degli eventi di migrazione live può variare leggermente in base al tipo di macchina in uso e ad altri fattori, come il sistema all'utilizzo delle risorse.

Impostazioni delle risorse per recinzioni

Nelle guide alla configurazione dei cluster ad alta disponibilità per SAP HANA, Google Cloud consiglia diversi parametri durante la configurazione delle risorse di recinzione del un cluster ad alta disponibilità. I valori consigliati sono diversi dai valori predefiniti che sono impostate da Corosync o dal tuo distributore Linux.

La tabella seguente mostra i parametri di recinzione utilizzati da Google Cloud consiglia insieme ai valori consigliati e ai dettagli dei parametri. Per i valori predefiniti dei parametri, che possono differire tra Per le distribuzioni Linux, consulta la documentazione per la tua distribuzione Linux.

Parametro Valore consigliato Dettagli
pcmk_reboot_timeout 300 (secondi)

Specifica il valore del timeout da utilizzare per le azioni di riavvio. Il valore pcmk_reboot_timeout deve essere maggiore di la somma di quanto segue:

  • Timeout di Corosync token.
  • Timeout di Corosync consensus.
  • Il tempo necessario per completare un'operazione di riavvio, inclusi eventuali attributi di ritardo.
pcmk_monitor_retries 4 Specifica il numero massimo di volte per cui eseguire un nuovo tentativo monitor entro il periodo di timeout.
pcmk_delay_max 30 (secondi)

Specifica un ritardo casuale per le azioni di fencing per evitare i nodi del cluster scherzando contemporaneamente. Per evitare una gara di scherma assicurando che a una sola istanza venga assegnato un ritardo casuale questo parametro deve essere abilitato solo su una delle risorse di fencing in un cluster HANA ad alta disponibilità a due nodi (scale up).

In un cluster HANA ad alta disponibilità con scale out, questo parametro deve essere abilitato su tutti i nodi che fanno parte di un sito (primari o secondari)

Test del cluster ad alta disponibilità su Google Cloud

Una volta configurato il cluster e dopo che il cluster e i sistemi SAP HANA vengono di cui è stato eseguito il deployment nel tuo ambiente di test, devi testare il cluster per verificare che il sistema ad alta disponibilità sia configurato correttamente funzionando come previsto.

Per verificare che il failover funzioni come previsto, simula vari scenari di errore con le seguenti azioni:

  • Arresta la VM
  • Crea un panic del kernel
  • Arresta l'applicazione
  • Interrompi la rete tra le istanze

Inoltre, simula un evento di migrazione live di Compute Engine sull'istanza principale per confermare che non attivi un failover. Puoi simulare un di manutenzione utilizzando il comando Google Cloud CLI gcloud compute instances simulate-maintenance-event.

Logging e monitoraggio

Gli agenti di risorse possono includere funzionalità di logging che propagano i log alle Osservabilità di Google Cloud per l'analisi. Ogni agente di risorsa include la configurazione informazioni che identificano le opzioni di logging. In caso di bash implementazioni, l'opzione di logging è gcloud logging.

Puoi anche installare l'agente Cloud Logging. per acquisire l'output dei log dai processi del sistema operativo e correlare le risorse all'utilizzo con gli eventi di sistema. L'agente Logging acquisisce i log di sistema predefiniti, che includono i dati di log di Pacemaker e di clustering. Per ulteriori informazioni, consulta Informazioni sul logging un agente.

Per informazioni sull'utilizzo di Cloud Monitoring per configurare i controlli del servizio per monitorare la disponibilità degli endpoint dei servizi, consulta Gestione dei controlli di uptime.

Account di servizio e cluster ad alta disponibilità

Le azioni che il software del cluster può eseguire in Google Cloud sono protetti dalle autorizzazioni concesse al servizio, di ogni VM host. Per ambienti ad alta sicurezza, puoi limitare autorizzazioni negli account di servizio delle VM host in modo che siano conformi del privilegio minimo.

Quando limiti le autorizzazioni dell'account di servizio, tieni presente che il tuo sistema potrebbero interagire con i servizi Google Cloud, come Cloud Storage, potresti dover includere le autorizzazioni per queste interazioni l'account di servizio della VM host.

Per le autorizzazioni più restrittive, crea un ruolo personalizzato con il minimo le autorizzazioni necessarie. Per informazioni sui ruoli personalizzati, consulta Creazione e gestione di ruoli personalizzati. Puoi limitare ulteriormente le autorizzazioni limitandole a specifiche di istanze VM di una risorsa, ad esempio le istanze VM nel cluster ad alta disponibilità, aggiungendo condizioni nelle associazioni di ruolo dei criteri IAM di una risorsa.

Le autorizzazioni minime necessarie ai tuoi sistemi dipendono Le risorse Google Cloud accessibili dai tuoi sistemi e le azioni a cui dei sistemi operativi. Di conseguenza, la determinazione delle autorizzazioni minime richieste le VM host nel cluster ad alta disponibilità potrebbero richiedere di indagare esattamente le risorse ai sistemi sulla VM host e le azioni che tali dei sistemi operativi con quelle risorse.

Come punto di partenza, l'elenco seguente mostra alcune risorse del cluster ad alta disponibilità le autorizzazioni associate di cui hanno bisogno:

  • Scherma
    • compute.instances.list
    • compute.instances.get
    • compute.instances.reset
    • compute.instances.stop
    • compute.instances.start
    • logging.logEntries.create
    • compute.zones.list
  • VIP implementato mediante un IP alias
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.instances.updateNetworkInterface
    • compute.zoneOperations.get
    • logging.logEntries.create
  • VIP implementato utilizzando route statiche
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.routes.get
    • compute.routes.create
    • compute.routes.delete
    • compute.routes.update
    • compute.routes.list
    • compute.networks.updatePolicy
    • compute.networks.get
    • compute.globalOperations.get
    • logging.logEntries.create
  • VIP implementato mediante un bilanciatore del carico interno
    • Non sono richieste autorizzazioni specifiche: il bilanciatore del carico opera sugli stati del controllo di integrità che non richiedono l'interazione con il cluster o modificare le risorse in Google Cloud

Implementazione di indirizzi IP virtuali su Google Cloud

Un cluster ad alta disponibilità utilizza un indirizzo IP fluttuante o virtuale (VIP). di spostare il carico di lavoro da un nodo cluster a un altro nel caso di un un guasto imprevisto o una manutenzione pianificata. L'indirizzo IP del VIP non cambia, quindi le applicazioni client non sono consapevoli che il lavoro viene gestito da un nodo diverso.

Un VIP è chiamato anche indirizzo IP mobile.

Su Google Cloud, i VIP vengono implementati in modo leggermente diverso nelle installazioni on-premise, in quanto, in caso di failover, l'ARP gratuito non possono essere utilizzate per annunciare il cambiamento. In alternativa, puoi implementare per un cluster ad alta disponibilità SAP, utilizzando uno dei seguenti metodi:

Implementazioni VIP del bilanciatore del carico di rete passthrough interno

In genere, un bilanciatore del carico distribuisce il traffico degli utenti su più istanze per le tue applicazioni, sia per distribuire il carico di lavoro tra sistemi e proteggerti da un rallentamento o un guasto dell'elaborazione su nessuno in esecuzione in un'istanza Compute Engine.

Il bilanciatore del carico di rete passthrough interno fornisce inoltre il failover di supporto che puoi utilizzare con i controlli di integrità di Compute Engine rilevare errori, attivare il failover e reindirizzare il traffico a un nuovo progetto SAP principale in un cluster ad alta disponibilità nativo del sistema operativo.

Il VIP consigliato è il supporto del failover per diversi motivi, tra cui:

  • Il bilanciamento del carico su Compute Engine offre una disponibilità del 99,99% SLA.
  • Il bilanciamento del carico supporta cluster multizona ad alta disponibilità, protegge dai guasti delle zone con tempi di failover tra zone prevedibili.
  • L'utilizzo del bilanciamento del carico riduce il tempo necessario per rilevare e attivare un di failover, solitamente entro pochi secondi dall'errore. I tempi complessivi di failover sono dipende dai tempi di failover di ciascuno dei componenti del sistema ad alta disponibilità, che può includere host, sistemi di database, sistemi applicativi e altro ancora.
  • Il bilanciamento del carico semplifica la configurazione del cluster e riduce delle dipendenze.
  • A differenza di un'implementazione VIP che utilizza le route, con il bilanciamento del carico, utilizzare gli intervalli IP della tua rete VPC, consentendoti di prenotare configurarle in base alle tue esigenze.
  • Il bilanciamento del carico può essere utilizzato facilmente per reindirizzare il traffico a un server per le interruzioni di manutenzione pianificate.

Quando crei un controllo di integrità per l'implementazione del bilanciatore del carico di un VIP, devi specificare la porta host probe del controllo di integrità per determinare l'integrità dell'host. Per un cluster SAP ad alta disponibilità, una porta host di destinazione nell'intervallo privato, 49152-65535, per evitare conflitti con altri servizi. Configura la porta di destinazione sulla VM host con un servizio helper secondario, come l'utilità socat o HAProxy.

Per i cluster di database in cui rimane il sistema secondario in standby online, il servizio di controllo di integrità e helper consente il bilanciamento del carico indirizzare il traffico al sistema online che attualmente funziona come principale nel cluster.

Utilizzando il servizio helper e il reindirizzamento delle porte, puoi attivare un'operazione per la manutenzione pianificata del software sui tuoi sistemi SAP.

Per ulteriori informazioni sul supporto del failover, consulta Configurare il failover per bilanciatori del carico di rete passthrough interni.

Per eseguire il deployment di un cluster ad alta disponibilità con un'implementazione VIP del bilanciatore del carico, consulta:

Implementazioni di VIP per le route statiche

L'implementazione delle route statiche fornisce inoltre protezione contro i guasti delle zone, ma richiede l'utilizzo di un VIP esterno agli intervalli IP della tua rete alle subnet VPC in cui si trovano le VM. Di conseguenza, devi anche assicurati che il VIP non sia in conflitto con indirizzi IP esterni nella tua rete estesa.

Le implementazioni delle route statiche possono anche introdurre complessità quando vengono utilizzate con configurazioni di VPC condivise, che sono destinate a isolare configurazione di rete a un progetto host.

Se utilizzi un'implementazione di route statiche per il tuo VIP, consulta il tuo l'amministratore di rete per determinare un indirizzo IP adatto un'implementazione di route statiche.

Implementazioni di IP alias VIP

Le implementazioni di IP alias VIP non sono consigliate per l'alta disponibilità multizona perché, in caso di errore di una zona, la riallocazione dell'IP alias a un nodo in una zona diversa possono subire ritardi. Implementa il VIP con un bilanciatore del carico di rete passthrough interno con supporto del failover.

Se esegui il deployment di tutti i nodi del tuo cluster SAP ad alta disponibilità nella stessa zona, puoi utilizzare un IP alias per implementare un VIP per il cluster ad alta disponibilità.

Se esistono già cluster SAP ad alta disponibilità multizona che utilizzano un IP alias per il VIP, puoi eseguire la migrazione a un bilanciatore del carico di rete passthrough interno senza modificare l'indirizzo VIP. Sia gli indirizzi IP alias sia i bilanciatori del carico di rete passthrough interni utilizzano gli intervalli IP della rete VPC.

Sebbene gli indirizzi IP alias non siano consigliati per le implementazioni VIP in i cluster ad alta disponibilità multizona, hanno altri casi d'uso nei deployment SAP. Per ad esempio per fornire un nome host logico e assegnazioni IP per deployment SAP flessibili, come quelli gestiti da SAP Landscape Management.

Best practice generali per i VIP su Google Cloud

Per ulteriori informazioni sui VIP su Google Cloud, consulta Best practice per gli indirizzi IP mobili.

Failover automatico dell'host SAP HANA su Google Cloud

Google Cloud supporta il failover automatico dell'host SAP HANA, soluzione di ripristino dagli errori fornita da SAP HANA. Failover automatico dell'host di una soluzione utilizza uno o più host di standby tenuti riservati affinché rispetto al lavoro dell'host master o di un host worker in caso di errore dell'host. Gli host in standby non contengono dati né elaborano alcun lavoro.

Al termine di un failover, l'host in errore viene riavviato come host in standby.

SAP supporta fino a tre host in standby sistemi di scale out di Google Cloud. Gli host in standby non vengono conteggiati rispetto il massimo di 16 host attivi supportati da SAP nei sistemi a scalabilità orizzontale su in Google Cloud.

Per ulteriori informazioni da SAP sulla soluzione di failover automatico dell'host, vedi Failover automatico dell'host.

Quando utilizzare il failover automatico dell'host SAP HANA su Google Cloud

Il failover automatico dell'host SAP HANA protegge dagli errori che interessano una singola nodo in un sistema di scale out SAP HANA, con errori di:

  • L'istanza SAP HANA
  • Il sistema operativo host
  • La VM host

Per quanto riguarda gli errori della VM host, su Google Cloud, il riavvio automatico che in genere ripristina la VM host SAP HANA più velocemente rispetto al failover automatico dell'host. e la migrazione live insieme proteggono da VM sia pianificate che non pianificate o in caso di interruzione del servizio. Quindi, per la protezione delle VM, la soluzione di failover automatico dell'host SAP HANA necessaria.

Il failover automatico dell'host SAP HANA non protegge da errori a livello di zona, il deployment di tutti i nodi di un sistema di scale out SAP HANA viene eseguito in un'unica zona.

Il failover automatico dell'host SAP HANA non precarica i dati SAP HANA in la memoria dei nodi di standby. Di conseguenza, quando un nodo in standby prende il controllo, il tempo complessivo di recupero del nodo è determinato principalmente dal tempo necessario per il caricamento i dati nella memoria del nodo in standby.

Valuta la possibilità di utilizzare il failover automatico dell'host SAP HANA per i seguenti scenari:

  • Errori nel software o nel sistema operativo host di un nodo SAP HANA che potrebbero non essere rilevati da Google Cloud.
  • Esegui la migrazione lift and shift, in cui è necessario riprodurre i configurazione SAP HANA on-premise fino a quando non potrai ottimizzare SAP HANA in Google Cloud.
  • Quando una configurazione ad alta disponibilità cross-zone completamente replicata costi proibitivi e la tua azienda può tollerare:
    • Un tempo di recupero del nodo più lungo a causa della necessità di caricare dati SAP HANA nella memoria di un nodo in standby.
    • Il rischio di errore a livello di zona.

Storage Manager per SAP HANA

I volumi /hana/data e /hana/log sono montati sul master e solo host worker. In caso di takeover, la soluzione di failover automatico dell'host utilizza l'API SAP HANA Storage Connector e Google Cloud Gestione archiviazione per i nodi in standby SAP HANA da cui spostare i montaggi dei volumi l'host non riuscito passa all'host in standby.

Su Google Cloud, è richiesto Gestione archiviazione per SAP HANA per i sistemi SAP HANA che utilizzano il failover automatico dell'host SAP HANA.

Versioni supportate di Gestione archiviazione per SAP HANA

Sono supportate le versioni 2.0 e successive di Gestione archiviazione per SAP HANA. Tutte le versioni precedenti alla 2.0 vengono è deprecata e non supportata. Se utilizzi una versione precedente, aggiorna il file SAP HANA per utilizzare l'ultima versione dello Gestione archiviazione per SAP HANA. Consulta: Aggiornamento di Gestione archiviazione per SAP HANA.

Per determinare se la tua versione è deprecata, apri il file gceStorageClient.py. La directory di installazione predefinita è /hana/shared/gceStorageClient.

A partire dalla versione 2.0, il numero di versione è indicato nei commenti alla pagina nella parte superiore del file gceStorageClient.py, come mostrato nell'esempio seguente. Se manca il numero di versione, significa che stai visualizzando una versione deprecata di Gestione archiviazione per SAP HANA.

"""Google Cloud Storage Manager for SAP HANA Standby Nodes.

The Storage Manager for SAP HANA implements the API from the SAP provided
StorageConnectorClient to allow attaching and detaching of disks when
running in Compute Engine.

Build Date: Wed Jan 27 06:39:49 PST 2021
Version: 2.0.20210127.00-00

"""

Installazione di Gestione archiviazione per SAP HANA

Il metodo consigliato per installare Gestione archiviazione per SAP HANA è utilizzare un metodo di deployment automatizzato per eseguire il deployment di un sistema SAP HANA con scale out che include il Gestione archiviazione più recente per SAP HANA.

Se devi aggiungere il failover automatico dell'host SAP HANA a un progetto SAP HANA esistente di scale out su Google Cloud, l'approccio consigliato è simile: usa il file di configurazione Terraform o Deployment Manager modello che è fornito da Google Cloud per eseguire il deployment di una nuova soluzione SAP HANA con scale out di sistema e quindi di caricare i dati nel nuovo sistema da quello esistente. Per caricare i dati, puoi utilizzare il backup e SAP HANA standard di ripristino o di replica del sistema SAP HANA, che possono limitare i tempi di inattività. Per ulteriori informazioni sulla replica del sistema, consulta la nota SAP 2473002 - Utilizzo della replica di sistema HANA per eseguire la migrazione del sistema di scale out.

Se non puoi utilizzare un metodo di deployment automatico, considera contattare un consulente per le soluzioni SAP, come disponibile tramite servizi di consulenza Google Cloud, per ricevere assistenza sull'installazione manuale di Gestione archiviazione per SAP HANA.

L'installazione manuale di Gestione archiviazione per SAP HANA un sistema SAP HANA con scale out esistente o nuovo non è attualmente documentato.

Per saperne di più sulle opzioni di deployment automatico per il failover automatico dell'host SAP HANA, consulta Deployment automatico di SAP HANA sistemi con scale out con failover automatico dell'host SAP HANA.

Aggiornamento di Gestione archiviazione per SAP HANA

Per aggiornare Gestione archiviazione per SAP HANA, devi prima scaricare l'installazione ed eseguendo uno script di installazione che aggiorna Gestione archiviazione per SAP HANA eseguibile nell'unità SAP HANA /shared.

La procedura seguente si applica solo alla versione 2 di Gestione archiviazione per SAP HANA. Se utilizzi una versione di Gestione archiviazione per SAP HANA scaricata Prima del 1° febbraio 2021, installa la versione 2 prima di tentare di aggiornare Gestione archiviazione per SAP HANA.

Per aggiornare Gestione archiviazione per SAP HANA:

  1. Controlla la versione del Gestione archiviazione attuale per SAP HANA:

    RHEL 

    sudo yum check-update google-sapgcestorageclient

    SLES 

    sudo zypper list-updates -r google-sapgcestorageclient

  2. Se esiste un aggiornamento, installalo:

    RHEL 

    sudo yum update google-sapgcestorageclient

    SLES 

    sudo zypper update

    Lo Gestione archiviazione aggiornato per SAP HANA è installato in /usr/sap/google-sapgcestorageclient/gceStorageClient.py.

  3. Sostituisci il campo gceStorageClient.py esistente con quello aggiornato File gceStorageClient.py:

    • Se il file gceStorageClient.py esistente è in /hana/shared/gceStorageClient, il valore predefinito percorso di installazione, utilizza lo script di installazione per aggiornare il file:

      sudo /usr/sap/google-sapgcestorageclient/install.sh

    • Se il file gceStorageClient.py esistente non è in /hana/shared/gceStorageClient, copia il file aggiornato nella nella stessa posizione del file esistente, sostituendo quello esistente.

Parametri di configurazione nel file global.ini

alcuni parametri di configurazione per Gestione archiviazione per SAP HANA tra cui se la fencing è abilitata o disabilitata, vengono memorizzati spazio di archiviazione del file SAP HANA global.ini. Quando utilizzi Terraform di configurazione del deployment o il modello di Deployment Manager forniti da Google Cloud per eseguire il deployment di un software SAP HANA con la funzione di failover automatico dell'host, il processo di deployment aggiunge di configurazione al file global.ini.

L'esempio seguente mostra i contenuti di un elemento global.ini creato per Gestione archiviazione per SAP HANA:

[persistence]
basepath_datavolumes = %BASEPATH_DATAVOLUMES%
basepath_logvolumes = %BASEPATH_LOGVOLUMES%
use_mountpoints = %USE_MOUNTPOINTS%
basepath_shared = %BASEPATH_SHARED%

[storage]
ha_provider = gceStorageClient
ha_provider_path = %STORAGE_CONNECTOR_PATH%

#
# Example configuration for 2+1 setup
#
# partition_1_*__pd = node-mnt00001
# partition_2_*__pd = node-mnt00002
# partition_3_*__pd = node-mnt00003
# partition_*_data__dev = /dev/hana/data
# partition_*_log__dev = /dev/hana/log
# partition_*_data__mountOptions = -t xfs -o logbsize=256k
# partition_*_log__mountOptions = -t xfs -o logbsize=256k
# partition_*_*__fencing = disabled

[trace]
ha_gcestorageclient = info

Accesso Sudo per Gestione archiviazione per SAP HANA

Per gestire i servizi e l'archiviazione SAP HANA, Gestione archiviazione per SAP HANA utilizza SID_LCadm account utente e richiede l'accesso sudo a un determinato sistema file binari.

Se utilizzi gli script di automazione forniti da Google Cloud eseguire il deployment di SAP HANA con failover automatico dell'host, l'accesso sudo richiesto è configurato per te.

Se installi manualmente Gestione archiviazione per SAP HANA, utilizza visudo per modificare il file /etc/sudoers in modo che abbia L'accesso sudo per l'account utente di SID_LCadm a quanto segue con i file binari richiesti.

Fai clic sulla scheda relativa al tuo sistema operativo:

RHEL 

/bin/kill
/bin/mount
/bin/umount
/sbin/dmsetup
/sbin/lvdisplay
/sbin/lvscan
/sbin/pvscan
/sbin/vgchange
/sbin/vgscan
/usr/bin/gcloud
/usr/bin/lsof
/usr/bin/mkdir
/usr/bin/sg_persist
/usr/bin/systemctl
/usr/sbin/lsof
/usr/sbin/xfs_repair

SLES 

/bin/kill
/bin/mount
/bin/umount
/sbin/dmsetup
/sbin/lvdisplay
/sbin/lvscan
/sbin/pvscan
/sbin/vgchange
/sbin/vgscan
/sbin/xfs_repair
/usr/bin/gcloud
/usr/bin/lsof
/usr/bin/mkdir
/usr/bin/sg_persist
/usr/bin/systemctl
/usr/sbin/lsof

L'esempio seguente mostra una voce nel file /etc/sudoers. Nella Ad esempio, l'ID di sistema per il sistema SAP HANA associato viene sostituito con SID_LC. La voce di esempio è stata creata Deployment Manager fornito da Google Cloud per lo scale out di SAP HANA con failover automatico dell'host. La voce creata dal modello Deployment Manager include programmi binari che non sono più necessari, ma che vengono conservati per la compatibilità con le versioni precedenti. Devi includere solo i file binari che appaiono nell'elenco precedente.

SID_LCadm ALL=NOPASSWD: /sbin/multipath,/sbin/multipathd,/etc/init.d/multipathd,/usr/bin/sg_persist,/bin/mount,/bin/umount,/bin/kill,/usr/bin/lsof,/usr/bin/systemctl,/usr/sbin/lsof,/usr/sbin/xfs_repair,/sbin/xfs_repair,/usr/bin/mkdir,/sbin/vgscan,/sbin/pvscan,/sbin/lvscan,/sbin/vgchange,/sbin/lvdisplay,/usr/bin/gcloud,/sbin/dmsetup

Archiviazione NFS per failover automatico dell'host SAP HANA

Un sistema di scale out SAP HANA con failover automatico dell'host richiede una soluzione NFS, come Filestore, per condividere /hana/shared e /hanabackup tra tutti gli host. Devi configurare la soluzione NFS autonomamente.

Quando utilizzi un metodo di deployment automatico, fornisci informazioni sul server NFS nel file di deployment, per montare le directory NFS durante il deployment.

Il volume NFS che utilizzi deve essere vuoto. Gli eventuali file esistenti possono con il processo di deployment, in particolare se i file o le cartelle fanno riferimento all'ID di sistema SAP (SID). Il deployment processo non è in grado di determinare se i file possono essere sovrascritti.

Il processo di deployment archivia /hana/shared e /hanabackup volumi sul server NFS e monta il server NFS su tutti gli host, incluso gli host in standby. L'host master gestisce quindi il server NFS.

Se stai implementando una soluzione di backup, come l'agente Backint di Cloud Storage per SAP HANA, puoi rimuovi il volume /hanabackup dal server NFS al termine del deployment.

Per ulteriori informazioni sulle soluzioni per i file condivisi disponibili che sono disponibili su Google Cloud, vedi Soluzioni di condivisione file per SAP su Google Cloud.

Supporto del sistema operativo

Google Cloud supporta il failover automatico dell'host SAP HANA solo su sui seguenti sistemi operativi:

  • RHEL per SAP 7.7 o versioni successive
  • RHEL per SAP 8.1 o versioni successive
  • RHEL per SAP 9.0 o versioni successive
    • Prima di installare qualsiasi software SAP su RHEL for SAP 9.x, è necessario installare pacchetti aggiuntivi dalle macchine host, in particolare chkconfig e compat-openssl11. Se utilizzi un'immagine fornita da Compute Engine, questi pacchetti vengono installati automaticamente te. Per ulteriori informazioni da SAP, vedi SAP Note 3108316 - Red Hat Enterprise Linux 9.x: Installazione e configurazione di Google.
  • SLES per SAP 12 SP5
  • SLES per SAP 15 SP1 o versione successiva

Per vedere le immagini pubbliche disponibili in Compute Engine, Immagini.

Architettura di un sistema SAP HANA con failover automatico dell'host

Il seguente diagramma mostra un'architettura di scale out su Google Cloud che include la funzionalità di failover automatico dell'host SAP HANA. Nel diagramma, Gestione archiviazione per SAP HANA è rappresentato dal nome di il suo eseguibile, gceStorageClient.

Il diagramma mostra un errore del nodo worker 2 e il nodo in standby. Storage Manager per SAP HANA funziona con SAP Storage Connector API (non mostrata) per scollegare i dischi che contengono i volumi /hana/data e /hana/logs nodo worker e rimontarle sul nodo in standby, che poi diventa worker Node 2, mentre il nodo in errore diventa il nodo di standby.

Il diagramma illustra l'architettura di un sistema SAP HANA a scale out che include supporto per il failover automatico dell'host

Opzioni di deployment automatico per le configurazioni ad alta disponibilità SAP HANA

Google Cloud fornisce file di deployment puoi utilizzare per automatizzare il deployment dei sistemi SAP HANA ad alta disponibilità puoi eseguire il deployment e configurare i tuoi sistemi SAP HANA HA manualmente.

Per il deployment automatico dei sistemi ad alta disponibilità SAP HANA, puoi utilizzare Terraform o con Deployment Manager.

Google Cloud fornisce file di configurazione Terraform specifici per il deployment completato. Puoi usare i comandi Terraform standard per inizializzare la directory di lavoro attuale e scaricare il provider Terraform dei plug-in e dei moduli dei moduli per Google Cloud e applicare per il deployment di un sistema SAP HANA.

I modelli di Deployment Manager che Google Cloud fornisce includono una configurazione template.yaml file completato. Deployment Manager legge di configurazione ed esegue il deployment di un sistema SAP HANA.

Questi metodi di deployment automatizzato di eseguire il deployment di un sistema SAP HANA supportato da SAP e che aderisce alle best practice di SAP e in Google Cloud.

Deployment automatico di cluster Linux ad alta disponibilità per SAP HANA

Per SAP HANA, i metodi di deployment automatizzato esegui il deployment di un cluster Linux ad alta disponibilità e ottimizzato per le prestazioni che include:

  • Failover automatico.
  • Riavvio automatico.
  • Una prenotazione dell'indirizzo IP virtuale (VIP) specificato.
  • Supporto del failover fornito dal bilanciamento del carico TCP/UDP interno che gestisce il routing dall'indirizzo IP virtuale (VIP) ai nodi nel cluster ad alta disponibilità.
  • Una regola firewall che consenta i controlli di integrità di Compute Engine per monitorare le istanze VM nel cluster.
  • Gestore delle risorse del cluster ad alta disponibilità Pacemaker.
  • Un meccanismo di scherma di Google Cloud.
  • Una VM con i dischi permanenti richiesti per ogni istanza SAP HANA.
  • Istanze SAP HANA configurate per la replica sincrona e di precaricamento della memoria.

Puoi utilizzare uno dei seguenti metodi di deployment per eseguire il deployment di un modello ad alta disponibilità per SAP HANA:

Deployment automatico di sistemi di scale out SAP HANA con failover automatico dell'host SAP HANA

Puoi utilizzare uno dei seguenti metodi di deployment per eseguire il deployment di SAP HANA sistemi a scalabilità orizzontale con failover automatico dell'host:

Per un sistema di scale out SAP HANA che include il failover automatico dell'host SAP HANA il deployment automatico esegue il deployment di:

  • Un'istanza SAP HANA master
  • Da 1 a 15 host worker
  • Da 1 a 3 host in standby
  • Una VM per ogni host SAP HANA
  • Dischi permanenti per gli host master e worker
  • Google Cloud Gestione archiviazione per i nodi in standby SAP HANA

Un sistema di scale out SAP HANA con failover automatico dell'host richiede una soluzione NFS, come Filestore, per condividere /hana/shared e /hanabackup volumi tra tutti gli host. Per fare in modo che Terraform Deployment Manager può montare le directory NFS durante devi configurare personalmente la soluzione NFS prima di eseguire il deployment HANA.

Puoi configurare rapidamente le istanze del server NFS di Filestore facilmente seguendo le istruzioni all'indirizzo Creazione di istanze.

Opzione Attiva/Attiva (lettura abilitata) per SAP HANA

A partire da SAP HANA 2.0 SPS1, SAP fornisce la configurazione attiva/attiva (con lettura abilitata) per gli scenari di replica del sistema SAP HANA. In un sistema di replica configurato per Attivo/Attivo (Lettura abilitata), le porte SQL sul sistema secondario sono aperte per l'accesso in lettura. Ciò consente di utilizzare il sistema secondario per attività ad alta intensità di lettura e di avere un migliore equilibrio dei carichi di lavoro tra le risorse di calcolo, migliorando le prestazioni complessive del database SAP HANA. Per ulteriori informazioni sulla funzionalità Attiva/Attiva (Lettura abilitata), consulta la Guida all'amministrazione di SAP HANA specifica per la tua versione SAP HANA e la Nota SAP 1999880.

Per configurare una replica di sistema che consenta l'accesso in lettura sul sistema secondario, devi utilizzare la modalità operativa logreplay_readaccess. Tuttavia, per utilizzare questa modalità operativa, i sistemi primari e secondari devono eseguire la stessa versione SAP HANA. Di conseguenza, l'accesso di sola lettura al sistema secondario non è possibile durante un upgrade in sequenza finché entrambi i sistemi non eseguono la stessa versione SAP HANA.

Per connettersi a un sistema secondario Attivo/Attivo (abilitato alla lettura), SAP supporta le seguenti opzioni:

  • Connettiti direttamente aprendo una connessione esplicita al sistema secondario.
  • Connettiti indirettamente eseguendo un'istruzione SQL sul sistema principale con un hint, che al momento della valutazione reindirizza la query al sistema secondario.

Il seguente diagramma mostra la prima opzione, in cui le applicazioni accedono al sistema secondario direttamente in un cluster Pacemaker di cui è stato eseguito il deployment in Google Cloud. Viene utilizzato un indirizzo IP virtuale o virtuale aggiuntivo (VIP) per scegliere come target l'istanza VM che funge da sistema secondario come parte del cluster SAP HANA Pacemaker. Il VIP segue il sistema secondario e può spostare il carico di lavoro di lettura da un nodo cluster a un altro in caso di errore imprevisto o per la manutenzione pianificata. Per informazioni sui metodi di implementazione VIP disponibili, vedi Implementazione di indirizzi IP virtuali su Google Cloud.

Panoramica di un cluster Linux ad alta disponibilità per un sistema di scaleup SAP HANA attivo/attivo (abilitato alla lettura)

Per istruzioni su come configurare la replica di sistema SAP HANA con Attivo/Attivo (abilitata per la lettura) in un cluster Pacemaker:

Passaggi successivi

Sia Google Cloud che SAP forniscono maggiori informazioni l'alta disponibilità.

Ulteriori informazioni di Google Cloud sull'alta disponibilità

Per saperne di più sull'alta disponibilità per SAP HANA su Google Cloud, vedi Guida alle operazioni di SAP HANA.

Per informazioni generali sulla protezione dei sistemi su Google Cloud nei confronti di vari scenari di errore, consulta la sezione Progettazione di sistemi solidi.

Ulteriori informazioni da SAP sulle funzionalità ad alta disponibilità di SAP HANA

Per ulteriori informazioni da SAP sulle funzionalità ad alta disponibilità di SAP HANA, consulta ai seguenti documenti: