Linux based iSCSI with automated mirroring for VMWare storage

Toggle sidebar Toggle sidebar
dgingeri

dgingeri

Distinguished
Dec 4, 2009
2,123
1
20,460
OK, I'm in a sensitive spot with a new job, where previously purchased (by an old employee who is no longer here) hardware left me with two VMWare hosts with local only storage, but are supposedly clustered. The trick is that the VMs can't move between the hosts without powering down, no matter of they are clustered or not.

VMWare makes a solution for this in the form of Virtual SAN, but paying for something like that is probably unlikely any time soon with this company. So, I'd like to see if I can find an open source solutions for this.

Does anyone know of a Linux open source iSCSI target software that can handle 13TB and do mirroring between two iSCSI targets without getting the hosts involved?

I'd like to create two VMs on the hosts' internal storage and create mirroring iSCSI targets, where the hosts just see two IPs for multipathing to a single virtual iSCSI target, and then run the other VMs from the iSCSI mirror. If either host goes down, the other will have a mirror of the VMs and bring them back up automatically. Does this sound doable?
 
Solution
S
if that's what you want, but you still have the issue of Vmotion. Each ESX only see their own storage. This means that if you lose a host, you would have to manually bring it up on the other host - it won't go automatically.
Sort by date Sort by votes
That would be nice, if we had some form of shared storage. I don't have any resources to just add more storage. In addition, they spend a bunch of money getting the current internal storage, 15 2.5" 900GB 10k drives each, which they would not like to see go to waste. That's why I'm looking to export the storage through iSCSI virtual appliances, mirror it, and then connect it back to the hosts to store the VMs.

If I can pull this off, getting proper VM host redundancy and mirroring the storage and no wasted resources and not spending any extra money, then I'd be sitting pretty with management, probably for years to come.

While it won't cost me my job right now to not get this figured out, it may be used as a mark against me later. I'm barely more than a week into this job so far. I'd like for the job to last me a while.
 
Upvote 0 Downvote
take one of the servers off-line and put all the vm's on the other one. Take the storage drives out. Put those drive into another server(buy one). Put freenas on it, and create a storage array with those drives. Put the esx server back online and connect the iscsi to the new storage, and then migrate the vm's back to the esx server connected to iscsi storage. Then do the same with the other esx - move the drives and create an additional array - you'll end up with 2 arrays of shared storage that both esx hosts can see(shared storage) utilizing the existing(already purchased) drives.
 
Upvote 0 Downvote
The other option - which should have been done in the first place(by the other guy) is to get a consultant in to design you a system, and give you a working plan to get where you need to be. It may cost a little, but for a small shop it is probably worth the extra cost(should have already been done) to make sure it got built correctly in the first place.
 
Upvote 0 Downvote
Don't be afraid to tell management that you can do the work, but you need help with the design to make sure you end up with a hearty system that will last for years, and will be easy to maintain and upgrade. What you have now isn't going to be able to be upgraded without downtime, and that defeats the whole point of having virtual servers.
 
Upvote 0 Downvote
I'm capable of writing up such a plan. I have built a dozen vSphere clusters before, with shared FC storage. So there's no need to hire that out. There were many reasons why the other guy was fired days after the offer was made to me and days before I started, not the least of which was this. Now I have to do what I can with what I have. It will take half a year or more before I will be able to purchase anything for this, so I was trying to find a way to get it going the way we need until we can buy things that will correct it.
 
Upvote 0 Downvote
OK, I've come up with something. We have an server that is being retired from service as a backup SAN for the desktop units that has 2 10Gb ports, but is still fairly new. (The desktop backup program never worked, and we finally gave up.) I'm going to create standard iSCSI targets based on Linux on each ESXi host, and then use this other server to mirror them and direct them for access from the hosts as iSCSI storage. It's a little complicated, but I believe it will work for now.
 
Upvote 0 Downvote
Ok I think I got the mirroring part. Your existing storage(on each ESX) is not shared - it's mirrored. This is why you have to shut down to migrate.
With the new shared storage you shouldn't need to mirror anything.
What you do want to do is back up your storage.
 
Upvote 0 Downvote
The 'new' storage is still the local storage on the hosts, so if either host goes down, half the storage goes down. The old backup SAN server is just facilitating mirroring and sharing. If I don't mirror them, if either host goes down, the VMs that were housed on that local storage won't be accessible, and can't be brought back up on the remaining host.
 
Upvote 0 Downvote
I thought the new storage was over on the new server and will be connected to the esx with ISCSI. If you present the ISCSI to both esx servers, they should both be able to access it and migrate between them while VM's are powered on.
Once you present the ISCSI and set it up on the ESX host, it should see the additional storage location, and all you need to do is storage migrate your vm's to the iscsi storage.

What you're doing is moving away from the local storage on the ESX boxes, and onto the shared ISCSI storage.
 
Upvote 0 Downvote
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom