White paper Libelle BusinessShadow - wssitalia.it · WHITE PAPER Libelle BusinessShadow® - High...

WHITE PAPER

Libelle BusinessShadow® - High Availability e Disaster Recovery 1

Libelle BusinessShadow®

High Availability e Disaster Recovery

Versione documento: 3.0

Libelle AG fornisce soluzioni di High Availability (HA) e Disaster Recovery (DR) da più di dieci anni.

Con più di 1000 installazioni in tutto il mondo, Libelle ha dimostrato di poter soddisfare le richieste più

esigenti.

Questo documento chiarisce i concetti di High Availability e Disaster Recovery, presenta la tecnologia

che supporta la soluzione BusinessShadow per HA e DR e include sia una panoramica su come la

soluzione si collochi sul mercato, sia alcune considerazioni importanti per la definizione di soluzioni di

replica.

Libelle BusinessShadow è disponibile per le maggiori piattaforme tecnologiche di mercato.

BusinessShadow è stata certificata per infrastrutture DB quali SAP, Oracle, BD2, SQL, MaxDB, etc., ed

integrabile con soluzioni basate su tecnologia SAP HANA.

WSS Italia S.r.l.

Via Giulio Ceradini, 12 - 20129 Milano

Telefono +39 02 70009046 - Fax +39 02 70009300

[email protected] - www.wssitalia.it

WHITE PAPER


Indice

Introduzione .......................................................................................................................................... 3

Terminologia ................................................................................................................................................... 3

High Availability .............................................................................................................................................. 3

Disaster Recovery .......................................................................................................................................... 4

Campo di Applicazione per HA e DR ....................................................................................................... 4

Architettura Enterprise IT .............................................................................................................................. 4

Recovery Point Objectives ............................................................................................................................. 5

Recovery Time Objectives ............................................................................................................................. 5

Recovery Consistency Objectives .................................................................................................................. 6

Replication basics .................................................................................................................................. 6

Database Layer, File Layer, Storage Layer ..................................................................................................... 7

Replica Sincrona ............................................................................................................................................. 7

Replica Asincrona .......................................................................................................................................... 8

Libelle BusinessShadow® ....................................................................................................................... 9

Software Components ................................................................................................................................... 9

Solution Design ............................................................................................................................................ 10

Scenari di High Availability .......................................................................................................................... 12

Scenari di Disaster Recovery ........................................................................................................................ 14

Integrazione nelle soluzioni SAP .......................................................................................................... 14

L'impegno di Libelle nel mercato SAP .......................................................................................................... 14

Requisiti per SAP .......................................................................................................................................... 15

La Tecnologia di BusinessShadow ........................................................................................................ 16

Core Server Agents ...................................................................................................................................... 16

Database Mirroring ...................................................................................................................................... 18

Mirroring dei files non strutturati ............................................................................................................... 19

Wide Area Network Enhancements: Option Long Distance ........................................................................ 20

Application Failover ..................................................................................................................................... 21

Recover Process in Emergency Mode .......................................................................................................... 21

Libelle SwitchApplication ............................................................................................................................ 21

Failover e altre interfacce utente ................................................................................................................. 23

Graphical User Interface (GUI) .............................................................................................................. 24

Sommario ............................................................................................................................................ 25

WHITE PAPER


lntroduzione

High Availability e Disaster Recovery sono spesso usati con significati diversi all'interno di specifiche, disegni e soluzioni in ambito informatico. Come prima cosa quindi inquadriamo i termini in uso e le loro implicazioni.

Terminologia

I termini "High Availability" (HA) e "Disaster Recovery'' (DR} sono ampiamente usati in questo documento.

Le architetture che saranno sviluppate nei paragrafi successivi si occupano sia di ambienti HA che di ambienti DR.

La nostra esperienza ci dimostra che anche i professionisti qualche volta non hanno ben chiaro il significato di questi termini o, addirittura, li confondono. Poiché questi termini definiscono lo scopo dei progetti, vogliamo essere chiari sul loro significato:

High Availability (HA): include tutti i tools, le strategie e le procedure che devono essere applicate per assicurare la disponibilità locale dei sistemi, inclusa la protezione contro guasti hardware ed errori del software e/o dell'utente. I tools che si occupano di HA sono tipicamente Server o database Clusters, ridondanza dei componenti, Storage Area Networks per i guasti hardware e il backup/recovery di database in standby per errori software, errori utenti o corruzione dei dati.

Disaster Recovery (DR): include tutti i tools, le strategie e le procedure per assicurare una normale ripresa delle operazioni dopo un guasto parziale o totale. I tools che si occupano di DR sono tipicamente backup e recovery che permettono l'accesso ad un nuovo sistema ("cold standby") o replica dei dati in tempo reale e failover verso un sistema secondario pre-configurato ("warm standby" o "hot standby").

Business Continuity Planning (BCP): termine che viene utilizzato per indicare il lato organizzativo del Disaster Recovery: ruoli, responsabilità e modello organizzativo, che include una precedente analisi d'impatto sul business.

La soluzione Libelle BusinessShadow si occupa sia di HA che di DR. Nel seguito vengono evidenziati gli scenari per entrambi i progetti.

High Availability

Generalmente, gli scenari di High Availability possono portare a potenziali tempi di inattività legati a problemi hardware o a problemi software e/o utente. Nel caso di malfunzionamenti hardware, il tempo di inattività non è solitamente un problema, grazie all'evoluzione della tecnologia che è in grado di fornire sistemi pressoché fault-tolerant.

