Reading Time: 2 minutes

Una delle nuove funzionalità introdutte in SRM 5.0 è la tecnologia di vSphere Replication (VR) che permette la replica a livello di VM (implementata in parte in SRM 5.0 e in parte in ESXi 5.0 o successivo). Questa permette di proteggere e replicare (in modo asincrono) le VM senza più la necessità  di disporre di funzionalità di replica a livello di storage array–based (tipicamente costose e troppo vendor dependent).

Gli elmenti che permettono la VR sono:

  • VRA (vSphere Replication agent): incluso in ESXi a partire dalla versione v5.0
  • VRMS (vSphere Replication Management Server): un virtual appliance (VA) per ogni sito
  • VRS (vSphere Replication Server): un virtual appliance (VA) per il sito di DR usato come “target” per il VR agent

Da notare che il deploy di queste VA è gestitibile dal plugin di SRM.

Come funziona VR?

Vi sono due tipi diversi di sincronizzazione di VM:

  • “Full synch”: avviene la prima volta, ma potrebbe capitare occasionalmente a seguito di problemi (ad esempio il recovering da un crash).
    Quando viene impostato VR, bisogna specificare il target sotto forma di una cartella vuota oppure di una copia dei VMDK originali (che devono avere lo stesso UUID).
    A questo punto viene generato un checksum dei blocchi da entrambi i lati e confrontato per determinare i blocchi da trasferire tramite la porta 31031.
  • “Lightweight delta”: tramite il VR agent e un vSCSI filter (che sono inclusi in ESXi 5.x) vengono tracciate le operazioni di I/O per definire i blocchi modificati, memorizzati in un “persistent state file” (.psf) all’interno della home directory della VM.  Il file psf contiene solo puntatori ai blocchi cambiati e viene usato per definire il trasferimento “incrementale” che avviene sulla porta 44046.

Per maggiori informazioni (in inglese) vedere anche:

Reading Time: 2 minutes

Nei giorni scorsi mi è capitato uno strano problema durante una migrazione a freddo tra storage (sullo stesso host), gestita da vCenter Server (con la funzione Migrate).

Questo è lo scenario: un host con Free Hypervisor con alcune VM già esistente, dove è stata aggiunta una licenza complete (Essential Plus, ma non è rilevante il tipo) e l’host a sua volta è stato aggiunto ad un vCenter Server (insieme ad un altro host). Per ragioni di matrice di compatibilità si è usata la versione 4.1 (benché lo storage potesse funzionare con 5.0, ma purtroppo sarebbe stato not supported). L’host esistente in realtà era “nato” in versione 4.0 e circa un anno fa era stato aggiornato alla versione 4.1.

Questo è invece il problema che si è verificato: dopo lo spostamente a freddo delle VM da uno datastore ad un altro tutte le VM create sulla versione 4.0 di ESXi hanno cambiato MAC address. Non si sono verificati inconvenienti su quelle che erano state create dopo che l’host era stato aggiornato alla versione 4.1 (pur rimanendo in versione free).

continue reading…

Reading Time: 3 minutes

Circa un mese mi è capitato un problema con VMware SRM 5.0.1 durante un test di un Recovery Plan.

Non mi ero accorto che lo storage era sì configurato bene per la replica, ma non per la replica nella direzione opposta (da usarsi per il ripristino della situazione di partenza). In queste condizioni il task di reprotect ha fallito miseramente, rimanendo in uno strano stato di lock dal quale non c’era modo di uscire (neppure la funzione di Delete Protection group era disponibile e rimaneva perennemente in grigio).

In questi casi si può cercare di sistemare manualmente la replica a livello di storage e riportare tutto allo stato iniziale, e normalmente funziona. Ma a complicare le cose, la LUN usata nel test era stata cancellata e mi sono accorto dai log che cercava una LUN con un particolare ID (che sullo storage a disposizione non era impostabile manualmente). Essendo poi questo stato memorizzato dei database di SRM non era neppure utile un riavvio degli stessi.

continue reading…

Reading Time: < 1 minute

Per chi non potrà partecipare al VMworld US (e per gli italiani non è proprio alla portata di mano) ma che vogliono comunque rimanere aggiornati sugli annunci rilevanti di VMware, quest’anno c’è un’occasione unica: partecipare all’evento online VMware NOW, evento che dovrebbe essere la stessa (o stesse) keynote di apertura del VMworld, probabilmente in diretta (e quindi in tarda serata italiana). L’evento è pianificato esattamente tra una settimana, per il giorno lunedì 27 agosto 2012 (la data di inizio del VMworld US).

Per partecipare a questo evento virtuale usare questa form di registrazione, o partire direttamente dalla pagina Facebook dell’evento.

Reading Time: < 1 minute

Dal 16 agosto 2012, è disponibile una nuova minor release di vCenter Server: VMware vCenter Server 5.0 Update 1b (build 804277).

Questa versione aggiunge il supporto ai seguenti database:

  • Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] – 64 bit
  • Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] – 32 bit

Inoltre, nella versione vCenter Server Appliance il database DB2 express embedded database è stato sostituito da VMware vPostgres database (interessante che PostgresQL non è ancora ufficialmente supportato, ma come si sospettava può essere usato come database per vCenter). La motivazione è legata ad una riduzione del footprint della VM ed una maggiore semplicità di gestione negli aggiornamenti.

Inoltre sono risolti alcuni problemi (per meggiori informazioni vedere le release notes).

Reading Time: < 1 minute

Veeam ha rilasciato la prima patch per Veeam Backup&Replication 6.1 che corregge alcuni problemi e aggiunge alcune migliorie:

  • Migliorate le performance dei synthetic full e del backup reverse incremental
  • Migliorate le performance del Direct SAN Access mode
  • Aggiunte cmdlet powershell per VeeamZIP
  • Vari fix sia per VMware che per Hyper-V

L’elenco completo delle modifiche è documentato nella KB1671.

La patch è direttamente scaricabile (previa login) sul sito di Veeam: http://www.veeam.com/download_add_packs/vmware-esx-backup/patch1/

Reading Time: < 1 minute

Normalmente l’aggiornamento di Veeam Backup and Replication alla version 6.1 non presenta particolari problem. Ma se Veeam Backup Enterprise Manager è installato sullo stesso server di Veeam Backup and Replication e l’aggiornamento non viene fatto prima al Veeam Backup Enterprise Manager, allora si potrebbe verificare un errore nel Veeam Backup Catalog Data service. Errore che causerà un ciclo infinito di reboot della macchina Windows!

La soluzione è descritta della KB 1645:

  1. Disinstallare Veeam Backup Enterprise Manager e Veeam Backup Catalog service.
  2. Eseguire Veeam_B&R_Setup_x64 per aggiornare Veeam Backup and Replication alla versione 6.1.
  3. Riavviare la macchina.
  4. Eseguire Veeam_B&R_EnterpriseManager_Setup_x64 per installare il Veeam Backup Enterprise Manager in versione 6.1.

Nel caso si verifichino i reboot infiniti:

  1. Durante la fase di boot, premere F8 e scegliere l’opzione “Last Known Good Configuration”.
  2. Disinstallare sia Backup and Replication che Enterprise manager e reinstallare la versione 6.1.
© 2025-2011 vInfrastructure Blog | Disclaimer & Copyright