Veeam Dr Orchestrator v.5: VONE – Tagging

Oggi illustreremo come indicare al Veeam Disaster Recovery Orchestrator quali risorse utilizzare per avviare un piano di Disaster Recovery.

Prima di leggere il presente articolo, vi suggeriamo di leggere l’articolo precedente (cliccando qui) che vi permette di verificare lo stato del Server VDrO.

Lo strumento principe dell’etichettatura delle risorse è Veeam One che ricordiamo viene di default installato contestualmente con il Veeam Disaster Recovery Orchestrator v.5.

La procedura è molto semplice:

Dopo essersi collegati via RDP al VDrO Server selezionate sul desktop la voce Veeam One Client (Vedi figura 1)

Figura 1

Dopo aver selezionato la voce Business View (in basso a sinistra), le risorse da etichettare sono:

  1. I Cluster: attraverso tale voce sono identificate le risorse vCenter di Disaster Recovery e di produzione (Figura 2)
  2. I DataStores: attraverso tale voce sono identificate le aree disco ove risiederanno le VM una volta accese (Figura 3)
  3. Le Virtual Machines: attraverso tale voce sono identificate le VM che garantiscono la continuità di servizio in caso di Disastro (Figura 4 e 5).

Figura 2

Figura 3

Figura 4

Figura 5

Nota 1: I job di replica sono stati configurati sul VBR embedded del server VDrO (vedi figura 6)

Figura 6

Nota 2: L’operazione di etichettatura (tagging) è trattata in un precedente post disponibile al seguente link:

https://lnx.gable.it/home-page/veeam-availability-orchestrator-v-3-0-dr-from-replicas/

Per oggi è tutto, a presto!

Kubernetes: I componenti

Nei precedenti articoli abbiamo visto alcuni dettagli di come è costruita l’architettura di Kubernetes.

Oggi verranno descritti i meccanismi di funzionamento del motore kubernetes indicando il nome di  ogni componente; per rimanere fedeli al paragone del motore dell’autovettura, parleremo degli alberi a camme, valvole, bronzine, … che afferiscono al Cloud Native

Nota1: Non verrà trattata l’installazione di k8s in Datacenter, Cloud e Laboratorio, la rete ha già messo a disposizione  esaustivi tutorial.

Per i familiarizzare con k8s vi consiglio di utilizzare Minikube (Piattaforma Linux)  Docker Desktop (piattaforma Windows & Mac).

Iniziamo!

Kubernetes Master:  E’ il nodo principale del cluster sul quale girano tre processi vitali per l’esistenza del cluster.

  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler

Nel master node è inoltre presente il DataBase etcd, che memorizza tutte le configurazioni create nel cluster.

I nodi che si fanno carico di far girare le applicazioni e quindi i servizi sono detti worker node. I processi presenti sui worker node sono:

  • Kubelet
  • kube-proxy

kubectl: E’ Il client ufficiale di Kubernetes (CLI) attraverso il quale è possibile gestire il cluster (Kube-apiserver) utilizzando le API.

Alcuni semplici esempi di comandi kubectl sono:

  • kubectl version (indica la versione di k8s installata)
  • kubectl get nodes (scopre il numero di nodi del  cluster)
  • kubectl describe nodes nodes-1 (mostra lo stato di salute del nodo, la piattafoma sulla quale k8s sta girando (Google, AWS, ….) e le risorse assegnate (CPU,RAM)).

Kube-Proxy:  Ha la responsabilità di gestire il networking, dalle regole di Routing a quelle di di Load Balancing.

Nota 2: K8s cercherà di utilizzare tutte le librerie disponibili a livello di  sistema operativo.

Container Runtime: E’ la base sulla quale poggia la tecnologia k8s.

kubernetes supporta diverse runtime tra le quali ricordiamo, container-d, cri-o, rktlet.

Nota 3: La runtime Docker è stata deprecata a favore di quelle che utilizzano le interfacce CRI; le immagini Docker continueranno comunque a funzionare nel  cluster.

Gli oggetti base di Kubernetes sono:

  • Pod
  • Servizi
  • Volumi
  • Namespace

I controller forniscono funzionalità aggiuntive e sono:

  • ReplicaSet
  • Deployment
  • StatefulSet
  • DaemonSet
  • Job

Tra i Deployment è indispensabile menzionare  Kube-DNS che fornisce i servizi di risoluzione dei nomi. Dalla versione kubernetes 1.2 la denominazione è cambiata in Core-dns.

Add-On: servono a configurare ulteriori funzionalità del cluster e sono collocati all’interno del name space kube-system (come Kube-Proxy, Kube-DNS, kube-Dashboard)

Gli Add-on sono categorizzati in base al loro utilizzo:

  • Add-on di Netwok policy. (Ad esempio l’add-on NSX-T si preoccupa della comunicazione tra l’ambiente K8s e VMware)
  • Add-on Infrastrutturali (Ad esempio KubeVirt che consente la connessione con le architetture virtuali)
  • Add-on di Visualizzazione e Controllo (Ad esempio Dashboard un’interfaccia web per  K8s).

