Differenza tra risorse on demand, modelli di servizio e modelli di deployment

Differenza tra risorse on demand, modelli di servizio e modelli di deployment

Infrastrutture cloud

I software descritti nell’articolo sul Cluster computing offrono molti vantaggi dal punto di vista delle applicazioni e dell’amministratore del cluster. Restano, comunque, alcune difficoltà, che potrebbero scoraggiare la realizzazione di un sistema di questo tipo. In particolare, per realizzare un cluster, dal punto di vista fisico, è necessario reperire ed installare l’hardware, per realizzare i vari nodi e l’infrastruttura di rete. Tali operazioni sono, sicuramente, molto onerose, sia dal punto di vista dei costi, che della progettazione e della manutenzione. Inoltre, dopo aver realizzato fisicamente il cluster, è necessario configurare ed installare il software di gestione sui vari nodi, operazione che richiede elevate competenze tecniche.

La soluzione a questi problemi può essere individuata nel cloud computing, cioè un servizio o un insieme di servizi che permettono di richiedere dinamicamente un insieme di risorse; tali risorse, potrebbero essere, ad esempio, macchine complete sulle quali eseguire delle applicazioni o, perfino, un intero cluster di macchine preconfigurate.

Differenza tra risorse on demand, modelli di servizio e modelli di deployment

Risorse on demand

Una delle caratteristiche essenziali del cloud computing è la possibilità di richiedere dinamicamente determinate risorse, tramite servizi che potrebbero essere esposti all’utilizzatore attraverso delle API. Queste risorse vengono reperite da una pool, condivisa tra tutti gli utilizzatori. Nel momento in cui, un utilizzatore richiede determinate risorse, queste vengono selezionate dalla pool e assegnate al richiedente. Le risorse potranno poi essere rilasciate dall’utilizzatore e ritornare nella pool in qualsiasi momento. Ciò permette all’utilizzatore di ridimensionare dinamicamente la quantità di risorse a disposizione per le proprie applicazioni, in base alle necessità.

In generale, le risorse offerte da un’infrastruttura cloud possono essere classificate in tre categorie di base: elaborazione, memoria e rete. La combinazione di queste può definire risorse più complesse, offerte dal cloud provider per velocizzare e facilitare il deployment di determinate entità frequentemente utilizzate o per offrire al cliente servizi di più alto livello.

Elaborazione

È la categoria che comprende tutte quelle risorse che offrono capacità computazionale per l’esecuzione di applicazioni. Si differenziano in base al tipo di istanza computazionale offerta, che potrebbe essere, ad esempio:

  1. Macchina fisica: Il cloud provider permette di allocare nuove macchine fisiche dinamicamente su richiesta. Cloud provider di questo tipo vengono chiamati anche bare-metal cloud.
  2. Macchina virtuale: Il cloud provider permette di allocare nuove macchine virtuali, cioè macchine che offrono le stesse funzionalità di macchine fisiche, ma che non possiedono un hardware fisico dedicato. L’hardware fisico è gestito da un software, denominato hypervisor. Tale hypervisor può creare e gestire un insieme di macchine virtuali, fornendo loro parte dell’hardware fisico sotto forma di hardware virtualizzato. Attraverso l’hardware virtualizzato, più macchine virtuali possono condividere lo stesso hardware fisico, mantenendo, comunque, un elevato isolamento tra di loro. Le macchine virtuali, rispetto alle macchine fisiche, sono molto più facili da installare, configurare e gestire; per questo, sono ampiamente utilizzate in ambito cloud. Inoltre, il software in esecuzione all’interno della macchina virtuale, grazie alla virtualizzazione dell’hardware, sarà eseguito allo stesso modo su qualsiasi hardware fisico, garantendo un’elevata portabilità. Va sottolineato però, che la virtualizzazione dell’hardware e la necessità di un sistema operativo per ogni macchina, porta ad un notevole spreco di risorse.
  3. Container: Il cloud provider permette di allocare dei container, cioè pacchetti software contenenti l’applicazione, le sue dipendenze e tutto il necessario per poterla eseguire in maniera isolata ed indipendente dal sistema operativo sottostante. Rispetto alle macchine virtuali, i container possono sprecare meno risorse, poiché non virtualizzano l’hardware, ma si appoggiano, invece, direttamente sul sistema operativo della macchina che li ospita. Nonostante ciò, l’isolamento viene comunque garantito, anche se in maniera ridotta, grazie a particolari meccanismi del sistema operativo che li ospita.
  4. Cluster: Il cloud provider permette di allocare interi cluster, cioè gruppi di macchine, virtuali o fisiche, gestite come un unico sistema. Le varie macchine potrebbero non essere configurate, cioè essere semplicemente un gruppo di macchine sulla stessa rete, provviste esclusivamente del sistema operativo. In questo caso, sarà compito dell’amministratore, installare, manualmente o attraverso particolari tool, il cluster management software che ritiene più adatto. Altrimenti, il cloud provider potrebbe offrire un cluster preconfigurato, già dotato di un cluster management software ed immediatamente utilizzabile. In quest’ultimo caso si può parlare di Cluster as a Service.

Memoria

È la categoria che comprende tutte quelle risorse che offrono capacità di archiviazione, come dischi, volumi persistenti, database o repository. Le risorse di elaborazione potrebbero usufruire di questo tipo di risorse per salvare persistentemente i propri dati, che potrebbero consistere, ad esempio, in interi dischi relativi a macchine virtuali in esecuzione, in file di configurazione, in segreti come password e chiavi o in singoli record di un database. Spesso, le risorse di archiviazione sfruttano tecnologie di replicazione e sharding, per essere tolleranti ai guasti e per migliorare le performance.

Rete

È la categoria che comprende tutte quelle risorse che permettono di modellare la rete presente fra le varie risorse di elaborazione. Alcune delle principali risorse di rete potrebbero essere, ad esempio, subnet di rete o LAN virtuali, router di rete, switch, gateway o firewall. In generale, la possibilità di definire e riconfigurare tramite software la rete presente tra i vari nodi di un sistema, viene detta Software Defined Networking (SDN).

Modelli di servizio

Il punto di forza delle infrastrutture cloud è la loro capacità di offrire, tramite un servizio, risorse on demand. In base alle modalità ed al tipo di risorse offerte, cioè se il cloud provider fornisce semplicemente risorse base o se invece fornisce risorse e servizi più complessi, è possibile classificare i cloud provider, come specificato dal NIST, in tre categorie:

  1. Infrastructure as a Service (IaaS): Viene fornita al cliente la possibilità di richiedere risorse base, cioè di elaborazione, memoria o rete. Il cliente potrà utilizzare tali risorse per eseguire un qualsiasi software, come un particolare sistema operativo o un’applicazione. Il cliente non dovrà gestire l’infrastruttura cloud sottostante, ma avrà un controllo completo delle risorse richieste.
  2. Platform as a Service (PaaS): Viene fornita al cliente la possibilità di effettuare il deployment, sull’infrastruttura cloud, di applicazioni, create sfruttando librerie, servizi o tool supportati dal provider. Il cliente non avrà il controllo né dell’infrastruttura cloud sottostante né delle risorse base utilizzate dal provider per eseguire le applicazioni dell’utente; ha però il completo controllo delle proprie applicazioni e, eventualmente, la possibilità di configurare l’ambiente di esecuzione.
  3. Software as a Service (SaaS): Viene fornita al cliente la possibilità di usufruire di applicazioni in esecuzione sull’infrastruttura cloud del provider. L’utente potrà accedere all’applicazione sfruttando, ad esempio, un’interfaccia web o un’application programming interface (API). Il cliente non avrà il controllo né dell’infrastruttura cloud sottostante né delle risorse base utilizzate dal provider per eseguire l’applicazione e neppure il controllo dell’applicazione stessa. Potrà però avere il controllo, eventualmente, di alcune configurazioni utente dell’applicazione.

Queste categorie potrebbero essere considerate come un’architettura a livelli, in cui il livello base è composto dai servizi IaaS e, al di sopra di esso, si posizionano prima il livello PaaS e poi SaaS. Ognuno dei livelli, per realizzare i propri servizi, potrebbe sfruttare quelli del livello sottostante.   In realtà, ciò non è obbligatorio: si potrebbe, ad esempio, realizzare un modello SaaS senza implementare i livelli sottostanti, anche se, probabilmente, sarebbero richiesti sforzi maggiori, poiché non si ha la possibilità di sfruttare gli automatismi dei livelli sottostanti.

