Ceph Octopus: note di una evoluzione…

(Estratto da un articolo di Sage Weil: https://ceph.io/ceph-management/introducing-cephadm)

Negli anni è emersa un'ampia varietà di strumenti di distribuzione Ceph con l'obiettivo di rendere lo storage Ceph più facile da installare e gestire. La maggior parte di questi ha sfruttato strumenti già esistenti come Ansible, Puppet e Salt, portando con sé un ecosistema esistente di utenti e un'opportunità per allinearsi a un investimento esistente da parte di un'organizzazione che utilizza un particolare strumento. Di conseguenza, tuttavia, l'investimento della comunità di Ceph è stato frammentato in molti sforzi diversi, i nuovi utenti devono affrontare una difficile scelta di strumenti all'inizio e i tentativi di semplificare l'esperienza e l'integrazione con Ceph stesso sono stati difficili.

Come molti altri, mi sono personalmente attaccato al datato strumento ceph-deploy, che ha il vantaggio di essere estremamente semplice da usare e capire (almeno per qualcuno che ha familiarità con Ceph), e ha la bella proprietà di non richiedere un investimento iniziale nell'installazione e nell'apprendimento di un altro strumento. Tuttavia, oggigiorno il ceph-deploy non è più manutenuto e non funziona nemmeno con alcune distribuzioni più recenti come RHEL / CentOS 8.

Soprattutto, tuttavia, nessuno di questi strumenti ha svolto un ottimo lavoro nel risolvere il problema principale: rendere Ceph molto facile da installare per un nuovo utente e rendere un cluster Ceph facile da manutenere nel tempo grazie alla perfetta integrazione con Ceph CLI e GUI . Una nuova API dell'orchestrator è stata introdotta per la prima volta in Ceph Nautilus per fornire un modo generico a Ceph - la CLI e il dashboard - di interagire con il suo ambiente di distribuzione, sia che si tratti di Rook o ceph-ansible o DeepSea, ma solo con Octopus questo ha raggiunto un livello di maturità in cui fornisce un'astrazione significativa su più backend: Rook per gli ambienti Kubernetes e Cephadm per tutti gli altri.

Uno sguardo a Cephadm

L'obiettivo di Cephadm è fornire un livello di installazione e gestione completo, robusto e ben manutenuto che può essere utilizzato per chiunque non utilizzi Ceph in Kubernetes. Gli obiettivi che ci siamo prefissati includono:

• Distribuzione di tutti i componenti nei contenitori. L'utilizzo dei contenitori semplifica la gestione delle dipendenze e il carico di pacchetti tra le diverse distribuzioni. Stiamo ancora sviluppando pacchetti RPM e Deb, ovviamente, ma man mano che più utenti passano a Cephadm (o Rook) e alle build del contenitore, vedremo meno bug specifici del sistema operativo.
• Stretta integrazione con l'API dell'orchestrator. L'interfaccia dell'orchestratore di Ceph si è evoluta ampiamente durante lo sviluppo di Cephadm per adattarsi all'implementazione e astrarre in modo pulito la funzionalità (leggermente diversa) presente in Rook. Il risultato finale è qualcosa che sembra, si sente e si comporta come una parte di Ceph.
• Nessuna dipendenza dagli strumenti di gestione. Sistemi come Salt e Ansible sono ottimi se distribuiti su larga scala in una grande organizzazione, ma fare in modo che Ceph dipenda da un tale strumento significa che c'è un altro pezzo di software che gli utenti possono imparare. Ancora più importante, la distribuzione risultante finisce per essere molto più complicata, più difficile da eseguire il debug e (cosa più significativa) più lenta di qualcosa che è stato creato appositamente per gestire solo Ceph.
• Dipendenze minime del sistema operativo. Cephadm richiede Python 3, LVM e un runtime del contenitore, Podman o Docker. Qualsiasi distribuzione Linux moderna andrà bene.
• Isolare i cluster l'uno dall'altro. Il supporto di più cluster Ceph coesistenti sullo stesso host è stato storicamente uno scenario di nicchia, ma si è presentato e disporre di un modo robusto e generico per isolare i cluster l'uno dall'altro rende il test e la ridistribuzione dei cluster un processo sicuro e naturale sia per gli sviluppatori che per gli utenti .
• Aggiornamenti automatici. Una volta che Ceph "possiede" la propria distribuzione, può assumersi la responsabilità di aggiornare Ceph in modo sicuro e automatizzato.
• Facile migrazione da strumenti di distribuzione "legacy". Dobbiamo consentire alle implementazioni Ceph basate su strumenti esistenti come ceph-ansible, ceph-deploy e DeepSea di passare senza problemi a Cephadm.

L'obiettivo con tutto ciò è quello di focalizzare l'attenzione degli sviluppatori Ceph e della comunità degli utenti su due sole piattaforme per la distribuzione e la gestione di Ceph - Cephadm per le implementazioni "bare metal" e Rook per l'esecuzione di Ceph in Kubernetes - e per fornire una simile esperienza di gestione per entrambi.

Guardando oltre…

Con la versione iniziale di Octopus, Cephadm ha un solido supporto per i servizi Ceph principali: RADOS, CephFS, RBD e RGW. Un certo numero di servizi secondari sono in fase di sviluppo attivo, incluso il supporto per gateway NFS e iSCSI, e il supporto CIFS (tramite Samba) dovrebbe seguire dopo. Tutte queste modifiche verranno trasferite su Octopus non appena saranno completate.

Nel frattempo, ci aspettiamo anche di migliorare la robustezza e l'intelligenza dell'algoritmo di "pianificazione" che decide dove eseguire i servizi. In questo momento, Cephadm distribuisce semplicemente i daemon di servizio tra gli host, ma (per impostazione predefinita) sceglie questi host a caso. Vorremmo migliorare questo impostando limiti di risorse sui contenitori di daemon (ad esempio, CPU e memoria) e scegliendo la posizione dei daemon in modo intelligente in base alle risorse disponibili su ciascun host.

Infine, ci aspettiamo di dedicare molto tempo nel prossimo ciclo di sviluppo a far emergere più funzionalità dell'orchestrator attraverso la dashboard Ceph per semplificare l'esperienza utente complessiva, in particolare per operazioni comuni come la distribuzione iniziale, l'espansione del cluster e la sostituzione di dispositivi di archiviazione guasti.