I'm studying the migration and then the Integration of a SAN Equallogic to a DATACORE SAN.
The existing SAN Infrastructure is using one Equallogic Group composed of two members and replicated to a second Group.
Then in the new SAN infrastructure, Datacore Servers will be Front-Ends for hosts servers and, Equallogic will be one of the various Back-Ends Storage Resources.
I'm wondering what would be the best integration of EQL with Datacore, as Equallogic Pool need to be divided on volumes presented as LUN to a Datacore Pool. For example what is preferable to create many small volumes on Equallogic and present them to Datacore virtualization Pool, or to present a big EQL Volume to Datacore ?
Also if we decided to remove one member from the EQL pool after ressources have been used on Datacore servers , what will happened as the virtualization of Datacore is applying over the virtualization of Equallogic...
To be more "K.I.S.S" do you recommend to split the members from their own EQL Group, to present them separately to Datacore ?
Thanks for your answers.
Without more specifics of what types of IO are going to occur and what OS's where talking about it's difficult to make specific suggestions.
In general, more smaller volumes out perform few or one single volumes. it's not an array issue but one at the OS. A single disk means a single command tag queue AKA outstanding IO queue. If that queue fills up, IOs begin to back up until IO already in the queue is processed. With multiple disks you have a unique queue for each.
In virtualized environments we see this all the time. Even at the virtual level, having more 'disks' with multiple virtualized SCSI controllers the IO rates go up dramatically. Since the OS can continue to process IO on other disks while one is queue is full. Also in some clustered environments, the use of SCSI-2 exclusive reservation means one host make lock out access to a volume until it processes its IO then releases the lock. This means all other nodes will have no access to that volume until the release occurs. But if other disks were available to that cluster those disks would continue to process IO. So going back to the one mega volume option, in an VMware ESX cluster performance would be very gated as nodes reserved that volume.
If you have multiple members in a single pool and your OS supports one of the EQL Host Integration Toolkits. They're available for Windows, Linux, ESX these include enhancements to native Multipathing that results in more efficient use of these multiple members. Since such members have their data striped between them. It's not a requirement, to do so but it does yield better performance.
There aren't any real advantages to spitting the group into multiple if they're not going to be replication partners. Splitting them into pools within a group provides the same effect. The data isn't striped across members, you increase the number of iSCSI connections possible and you can move volume between pools live. So if you added a much faster array later, you can move volumes to that faster pools w/o any downtime. Not so if you have them in different groups.
Hope this help!
Thanks a lot Don for your interesting answer.
Hosts OS to the Datacore SAN are ESX 4.1 (SCSI-2), but Datacore Servers OS to the EQL are Windows 2008 R2 (not sure it’s possible to use EQL Host Integration Toolkits above Datacore) .
Then for performances, smallers LUNs would be better than one mega volume.
And splitting in Pools is a good option to consider regarding splitting in multiple Groups But it needs validation with Datacore experts.
I would like to reinforce that opinion with other people.
BTW, the more Virtual SCSI controller/disk was directly related to ESX, as is the more smaller disks because of the ESX's use of SCSI-2 exclusive reservations. ESXi v5 w/VAAI and EQL FW v5.2.2 lessen the times when that occurs but ESX hasn't eliminated it. Also, if you don't use MEM for ESX, then set Round Robin and tune the IOPs per path value to 3. EQL has a script you can run on each node to set the policy to Round Robin and the IOPs value.
Re: HIT. Datacore doesn't replace the iSCSI initiator nor their MPIO AFAIK, so HIT/MEM should be available.