Comunque, anche se la tecnologia può sopperire alle criticità hardware, gli applicativi possono aver bisogno di più tempo per essere nuovamente e completamente disponibili.

Incidenti legati al software e/o all'utente sono motivo di preoccupazione poiché, spesso, sono i maggiori responsabili dei tempi di inattività. In particolare, con il crescere della complessità delle interdipendenze fra i componenti hardware e software, la disponibilità globale dei sistemi è costantemente a rischio.

WHITE PAPER


In base alia nostra esperienza, possiamo affermare che i sistemi sono al 99,999% lontani dall'essere affidabili.

Disaster Recovery

Oltre ai problemi locali sui server o sui software e/o utente, gli scenari di Disaster Racovery devono tenere conto anche di eventi quali incendi, alluvioni, attacchi terroristici, interruzioni nelle comunicazioni o di corrente.

Disaster Recovery e High Availability sono visti come proporzionali alia loro probabilità di accadere e all'impatto che potrebbero produrre: problemi locali (HA) possono verificarsi abbastanza spesso, ma possono essere risollit abbastanza velocemente con un impatto minimo. D'altro canto, un incident di Disaster Recovery è meno probabile, ma ha un impatto enorme, poiché tutta l'area produttiva non è più disponibile.

Campo di Applicazione per HA e DR

Questo capitolo si focalizza sugli aspetti tecnici delle soluzioni per I'High Availability e il Disaster Recovery. Prima di delineare l'architettura, deve però essere definito in modo chiaro il campo di applicazione del progetto.

Architettura Enterprise IT

Generalmente, il termine Enterprise IT indica l'insieme di differenti infrastrutture, reti, storage e server che fanno da supporto alle applicazioni come, ad esempio, soluzioni ERP in ambito SAP, Oracle, Microsoft, lnfor e molti altri ancora, tipicamente rivolte a centinaia di migliaia di utenti.

Queste applicazioni si interfacciano con database quali IBM DB2, MaxDB, MySQL, Microsoft SQL Server e Oracle, principalmente su server UNIX o Windows

Nell'ottica di un Disaster Recovery, tutti i componenti che fanno da supporto ai processi legati al business devono essere parzialmente o totalmente disponibili in un ambiente alternativo.

L’architettura illustra i componenti critici sia per I'High Availability che per II Disaster Recovery.

WHITE PAPER


Invece, nell'ottica dell'High Availability, entrano in gioco molti altri fattori. Un primo approccio di difesa consiste nel garantire 24 ore al giorno, per 7 giorni, la fornitura di componenti ridondanti.

Molti componenti a medio/alto livello garantiscono una ridondanza interna; in questo modo, un malfunzionamento di una CPU o di un singolo disco passerebbero inosservati.

II secondo passo per I'High Availability è quello di fornire lo stesso componente due volte, anche se è già dotato di una ridondanza interna. Per esempio, una Software Cluster Solution garantisce la capacità di effettuare un server failover in caso di malfunzionamento totale del server.

Unendo questa soluzione con delle storage in mirror in ambito locale e percorsi ridondanti per i collegamenti tra server e storage, il failover verso il nuovo sistema può concludersi in un periodo relativamente breve.

Middleware, database e applicativi diventano relativamente "cluster-aware", in modo che un'applicazione possa essere resa disponibile su un altro hardware in un tempo stimato fra i 5 e i 10 minuti.

Comunque, la ridondanza hardware (HR) non può proteggere dalla causa numero uno dei fermi macchina dovuti a errori utente e al software, come la corruzione dei dati ed errate operazioni di configurazione che si propagano in rete.

Recovery Point Objectives

Sia i progetti di HA, che quelli di DR, si pongono come quesiti la potenziale perdita di dati in caso di incidente (Recovery Point Objective o "RPO") e il tempo necessario per riavere il sistema in linea e funzionante (Recovery Time Objective o "RTO").

La differenza tra HA e DR è che malfunzionamenti locali hanno tipicamente risposte e tempi di failover ridotti in quanto i server sono disponibili localmente nella stessa rete.

I Recovery Point Objectives possono variare da zero in un ambiente di replica sincrono, fino ad un paio di minuti in un ambiente di replica asincrono o quando devono essere inviati i log.

Recovery Time Objectives

II Recovery Time Objective è il tempo necessario affinché l'applicazione venga resa nuovamente disponibile dopo il guasto di un componente. II failover può avvenire automaticamente in un ambiente di HA o in modo parzialmente automatico in un ambiente di DR.

Per uno scenario di HA, l’RTO può essere zero o vicino allo zero se l'applicazione consente di utilizzare componenti ridondanti, come più database servers in un architettura RAC, o più application servers in cui gli utenti si collegano al primo server disponibile.

Comunque, molte applicazioni richiedono un reboot dopo la ripartenza su un server diverso e quindi I'RTO può variare tra i 5 e 15 minuti.

Per uno scenario DR, I'RTO è tipicamente più alto perché un intero centro con sistemi interdipendenti viene mosso verso un nuovo luogo, e in molti casi in un segmento di rete separato.

Con gli hot-standby mirrors è possibile ottenere un Recovery Time Objectives tra 2 e 4 ore, se le procedure e le tecnologie sono in loco.

WHITE PAPER


