Articoli

Pubblicato il

Snapshot e protezione dei dati

Con lo storage ormai integrato nel cluster, il passo successivo è  “salvare dati”, anche se preferisco la dizione proteggerli.
In questo capitolo il desiderio è stato quello di far passare il laboratorio da semplice piattaforma Kubernetes a sistema resiliente.

Perché gli snapshot sono fondamentali

In Kubernetes i dati vivono dentro volumi persistenti (PVC), ma senza snapshot:

  • non puoi fare rollback
  • non puoi fare restore veloci
  • non puoi garantire recovery point affidabili

Gli snapshot sono l’equivalente moderno dei checkpoint delle macchine virtuali, ma applicati ai volumi containerizzati.

Snapshot CSI: la base tecnologica

Tramite Il CSI driver di Synology, il cluster ha ottenuto una nuova capacità:

K8s può chiedere allo storage di creare snapshot dei volumi.

Questo introduce tre nuove entità:

  • VolumeSnapshotClass
  • VolumeSnapshot
  • VolumeSnapshotContent

Non sono file.
Sono oggetti Kubernetes che rappresentano snapshot reali creati sul NAS.

Il legame tra Kubernetes e Synology

Quando Kubernetes crea un VolumeSnapshot:

  • Il CSI driver invia la richiesta al Synology
  • Il NAS crea uno snapshot iSCSI nativo
  • Kubernetes riceve l’ID dello snapshot
  • Il VolumeSnapshot diventa ReadyToUse

A questo punto lo snapshot è:

  • consistente (non da un punto di vista applicativo)
  • puntuale
  • indipendente dal pod

Ed è pronto per essere usato per backup o restore.

Validazione degli snapshot

Nel laboratorio è stato creato un PVC di test con dati scritti da un pod.
Da lì sono stati generati snapshot CSI e verificato che:

  • esistono nel NAS
  • sono visibili come oggetti Kubernetes
  • possono essere usati per creare nuovi volumi

Questo ha dimostrato che lo storage era snapshot-aware, requisito essenziale per Kasten K10.

Perché questo passaggio è cruciale per il backup

Kasten K10 non lavora direttamente con i filesystem ma lavora con Snapshot CSI consistenti.

Senza questa aggiunta, Kasten avrebbe potuto solo fare backup “file based”, con gli snapshot, invece è possibile effettuare:

  • backup istantanei
  • consistenza applicativa
  • restore rapidi

È qui che nasce la vera data protection cloud-native.

Risultato

Alla fine di questo step il cluster possiede:

  • Storage persistente
  • Snapshot nativi
  • API Kubernetes per gestirli

Il laboratorio è pronto per introdurre un altro protagonista:
Kasten K10.

Pubblicato il

Storage e k8s cluster

Con il cluster Kubernetes operativo, il passo successivo è quello di gestire la cosa più critica di tutte i dati.

Un cluster senza storage persistente è solo una piattaforma di calcolo.
Un cluster con storage condiviso diventa invece una piattaforma applicativa reale 🙂

Il problema da risolvere

Le applicazioni Kubernetes non possono dipendere dai dischi locali dei nodi:

  • un pod può spostarsi da un nodo all’altro
  • un nodo può spegnersi
  • un container può essere ricreato

Quindi se i dati restano legati al nodo, vengono persi.

Serve quindi uno storage:

  • condiviso tra i nodi
  • persistente
  • gestito dinamicamente da Kubernetes

Lo storage esterno: Synology e WD

Nel laboratorio erano disponibili due sistemi di storage esterni:

  • Synology → usato come storage primario con supporto iSCSI e snapshot
  • WD NAS → usato come repository NFS per la seconda copia (backup)

Integrazione dello storage con Kubernetes

Per permettere a Kubernetes di usare lo storage Synology come se fosse nativo, è stato installato:

  • CSI Driver di Synology
  • Snapshot Controller CSI

Questi componenti trasformano lo storage fisico in risorse Kubernetes:

  • PersistentVolumes
  • PersistentVolumeClaims
  • VolumeSnapshots

In pratica, Kubernetes ha iniziato a parlare direttamente con il NAS, senza script o mount manuali.

Le StorageClass

Una volta installato il driver, sono state create le StorageClass, che definiscono:

  • tipo di storage (iSCSI)
  • policy di cancellazione
  • supporto snapshot

Ogni applicazione che richiede storage non chiede più “un disco”, ma chiede una Storage Class con determinate caratteristiche.

Ed è K8s, tramite il CSI driver, che crea automaticamente i volumi sul NAS.

Verifica con PV, PVC e Pod

Per validare l’integrazione sono stati creati:

  • un PVC (PersistentVolumeClaim)
  • un PV (creato dinamicamente dal NAS)
  • un Pod di test che scrive dati sul volume

In quel momento è stato verificato che:

  • il volume esiste realmente sul Synology
  • il pod può scrivere dati
  • i dati sopravvivono al riavvio del pod

Questo è stato il primo vero test di persistenza reale del cluster.

Risultato

Il cluster è diventato un cluster Kubernetes con storage condiviso.

Ora il sistema era pronto per:

  • snapshot
  • backup
  • restore
  • disaster recovery

Prossimo capitolo, usare Kasten K10 per proteggere l’ambiente.

Pubblicato il

Configurazione dei NUC dopo l’installazione di Ubuntu

Scopo di questa fase

Una volta installato Ubuntu Server su ciascun Intel NUC, l’obiettivo non è ancora Kubernetes, ma creare una base stabile, sicura e coerente su cui costruire il cluster.

In questa fase si definisce il “DNA” dei nodi:

  • come si collegano in rete
  • come vengono amministrati
  • come vengono identificati
  • come possono essere automatizzati

Se questa base è solida, tutto il resto (Kubernetes, storage, backup) sarà affidabile.

Allineamento del sistema operativo

Ogni NUC deve partire dallo stesso stato logico in modo che reagiscano allo stesso modo in caso di problemi e che le performance non decadano se i workload vengono automaticamente spostati

  • Sistema aggiornato
  • Pacchetti base installati
  • Kernel e firmware allineati
  • Tool di rete, NFS, iSCSI e storage pronti
  • Questo garantisce che:

Identità dei nodi

Si configurano:

  • hostname univoci (nuc-01, nuc-02, nuc-03, nuc-mngt)
  • risoluzione DNS o /etc/hosts coerente

Questo è fondamentale perché Kubernetes non lavora con IP casuali, ma con identità logiche dei nodi.

Networking a più interfacce

Ogni NUC ha più schede di rete, con ruoli distinti:

Rete Scopo
Management SSH, API, controllo cluster
Storage iSCSI / NFS verso NAS
(opzionale) Frontend traffico applicativo

La separazione delle reti è una best practice enterprise per evitare che il traffico storage o backup rallenti k8s.

Configurazione firewall e sicurezza

  • porte aperte per Kubernetes
  • porte per SSH
  • porte per storage (iSCSI, NFS)
  • tutto il resto bloccato

Questo crea una superficie di attacco minima, fondamentale quando si parla di dati.

Abilitazione dell’accesso remoto sicuro

Tutti i nodi vengono resi amministrabili via SSH. permettendo :

  • gestione remota
  • automazione
  • troubleshooting
  • integrazione con strumenti di orchestrazione

È la base per poter gestire il cluster come una piattaforma, non come singole macchine.

Verifica delle interfacce di rete e dello storage

Prima di installare Kubernetes, si verifica che:

  • ogni nodo veda gli storage (Synology, WD)
  • le interfacce di rete siano attive
  • le rotte siano corrette
  • i NAS rispondano

In questa fase si valida un principio chiave:

k8s non può essere più affidabile dell’infrastruttura che lo sostiene.

Risultato

Alla fine di questa fase, i NUC non sono più “PC con Ubuntu”, ma diventano:

  • nodi di un’infrastruttura
  • pronti per lavorare insieme
  • collegati allo storage
  • gestibili in modo centralizzato

Questa è la fondazione fisica e logica su cui verrà costruito il cluster Kubernetes.

Pubblicato il

Da Bare-Metal a Kubernetes Cyber-Resiliente – Introduzione

Introduzione

Negli ambienti Kubernetes moderni, la vera sfida non è far girare i container, ma proteggere i dati.
Applicazioni, database e servizi stateful richiedono una piattaforma che garantisca:

  • Persistenza
  • Snapshot
  • Backup off-cluster
  • Ripristino affidabile

Questo progetto nasce con l’obiettivo di costruire, partendo da hardware fisico, una piattaforma Kubernetes pronta per ambienti enterprise, in grado di offrire resilienza dei dati e protezione da eventi critici come guasti o ransomware.

Obiettivo del progetto

L’obiettivo non era creare un semplice laboratorio, ma una piattaforma cloud-native completa, in cui:

  • Lo storage è condiviso e ridondato
  • I volumi sono gestiti da Kubernetes tramite CSI
  • I dati possono essere snapshot-tati
  • I backup sono esportati fuori dal cluster

In altre parole: Kubernetes diventa una piattaforma dati, non solo di calcolo.

Architettura di base

L’architettura si basa su tre elementi fondamentali:

  1. Nodi di calcolo (Intel NUC) per eseguire Kubernetes
  2. Storage esterno (Synology e WD) per ospitare i dati
  3. Rete dedicata per collegare compute e storage

Questo modello separa fisicamente calcolo, dati e gestione, una best practice delle architetture enterprise.

Abilitazione dello storage persistente

Lo storage esterno viene esposto a Kubernetes tramite:

  • iSCSI (Synology)
  • NFS (WD)

e integrato nel cluster attraverso CSI (Container Storage Interface).

Questo permette a Kubernetes di creare, montare e gestire volumi come risorse native.

Snapshot e consistenza dei dati

Sul CSI sono stati abilitati i componenti di snapshot, che consentono di:

  • Congelare lo stato di un volume
  • Proteggere database e file
  • Consentire backup applicativi consistenti

Questa è la base di qualsiasi strategia di data protection moderna.

Protezione dei workload con Kasten K10

Sopra Kubernetes è stato installato Kasten K10, la piattaforma di data management per Kubernetes, che fornisce:

  • Policy di backup
  • Snapshot orchestrati
  • Esportazione su storage esterno
  • Restore applicativo

Grazie a Kasten, i workload non sono più solo container, ma entità protette.

Storage di backup off-cluster

Un NAS Wester Digital collegatovia NFS è stato configurato come destinazione di backup al fine di mantenere una copia dei dati fuori dal cluster, requisito essenziale per:

  • Disaster recovery
  • Protezione ransomware
  • Isolamento dei backup

Risultato finale

Il risultato è una piattaforma Kubernetes che:

  • Gestisce storage persistente
  • Supporta snapshot CSI
  • Effettua backup applicativi
  • Replica i dati su storage esterno

In pratica:

K8s pronto per ambienti di produzione e cyber-resilienza.

Pubblicato il

Proxmox Backup

L’integrazione tra Proxmox Virtual Environment (PVE) e Veeam Backup & Replication (VBR) rappresenta un passo significativo per ottimizzare le politiche di backup e recupero. Questo articolo illustra i passaggi chiave per abilitare il plug-in di VBR, a partire dall’architettura del sistema, fino all’installazione e configurazione del plug-in, e all’aggiunta del server Proxmox nella console di VBR.

Si noti che le istruzioni si basano sulla versione Beta del plug-in, pertanto potrebbero esserci differenze nella versione ufficiale.

Rileggendo l’articolo scritto qualche mese fa (disponibile su questo sito al seguente link), credo che chi considera la virtualizzazione una commodity sceglierà PVE per uscire rapidamente dall’incertezza causata dalle scelte commerciali di Broadcom.

Nota 1: PVE è una distribuzione Linux basata su Debian con kernel Ubuntu che consente l’implementazione e la gestione sia di macchine virtuali che di container.

Nota 2: Proxmox è un’azienda Europea con sede in Austria.

In questo primo articolo (di tre) vedremo i passaggi fondamentali per abilitare il plug-in che permette a VBR di realizzare politiche di backup e ripristino.

Chiedete al vostro Veeam SE di riferimento per testare la versione Beta.

Architettura:

