Thoughts on VMware Virtual SAN

[KapsZ28]

I know it is still in BETA, but has anyone tested it or have any opinions on it? Our CTO seems to think it is a good idea. We are mostly a cloud computing company offering customers private clouds. Currently we use NetApp SANs but he wants to switch to vSAN in the future. We haven't even tested it ourselves and according to our VMware rep, she doesn't see any plans for it in VSPP.

So what are your thoughts?

 

[Thuleman]

It's tough to say whether it makes any business sense for you without knowing everything there is to know about your deployment and the plans you have for the future. IMHO there is a fairly significant movement back to local storage (local to the server) as storage continues to be one of the biggest bottlenecks in virtualization.

People buy these SAN arrays for thousands, or hundreds of thousands, of dollars just to find out that the arrays are oversized and underperforming. Storage simply doesn't scale well. You can have one server and you can run a lot more "standard" workloads on the server by just doubling the memory that's in it. That doesn't work for storage, you can't just pull drives out and double capacity to accept more VMs per array.

Storage needs to be distributed and not centralized, but it still needs to be shared. You need more controllers, more NICs, and more spindles. Monolithic SAN storage does not solve this problem and I am continuing to be surprised that "enterprise" storage vendors turn out arrays which are in theory capable of a million IOPS but in reality fall short once you put 70 VMs on it. IMHO inexpensive distributed storage is the future of virtualization, and the easiest way to achieve that is to use local storage as opposed to hugely expensive SANs with expensive annual maintenance contracts and expensive software licenses to run the arrays.

I think that vSAN is a huge improvement over VSA. I am not convinced that vSAN is the best bang for your buck if you decide to go the software route. If it were my money I'd buy DataCore (http://www.datacore.com) instead, which is probably a bit more pricey than vSAN but does oh-so-much more and does it much better.

 

[peanuthead]

Grabbing the popcorn for this thread. Subscribing. This is a good topic but I will wait a bit before chiming in.

 

[lopoetve]

The biggest thing to know about vSAN is, it's not about ~storage~. It's an object based, policy driven storage system, but the whole point isn't the "storage" as much as it is the policy. Have the platform adapt to the needs of the application, on demand, without downtime, instead of adapting the app or moving things around manually. It's just step 1 in software defined storage. There are many more coming.

 

[Vader]

The biggest thing to know about vSAN is, it's not about ~storage~. It's an object based, policy driven storage system, but the whole point isn't the "storage" as much as it is the policy. Have the platform adapt to the needs of the application, on demand, without downtime, instead of adapting the app or moving things around manually. It's just step 1 in software defined storage.

I am SO glad you made this point!! I have yet to hear "policy driven storage" that much on the INTERWEBS regarding VSAN, and this is really the key. I mean that's what VMware is moving towards, Policy based MGMT of your infrastructure and applications. Much easier for automation..etc.

 

[somebrains]

Yeah, are you sure I don't work with you?
Did you and I have this conversation with higher ups about storage not being just "space".
Did you have to explain to your management that just because the vendor promised "x" IOPS that in reality once we tier out a couple Sitecore and Hadoop process our $98k medium SANs are done.
Did we get yelled at b/c $2600 Cisco eth cards were stripped off the PO and all of the sudden it's not their fault?

Did they look at you like you'd grown a new head when you explained that disks on hosts were an upcoming viable solution, and to stop listening to vendors wanting to upsize what is essentially a 1 tier in performance DAS (DELL).

Do you get the feeling that your higher ups haven't touched a keyboard in a long time.....and their vision of service is still 90's core linux/BSD/SVR4 web/email/bandwidth

Do I sound like I need a new job.....or hire some poor bastard to be a storage SME just so they can try to explain storage in meetings.

It's tough to say whether it makes any business sense for you without knowing everything there is to know about your deployment and the plans you have for the future. IMHO there is a fairly significant movement back to local storage (local to the server) as storage continues to be one of the biggest bottlenecks in virtualization.

People buy these SAN arrays for thousands, or hundreds of thousands, of dollars just to find out that the arrays are oversized and underperforming. Storage simply doesn't scale well. You can have one server and you can run a lot more "standard" workloads on the server by just doubling the memory that's in it. That doesn't work for storage, you can't just pull drives out and double capacity to accept more VMs per array.