Oltre a queste categorie di base, stanno emergendo ulteriori categorie, che spesso, sono una combinazione o un caso specifico di quelle appena descritte. Il numero di queste categorie è in continuo aumento, poiché, spesso, vengono coniate per fini puramente commerciali e non perché ve ne sia realmente la necessità. In generale, ricadono nel cosiddetto XaaS (Anything as a Service), cioè fornire qualsiasi cosa attraverso un servizio. Tra queste:

  1. Function as a Service (FaaS): Il cliente può inviare direttamente al cloud provider il codice delle funzioni da eseguire. Tali funzioni verranno eseguite senza che l’utente debba installare o configurare l’ambiente di esecuzione. Questo tipo di modello è conosciuto anche con il nome di serverless computing. Un esempio di cloud provider che offre questo modello è AWS Lambda.
  2. Cluster as a Service: Viene fornita al cliente la possibilità di richiedere interi cluster, preconfigurati o meno. Alcuni esempi di cloud provider che offrono questo modello sono Amazon EKS o Google Kubernetes Engine; entrambi permettono di richiedere un cluster preconfigurato con Kubernetes.
  3. Database as a Service (DBaaS): Viene fornita al cliente la possibilità di accedere ad un servizio di database, senza dover configurare l’infrastruttura sottostante. Un esempio di cloud provider che offre questo modello è Amazon Relational Database Service (RDS).
  4. Container as a Service (CaaS): Viene fornita al cliente la possibilità di effettuare il deployment, sull’infrastruttura cloud, di applicazioni containerizzate. Rispetto a PaaS, l’utente ha un controllo maggiore delle risorse base utilizzate dal provider, poiché può specificare le risorse e l’ambiente necessari al container per operare correttamente. Contrariamente a IaaS, che utilizza come risorsa base macchine virtuali o bare-metal, CaaS utilizza, come risorsa base, i container. Si posiziona quindi tra un modello IaaS e PaaS. Un esempio di cloud provider che offre questo modello è AWS Fargate.
  5. Metal As A Service: Viene fornita al cliente la possibilità di richiedere ed allocare intere macchine fisiche. Metal As A Service corrisponde al nome del tool per realizzare bare-metal cloud offerto da Canonical, MAAS.

Uno degli obiettivi di questa trattazione sarà quello di effettuare il deployment di un cluster di elaboratori in maniera automatica. Tale automatismo potrà essere raggiunto, senza troppe difficoltà, sfruttando i servizi messi a disposizione da un cloud. In particolare, sarà necessario adottare un’infrastruttura cloud che offra, almeno, il modello IaaS, per poter allocare le macchine con le quali realizzare il cluster. Inoltre, poiché le macchine dovranno essere fisiche e non virtuali, sarà necessario adottare tecnologie per realizzare un bare-metal cloud. Successivamente, sfruttando il livello IaaS appena definito, si realizzerà un modello riconducibile al Cluster as a Service, permettendo, in maniera automatica, di realizzare un cluster Kubernetes preconfigurato.

Modelli di deployment

Ogni infrastruttura cloud può essere classificata in base al numero ed al tipo di soggetti coinvolti nella condivisione delle risorse fisiche. Il NIST individua quattro categorie:

  1. Public Cloud: I servizi vengono offerti attraverso una rete aperta al pubblico. L’infrastruttura cloud è quindi condivisa tra più clienti e, per questo, offre dei livelli di sicurezza ed isolamento potenzialmente non sufficienti per applicazioni critiche. L’hardware dell’infrastruttura cloud è gestito interamente dal cloud provider e si trova nella sua sede. Attualmente, i principali provider cloud pubblici sono Amazon Web Services, Google Cloud Platform e Microsoft Azure.
  2. Private Cloud: L’infrastruttura cloud è dedicata interamente ad un singolo cliente. Poiché l’hardware non è condiviso offre i livelli di sicurezza ed isolamento massimi. L’hardware dell’infrastruttura cloud potrebbe essere gestito da un provider esterno o direttamente dal cliente e potrebbe essere collocato internamente alla sede del cliente o all’esterno. Un’infrastruttura cloud privata gestita interamente da un’organizzazione offre, sicuramente, il grado più elevato di sicurezza ma richiede anche ingenti sforzi economici e competenze interne. In quest’ultimo caso, l’organizzazione, per realizzare l’infrastruttura, dovrà adottare tecnologie e software appositi. Attualmente, i principali software per la realizzazione di cloud privati sono OpenStack, CloudStack, VMware vSphere o, per la realizzazione di bare-metal cloud, Canonical Metal As A Service (MAAS).
  3. Community Cloud: L’infrastruttura cloud è dedicata ad un gruppo di organizzazioni, con obiettivi comuni, che hanno scelto di cooperare per la realizzazione dell’infrastruttura cloud. L’hardware dell’infrastruttura cloud potrebbe essere gestito da una o più organizzazioni del gruppo e potrebbe essere collocata in sede o presso un provider esterno. Offre un grado di sicurezza intermedio tra il public cloud ed il private cloud.
  4. Hybrid Cloud: L’infrastruttura cloud è composta da due o più distinte infrastrutture cloud (public, private o community), che mantengono la loro indipendenza ma che cooperano per raggiungere un determinato obiettivo.

Per raggiungere l’obiettivo principale di questa trattazione, che prevede di realizzare un cluster con hardware fisico gestito privatamente, sarà necessario adottare il modello private cloud, sfruttando uno dei possibili software per realizzare cloud di questo tipo.

 

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *