Enterprise Manager – Delega dei ripristini

Un articolo dedicato a come poter delegare i ripristini  con Veeam Backup & Replication (VBR).

Il case study è legato alla protezione di file in cartelle condivise, ma può essere esteso a molti degli oggetti protetti con VBR. (vedi immagine 7)

  1. Nell’immagine 1 sono illustrate le tre cartelle di rete condivise (SHARE-A, SHARE-B, SHARE-C) che sono utilizzate come sorgente dei file da proteggere.

share-sorgenteImmagine 1

Nello scenario si ipotizza che per ogni singola cartella condivisa, solo uno specifico utente possa procedere alle attività di ripristino.

  1. L’ immagine 2 evidenzia la creazione di tre utenti di Dominio, ShareA, ShareB, ShareC.

utenti-ADImmagine 2

I file afferenti ad una specifica cartella condivisa saranno ripristinabili dall’utente che ha nel nome l’identica lettera finale. Ad esempio, i file afferenti alla SHARE-A saranno ripristinabili dall’utente ShareA.

(NDR: Per semplicità espositiva la lettera X sostituirà una delle tre lettere dell’alfabeto A-B-C)

  1. Per ogni cartella condivisa è stato creato un job di Backup denominato “BkF-Share-X”

L’immagine 3 evidenzia che il job “BKF-Share-A” (freccia arancio) protegge l’intera SHARE-A (freccia Blue).

Immagine 3

  1. Nell’immagine 4 viene evidenziato il menù “configurazione” dall’ Enterprise Manager.

In questa fase di configurazione sono necessarie le credenziali amministrazione.

Immagine 4

  1. Dal sotto menù role (immagine 5 – freccia arancio) vengono aggiunti (freccia verde) i tre utenti precedentemente creati (ShareX) ai quali viene assegnato il ruolo di Restore Operator (freccia blue).

roleImmagine 5

  1. L’immagine 6 mostra le opzioni di delega.

All’ utente ShareA (freccia verde) viene assegnata la possibilità di effettuare il ripristino di tutti gli oggetti protetti da VBR attraverso il pulsante “Choose” (freccia arancio); nelle opzioni di ripristino è possibile permettere il solo ripristino in-place  (freccia blue).

Nelle immagini successive (7-8) viene indicato come effettuare la scelta degli oggetti da visualizzare durante le operazioni di delega del ripristino.

role-1Immagine 6

scopeimmagine 7

role-2Immagine 8

  1. L’immagine 9 illustra e conferma che effettuato il login dall’Enterprise Manager con le credenziali dell’utente ShareX (freccia Blue), siano visibili e ripristinabili solo i file della corrispettiva cartella condivisa (freccia arancio).

DelegaImmagine 9

Nota Finale:

VMware Broadcom – Cosa fare ?

Broadcom's Acquisition of VMware Closed: What Now?

Broadcom ha dato una grande scossa al  2024.

Dagli ultimi rumors, sembra che il licensing della appena acquisita VMware verrà pesantemente rivisto.

Uno dei primi risultati è che molti clienti si chiedono cosa sia giusto fare.

Non ho la pretesa di conoscere la risposta corretta.

Ho effettuato alcune riflessioni che mi hanno portato a pensare a quattro futuri scenari  dei quali vi parlerò nel presente articolo.

  1. Il cliente continua la collaborazione con VMware/Broadcom.
  2. Il cliente sostituisce la tecnologia Hypervisor.
  3. Il cliente migra il proprio datacenter verso un Hyperscaler o  un Service Cloud Provider Locale.
  4. Il cliente trasforma il proprio Datacenter in un  “Datacenter as a Software”.

Per ogni scenario andrò ora a descrivere i macroscopici pro e contro.

1. Credo che il desiderato di Broadcom sia quello di semplificare il più possibile il licensing al fine di avere a portfolio soluzioni snelle e semplici da proporre.

Ciò implica eliminare alcune delle soluzioni ora presenti per concentrare le  energie unicamente su quelle a maggior rilevanza d’uso e guadagno.

Ora vi domando: Le soluzioni VMware ora presenti nel vostro datacenter sono quelle strategiche anche per Broadcom?

E ancora, siamo certi che l’ottimizzazione Broadcom non toccherà il dipartimento R&D di VMware che sviluppa le soluzioni divenute ora strategiche?

E non per ultimo, quale sarà il prezzo per poter rimanere nell’ecosistema Broadcom-VMware?

