Verso altri cloud provider

(i) Confronto generale in minuti

(a) (b) (c)

0 5 10 15 20 25 30 35

min

snapshot backup snapshot restore

(ii) Tempo riportato in percentuale

(a) (b) (c)

0%

20%

40%

60%

80%

100%

restic backup restic restore

0%

20%

40%

60%

80%

100%

Figura 4.13: Confronto tra snapshot e Restic per la migrazione verso altre regioni

rispetto alle altre con i valori descritti in percentuale sul totale dei quattro tipi di dati. Quest’ultimo grafico vuole evidenziare le differenze di ciascuna operazione di backup e ripristino con i due metodi utilizzati ed è possibile leggerlo prendendo come riferimento l’asse delle ordinate di sinistra per focalizzarsi sugli snapshot o quello di destra per iniziare il confronto con Restic. I colori con tonalità sul blu sono legati al metodo con snapshot, mentre il rosso identifica Restic.

Al fine di analizzare uno scenario multi-cloud, è stato deciso di usufruire dei servizi di AWS ed Azure. Sono quindi stati creati due cluster OpenShift in versione 4.9.11 formati da 1 control plane e 2 nodi worker. Per cercare di utilizzare risorse dello stesso tipo è stato deciso di utilizzare le macchine virtuali m5a.xlarge nella regione eu-south-1 di AWS, mentre su Azure sono state richieste le VM Standard_D4s_v3 nella regione germanywestcentral. Entrambi i tipi di macchine virtuali hanno 4 vCPU e 16 GiB di memoria.

Si è deciso di utilizzare un volume di dimensione pari a 50 GiB l’applicazione stateful di mysql. Inoltre, sono stati creati due bucket nelle stesse regioni dei cluster per permettere a Velero, in versione 1.7.1, di salvare i dati sia su AWS che su Azure. I nomi dei bucket sono stati dati seguendo le convenzioni consigliate dai cloud provider:

• st-velero-aws-eu-south-1

• st-velero-azure-germanywestcentral-1

Per poter ripristinare con successo le applicazioni stateful in un cloud provider diverso è stato necessario aggiungere una informazione a Velero, cioè il tipo di storage utilizzato per il provisioning dei volumi. Infatti se si utilizzano Persistent Volume tramite i dischi offerti dai cloud provider, è necessario configurare cor-rettamente un StorageClass opportuno. Questo processo avviene in automatico tramite l’installazione del cluster, ma la risorsa StorageClass è sicuramente diversa tra cloud provider differenti. Dunque, se si vuole migrare un PV in un contesto multi-cloud è necessario aggiungere, con nomenclatura chiave-valore, una risorsa di tipo ConfigMap nel progetto di Velero specificando come chiave il nome del vecchio StorageClass e come valore quello nuovo. Di seguito è riportato il manifest file di tipo ConfigMap utilizzato per la migrazione da AWS ad Azure.

1 apiVersion: v1

2 kind: ConfigMap

3 metadata:

4 name: change-storage-class-config

5 namespace: velero

6 labels:

7 velero.io/plugin-config: ""

8 velero.io/change-storage-class: RestoreItemAction

9 data:

10 gp2: managed-premium

Si sono identificati quattro diversi scenari, che evidenziano due strategie di migrazione; in questo modo è stato possibile analizzare diverse configurazioni di DR e verificare l’effettiva funzionalità della soluzione tecnologica scelta.

1. Migrazione da AWS ad Azure:

1.1 utilizzando il bucket situato nella regione di partenza (AWS);

1.2 utilizzando il bucket creato nella regione di destinazione (Azure).

2. Migrazione da Azure ad AWS

2.1 utilizzando il bucket situato nella regione di partenza (Azure);

2.2 utilizzando il bucket creato nella regione di destinazione (AWS).

I risultati sono interessanti e diversi dalle aspettative; essi sono stati riportati nelle figure 4.14 per quanto riguarda la migrazione da AWS ad Azure e 4.15 per la migrazione nel verso opposto. In tutti gli scenari sono stati considerati i servizi utilizzati anche nei sottocapitoli precedenti, in particolare l’applicazione stateless definita in 4.2.1 e quella stateful 4.2.2.

