Start a Conversation

Unsolved

This post is more than 5 years old

108904

July 30th, 2008 15:00

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

9.3K Posts

July 30th, 2008 19:00

I doubt you'll find an answer for acceptable throughput, but with VMware raid 10 is your best bet for performance, and obviously also a single virtual disk per disk group.

Check your Cisco documentation to see if there is any info about optimizing the switch for iSCSI.

2 Posts

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.

12 Posts

November 10th, 2008 10:00

Have you checked to see if there is a problem with your cache battery?

2 Posts

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

9.3K Posts

January 19th, 2009 06: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.

 

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.

175 Posts

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

5 Posts

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

847 Posts

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.

847 Posts

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.

5 Posts

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 :)

5 Posts

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!

175 Posts

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. ;-)

 

 

 

847 Posts

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.

 

No Events found!

Top