samedi 13 décembre 2008

Support, quand il ne reste plus rien d'autre ....

Je vais vous relater un petit retour d'expérience sur lequel certains devraient prendre modèle.
FalconStor a eu la gentillesse de me laisser tester un nouveau produit dans leur gamme : le Network Storage Sserver Virtual Appliance en environnement SRM.
FalconStor produit toute une gamme d'outils matériels qui permettent de virtualiser le stockage FC et donc de faire voir de la même manière des SANs à priori incompatibles. Les applications peuvent être la migration vers un nouveau stockage sans arrêt de prod, la réplication entre des baies provenant de constructeurs différents, le VTL, le thin provisionning ....Voilà c'est ça la virtualisation du stockage. NSSVA donc, est une appliance virtuelle qui permet de transformer l'un de vos hôtes ESX raccroché en FC à votre SAN, en target ISCSI avec possibilité de réplication synchrone sur IP avec un homologue : Les autres ESX n'ont plus qu'à monter les LUNs mis à dispo via ISCSI.
Malheureusement, lors de la création des protection group, les VMs répliqués à prendre en compte dans SRM, j'avais un message du Site Recovery Agent m'indiquant qu'il était impossible d'éxécuter les scripts afin découvrir les volumes à protéger.

Ca c'est fini à 1H00 du mat (heure française) en conf call & webex avec Pascal Bony de chez FaconStor France, le support de FalconStor US et les développeurs SRM de chez VMWARE.

J'ai appris par la même occasion que les logs de SRM se trouvent dans C:\Documents and Settings\All Users\Application Data\VMware\VMware Site Recovery Manager\Logs ... on ne sait jamais ça peut servir :)

Au final, j'avais décidé de m'appuyer sur un moteur Oracle 10G et deux bases pour l'hébergement des données de VC & SRM. Et bien le coupable c'est PERL.EXE, fournis à la fois par Oracle et par VMWARE mais dans des versions incompatibles. J'ai renommé le répertoire PERL d'Oracle en PERL.old et tout est rentré dans l'ordre. Une autre solution consiterait à modifier le PATH. Néammoins, FalconStor va modifier son SRA et le pb à été pris en compte chez VMware.
Voici un extrait des logs .... on peut dire que ça ne saute pas aux yeux et qu'il n'y avait guère que le développeur qui pouvait trouver.

[2008-12-13 11:32:59.406 'LocalSiteStatus' 4652 warning] Low memory: 0 Mb
[2008-12-13 11:33:31.656 'RemoteSite 'Site Recovery for 192.168.203.6'' 4652 warning] Failed to ping remote site
[2008-12-13 11:33:59.406 'LocalSiteStatus' 4072 verbose] Free disk space: 137492 Mb
[2008-12-13 11:33:59.406 'LocalSiteStatus' 4072 error] Can't collect counter value: Unknown error -2147481643 (0x800007d5).
[2008-12-13 11:33:59.406 'LocalSiteStatus' 4072 verbose] CPU usage: 0 %
[2008-12-13 11:33:59.406 'LocalSiteStatus' 4072 verbose] Available memory: 0 Mb
[2008-12-13 11:33:59.406 'LocalSiteStatus' 4072 warning] Low memory: 0 Mb
[2008-12-13 11:34:31.656 'RemoteSite 'Site Recovery for 192.168.203.6'' 1132 warning]

FalconSTor a vraiment sorti l'artillerie lourde pour traiter un problème lors de l'évaluation de l'un de ses produits, c'est suffisamment rare pour être souligné.

DSment Vôtre.

Aucun commentaire: