Hi all
I am setting up a Business Continuity environment. To achieve SAN indipendence I would like to set up VM with two virtual disk: one will be hosted on a SAN, the other on a second SAN.
Disks will be mirrored inside the VM OS by a third party volume manager agent.
If one of the SAN goes down and I restart my VM it won't start because the .vmdk indicated in the vmx files will be missing.
Is there a way to avoid this control?
I've managed to find the setting:
scsi.returnBusyOnNoConnectStatus
Used on 2.x to simulate disk failures, but I can't find a setting to exclude the control of the .vmdk at boot time.
Any idea?
Thank you.
Fabio
Why using Business continuity based on disk failures?
LUNs corruption is an extremely difficult event to happen!
I would rather think to HOST failures recovery using ESX Clusters on VC.
If you have two sites you have 2 SAN... and SAN replica always require a reboot of the VM
That's why I mention BC instead of DR.
Message was edited by:
Aketaton
Aketaton. SAN failures are very very difficult events to happen.
I think you should simulate such an event because I'm not sure that you can implement Business continuity in this way, you can do only Disaster Recovery.
Even if you have one disk on the first SAN and another on the second you should have configuration files on one of the two.
When this SAN go down vm will crash.
I think that the only way to do it is using Business Continuity Volumes for example and specific SAN software.
>Even if you have one disk on the first SAN and another on the second
>you should have configuration files on one of the two.
>When this SAN go down vm will crash.
As a matter of fact, thinking about the details, with the old 2.x architecture it was easier to implement sw based replication within the vm's because the sw based replication is responsable for mirroring the only object on the san that is the vmdk file. Now with the new 3.x architecture you have everything on the SAN (vmx etc etc) and there is no easy way / out of the box solution to replicate these files on both SANs (unless you use proprietary SAN replication mechanisms which have their own limitations).
I am pretty sure though we will see interesting technologies coming out in the next future to create more "out-of-the-box-DR" type of scenarios.
Stay tuned.
Massimo.
I am pretty sure though we will see interesting technologies coming out in the next future to create more "out-of-the-box-DR" type of scenarios.
I guess you mean something like Double-Take[/url]... Haven't tried it yet, but it looks promising, especially since they're leveraging technology they have been using for many years between Windows machines.
Paulo
Paulo,
no I was not referring to that, which is a product I don't know but I am pretty sure it has a purpose ......
Massimo.
Hi, Massimo!
In short, Double-Take does block-level real-time replication of file changes on separate servers through the network. It's installed on ESX and allows us to replicate files on VMFS volumes (.vmx, .vmdk, etc.) to another ESX server (or volume). This provides more granularity and is more "hardware agnostic" than LUN replication. The downside is that it puts an extra burden on both the servers and the network, but life isn't perfect... :smileygrin:
Ok, showed you mine, will you show me yours? What products were you talking about? Or is it still under NDA?
Paulo
Message was edited by:
paulo.meireles
Can't really say much ...... not that I know a lot either ...... but as far as I have heard it's going to be interesting/cool .... whatever that is ..... from whover that will be .......
Massimo.
Aketaton. SAN failures are very very difficult events
to happen.
I think you should simulate such an event because I'm
not sure that you can implement Business continuity
in this way, you can do only Disaster Recovery.
Even if you have one disk on the first SAN and
another on the second you should have configuration
files on one of the two.
When this SAN go down vm will crash.
I think that the only way to do it is using Business
Continuity Volumes for example and specific SAN
software.
Believe me: a SAN failure can happen
Configuration files are another issue, you're right, that's another issue I will have to face with VI3. Probably some software line Veritas Cluster 5 could help me: I've to take a look at it as soon as possible.
I need a BC environment with total indipendence from HW: be it ESX host or SAN...
Thanks for pointing this out
Can't really say much ...... not that I know a lot
either ...... but as far as I have heard it's going
to be interesting/cool .... whatever that is .....
from whover that will be .......
Massimo.
This solution (obscure and misterious) looks appealing... 😛
When this will be relesed? 😛
Message was edited by:
Aketaton
As far as I know it's still in the works ..... might be by year end or might be next year .........
I suggest you don't hold your breath though......
Massimo.
What kind of SAN?
If you have a lot of money my suggestion is using a redundant mirrored SAN (SANCopy or similar software inside) Volumes.
We have a project with two CX500 one active and the second stand by.
this is the best I think.
IMHO SAN failures are dued to unstable firmware revision.
Look for upgrades.
>Can't really say much ...... not that I know a lot either ...... but as far as I have heard it's going to be interesting/cool .... whatever that is ..... from whover that will be .......
As far as I know it's still in the works ..... might be by year end or might be next year .........
Clear as mud... Ok, at least we know someone is doing something about it... ...or do we just suspect so?! :smileygrin:
Paulo
One of my colleagues pointed out a thing I must take into account:
Swap files for VM are stored on the SAN so probably it is not possible to survive a SAN crash even if I mirror the virtual disk with a software raid inside the VM.
Sbonk... I have to re-think my infrastructure..
SAN crashes are rare event to happen!
If you have infinite money you can use a spare SAN with a mirroring software on it. For example EMC SANs use SRDF and Dell MirroView to replicate data over SANs