Un esperimento distruttivo per garantire il ripristino dei nostri dati
A volte, hai solo bisogno di uno spazio di archiviazione che funzioni. Il lusso di avere una classe di archiviazione presso un provider cloud non è sempre possibile e devi gestire tutto da solo. Questa è la sfida a cui ho dovuto rispondere per il mio cliente in sede nel settore sanitario.
In questo articolo imparerai perché e come installare Rook Ceph per fornire al tuo cluster Kubernetes una classe di archiviazione replicata facile da usare.
Distribuiremo quindi un’app di condivisione file, distruggeremo il nodo su cui è distribuita e vedremo cosa succede. Ceph renderà nuovamente accessibili i nostri file?
Lo storage è sempre stato una sfida in Kubernetes poiché non fornisce nativamente soluzioni di storage ridondanti e distribuite. Con Kubernetes nativo, puoi collegare solo un volume hostPath per l’archiviazione persistente.
Il mio cliente dispone di una propria infrastruttura locale e voleva assicurarsi che nessuno dei suoi dati andasse perso in caso di guasto di uno dei suoi server. La maggior parte delle sue app sono monoliti e non includono nativamente meccanismi di replica dei dati.
Quindi ho dovuto scegliere una varietà di soluzioni di archiviazione. Il mio cliente non aveva bisogno di prestazioni elevatissime ma voleva una soluzione stabile. Sono arrivato a scegliere Rook Ceph perché:
Abbiamo bisogno di un cluster Kubernetes composto da un minimo di 3 nodi e 1 disco collegato vuoto per ciascuno.
Consiglio di utilizzare Scaleway Kapsule per istanziare facilmente un cluster Kubernetes e attribuire dischi non formattati. Una volta avviato il cluster Kubernetes, creeremo un volume (disco) collegato per ciascun nodo:
- Vai a “Istanze”
- Seleziona il tuo nodo
- Fare clic sulla scheda “Volumi collegati”.
- Fare clic su “+” (Crea volume) e creare un nuovo disco
Scarica il tuo kubeconf archiviarlo e inserirlo ~/.kube/config . Ora dovresti ottenere l’accesso al tuo cluster con il tuo kubectl CLI.
1. Questo post del blog ha un repository associato su GitHubcloniamolo per avere tutte le risorse di cui abbiamo bisogno
git clone https://github.com/flavienbwk/ceph-kubernetes
cd ceph-kubernetes
2. Clona il repository Rook e distribuisci l’operatore Rook Ceph
git clone --single-branch --branch release-1.11 https://github.com/rook/rook.git
kubectl create -f ./rook/deploy/examples/crds.yaml
kubectl create -f ./rook/deploy/examples/common.yaml
kubectl create -f ./rook/deploy/examples/operator.yaml
3. Creare il cluster Ceph
kubectl create -f ./rook/deploy/examples/cluster.yaml -n rook-ceph
Attendere alcuni minuti affinché Ceph configuri i dischi. La salute dovrebbe esserlo HEALTH_OK :
kubectl get cephcluster -n rook-ceph
4. Creare le classi di archiviazione
Rook Ceph può fornirti due classi di archiviazione principali. Uno è RBD e ti consente di avere uno spazio di archiviazione replicato ReadWriteOnce modalità. Il secondo che installeremo è CephFS, che ti consente di avere spazio di archiviazione replicato ReadWriteMany modalità. RBD sta per Dispositivo a blocchi RADOS e ti consente di avere una classe di archiviazione per effettuare il provisioning dei volumi nel tuo cluster Kubernetes. Questo supporta solo ReadWriteOnce volumi (RWO). CephFS agisce come un server NFS replicato. Questo è ciò che ci permetterà di creare volumi in ReadWriteMany modalità (RWX).
kubectl create -f ./rook/deploy/examples/csi/rbd/storageclass.yaml -n rook-ceph
kubectl create -f ./rook/deploy/examples/filesystem.yaml -n rook-ceph
kubectl create -f ./rook/deploy/examples/csi/cephfs/storageclass.yaml -n rook-ceph
5. Distribuisci la dashboard Ceph
kubectl create -f ./rook/deploy/examples/dashboard-external-https.yaml -n rook-ceph
Inoltra l’accesso HTTP del dashboard:
kubectl port-forward service/rook-ceph-mgr-dashboard -n rook-ceph 8443:8443
Connettiti con il nome utente admin e la seguente password:
kubectl -n rook-ceph get secret rook-ceph-dashboard-password -o jsonpath="{('data')('password')}"
Dovresti ottenere la seguente pagina navigando https://localhost:8443
Distribuiremo un’app di condivisione file self-hosted (trasferimento psi) per verificare se i nostri volumi si legano correttamente.
1. Distribuire l’app di condivisione file (NodePort 30080)
kubectl create -f ./psitransfer-deployment-rwx.yaml
2. Scopri su quale nodo è distribuito
kubectl get pods -o wide -l app=psitransfer
Recupera l’IP di questo nodo (tramite l’interfaccia Scaleway) e controlla che l’app sia in esecuzione http://nodeip:30080
3. Carichiamo alcuni file
Scarica il 5 MB, 10 MB E 20 MB file da Sito web xcal1.vodafone.co.uk.
Caricali sulla nostra app di trasferimento file. Fare clic sul collegamento visualizzato sullo schermo.
Ora dovresti vedere i file dell’albero importati. Fare clic su di esso e mantieni il collegamento nella scheda del browserlo useremo più tardi.
Dopo aver caricato circa 400 MB di file, possiamo vedere che la replica dei dati è coerente su tutti i dischi. Vediamo che i 3 dischi vengono scritti contemporaneamente mentre carichiamo i file. Nello screenshot seguente, l’utilizzo è dell’1% per ciascun disco: sebbene abbia effettuato il caricamento sullo stesso host, sembra che la replica funzioni come previsto con i dati equamente persistenti sui 3 dischi (OSD). Il disco 2 ha molta attività di “lettura” poiché gli altri 2 dischi sincronizzano i dati da esso.
La dashboard di Ceph ora dovrebbe assomigliare a questa:
Arresteremo il nodo che ospita l’app Web per assicurarci che i dati vengano replicati sugli altri nodi.
- Scopri su quale nodo è distribuita l’app
kubectl get pods -o wide -l app=psitransfer
2. Spegnere il nodo dalla console Scaleway
Questo simula un’interruzione di corrente su un nodo. Dovrebbe diventarlo NotReady dopo diversi minuti:
$> kubectl get node
NAME STATUS ROLES AGE VERSION
scw-ceph-test-clustr-default-5f02f221c3814b47a Ready <none> 3d1h v1.26.2
scw-ceph-test-clustr-default-8929ba466e404a00a Ready <none> 3d1h v1.26.2
scw-ceph-test-clustr-default-94ef39ea5b1f4b3e8 NotReady <none> 3d1h v1.26.2
E il Nodo 3 non è disponibile sul nostro dashboard Ceph:
La dashboard di Ceph ora dovrebbe assomigliare a questa:
3. Riprogrammare il nostro pod
Il nodo pod pianificato non è disponibile. Tuttavia, il nostro pod pensa ancora che sia attivo:
$> kubectl get pods -o wide -l app=psitransfer
NAME READY STATUS RESTARTS AGE IP NODE
psitransfer-deployment-8448887c9d-mt6wm 1/1 Running 0 19h 100.64.1.19 scw-ceph-test-clustr-default-94ef39ea5b1f4b3e8
Eliminalo per riprogrammarlo su un altro nodo:
kubectl delete pod psitransfer-deployment-8448887c9d-mt6wm
Controlla lo stato del pod appena riavviato. La tua app dovrebbe essere nuovamente disponibile al link precedentemente mantenuto.
Per evitare di dover eliminare manualmente il pod da riprogrammare quando un nodo diventa “NotReady”, ridimensiona il numero di repliche della tua applicazione ad almeno 3 per impostazione predefinita.
Ora puoi riavviare il nodo precedentemente spento.
Se le tue applicazioni necessitano di prestazioni migliori e richiedono l’archiviazione a blocchi con modalità di accesso RWO, utilizza il file torre-cefalo-blocco (RBD) classe di archiviazione. Se invece le tue applicazioni necessitano di un file system condiviso con modalità di accesso RWX (CephFS) e conformità POSIX, utilizza il comando cefalo-torre classe di archiviazione.
Se scegli RBD e provi a riprogrammare un pod mentre il suo nodo originale è offline come abbiamo fatto con CephFS, riceverai un errore dal PVC che indica: “Il volume è già collegato esclusivamente a un nodo e non può essere collegato a un altro“. In tal caso, devi solo attendere che il PVC si ricolleghi (ci sono voluti circa 6 minuti affinché il mio cluster riattribuisse automaticamente il PVC al mio pod, consentendone l’avvio).
Prova questo comportamento seguendo il capitolo relativo ai pronti contro termine.
Hai imparato come installare e distribuire un’app con Ceph. Hai anche dimostrato che replica i dati. Complimenti ✨
Tutte le immagini, se non diversamente specificato, sono dell’autore.
Fonte: towardsdatascience.com
