Informazioni sulla modernizzazione dello storage con Oracle Cloud Infrastructure Object Storage

Questa guida alla soluzione ti aiuterà a capire come progettare ed eseguire la migrazione dello storage a lungo termine dai file system locali o NFS a Oracle Cloud Infrastructure Object Storage (OCI Object Storage). Una soluzione di questo tipo può aiutare a ridurre i costi e applicare la conservazione, le regole del ciclo di vita e le richieste preautenticate come funzioni aggiunte.

In questa guida alle soluzioni, stiamo utilizzando un caso d'uso del cliente per evidenziare il punto di partenza per l'implementazione di un impegno di modernizzazione di successo.

Spesso parliamo di migrazione e modernizzazione del cloud nella stessa conversazione, esaminando tutti i metodi, i servizi e le offerte disponibili. La conversazione spesso comporta un approccio graduale, in cui un intero data center viene sistematicamente spostato nel cloud, sollevato e spostato così com'è, e poi tutto il resto segue l'esempio.

Una volta completata la fase iniziale, la modernizzazione delle applicazioni spesso perde la sua importanza rispetto alle sfide di sicurezza, monitoraggio, integrazione attuale e continua. Inoltre, evidenzia un passaggio dal lavoro che i team dell'infrastruttura possono fare a quello dei team delle applicazioni. Budget, tempistiche e altre priorità hanno la precedenza e, di conseguenza, le applicazioni devono essere eseguite così com'è nel cloud. Per realizzare i veri risparmi potenziali che il cloud può offrire, le aziende dovrebbero guardare a tecnologie come lo storage degli oggetti per risparmiare sui costi.

Gli archivi di file sono un ottimo punto di partenza, in quanto possono essere trasferiti da NFS a OCI Object Storage con un lavoro di sviluppo e test minimi. L'implementazione di una soluzione come questa può risparmiare sull'ordine di 10-50x sullo storage, a seconda del caso d'uso. Le aziende si sono rese conto che i data center operativi stanno diventando sempre più responsabili e potrebbero comportare costi aggiuntivi invisibili, con il crescente numero di potenziali attacchi, perdite di servizio e concorrenti che innovano costantemente.

Ciò dovrebbe rendere l'uso di servizi cloud nativi come OCI Object Storage una priorità, per risparmiare sui costi, proteggere l'azienda, condividere l'onere di gestire una vasta gamma di carichi di lavoro eterogenei con un hyperscaler e altro ancora.

Comprendi le sfide successive alla migrazione

La chiave qui è stata quella di concentrarsi su un punto di dolore post-migrazione e riprogettare un pezzo abbastanza grande dell'applicazione per essere di impatto, ma abbastanza piccolo da affrontare all'interno di un unico sprint di progettazione. In questo modo, l'azienda realizza risparmi e tranquillità, mantenendo bassi i costi di sviluppo e test.

Per il caso d'uso in questo playbook di soluzioni, il costo dello storage di file condiviso (NFS) è diventato un problema nel cloud e il design originale dell'applicazione è diventato il motivo per cui non è stato così facile cambiare. Durante il progetto di migrazione da on-premise al cloud, abbiamo parlato dello storage degli oggetti come alternativa più economica e affidabile allo storage di file, sulla carta circa 10x in termini di risparmio. Aggiunta di backup e repliche, che 10x è probabilmente superiore. Funzionalità efficienti come la replica tra più aree, il blocco della conservazione e i criteri del ciclo di vita possono tutti lavorare insieme per rendere lo storage degli oggetti la base per un sistema sicuro, affidabile e conveniente in cui memorizzare documenti importanti. Tuttavia, quando l'applicazione è progettata attorno al file system NFS per l'archiviazione dei documenti e prevede la semantica POSIX, le cose diventano più difficili.

L'applicazione che è stata modernizzata in questo caso d'uso è un'applicazione standard a 3 livelli, ma con diversi componenti esterni che devono eseguire un processo coordinato e cpu-intense per generare le fatture dei clienti, contabilizzarle in una struttura di directory organizzata e catalogarle per il download e lo storage a lungo termine. Questi file PDF e altri file sono stati memorizzati su un grande file system NFS con un modello di denominazione file molto specifico, al fine di essere accessibili da un percorso generato. Ancora un'altra applicazione è stata costruita attorno al server Apache HTTP, utilizzando l'area di archiviazione a lungo termine di questa condivisione NFS come radice del documento, in modo tale che gli URL generati dall'applicazione potrebbero essere utilizzati per scaricare file da qualsiasi punto negli ultimi 2 anni. Infine, i file più vecchi di una certa età potrebbero essere rimossi dall'archivio online, ma potrebbero ancora essere richiesti dagli auditor che cercano record.

Pertanto, tutti i file fino a 10 anni dovevano essere conservati sul file system NFS, essenzialmente costando all'azienda più denaro ogni giorno che venivano generati nuovi file. Il problema esisteva in diverse applicazioni, quindi il problema dei costi peggiorerebbe solo nel tempo.

Utilizzo dello storage degli oggetti OCI

Lo storage degli oggetti è perfetto per i file che non cambiano frequentemente. Ciò è in contrasto con NFS, che si concentra sullo storage condiviso a uso misto.

Sfruttando diversi elementi di progettazione dello storage degli oggetti e alcune funzioni specifiche del servizio di storage degli oggetti OCI, possiamo aumentare la disponibilità e ridurre i costi per i carichi di lavoro adatti.

In questo caso d'uso, i file creati per l'accesso a medio termine e l'archivio a lungo termine sono una buona soluzione. Questi file sono probabilmente scritti una volta e hanno la necessità di essere memorizzati per mesi o anni senza modifiche. In effetti, l'azienda potrebbe voler garantire che siano immutabili per un periodo di tempo.

Nel complesso, ecco un elenco dei motivi di base per cui lo storage degli oggetti offre vantaggi rispetto allo storage di file tradizionale per questi tipi di file.

  • Disponibilità: lo storage degli oggetti è un servizio regionale, il che significa che non è collegato a un singolo dominio di disponibilità.
  • Cerca: l'utilizzo dei metadati degli oggetti è probabilmente più utile che basarsi esclusivamente su nomi di file e comandi di ricerca di tipo POSIX.
  • Regole di conservazione: è possibile garantire che un intero bucket non venga modificato dopo la scrittura degli oggetti per garantire la conformità immediata.
  • Livelli di storage: il livello di storage degli oggetti (automatico o manuale) comporta un'enorme riduzione dei costi per gli oggetti di retention ad accesso non frequente o richiesti da regole aziendali.
  • Criteri del ciclo di vita: il tuning dello spostamento tra i livelli di storage e l'eliminazione automatica (cleanup) dopo la conservazione consentirà di risparmiare su storage e amministrazione.
  • Replica: la replica semplice e automatica di un intero bucket in un'altra area può aumentare la disponibilità e l'accesso ai dati.
  • Costo: lo storage degli oggetti costruito e gestito in modo appropriato costa molto meno dei file system NFS duplicati e ingombranti.

NFS è ancora utile per le applicazioni che richiedono un file system attivato, condiviso e di tipo POSIX. Il cliente necessitava ancora di NFS per lo storage condiviso, ma il suo uso era limitato a file "operativi" e non a file "archivi". La soluzione descritta di seguito descrive come impostare e accedere allo storage degli oggetti e come l'applicazione è stata modificata per utilizzare sia lo storage NFS che il nuovo archivio di storage degli oggetti creato per lo storage a lungo termine.

Architettura

Questa architettura mostra la progettazione e l'esecuzione per spostare lo storage a lungo termine in OCI Object Storage, riducendo i costi e applicando la conservazione, le regole del ciclo di vita e le richieste preautenticate come funzioni aggiunte.

Le seguenti immagini raffigurano l'architettura "prima" e "dopo" l'implementazione. Oracle File System Service (FSS) viene utilizzato per un file system condiviso di grandi dimensioni. Su questo file system, di cui è stata eseguita la migrazione da un data center in locale, i componenti dell'applicazione utilizzano l'elaborazione in batch per generare i file di archivio su base continuativa. Pertanto, lo stesso file system NFS contiene sia gli elementi dell'applicazione necessari per eseguire l'elaborazione intermedia (script, file temporanei e così via) e l'archivio di file effettivo, memorizzato in una gerarchia che deve essere gestita per un massimo di 10 anni, in base ai requisiti aziendali.

Una volta impostato, i bucket di OCI Object Storage vengono utilizzati per ospitare la parte di archivio delle operazioni eseguite da NFS. Le autorizzazioni per la lettura e la scrittura del bucket vengono definite in modo limitato e vengono stabilite regole di conservazione e ciclo di vita per essere preparate a un grande afflusso di dati. La gerarchia di grandi dimensioni dei file di archivio viene copiata nello storage degli oggetti OCI e l'elaborazione batch viene sottoposta a rifacimento per inserire nuovi archivi nel nuovo bucket degli oggetti. Anche i meccanismi di accesso sono stati leggermente aggiornati al fine di accedere ai file dallo storage degli oggetti, in un modo che ha impedito al resto dell'applicazione e ai clienti finali di dover apportare modifiche alle modalità di accesso a questi archivi.

Il seguente diagramma illustra l'architettura prima dell'implementazione:



oci-object-storage-modernization-arch-oracle1.zip

Il seguente diagramma illustra l'architettura dopo l'implementazione:



oci-object-storage-modernizzazione-arch-oracle.zip

a: Criterio OSS predefinito:
  • Amministratori tenancy - Accesso completo
  • Ammin. app - Accesso limitato senza lettura oggetto
  • Sola lettura - Ispezione bucket senza lettura oggetto
b: Criterio IAM gruppo dinamico:
  • Istruzioni aggiunte per gruppo dinamico
  • Definito in modo limitato per risorse specifiche
c: Definizione del gruppo dinamico (una delle due):
  • Lista di OCID istanza
  • OCID compartimento istanza
d: Regole di conservazione:
  • 3650 giorni (10 anni)
  • bloccate