L’applicazione stateless non ha dato problemi durante la fase di ripristino e anche i tempi sono come quelli discussi nel sottocapitolo 4.4.1, perciò si può utilizzare la formula 4.1 per stimare il tempo di recupero.

Per quanto riguarda il DR dell’applicazione stateful si sono riportati i grafici contenteti solo i risultati più significativi, cioè con un volume di dati pieno di file;

in particolare utilizzando i due tipi di file descritti nel sottocapitolo precedente: (b) e (c).

Negli scenari considerati si è voluto confrontare i tempi per eseguire backup e recupero dati utilizzando archiviazioni ad oggetti differenti, cioè offerti da fornitori diversi e in due posizioni geografiche diverse. Diversamente da quanto si poteva immaginare, la distanza geografica sembra che non abbia influenzato questo tipo di prova poiché sono registrate differenze dell’ordine di pochi punti percentuali, in media circa 3 %, con eccezione per i risultati riportati nel grafico 4.14i.

Si sono registrate delle anomalie per quando riguarda il backup effettuato sul cluster AWS verso il bucket di Azure. Tramite l’utilizzo del volume con file di tipo (b) la differenza rilevata può essere legata esclusivamente al diverso tipo di bucket; infatti il Blob di Azure non ha mai registrato una velocità di scrittura superiore a 36 MiB/s e quindi un tempo inferiore a 23 min. Analizzando i tempi con i file di tipo (c) si può stilare una seconda ipotesi, più realistica, legata alla funzionalità del bucket; infatti utilizzando file di dimensione 4 MB la tecnologia di archiviazione non usa l’HTBB [28]. La tecnologia di High-Throughput Block Blob è stata implementata da Azure per aumentare la velocità di scrittura e gestione delle richieste di PUT ed è abilitata di default sul tipo di archiviazione utilizzato,

cioè Blob Storage. Questa tecnologia, però, funziona solo per richieste PUT di dimensione superiore a 4 MiB e quindi non è attiva con lo scenario considerato.

(i) Backup di AWS in bucket differenti

(b) (c)

20 40 60 80

min

(1.1) AWS (1.2) Azure

(ii) Restore su Azure da bucket differenti

(b) (c)

6 12 18

min

(1.1) AWS (1.2) Azure Figura 4.14: Migrazione da AWS ad Azure

(i) Backup di Azure in bucket differenti

(b) (c)

6 12 18 24

min

(2.1) Azure (2.2) AWS

(ii) Restore su AWS da bucket differenti

(b) (c)

2 4 6 8

min

(2.1) Azure (2.2) AWS Figura 4.15: Migrazione da Azure ad AWS

Un ulteriore commento è legato alle velocità di scrittura e lettura sui bucket aggregando i risultati per i due cluster utilizzati. Si può notare come il cluster OpenShift installato su AWS riesca a scrivere e leggere circa 2.5 volte più veloce rispetto a quello creato su Azure. Questo dato lo si può acquisire dai tempi di

backup e restore registrati con il bucket di AWS, ma anche dalle tempistiche del recupero tramite il bucket di Azure. Mentre il backup tramite quest’ultima archiviazione ad oggetti risulta essere diverso e verrà commentato di seguito.

Se si analizzano i tempi di backup con il bucket di Azure si può notare un compor-tamento insolito, cioè tempi molto alti legati al cluster AWS, allo stesso tempo è stato anche l’unico test in cui le risorse del cluster sono state utilizzate meno. Si è registrato infatti un utilizzo di vCPU di circa 0.4 durante il backup del il volume di tipo (b) e di 0.2 vCPU per il (c). Se si esegue un calcolo per ipotizzare un backup con un utilizzo della vCPU al 100 %, si possono trovare dei tempi molto vicini a quelli misurati con il bucket di AWS. Per questo motivo, si è potuto constatare che le prove sono state eseguite con risorse diverse a livello di prestazioni, perciò i dati acquisiti non possono essere utilizzati in modo generalizzato.

In ultimo, si può affermare che i dati registrati in questi tipi di scenari sono soggetti a variazione da tante incognite, tra cui le prestazioni delle VM utilizzate, la velocità dei dischi per i volumi e le capacità legate al sistema di archiviazione ad oggetti utilizzato, oltre che alla posizione geografica. Pertanto si è potuto solo commentare le prove eseguite in ambiente multi-cloud, senza però acquisire dei tempi generalizzabili.