L’immagine 1 riporta lo schema di funzionamento dell’integrazione. Il Plug-in è il componente che abilita la comunicazione tra il Backup Server Veeam (VBR) e l’architettura Proxmox.

Nota 3: Il ruolo Proxy (qui denominato Worker) ha il compito di raccogliere i dati  delle VM da proteggere per copiarli  verso il Backup Repository.

Il processo di Backup prevede l’innesco di snapshot e la connessione tra il server Proxmox e  VBR avviene tramite API REST.

Immagine 1

Una volta installato il plug-in sul server VBR è necessario:

  1. Dalla consone di VBR all voce Backup Infrastructure aggiungere il server Proxmox (immagine 2 e 3).

Immagine 2

Immagine 3

2. Nelle successivle immagini (dalla 4 alla 9) sono mostrati i semplici passaggi per aggiungere l’architettura PVE nella console di VBR.

Immagine 4

Immagine 5

Immagine 6

Immagine 7

Nota 4: E’ possibile selezionare lo storage ove le snapshot verranno salvate.

Immagine 8

Immagine 9

Al termine è possibile effettuare immediatamente il deploy del worker (proxy). Il vantaggio è quello di accelerare il processo di backup (immagine 10).

Immagine 10

Nota 5: Per chi proviene dal mondo VMware è esattamente come abilitare il metodo di trasporto virtual appliance.

In quest’ultima fase è possibile configurare su quale host effettuare il deploy del worker, quale storage utilizzare (immagine 11), quali risorse assegnare (immagine 12) e su quali reti operare (immagine 13, 14 e 15 ).

Immagine 11

Immagine 12

Immagine 13

Immagine 14

Immagine 15

Dopo aver controllato che tutte le configurazioni soddisfino le desiderate (immagine 16), cliccando su finish il setup è completato.

Immagine 16

Nel prossimo articolo vedremo come configurare i job di Backup.

Pubblicato il

Proxmox Backup

Integrating Proxmox Virtual Environment (PVE) and Veeam Backup & Replication (VBR) is a significant step in optimizing backup and recovery policies. This article outlines the key steps to enable the plug-in of VBR, starting with the system architecture, installing and configuring the plug-in, and adding the Proxmox server to the VBR.

Note that the instructions are based on the Beta version of the plug-in, so there may be differences in the official version.

Rereading the article written a few months ago (available on this site at the following link), I believe that those considering virtualization as a commodity will choose PVE to quickly escape the uncertainty caused by Broadcom’s business choices.

Note 1: PVE is a Debian-based Linux distribution with Ubuntu kernel that allows virtual machines and containers to be deployed and managed.

Note 2: Proxmox is a European company based in Austria.

In this first article (of three) we will look at the basic steps to enable the plug-in that allows VBR to implement backup and recovery policies.

Ask your referring Veeam SE to test the Beta version.

Architecture:

Image 1 shows the operation diagram of the integration. The Plug-in is the component that enables communication between the Veeam Backup Server (VBR) and the Proxmox architecture.

Note 3: The Proxy role (referred to here as Worker) is responsible for collecting the data from the VMs to be protected and copying it to the Backup Repository.

The Backup process involves the triggering of snapshots, and the connection between the Proxmox server and VBR is via REST API.

Picture 1

Once the plug-in is installed on the VBR server, it is necessary:

  1. From the console of VBR under Backup Infrastructure add the Proxmox server (images 2 and 3).

picture 2

Picture 3

2. The next images (4 through 9) show the simple steps to add the architecture PVE in the console of VBR.

Picture 4

Picture 5

Picture 6

Picture 7

Note 4: It is possible to select the storage where the snapshots will be saved.

Image 8

Image 9

When finished, you can immediately deploy the worker (proxy). The advantage is to speed up the backup process (image 10).

Image 10

Note 5: For those coming from the world VMware is exactly how to enable the virtual appliance transport method.

In this last step, it is possible to configure which host to deploy the worker, which storage to use (image 11), which resources to assign (image 12), and which networks to operate on (images 13, 14, and 15 ).

Image 11

Image 12

Image 13

Image 14

Image 15

After checking that all configurations meet the desired ones (image 16), clicking finish completes the setup.

Image 16

In the next article, we will see how to configure Backup jobs.