Il primo prototipo di storage oggetti è stato visto nel 1996. Dieci anni dopo, Amazon Web Services ha lanciato Amazon S3, e il mondo ha iniziato a impazzire progressivamente per lo spazio indirizzato piatto. Grazie al lavoro con i metadati e alla capacità di scalare senza subire rallentamenti sotto carico, gli storage oggetti sono rapidamente diventati lo standard per la maggior parte dei servizi di archiviazione dati nel cloud, e non solo. Un'altra caratteristica importante è la buona adattabilità per la conservazione di archivi e file di uso raro. Tutti coloro che lavoravano con la memorizzazione dei dati festeggiavano e portavano a spasso questa nuova tecnologia.
Eppure, la voce popolare era piena di rumors che gli storage oggetti riguardavano solo i grandi cloud, e se non si desiderano soluzioni dai maledetti capitalisti, realizzare il proprio sarebbe molto difficile. Sono già state scritte molte cose sul deployment del proprio cloud, mentre le informazioni sulla creazione di soluzioni compatibili con S3 sono piuttosto scarse.
Quindi oggi analizzeremo quali sono le opzioni "Per avere come i professionisti, non CEPH e un martello più grande", implementeremo una di esse, e verificheremo che tutto funzioni con Veeam Backup & Replication. Questo supporta il lavoro con storage compatibili con S3, e verificheremo questa affermazione.
E per quanto riguarda gli altri?
Iniziamo con una piccola panoramica del mercato e delle opzioni di storage oggetti. Il leader indiscusso e lo standard è Amazon S3. I due inseguitori più vicini sono Microsoft Azure Blob Storage e IBM Cloud Object Storage.
Davvero è tutto? Non ci sono altri concorrenti? Certo, ci sono concorrenti, ma alcuni seguono la propria strada, come Google Cloud o Oracle Cloud Object Storage, con supporto limitato per l'API S3. Altri utilizzano versioni obsolete dell'API, come Baidu Cloud. E alcuni, come Hitachi Cloud, richiedono l'uso di una logica speciale, che certamente porterà le sue difficoltà. In ogni caso, tutti vengono paragonati ad Amazon, che si può considerare lo standard industriale.
Ecco, nelle soluzioni on-premise la scelta è sicuramente molto più ampia, quindi definiamo i criteri che ci interessano. In sostanza, ne bastano due: supporto per l'API S3 e utilizzo della firma v4. A dire il vero, a noi come futuri clienti interessano solo le interfacce per l'interazione, mentre la parte interna dello storage ci interessa di meno.
Queste semplici condizioni sono soddisfatte da un sacco di soluzioni. Ad esempio, i classici pesi massimi aziendali:
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix Buckets
- Pure Storage FlashBlade e StorReduce
- Huawei FusionStorage
C'è anche una nicchia di soluzioni puramente software, pronte all'uso:
- Red Hat Ceph
- SUSE Enterprise Storage
- Cloudian
E anche chi ama limare il prodotto finito non è stato trascurato:
- CEPH puro
- Minio (versione Linux, poiché ci sono molte domande sulla versione Windows)
La lista non è affatto completa, possiamo discuterne nei commenti. Ricordate solo di controllare, oltre alla compatibilità API, anche le prestazioni del sistema prima di implementare. Ultima cosa di cui avete bisogno è perdere terabyte di dati a causa di richieste bloccate. Quindi non esitate a fare test di carico. In generale, tutto il software maturo che lavora con grandi volumi di dati ha almeno rapporti di compatibilità. Nel caso di Veeam c'è di test reciproci, che permette di dichiarare con sicurezza la piena compatibilità dei nostri prodotti con hardware specifico. È già un lavoro reciproco, non sempre veloce, ma stiamo costantemente ampliando delle soluzioni testate.
Costruiamo il nostro stand
Vorrei parlare un po' della scelta del soggetto.
Innanzitutto, volevo trovare un'opzione che funzionasse subito, out of the box. O perlomeno con la massima probabilità che funzionasse senza dover compiere sforzi aggiuntivi. Ballare attorno al fuoco e armeggiare con la console di notte è molto affascinante, ma a volte si desidera che tutto funzioni subito. Inoltre, l'affidabilità generale di tali soluzioni è solitamente più alta. E sì, in noi è svanito lo spirito d'avventura, abbiamo smesso di arrampicarci sulle finestre delle nostre donne e così via.
In secondo luogo, a essere sinceri, la necessità di lavorare con i repository oggetti si presenta in aziende di dimensioni considerevoli, quindi questo è proprio il caso in cui non solo non è vergognoso guardare verso soluzioni di livello enterprise, ma è addirittura incoraggiato. Ad ogni modo, al momento non conosco esempi di persone licenziate per aver acquistato tali soluzioni.
In base a quanto detto finora, la mia scelta è ricaduta su Dell EMC ECS Community Edition. Questo è un progetto molto interessante e ritengo sia necessario parlarvi di esso.
La prima cosa che viene in mente alla vista dell'add-on Community Edition è che sia semplicemente una copia dell'ECS completo con alcune limitazioni, rimuovibili acquistando una licenza. E invece no!
Ricordate:
!!!Community Edition è un progetto separato, creato per testare, e non ha supporto tecnico da parte di Dell!!
E non può essere trasformato in un ECS completo, anche se lo si desiderasse.
Facciamo chiarezza
Molti considerano Dell EMC ECS come una delle migliori soluzioni se avete bisogno di storage oggetti. Tutti i progetti a marchio ECS, comprese le versioni commerciali ed enterprise, si trovano su . Questa è una sorta di gesto di buona volontà da parte di Dell. E oltre al software che gira sulle loro server brandizzati, c'è anche una versione open source, che può essere implementata sia nel cloud, sia su una macchina virtuale, sia in un container, sia su qualsiasi hardware di vostra proprietà. Spoiler alert: c'è anche una versione OVA, di cui faremo uso.
Il DELL ECS Community Edition è una mini-versione del software completo, progettato per funzionare sui server brandizzati Dell EMC ECS.
Ho identificato quattro principali differenze:
- Non c'è supporto per la crittografia. È un peccato, ma non è critico.
- Manca il Fabric Layer. Questa funzione è responsabile della creazione dei cluster, della gestione delle risorse, degli aggiornamenti, del monitoraggio e dello storage delle immagini Docker. Qui già fa un po' più male, ma si può anche capire Dell.
- La conseguenza più fastidiosa del punto precedente: la dimensione del nodo non può essere ampliata dopo il completamento dell'installazione.
- Non c'è supporto tecnico. Questo è un prodotto per test, che può essere usato in installazioni di piccole dimensioni, ma personalmente non mi sentirei di caricare petabyte di dati importanti. Ma tecnicamente, nessuno può impedirvi di farlo.
E cosa succede nella versione grande?
Faremo un rapido giro d'orizzonte sulle soluzioni hardware per avere un'idea più completa dell'ecosistema.
Non intendo confermare o smentire l'affermazione che DELL ECS sia il miglior oggetto di archiviazione on-prem, ma se avete qualcosa da dire a riguardo, sarei felice di leggerlo nei commenti. In ogni caso, secondo la versione Dell EMC è saldamente tra i primi cinque leader del mercato OBS. Anche se non vengono considerati i soluzioni basate su cloud, questo è un discorso a parte.
Dal punto di vista tecnico, l'ECS è un oggetto di archiviazione 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 la possibilità di esportazione a livello di file.
Il processo di scrittura delle informazioni è piuttosto inusuale, soprattutto dopo i classici sistemi di archiviazione a blocchi.
- Quando arrivano nuovi dati, viene creato un nuovo oggetto, che ha un nome, i dati stessi e metadati.
- Gli oggetti vengono suddivisi in chunk da 128 MB, e ogni chunk viene scritto simultaneamente su tre nodi.
- Si aggiorna il file indice, dove vengono registrati gli identificatori e i luoghi di archiviazione.
- Si aggiorna il file di log (registro di scrittura), che viene anch'esso registrato su tre nodi.
- Al cliente viene inviata una notifica di scrittura avvenuta con successo.
Tutte e tre le copie dei dati vengono scritte in parallelo. La scrittura è considerata riuscita solo se tutte e tre le copie sono state scritte con successo.
La lettura avviene in modo più semplice:
- Il cliente richiede i dati.
- Si cerca nel indice il luogo di archiviazione dei dati.
- I dati vengono letti da un nodo e inviati al cliente.
I server sono piuttosto numerosi, quindi diamo un'occhiata al più piccolo Dell EMC ECS EX300. Inizia da 60TB, con la possibilità di crescere fino a 1,5PB. E il suo 'fratello maggiore' Dell EMC ECS EX3000 permette già di archiviare ben 8,6PB per rack.
Deploy
Tecnica Dell ECS CE può essere implementato in modo illimitato. In ogni caso, non ho trovato limitazioni esplicite. Tuttavia, è conveniente scalare clonando il primo nodo, per il quale avremo bisogno di:
- 8 vCPU
- 64GB RAM
- 16GB per il sistema operativo
- 1TB per l'archiviazione
- Ultima release di CentOS minimal
Questa è un'opzione nel caso tu voglia installare tutto da zero. Per noi questa opzione non è rilevante, dato che userò un'immagine OVA per il deploy.
Ma in ogni caso i requisiti sono piuttosto esigenti anche per un singolo nodo, e se seguiamo rigorosamente la lettera della legge, servono quattro nodi.
Tuttavia, gli sviluppatori di ECS CE vivono nel mondo reale, e l'installazione avviene con successo anche con un solo nodo, e i requisiti minimi sono i seguenti:
- 4 vCPU
- 16 GB RAM
- 16 GB per il sistema operativo
- 104 GB di storage
Proprio queste risorse sono necessarie per il deployment di un'immagine OVA. È già molto più umano e realistico.
Puoi ottenere il nodo di installazione ufficiale da . Qui troverai anche una documentazione dettagliata sul deployment all-in-one, ma puoi anche leggere sul sito ufficiale di . Pertanto, non ci fermeremo a lungo sul deployment dell'OVA, è tutto piuttosto semplice. La cosa principale è non dimenticare, prima di avviarla, di espandere il disco al volume desiderato o di attaccare le necessarie.
Avviamo la macchina, apriamo la console e utilizziamo delle credenziali predefinite eccellenti:
- login: admin
- password: ChangeMe
Poi lanciamo sudo nmtui e configuriamo l'interfaccia di rete — IP/mask, DNS e gateway. Ricordando che in CentOS minimal non ci sono net-tools, verifichiamo le impostazioni tramite ip addr.
E poiché solo i coraggiosi conquistano i mari, facciamo yum update e poi riavviamo. In realtà, è piuttosto sicuro, poiché tutto il deployment avviene tramite playbook e tutti i pacchetti importanti di Docker sono bloccati sulla versione corrente.
Ora è il momento di modificare lo script di installazione. Niente finestre carine o pseudo UI — tutto attraverso il tuo editor di testo preferito. Tecnicamente, ci sono due modi: si può eseguire ogni comando manualmente o lanciare subito il configuratore videploy. Esso aprirà semplicemente il configuratore in vim e, al termine, avvierà la sua verifica. Ma non è interessante semplificarsi la vita, quindi eseguiremo due comandi in più. Anche se non ha molto senso, vi ho avvertito =)
Quindi, facciamo vim ECS-CommunityEdition/deploy.xml e apportiamo le modifiche ottimali e minime affinché ECS si attivi e funzioni. L'elenco dei parametri può essere abbreviato, ma l'ho fatto in questo modo:
- licensed_accepted: true Puoi anche non cambiarlo, in tal caso durante il deployment ti chiederà esplicitamente di accettarlo e ti mostrerà una frase carina. Potrebbe anche essere un easter egg.
- Decommentare le righe autonames: e custom: Inserire almeno un nome desiderato per il nodo — il nome host verrà sostituito con esso durante il processo di installazione.
- install_node: 192.168.1.1 Specificare l'IP reale del nodo. Nel nostro caso, indichiamo lo stesso di nmtui
- dns_domain: inseriamo il nostro dominio.
- dns_servers: inseriamo il nostro dns.
- ntp_servers: puoi specificare qualsiasi. Ho preso il primo che ho trovato nel pool 0.pool.ntp.org (diventato 91.216.168.42)
- autonaming: custom Se non si decommenta, la luna si chiamerà 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 indichiamo nuovamente l'IP reale del nodo - ecs_block_devices:
/dev/sdb Повторяем операцию вырезания несуществующих устройств.
In effetti, l'intero file è descritto in dettaglio in , ma chi lo leggerà in un momento così turbolento. È scritto che il minimo necessario è specificare l'IP e la subnet mask, ma nel mio laboratorio tale impostazione ha funzionato male, e ho dovuto espanderla a quanto indicato sopra.
Dopo essere uscito dall'editor, è necessario eseguire update_deploy /home/admin/ECS-CommunityEdition/deploy.yml, e se tutto è stato fatto correttamente, verrà comunicato esplicitamente.
Poi dovrai eseguire videploy, attendere l'aggiornamento dell'ambiente, e puoi avviare l'installazione con il comando ova-step1, e dopo il suo completamento con successo il comando ova-step2. Importante: non fermare l'esecuzione degli script manualmente! Alcuni passaggi possono richiedere tempo considerevole, non essere completati al primo tentativo e sembrare che tutto sia rotto. In ogni caso, è necessario attendere il completamento naturale dello script. Alla fine dovresti vedere un messaggio simile a questo.
Ora finalmente possiamo aprire il pannello di controllo WebUI all'IP che conosciamo. Se nella fase di configurazione non abbiamo modificato nulla, il login di default sarà root/ChangeMe. Possiamo anche iniziare immediatamente a utilizzare il nostro storage compatibile con S3. È disponibile sulle porte 9020 per HTTP e 9021 per HTTPS. Ancora una volta, se non hai modificato nulla, l'access_key: object_admin1 e secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
Ma non anticipo troppo e cominciamo in ordine.
Al primo accesso ti verrà chiesto di cambiare la password in qualcosa di più adeguato, il che è assolutamente giusto. La dashboard principale è estremamente comprensibile, quindi facciamo qualcosa di più interessante che spiegare metriche ovvie. Ad esempio, creiamo un utente che utilizzeremo per accedere allo storage. Nel mondo dei fornitori di servizi, tali utenti sono chiamati tenant. Si fa in Manage > Users > New Object User
Quando creiamo un utente ci viene chiesto di specificare il namespace. Tecnicamente, nulla ci impedisce di crearne quanti più ne servono, quanti sono gli utenti. E viceversa. Questo consente di gestire le risorse in modo indipendente per ogni tenant.
Di conseguenza, selezioniamo le funzioni necessarie e generiamo le chiavi utente. Mi basterà S3/Atmos. E non dimentichiamo di salvare la chiave 😉
L'utente è stato creato, ora è tempo di assegnargli un bucket. Passiamo a Gestisci > Bucket e compiliamo i campi richiesti. Qui è tutto semplice.
Ora abbiamo tutto pronto per un utilizzo praticamente operativo del nostro storage S3.
Configuriamo Veeam
Dunque, come sappiamo, uno degli usi principali degli storage object è l'archiviazione a lungo termine delle informazioni a cui si accede raramente. Un esempio ideale è la necessità di conservare i backup in una location 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 l'aggiunta di un nuovo repository e selezioniamo la voce Object Storage.
Scegliamo ciò per cui è stato tutto progettato — S3 Compatibile.
Nella finestra che appare, digitiamo il nome desiderato e passiamo al passaggio Account. Qui dobbiamo indicare il Service point nel formato , possiamo lasciare il regione così com'è e aggiungere l'utente creato. Il server gateway è necessario se il tuo storage si trova in una location remota, ma questo è già un tema di ottimizzazione dell'infrastruttura e di un articolo separato, quindi qui possiamo tranquillamente saltare.
Se tutto è specificato 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 fino in fondo e godiamoci il risultato.
Nel passaggio successivo è necessario creare un nuovo Scale-out Backup Repository o aggiungere il nostro S3 a uno esistente — sarà utilizzato come Capacity Tier per l'archiviazione in formato archivio. Non è presente, nell'attuale rilascio, la funzione di utilizzare storage compatibili con S3 direttamente come repository normale. Ci sono troppi problemi piuttosto non ovvi da risolvere per questo, ma tutto è possibile.
Accediamo alle impostazioni del repository e attiviamo il Capacity Tier. Lì è tutto chiaro, ma c'è un aspetto interessante: se si desidera che tutti i dati vengano inviati nello storage object il più rapidamente possibile, basta impostare 0 giorni.
Dopo aver completato la procedura guidata, se non si desidera aspettare, si può premere ctrl+click destro sul repository, avviare forzatamente il Tiering job e osservare come iniziano a salire i grafici.
Per ora è tutto. Ritengo di aver dimostrato che gli storage a blocchi non sono così spaventosi come si pensa. Sì, ci sono un sacco di soluzioni e opzioni di implementazione, ma in un solo articolo non si può coprire tutto. Quindi, condividiamo le nostre esperienze nei commenti.
Fonte: habr.com
