November 24, 2024

PAPERS

A volte la vita ti colpirà alla testa con un mattone

Una definizione e cosa chiedere ai fornitori

Stoccaggio in container è un’area calda in questo momento. Ma è una nuova frontiera, quindi c’è un certo grado di confusione su ciò che viene offerto e il marketing dei fornitori può essere un po ‘confuso.

È accettato che la maggior parte delle applicazioni containerizzate nell’azienda richiedano archiviazione persistente, ma non è sempre così facile definire esattamente come funziona lo stoccaggio di container di un fornitore. Una variante emergente, e quello che sembrerebbe essere il Santo Graal per vari motivi, è archiviazione nativa del contenitore, noto anche come archiviazione nativa del cloud.

Perché il Santo Graal? Perché è la forma di stoccaggio dei container che più si conforma all’etica generale alla base della containerizzazione. Cioè, tutto ciò che è necessario per gestire lo storage può essere incapsulato in contenitori ed eseguito da Kubernetes. È essenzialmente una forma di archiviazione definita dal software che viene eseguito in contenitori.

In altre parole, è lo storage che, come qualsiasi altro servizio che fa parte del panorama applicativo complessivo, può essere fornito tramite codice ed è portabile con l’applicazione, senza dipendenze hardware.

Ciò è importante per alcuni motivi e il principale tra questi è l’influenza del cloud sul modo in cui si sta dirigendo l’IT. L’aumento dell’uso del lavoro ibrido e multicloud significa che la capacità di spostare i carichi di lavoro tra data center e posizioni cloud è essenziale.

Motivi secondari includono la crescente necessità di rendere l’archiviazione una delle cose che gli sviluppatori forniscono tramite codice e/o clic, piuttosto che inviare un ticket.

Fondamenti di stoccaggio in container

Il fondamenti dell’archiviazione persistente di Kubernetes si basano su una serie di API (Application Programming Interface). In primo luogo, le dichiarazioni di volume persistenti (PVC) fatte dalle applicazioni. Questi vivono con i contenitori dell’applicazione e viaggiano con esso per specificare la capacità richiesta, il livello di archiviazione e così via.

Nel frattempo ci sono volumi persistenti (PV) e classi di storage, che sono attributi dello storage stesso, che descrivono la natura dello storage persistente disponibile e lo abbinano ai PVC dell’applicazione in Kubernetes.

Tale spazio di archiviazione può essere locale rispetto ai server su cui viene eseguito il cluster Kubernetes o esterno, in un array di archiviazione, forse. Se lo spazio di archiviazione è residente su uno spazio di archiviazione condiviso esterno, potrebbe essere fornito ad applicazioni containerizzate da plug-in come CSI (interfaccia di stoccaggio del contenitore).

Allora, cos’è lo storage nativo del contenitore?

Tenendo conto di quanto descritto finora, e in particolare dell’etica delle operazioni cloud-native e della containerizzazione, c’è un concetto fondamentale che dovrebbe definire lo storage container-native.

Ovvero, tale archiviazione dovrebbe essere gestita dal cluster Kubernetes per qualificarsi realmente come container-nativa ed essere aggregata da supporti direttamente accessibili al cluster (qualcosa come Rook, forse?).

Nel frattempo, per iniziare a competere con il set di funzionalità offerto dai prodotti di archiviazione maturi, i prodotti di archiviazione nativi dei contenitori dovrebbero includere anche servizi di archiviazione come replica, istantanee, riduzione dei dati, qualità del servizio e crittografia, ma questi non sono fondamentali per una definizione .

Ora, è vero che è possibile eseguire il provisioning dell’archiviazione sui contenitori dall’archiviazione basata su array e, in una certa misura, gestirlo dal cluster. Ma questo, a volte chiamato storage pronto per i container, contravviene all’idea che tutto dovrebbe essere gestito da Kubernetes perché nessun array di storage aziendale è impostato e dimenticato. Tutto ciò richiede la gestione e il provisioning nell’array.

Potrebbe anche contravvenire ai principi del cloud-native in quanto i carichi di lavoro potrebbero non essere molto portabili, anche se in teoria dovresti assicurarti che il giusto tipo di supporto fosse disponibile ovunque fosse necessario eseguire applicazioni containerizzate, anche se strettamente container-native, come definito qui.

Possiamo ridurre tutto questo a domande che potrebbero essere poste ai fornitori? Può essere. Ecco un tentativo:

  • Il tuo software di archiviazione viene eseguito in contenitori?
  • E virtualizza, fornisce ed esegue lo storage da lì?
  • Quale gestione dello storage è necessaria esternamente a Kubernetes?

Fornitori di storage nativi per container

Ecco una selezione di fornitori che offrono lo storage nativo del container: