Pianifica flessibilità

La società o l'organizzazione dispone di requisiti specifici per l'integrazione dei dati di un nuovo client. Pianificare un'architettura di integrazione che soddisfi i propri requisiti prima di iniziare a progettare i dettagli.

Determinare i requisiti di flessibilità

Prima di tutto ciò che rende il resiliente dell'ambiente, è necessario definire in primo luogo il significato per la flessibilità e la tua attività. In altre parole, qual è il costo associato all'indisponibilità dei processi di integrazione?

Per alcuni clienti, un'indisponibilità di alcuni minuti è accettabile e ritarda solo parzialmente un processo batch eseguito correttamente nella finestra di elaborazione. Per altri clienti, anche per alcuni secondi di indisponibilità si ottengono perdite finanziarie che hanno un impatto diretto sull'attività.

Da tale prospettiva, è importante controllare gli elementi riportati di seguito.

  • Qual è la durata di un'indisponibilità accettabile nell'ambiente in uso? Qui è consigliabile definire il costo per l'attività in caso di indisponibilità e indicare in che modo l'indisponibilità si evolve con la durata dell'indisponibilità.
  • Quali sono le tecnologie utilizzate e in che modo possono essere fornite sul livello di servizio previsto? Si sta utilizzando un approccio in tempo reale o batch? Oppure una combinazione dei due? Quanti dati vengono elaborati?

Definizione di un'architettura resiliente

La definizione di un'architettura resiliente richiede la ricerca della soluzione di integrazione dati end-to-end.

Nel caso di un processo di integrazione, è necessario considerare i seguenti componenti dell'architettura (sia hardware che software):

  • Resilienza del sistema di origine
  • Resilienza del sistema di destinazione
  • Resilienza dell'area intermedia se utilizzata
  • Resilienza degli strumenti di integrazione dei dati
  • Resilienza dell'orchestrazione (se al di fuori dello strumento ETL)
  • Resilienza della rete (sia dalla prospettiva di connettività che dalla prospettiva di larghezza di banda)

È inoltre necessario considerare i requisiti in termini di disaster recovery e High Availability. Che cosa accade se si perde il data center in cui è installata questa infrastruttura?

Per garantire che l'installazione di Oracle Data Integrator sia resiliente, sono necessari gli elementi riportati di seguito.

  • Gli agenti devono essere ridondanti: gli agenti JEE sono progettati per garantire la resilienza in quanto un load balancer distribuirà il carico tra gli agenti.
  • Il repository di Oracle Data Integrator deve essere in esecuzione su un sistema resiliente: un'installazione di Oracle RAC o Exadata richiede un requisito minimo, in modo che la perdita di un nodo non indichi la perdita completa dell'infrastruttura. Per le distribuzioni di Oracle Cloud, Oracle Database Exadata Cloud Service offre una soluzione resiliente.
  • Se si utilizza un prodotto esterno per orchestrare i processi Oracle Data Integrator (ad esempio Oracle Integration ), è necessario accertarsi che anche questo prodotto sia resiliente.

Se si sta prendendo in considerazione una strategia di disaster recovery, gli stessi elementi descritti in precedenza sono obbligatori, pertanto è necessario accertarsi che:

  • Si dispone di una copia (sufficiente recente) del repository Oracle Data Integrator nel sito DR per poter continuare a eseguire i processi Oracle Data Integrator.
  • In tale sito DR sono disponibili agenti Oracle Data Integrator per l'accesso a questo repository.
  • È possibile accedere ai sistemi di origine e target oppure a una copia dei sistemi di origine e target.

Per Oracle Data Integrator in modo specifico, saranno disponibili due elementi di topologia da convalidare:

  • L'indirizzo IP o il nome server del repository di lavoro di Oracle Data Integrator viene memorizzato nel repository master di Oracle Data Integrator. Se il nome o l'indirizzo IP cambia quando si passa al sito DR, è necessario assicurarsi che queste informazioni vengano aggiornate prima di avviare Oracle Data Integrator.
  • L'indirizzo IP o il nome server per i sistemi di origine e di destinazione sono memorizzati nel repository di lavoro. Le strategie possibili sono due:
    • Definire contesti separati per ogni ambiente (principale e DR) che consenta di avere due definizioni di server fisico distinte per ogni unità logica.
    • In alternativa, sovrascrivere l'indirizzo IP o i nomi server prima di avviare Oracle Data Integrator nel sito DR.
  • In tutti i casi, per ripristinare le informazioni nel sito primario è necessario che lo script che utilizza il kit SDK per sovrascrivere le informazioni nei repository di Oracle Data Integrator.

Pianifica caricamenti iniziali e riusciti

Per poter concentrarsi sui caricamenti regolari, ad esempio vicino ai batch in tempo reale o giornalieri, è necessario progettare un processo leggermente diverso per il caricamento iniziale del sistema di destinazione.

Questo ha spiegato se si desidera proteggersi da indisponibilità future non adatte, è fondamentale mantenere e gestire questi processi di caricamento iniziali. La possibilità di eseguire di nuovo un caricamento iniziale (o caricamento iniziale parziale) non deve mai essere valutata in particolare nelle situazioni riportate di seguito.

  • Viene trovata una modifica grave nella validità dei dati caricati (dati mancanti, formula non valida in ETL e così via).
  • L'indisponibilità principale si verifica sul sistema di destinazione causando una perdita elevata di dati.
  • L'esecuzione dei processi di integrazione non riesce per un periodo troppo lungo.

Grazie alla possibilità di eseguire i caricamenti iniziali at-will, la possibilità di creare istanze di nuovi ambienti.

È inoltre possibile migliorare queste strategie di caricamento con la possibilità di applicare di nuovo un caricamento precedente, ad esempio un mese precedente di dati. Ciò richiede una combinazione di cleanup parziale dei dati caricati e anche un caricamento parziale.