Storage needs to be distributed and not centralized, but it still needs to be shared. You need more controllers, more NICs, and more spindles. Monolithic SAN storage does not solve this problem and I am continuing to be surprised that "enterprise" storage vendors turn out arrays which are in theory capable of a million IOPS but in reality fall short once you put 70 VMs on it. IMHO inexpensive distributed storage is the future of virtualization, and the easiest way to achieve that is to use local storage as opposed to hugely expensive SANs with expensive annual maintenance contracts and expensive software licenses to run the arrays.

I think that vSAN is a huge improvement over VSA. I am not convinced that vSAN is the best bang for your buck if you decide to go the software route. If it were my money I'd buy DataCore (http://www.datacore.com) instead, which is probably a bit more pricey than vSAN but does oh-so-much more and does it much better.

 

[somebrains]

OMG, "policy driven" is like this new nail vendors are hammering sine July '13 whenever you start down another storage PO.

Problem is that in all of their screencast demos, they are so trying to sell you the solution that fits into your profile, not what you need.

SSDD

I am SO glad you made this point!! I have yet to hear "policy driven storage" that much on the INTERWEBS regarding VSAN, and this is really the key. I mean that's what VMware is moving towards, Policy based MGMT of your infrastructure and applications. Much easier for automation..etc.

 

[somebrains]

Lolz, anyone else have a chat about storage complexity requiring a PO for converged network adapters b/c they bought 1u hosts against the advice of IT

 

[Thuleman]

Yeah, are you sure I don't work with you?

LOL
After what you wrote I am positive that we don't work at the same place.

I couldn't be happier with my Director and I do get all the support I need to get things done. I feel that a lot of times IT doesn't get the support they need from the C-level folks because IT can't adequately explain it (whatever it is) in such a way that the C-levels get it.

Back on topic though, if I were VMware I would just buy DataCore (the company) and be done with it. If you want software defined storage then you will be hard pressed to find a better product that is fully functional and well tested/deployed today. It's really tough to not be in awe with their product.

 

[lopoetve]

OMG, "policy driven" is like this new nail vendors are hammering sine July '13 whenever you start down another storage PO.

Problem is that in all of their screencast demos, they are so trying to sell you the solution that fits into your profile, not what you need.

SSDD

Well, if they're talking about VVOL, they're actually talking about the same thing. That's just the enterprise array backed platform.

 

[lopoetve]

LOL
After what you wrote I am positive that we don't work at the same place.

I couldn't be happier with my Director and I do get all the support I need to get things done. I feel that a lot of times IT doesn't get the support they need from the C-level folks because IT can't adequately explain it (whatever it is) in such a way that the C-levels get it.

Back on topic though, if I were VMware I would just buy DataCore (the company) and be done with it. If you want software defined storage then you will be hard pressed to find a better product that is fully functional and well tested/deployed today. It's really tough to not be in awe with their product.

I love DataCore. I have 6 licenses. Spectacular product.

DataCore is a VSA. A VSA has nothing to do with software defined storage. VSAN is not a VSA. VVOL will be able to run on VSAs; the two don't compete as one is a concept and the other is an array platform. VSAN doesn't have a storage ~protocol~ - datacore runs FC or iSCSI.

VSAN/VVOL are a method of describing capabilities and requirements to a storage platform - either local disks or enterprise arrays with advanced hardware - and then having those platforms feed that data back to the hosts with additional information on their own capabilities and capacities.

VSAN tells hosts, as a group, to cache, replicate, and store data in specific ways for an object (VM disk, snapshot, etc). VVOL will do similar things, and expose precise details on tier capacities and capabilities back to the host through micro luns/shares so that we can effectively merge the storage for a VM with the virtual machine itself. No more storage vmotioning between tiers - just tell it you need more performance.



Right now, CPU/memory? Properties of a VM. Network segments/firewalls/logical routers/etc? With NSX, properties of a VM. That's what the SDDC is - it's all virtual machines.

Storage? It's blocks on a device we can't really talk to. VSAN and VVOL fix that.

 

[Vader]

OMG, "policy driven" is like this new nail vendors are hammering sine July '13 whenever you start down another storage PO.

I was referring to VSAN only. Most people talk about peformance, how it works etc, but they are not getting what lopoetve is saying. They are more concerned about looking at the product like a SAN and I get that, but the real power, and mojo is in the policies. Application specific performance by policy on a per VM basis. That's the power of VSAN.

 

[lopoetve]

I was referring to VSAN only. Most people talk about peformance, how it works etc, but they are not getting what lopoetve is saying. They are more concerned about looking at the product like a SAN and I get that, but the real power, and mojo is in the policies. Application specific performance by policy on a per VM basis. That's the power of VSAN.

Per Object - Disk/Snapshot/config space/Swap. Far more granular than just per-VM, and also reliability/redundancy (not just performance)

Oh, and change policy on the fly and the platform adapts to the new requirements.

There's the mojo.

 

[Vader]

Well..yes..but those are all objects associated with Virtual Machines, Applications..right? It's not like Simplivity where I can present storage externally to physical machines.

Exciting times ahead...honestly I think some of the storage vendors out there are up for some stiff competition. Some get it like EMC with ScaleIO and now they are talking about actually providing a Server SAN Appliance based on ScaleIO..hope to find out more at PEX.

 

[goodcooper]

how long until the hard disk manufacturers come out with hard disk drives with gig ethernet ports and all we need as a backplane is legacy gig switches w/ beefy uplinks and the software to make it all work?

 

[Jerky_san]

We've been looking at a purestorage box.. its 5k a tera 175k for a full system.. But damn its fast..

 

[lopoetve]

Well..yes..but those are all objects associated with Virtual Machines, Applications..right? It's not like Simplivity where I can present storage externally to physical machines.

Exciting times ahead...honestly I think some of the storage vendors out there are up for some stiff competition. Some get it like EMC with ScaleIO and now they are talking about actually providing a Server SAN Appliance based on ScaleIO..hope to find out more at PEX.

That's where VVOLs come in - expose all of that from the enterprise storage layer, using a very similar setup to vSAN.

 

[Thuleman]

DataCore is a VSA. A VSA has nothing to do with software defined storage. VSAN is not a VSA.

I really wonder whether some of this is just semantics What something is by definition is in operational terms secondary (if that) to its function.

"VMware's Virtual SAN clusters direct-attached server disks to create radically simple shared storage designed for virtual machines."

Given that the above quote is straight from the vSAN web site it's imho tough to argue that for practical purposes vSAN isn't a VSA.

 

[Vader]

VSAN is not a VSA because the functionality is built into the Hypervisor....it doesn't require a Virtual Appliance.

 

[Thuleman]

VSAN is not a VSA because the functionality is built into the Hypervisor....it doesn't require a Virtual Appliance.

I think that we can all agree that you don't need a virtual appliance to run vSAN. Where the disagreement comes in is in answering the "so what?" question. Just because you don't need to spin up a virtual appliance doesn't mean that the functionality provided by vSAN is fundamentally different from a 3rd party appliance of equal (or better) feature set.

 

[lopoetve]

I really wonder whether some of this is just semantics What something is by definition is in operational terms secondary (if that) to its function.

"VMware's Virtual SAN clusters direct-attached server disks to create radically simple shared storage designed for virtual machines."

Given that the above quote is straight from the vSAN web site it's imho tough to argue that for practical purposes vSAN isn't a VSA.

VSA = Virtual Machine that provides storage of some kind (block/file/object) to the host as if it was external to said host(s). Virtual Storage Appliance, hence a VM, with a separate management plane that presents storage of some kind to the host for use by guests.

VSAN = Kernel integrated and native VM storage that utilizes local magnetic disks and SSDs for storing virtual machine data. Management is done at the VM layer

VVOL = Kernel integrated and native VM storage utilizing enterprise arrays and native transmission protocols (FC / iSCSI / NFS) to store VM data. Management is done once at the array layer to configure for VVOL, then done at the VM layer to consume from then on.

It is not a VSA. There is no virtual machine, there is no separate management plane, and there is no "storage" presented to the host for use (it just exists).

 

[lopoetve]

I think that we can all agree that you don't need a virtual appliance to run vSAN. Where the disagreement comes in is in answering the "so what?" question. Just because you don't need to spin up a virtual appliance doesn't mean that the functionality provided by vSAN is fundamentally different from a 3rd party appliance of equal (or better) feature set.

Other than "they both happen to write data (at some point) to a magnetic storage device for later retrieval", I'm not sure how you see them as having anything in common?

All VSAs present block or file storage right now. That means you have luns/shares to manage, and to change how those work, you're either rearranging hardware raid groups underneath (ick), network raid of some kind (limited benefit - can't get more performance that way easily), or storage vmotioning to new "devices" that are based on other disks/nodes to improve performance. It's how we've been doing things for decades, just as a VM on something else.

