Usa replica a blocchi sincroni remoti su Oracle Cloud Infrastructure

Fornire tolleranza agli errori dei volumi a blocchi utilizzando la replica a blocchi sincrona remota.

Le sfide tipiche per molte aziende includono: applicazioni in esecuzione su un database, applicazioni che accedono ai dispositivi a blocchi sottostanti e un requisito aziendale per zero ritardi nei servizi.

Prendiamo ad esempio le società di elaborazione dei pagamenti. Poiché un ritardo nell'elaborazione dei pagamenti influisce negativamente sulla reputazione e sul marchio agli occhi dei loro clienti, devono disporre di una tecnologia ad alta disponibilità per fornire una vera tolleranza agli errori (ovvero, zero interruzioni del servizio in caso di guasto di un singolo componente).

Architettura

Questa architettura implementa un dispositivo a blocchi ad alta disponibilità su Oracle Cloud Infrastructure (OCI), completamente tollerante a un errore a livello di applicazione aziendale. Utilizzare questa architettura per applicazioni sensibili alle prestazioni che richiedono contemporaneamente continuità.

Questa architettura fornirà agli utenti una singola entità, un dispositivo a blocchi iSCSI. Questo dispositivo sarà sempre disponibile, indipendentemente dagli errori di un singolo componente. Tutti gli altri componenti dell'architettura verranno nascosti agli utenti. L'architettura è completamente automatizzata in caso di guasto o switchover. L'unico effetto che gli utenti noteranno in caso di guasto o switchover sarà il deterioramento delle prestazioni del dispositivo iSCSI di circa il 50% per uno o due secondi.

L'implementazione di un singolo dispositivo a blocchi sempre disponibile richiede quanto segue.

  • Tre istanze di computazione, virtual machine o Bare Metal (BM). Questi ultimi possono essere preferibili in quanto hanno prestazioni stabili.
  • Due VCN: una pubblica, una privata.
  • Due volumi a blocchi del dispositivo di destinazione sempre disponibile.
  • (Consigliato) Impostare almeno 10 VPU per i volumi a blocchi. Si consiglia di prendere in considerazione un livello di IOPS ancora più elevato, a seconda dell'aggressività del throughput di I/O e della distanza tra gli host con mirroring (e i volumi a blocchi).

Pertanto, il costo dell'implementazione di un dispositivo a blocchi sempre disponibile è tre volte superiore al costo dell'istanza di computazione e due volte superiore al costo del dispositivo stesso.

Il seguente diagramma illustra questa architettura di riferimento.



remote-synchronous-block-replication-diagram-oracle.zip

L'architettura presenta i seguenti componenti:

  • Dispositivo a blocchi replicato distribuito

    Distributed Replicated Block Device (DRBD) è un driver kernel Linux che gestisce la connessione di rete tra due dispositivi a blocchi su istanze Linux remote e replica le operazioni di I/O dall'istanza di origine all'istanza di destinazione.

  • Pacemaker

    Pacemaker è un gestore di risorse cluster open source ad alta disponibilità, comunemente utilizzato in ambienti Linux. Garantisce l'esecuzione continua di applicazioni, servizi o risorse con tempi di inattività minimi rilevando gli errori e riavviando o riposizionando automaticamente i servizi su altri nodi in un cluster.

  • Corosincroni

    Corosync è un software open source che estende Pacemaker con semantica di restauro nel caso di cervello diviso.

  • Responsabile avvio e destinazione iSCSI

    iSCSI è un componente software client e server che fornisce un dispositivo SCSI su una rete.

Suggerimenti