Per la messa in esercizio, gli Add-on utilizzano i controller DaemonSetDeployment.

L’immagine di figura 1 riepiloga quanto appena esposto.

Figura 1

Statemi bene e a presto.

Kubernets: Conoscere i dettagli

Una buona modalità per descrivere gli ambient cloud-native è rifarsi all’immagine della vostra autovettura.

Il container è il motore, k8s è la centrale elettronica che gestisce il buon funzionamento del mezzo, i conducenti, indicando il percorso e la meta, selezionano il tipo di servizio che dovrà essere erogato.

L’articolo di oggi vi svelerà alcuni dettagli di architettura per comprendere come “l’automobile” riesce a giungere la destinazione in modalità efficente.

I Container sono di due tipologie:

Il primo è detto System Container. E’ la carrozzeria dell’autovettura (intendo dalle lamiere a sedili, volante, leva del cambio e accessori).

Spesso per semplicità di creazione è una Virtual Machine (VM) con sistema operativo Linux (può essere anche Windows).

I servizi più comuni presenti nella VM sono  ssh, cron e syslog, il File System è di tipo ext3, ext4, ecc.

La seconda tipologia è detta Application Container ed è il luogo dove l’immagine realizzerà le attività.

Nota1: L’immagine non è un singolo e grosso file. Di norma sono più file che attraverso un sistema interno di puntamento incrociato permettono all’applicazione di operare nel modo corretto.

L’application Container (d’ora in avanti solo container), ha una modalità di funzionamento basata su una rigida logica, dove tutti livelli (layers) hanno la peculiartità di comunicare tra loro e sono interdipendenti.

    Figura 1

Questo approccio è molto utile poiché è in grado di gestire i cambiamenti che possono avvenire nel corso del tempo in modalità efficace perchè gerarchica.

Facciamo un esempio: Nel momento in cui avviene un cambio di configurazione del servizio, per il quale viene aggiornato il Layer C, il Layer A e B non ne sono impattati, il che significa che NON devono essere a loro volta modificati.

Visto i Developer hanno piacere nell’affinare le proprie immagini (program file) piuttosto che le dipendenze, ha senso impostare la logica di servizion nella modalità indicata in figura 2 dove le dipendenze non sono impattate da una nuova immagine.

    Figura 2

Nota2 : Il File system sul quale si appoggiano le immagini (nell’esempio del motore dell’auto parliamo di pistoni, bielle, alberi …) è principalmente di tre differenti tipologie:

  • Overlay
  • Overlay 2
  • AUFS

Nota3: Un buon consiglio lato sicurezza è quello do non costruire l’architettura in modo che le password siano contenute nelle immagini (Baked in – Cucinata)

Una delle splendide novità introdotte nel mondo containers è la gestione delle immagini:

In un ambiente classico di alta affidabilità, l’applicazione viene installata su ogni singolo nodo del cluster.

Nei container, l’applicazione viene scaricata e distribuita solo quando il carico di lavoro richiede maggiori risorse, quindi un nuovo nodo del cluster con una nuova immagine.

Per questo motivo le immagini sono salvate all’interno di magazzini  “virtuali”,  che possono essere locali oppure distribuiti su internet. Sono chiamati  “Register Server”.

I più famosi sono Docker Hub, Google Container Registry, Amazon Elastic Container Registry, Azure Container Registry.

Concludiamo il presente articolo parlando di gestione delle risorse associate ad un servizio.

La piattaforma container utilizza due funzionalità denominate Cgroup e NameSpace per assegnare le risorse che lavorano a livello di kernel.

Lo scopo del Cgroup è di assegnare allo specifico processo (PID) le corrette risorse (CPU&RAM).

I Name space hanno lo scopo di ragguppare i differenti processi e fare in modo che siano isolati tra loro (Multitenancy).

La tipologia di NameSpace puo interesare tutti i componenti del servizio come indicato nella lista qui sotto.

  • Cgroup
  • PID
  • Users
  • Mount
  • Network
  • IPC (Interprocess communication)
  • UTS (consente a un singolo sistema di apparire con nomi di host e domini diversi e con processi diversi, utile nel caso di migrazione)

Un esempio di limitare le risorse di un’applicazione è indicata nella figura 3 dove l’immagine thegable, scaricata dal Register Server grcgp,ha un limite di risorse RAM e CPU assegnate.

Figura 3

A presto

VDrO v.4 – Run a DR plan

This is the last article about how to integrate the Continuous Data Protection (CDP)  technology (available from VBR v.11) and VDrO v.4 (former VAO).

In this part, we are going to see what happens when an orchestration plan is launched.

Yes, I wrote the word “see” because I created a short video showing the tasks that are automatically completed when a Disaster Recovery is occurring.

If you need more details about how to set up the environment, please read the previous articles.