I don't have to do any of that with VSAN - I just tell it I need more stripes, more cache, or more reliability, and it takes care of it behind the scenes, silently. I don't have luns to manage or shares to manage, it's just "consumed" by each object based on the policy set. Eventually, that same system will span to everything (including VSAs) where we can utilize the things they can do in conjunction with that same management system.

Don't get me wrong - VSAs are great and have their places right now (I can't present anything from VSAN outside of the cluster it lives in, by design, nor can I do clustering/etc because of how it works, and they rock for heterogeneous clusters and older gear), and there are definitely times they're more applicable than VSAN, but they're not really related other than "VMs can live on them".

 

[Vader]

I think that we can all agree that you don't need a virtual appliance to run vSAN. Where the disagreement comes in is in answering the "so what?" question. Just because you don't need to spin up a virtual appliance doesn't mean that the functionality provided by vSAN is fundamentally different from a 3rd party appliance of equal (or better) feature set.

Hence my original response to somebrains in this post...again..looking at this like any other storage product...

 

[NetJunkie]

Well, lopoetve, pretty much said it. VSAN isn't about storage. It's about true policy driven software-defined storage. It's our first REAL implementation of those ideas since we haven't gotten to VVOLs yet. The ability to define policies for storage on a per-VM basis is fantastic and the future.

In my opinion, these node-based storage architectures are the future. Whether it's Nutanix, VSAN, or ScaleIO it's going to become very popular. It's simpler, scales better, and offers many enhancements over traditional storage arrays. We'll still be selling SANs in 5 years..but I bet we sell less of them.

Someone above mentioned how traditional arrays don't scale and really don't perform as promised. Let me talk about that for a second. I don't mean to offend anyone...but if an array is properly architected and the pre-work is done you won't have that problem unless the requirements change SIGNIFICANTLY later. We're known for the large amount of pre-sales work we do for customers on sizing, information gathering, scoping, and designing arrays. We frankly don't hit those problems. But anyway....

We are working on building an 8-node VSAN cluster right now. I'm just waiting on the Kingston SSDs and controllers to show up. We'll also be using it for ScaleIO demo and testing..though I don't think ScaleIO is really a viable product for the commercial market right now. It was built for service providers with 50 or 100 nodes in a cluster..not 8 or 16. No tiering and configuration is done via CLI. Give it 12 to 18 months and that will be a different discussion.

Storage is undergoing a major upheaval. Flash started it by making storage performance a non-issue (with the right $$$) and greatly simplifying management (go configure and manage an XtremIO, for example. Easy). It's now pushing closer to the applications thanks to things like PernixData FVP and vFRC. Flash has also allowed us to drive down storage cost with hybrid arrays such as Tintri and Nimble..and now we're seeing VERY robust node-based storage from Nutanix, Simplivity, and VSAN. It's very exciting.

Before long we'll be having very similar conversations around networking with NSX and Cisco ACI.

 

[lopoetve]

Pffft. NSX >*

I suspect things like VVOL and VVOL+ViPR will open up all sorts of new possibilities for enterprise arrays as well - especially if we can get integration between policies, SRM (or a later derivative), and other replication bits.

Imagine a policy that auto-configures a VM for array-based replication, adds it to SRM based on VIN monitoring of the application communication patterns, sets priorities for failover for you from that same info, and is auto-scalable from AppD and VCAC.

That's the future, baby. That's the future.

 

[NetJunkie]

Exactly. Everything will be driven by policy..not static configuration. Let's push this stuff along lopo. I'm ready today!

As for NSX... The biggest holdup on adoption is VMware itself. Cisco is pushing us hard on ACI. VMware chose 5 partners without any discussion to begin the "NSX Elite" program. In the end software will win...but VMware could do it a lot faster if they'd open up to the channel. It's giving a bad impression of NSX. People wonder if it's just not ready yet or so complex they don't trust others.

 

[Thuleman]

Guys, I really do understand the technical difference between a virtual storage appliance and vSAN. All I was saying is that depending on the environment there may be no real practical difference. For example, if you only have three servers and a few dozen VMs it doesn't matter at all that you have to spin up a VSA and configure LUNs and whatnot. That's what I tried to get across in my very first reply where I said that it depends on the environment. The technical differences shine as you scale up but in small environments the additional overhead of dealing with VSA settings/configuration is negligible especially if a modern VSA provides benefits that vSAN simply cannot provide today (i.e. use existing SAN storage). I am not disagreeing that they are technically different. I am simply saying that this technical difference may not matter in practical terms.

