Skip to main content
Start a Conversation

Unsolved

This post is more than 5 years old

PaulNSW

2 Posts

9380

July 4th, 2018 03:00

VMware 6.7 MEM support

Any idea when this will be available?

dwilliam62

6 Operator

 • 

1.5K Posts

 • 

6.4K Points

August 12th, 2019 19:00

Hello, Yes it is in the works. Are you running SANHQ? How many servers? MEM provides maximum performance benefit in multiple member pools, especially when you have three or more members. That's when MEM really shows greater performance over native round robin with IOs per path change to 3 from default of 1000. So if you have SANHQ you can see how much IO you are using. If you aren't pushing anywhere near maximums not having MEM won't likely hurt you at all. Just make sure all best practices are configured. One that is often missed is sharing multiple VMDKs or RDMs on a single virtual SCSI controller in each VM. Each VM can have up to four. I like to compare it to one person doing four jobs or four people doing one job each at same time. This helps with SQL, Exchange, etc.. Where multiple disks are being accessed at same time. This PDF covers all of these settings. https://downloads.dell.com/solutions/storage-solution-resources/BestPracticesWithPSseries-VMware%28TR1091%29.pdf The other MEM benefit you don't have to remember to optimize the MPIO parameters every time you set up a server. Just install MEM and that part is set. So your plans to move to v6.7 or use these arrays for another year should not be impacted by lack of MEM right now. I would make sure all your arrays are running 10.0.3. The current EQL firmware. The next version of MEM is only certified again 9.1.x and 10.0.x firmware. Regards, Don

Lady Margaret

7 Posts

August 15th, 2019 11:00

Hi Don,

Thanks for the info, very useful. No, I'm not running SANHQ, so guess I'm operating blind in terms of IO performance. I've just recently inherited the responsibility for this setup, an existing implementation of 2x PS6210 and 1x PS4100 all configured as a single pool. There're 6 ESXi hosts connected, the fabric is 1000Base-T which is a lowest common denominator so as not to mix connection speeds as per the PS Series Best Practice documentation. Firmware is 10.0.2, so one dot release off current.

Hence why I'm interested in configuration for best performance over the 1G fabric.

As you mention, the first step I guess is to deploy SANHQ to get some visibility of IO.

Regards

dwilliam62

6 Operator

 • 

1.5K Posts

 • 

6.4K Points

August 15th, 2019 17:00

Hello, re: SANHQ. Definitely! It's a great tool. Did you also set the ESXi servers to best practices per TR1091? Regards, Don

Lady Margaret

7 Posts

August 17th, 2019 10:00

Hi Don,

Yes, I've verified the implementation against TR1091 and the referenced articles (specifically TR1075 - Configuring iSCSI Connectivity with VMware vSphere 6 and Dell PS Series Storage). All seems to be compliant.

What I'm conscious of is that with a multi-host, multi member, MPIO setup (all operating over 1G fabric), is that there'll be a tipping point where with enough IO demand, the routing/referral operation of the PS members will fall off a cliff.

Yeah I need to deploy SANHQ to get visibility, but the reality is with the vSAN deployment being around a year away, I'm really wanting to have a card up my sleeve I guess.

Thanks

dwilliam62

6 Operator

 • 

1.5K Posts

 • 

6.4K Points

August 17th, 2019 15:00

Hello, I would make SANHQ install my priority here. Begin gathering data to see what percentage of IO you are using and when. Re; Best practices. If you set them AFTER you discovered the volumes then the best practices aren't set on those volumes. Only one new ones you create. You have to remove all the discovery addresses then clear out the static mappings. Reboot. Then set the best practices and rescan. Then the DB ESXi uses will be properly populated. re: "Fall off cliff" With only three members you are likely to run out of disk IO before you run out of network capacity. Even at GbE. Especially with ESXi since that tends to be high IO rate demand, less MB/sec demands. MEM does help you get more IOs as the load scales up. That is true. But you don't know what the load is yet. Also I don't believe the wait for MEM to be available will be very long. Regards, Don

ChadCorkrum

1 Rookie

 • 

24 Posts

September 17th, 2019 09:00

I'm wrong, release notes say 6.7, the webpage says 5.5-6.5!

Looks like the sun has shown through!!

 

ChadCorkrum

1 Rookie

 • 

24 Posts

September 17th, 2019 09:00

I see MEM 1.6 was just released, doesn't say ESXi 6.7 though, is it supported or not?

dwilliam62

6 Operator

 • 

1.5K Posts

 • 

6.4K Points

September 18th, 2019 05:00

Hello, Correct. It should say ESXi v6.0 through 6.7. ESXi v5.5 is not supported by MEM v1.6 Also the minimum firmware is v9.1.x. Regards, Don

dwilliam62

6 Operator

 • 

1.5K Posts

 • 

6.4K Points

September 18th, 2019 08:00

FYI:

The download page has been corrected. 

Thank you. 

Don 

 

ChadCorkrum

1 Rookie

 • 

24 Posts

September 18th, 2019 11:00

I see LRO made it into the install guide, so have the decided that it should be disabled again? Other performance tuning guides had removed mention of it. Thanks

dwilliam62

6 Operator

 • 

1.5K Posts

 • 

6.4K Points

September 19th, 2019 22:00

Hello, 

 Unlike the the other best practices, like Delayed_ACK and tuning round robin IOs per path,  LRO seems to be a case of "your mileage may vary".    With benchmark testing it usually comes out a little better.  

 I have never seen it provide a large bump in performance.  Especially compared to Jumbo frames or proper MPIO tuning.  Or in VMware adding additional Virtual SCSI adapters in each VM with multiple VMDKs/RDMs.   Those are clear and easy to measure. 

 You would need to establish your baseline IO very carefully, make the change and observe results over time. 

  Regards, 

Don 

 

Was this post helpful?

View All

No Events found!

Top