SolidFire Reviews

We are a distributor and this is one of the products that we resell. I work with the entire NetApp portfolio.

It is used by our clients as a block storage solution.

The most valuable feature is the QoS and its ease of use. The dashboard is such that you don't need to be a storage expert to administer it.

The replication works well.

They now have a 100GB network interface, which is nice because I was disappointed with the original iSCSI protocol. That was all that it supported and I found it to be a limitation.

For people using FC SAN, SolidFire is not an option because of the interface.

The inclusion of more protocols and interfaces would make it easier to integrate with other products.

Adding NFS or another file service would be a good feature, on top of the block storage. There are, however, already other solutions for this in the NetApp portfolio.

I began working with SolidFire two years ago.

I have a SolidFire grid set up and I find that it is a stable solution. I did have to replace a disk on one occasion, which is something that the technical support contacted me about. While I have not used SolidFire in production, I have not heard complaints about stability from any of our customers.

There are some rules that have an impact on scalability. If the existing nodes have a small capacity then a much bigger node cannot simply be added. The reason for this is that there needs to be sufficient capacity to provide redundancy in case one of the nodes is lost. This means that during the design of the system, there are a few things that have to be considered. If the rules are respected then scalability is not a problem.

Each time I have been in contact with technical support, it has been proactive. They always call me before I realize that there is a problem. They will call or send an email, at which point they will explain whether there are updates that you should consider installing.

We are connected to NetApp using Active IQ, and the support contacted me to say that there was a disk that was not behaving as expected, according to their metrics and analytics.  They sent me a new disk and we changed it, which was a very easy process. 

In a previous experience, I had a SolidFire platform in the lab, and I remember that we changed a motherboard on one of the nodes. It was not a problem and it was done without disruption. The data on the system was still available from the other nodes.

Overall, I have no complaints about the NetApp support around SolidFire.

I have experience with Pure Storage and NetApp is the better option. The software is similar and the Pure Storage has better performance but with NetApp, it is easier to scale up and scale-out.

Most of the time when we sell SolidFire, it is integrated with NetApp HCI. Together, they make up part of a whole package that includes servers, compute, storage, and network. SolidFire can be fun in standalone mode but most of the time, if we have a need for flash storage then we will use the EF-Series. We also have the AFF storage with ONTAP as an option.

My advice to anybody who is implementing this solution is to make sure that it is properly designed. There are always things that you need to be aware of when designing an efficient system.

I would rate this solution an eight out of ten.

We are a solution provider and SolidFire is one of the products that we implement for our customers. It is used for virtualization.

The most valuable feature is the performance, as well as how you manage performance on the system.

The technical support is really bad and has to be improved.

We have been working with SolidFire since it was acquired by NetApp in 2016.

In terms of stability, I have not had any issues.

Scalability has not been a problem.

The technical support from NetApp is really bad.

We deal with and promote similar solutions from NetApp and Kaminario.

The initial setup is straightforward and quick.

Rating this solution is difficult because I would rate SolidFire very high and NetApp very low.

I have no trouble with features but we need the proper support. Whether I would recommend this solution depends on the requirements, although without knowing more, I would recommend something else.

Overall, I would rate this solution a five out of ten.

I work as a technical consultant and our company are resellers. We sell hyper-converged solutions to our customers. We use mainly NetApp HCI and SolidFire. We use a variety of versions depending on the customer's requirements. Our main use of the product is for ESX environments and Hyper-V environments. 

The most valuable feature of the product is its resiliency. 

The product does what it's meant to do and I don't think there's any need for improvement at the moment. The same applies to additional features, which would make the product quite expensive and I don't think it requires that. If you add features, you might lose the things that the product is best at. It makes the most sense to let it be what it is. If you buy the solution for its specific purpose it will work well. Once you add additional features like Essex, you diminish the system and that would be a shame. 

They could make the mNode more user-friendly. Now you need to configure and add nodes by CLI and it’s not really easy to manage. If they created a web interface to do the management of the mNode, that would be great!.

The product is stable and performs very well without any bugs. 

I believe the scalability of the product is very good. 

I've had a very good experience with technical support. 