Let me know if videos and youtube platform are a good way to expose technological valuable topics.

Thx for reading and watching and take care

Veeam Disaster Recovery Orchestator v.4 – How to Upgrade

Also Veeam Availability Orchestrator, commonly called VAO, changed its name with this new release.

The new name is Veeam Disaster Recovery Orchestrator (VDrO).

The main news of this version is the support of the technology of continuous data protection (CDP) introduced in VBR v.11.

Which are the main benefits allowed by this new feature?

  • New readiness checks now including RPO and SLA.
  • Recovery Point Object close to real-time.
  • Detailed reports to track and audit the Disaster Recovery plan of your company.

The next article will explain how to implement a DR plan using CDP.

Before doing the upgrade procedure please:

  1.  Perform backup of all existing databases (VAO, VBR, ONE)
  2. Make sure there is enough space for the upgrade of the Microsoft SQL Server configuration database
  3. Make sure there are no orchestration plans being tested or executed
  4. Make sure there are no orchestration plans scheduled to run during the upgrade.
  5. Read carefully the user guide.

Before proceeding please check that the VAO current version on the server is 3.0 (picture 1).

Picture 1

After downloading the ISO file from the Veeam website and mounting it (picture 2)

Picture 2

just select the “Setup” voice; the wizard immediately begins the upgrade (picture 3).

Picture 3

Please check that the previous version of VAO has been discovered. If so the upgrade button is available (picture 4).

Picture 4

The setup checks if Visual C++ 2019 Redistributable package is already installed.  If not it will automatically be deployed. This procedure requires the server reboot (pictures 5 and 6).

Picture 5

Picture 6

After reboot is completed, relaunch the setup.  The wizard will show which components will be automatically upgraded (picture 7).

picture 7

Now the wizard will ask for a valid license (picture 8) and will install the missing components (Pictures 9 and 10).

Picture 8

picture 9

picture 10

The next steps are about the Veeam Databases.
The wizard will ask to connect to them and update the VBR one if necessary (pictures 11 and 12).

Picture 11

Picture 12

The main point of the upgrade procedure is the certification step.
As shown in picture 13, the wizard will ask the VAO administrator which certificate to use. It can be a self-signed and autogenerated or an own certificate created from an external authority.
My suggestion is to ask your security specialist to know which is the best choice for your company.

Picture 13

Picture 14

Clicking on the install button it will complete the upgrade wizard as shown in pictures 15 & 16.

Picture 15

Picture 16

After upgrading please check the versions of VAO (4.0.0.2088), VBR (11.0.0.837), ONE (11.0.0.1379) now installed.

Just a note before ending the article: has already said, VAO (Veeam Availability Orchestrator) has changed its name to VDrO  (Veeam Disaster Recovery Orchestrator).
The web pages of the product still show the old name. It will be updated in the next release.

That’s all for now guys. Take care

VDrO-Baseline 2

Let’s continue the VDrO features description talking about scope (Picture 1).

Picture 1

The VDrO controls access to its functionality with the scopes.

A scope defines which operations users can perform.

Let’s back to my example, I created a SQL Production scope where only the users belonging to the SQL administrator group can manage and launch the DR process.

The plan components are probably the main VRrO attention point (Picture 2).

(Picture3)

From this menu, it’s possible to group as a single entity all objects you need to create a Disaster Recovery strategy.

I’m talking scope (first to select), VM (applications and services), recovery locations, plan steps, credentials, and jobs template.

To be clearer, it’s like creating a picnic basket and putting it inside different dishes.

Now you just have to lay the table.

How to do it? (Which dishes do I have to put into the basket?)

Just select scope (Picture 4), then from VM groups include the needed VMs source (Picture 5), from recovery locations, select the DR site (picture 6), and at the end select plan steps, credential, and Template Job.

Picture 4

Picture 5

Picture 6

The last point is the DataLabs assignment but I’m sure you can now include them on the right scopes.

Exit from the Administrator menu and move to the main menu to create the first Recovery Plan.

The wizard is very easy to be used:

Picture 7

Picture 8 shows how to select the Scope.

Picture 8

Picture 9 shows the detailed plan info and Picture 10 the plan type (next articles will deep how to set them up).

Picture 9

Picture 10

Pictures 11, 12, 13 show how it’s possibles to discover the VMs that belong to the group selecting VM group.

Picture 11

Picture 12

Picture 13

Picture 14 shows the control options for the DR plan. If something goes wrong the plan can be halted or not.

Picture 14

Picture 15 shows the steps, 16 the option to protect VMs switched on after the failover has been completed, 17 the RPO and RTO that the plan has to respect.

Picture 15

Picture 16

Picture 17

Picture 18 shows the template docs that will be used, while picture 19 shows a (for me) interesting mandatory check option.

Before doing any new activity the Readiness check analyzes that all components are correctly set up.

Picture 18

Picture 19

In my next article, I will cover two examples: DR-plan from Replica and DR-plan from backup. Keep in touch!