Unsolved
This post is more than 5 years old
2 Posts
0
108904
MD3000i and iSCSI Question
We have a MD3000i connected to a iSCSI San for VM Ware, 4 ESX servers and 2 VC servers, connected to a 6905 cisco switch. Two controllers in the MD3000i and 2 NICs in each of the ESX servers and VC servers dedicated to iscsi. All of these are on one subnet for the iscsi. We are getting great reads but poor rights. About 1.4mb for rights and 3-4 for reads. A few questions
What is acceptable throughput for this iSCSI. What can be tweeked?
Thanks
Message Edited by quadrille on 07-30-2008 11:35 AM
Dev Mgr
9.3K Posts
0
July 30th, 2008 19:00
Check your Cisco documentation to see if there is any info about optimizing the switch for iSCSI.
quadrille
2 Posts
0
August 1st, 2008 16:00
Also we are seeing the write cache suspened.
Read cache: Enabled
Write cache: Enabled (currently suspended)
Write cache without batteries: Disabled
Write cache with mirroring: Enabled (currently suspended)
Flush write cache after (in seconds): 10.00
Dynamic cache read prefetch: Enabled
Dell says this is not user configurable.
dkleeman
12 Posts
0
November 10th, 2008 10:00
Have you checked to see if there is a problem with your cache battery?
adam_n
2 Posts
0
January 14th, 2009 04:00
Just a quick note, you write "All of these are on one subnet for the iscsi", thats a big "no no". Each port on the controller on the MD3000i should be on a separate subnet, so you will need two subnets. each nic on the client should be on different subnets. Like this:
C(ontroller)1:P(ort)1 10.0.0.1
C1:P2 10.0.1.1
C2:P1 10.0.0.2
C2:P2 10.0.1.2
N(ic)1: 10.0.0.20
N(ic)2: 10.0.1.20
Then you make sure that both nics logs on to both controllers, you can verify that from the MD3000i managment application. Done right you will have the same write and read speeds, and as an added bonus you will have complete loadbalancing, fail over and no single point of failure.
/Adam
Dev Mgr
9.3K Posts
0
January 19th, 2009 06:00
Those entries for the write cache saying "currently suspended" doesn't look right. Did support have any feedback on why it says that? It looks to me like it has suspended (effectively disabled) write cache, which could play a role in your very low write performance.
dzenz
175 Posts
0
January 19th, 2009 08:00
Cache settings, including write cache (enabled | disabled) are end user configurable. See the Set Virtual Disk command in the CLI guide:
http://support.dell.com/support/edocs/systems/md3000i/en/CLI/PDF/CLIMR2g.pdf
Write cache will be suspended if there is a battery error or if the battery is currently in a learn cycle (the latter only applies to the Gen 2 update which introduced Smart Battery support).
Is the storage array in a Needs Attention state?
Dave
gbadenes
5 Posts
0
February 10th, 2009 04:00
I am experiencing exactly the same problem. Here goes an excerpt from the profile data:
Battery status: Optimal
Location: RAID Controller Module 0
Age: 27 days
Days until replacement: Not applicable
Last learn cycle: 14 January 2009
Next learn cycle: 15 April 2009
Weeks between learn cycles: 13
Part number: PN JY200
Serial number: SN 047118334386
Vendor: VN DELL
Date of manufacture: 01 March 2008
Battery status: Battery learning
Location: RAID Controller Module 1
Age: 27 days
Days until replacement: Not applicable
Last learn cycle: 14 January 2009
Next learn cycle: 15 April 2009
Weeks between learn cycles: 13
Part number: PN JY200
Serial number: SN 0471182J4767
Vendor: VN DELL
Date of manufacture: 01 February 2008
Virtual Disk name: test-RAID1-100GB
Virtual Disk status: Optimal
Read cache: Enabled
Write cache: Enabled (currently suspended)
Write cache without batteries: Disabled
Write cache with mirroring: Enabled (currently suspended)
Flush write cache after (in seconds): 10.00
Dynamic cache read prefetch: Enabled
I guess there must be a problem with one of the batteries (although everything is marked as "optimal"): if the last learn cycle took place on January 14 and the next one is scheduled for April 15, why is it still in "learning" state?
Cheers,
Gonçal
JOHNADCO
847 Posts
0
February 16th, 2009 09:00
I had some oddites with this when I did the second gen fw updates.
Only thing support and I ever figured out was to leave the san up for a long time after the update to complete the learn cycles.
Shutting it off before the learn cycle completes seems to lead to the oddites. best of luck, keep us informed please on how this progresses.
I do think your slow write issue is being caused be this as well.
JOHNADCO
847 Posts
0
February 16th, 2009 09:00
Just a reminder that when you fail a controller you are supposed to do a "redistribute controller ownership / prefered path" on all the VD's handled by the MD3000i.....
It may have fixed it, but you may be forcing all I/O to the controller that was left online is all.
gbadenes
5 Posts
0
February 16th, 2009 09:00
Thanks for the reminder! Indeed, I had forgotten to do it in the first instance, but luckily I noticed and corrected the mistake when I double-checked the configuration :)
gbadenes
5 Posts
0
February 16th, 2009 09:00
Hi!
I have actually removed the offending controller and inserted it back in. This has solved the issue (!) and now writing speeds are back to decent levels (e.g. ~50MB/s on a 3-disk RAID5 volume on ext3 filesystem).
In the mean time, we have also opened a ticket with technical support, just to see if they can find out whether there is anything wrong with the hardware.
Cheers!
dzenz
175 Posts
0
February 16th, 2009 21:00
Well, the MD3000i SAN is designed to never be shut off.
Might be obvious but I just wanted to point that out. ;-)
JOHNADCO
847 Posts
0
February 17th, 2009 07:00
Not so obvious.... I do keep our redundant offline MD3000i turned on now though, since I had issues with the controller battery. :) In testing and experience, those learn cycles are not to be interrupted or missed, and can cause issues.