Il primo prototipo di archiviazione a oggetti è apparso nel 1996. Dieci anni dopo, Amazon Web Services ha lanciato Amazon S3, e il mondo ha iniziato a impazzire per lo spazio degli indirizzi piatto. Grazie alla gestione dei metadati e alla capacità di scalare senza perdere performance, gli archivi a oggetti sono rapidamente diventati lo standard per la maggior parte dei servizi di archiviazione dati nel cloud e oltre. Un'altra importante caratteristica è la buona adattabilità per l'archiviazione di archivi e di altri file raramente utilizzati. Tutti coloro che erano coinvolti nell'archiviazione dei dati esultavano e portavano in trionfo questa nuova tecnologia.
Ma la voce popolare era piena di dicerie, secondo cui gli archivi a oggetti erano solo per grandi cloud, e se non si voleva dipendere dalle soluzioni dei maledetti capitalisti, sarebbe stato molto difficile crearne uno proprio. Sono già stati scritti molti articoli sullo schieramento del proprio cloud, mentre le informazioni sulla creazione di soluzioni compatibili con S3 sono piuttosto scarse.
Oggi analizzeremo quali sono le opzioni "Come da adulti, non come CEPH e un po' di attrezzi in più", esploreremo una di esse e testeremo il funzionamento utilizzando Veeam Backup & Replication. Questo software dichiara di supportare il funzionamento con archivi compatibili con S3, e verificheremo questa affermazione.
E per gli altri?
Iniziamo con una breve panoramica del mercato e delle opzioni di archiviazione a oggetti. Il leader riconosciuto e lo standard è Amazon S3. I due più vicini inseguitori sono Microsoft Azure Blob Storage e IBM Cloud Object Storage.
Davvero è tutto? Non ci sono altri concorrenti? Certo, i concorrenti esistono, ma alcuni seguono il proprio percorso, come Google Cloud o Oracle Cloud Object Storage, con supporto parziale per S3 API. Altri utilizzano versioni obsolete dell'API, come Baidu Cloud. E alcuni, come Hitachi Cloud, richiedono l'uso di logiche particolari, il che porterà inevitabilmente a delle difficoltà. In ogni caso, tutti vengono confrontati con Amazon, che può essere considerato lo standard industriale.
Tuttavia, nelle soluzioni on-premise, c'è una scelta molto più ampia, quindi definiamo i criteri importanti per noi. In sostanza, due sono sufficienti: supporto per S3 API e utilizzo della firma v4. A essere onesti, come futuri clienti ci interessano solo le interfacce per l'interazione, mentre le specifiche interne dello storage ci interessano meno.
A queste semplici condizioni corrispondono davvero moltissime soluzioni. Ad esempio, i classici colossi aziendali:
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix Buckets
- Pure Storage FlashBlade e StorReduce
- Huawei FusionStorage
Esiste una nicchia di soluzioni puramente software, pronte all'uso:
- Red Hat Ceph
- SUSE Enterprise Storage
- Cloudian
E anche coloro che amano rifinire con cura dopo l'assemblaggio non sono stati trascurati:
- CEPH nella sua forma pura
- Minio (versione Linux, poiché ci sono molte domande sulla versione Windows)
L'elenco non è completo e può essere discusso nei commenti. Ricordate solo di controllare le prestazioni del sistema oltre alla compatibilità API prima dell'implementazione. L'ultima cosa di cui avete bisogno è perdere terabyte di dati a causa di richieste in sospeso. Non esitate a effettuare test di carico. In generale, tutto il software serio che gestisce grandi volumi di dati ha almeno dei rapporti di compatibilità. Nel caso di Veeam ci siano di testing reciproco, che consente di affermare con sicurezza la completa compatibilità dei nostri prodotti con specifiche attrezzature. Si tratta già di un lavoro bilaterale, non sempre veloce, ma stiamo costantemente ampliando le soluzioni testate.
Stiamo preparando il nostro stand
Vorrei parlare un po' della scelta del soggetto.
In primo luogo, volevo trovare un'opzione che funzionasse subito, senza problemi. O almeno con la massima probabilità che funzionasse senza dover fare troppi passaggi. Giocare con i dettagli e frugare nella console di notte è affascinante, ma a volte si desidera semplicemente che funzioni immediatamente. Inoltre, l'affidabilità complessiva di queste soluzioni è generalmente maggiore. Sì, ci siamo lasciati alle spalle lo spirito avventuroso, abbiamo smesso di arrampicarci per le finestre delle nostre amate, e così via.
In secondo luogo, se devo essere sincero, la necessità di lavorare con repository oggettuali si presenta in realtà in grandi aziende, quindi questo è uno di quei casi in cui guardare alle soluzioni di livello enterprise non è solo accettabile, ma persino incoraggiato. Almeno, finora non conosco esempi di persone licenziate per aver acquistato tali soluzioni.
In base a quanto detto finora, la mia scelta è caduta su Dell EMC ECS Community Edition. Si tratta di un progetto molto interessante, e ritengo sia necessario parlarvi di esso.
La prima cosa che viene in mente vedendo l'aggiunta Community Edition è che sia semplicemente un'imitazione della versione completa di ECS con alcune limitazioni, che si eliminano con l'acquisto di una licenza. Ebbene, non è così!
Ricordate:
!!!Community Edition — è un progetto a sé stante, creato per il test, senza supporto tecnico da parte di Dell!!
E non può essere trasformato in un ECS a tutti gli effetti, anche se lo si desidererebbe moltissimo.
Analizziamo
Molti ritengono che Dell EMC ECS sia una delle migliori soluzioni se avete bisogno di uno storage a oggetti. Tutti i progetti a marchio ECS, inclusi quelli commerciali ed enterprise, si basano su . Un gesto di buona volontà da parte di Dell. Oltre al software che gira sui loro server brandizzati, esiste una versione open source che può essere installata sia nel cloud, sia su una macchina virtuale, sia in un contenitore, sia su qualsiasi hardware di vostra scelta. Anticipando un po' — esiste persino una versione OVA, che utilizzeremo.
Il DELL ECS Community Edition è una mini-versione del software completo, funzionante sui server brandizzati Dell EMC ECS.
Ho evidenziato quattro principali differenze:
- Nessun supporto per la crittografia. È deludente, ma non critico.
- Mancanza del Fabric Layer. Questa parte si occupa della creazione di cluster, gestione delle risorse, aggiornamenti, monitoraggio e memorizzazione delle immagini Docker. Qui è davvero deludente, ma possiamo capire anche Dell.
- La cosa più sgradevole derivante dal punto precedente: la dimensione della node non può essere ampliata dopo il completamento dell'installazione.
- Nessun supporto tecnico. Questo prodotto è pensato per test, ed è consentito utilizzarlo in piccole installazioni, ma personalmente non mi sentirei a mio agio a caricare petabyte di dati importanti. Tuttavia, tecnicamente nessuno può impedirvi di farlo.
E per la versione grande?
Diamo un veloce sguardo alle soluzioni hardware per avere una visione più completa dell'ecosistema.
Non commenterò né confermerò l'affermazione che DELL ECS sia il miglior storage object on-prem, ma se avete qualcosa da dire su questo argomento, leggendolo con piacere nei commenti. In ogni caso, secondo la versione Dell EMC si colloca saldamente tra i cinque leader nel mercato degli OBS. Anche se non vengono considerati i soluzioni cloud-based, questo è un discorso a parte.
Dal punto di vista tecnico, ECS è uno storage object che fornisce accesso ai dati tramite protocolli di archiviazione cloud. Supporta AWS S3 e OpenStack Swift. Per i bucket abilitati ai file, ECS supporta NFSv3 per l'esportazione a livello di file.
Il processo di registrazione delle informazioni è piuttosto insolito, soprattutto rispetto ai classici sistemi di archiviazione a blocchi.
- Quando arrivano nuovi dati, viene creato un nuovo oggetto che ha un nome, i dati stessi e i metadati.
- Gli oggetti vengono suddivisi in chunk da 128 MB, e ogni chunk viene registrato immediatamente su tre nodi.
- Si aggiorna il file di indice, dove sono registrati gli identificatori e i luoghi di archiviazione.
- Viene aggiornato il file di log e anche questo viene registrato su tre nodi.
- Il cliente riceve un messaggio che conferma la registrazione avvenuta con successo.
Tutte e tre le copie dei dati vengono registrate in parallelo. La registrazione è considerata riuscita solo se tutte e tre le copie sono state salvate con successo.
La lettura avviene in modo più semplice:
- Il cliente richiede i dati.
- Si cerca nell'indice il luogo di archiviazione dei dati.
- I dati vengono letti da un nodo e inviati al cliente.
Ci sono molti server, quindi diamo un'occhiata al più piccolo, il Dell EMC ECS EX300. Parte da 60 TB, con la possibilità di espandersi fino a 1,5 PB. E il suo "fratello maggiore", il Dell EMC ECS EX3000, consente di archiviare fino a 8,6 PB per rack.
Deploy
Tecnicamente, Dell ECS CE può essere scalato quanto si vuole. In ogni caso, non ho trovato restrizioni esplicite. Tuttavia, è conveniente eseguire la scalabilità clonando il primo nodo, per il quale avremo bisogno di:
- 8 vCPU
- 64GB RAM
- 16GB per il sistema operativo
- 1TB per lo storage
- L'ultima versione di CentOS minimal
Questa è un'opzione nel caso in cui si desideri installare tutto da zero. Per noi questa opzione non è attuale, poiché utilizzerò un'immagine OVA per il deployment.
Ma in ogni caso, i requisiti sono piuttosto elevati anche per un singolo nodo, e se seguiamo rigorosamente la lettera della legge, servirebbero quattro nodi.
Tuttavia, gli sviluppatori di ECS CE vivono nella realtà e l'installazione riesce anche con un solo nodo, e i requisiti minimi sono:
- 4 vCPU
- 16 GB RAM
- 16 GB per il sistema operativo
- 104 GB per lo storage
Questi sono le risorse necessarie per il deployment dell'immagine OVA. Già molto più ragionevole e realistico.
Il nodo di installazione può essere scaricato ufficialmente . Qui troverai anche documentazione dettagliata sul deployment all-in-one, ma puoi anche leggere su . Pertanto, non ci soffermeremo a lungo sullo sviluppo dell'OVA, è tutto piuttosto semplice. L'aspetto fondamentale è non dimenticare di espandere il disco alla dimensione richiesta prima di avviarla o di collegare i necessari.
Avviamo la macchina, apriamo la console e utilizziamo le migliori credenziali predefinite:
- login: admin
- password: ChangeMe
Poi eseguiamo sudo nmtui e configuriamo l'interfaccia di rete — IP/mask, DNS e gateway. Ricordando che in CentOS minimal non ci sono net-tools, controlliamo le impostazioni tramite ip addr.
E poiché solo i coraggiosi conquistano i mari, eseguiamo yum update, quindi reboot. In realtà è piuttosto sicuro, poiché tutto lo sviluppo viene eseguito tramite playbook e tutti i pacchetti importanti di Docker sono bloccati sulla versione attuale.
È giunto il momento di modificare lo script di installazione. Niente finestre grafiche o pseudo UI — tutto tramite il tuo editor di testo preferito. Tecnicamente, ci sono due modi: puoi eseguire ogni comando manualmente oppure avviare direttamente il configuratore videploy. Questo aprirà semplicemente il file di configurazione in vim e, al termine, ne verificherà la correttezza. Ma semplificare la vita non è interessante, quindi faremo due comandi in più. Anche se non ha realmente senso, ti ho avvisato =)
Quindi, apriamo vim ECS-CommunityEdition/deploy.xml e facciamo le modifiche ottimali e minime affinché ECS si attivi e funzioni. Puoi ridurre il numero di parametri, ma io l'ho fatto in questo modo:
- licensed_accepted: true Puoi anche non cambiarlo, allora durante il deploy ti verrà esplicitamente richiesto di accettarlo e ti mostrerà una frase carina. Potrebbe anche essere un easter egg.
- Decommentare le righe autonames: e custom: Inserisci almeno un nome desiderato per il nodo — il hostname verrà sostituito da esso durante il processo di installazione.
- install_node: 192.168.1.1 Specifica l'IP reale del nodo. Nel nostro caso, indichiamo lo stesso che in nmtui
- dns_domain: inserisci il tuo dominio.
- dns_servers: inserisci il tuo DNS.
- ntp_servers: puoi specificare qualsiasi. Ho preso il primo disponibile dal pool 0.pool.ntp.org (che è diventato 91.216.168.42)
- autonaming: custom Se non viene decommentato, la luna verrà chiamata Luna.
- ecs_block_devices:
/dev/sdb
Per qualche motivo sconosciuto qui potrebbe esserci un dispositivo di archiviazione a blocchi inesistente /dev/vda - storage_pools:
members:
192.168.1.1 Qui dobbiamo nuovamente specificare l'IP reale del nodo - ecs_block_devices:
/dev/sdb Повторяем операцию вырезания несуществующих устройств.
In effetti, l'intero file è descritto in dettaglio in , ma chi lo leggerebbe in un momento così turbolento. È scritto che il minimo necessario è specificare l'IP e la subnet mask, ma nel mio laboratorio tale configurazione non funzionava bene, quindi ho dovuto espandere a quanto indicato sopra.
Dopo essere usciti dall'editor, bisogna lanciare update_deploy /home/admin/ECS-CommunityEdition/deploy.yml, e se tutto è stato fatto correttamente, verrà comunicato esplicitamente.
Dopo dovremo avviare videploy, attendere l'aggiornamento dell'ambiente e possiamo avviare l'installazione con il comando ova-step1, e dopo il suo completamento con il comando ova-step2. È importante: non interrompere l'esecuzione degli script manualmente! Alcuni passaggi possono richiedere tempo significativo, potrebbero non riuscire al primo tentativo e sembrare che tutto si sia rotto. In ogni caso, bisogna attendere che lo script termini naturalmente. Alla fine dovresti vedere un messaggio simile.
Ora finalmente possiamo aprire il pannello di controllo WebUI all'indirizzo IP che conosciamo. Se non hai modificato nulla durante la configurazione, la credenziale predefinita sarà root/ChangeMe. Possiamo anche iniziare a utilizzare il nostro storage compatibile con S3. È accessibile sulle porte 9020 per HTTP e 9021 per HTTPS. Ancora una volta, se non hai fatto modifiche, le chiavi saranno access_key: object_admin1 e secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
Ma non anticipiamo troppo e iniziamo con ordine.
Al primo accesso, vi verrà chiesto di cambiare la password in qualcosa di adeguato, il che è assolutamente corretto. La dashboard principale è estremamente chiara, quindi facciamo qualcosa di più interessante anziché spiegare metriche ovvie. Per esempio, creiamo un utente che utilizzeremo per accedere allo storage. Nel mondo dei provider di servizi, questo è chiamato tenant. Si fa in Manage > Users > New Object User.
Durante la creazione dell'utente ci viene chiesto di fornire uno spazio dei nomi. Tecnicamente, non abbiamo limiti nel crearne tanti quanti sono gli utenti. E viceversa. Questo consente di gestire le risorse in modo indipendente per ciascun tenant.
Di conseguenza, scegliamo le funzioni necessarie e generiamo le chiavi dell'utente. A me basta S3/Atmos. E non dimentichiamo di salvare la chiave 😉.
L'utente è stato creato, ora è tempo di assegnargli un bucket. Passiamo a Manage > Bucket e compiliamo i campi richiesti. Qui è tutto semplice.
Adesso siamo pronti per un utilizzo reale del nostro storage S3.
Configuriamo Veeam.
Come sappiamo, uno degli usi principali degli storage object è l'archiviazione a lungo termine di informazioni a cui si accede raramente. Un esempio ideale è la necessità di conservare backup in una posizione remota. In Veeam Backup & Replication, questa funzione è chiamata Capacity Tier.
Iniziamo la configurazione aggiungendo il nostro Dell ECS CE all'interfaccia di Veeam. Nella scheda Backup Infrastructure, avviamo la procedura guidata per aggiungere un nuovo repository e selezioniamo la voce Object Storage.
Selezioniamo ciò per cui è stata creata questa configurazione: S3 Compatible.
Nella finestra che appare, inseriamo il nome desiderato e passiamo al passaggio Account. Qui dobbiamo specificare il Service point sotto forma di , la regione può rimanere invariata, e aggiungiamo l'utente creato. Il gate server è necessario se il tuo storage si trova in una posizione remota, ma questo è un argomento di ottimizzazione dell'infrastruttura e merita un articolo a parte, quindi qui possiamo tranquillamente saltare.
Se tutto è indicato e configurato correttamente, apparirà un avviso sul certificato e poi una finestra con il bucket, dove possiamo creare una cartella per i nostri file.
Completiamo la procedura guidata e godiamoci il risultato.
Nel passaggio successivo, è necessario creare un nuovo Scale-out Backup Repository oppure aggiungere il nostro S3 a quello esistente: sarà utilizzato come Capacity Tier per l'archiviazione. Non ci sono funzioni per utilizzare archivi compatibili con S3 direttamente come un repository normale nella versione attuale. Ci sono troppi problemi non ovvi da risolvere, ma tutto può essere fatto.
Accediamo alle impostazioni del repository e attiviamo il Capacity Tier. È tutto chiaro, ma c'è un aspetto interessante: se si desidera che tutti i dati vengano inviati il prima possibile al cloud storage, basta impostare 0 giorni.
Dopo aver completato il wizard, se non si vuole aspettare, è possibile premere ctrl+clic destro sul repository, avviare forzatamente il Tiering job e osservare come si muovono i grafici.
Per ora è tutto. Ritengo di aver raggiunto l'obiettivo di dimostrare che gli archivi a blocchi non sono così spaventosi come si pensa generalmente. Sì, ci sono un sacco di soluzioni e varianti di implementazione, ma non si può coprire tutto in un solo articolo. Quindi, condividiamo le esperienze nei commenti.
Fonte: habr.com