e: Regole ciclo di vita:

  • Dopo 90 giorni - Deposito non frequente
  • Dopo 180 giorni - Storage di archivio
  • Dopo 3651 giorni - Elimina

Questa architettura supporta i componenti elencati di seguito.

  • Storage degli oggetti

    Lo storage degli oggetti Oracle Cloud Infrastructure fornisce un accesso rapido a grandi quantità di dati strutturati e non strutturati di qualsiasi tipo di contenuto, inclusi backup del database, dati analitici e contenuti avanzati come immagini e video. Puoi memorizzare e quindi recuperare i dati direttamente da Internet o dall'interno della piattaforma cloud. Puoi ridimensionare lo storage senza alcun deterioramento delle prestazioni o dell'affidabilità del servizio. Utilizza lo storage standard per lo storage "caldo" a cui è necessario accedere rapidamente, immediatamente e frequentemente. Utilizza lo storage di archivio per lo storage "freddo" che conservi per lunghi periodi di tempo e a cui accedi raramente o raramente.

  • Storage file

    Il servizio Oracle Cloud Infrastructure File Storage offre un file system di rete duraturo, scalabile, sicuro e di livello aziendale. Puoi connetterti a un file system del servizio di storage di file da qualsiasi istanza Bare Metal, virtual machine o container in una rete VCN. Inoltre, puoi accedere a un file system dall'esterno della VCN utilizzando Oracle Cloud Infrastructure FastConnect e IPSec VPN.

  • Identity and Access Management (IAM)

    Oracle Cloud Infrastructure Identity and Access Management (IAM) è il piano di controllo dell'accesso per Oracle Cloud Infrastructure (OCI) e Oracle Cloud Applications. L'API IAM e l'interfaccia utente consentono di gestire i domini di Identity e le risorse all'interno del dominio di Identity. Ogni dominio di Identity IAM OCI rappresenta una soluzione standalone per la gestione delle identità e degli accessi o una popolazione di utenti diversa.

Considerazioni per Identity Management

L'uso di bucket di storage degli oggetti privati implica l'impostazione di autorizzazioni appropriate per l'uso. Per impostazione predefinita, ai gruppi di utenti e ai gruppi dinamici non viene in genere concesso l'accesso a set di autorizzazioni estese, ad esempio object-family, a meno che non venga applicato a un compartimento.

Prima di intraprendere questa soluzione, vale la pena assicurarsi che solo i gruppi a cui si desidera accedere allo storage degli oggetti dispongano delle autorizzazioni. Una cosa estremamente utile qui è seguire la metodologia CIS Landing Zone relativa alla limitazione dell'accesso. Quando si implementa questa soluzione, si discute della creazione di gruppi dinamici, quindi vale la pena comprendere sia la struttura del compartimento della tenancy, sia i concetti discussi nella zona di destinazione. Vale anche la pena leggere su Sintassi dei criteri OCI, incluso come definire in modo limitato un gruppo dinamico e un'istruzione dei criteri.

Sebbene sia RCLONE che OCIFS supportino le chiavi API OCI standard come meccanismo di autenticazione, abbiamo scelto i principal delle istanze e i gruppi dinamici per l'autenticazione. Ciò migliora la postura generale della sicurezza: non è necessario creare, distribuire o ruotare le chiavi. Vengono invece utilizzati gruppi dinamici separati, al fine di garantire le autorizzazioni più ristrette possibili per ciascun gruppo dinamico. Ad esempio, la possibilità di creare bucket potrebbe essere consentita dai criteri per il gruppo dinamico RCLONE, mentre per il gruppo dinamico Apache è consentita solo la lettura degli oggetti.

Considerazioni per lo storage di archivio

Per risparmiare sui costi e utilizzare il livello di costo più basso dello storage degli oggetti OCI, questa soluzione ha implementato le regole del ciclo di vita, che spostano gli oggetti nel livello non frequente e quindi nel livello di archivio dopo un periodo di tempo dalla creazione.

Una volta archiviati, gli oggetti non possono essere riclassificati direttamente al livello standard. A causa della natura offline dello storage degli oggetti archiviato, è necessario sviluppare un processo in cui sia possibile richiedere un audit (processo aziendale), alcuni file estratti dall'archivio e quindi i file diventano accessibili per un periodo di tempo limitato.

Ancora una volta, utilizzando le funzioni intrinseche dello storage degli oggetti, i file possono essere richiamati temporaneamente, copiati in una posizione temporanea (un altro bucket) ed esposti esternamente utilizzando le richieste preautenticate (PAR, Pre-authenticated Requests). Si tratta di URL oscuri (sicurezza per oscurità) che consentono l'accesso a file specifici in un bucket e possono scadere dopo un determinato periodo di tempo, revocando l'accesso.

Durante il periodo di richiamo, i file possono essere copiati in nuovi bucket di livello standard e quindi tornare automaticamente alla modalità di archiviazione e non è necessaria alcuna manutenzione. RCLONE e CLI OCI, Java, REST o Python possono essere utilizzati in modo simile per la soluzione principale, dando nuovamente accesso a un bucket di audit specifico.