We're currently investigating Open-E as a solution for our iSCSI backend for Xen virtual machines. We want to know if and how the following setup is possible :
- Using a dualcontroller FC array (Infortrend) as storage backend.
- Two Open-E iSCSI servers both import half of the capacity of the backend array and vitualize / export this as iSCSI...two servers to increase performance.
- Use one extra Open-E iSCSI server as a spare.
I guess normally you would replicate to give a spare server access to the same data as the active server, but in this case there's nothing to replicate I guess because of the FC array having all data on it.
What I would like to know is how to get that spare server take over the job in case one of the active servers fails...is it possible and how do we do this...if there's any estimate for the time it takes I would like to know that as well...
Thanks in advance and regards,
Werner Reuser
XL-Data Hosting, Development & Consultancy
Currently DSS Volume Replication for iSCSI Targets is manual failover.
Typical setup would involve the following:
1 - DSS set as Source - located in Volume Replication
Logical Volumes to be set the same size
1 - DSS set as Destination - located in Volume Replication
Logical Volumes to be set the same size
If Source failed logically or physically set Destination to Source. Then set failed Source to Destination.
Then enable the Target in Target Manager and access the initiator to logon the Target IP address of the new Source.
You can download and test with DSS for a full 30 day trail version by accessing link below additionally the manual and online help to assist.
I read your answer, but it doesn't really answer my question...I'm aware of the typical setup with replication involved. But that's the case for two boxes having their own local storage. My setup would be using two boxes running on top of shared FC storage...and one extra box that 's passive and should only be used to replace one of the two active boxes in case of failure.
My question regarding that setup is it possible to use that extra box as a spare and how to get that second box failover the broken one...I know it isn't an automatic failover. Main issue would be to get the spare to run with the config of the active box that has failed...so all FC imports, volumes and exported lun's will be available again within the shortest time...
Using a demo cd wouldn't be much of a help...I'm not going to invest in the other equipment unless I'm certain of this...
So if you could be some more specific I would be happy
From your first question you asked if “how to get that spare server take over the job incase one of the active server fails”. This can be done from our Volume Replication (iSCSI Target) feature where the Source Target is active. If Source has failed and “spare server take over” then Destination server of the mirrored Source Volume being replicated would take over as Source. The iSCSI servers would have their own independent storage from the FC Storage backend and can utilize MPIO. Each iSCSI server would have its own storage but currently you can have only 1 to 1 relation with our Volume Replication – meaning Server A (has a value size of xxxTB or GB for designated target volume) to Server B (has an equal value size of xxxTB or GB for designated target volume) only for Source to Destination. So if Source fails then Destination will become Source and the mirrored iSCSI Target Volume from the failed Source will be available by enabling the Target for the promoted new Source Server. The time to do this would be very short (several clicks to enable this). We do not have this documented with Xen virtual machines for your specific inquiry, so this is why I was providing you the 30 day evaluation of our software to perform some test as most of our enterprise customers do this in a simulated test lab to assist their process. The only way to share the same capacity pool would be to have DSS on the front end and use the iSCSI initiator to access the iSCSI-R3 servers on the back end then create a Volume group (using Software RAID) from the 2 iSCSI-R3 servers. You may feel free to contact us on pre-sales questions at T: +49 (89) 800777-0 for UK territories or 770-881-7680 for North America territories.
Thnkz for the answer...
In short what I understood from it...each active iscsi server has it's own storage, in this case a fc volume. And each active iscsi server needs it's own standby server to replicate to...is this correct ?
The replicating part confused me a little because there's no need to replicate data from the volumes...but I guess you mean the configuration is replicated...right ?
I didn't really understand what you mean by a DDS server in front of two iscsi r3 servers...it seems to me an extra layer is added that doesnt really give me more high availability....but I guess that's my way of thinking messing this up...could you explain that ?
As for the Xen thing...it should work...but were waiting for Xensource to come out with their next version that supports iSCSI in a decent way....now they import large iscsi volumes and use lvm2 on top of that locally to create volumes for the xen guests...
But we tested some with the open source hypervisor and open-iscsi and it worked like a charm...
Hopefully Xensource and Open-E soon release new versions so Open-E has HA support and Xensource supports a volume for each Guest...sometimes the world can be really great
As I'm from the Netherlands I don't know what area I'm in for pre sales questions...
Anyway...lots of thanks for your answers...
Correct to replicate you will need 2 - iSCSI servers. Let me try another way as well.
Server A config:
FC HBA ---> (Direct connected or with Switch) to FC Storage system (DotHill, Infortrend..whoever).
iSCSI Target Logical Volumes created from FC Storage then marked for replication.
Target Volume is set to Source then add mirror IP Address of Destination Server.
Then select the Logical Volume to replicate start task.
Server B config:
FC HBA ---> (Direct connected or with Switch) to FC Storage system (DotHill, Infortrend..whoever).
iSCSI Target Logical Volumes created from FC Storage then marked for replication.
Target Volume is set to Destination then add mirror IP Address of Source Server.
The replicating Source Target Volumes where the data will be replicated to the Destination server not the configuration.
Never mind the DSS on the front end this was incase you needed additional 99.999% uptime and replying to your needs incase this was what you where interested in. But let's drop that configuration as this was not what you need and if you did I would send you a design on power point instead of text.
If you could be so kind as to add your knowledge on the VMware section of this Forum as did others to help them as well
Unless I am missing something you should be successful with our iSCSI-R3 Ent. version as we use lvm2 as well and the open-iscsi we support .
I am interested in your powerpoint...I just didn't get the point you wanted to make with the dds setup...
And I still don't see why replicating the volume data as it is on shared storage...I got the feeling you want to give the standby server it's own FC volume so all data will be available twice on the FC array...When I import a FC volume on a linux box and create volumes on it using LVM2 I can have any other linux box import the same FC volume and it sees all LVM2 created volumes...So only thing left to replicate would be target config, snapshot schedules and all other sorts of config files...
I guess it should also be possible when I have a single Open-E box using a FC backend and it completely dies to get my data back on line without anything missing ? A simple config backup of the Open-E box should do the trick (if possible)
I would be happy to post some stuff in the vmware section (rename to virtualisation software ??? ) As soon as I have a beta for the next version I will post some howto's...
For know linux users that do not have serious experience with iscsi can use Kiscsiadm a small desktop tool to makes iscsi initiator management very easy. http://sourceforge.net/projects/kiscsiadm/
If you do not plan on using the DSS for the front end and 2 x iSCSI-R3 Ent. on the back using the initiator built in from the DSS then will not be part of your needs.
We currently do not replicate the config (snapshot, backup, users….) only the iSCSI Volumes. But the config can be stored on the module and on your host system.
If possible download the Demo-CD. Over 90% that do usually have all the answers they need. New release to come out next week 1.21 for DSS.
We appreciate any updates to the VMware section and others will too.
Yes this is a great initiator management tool to for sharing this to every one.
I guess it shouldn't be a problem to backup config for each host system...that creates a setup where it is fairly easy to restore everything to a spare node...
For our case the iSCSI R3 dom's would fit great into the plan, but I think we will use the DDS dom's...NFS sharing is always nice to have and the other features might be handy some time as well...
I will download a demo version to try some stuff...but it will be hard to simulate my setup without the FC hardware available
When I find something usefull for this forum I will post it !
Redundancy...
Reply With Quote
