SAP · Infrastruttura · scheda YoctoIT

HA & DR

RTO e RPO reali per il sistema più critico dell'azienda: cluster, repliche e piani di disaster recovery testati davvero.

FOCUS · CONTINUITÀ DELL'ERPHSR, cluster Pacemaker e DR geografico: la continuità si progetta e si prova
Materiale YoctoIT per clienti e partner · SAP, S/4HANA, HANA, BTP e gli altri prodotti citati sono marchi di SAP SE o di sue affiliate.
01 · Cos'è

Alta affidabilità & DR SAP, in chiaro.

Se si ferma SAP si ferma l'azienda: ordini, spedizioni, fatture. La continuità dell'ERP si costruisce a strati — cluster locale per il guasto singolo, replica geografica per il disastro, e prove periodiche perché un DR non testato è una speranza, non un piano.

RPO 0
con HANA System Replication sincrona nel campus
RTO <1h
l'obiettivo tipico dei nostri piani, misurato nei test
2 test/anno
il minimo per chiamare 'piano' un disaster recovery
Alta affidabilità & DR SAP
VESTE UFFICIALE SAP · HA & DR
SCHEMA UFFICIALE · CLUSTER HA SAP HANA · FONTE: RED HAT DOCS
SCHEMA UFFICIALE · CLUSTER HA SAP HANA · FONTE: RED HAT DOCS
02 · Come lo si usa bene

Le cose che fanno la differenza.

I tre strati

Applicazione SAPASCS/ERS protetti dal cluster
Cluster HA locale
HSR sincrona
Replica asincrona DR
guasto · campus · geografia
Runbook di failoverchi fa cosa, scritto e provato
Test periodici documentatil'evidenza per audit e assicurazioni
Dal guasto del nodo al disastro di sito

Cluster ASCS/ERS

Il single point of failure applicativo protetto con Pacemaker: il lock server che non muore.

HSR multitier

Replica sincrona + asincrona in catena: HA e DR con un'unica tecnologia nativa.

DR su cloud

Il sito secondario in cloud quando il secondo data center non c'è: la sponda ibrida pragmatica.

Failback incluso

Tornare indietro è metà del piano: lo scriviamo e lo proviamo come l'andata.

03 · In profondità

Anatomia del cluster SAP

La catena HA di un sistema SAP ha tre anelli: ASCS/ERS protetti da Pacemaker con risorse SAPInstance e regole di anti-collocazione (ENSA2), il database in replica nativa (HSR per HANA) orchestrato da SAPHanaSR/angi con takeover automatico, e il file system condiviso (/sapmnt) ad alta disponibilità. Il DR aggiunge il terzo sito o il tier asincrono: log replay continuo, RPO da secondi, e il runbook di failover geografico con la sequenza DNS/virtual IP.

  • ENSA2 — Standalone Enqueue Server 2: il lock server che rinasce su un altro nodo senza perdere i lock
  • SAPHanaSR-angi — il resource agent moderno per HSR: takeover automatico con fencing verificato
  • Fencing/SBD — STONITH sempre attivo: il cluster senza fencing è un incidente in attesa
  • HSR multitier — sync in campus + async geografico in catena: HA e DR con una tecnologia
  • Log replay — la standby applica i log in continuo: takeover in minuti, non ore
  • Prove semestrali — switchover e failover documentati con verbale: NIS2 e assicurazioni servite
04 · Numeri e ciclo di vita

I numeri che contano.

RPO 0
in sincrono nel campus (fino a ~100 km di fibra)
RTO <15'
il takeover HANA tipico con SR e agent ben tarati
2
i test di failover l'anno che consideriamo il minimo professionale
3
gli anelli protetti: enqueue, database, filesystem
L'alta affidabilità SAP è una catena: si spezza sull'anello che nessuno ha provato — noi li proviamo tutti, due volte l'anno.
05 · Use case

Dove rende davvero.

Compliance NIS2

La continuità dell'ERP tra i requisiti: evidenze e test documentati.

Fusioni e carve-out

La continuità durante le trasformazioni societarie.

Stagionalità critica

Il picco che non può cadere: la campagna, la vendemmia, il Black Friday.

Il DR di SAP è il nostro esame di maturità preferito: lo passiamo due volte l'anno, coi tuoi dati.