J’ai découvert les produits Vembu au VMworld 2017 à Barcelone et j’ai commencé à les tester à mon retour de l’événement.

Finalement, le test s’est tellement bien passé que les sauvegardes sont en place depuis cette période et les quelques restaurations, dont j’ai eu besoin, ont parfaitement fonctionné. Petit retour sur l’installation et la configuration de l’un des produits de cet éditeur encore trop méconnu.

Voici le déroulement du setup. Celui-ci est très simple les sources sont disponibles directement sur le site de vembu :

Le setup par défaut est le suivant, mais l’installation est entièrement personnalisable :

Install ou Customize

Choix du nom de l’instance de la base, port réseau, emplacement des sources du serveur PostgreSQL ainsi que de la base de données :

Choix de l’emplacement du produit en lui-même :

Choix des emplacements de stockage des sauvegardes qui peuvent être locales au serveur de sauvegarde ou sur un partage réseau NFS ou CIFS. Cette option est complétement paramétrable par la suite :

Pour ma part, j’ai ajouté un disque de 500GB à la VM :

Mais vous pouvez utiliser du NFS ou CIFS :

Choix du port de communication à l’interface Web qui permettra l’administration de la solution ainsi que du compte et du mot de passe pour s’y connecter :

Enfin, le récapitulatif du chemin d’installation et le setup indique que l’application sera déclarée en service Windows :

Une fois le setup effectué, attendre quelques minutes pour l’initialisation de la base de données afin de se connecter à l’interface d’administration. Sinon vous aurez ce message d’erreur :

Après la connexion, configurez la timezone :

Définir un ID unique Vembu BDR. Comme recommandé, je suis parti sur le FQDN du serveur :

Vous arrivez ensuite sur cette page :

Le dashboard est vide pour le moment, il n’y a que l’état des emplacements de stockage des sauvegardes :

Il faut procéder à l’enregistrement du serveur de sauvegarde, si ce n’est pas déjà le cas, créer un compte sur https://portal.vembu.com

 

C’est le moment de renseigner le compte vembu :

Tout se déroule correctement le serveur est enregistré:

 

Il faut maintenant configurer la sauvegarde, ici le choix est plutôt large, pour VMware cela peut être un/des vCenters ou directement les hôtes ESXi, pour Microsoft les hôtes Hyper-V ou partage SMB et enfin directement des machines Windows :

 

Microsoft Hyper-V Standalone:

 

Microsoft Hyper-V SMB Host :

Machine Windows Serveur ou Workstation :

Pour VMware, Host ou vCenter :

Une fois les serveurs ajoutés,  ils sont visibles dans la liste des serveurs. C’est ici que je vais sélectionner la liste des machines à sauvegarder (en cliquant sur Backup), éditer le mot de passe ou simplement supprimer la connexion :

Sélection des VMs, ici le choix est très granulaire et les exclusions des VMs ou de disques bien pensées:

 

Choix des options de sauvegardes. Ici, plusieurs possibilités concernant les VSS Windows, les logs et processus en cours :

Voici le détail de chaque option, c’est aussi bien que chez les ténors du marché :

Application Aware Process:

Require successful application processing :

Ignore application processing failures :

Truncate the translactions logs :

VMware Guest Credentials :

Je passe à la planification. Ici, la sauvegarde incrémentielle peut être effectuée de 15min à 12 heures. Sur le même onglet, on pourra planifier optionnellement des sauvegardes complètes :

Stratégie de rétention, choix de la destination de stockage de la sauvegarde ainsi qu’activation du chiffrement :

 

Résumé de la tâche, je touche au but :

Dernière confirmation lorsqu’on clique sur Save the backup :

La sauvegarde est en place !

J’ai réalisé ce billet seulement maintenant car je voulais être certain d’avoir éprouvé la solution.

Lorsqu’il s’agit de sauvegarde, c’est en général notre dernière chance donc pas question de partir sur un produit qui ne ferait pas correctement le boulot.

D’ailleurs, celui-ci dépasse largement mes attentes et je pense qu’il peut répondre au besoin de nombreuses entreprises. Il suffit d’aller jeter un œil sur leur catalogue pour comprendre qu’ils proposent une très large gamme de produits qui sera s’adapter à beaucoup de besoins.

L’éditeur m’a récemment contacté pour m’indiquer qu’il proposait à l’occasion des “World Backup Day”.

Une promotion de 10% sur ces produits aux travers de ce lien : https://www.vembu.com/world-backup-day-2018/

 

Les nouveaux nœuds Nutanix ont été réceptionnés. Ils sont maintenant rackés, câblés en datacenter, prêts à être ajoutés aux clusters existants.

Afin de réaliser l’opération d’installation, le réseau est configuré en “access” sur le même VLAN que mes autres CVM. Je modifierai la configuration après l’ajout du noeud.

Autre prérequis l’iDrac (oui, ce sont des serveurs Dell) est sur le même plan d’adressage que les autres IPMI, déjà en place dans le cluster.

J’ai déjà eu le problème avec un iDrac sur un autre VLAN et on obtient une erreur : “Failed to perform network validation !”

Je prépare mes adresses IP et je suis enfin prêt pour l’Expand Cluster.

Comme le réseau est correctement configuré, le nouveau nœud est disponible.

Je renseigne les champs pour les adresses IP qui permettent aisément la configuration de plusieurs nœuds à la fois, si les adresses se suivent.

Concernant la détection automatique des masques de sous-réseau, je pense qu’il y a un souci comme vous pouvez le voir sur la capture. Ils ne sont jamais corrects, mais l’installation se poursuit sans encombre.

La deuxième étape consiste à ré-imager l’hôte avec le même hyperviseur que les autres membres du cluster, dans mon cas ESXi.

Ici, on constate que la version n’est pas tout à fait la même. Je procéderai avec VMware Update Manager pour l’application des derniers correctifs et venir au même niveau que le cluster. Je procède à la phase de vérification en cliquant sur “Run Checks”.

 

 

SI la vérification est concluante…

 

…il est temps de cliquer sur “Expend Cluster”.

 

L’opération est assez longue, elle contient une multitude de sous-tâches.

L’ajout du nœud a pris une heure et s’est terminé correctement. Il me reste maintenant à configurer l’hyperviseur et le cluster profitera rapidement d’une ressource supplémentaire pour repartir la charge.

Encore une fonctionnalité de Prism très pratique. L’important est de bien respecter les prérequis et l’extension du cluster sera réalisée en quelques clics seulement.

Dans la série “One Click” sur Nutanix, je vais tester aujourd’hui l’extension de RAM des CVM.

Je n’avais jamais eu l’opportunité de tester cette option relativement récente de Prism “Configure CVM” :

Un menu déroulant permet de choisir la quantité de RAM allouée aux CVM :

Une fois la sélection effectuée, toutes les CVM impactées sont listées :

On valide en cliquant sur “Apply”, puis un dernier avertissement nous prévient que Prism pourrait être temporairement indisponible :

On valide sur “Yes”, puis l’opération débute :

La tâche se déroule avec succès, sans encombre…

Les CVM sont maintenant à 32GB de RAM.

Encore une option qui simplifie la vie. Je vais bientôt recevoir de nouveau nœud donc prochainement “OneClick ExpandCluster”.

À la suite d’une bascule DRP avec SRM, plusieurs machines ne se sauvegardaient plus. Après un rapide diagnostique, nous remarquons qu’elles indiquent être “managed by” SRM alors qu’il s’agit des VMs du site de production.

Nous avions déjà eu le problème en 5.5 et la KB2032366 VMs are reported as managed by Site Recovery Manager nous avait permis de résoudre le problème. Mais nous sommes maintenant en VCSA 6.5 avec  la version associée de SRM et plusieurs éléments de l’article ne correspondent plus.

Pour faire court, ne vous embêtez pas avec cette KB. Le support nous avait même indiqué comment retrouver notre chemin dans la mob mais cela n’a pas suffi.

D’ailleurs l’article n’est pas censé convenir à la 6.5 :

Comme SRM est un produit vraiment souple et magique… nous avons résolu en dé-enregistrant les VMs concernées de l’inventaire du vCenter, ce qui n’est pas le plus élégant. L’autre option, qui n’était pas envisageable pour nous, consistait à refaire une bascule complète.

Pour information le nettoyage de la mob à l’aide de la KB2032366, nous avait permis de refaire des sauvegardes mais pas de gérer manuellement les snapshots.

 

Voici une partie du script que j’utilise pour exporter mes informations d’hôtes à notre CMDB, l’intérêt principale de celui-ci est l’utilisation de “Get-View” et donc sa rapidité d’exécution.

$vCenter = Read-Host "Entrer ici le nom ou l'ip du vCenter"
Connect-VIServer $vCenter

#Creation du dossier pour l'export
md "C:\Scripts" -ErrorAction SilentlyContinue

#Inventaire Hosts
Get-View -ViewType HostSystem -Property Name, Config.Product, Summary.Hardware.Model, Summary.Hardware.MemorySize, Summary.Hardware.CpuModel, Summary.Hardware.NumCpuPkgs, Summary.Hardware.NumCpuCores, Summary, Hardware, Parent |

select Name,

    @{N='Product';E={$_.Config.Product.FullName}},

    @{N='Build';E={$_.Config.Product.Build}},
	
	@{N='Model';E={$_.Summary.Hardware.Model}},
	
	@{N='Memory';E={[Math]::Round(($_.Summary.Hardware.MemorySize)/ 1GB, 0)}},
	
	@{N='CpuModel';E={$_.Summary.Hardware.CpuModel}},
	
	@{N='CpuSocket';E={$_.Summary.Hardware.NumCPuPkgs}},
	
	@{N='CpuCore';E={$_.Summary.Hardware.NumCpuCores}},
	
	@{Name="Serial"; Expression={($_.Hardware.SystemInfo.OtherIdentifyingInfo | where {$_.IdentifierType.Key -eq "ServiceTag"}).IdentifierValue}},
	
	@{N='Cluster';E={
				
		$parent = Get-View -Id $_.Parent -Property Name,Parent
		While ($parent -isnot [VMware.Vim.ClusterComputeResource] -and $parent.Parent){
		$parent = Get-View -Id $parent.Parent -Property Name,Parent	}
		if($parent -is [VMware.Vim.ClusterComputeResource]){
		$parent.Name}}}, 
	   		
	@{N='DC';E={	  	  
		$parent = Get-View -Id $_.Parent -Property Name,Parent
		Do {$parent = Get-View -Id $parent.Parent -Property Name,Parent}
                While ($parent.Moref.Type -ne "Datacenter" -and $parent.Parent)
	        echo $parent.name}}	|
			
	Export-csv -NoTypeInformation -encoding "unicode" -append "C:\Scripts\export-Hotes.csv"

Voici le résultat dans Excel :