Bonjour à tous,
je rencontre un problème à la mise en place de mon PRA et j'aurais besoin d'un avis éclairé ;)
Je dispose de 2 baies P2000 G3 iSCSI et de la licence Remote Snap de réplication. J'ai mis en place une réplication de volume suivant : Vol_02 Primary volume 2400GB / Snap Pool 587GB / Réplication toutes les 2H, sur 3 Replication images
Pas de message d'erreur pour la réplication. Le SAN primaire est relié à 2 vsphere 5.5 en iSCSI, volume visible, VM montées et opérationnelles. Le SAN secondaire est relié à 3 vsphere 5.5 en iSCSI.
La procédure de basculement prévoit de passer le volume secondaire en primaire (et le primaire en secondaire), d'unmap l'ancien volume primaire et de map le nouveau volume primaire.
Jusque la tout se passe bien.
C'est à l'ajout du Datastore sur les serveurs du PRA que je rencontre un problème.
l'Hote voit bien les paths iSCSI, un ajout du Datastore fait apparaître le volume, je choisis "Keep signature", je valide, mais le Datastore n'apparait pas. Les log vmware mentionnnent :
2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8389: Device naa.600c0ff0001bb2b00bc8c25401000000:1 detected to be a snapshot: 2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8396: queried disk ID: <type 2, len 22, lun 1, devType 0, scsi 0, h(id) 3984229857219157175> 2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8403: on-disk disk ID: <type 2, len 22, lun 1, devType 0, scsi 0, h(id) 4696608278127668448>
Pourtant le volume est indiqué comme Master volume dans la baie :
Vdisk Name Size Serial Number WR Policy Cache Opt Read Ahead Size Type Class Qualifier ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- VDReplication rVol_02 2399.9GB 00c0ff1bb2b000000bc8c25401000000 write-back standard Default master volume PTSNAP RSR
Si quelqu'un de la liste à la solution je suis preneur ;)
Merci d'avance
Cordialement,
J. Talbot
Hello,
2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8389: Device naa.600c0ff0001bb2b00bc8c25401000000:1 detected to be a snapshot: 2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8396: queried disk ID: <type 2, len 22, lun 1, devType 0, scsi 0, h(id) 3984229857219157175> 2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8403: on-disk disk ID: <type 2, len 22, lun 1, devType 0, scsi 0, h(id) 4696608278127668448>
Essai de le monter via "esxcfg-volumes -M <uuid>" Ton ESX le detecte en tant que snapshot et ne l'utilise pas, il suffit donc de le forcer.
Benjamin,
Bonjour,
J'étais passé à côté d'une KB mentionnant le problème http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd...
Merci ;)
Pour info, la commande sous vsphere 5.5 est "esxcli storage vmfs snapshot mount -u <uuid>"
De manière générale, comment gérez-vous un basculement vers un PRA ? Tout en manuel, un peu de scripting ou la solution vmware Site Recovery Manager ?
Cordialement,
J. Talbot
2015-07-20 11:21 GMT+02:00 Benjamin Mercier benjamin@mogui.fr:
Hello,
2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8389: Device naa.600c0ff0001bb2b00bc8c25401000000:1 detected to be a snapshot: 2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8396: queried
disk ID:
<type 2, len 22, lun 1, devType 0, scsi 0, h(id) 3984229857219157175> 2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8403: on-disk
disk ID:
<type 2, len 22, lun 1, devType 0, scsi 0, h(id) 4696608278127668448>
Essai de le monter via "esxcfg-volumes -M <uuid>" Ton ESX le detecte en tant que snapshot et ne l'utilise pas, il suffit donc de le forcer.
Benjamin,
Hello,
Personnellement je préfère un bon script quand les compétences sont là et que le PRA est testé régulièrement (1 ou 2 fois par ans minimum).
SRM est intéressant quand tu n'as pas le temps/les compétences en internes pour t'en occuper, où quand tu dois répondre à des contraintes fortes de reporting/supportabilité de la solution par un éditeur. C'est cher (double licence vCenter + packs de licences par VM), mais en général une fois posé ça "juste marche".
Techniquement, si il n'y a pas de changement d'IP dans les VMs à faire, un "bête" script de quelques (une 10aines) lignes suffit à faire la bascule (parcours des datastore, enregistrement des .vmx, power on + réponse à la question posée avec la réponse "I moved it"). Si tu as du changement d'adresse IP a prévoir, c'est un peu plus complexe, mais tout à fais faisable (avec une bascule DNS + un script/service au lancement de la machine, avec l'API VIX et les VMware Tools installés dans les VMs, etc.).
Après en général, un PRA ça reste souvent le dernier recours, on vas préférer un PCA avec une répli synchrone si la criticité est forte (quitte à investir des sous quelques part, je le ferais dans un PCA bien montée et de la répli synchrone, plutôt que dans SRM pour automatiser un PRA...).
Sylvain.
2015-07-20 18:17 GMT+02:00 Naigel naigel76@gmail.com:
Bonjour,
J'étais passé à côté d'une KB mentionnant le problème http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd...
Merci ;)
Pour info, la commande sous vsphere 5.5 est "esxcli storage vmfs snapshot mount -u <uuid>"
De manière générale, comment gérez-vous un basculement vers un PRA ? Tout en manuel, un peu de scripting ou la solution vmware Site Recovery Manager ?
Cordialement,
J. Talbot
2015-07-20 11:21 GMT+02:00 Benjamin Mercier benjamin@mogui.fr:
Hello,
2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8389: Device naa.600c0ff0001bb2b00bc8c25401000000:1 detected to be a snapshot: 2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8396: queried
disk ID:
<type 2, len 22, lun 1, devType 0, scsi 0, h(id) 3984229857219157175> 2015-07-20T07:54:12.818Z cpu7:34015 opID=83c4915a)LVM: 8403: on-disk
disk ID:
<type 2, len 22, lun 1, devType 0, scsi 0, h(id) 4696608278127668448>
Essai de le monter via "esxcfg-volumes -M <uuid>" Ton ESX le detecte en tant que snapshot et ne l'utilise pas, il suffit donc de le forcer.
Benjamin,
Liste de diffusion du FRsAG http://www.frsag.org/