The initial setup is very simple, anyone can do it. 

I can't comment on the price of the product because I only deal with it on a technical level. 

I would rate it a nine out of ten.

The most valuable feature of this solution is its scalability. That is the biggest benefit of using this solution. 

The entry-level for this solution is so high that we had to use other solutions for some of our smaller office locations that are in different parts of the world. As a consequence, because we could not use it across our entire organization, we have changed to something else. I would like to see the entry-level changed so that you can do really small systems with SolidFire.

This solution would be improved if it were made to be more compatible with other products.

This is a stable solution.

Scalability is the biggest benefit of using this solution.

The technical support for this solution can be good and bad. If you have a really big issue then it's bad because it takes quite a long time for the issue to be solved.

There are different levels of service. You can have a technician who is able to do the troubleshooting and is allowed to set up the commands.

If you just have questions with no due date, or you just have to fix a small package, the support is good. You always get the answers you need. However, in critical situations, we have had problems. For example, in the last three years, we spend three or four hours on the phone with support where nobody could escalate our tickets. 

We have had to stop using this solution because the price was too high for global implementation. We are now using NetApp MetroCluster. We were happy with the functionality and switched only because of the price.

The initial setup of this solution is straightforward.

I would say that you can deploy this solution in an hour if you know how to do it.

The price of this solution is more expensive than others.

The suitability of this solution depends on the use case, so anybody who is researching this solution should take care to consider their use cases first.

I cannot think of any additional features this solution needs, but there is a long list of improvements.

I would rate this solution a seven out of ten.

With this solution, you can actually do more with less. You can have more tenants and more application with less space and less dollar per gigabyte. By increasing the utilization up to four or five times someone can get more with less.

In Asia, a lot of people are still using the Fibre Channel and Fibre Channel is actually the best part of NetApp SolidFire. By providing the journey, we enable the customer to actually experience the new technology but without the need to make a lasting investment. We have to transition to the next generation because whatever SolidFire is offering it's not common hyperconverged work. It is actually for the centrifugal outlook but, it is not about the Fibre Channel. It's no longer required, The transition to next-generation infrastructure is where the Fibre Channel switch is required.

The quality of service for minimum iOS to maximum iOS in a multi-terminal environment is very powerful. The SQL service feature is the best part of SolidFire.

They took away the centrifugal outlook and it is not included anymore which is unfortunate. Additionally, I think there is room for improvement needed with its storage capability. A bigger node is needed.

The quality of service is unique. There's no one who does it like NetApp. Additionally, we can allow customers to do more with less while using this solution.

Primarily this is used as the backend iscsi SAN for our oracle 12c RAC implementation.... 2 x 2-node clusters, plus 3 add'l servers (dev/qa/stg).  We also use now for some limited-use VMs (vmware), and have implemented the VVOL configuration that SF makes available.  We debated using this for non-prod data for Oracle or not, but two things swayed our opinion.  1) We would not incur a huge disk-space penalty for having dev/qa/stg there as the de-dupe functions would come into play, and 2) we can guarantee IOPS so we know that regardless of what we do in dev/qa, it won't incur a perfornance penalty for production volumes.

The compression and de-dupe have been great in terms of space-savings, especially for our prod/stg/qa/dev DB instances (where you gain add'l savings for the de-duped data);  the QOS for IOPS helps us to ensure that no non-prod action can be deleterious to our production-stack data

• Expandability (incrementally and non-disruptive
• Compression/Deduplication/thin provisioning
• Recovery from failure/data-protection
• Guaranteed IOPS per volume
• Simple browser web-admin (with extensive out API interface)

The level of monitoring could be better. They give you access to stats and it is very informative. But you really need to do your own internal availability monitoring. Perhaps they just assume you are. And part of the thing, perhaps an adjustment on my part is needed, is that because something like a drive failure is handled internally and data-blocks are re-duplicated automatically, a failure somehow becomes less urgent. That is not second nature to me.

Having said that, 1) support reaches out if there is an issue, and 2) the on-line reporting is pretty good and only getting better. 

