1. Distribuire un file system scalabile e distribuito utilizzando GlusterFS
  2. Distribuire un file system scalabile e distribuito utilizzando GlusterFS

Distribuire un file system scalabile e distribuito utilizzando GlusterFS

Un file system di rete distribuito scalabile è adatto per attività ad alta intensità di dati come l'elaborazione delle immagini e lo streaming multimediale. Quando viene utilizzato in ambienti HPC (High Performance Computing), GlusterFS offre un accesso ad alte prestazioni a data set di grandi dimensioni, in particolare file immutabili.

Architettura

Questa architettura di riferimento contiene i componenti dell'infrastruttura necessari per un file system di rete distribuito. Contiene tre istanze Bare Metal, ovvero il minimo necessario per impostare High Availability per GlusterFS.

In una configurazione a tre server, almeno due server devono essere in linea per consentire operazioni di scrittura nel cluster. I dati vengono replicati su tutti i nodi, come mostrato nel diagramma.

Segue una descrizione dell'immagine glusterfs-oci.png
Descrizione dell'immagine glusterfs-oci.png

glusterfs-oci-oracle.zip

  • Area

    Un'area Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni, e vaste distanze possono separarle (tra paesi o addirittura continenti).

  • Dominio di disponibilità

    I domini di disponibilità sono data center indipendenti e autonomi all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità vengono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono un'infrastruttura come l'alimentazione o il raffreddamento oppure la rete interna del dominio di disponibilità. È improbabile che l'eventuale guasto di un dominio di disponibilità influenzi gli altri domini di disponibilità della regione.

  • Dominio di errore

    Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità ha tre domini di guasto con alimentazione e hardware indipendenti. Quando si distribuiscono risorse su più domini di errore, le applicazioni possono tollerare errori fisici del server, la manutenzione del sistema e gli errori di alimentazione all'interno di un dominio di errore.

  • Rete cloud virtuale e subnet

    Un VCN è una rete customizzabile e definita dal software impostata in un'area Oracle Cloud Infrastructure. Come le reti di data center tradizionali, offre controllo completo sull'ambiente di rete. Un VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo la creazione di VCN. È possibile segmentare un VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet in VCN. È possibile modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.

    Questa architettura utilizza due subnet: una subnet pubblica per creare DMZ e ospitare il server bastion e una subnet privata per ospitare i nodi GlusterFS.

  • Gruppo di sicurezza di rete (NSG)

    I NSG fungono da firewall virtuali per le risorse cloud. Con il modello di sicurezza zero-trust di Oracle Cloud Infrastructure, tutto il traffico viene negato ed è possibile controllare il traffico di rete all'interno di un VCN. Un NSG è costituito da un set di regole di sicurezza in entrata e in uscita che si applicano solo a un set specificato di VNIC in un singolo VCN.

  • Lista di sicurezza

    Per ogni subnet è possibile creare regole di sicurezza che specifichino l'origine, la destinazione e il tipo di traffico che devono essere consentiti all'interno e all'esterno della subnet.

  • Codici GFS

    Queste sono le intestazioni di GlusterFS, con 1 TB di memorizzazione a blocchi collegati a ogni istanza.

  • /gfs-data

    Nell'architettura di riferimento, il client esegue il MOUNT del volume GlusterFS nel punto di accesso /gfs-data, tramite il quale l'applicazione accede al file system. Più server possono accedere ai nodi headend in parallelo.

  • Host bastion

    L'host bastion è un'istanza di calcolo che funge da punto di accesso sicuro e controllato alla topologia dall'esterno del cloud. L'host bastione viene eseguito in genere in una zona demilitarizzata (DMZ). Consente di proteggere le risorse sensibili inserendole in reti private a cui non è possibile accedere direttamente dall'esterno del cloud. La topologia dispone di un singolo punto di accesso noto che è possibile monitorare e controllare regolarmente. Così, è possibile evitare di esporre i componenti più sensibili della topologia senza compromettere l'accesso a loro.

Suggerimenti

Le vostre esigenze potrebbero differire dall'architettura descritta qui. Utilizzare i suggerimenti riportati di seguito come punto di partenza.

  • Architettura GlusterFS

    Questa architettura utilizza volumi GlusterFS replicati; i dati vengono replicati su tutti i nodi. Questa configurazione fornisce la massima disponibilità di dati, ma utilizza anche la maggiore quantità di spazio. Come mostrato nel diagramma di architettura, quando File1 viene creato, viene replicato tra i nodi.

    GlusterFS supporta le architetture riportate di seguito. Selezionare un'architettura che soddisfi le proprie esigenze:
    • Volume distribuito

      Questa architettura è la configurazione predefinita di GlusterFS ed è utilizzata per ottenere la dimensione massima del volume e la scalabilità. Nessuna ridondanza di dati. Pertanto, se un mattone nel volume fallisce, porterà alla completa perdita di dati.

    • Volume replicato

      Questa architettura è più utilizzata dove l'alta disponibilità è critica. Problemi di perdita di dati derivanti da guasti di mattoni vengono evitati replicando i dati su due o più mattoni. Questa architettura di riferimento utilizza la configurazione dei volumi replicati.

    • Volume replicato distribuito

      Questa architettura è una combinazione di volumi distribuiti e replicati ed è utilizzata per ottenere dimensioni di volume più grandi di un volume replicato e una disponibilità maggiore di un volume distribuito. In questa configurazione, i dati vengono replicati in un subset del numero totale di mattoni. Il numero di mattoni deve essere un multiplo del conteggio delle repliche. Ad esempio, quattro mattoni da 1 TB ciascuno ti daranno uno spazio distribuito di 2 TB con una duplice replica.

    • Volumi a strisce

      Questa architettura viene utilizzata per file di grandi dimensioni che verranno divisi in pezzi più piccoli e ogni pezzo viene memorizzato in un mattone. Il carico viene distribuito sui mattoni e il file può essere recuperato più velocemente, ma non è disponibile alcuna ridondanza di dati.

    • Volume a strisce distribuito

      Questa architettura viene utilizzata per file di grandi dimensioni con distribuzione su un maggior numero di mattoni. Il compromesso con questa configurazione è che se si desidera aumentare la dimensione del volume, è necessario aggiungere mattoni in più del conteggio delle strisce.

  • Forme di computazione

    Questa architettura utilizza una forma Bare Metal (BM.Standard2.52) per tutti i nodi GlusterFS. Queste istanze di calcolo bare metal dispongono di due NIC fisici in grado di eseguire il push del traffico a 25 Gbps ciascuna. La seconda NIC fisica è dedicata al traffico GlusterFS.

  • Memorizzazione a blocchi

    Questa architettura utilizza 1 TB di memorizzazione a blocchi. Si consiglia di configurare un volume manager logico (LVM) per consentire la crescita del volume se si ha bisogno di più spazio. Ogni volume a blocchi è configurato per utilizzare prestazioni bilanciate e fornisce IOPS 35K e 480 MB/s di throughput.

  • Rete cloud virtuale (VCN)

    Quando si crea un VCN, determinare il numero di blocchi CIDR richiesti e la dimensione di ciascun blocco in base al numero di risorse che si prevede di associare alle subnet in VCN. Utilizzare blocchi CIDR che si trovano all'interno dello spazio degli indirizzi IP privati standard.

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

    Dopo aver creato un VCN, è possibile modificare, aggiungere e rimuovere i blocchi CIDR.

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

  • Gruppi di sicurezza di rete (NSG)

    È possibile utilizzare i NSG per definire un set di regole di ingresso e uscita applicabili a VNIC specifiche. Si consiglia di utilizzare gli NSG anziché gli elenchi di sicurezza, poiché gli NSG consentono di separare l'architettura della subnet di VCN dai requisiti di sicurezza dell'applicazione. Nell'architettura di riferimento, tutta la comunicazione di rete è controllata tramite NSG.

  • Liste di sicurezza

    Utilizzare gli elenchi di sicurezza per definire le regole di ingresso e uscita applicabili all'intera subnet.

Considerazioni

  • Prestazioni

    Per ottenere le migliori prestazioni, utilizzare NIC dedicati per la comunicazione dall'applicazione agli utenti e alle intestazioni GlusterFS. Utilizzare il NIC primario per la comunicazione tra l'applicazione e gli utenti. Utilizzare il NIC secondario per la comunicazione con le intestazioni GlusterFS. È inoltre possibile modificare le prestazioni del volume per la memorizzazione a blocchi per aumentare o ridurre lo IOPS e il throughput del disco.

  • Disponibilità

    I domini di errore forniscono la migliore resilienza all'interno di un dominio di disponibilità. Se è necessaria una maggiore disponibilità, prendere in considerazione l'utilizzo di più domini di disponibilità o più aree. Per i carichi di lavoro mission-critical, prendere in considerazione l'utilizzo di volumi GlusterFS con striping distribuito.

  • Costo
    Il costo della distribuzione di GlusterFS dipende dai requisiti per le prestazioni e la disponibilità del disco:
    • È possibile scegliere tra le seguenti opzioni di prestazioni: alte prestazioni, prestazioni bilanciate e basso costo.
    • Per una maggiore disponibilità, è necessario un numero maggiore di nodi e volumi GlusterFS.

Distribuzione

Il codice richiesto per distribuire questa architettura di riferimento è disponibile in GitHub. È possibile estrarre il codice in Oracle Cloud Infrastructure Resource Manager con un solo clic, creare lo stack e distribuirlo. In alternativa, scaricare il codice da GitHub nel computer, personalizzare il codice e distribuire l'architettura utilizzando Terraform CLI.

  • Distribuisci utilizzando Oracle Cloud Infrastructure Resource Manager:
    1. Fare clic su Distribuire in Oracle Cloud

      Se non si è già connessi, immettere la tenancy e le credenziali utente.

    2. Rivedere e accettare i termini e le condizioni.
    3. Selezionare l'area in cui distribuire lo stack.
    4. Seguire le istruzioni e i prompt sullo schermo per creare lo stack.
    5. Dopo aver creato lo stack, fare clic su Azioni Terraform e selezionare Piano.
    6. Attendere il completamento del job e rivedere il piano.

      Per apportare eventuali modifiche, tornare alla pagina Dettagli stack, fare clic su Modifica stack e apportare le modifiche necessarie. Eseguire di nuovo l'azione Piano.

    7. Se non sono necessarie ulteriori modifiche, tornare alla pagina Dettagli stack, fare clic su Azioni Terraform e selezionare Applica.
  • Distribuzione con Terraform CLI:
    1. Andare a GitHub.
    2. Duplicare o scaricare il repository nel computer locale.
    3. Seguire le istruzioni contenute nel documento README.

Visualizza altro

Log delle modifiche

Questo log elenca le modifiche significative: