Étiquette : backup

IMG_0603

Nakivo 7.5 : DDBoost et restauration cross-plateforme au menu

Posted on by Cédric

Vous le savez maintenant, je suis en partenariat depuis quelques mois avec Nakivo Backup & Replication, une solution de backup d’environnements virtualisés particulièrement légère et efficace, de mon point de vue.

Profitant, sans doute, d’un petit creux dans les annonces des grands éditeurs de l’IT en cette saison estivale, la société proposera dès demain, 1er Août, Nakivo 7.5 dont quelques points, en particulier, ont attiré mon attention. Premièrement, le support de DDBoost, l’API des VTL Datadomain. Se faisant, la solution inclus désormais dans son offre une option de dé-duplication à la source grâce à ce plugin. Le deuxième est, évidemment, le support officiel de vSphere 6.7 (même si ça marchait déjà très bien avec la version précédente).

Enfin, sans en savoir plus techniquement pour le moment, Nakivo étant compatible Hyper-V et vSphere, cette version apporte le support de restauration cross-plateforme ! Vous pouvez exporter les données d’une VM en VHD, VHDx ou VMDK, qu’elle soit issue d’un backup vSphere ou VMware. Certainement un grand plus pour vous qui travaillez en environnement hétérogène. Si j’en ai la possibilité, je ferais un petit test sur mon vLab, au moins pour la fonction export VMware ;)

Accessoirement, on trouve également le support des NAS Netgear (la série des ReadNAS) qui complète celui des Synology dans le segment professionnel “entry-level”.

Nakivo continue ainsi sur sa lancée pour progresser et faire de l’oeil aux entreprises – moyennes et grandes – capables d’investir dans du Datadomain, une très bonne solution de support de sauvegarde qui reste globalement assez chère par rapport à certains support moins intelligents mais beaucoup, beaucoup plus accessibles. Elle prouve, s’il en était encore besoin aujourd’hui, toutes ses ambitions. On peut imaginer sans peine un partenariat avec Dell EMC, pourquoi pas, sur certains segments dans l’avenir.

Pour plus d’information sur cette nouvelle version, rendez-vous ici
… et comme toujours, l’appliance Nakivo est disponible en mode trial à cette adresse. Amusez-vous bien !

img_9355

Cohesity : le Nutanix de la sauvegarde ?

Posted on by Cédric

On continue notre découverte de solutions originales, disruptives, avec Cohesity, un nouvel entrant, un de plus pourrait-on dire, dans le monde des appliances dites “de sauvegarde” mais dont l’approche et le périmètre adressé diffère sensiblement de “la masse”.

Cohesity est né en 2013 par la volonté d’un des anciens fondateurs de Nutanix, Mohit Aron et se développe rapidement depuis.

Contrairement à la plupart des offres du secteur, Cohesity s’attaque non seulement à la sauvegarde de VMs et de hosts physiques, mais entant aussi remplacer tout ou partie des autres types de stockage dit “secondaires” moins critiques, au moins en terme de performance : archives patrimoniales, filers, environnements de test et dev etc.

Lire la suite …

IMG_1030

MAJ : Contourner une erreur de vMotion “the source detected that the destination failed to resume”

Posted on by Cédric

Mise à jour le 09/07/2013 : une méthode plus simple (pas de ligne de commande), effectuez tout simplement un STORAGE vMotion de votre VM sur un autre datastore de votre environnement, ensuite, l’ESXi “lache le lock”. Merci à Mikael (qui se reconnaitra) pour l’info !

tipDepuis quelques semaines/mois, nous sommes confrontés sporadiquement à des erreurs de vMotion sur certaines VM de production. La VM en question commence son vMotion et termine en erreur aux alnentour de 65/75% avec l’erreur générique “A general system error occurred: The source detected that the destination failed to resume”. Si l’on regarde le détail de l’erreur, on découvre en fait un problème de lock au niveau des disques vmdk :

Capture

Après pas mal de recherches et quelques cheveux arrachés, il se trouve que le problème est lié à nos outils de backup de VM utilisant la fonction CBT. Cette fonction activée en standard sur les VM disposant d’un profil hardware 7+ génère des fichiers trace permettant de suivre les blocs modifiés entre chaque sauvegarde afin d’optimiser grandement le temps de parcours des vmdk. Pour une raison encore obscure, certains fichiers CBT sont lockés pendant la phase de sauvegarde, mais pas libérés.

Ceci étant, il existe une solution de contournement pour pouvoir s’en sortir. Il s’agit de déplacer les fichier de tracking de la VM dans un répertoire temporaire. Ces fichiers n’étants pas très gros (quelques Mo) cela ne pose pas de souci en terme de consommation d’espace disque. D’autre part, ces locks sont libérés au fur et à mesure que vous “entretenez” votre ferme VMWare via des reboots d’ESXi lors de remediations par exemple.

Voici la méthode : la VM “machine” est concernée par ce blocage de vMotion. Connectez vous en SSH (ou en mode console) sur le serveur ESXi sur lequel est hébergée la machine, placez vous à la racine du datastore qui contient la VM :
cd /vmfs/volumes/DATASTORE

Ensuite, créez un répertoire temporaire (qui va accueillir les fichiers lockés) :
mkdir temp_lockfiles

Maintenant, placez vous dans le répertoire de la machine virtuelle, en général identique à son nom lors de sa création :
cd machine

Enfin, déplacez les fichier “ctk” vers le répertoire temporaire précédemment créé :
mv *ctk.vmdk ../temp_lockfiles

Normalement, à l’issue de cette opération, vous devriez à nouveau pouvoir déplacer votre machine d’un ESXi à l’autre. Evidemment, le déplacement des fichiers de tracking et leur disparition du répertoire de la vm obligera votre outil de sauvegarde, à la prochaine échéance, à parcourir l’ensemble des disques.

Une autre petite astuce qui vous permet de savoir, avant d’utiliser cette solution de contournement, quels sont les fichiers lockés. Vous pouvez utilisez cette commande sur un fichier quelconque du datastore :
vmkfstools -D NOMDUFICHIER

Vous allez obtenir un listing de ce type :

Suivant le “mode”, vous pouvez savoir si le fichier est locké ou non : mode 0, le fichier n’est pas locké ; mode 1, il l’est.

En somme, il y a sans doute des problèmes purement VMWare par rapport à la gestion des locks sur ces fichiers de tracking et il va falloir investiguer plus avant avec notre cher éditeur de solutions de virtualisation.