Recovery Consistency Objectives

Un terzo e più recente traguardo in aggiunta all'RTO e all'RPO è il Recovery Consistency Objective.

L'RCO applica gli obiettivi di consistenza dei dati alle architetture di DR e di HA. In base alle definizioni di RPO e RTO, l’RCO indica la misura della consistenza dei dati distribuita all'interno dei sistemi interconnessi dopo un guasto disastroso. La seguente immagine sottolinea le relazioni tra RPO,RTO e RCO.

RPO = How much data loss? RTO = How much downtime?

RCO = Consistency of business transactions across landscape systems

Replication Basics

II concetto di base di qualsiasi soluzione di replica è garantire copie dei dati critici di produzione e delle applicazioni su uno o più sistemi di mirror nello stesso luogo (High Availability) o in un luogo diverso (Disaster Recovery). In una situazione di emergenza, i sistemi di mirror prendono in carico le applicazioni e gli utenti si possono collegare al sistema di mirror.

Confronto tra Recovery Point, Recovery Time e Recovery Consistency Objectives

La maggior parte della applicazioni sono configurate per avere un nodo attivo e uno passivo.

Ci sono soluzioni di replica attivo/attivo ma, poiché l'applicazione stessa non è disegnata per supportare

questa configurazione, la condizione è attivo/passivo.

WHITE PAPER


Database Layer, File Layer, Storage Layer

Le applicazioni sono principalmente basate su database e file non strutturati (applicazioni binarie, dati di configurazione e qualsiasi dato critico non memorizzato sui database).

Il database stesso è a sua volta basato su files non strutturati che sono gestiti dal software del db.

Ad un livello inferiore, uno storage controller e/o degli storage systems gestiscono come questi files vengono memorizzati e recuperati.

Applichiamo adesso questo modello agli ambienti di replica sincrona ed asincrona e confrontiamo i diversi strati di mirror.

E' fondamentale capire come le applicazioni lavorano e memorizzano i loro dati attraverso i vari strati allo scopo di rendere utilizzabili applicazioni e dati dopo un failover.

La Replica può essere fatta su uno qualunque di questi strati. Un dispositivo di replica degli storage si baserà sui blocchi di Storage, mentre un dispositivo di replica dei file farebbe lo stesso, ma per i files e una soluzione di replica del database si focalizzerebbe sui db.

Replica Sincrona

Per avere una replica sincrona garantita al 100%, il livello sul quale i dati vengono replicati è irrilevante, poiché la sincronizzazione viene comunque propagata fino allo strato applicativo. Questo rende le soluzioni locali di High Availability, come i Server Clusters con storage ridondante, molto diffuse.

Ci sono anche soluzioni come Hardware Cluster (ad esempio, IBM HACMP, HP MC/SG, etc.), Database Cluster (Real Application Cluster, Direct Partitioning Features), Application-based dual-writes di dati o una loro combinazione.

Differenti metodologie di mirror su differenti substrati.

II Database Layer, per esempio, garantisce l'integrità a livello di database, mentre lo Storage Layer

garantisce soltanto l'integrità a livello di Storage.

WHITE PAPER


Per il DR, la Replica Sincrona al 100% molte volte non è raggiungibile (a causa di latenze sulla rete e limitazioni di banda per mirror su grandi distanze) o non è auspicabile (si aggiungerebbe una infrastruttura molto complessa e si avrebbero riduzioni di performance sui sistemi di Produzione). Le architetture DR sono solitamente basate su Repliche Asincrone.

Come per I'High Availability, la replica sincrona non cautela da errori software/utente o dalla corruzione dei dati. Per cautelarsi da questi incidenti, i clienti tendono ad adottare soluzioni in cui il mirror abbia un tempo di ritardo.

Le differenze sono illustrate nella seguente tabella:

Cautelarsi da Replica Sincrona Replica Asincrona

Errori Hardware? Si Si

Errori Software? No Si

Errori Utente/Operativi? No Si

Corruzione dei Dati? No Si

Replica Asincrona

Quando si decide di replicare i dati in modalità asincrona, è fondamentale sapere su quale livello (Applicazione/Database/File/Storage) la replica venga attivata e se sono attive metodologie di consistenza a livello di Applicazione.

Ad esempio, se il livello dei blocchi di storage viene mirrorato in modo asincrono, non verrà fatta una replica consistente a livello di file, di database o di applicazione.

Con una Replica basata sui blocchi di storage e asincrona, è quasi sicuro che il Sistema di Mirror sarà in uno stato di inconsistenza dal punta di vista dell'Applicazione:

Assumiamo che i blocchi di storage vengano mirrorati con punti di consistenza a livello di storage.

I Files sono composti da più blocchi di storage, quindi i files potrebbero essere inconsistenti.

I database sono composti da più files: il database è verosimilmente inconsistente.

Le applicazioni si appoggiano su più database: l'applicazione è verosimilmente inconsistente.

I processi aziendali utilizzano più applicazioni: i processi saranno inconsistenti.

WHITE PAPER


Libelle BusinessShadow®

Libelle BusinessShadow è una soluzione software per mirrorare applicazioni a livello di database (DBShadow®) e di file non strutturati (FSShadow®).

Un modulo aggiuntivo permette di automatizzare I'Application Failover (SwitchApplication) ed esiste un'edizione speciale per gestire Ia Replica tramite WAN (Opzione Long Distance).

BusinessShadow viene utilizzata per l’High Availability, il Disaster Recovery e varie combinazioni di entrambi.

Software Components

Libelle BusinessShadow è un involucro che contiene più componenti dedicati al mirror.

Nel dettaglio, questi componenti sono:

DBShadow fornisce moduli per IBM DB2, MaxDB, Microsoft SOL Server, MySQL, e Oracle. Viene utilizzato per mirrorare i database.

FSShadow viene utilizzato per mirrorare i dati critici che non fanno parte del database come, ad esempio, file di configurazione, dati di interfaccia EDI, o altri files non strutturati specifici dell'applicazione.

SwitchApplication viene utilizzato per attivare e disattivare gli indirizzi IP e application-specific failover tasks.

L'opzione Long Distance estende la funzionalità base di mirror del componente DBShadow e del componente FSShadow per supportare le impostazioni Wide Area Network.

Tutti i componenti sono disponibili per differenti sistemi operativi, come HP-UX, IBM AIX, Solaris, Tru64 UNIX, la maggior parte delle distribuzioni di Linux e tutte le piattaforme Windows.

La maggioranza delle implementazioni di Libelle AG mirrorano applicazioni di SAP AG con un'edizione Speciale di BusinessShadow per soluzioni SAP e un'integrazione Certificata SAP. Altre implementazioni

I component di Libelle BusinessShadow

WHITE PAPER


includono Oracle, Microsoft Dynamics, Soluzioni ERP che si appoggiano su soluzioni di lnfor Global e molte altre applicazioni.

Solution Design

DBShadow e FSShadow

Le architetture dei principali componenti di BusinessShadow, DBShadow e FSShadow, sono definite in modo che ogni singolo mirror si appoggi su un Sistema di Produzione e uno o più sistemi di Mirror.

Dopo che un sistema viene replicato su un altro con una "Copia iniziale", un processo di Archiviazione (Archiver} prende dal sistema di Produzione i file di database, e che non sono cambiati, e li spedisce verso il sistema di Mirror usando il TCP/IP di Libelle.

L'Archiver viene configurato secondo i requisiti dell'applicazione e tenendo conto dei Recovery Point Objectives stabiliti in fase di analisi. Può essere configurato in modo che, ad esempio, i dati vengano collezionati e inviati ogni 5 o 10 minuti.

Un processo di recovery attivo sul sistema di mirror si occupa di applicare quanto riceve dall'Archiver per aggiornare il database (DBShadow) o il file system (FSShadow).

Tutti i processi possono operare in modo indipendente, nel caso uno o l'altro sistema non fosse temporaneamente disponibile, ricominciando a collezionare i dati non appena il link viene ristabilito, ma generalmente dipendono l'uno dall'altro, ed è questa interazione a permettere di coordinare in modo coerente le fasi di HA e DR.

II software stesso si basa sui Server Agents a basso livello (Shared Memory per Unix, Servizi per Windows) che risiedono su ciascun host.

Gli Agents comunicano l'un l'altro tramite sockets di rete specializzati.

Una interfaccia utente grafica (GUI) permette di intercettare le comunicazioni e gestire uno o più mirrors dell'applicazione.

I server Agents di DBShadow e FSShadow comunicano l'uno con l'altro e con una GUI che permette una

gestione centralizzata e il monitor delle operazioni.

WHITE PAPER


L'operazione giornaliera di replica è quindi basata sui processi di Archiver e Recover sempre attivi e monitorati dalla GUI. In caso di irregolarità, vengono prodotti dei log che il server invia alla GUI e/o ad altri tools di Gestione del Sistema.

Opzione Long Distance

Un componente aggiuntivo di BusinessShadow è l'opzione Long Distance per estendere il trasferimento dei dati compressi via TCP/IP con un'ulteriore compressione, parallelismo e configurazione, in modo da poter gestire grandi distanze tra un sistema di produzione e un sistema di mirror che presentano tipicamente grandi tempi di latenza sulla rete.

SwitchApplication

Infine, il componente SwitchApplication può gestire il failover dell'indirizzo IP tra i due sistemi, in modo che un Hostname virtuale o un indirizzo IP presente sul sistema di Produzione venga mosso sul sistema di Mirror come parte del processo di failover.

Graphical User Interface (GUI) Management Console

Libelle fornisce all'amministratore un'interfaccia grafica che comunica con un qualsivoglia numero di Server Agents.

La GUI è il componente centrale per configurare, controllare e operare i mirrors. Inoltre, fornisce una semplice interfaccia grafica per gestire i failovers di emergenza o i test di Disaster Recovery.

La GUI si occupa quindi solo del monitoraggio e del controllo delle operazioni e non prende parte attiva al processo di replica.

I Server Agents Libelle agiscono in modo indipendente; possono inviare degli SMTP traps o altri messaggi e possono essere gestiti anche dalla riga di comando.

Lo SwitchApplication permette di aggiungere e rimuovere IP virtual Hostname automaticamente in caso

di fallover.

WHITE PAPER


Scenari di High Availability

BusinessShadow per I'High Availability può fornire un sistema di mirror replicato in locale per qualsiasi sistema in produzione. II software può essere usato come una soluzione di failover senza perdita di dati verso un sistema di Mirror con storage condivisa, o come una soluzione con un minimo di perdita di dati in caso contrario.

