This post is more than 5 years old
6 Posts
0
2796
VPLEX storage volumes best practice
Greets everyone!
Right now we're performing a fresh install of vplex + VNX solution. Vplex will service a vmware environment and a small bunch of Oracle hosts.
I've tried to find any notes about storage provisioning best practices for vplex and found almost nothing.
I observe 2 approaches how I can provision storage for a vplex:
1. Create a multiple LUN's (or meta LUN's) on VNX array (each LUN for certain purpose like VMFS datastore, RDM device, or file system). Then present it to vplex, create an extent then device and then a volume which is presented to the host.
OR
2. Create a large LUN's (like single LUN for entire storage pool) on VNX array and present these large LUN's to vplex. Then slice these storage volumes to extents of any size I need and create devices and volumes on top of it.
Approach #1 will force me t manage 2 layers of storage provisioning. This is complex (pretty much complex ). But it provides me more control over storage traffic and gives me ability to leverage VNX Storage QoS for certain LUN's. While Approach #2 make storage provisioning quite simple. But I'll be forced to use SIOC in vmware to handle performance issues (if they occur).
So I'd like to ask you which of these models of storage provisioning you're using now? And why you're using it
Thanks.
echolaughmk
522 Posts
1
March 20th, 2015 06:00
The term 1:1 relates to mapping it all the way through - 1 storage volume is 1 extent is 1 device is 1 virtual volume. Slicing up extents on the storage volumes would still give you the possible fragmentation of workloads, if the same storage volume is used to service virtual volumes for VMware and Oracle, let's say.
I don't see your second approach utilized much out there to be honest (others can chime in if they utilize it like that). Let's say you have a giant 5TB single LUN on the VNX presented to the VPLEX and you slice that 5TB LUN up for all your virtual volumes....on the back-end array with write-through caching, etc that is still only 1 single LUN in terms of parallelism servicing all of your workload. SIOC might be able to assist in controlling it on the VMware side, but I usually tend to err on the side of predictable performance when possible. I'm not sure if you are using a Local or Metro either, but the 1:1 mapping also future-proofs you for any array-based replication you might decide to use for HA/DR/BC as well as any storage-volume expansion. In the end it is really a decision on how you want to manage your environment's needs and performance.
adiakonov
6 Posts
0
March 20th, 2015 06:00
1:1 is for devices not for extents.
Assume that I don't have any data on VNX to migrate. Which means that i should not mess with app consistent extents.
I agree with you about performance and troubleshooting (as I stated in my original post), but in vmware environments you can use SIOC to resolve IO contention (in most cases).
So #2 approach seems to be working for fresh vmware installs.
echolaughmk
522 Posts
1
March 20th, 2015 06:00
Hi,
My 2 cents from doing VPLEX installs and design:
In general, I would say 99% of the people use the 1:1 mapping (approach #1 above) for several reasons. This is generally the recommended approach for ease of use, troubleshooting and monitoring, and due to the fact that any underlying replication of these volumes (RP/SRDF/Snapview/etc) will require a 1:1 mapping to be in effect (check out the array replication guide with vplex here). It also allows for better ease of use when performing any migration/expansion/data mobility jobs within the VPLEX or outside of it. Some of these operations require the 1:1 mapping. Performance-wise, the 1:1 mapping will also generally provide more predictable performance that can be monitored and troubleshot easier. If you have a giant single LUN with slices on it and those slices are being allocated to varying applications with different I/O profiles, they would all funnel to the same back-end LUN and monitoring what application is doing what from an element manager perspective could be more involved.
I would recommend the 1:1 approach given the workloads you described above.
HTH,
-Keith
adiakonov
6 Posts
0
March 20th, 2015 07:00
Thanks for detailed clarification.