There were no issues with stability.  We've had 1 failed drive so far, and gone through 2 firmware upgrades - including reboots of invidual nodes, one at a time - and everything continues to "just work".  

There were no issues with scalability.  Far from it - see previous comments

Customer Service:

Customer service was good. I haven't needed much so far. We prefer to be our own source of knowledge and reach out to clarify or confirm something.

Technical Support:

Technical support is good and helpful. While you can schedule the node S/W upgrades and have them take care of, I had them walk me through it, as we were in pre-production at the time. Knowing/understanding more about the process gave me a better feeling.

I don't like black boxes, so anything I can understand or wrap my head around things provides comfort. The nodes are ubuntu and they leverage ubuntu/debian update mechanisms. These methods are well-known and understood, so no re-inventing the wheel was necessary here.

We have some older EMC boxes that were not sufficient to the task. We wanted an AF (all-flash array).

The setup was quite simple. Even though we had help, it would not have been required.  To date, we've added 2 add'l nodes with no outside assistance. 

We implemented in-house, although SF sent a technical staff members out to us. He allowed us to pick their brain and ask questions, which was very helpful.

I believe the initial buy-in/purchase is more expensive, because you are starting out with 4 (minimum) nodes. It then becomes cheaper and easier to expand and grow.

For example, compared to the more traditional dual-controllers+shelf, expanding to a new shelf was a pretty big investment and you needed to fully populate it with drives).

That uses the same controllers, so you have added capacity but not performance. Whereas, adding another node is a relatively simple operation. You don't even have to add all the drives right away. Licensing is via your support contract.

We did an extensive evaluation of several products and vendors, looking at SF, Kaminario, Nimble, Pure Storage, EMC, and HPE.

Price was a factor, but it was not the only factor. We are not a huge shop, but are growing, so we wanted something that had a solid architecture for now and for later.

We wanted it to be as bulletproof as possible, and yet be able to change/grow with us. The more standard, dual-controller-with-1-shelf can survive with a controller failure, or 1+ drive failures, but what about a shelf failure? While this is unlikely, it is still a possibility.

With SF, a few minutes after a drive failure, the data (blocks) that were located on that drive are re-duplicated elsewhere. In a very short time (a few minutes), you are fully-protected again. And as long as you have sufficient spare capacity - you can lose an entire node with no data-loss and reportedly only a small performance hit (even software upgrades are non-disruptive, as they are done 1 node at a time).

That entire node's data is re-duplicated elsewhere on the remaining nodes. If you don't have a node's worth of spare capacity, that becomes more problematic, of course.

What this also means is, as you add nodes, for increases in both capacity and performance, a.k.a. the scale-out model, you also get faster recovery times in case an entire node fails.

Adding nodes is a simple as:

1. Adding a node to the cluster
2. Adding the drives.

Data is re-balanced across the new nodes automatically. Removing/Decommissioning a node is just as easy:

1. Remove the drives from the cluster
2. Allow data to be re-located
3. Remove the node from the cluster

There is another unique option. Let's say I grow to 10 nodes, but the LOB application changes, and the role is no longer the same. I can break that into 2 x 5-node arrays and redeploy in different roles.

_______

update: since doing the initial review, we have added two additional nodes.  Very easy to do, the data re-balancing (distribution) is done automatically.

I'm not sure why SF isn't more popular in the SMB space. To my mind, it offers a unique combination that isn't easily matched in the marketplace. Kaminario seems to be the closest. I haven't had it long enough to truly "know" the product, but will happily revisit this in 6-12 months.

-----------------

Since the intial rollout, we have implemented VVOLs on SF with our VMware 6 setup.  Once setup - the initial configuration and communication, plus the SPBM policies - it is quite easy to use, and allows the vmware admin to do it all without having to touch the SF webadmin URL - even setting IOPS per volumes is done there.  Very nice. 

------------------

Lastly... scaling up, either for perf. or capacity (more likely), is so much of a non-issue that it is hard to over-state:

- predictable cost: you are adding a node, you know how much they cost.  No "threshold" where you have to add add'l controllers, or a new shelf, nothing like that

- no (minimal) impact to add to a running system.  They _say_ that when data is re-balanced (across the new node(s)), you have a percentage perf. hit, but we have not noticed this (and we've added 2 add'l nodes so far).  

- in fact, adding OR removing nodes requires no downtime, literally a 'non-event'

Just moving away from traditional spinning disc to solid state storage is a step forward, and user applications obviously are performing much faster. We have a much smaller footprint within our datacenter, so we've able to reduce overall operating expenses within our datacenter; shrinking costs for our business. It's been a fantastic improvement all round.

• The resiliency of the platform
• No down-time with the product itself
• Overall performance of the solution
• The dedupe

All of the feature set has been fantastic.

Really, everything our business needs, the solution currently has. Some of the other things that we are really looking forward to are some of the CloudConnect abilities. 

We only have one array today, so we want to add an additional arrays in a different datacenter so then we can actually do some of the Snapshot mirroring. That capability is already there, we just don't have an additional solution for it. Right now, for us, there is not much else that we really need. 

I do like their automation, some of the things that they've actually built in with their PowerShell. A lot of that stuff will help us automate our day to day operations. They've been on track with everything that we're looking for and it's just a great solution.

We've run it for a year and a half, we've done multiple code upgrades, there's been zero impact to the business when we do a code upgrade. During our testing we actually demoed unplugging an entire node from the solution just to see if there was any impact to the business, there was none. In a year and a half there has been zero down-time and it's been really a solid product.

Scaleout, the ability to just add additional nodes without needing storage vMotion, moving anything on the virtual side around, has been really great to see. We actually just recently went through and added an additional node, we did that seamlessly; no impact to the business, no impact to our users. Our application set just continued to run. All of the LUNS just expand once the new node is added, you really can't ask for anything better.

Honestly they have probably one of the best technical support staff we've worked with. One of the things that we did do during our PoC, is we actually made support calls at two in the afternoon, asked specific questions. We actually opened up support calls at 2am, just to see if we would actually get the same response which is exactly what we saw. It was good to see.

Simple, easy, adding an additional node is easy, just a couple of cables, there's no complexity at all with the solution.

We looked at Texas Memory, we looked at Violin Memory, we looked at XtremIO. All those solutions just didn't compare with what we could do with SolidFire in terms of performance, support, product stability. SolidFire definitely just blew the competition away.

I would definitely say have a look at SolidFire, just because of the scalability, the ability to add additional nodes, the resiliency of the product. There are definitely other solutions that may come in and say they can do everything that SolidFire does, but in our testing we were unable to find a solution that mirrored what SolidFire could do. I think it just makes a lot of sense to just continue down that path with Solid Fire.

The scalability and being able to implement it quickly.

Because we're a service provider, we have customers that need to grow and need their data increased quickly, so it helps us with that. We're also incorporating SolidFire into being our cloud-providing mechanism, so it allows customers to get in and out of our cloud, as well as move into the main cloud.

Because of the scalability and being able to add and decrease quickly, it allows us to service our customers at a quick rate, versus how they normally would have done it.

I would like to see more of the fiber channel connect, legacy-type, Linux-type front-ends to it. That would really help in our environment.

It's a very good Windows-type solution. But we do a lot of legacy systems and the like. So it's getting that incorporated into it that would help us.

So far we haven't had any problems with it. I think it's a very good product so far.

NetApp overall has been very good at helping us incorporate things quickly. The SolidFire was a quick, scalable solution. You can add nodes as quick as you need them. 

Where we were before that was bringing in and setting up whole arrays and then trying to get the pieces we need. The scalability with that is a lot tougher because you're not scaling the nodes, you're scaling strictly storage, unless you bring in another whole set of clustered environment, which takes time. 

We actually had a partner come in and set it all up for us and get us started with it. We didn't have to do it ourselves.

It was quick. It's not very complex. It went in very quickly. Basically added it to the network and it was ready to go.

We've got quite a few different vendors on our floor today. Just about any vendor, you name them, is on our floor. For the applications, and what we were trying to move towards, the SolidFire seemed to fit every niche we were looking at, for the part we brought it in for. It was a very good product.

I don't think we looked at much in the hybrid. SolidFire met all the criteria of what we were looking for, for that part of our infrastructure. 

We purchased SolidFire, in some aspects, for customer facing application. We have started to bring SolidFire into our house to use for our own applications, versus just using it for our customers.

The most important criteria when selecting a vendor to work with are, I would say, performance, ease of of using, how to incorporate it in to our datacenter. And that's one of the things with ONTAP - that it's able to be used on SolidFire -  we know ONTAP. It made it a lot easier than to have to bring in a different application, learn something new. So that also helped in our decision, it was the ease of bringing it in.

I didn't give it a 10 out of 10 because, like I said, the things that we need it for, that we're still missing - some of the Linux and the Unix-type connections - that would really help it. 

Given the ease, for the value of the product, it's a great thing to bring in and start going to the cloud with.

• Ease of use
• Performance guarantees that you can set
• Individual settings you can put on each individual volume, if you want to do that
• Ability to scale up, scale down whenever you want
• Scale-out ability, and the ease of adding a cluster - When you get a new node, if you farm out the datacenter tasks like we do, there is no technical ability required for them to plug it in and connect it and we can just add it.
• Open RESTful APIs are great

It's provided us the ability to not be concerned with setting SLOs for whatever application we're using. Everything is pretty much tier-one.

Our primary use case is virtualization, right now. We initially purchased it to be incorporated into our own internal cloud, OpenStack-based, KVM-based, so we use it for that. And, we've also branched into standard VMware as well. So we have both.

Based on those use cases we get really good efficiencies. We do a lot of encryption. We initially didn't have any because we were using it for anything, any LUNS, Oracle, whatever, and we didn't get the efficiency. So we positioned the use case over to virtualization and we're getting good efficiencies that way; to make it more cost effective. That's one of disadvantages, the actual cost. We haven't gotten there yet, but...

A little better segregation of the multi-tenancy. Right now, it's just VLAN-specific, that's all you can do. There's no authentication domain separations, things like that. For example, the NetApp product has storage virtual machines, which has a lot better segregation, and a lot better multi-tenancy, a lot better role-based access. That's probably the biggest thing that I would say, so we could actually use it for different tenants.

We've had some issues with hardware failures, and for them to resolve that it's actually meant replacing nodes. Otherwise, the stability is pretty good, all we've had is hardware failures. And they're built for a smaller scale, so before they were purchased by NetApp it was just, "replace the node, it's easier to replace." Any other field-replaceable unit, anything that breaks is, "replace the node," except the power supply or the disk.

We're impressed with its scalability.

For the most part, it's been pretty good. We've had to use it a lot for what I explained earlier, the hardware failures. This was mostly before it was integrated into NetApp support. We haven't really used them recently, so I don't know how the assimilation into NetApp support has taken effect.

We purchased SolidFire for customer facing applications, they're all internal, house-developed applications that we sell to customers, to financial services.

When selecting a vendor to work with what's important to me are

• support
• viability - are they going to be around?

Support is the big one. Is it just reactionary support, or proactive support? You need both of those.

I gave it a seven out of 10 based on what I've already explained. In the past, they seemed like more like a small company - and they were. But what I explained before, the hardware replacement, just replace a node. That's a small company.

Make sure that you have the performance requirement for it, because its price per gigabyte is a lot more than other solutions out there, if you don't need the performance requirements. You can get by on all-flash unless you have the need to guarantee performance on specific volumes.

For us it's the horizontal scalability. We traditionally run our private clouds for our R&D engineering on AFF, which worked quite well. But we ran into IOP-driven scalability. So instead of adding more clusters and more HA pairs with all-flash disks in an AFF scenario, we were able to just scale with SolidFire. That is so much better because we can add a node, we add compute, we add storage, and we've had really good luck with that.

Our use case is all private cloud right now, running OpenStack. All internal, for our internal R&D and engineering.

For us, moving into a private cloud area was a big step for R&D. So while we are just in our infancy right now, it has made a big difference in storage efficiency. Traditional workloads that we ran on AFF, we saw better deduplication ratios, and efficiency ratios on SolidFire than AFF for our workloads. It's a very IOP-driven environment, very IOP intensive, and the SolidFire handles that quite well using the QoS for IOP.

We're really in our infancy right now for what we use it for. We haven't really gotten into a lot of the advanced features and functionality of SolidFire because we get so many things out of the OpenStack overlay. For now it's doing what we wanted it to do.

Anything we've had, were covered by Hotfix. We had some false positives, power supplies failing, and that's really been about it. We had a couple of glitches during some upgrade processes but nothing that was really concerning to us.

Everything has been resolved.

It happens with any product. It wasn't anything that stood out for us, to be a red light.

It's been really good. We've had no issues, we've had non-disruptive upgrades, non-disruptive hotfixes, which is really great for the customer - the R&D customer. They don't like any disruption. Disruption is money to them. So we have been really satisfied.

Great. For us, budget wise, just being able to say we know this workload is coming down the pipes for new design, a new ASIC chip, anything like that. We can predict what the cost is going to be versus having to buy disk at another solution. It's great for us.

Any small, minor issues that we've had have been resolved by support really quickly and support has been extremely good with SolidFire.

We had initially purchased AFF for this solution and, while it met our needs, we thought that SolidFire might be a better fit based on how we wanted to configure OpenStack and what our workload was; and again, for the scalability in terms of IOPs and how we have to grow that for AFF versus SolidFire.

Purely the scalability, being able to add a node, add compute, add storage, and being able to restrict IOPs for specific applications and workflows is a really a huge benefit for us.

I was involved. We did a proof of concept, set it all up and then we ended up adding on to that. We turned our PoC into production and then we added more nodes, and more nodes. We've gone from a five-node initial proof of concept to, now, a 15-node cluster.

The initial setup was easy. Very simple. We were up and running in less than an hour I think, which was really easy; after it was racked and stacked, etc. Very, very easy to get going.

I can't really speak about SolidFire's impact on operational cost compared to other storage platforms because all our other storage platforms are NetApp. The scalability for us, it is a cost-savings, so if we hit a certain number of IOPs within an AFF system we have to add another pair of controllers and we have to add more disk. There are also bottlenecks for AFF, for how many SSD shelves you can run for those specific clusters, whereas with the SolidFire side we are just able to add nodes on and get what we need. They're both great solutions that fit the use case a lot better.

I'm not sure it's uniquely valuable to an enterprise-type company like us but I think it's unique in how it operates. That whole "add a node, add compute, add storage" has been done before but I think they really do it right with their all-flash technologies. Some of the other vendors don't do it with all-flash and run into bottlenecks for IOP and the like. I think SolidFire has really done a great job with that. They have done a really good job with storage efficiencies versus a lot of other vendors. A lot of the other vendors are add-ons for things like deduplication or compression/compaction. So I think SolidFire has done a great job with that.

It's all been NetApp products. There's been AFF FAS and then we just thought we would look at SolidFire because we've had such great luck with AFF and FAS for many, many years. We've been a long standing NetApp customer and it just looked like a good solution for us to try, do the proof of concept, and it worked out well for us.

We did not consider hybrid storage for this specific use case, but we do have hybrid storage from that NetApp in other parts of our infrastructure. We are also adding some other tiers of storage into this cloud solution, potentially storage grid and potentially some other FAS-type thing for protocol-based access.

The most important criterion when selecting a vendor to work with, for me personally, is partnership. I think it's also important that the vendor has vision. I think it's important that they are willing to collaborate with customers and not just throw solutions at them. I think they should really want to understand your workflows, how they can benefit you and how they can make your life easier in terms of automation or efficiencies or performance. I want to find that they actually really care about what you are doing, as opposed to just throwing a solution out there.

Do your due diligence. Do proofs of concept. Make sure that you try to break it with what you are trying to do, and make sure you engage the vendor. Tell them exactly and share exactly what you trying to do and let them help you build the correct solution. Especially with NetApp, they have such a huge portfolio. You might be thinking traditionally you have experience in AFF or FAS but SolidFire might be a good fit, or E-Series might be a good fit, or cloud ONTAP might be a good fit. So it's important to engage the vendor and find out what the best solution is for your use case.