Someone above mentioned how traditional arrays don't scale and really don't perform as promised. Let me talk about that for a second. I don't mean to offend anyone...but if an array is properly architected and the pre-work is done you won't have that problem unless the requirements change SIGNIFICANTLY later.

This is kind of getting off topic, but since I made that original comment I feel compelled to reply.

You have probably seen quite a large number of environments where that pre-work wasn't done, either at all, or just eyeballed. The customers often have no way to know that, all they know is that their storage is slow, and then the VAR comes in and sells another array to spread the workload out more.

In all fairness, figuring out storage isn't simple and there are a lot of variables, so I see how it's easier for some companies to simply sell a SAN, and then sell another one, and another one to the same customer to deal with performance issues.

Just as it takes VARs time to figure out what storage is appropriate, it takes the client even longer if they decide to look into it since the client lacks the expertise VARs have (or ought to have).

Storage, dual controllers, what storage controller processors, how much RAM cache, are the controllers active/active or active/passive, or does that matter at all, is it better to put all drives into one array (more spindles per array) or separate them out so that there is a physical separation between raid groups, does the array even support splitting the 16-24 drives into say 2-3 groups of 8, should it be raid 5 or 6, or 10, or 50, or 60, or something else, formatted with what block size, read ahead appropriate or not, SATA, NL-SAS, SAS drives, what RPM, how much cache on drives, does switching configuration introduce latency, which multipathing option method to use in vSphere (MRU, Round Robin, etc.), it's no wonder larger organizations employ storage professionals, it's a full time job to just consider the options.

The result though is that SAN arrays end up underperforming because it was sold under the

premise with little or no consideration for all other variables involved.

 

[NetJunkie]

Guys, I really do understand the technical difference between a virtual storage appliance and vSAN. All I was saying is that depending on the environment there may be no real practical difference.

Sure. For low end it might not matter. They just want cheap storage. But that's not really the target for these VSAN type deployments. You can use it for that...but you don't really get more than what a VSA can provide.

You have probably seen quite a large number of environments where that pre-work wasn't done, either at all, or just eyeballed. The customers often have no way to know that, all they know is that their storage is slow, and then the VAR comes in and sells another array to spread the workload out more.

In all fairness, figuring out storage isn't simple and there are a lot of variables, so I see how it's easier for some companies to simply sell a SAN, and then sell another one, and another one to the same customer to deal with performance issues.

Just as it takes VARs time to figure out what storage is appropriate, it takes the client even longer if they decide to look into it since the client lacks the expertise VARs have (or ought to have).

There is no secret to why my company is so successful and why we beat our 2013 revenue target by 40%. We do the work. We size appropriately. We don't just throw things at a customer and if we miss tell them to buy another. VARs that do these things give us ALL a bad name and will soon (due to IT Transformation shift) be out of business or fighting for very low margin commodity gear deals.

There is probably only one array that I sell that I'd ever tell a customer is good for a specific level of IOPS..and that's XtremIO. EMC publishes their worst case, 90% full, real world stats and tells you that you'll still get 250K IOPS and <1ms latency per XBrick. That's a given. Anything else isn't. And anyone that says this array is good for X number of IOPS is doing a great disservice to customers.

Properly sizing and designing a modern storage array really isn't complicated. It can just be time consuming. But that's why we have a dedicated pre-sales team focused on these things....and it seems to be working.

And in fact I'd say that something like VSAN is going to be harder to size and scope. You'll need to work with the customer and figure out how they are going to set policies for different VMs. Performance...resiliency...etc...those impact usable capacity and performance requirements.

 

[lopoetve]

Agreed with both of you. VSAN supports 3 nodes. Does it make a ton of sense there? Not imho. VSAs are still awesome and still have places in the market.

And NetJunkie, if only every single VAR was like you... good thing about VSAN - if ya don't like the policy, change it, and if you need more power, add another host.

 

[Thuleman]

And NetJunkie, if only every single VAR was like you...

Seriously!
I think that NetJunkie's posts have over time created no small amount of resentment readers hold for their current VARs as those don't do the things NetJunkie posts about.

 

[lopoetve]

As for NSX... The biggest holdup on adoption is VMware itself. Cisco is pushing us hard on ACI. VMware chose 5 partners without any discussion to begin the "NSX Elite" program. In the end software will win...but VMware could do it a lot faster if they'd open up to the channel. It's giving a bad impression of NSX. People wonder if it's just not ready yet or so complex they don't trust others.

Preaching to the choir, preaching to the choir.

 

[lopoetve]