2. La prima sfida è quella di fornirsi di strumenti in grado di migrare le VM da una tecnologia HyperVisor all’altra.

La seconda è quella di proteggerle.

(NDR. Meno male che Veeam Backup & Replication permette di realizzare con un solo strumento entrambe le cose 🙂 )

Aggiungo, che bisognerà essere anche fortunati nello scegliere un vendor che non sia nel mirino di una nuova Broadcom, perché finire nello stesso giro dantesco sarebbe diabolico.

Pensare ad una tecnologia open-source based?

3. Il modello degli Hyper-Scaler è quello di fornire una serie di servizi  personalizzabili.

Spesso sento qualcuno affermare che esistano dei “costi nascosti”.  Non è vero, sono tutti ben illustrati, solo che capirli preventivamente è spesso molto difficile.

Avrà quindi particolare importanza la fase di creazione del progetto di migrazione che dovrà essere particolarmente accurata al fine di non ritrovarsi brutte sorprese  a fine mese .

4. Data Center as a Software è sinonimo di un’architettura Cloud Native.

Ciò implica riscrivere applicazioni e servizi in modo tale che siano  indipendenti dal HyperVisor.

E’ il nuovo approccio che negli anni diventerà un comune standard per scrivere codice.

Nel sito troverete una serie di articoli sul mondo Container e kubernetes ai quali vi rimando.

Tante domande, una sola risposta giusta?

No, credo che la migliore strategia sia quella di ricercare il miglior bilanciamento nell’utilizzo delle diverse opzioni disponibili, per arrivare a regime con la soluzione che si adatta al meglio alle necessità della vostra azienda in un corretto bilanciamento tra costi e benefici.

Ultima nota: Non dimenticate mai di aggiungere dei piani di formazione del personale perchè il training on the job in scenari particolarmente complessi NON è mai la via migliore per rendere sicuri i vostri sistemi ovunque questi siano

Check Replica Status – Before deleting it – Part 2

My previous article explained the procedure to perform a failover from VBR console explaining why it is safe (Click here to read it)

In this second article, I’ll show you what can happen if you try a failover in a different way, answering the behavior that a partner had during a cleanup procedure.

In my lab, I created a new Replica Job where the original VM is still Ubuntu-02 (Picture 1) and the replica VM has the suffix _Rep_vc01-1-1 (Picture 2).

Picture 1

Picture 2

After the VM has been created (Picture 3) It is switched it on directly from the vCENTER console (Picture 4). To be sure it works as expected, it is possible to connect remotely.

Picture 3

Picture 4

Picture 5

Going back to VBR console it’s possible to see that nothing has changed (Picture 6) just because the power-on action has been performed directly from the  VMware console,

Picture 6

Attention point: If you try to perform a replica task it fails because the VM is running (picture 7)

Picture 7

Now the main point of the two articles:

It’s a bad choice to delete VMs from VBR “Ready Replica VM”  menu (picture 8/9) without knowing if the VMs have been started from vCENTER console. Why? Because also the production VM gets deleted as shown in picture 10.

Picture 8

Picture 9

Picture 10

Let’s get a little wild with some supposing:

1. If you see the “active” status icon switched on ( from VBR console) it means the failover is started (picture 11)

Picture 11

2. If a permanent failover was performed, the VM disappears from “Replica Ready” menu and replica job results to be empty (Picture 12)

Picture 12

3. If the replica job works fine it means that no permanent failover has been performed

4. If the replica Job works fine but when clicking on the delete button (from “Replica ready menu” of VBR console) (picture 13) the production VM disappears, it means that a new replica job has been re-created after the manual failover has been launched (picture 14).

Picture 13

Picture 14

Knowing that deleting a VM replicated from VBR console needs a little attention, especially if you do not have the continuous and complete control of the VMware architecture, the question is: is it possible to think an easy checking-up before deleting VM?

The answer is Yes and Veeam One can easily help just creating them.

a. From vCENTER: setting up a report that checks if the VM to be deleted is running (power state status) (Table 1)

b. From VBR: if a Replication job is setted-up for that VM (Table 2)

Table 1

Table2

Is there another way to check it up?

Yes. using Powershell scripts.

The example you can find here below is just the first idea that can be polished with a little bit of your effort.

NB1: I’m not a PowerShell expert, I just love writing scripts easy to read by anyone.

NB2: Before trying it please ask your PowerShell expert a consultant!

NB3: It is meant to be launched from VBR.

NB4: If you think that it can be a feature request write to me!

Table 3

That’s all for now guys!