Utilizzare i seguenti suggerimenti come punto di partenza per <riposo della frase.> I requisiti potrebbero differire dall'architettura descritta qui.
  • VCN

    Quando crei una VCN, determina il numero di blocchi CIDR necessari e la dimensione di ciascun blocco in base al numero di risorse che intendi collegare alle subnet nella VCN. Utilizzare i blocchi CIDR all'interno dello spazio di indirizzi IP privati standard.

    Selezionare i blocchi CIDR che non si sovrappongono a qualsiasi altra rete (in Oracle Cloud Infrastructure, nel data center on premise o in un altro provider cloud) a cui si intende impostare connessioni private.

    Dopo aver creato una VCN, puoi modificarne, aggiungerne e rimuoverne i blocchi CIDR.

    Quando si progettano le subnet, considerare il flusso di traffico e i requisiti di sicurezza. Collega tutte le risorse all'interno di un livello o ruolo specifico alla stessa subnet, che può fungere da limite di sicurezza.

  • Cloud Guard

    Duplica e personalizza le ricette predefinite fornite da Oracle per creare ricette personalizzate del rilevatore e del rispondente. Queste ricette consentono di specificare il tipo di violazione della sicurezza che genera un'avvertenza e le azioni consentite per l'esecuzione. Ad esempio, potresti voler rilevare i bucket di storage degli oggetti con visibilità impostata su Pubblico.

    Applica Cloud Guard a livello di tenancy per coprire l'ambito più ampio e ridurre l'onere amministrativo legato alla gestione di più configurazioni.

    È inoltre possibile utilizzare la funzione Lista gestita per applicare determinate configurazioni ai rilevatori.

  • Zone di sicurezza

    Per le risorse che richiedono una maggiore sicurezza, Oracle consiglia di utilizzare le zone di sicurezza. Una zona di sicurezza è un compartimento associato a una ricetta definita da Oracle dei criteri di sicurezza che si basano sulle best practice. Ad esempio, le risorse in una zona di sicurezza non devono essere accessibili dalla rete Internet pubblica e devono essere cifrate utilizzando chiavi gestite dal cliente. Quando crei e aggiorni le risorse in una zona di sicurezza, Oracle Cloud Infrastructure convalida le operazioni in base ai criteri nella ricetta della zona di sicurezza e nega le operazioni che violano uno qualsiasi dei criteri.

  • Gruppi di sicurezza di rete (NSG)

    Puoi utilizzare i gruppi NSG per definire un set di regole in entrata e in uscita che si applicano a VNIC specifiche. Si consiglia di utilizzare i gruppi NSG anziché gli elenchi di sicurezza, poiché i gruppi NSG consentono di separare l'architettura della subnet della VCN dai requisiti di sicurezza dell'applicazione.

  • Larghezza di banda del load balancer

    Durante la creazione del load balancer, puoi selezionare una forma predefinita che fornisca una larghezza di banda fissa oppure specificare una forma personalizzata (flessibile) in cui impostare un intervallo di larghezza di banda e consentire al servizio di ridimensionare automaticamente la larghezza di banda in base ai pattern di traffico. Con entrambi gli approcci, puoi modificare la forma in qualsiasi momento dopo aver creato il load balancer.

Considerazioni

Quando si distribuisce questa architettura di riferimento, tenere presente quanto riportato di seguito.

  • Prestazioni

    Dovresti pianificare due volte N di IOPS nominali sul tuo dispositivo sempre disponibile per fornire N IOPS ai tuoi utenti. Ciò è dovuto al fatto che metà delle prestazioni viene spesa per il mirroring in tempo reale.

  • Sicurezza

    Si consiglia vivamente di isolare i dettagli di implementazione suddividendo la soluzione in reti pubbliche e private.

  • Disponibilità

    Si consiglia di implementare un dispositivo sempre disponibile poiché iSCSI per questa tecnologia è indipendente dal sistema operativo, in modo che gli utenti possano godere di una vera tolleranza agli errori, indipendentemente dal fatto che eseguano Linux o Windows sulle proprie macchine.

    Tutti i componenti software della soluzione sono disponibili pubblicamente come prodotti open source. In particolare, il driver DRBD è un componente integrale del kernel vanilla Linux ed è disponibile in qualsiasi distribuzione Linux.

Visualizza altro

Scopri di più sui prodotti e sulle tecnologie utilizzati in questa architettura di riferimento.

Esamina queste risorse aggiuntive:

conferme

  • Autori: Andrea Del Monaco, Yuri Rassokhin
  • Collaboratori: Alessio Comisso, Deepak Soni, John Sulyok