Seriously!
I think that NetJunkie's posts have over time created no small amount of resentment readers hold for their current VARs as those don't do the things NetJunkie posts about.

If I ever leave the mothership, he's the one dude I'm calling for a job (if he'd even have me )

 

[Child of Wonder]

Seriously!
I think that NetJunkie's posts have over time created no small amount of resentment readers hold for their current VARs as those don't do the things NetJunkie posts about.

+1

Working for a VAR even I get envious reading how NJ's company does things. Too often pre-sales doesn't do their job, sells a customer Blah, then the project gets pitched over the fence to me, I show up and say "umm.... Blah can't do this. Why did we sell them Blah?"

 

[Thuleman]

If I ever leave the mothership, he's the one dude I'm calling for a job (if he'd even have me )

By the time you leave the mothership and cash in your stock options you won't need a job.

 

[lopoetve]

By the time you leave the mothership and cash in your stock options you won't need a job.

pffft. I came on post-IPO, I missed that joy-train.

 

[Vader]

Working for a VAR even I get envious reading how NJ's company does things. Too often pre-sales doesn't do their job, sells a customer Blah, then the project gets pitched over the fence to me, I show up and say "umm.... Blah can't do this. Why did we sell them Blah?"

Fortunately this doesn't happen too often where I work, however it does happen and the hardest part is explaining any discrepancies in design etc to the customer.

I'm fortunate to work for a VAR where the Sales folks are even semi-technical and I mean that loosely meaning that they know how to define the customer needs and that helps, especially in a smaller VAR like mine.

It seems, from your input Thuleman, that you've been face to face with incompetent VAR's..and unfortunately, there are always bad seeds in the bunch. I run into poor design all the time in our area, especially around storage.


We make sure that we right size and always always, keep the customer business requirements in mind. Having said that, sometimes we have customers that may be implementing a Greenfield deployment and are working with less than stellar software companies for their applications that do not understand the importance or need to obtain requirements..etc, that's the nature of this industry or anything for that matter, it happens. In those situations, sometimes we have to provide costly infrastructure to accommodate for unknowns..it's unfortunate..but this happens.

 

[peanuthead]

I agree 100% with NJ post about going the pre-work. This goes for any vertical or industry you are in. While I don't work with virtualization, storage, etc. like some here my company does do the pre-work and the results show. I'm apart of our pre-sales team from time to time on the technical stuff and I'll be the first to tell someone not to do it (or do it). The difficult part is dealing with something after it's been sold and a tech wasn't consulted.

Side note: The company I work for left a VAR because they didn't know their stuff and went to Varrow. Needless to say that was a great change up for us.

Sometimes the pre-work is nothing more that reading documents and tech specs. Point in case; I helped an AE yesterday just about close a sale after talking with the client for 45 minutes on the technical bits of our services and software. The client was all but ready to sign the quote. Felt great to know that the pre-work I had but in for my personal growth paid off. I personally study the virtualization and storage because it intrigues me and I just want to be better at what I do. While people like Vader, Ioptoeve, NJ, etc. talk over my head some times I'll at least try to research it and understand.

 

[KapsZ28]

Glad to see so much attention on this, however I think I may be more lost now.

Oh, it took me awhile to realize NJ = NetJunkie. I am from NJ, so that was confusing.

I think once we have our 10GbE network setup, it will either show us that our NetApp still has plenty of resources, or we may look into a different investment. I am fairly confident that 10GbE will be a big improvement being that everything is 1GbE using NFS datastores only going to a single IP address.

 

[peanuthead]

Glad to see so much attention on this, however I think I may be more lost now.

Oh, it took me awhile to realize NJ = NetJunkie. I am from NJ, so that was confusing.

I think once we have our 10GbE network setup, it will either show us that our NetApp still has plenty of resources, or we may look into a different investment. I am fairly confident that 10GbE will be a big improvement being that everything is 1GbE using NFS datastores only going to a single IP address.

I'm somewhat lost too. However this is the first time seeing the acronyms and definitions. Did I read the last sentence correctly that everything (VMs, etc.) is being served over a single 1GigE link?

 

[KapsZ28]

I'm somewhat lost too. However this is the first time seeing the acronyms and definitions. Did I read the last sentence correctly that everything (VMs, etc.) is being served over a single 1GigE link?

There are multiple 1GbE connections and storage, production, and management are all separate. But as far as storage, each ESXi host is only utilizing a 1GbE back to the NetApp. So as far as read/write and IOPS, we are a bit lacking due to that bottleneck.