FreeNAS Replication/Clustering with ESX 5.5.x

[venomhed]

Hello folks,

I have a test lab using ESX vSphere 5.5. We have two physical hosts with 4 nics in each. I have used FreeNAS in the past but wanted to find out some suggestions on how to deploy 2 FreeNAS iSCSI San's in a cluster or failover replication scheme that works with ESX?

As mentioned we have two ESX hosts that are in a cluster and now two FreeNAS sans. How do I leverage these Sans to work with ESX in the event of a total failure? I would like to just have one SAN showing even though two are really there strictly for failover and redundancy.

Is this even possible? Is this more of an ESX question or a FreeNAS question?

Thanks so much for any design suggestions or guidance here. Appreciate it.

 

[zambanini]

not possible. you will need truenas.

 

[venomhed]

Care to elaborate? I guess it would be possible to use Replication between the two FreeNAS units and have an Active Passive deployment? The "fear" in my lab is to simulate a SAN outage by physical means. If that were to happen, if I had replication to the other online FreeNAS unit I should be able to see those VM's as well?

I guess I could even cross replication but I think that would get a bit confusing in the event of an outage.

Any thoughts?

 

[zambanini]

freenas has no shared ip service or something like HAST (well, but if you have to ask..it is not for you).

you can replicate the volumes, but everything else has to be changed manually.

 

[venomhed]

Ok, I see what you mean and since this is a lab that can be tested. I guess I will just setup the FreeNAS replication between the two SAN's and then also add those SAN's to ESX. Not sure how that will all work but I can get on the VMWare Forums and see a best approach.

Appreciate the reply. I think what I am looking for is built into more high end NAS products as you are implying like TrueNAS, Nimble and NetApp.

 

[jgreco]

freenas has no shared ip service or something like HAST (well, but if you have to ask..it is not for you).

you can replicate the volumes, but everything else has to be changed manually.

There are many problems inherent in any system that isn't using a live replication strategy. The data you happen to snap may not be in a fully consistent state, depending on what the VM is doing, for example. You can certainly use ZFS replication to blast a backup copy to a backup filer and then be mostly-ready-and-configured to mount it quickly. That's about as good as it gets.

 

[venomhed]

I am hoping to take snapshots of these test VM's every 15 minutes for up to 24 hours. We will also be doing internal backups twice daily. I am hoping that the snapshots can replicate to the other FreeNAS SAN so that we could indeed do a quick recovery in the event that the primary SAN died due to a hardware issue. Seems like this is doable in theory.

 

[jgreco]

I am hoping to take snapshots of these test VM's every 15 minutes for up to 24 hours. We will also be doing internal backups twice daily. I am hoping that the snapshots can replicate to the other FreeNAS SAN so that we could indeed do a quick recovery in the event that the primary SAN died due to a hardware issue. Seems like this is doable in theory.

Totally doable. How well a recovery works, though, is dependent on your VM's and how well they behave w.r.t. disk writes.

 

[venomhed]

My VM's at this point in time will all be Windows based - Win7, Server 2008-2012. Since this snapshot is outside the VM/OS I am not sure what to expect.

 

[jgreco]

My VM's at this point in time will all be Windows based - Win7, Server 2008-2012. Since this snapshot is outside the VM/OS I am not sure what to expect.

You can see if the new functionality to integrate with VMware helps any. In many cases, though, it is impractical to quiesce a VM so it is kind of fraught with peril. Properly designed VM's that perform consistency checks and the like upon reboot are a good idea, as are mitigation strategies for things that could be fouled up. For example, most of our VM's that run MySQL or PostgreSQL will store daily database dumps as a crisis-recovery aid in the event a crash scrambles a database file, and the rc scripts for the DB perform an integrity check when starting up.

Plan for failure and delight when it all just magically works without a problem.