Tag: creazione

Pubblicato il

Veeam & Google Cloud Platform – Parte 1

Il primo articolo del 2022 è dedicato a come proteggere le istanze Google (GCP).

Il flusso e l’architettura di protezione è riportato nell’immagine 1 dove sono presenti due componenti Veeam.

  1. L’ istanza Veeam Backup for Google Platform (VBGP) ha il compito di realizzare backup e ripristini delle istanze GCP.
  2. Veeam Backup & Replication (VBR) ha l’onere di gestire centralmente la movimentazione dei dati di Backup da e per il cloud (Data Mobility).

Immagine 1

  • Nota 1: VBGP può essere installato in modalità stand alone oppure utilizzando il wizard di VBR.
  • Nota 2: Il presente articolo mostrerà come agganciare da VBR un istanza VBGP già presente in GCP.

Vediamo in modalità dettagliata i passaggi:

Dalla console di VBR scegliamo la voce Backup Infrastructure.

Cliccando con il tasto destro del mouse, selezioniamo la voce add server e successivamente Google Cloud Platform (vedi immagine 2)

Immagine 2

Il prossimo passaggio è quello di inserire le credenziali di accesso al Service Account di Google (immagine 3)

Immagine 3

Il wizard prosegue chiedendovi di inserire il nome del server VBGP già creato (immagine 4)

Immagine 4

Dopo aver selezionato la tipologia di rete presente (immagine 5) il passaggio successivo è quello di inserire le credenziali di accesso al Repository (immagine 6).

Ricordo che la best practice di protezione è quella di effettuare il backup dell’istanza come snapshot, successivamente riversare la snapshot verso il Cloud Object Storage di Google.

Si rispetta così la regola del 3-2-1, avere cioè 3 copie dei dati (Produzione + Snapshot + Object Storage) su due differenti media (Storage primario + Object Storage) con una copia offsite (Object storage dovrebbe afferire ad un’altra region).

Immagine 5

Immagine 6

Concluso il wizard, sempre dalla console di VBR possiamo collegarci alla console al server VBGP (immagine 7) per iniziare a creare policy di protezione.

Immagine 7

Dopo aver inserito le credenziali di accesso (immagine 8)

Immagine 8

è possibile monitorare l’ambiente attraverso un overview delle istanze presenti, di quelle protette (immagine 9 & 10)

Immagine 9

Immagine 10

Gestire le politiche di protezione attraverso:

La creazione delle policy di Backup, indicando nome (immagine 12), selezionando il progetto (immagine 13), la region (immagine 14), le risorse (immagine 15), il target di Backup (immagine 16), la schedulazione e la tipologia di backup (immagini da 17 a 19)

Immagine 11

Immagine 12

Immagine 13

Immagine 14

Immagine 15

Immagine 16

Immagine 17

Immagine 18

Immagine 19

Le ultime due voci indicano la stima dei costi mensili per realizzare la policy di backup (immagine 20) e l’impostazione dei retry e delle notifiche (immagine 21)

Immagine 20

Immagine 21

Terminata la configurazione e dal monitoraggio verificato che la policy si è completata con successo, è possible procedere al ripristino (immagine 22).

Immagine 22

Le opzioni disponibili sono:

  • Intera Istanza
  • File e Cartelle

Le prossime immagini  (23-24-25) mostrano i passaggi chiave per ripristinare l’ìntera istanza.

Immagine 23

Immagine 24

Immagine 25

Nel prossimo articolo vedremo come poter proteggere e rispristinare un DB Sql presente in un’istanza GCP

A presto

Pubblicato il

Kubernetes: Pods

Nei precedenti articoli, abbiamo visto che i container sono dei luoghi “astratti” dove girano le applicazioni sotto forma di immagini.

I POD sono l’aggregazione di più container.

Un servizio è l’aggragazione di più POD.

L’immagine di figura 1 mostra il concetto appena esposto.

Figura 1

 

Tutte le applicazioni (immagini) presenti all’interno dello stesso POD, avranno lo stesso indirizzo IP (condiviso) e lo stesso Hostname (UTS NameSpace).

La comunicazione tra i container all’interno dello stesso HOST avviene attraverso POSIX o le IPC di System V

Immaginate ora di voler erogare il servizio “the-gable-svc“, costruito con due immagini (container): un Database e un Front-End.

In fase di progetto è meglio disegnare un unico POD che contenga i due contanier (figura 2) oppure due POD con ognuno un container (figura 3)?  (1POD x 2 CONTAINER oppure 2 POD x 1 CONTAINER)

Figura 2

Figura 3

Per rispondere accuratamente è necessario comprendere quale applicazione ha la necessita di maggiore scalabilità e flessibilità.

Nel nostro esempio è il DB che per gestire picchi di accesso, potrebbe richiedere maggiori risorse (RAM & CPU).

Se avessi disegnato un unico POD, l’aumento delle risorse coinvolgerebbe entrambe le applicazioni, andando di fatto a non ottimizzare il dispendio energetico.

Nota 1: Le risorse CPU & RAM sono assegnate durante la creazione del POD.

E’ sempre meglio creare più POD?

Quest’ultima affermazione non è allineata con la politica di resilienza di K8s, dove  i POD dovrebbero girare su host fisici differenti (k8s è un cluster).

Per risolvere la dipartita, esista una buona regola:

Se il servizio funziona correttamente anche se i POD sono distribuiti su più host, allora è meglio utilizzare più POD (figura 2).

La Figura 4 mostra il contenuto del file mysql-pod.yaml che crea il POD per l’applicazione mySQL.

Figura 4

Vediamo la sintassi di base di gestione del POD:

  • Per avviarlo è sufficiente lanciare il comando: kubectl apply -f mysql-pod.yaml
  • Per verificarne lo stato: kubectl get pods
  • Per ottenere tutti i dettagli: kubectl describe pods some-mysql
  • Se volessimo cancellarlo: kubectl delete -f mysql-pod.yaml

Per oggi è tutto a tra poco dove parleremo di Accesso al POD, come copiare files e tanto altro ancora.

A presto