L'implementazione principale di BusinessShadow per I'HA si basa sul concetto di mirror ritardato nel tempo per garantire la protezione da errori software e utente.

In questo caso, l'architettura si basa su un mirror tra I due sistemi intenzionalmente ritardato nel tempo. I cambiamenti del sistema di Produzione vengono applicati al sistema di Mirror con un ritardo, ad esempio, di 2 o 4 ore, allo scopo di permettere un intervallo di reazione in caso di corruzione causata da errori software, errori utente, errori di configurazione, esecuzioni non corrette o non pianificate di Aggiornamenti di Sistema e altre situazioni che possono portare a dati corrotti o non utilizzabili.

BusinessShadow GUI

Questo esempio visualizza sei gruppi sulla sinistra, con II gruppo "Production" nel mezzo.

Ogni gruppo gestisce più mirror. I segni di spunta verdi indicano uno stato ok. La X rossa mostra gli errori

(ad esempio, database non attivo).

I punti esclamativi gialli indicano i warning (ad esempio, lo spazio su disco esaurito).

WHITE PAPER


In questo modo, se un errore software o un errore utente ha corrotto il database del Sistema di produzione, il database di Mirror è quattro ore in ritardo e ha una coda di quattro ore in attesa per il file System. Per una restore veloce, I'Amministratore userà la BusinessShadow GUI o l'interfaccia della Shell per attivare un recovery automatico fino ad un momento antecedente l'istante in cui si è generato l'errore.

Normalmente, applicare quattro ore di recovery comporta un attesa di circa 20 minuti, a seconda delle prestazioni garantite dall'hardware. Paragonando questa alternativa ad un full restore da nastro, questa metodologia è la più rapida possibile.

Generalmente, possiamo individuare il Recovery Time Objectives (tempo di failover), che include la ripartenza dell'applicazione, in circa 25-40 minuti in caso di un sistema di Produzione corrotto da errori Software o utente con un ritardo di sincronizzazione di 4 ore.

DBShadow e FSShadow durante il funzionamento normale.

Le transazioni vengono accodate sul sistema dl Mirror prima di essere applicate, in modo da garantire

una finestra dl reazione per i dati corrotti.

DBShadow e FSShadow durante il funzionamento in situazione di emergenza causata dai dati corrotti.

Il Sistema di Mirror garantisce che l'applicazione sia in uno stato consistente con i dati a prima

del momento in cui si è generato l'errore.

WHITE PAPER


Per implementazioni che non prevedono tempi di ritardo, il Recovery Time Objectives è tipicamente meno di 10-15 minuti.

II Recovery Point Objectives (perdita di dati) varia in base al tempo di ritardo. Per un errore software, la nostra intenzione è di tornare indietro nel tempo, ad esempio, dagli ultimi cinque minuti fino a 4 ore.

Una volta che l'amministratore di Libelle ha deciso l'istante a cui riportare il sistema, tutti i task legati al database (recovery, rinomina del database, tablespaces gestiti localmente, etc...) vengono completamente automatizzati.

Per un failover senza perdita di dati, gli ultimi 5 o 10 minuti di Logs che non possono essere inviati, vengono posti in uno storage condiviso a cui il Sistema di Mirror può accedere.

Scenari di Disaster Recovery

La seconda applicazione di BusinessShadow è di rappresentare a tutti gli effetti una soluzione per il Disaster Recovery.

I Server Agents, che hanno un basso impatto sull'uso delle risorse del sistema e il basso utilizzo delle risorse di rete, rende questa soluzione adatta a mirrorare qualsiasi ambiente su un sistema remoto.

Le installazioni di Libelle per il Disaster recovery vanno dal mirror di una singola applicazione con, ad esempio, 400 GB mirrorati su una rete VPN 3Mbit/s, fino a 20-30 TB con dozzine di applicazioni mirrorate attraverso un link dedicato ad una rete WAN 100 Mbit/s.

La metodologia è simile all'implementazione dell'High Availability, tranne per il fatto che il tempo di ritardo è meno significativo. L'Archiver è solitamente configurato per rispondere ad un dato Recovery Point Objectives (perdita di dati al massimo di 10-15 minuti in caso di guasto), ma anche in modo da non creare problemi di performance sul sistema di Produzione (l'aggiornamento sincrono del sistema di mirror richiederebbe troppe risorse sia sulla rete che sui server).

In entrambi i casi, con BusinessShadow che si occupa del mirror delle scenario applicativo per un numero qualsiasi di Sistemi, si ottiene un Sistema in stand-by per il Disaster Recovery costantemente aggiornato nello stesso luogo dove si trova il sistema in produzione. II failover durante le situazioni di emergenza e i test annuali di Disaster Recovery sono altamente automatizzati.

Integrazione nelle soluzioni SAP

L'impegno di Libelle nel mercato SAP

Libelle offre la sua soluzione software rivolta al mercato di SAP dalla fine degli anni 90. Il primo database supportato è stato la versione 6 di Oracle e, poiché la società ha sede in Germania, ha accesso ad un numero elevato di clienti SAP.

Dopo aver aggiunto il supporto per DB2, MaxDB e SOL Server, Libelle fornisce supporto a tutti gli ambienti SAP più diffusi.

Nel 2005, Libelle ha esteso il suo interesse verso iI mercato SAP con un’integrazione certificata per SAP NetWeaver. Le applicazioni SAP ora rappresentano l'80% del clienti di Libelle.

WHITE PAPER


Nel 2009, Libelle ha acquisito un interesse di maggioranza in una azienda di consulenza su SAP con sede in Germania per incentivare la sua esposizione sui mercato di SAP.

Requisiti per SAP

Con l'ultima architettura NetWeaver, SAP AG fornisce un servizio altamente raffinato.

Funzionalità aggiuntive hanno aumentato l'alto grado di complessità nel disegno tecnico e nel funzionamento, specialmente se raffrontato al precedente SAP R/3, basato su un'installazione ABAP (Advanced Business Application Programming) con una o due istanze SAP.

A meno che non implementiamo una replica sincrona al 100%, qualsiasi soluzione di replica che non dipenda dall'applicazione (ad esempio, replica block-based) e che non sia strettamente integrata nell'architettura SAP NelWeaver, è condannata a causare problemi in caso di failover.

Anche le soluzioni basate solo sui database (spostamento dei Log) trascureranno una gran parte di dati memorizzati in files non strutturati e questo comporterà una serie di problemi nell'ottenere una soluzione attiva e funzionante sul sistema di Mirror.

II seguente schema mostra come Libelle BusinessShadow sia integrato in una singola istanza SAP. Mentre la figura mostra un sistema in Produzione come nodo singolo, la maggior parte dei clienti ha sistemi basati su cluster a due nodi.

BusinessShadow: integrazione in una tipica istanza SAP.

WHITE PAPER


La Tecnologia di BusinessShadow

Core Server Agents

I componenti centrali di Libelle BusinessShadow si basano sui Server Agents che girano sul sistema di produzione e sul sistema di Mirror.

Gli Agents di Libelle sono scritti in C e C++, girano come processi di Shared Memory su Unix e come Servizi in Windows.

Nella versione 1.0 di DBShadow per Oracle, sviluppata nel 1996, gli agents erano demoni basati sui socket del TCPIP. Oggi, le versioni 4.5, 4.8 e 5.x, contengono 15 anni di sviluppo e di miglioramenti, e funzionano su oltre 1000 installazioni piccole, medie e grandi, mirrorando database a partire da 1OOGB per arrivare a 18TB, sia in installazioni con una sola istanza o con scenari che prevedono più di 50 server, con qualsiasi versione di Unix e Windows

I Server Agents gestiscono le comunicazioni tra i due sistemi e vengono controllati mediante comandi diretti o interfaccia grafica. Mantengono le informazioni relative alle attività correnti presenti nella Shared Memory alla quale possono accedere entrambi i sistemi.

Ogni processo contiene dei "main processes" che lanciano, arrestano o gestiscono dei "Son Processes", i quali, a loro volta, eseguono task specifici. Ad esempio:

DBShadow per il processo Archiver in ambiente HP-UX lancia, arresta e controlla il processo di copia dei log file di Oracle 11i log file verso il proprio Sistema di Mirror.

DBShadow e FSShadow Server Agents comunicano tramite i propri socket.

La figura mostra i processi di "Initial Copy", "Archiver" e "Structure" sul sistema di Produzione e il

processo di "Recover'' sul sistema di Mirror.

Dopo un Failover, i ruoli vengono rovesciati e la replica va in direzione opposta.

WHITE PAPER


DBShadow per il processo di Recover in ambiente Windows applica e controlla il processo di recovery dei Log Files di Backup delle transazioni con un determinato ritardo di tempo nel proprio Sistema di Mirror.

FSShadow per il processo di Archiver in ambiente IBM AIX verifica la lista dei files non strutturati sul sistema di Produzione ogni 20 minuti e copia quelli modificati verso il proprio Sistema di Mirror.

DBShadow per il processo Structure in ambiente Solaris controlla il database Oracle per quanto riguarda le transazioni no-logging, nuovi files di dati, nuove directory e aggiorna il Sistema di Mirror.

DBShadow per il processo di Recover in ambiente IBM AIX effettua un Recovery aggiornato per un database DB2 al memento del failover.

I Server Agents devono girare 24 ore per 7 giorni, 365 giorni all'anno e sono studiati per sopravvivere ai riavvii del server, alle interruzioni di rete o a qualsiasi altro disturbo che si può crearsi su una LAN o WAN.

Nei paragrafi successivi entreremo più nel dettaglio dei processi e su come interagiscano con l'ambiente per configurare un sistema di replica.

La figura mostra uno screenshot della Shared Memory preso da un sistema di Mirrror.

La stessa informazione può essere ottenuta mediante comando shell.

Le informazioni sono accessibili per entrambi i sistemi.

WHITE PAPER


Database Mirroring

La replica del database con Libelle DBShadow si basa sui seguenti punti:

Creare una copia iniziale di un database di produzione sul sistema di Mirror.

Ad intervalli configurabili, ad esempio, ogni 10 minuti, controllare il database di Produzione per verificare i cambiamenti dei files di Log fuori linea e spedirli al sistema di Mirror con un processo Archiver.

Applicare in continuazione i cambiamenti dal database di produzione nel database di Mirror con un ritardo di tempo configurabile.

Ad intervalli di tempo configurabili, per esempio, ogni 2 ore, verificare la presenza di nuovi file dati per il database di Produzione, transazioni no-logging, nuove direttrici e aggiornare II database di Mirror con i cambiamenti riscontrati.

Tutti i processi DBShadow possono agganciare differenti database, comunicare e funzionare in base alla struttura del database. Un processo di archiviazione per Oracle lavora in modo differente rispetto a quello per MS SOL Server, etc...

Lo stesso vale per la copia iniziale, il Recover e la struttura dei srocessi in operazioni di replica normale e di failover in caso di emergenza, dove il sistema di Mirror viene attivato da BusinessShadow.

l processi "lnitialCopy", "Archiver" e "Recover" interagiscono con un sistema di produzione e di mirror.

Un ulteriore processo "Structure" testa il database di Produzione e coordina gli aggiornamenti alla

Struttura per il database di mirror con il processo di Recover.

WHITE PAPER


Mirroring dei files non strutturati

II mirroring dei files non strutturati funziona in modo analogo al mirror del database.

II componente FSShadow deve preoccuparsi del mirror dei files non strutturati per tutti i files definiti nel processo o aggiunti in seguito.

Inizialmente, mediante una copia iniziale, i files vengono replicati sui sistema di Mirror.

Successivamente, un processo di Archiviazione controlla il File System del sistema di Produzione ad intervalli configurabili, per esempio ogni 30 minuti o ogni 5, in base al progetto, alle necessità dei clients e a considerazioni di prestazioni.

Infine, un processo di Recovery gestisce il recovery dei files nel Sistema di Mirror.

Come per DBShadow, l'architettura ha un ritardo di tempo configurato. I files non strutturati non saranno applicati non appena vengono scaricati sui sistema di Mirror, ma dopo un periodo definito a priori in fase di configurazione, ad esemplo, 4 ore.

Questo permette di avere una finestra di reazione in caso di corruzione sia in caso di High Availability, sia di Disaster Recovery.

DBShadow Archiver per database Oracle.

WHITE PAPER


Wide Area Network Enhancements: Option Long Distance

Entrambi i componenti, DBShadow per i database e FSShadow per i files non strutturati, permettono un'estensione dei servizi di comunicazione di base con caratteristiche speciali per le WAN (Wide Area Network) chiamata "Option Long Distance".

Generalmente, i problemi che si pongono con un ambiente di replica in WAN rispetto ad uno in LAN sono tipicamente una drastica riduzione della larghezza di banda disponibile, reti instabili e una latenza di rete molto alta con distanze maggiori a 50 miglia.

Per risolvere questi inconvenienti, I'Opzione Long Distance adatta gli stacks base del TCP/IP di Libelle con estensioni configurabili che includono:

High Compression: aggiungendo altra compressione alla compressione standard prima che i dati vengano spediti.

Parallel Archive Shipping: i files di log singoli vengono inviati in parallelo. Per esempio, un Log File di 200MB può essere diviso in più pacchetti dati che possono essere inviati in parallelo al sistema di Mirror e poi gestiti dal database di Mirror.

Very Large Packets Technology: l'opzione aumenta la dimensione del pacchetto TCP/IP di default. Le dimensioni standard dei pacchetti sono orientate verso le LAN e spesso inadatte per le WAN.

Il componente FSShadow.

WHITE PAPER


Application Failover

Libelle BusinessShadow mette a disposizione tre componenti per un Application Failover in caso di emergenza:

I processi di Recover Libelle DBShadow e FSShadow in Emergency Mode per completare in modo automatico tutti i tasks di failover per il datatabse e per i files non strutturati.

Libelle SwitchApplication per aggiungere o rimuovere in modo automatico gli hostname dei server e gli indirizzi IP da/in un sistema di Mirror o in un sistema di Produzione.

L'interfaccia utente per Libelle DBShadow, FSShadow, e SwitchApplication per automatizzare i tasks predefiniti durante il failover.

Recover Process In Emergency Mode

Durante la procedura di replica normale, i processi DBShadow e FSShadow possono applicare i cambiamenti che ricevono dal processo Archiver nel database di Mirror o nel File System di Mirror.

Durante una situazione di emergenza, dove è necessario attivare, dopo un failover, il sistema di Mirror, lo stesso processo di Recover opererà in "Emergency Mode" garantendo automaticamente che il sistema di Mirror si trovi nella stato adatto per prendere in carico l'ambiente di produzione.

Per il failover del database, DBShadow include tutti i task relativi al database e include anche, ad esempio, il Point-In-Time Recovery automatico ad un timestamp configurabile. Inoltre, DBShadow applicherà tutti i files di log che non sono ancora stati applicati.

II processo di Recovery permette anche uno switch di ruoli automatico tra Produzione e Mirror in caso di failover pianificato per la maggior parte dei database (per Oracle, ad esempio, potrebbe prendere i rimanenti Online Logs dalla produzione e aprire il mirror con l'opzione "no reset logs" per non perdere le transazioni iniziate). Infine, il processo rinomina automaticamente il database con il nome del database di Produzione e, se necessario, esegue dei tasks addizionali.

II failover dei files non strutturati con FSShadow opera in modo simile. Con un ritardo di tempo configurato, il client può specificare un timestamp fino al quale i files devono essere recuperati e quindi garantire al sistema di Mirror la struttura voluta.

WHITE PAPER


Libelle SwitchApplication

Un'altra parte essenziale del failover su uno o più sistemi è quella di attivare automaticamente gli indirizzi IP e gli Hostnames sul sistema di Mirror e, se richiesto, rimuoverli prima dal sistema di Produzione.

Libelle SwitchApplication è un prodotto software che si basa sui Server Agents e su un'interfaccia utente grafica per gestire più sistemi. I Server agents possono interagire con un sistema in modo da aggiungere o rimuovere ulteriori hostname virtuali e indirizzi IP virtuali, sia su server Unix che su server Windows.

II processo di aggiungere e rimuovere questi nomi di indirizzi non richiede il riavvio del server. II tool viene gestito e innescato dai clients o dai processi di failover DBShadow e FSShadow.

SwitchApplication può essere installato sia sul sistema di produzione che sul sistema di mirror.

La maggior parte dei clienti comunque ha già implementato un Cluster Software sui sistemi di produzione, quindi SwitchApplication dovrebbe essere installato solo sul sistema di Mirror per attivare l'indirizzo IP una volta che questo stesso indirizzo non fosse più disponibile sul sistema di Produzione.

Affinché SwitchApplication sia operativo, è necessario che sia il sistema di produzione che quello di Mirror siano nella stessa rete, perché SwitchApplication non esegue alcun controllo sulle tabella di routing o sui DNS.

La parte alta dello schermo mostra le opzioni di failover.

l cerchi verdi rappresentano i files di log con la percentuale di disco usata.

La GUI visualizza l'ora corrente di ogni server e, sulla sinistra, la lista dei mirrors.

WHITE PAPER


Per il Disaster Recovery, il cliente potrebbe anche implementare una LAN virtuale con la stessa subnet. Se questo non fosse possibile, i sistemi possono risiedere in reti separate e !'Application Failover viene attivato, ad esempio, aggiornando II DNS.

La figura sotto mostra un’implementazione di BusinessShadow con SwitchApplication installato sui sistemi di Produzione e Mirror per sistemi standalone e implementato sui sistemi di Mirror per sistemi di Produzione Clustered.

Failover e altre interfacce utente

Tutti i componenti di BusinessShadow sono provvisti di un vasto set di interfacce utente configurabili che all'inizio dell'implementazione sono vuote.

Una tipica installazione standard, con un solo mirror, richiede soltanto integrazioni addizionali secondarie come l'automatismo del failover. Un'implementazione multi-mirror comunque è spesso estesa con una struttura di interfacce utente dove un mirror principale inizia automaticamente il failover di un gruppo di applicazioni correlate o di altri sistemi.

Le interfacce utente possono eseguire dei Task fuori linea (ad esempio, scripts) o Tasks in linea (eseguire uno script con opzioni di feedback) e possono risiedere sia sui sistemi di Produzione che sui sistemi di Mirror.

I task possono essere eseguiti localmente (agiscono sullo stesso server dove sono definiti) o in modalità remota (azioni innescate sui sistemi di Mirror).

Un'interfaccia utente centrale innescata durante, prima, o dopo DBShadow o FSShadow, completa i tasks di failover. L'integrazione può essere semplicemente o l'innesco diretto di altri failovers di sistemi o una pianificazione sofisticata di test e di task per i failovers che normalmente venivano effettuati manualmente.

BusinessShadow multi-system SAP landscape.

WHITE PAPER


Graphical User Interface (GUI)

Libelle BusinessShadow GUI è il punto centrale dove tutte le configurazioni DBShadow e FSShadow vengono definite, controllate, monitorate e gestite. La GUI è un'applicazione JAVA e viene solitamente installata su una workstation. Tramite la GUI si possono configurare e attivare uno o più mirrors.

La parte più in basso della schermata mostra il setup della configurazione diviso in "Copy", "Archiver", "Recovery" e "Structure" come discusso nei capitoli precedenti. "Alarm" è la configurazione di come i Server Agents devono reagire in caso di disturbi e se errori o warnings devono essere inviati via email o SMTP. Dopo che le configurazioni del mirror sono state definite, il passo successivo è quindi di permettere il monitoraggio di più sistemi, come mostrato nella figura seguente.

BusinessShadow Configure Menu.

BusinessShadow Monitoring.

WHITE PAPER


Sommario

Questo documento evidenzia in dettaglio differenti metodi per il mirroring, sia per l'High Availability che per il Disaster Recovery.

Libelle BusinessShadow consente di ottenere il più alto livello di consistenza del database/applicazione, poiché i dati vengono mirrorati tenendo conto di tutte le più diffuse tecnologie utilizzate dai database presenti sul mercato.

D'altro canto fornisce una soluzione completa per il mirror di differenti database su differenti piattaforme e offre una soluzione sofisticata per il mirror dei files non strutturati.

Tutte le soluzioni Libelle si basano su concetti di implementazione e modello operativo così sofisticati da potersi adattare a qualsiasi grado di complessità, da un'installazione per un solo mirror fino a scenari con più di 100 servers.

Su richiesta del Cliente, i nostri consulenti sono in grado di valutare lo scenario che viene sottoposto per delineare una soluzione specifica, l'implementazione conseguente e l'approccio operativo più adatto alle specifiche esigenze.

© Libelle and the Libelle Logo are trademarks of Libelle AG, Germany and other countries. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or a SAP affiliate company) in Germany and other countries. All other products and service names mentioned are the trademarks of the respective companies.

White paper Libelle BusinessShadow - wssitalia.it · WHITE PAPER Libelle BusinessShadow® - High...

Documents

Transcript of White paper Libelle BusinessShadow - wssitalia.it · WHITE PAPER Libelle BusinessShadow® - High...