3PAR Users Group

A Storage Administrator Community




Post new topic Reply to topic  [ 12 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: 3PAR VV for datastores Vmware
PostPosted: Mon Jan 28, 2019 5:16 am 

Joined: Thu Jun 28, 2018 8:26 am
Posts: 9
Hello,

We use 3PAR 8400 (4 nodes) with Vmware vSphere 6.5.

Actually, we have 4 VVs for 4 Vmware Datastore (cardinality 1:1), one VV for one Datastore.
Each hosts own 2 HBA (16Gbps)

Each VV is sized with 15To (dedup, thin).
We host about 150 Vms (application, database, and so on), anyway very eclectic !
I heard many different things about max sizing VV, do you think 15To for a VV is too high ?

Thanks for your advise.

Best regard

Speedypizz


Top
 Profile  
Reply with quote  
 Post subject: Re: 3PAR VV for datastores Vmware
PostPosted: Mon Jan 28, 2019 6:22 am 

Joined: Wed Nov 09, 2011 12:01 pm
Posts: 337
Personally I'd prefer smaller VVs for running VMs on, we currently use 1-2TB VVs for general VMs but have larger VVs for specific large data VMs (up to around 10TB atm).

VMware can now be configured to use the VVs automatically for distributing where VMs are stored so little management overhead with lots of VVs.

It's normally the number of VMs/Datastore that drives this, our VMware Team tend to prefer between 10-20 small VMs per datastore so have been happy to stick to 1-2TB VVs.

However I would be happy if are Solaris Team would use bigger VVs, they tend to like loads of 20GB ones, getting them to use fewer 200GB ones was challenging. ;)


Top
 Profile  
Reply with quote  
 Post subject: Re: 3PAR VV for datastores Vmware
PostPosted: Mon Jan 28, 2019 6:38 am 

Joined: Mon Sep 21, 2015 2:11 pm
Posts: 934
Location: Europe
I would say "maybe".

Remember that each vmware host has one I/O queue for each datastore. So one VM on one host might impact other VMs on the same host using the same datastore more than it would if the other VMs was on another host or another datastore.

I second Ailean. I prefer smaller datastores/VVs with less VMs and I have no issues creating huge datastores for large single VMs.

Your problem will become apparent if you have 15TB datastores with 150 VMs of 100GB and suddenly two of those start running IOMeter.

_________________
The views and opinions expressed are my own and do not necessarily reflect those of my current or previous employers.


Top
 Profile  
Reply with quote  
 Post subject: Re: 3PAR VV for datastores Vmware
PostPosted: Mon Jan 28, 2019 6:53 am 

Joined: Thu Jun 28, 2018 8:26 am
Posts: 9
Ok,

Thank you all for your opinion.

It's more clear in my mind now :)

Speedypizz


Top
 Profile  
Reply with quote  
 Post subject: Re: 3PAR VV for datastores Vmware
PostPosted: Wed Jan 30, 2019 3:25 pm 
User avatar

Joined: Tue Oct 07, 2014 8:34 am
Posts: 184
I have seen multiple cases were Datastores become corrupted and unusable.
If you're have a Big one you will have a big issue.


Top
 Profile  
Reply with quote  
 Post subject: Re: 3PAR VV for datastores Vmware
PostPosted: Fri Feb 01, 2019 11:12 am 

Joined: Tue Mar 29, 2016 9:32 pm
Posts: 106
We run multiple small datastores (4TiB is the size we chose) rather than giant sized ones.
Take a look a Vvols that's our next step, each VM has its own set of volumes from the 3PAR.


Top
 Profile  
Reply with quote  
 Post subject: Re: 3PAR VV for datastores Vmware
PostPosted: Fri Feb 01, 2019 1:38 pm 

Joined: Mon Sep 21, 2015 2:11 pm
Posts: 934
Location: Europe
markinnz wrote:
We run multiple small datastores (4TiB is the size we chose) rather than giant sized ones.
Take a look a Vvols that's our next step, each VM has its own set of volumes from the 3PAR.


Vvol are generally a good idea, but for siloed organisations it may cause the same conflicts as with hyper-converged... Server/virtualisation teams doesn’t always understand storage and with Vvol everything is controlled from vCenter and storage teams will have limited access/visability.

Also I still think there are some storage feature available on 3pars (and other systems) which are still not available with Vvol because the storage systems doesn’t control the volumes.

_________________
The views and opinions expressed are my own and do not necessarily reflect those of my current or previous employers.


Top
 Profile  
Reply with quote  
 Post subject: Re: 3PAR VV for datastores Vmware
PostPosted: Sat Feb 02, 2019 2:24 pm 

Joined: Tue Mar 29, 2016 9:32 pm
Posts: 106
MammaGutt wrote:

Vvol are generally a good idea, but for siloed organisations it may cause the same conflicts as with hyper-converged... Server/virtualisation teams doesn’t always understand storage and with Vvol everything is controlled from vCenter and storage teams will have limited access/visability.

Also I still think there are some storage feature available on 3pars (and other systems) which are still not available with Vvol because the storage systems doesn’t control the volumes.


Well this particular storage admin is now also a VMware admin (taking over from the inside) :-)

I'd been keen to know of any pitfalls of VVols, going to be trailing them in a test bed once I get back to NZ and get the firewalls/routing between the 3PAR and vCenter sorted out.
I do know that 3.2.2 code exposes less 3PAR features for use by vCenter (just basic creation and snapshots I think), but 3.3.1 also gives control of replication. In time it should just get better as HPE and VMware sort the code out.


Top
 Profile  
Reply with quote  
 Post subject: Re: 3PAR VV for datastores Vmware
PostPosted: Tue Feb 05, 2019 6:15 am 

Joined: Wed Nov 09, 2011 12:01 pm
Posts: 337
The main limit to VVols with the latest 3PAR/VMware code is no Peer Persistence support I believe, last update seemed to improve the scaling to larger setups.

Did poke our HPE reps last week about this and they are off to speak with the developers soon so might get some feedback. :)


Top
 Profile  
Reply with quote  
 Post subject: Re: 3PAR VV for datastores Vmware
PostPosted: Tue Feb 12, 2019 11:05 pm 
Site Admin
User avatar

Joined: Tue Aug 18, 2009 10:35 pm
Posts: 1224
Location: Dallas, Texas
I think somewhere above you may have also asked about Thick provisioning on Thin provisioning... just not in those exact words.

I am a fan of of the VMDK files being Thick Eager Zero, and the 3PAR VVs being Thin Provisioned. Its helps the ESX admins keep from overloading a single datastore with too many guests, and also takes the headaches of thin provisioning off their plate completely (and off their processors). The eager zeros help the 3PAR reclaim any space that may have been missed by T10/Unmap.

Also ESX 6.5 and VMFS6 support the automatic unmap of deleted data. ESX 6.5 and VMFS5 do not. Remember to check your datastore VMFS versions.

_________________
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ]  Go to page 1, 2  Next


Who is online

Users browsing this forum: Google [Bot] and 35 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group | DVGFX2 by: Matt