HPE Apollo Systems Reviews

We actually install Scality on the Apollo servers and so we have a ring, a Scality ring, where we store our customers' documents. That allowed us to migrate away from traditional NAS with a cost effective solution whose architecture is both scalable for the future and able to handle the PB scale of document content that we deal with.

Just not having to manage traditional NAS has made a big difference. Not having to manage traditional volumes and aggregates and LUNs and things like that. Being able to be flexible when it comes to that, and Apollo has made that possible.

We're pretty happy with the Apollo line of servers. It would be interesting to see the new hyper-converged DL380s. It would be cool to see if that type of same thinking about hyper-convergence was applied to the Apollo line of servers as well. It would be interesting, not on the storage-dense model of Apollo servers but on the compute-dense models of Apollo servers, to see kind of a hyper-converged solution running in those chassis that can have multiple compute nodes all in one. So that would be interesting to see if HPE could do something like that. It would make a compelling argument for them in their hyper-converged space. It would really complement the DL380 hyper-converged solution that they're providing now and would be I think a good choice for lots of people who are looking at hyper-converged.

We deployed our first ring on Apollo servers towards the end of last year so it's been running for eight or 10 months or so and it has had zero downtime.

With the Apollo systems, we initially expected it to be of PB size. The great thing about the Apollo servers using Scality is that if we need to add more disks to those existing systems, that disk will instantly be usable to the ring. If we need to add more servers to have more compute power and more storage, we can do that as well.

We've only contacted them to help replace drives when drives go bad as they do, but nothing beyond that.

So for a long time, we were storing our documents on a traditional NAS, through NetApp, and that got to the point where NetApp couldn't handle PB scale affordably. We're talking about tens of millions of dollars in order to buy a NetApp that could do PB scale on the number of IOPS that we needed. And on top of that, it was cost prohibitive to be able to scale out on traditional NAS, so the Apollo line became the clear choice, I guess. And deciding that we had to go to something like an object storage, that decision was made long before we decided on Apollo. It turns out that Apollo fit our decision to go to object store.

The initial setup was pretty straightforward. The Apollo series that we use is basically the guts of a ProLiant DL380, which we've used many, many times in the past, but then allows us to put double the disk capacity of a traditional DL380 in that line of Apollo servers. And so setting it up was pretty easy because we've done Apollo servers in the past. The iLO functionality made it pretty straightforward and had no problems getting things deployed.

We spent a long time looking, actually, at doing the Scality ring on just commodity hardware from someone like Supermicro, and we found out that, in terms of reliability, supportability, ease of management, that having all our servers under the same contract through HPE, made the decision to use Apollo was apparently clear. Even though it was marginally a little bit more expensive up front, the total cost of ownership of having to manage those many servers was lower. This made the decision really easy.

If someone came with a similar storage need, the Apollo servers do make a lot of sense, especially when you're talking about scale out object storage-type implementations. That Apollo line, it makes perfect sense from my perspective and I would recommend that.

Our first batch of Apollo servers that we got were so new that it was just hard to know kind of what to expect from HPE and what they wanted to deliver to us. The first batch of servers that we got were missing an iLO and that may have been a confusion between what we ordered and we thought we ordered or what we thought we would've had. But anyways, that way it was resolved quickly and the iLo modules were shipped out and there was no problem there. But just because it was so new when we first got it that there was just some speed bumps when we first ordered them. Otherwise, they're a very solid server.

The cost benefit of this solution is most valuable. It is quite effective for the work for which we are using it. We are mainly running video servers on these, and we are quite happy with the resilience, density storage, and streaming capacity of the system.

We are quite happy with it, but its price and storage density can be better.

I have been using this solution for three to four years. We have two different generations. We have servers that were bought four years ago and two years ago.

It is stable.

It is easy to scale. We are on top of it. We have an application from a specific vendor. We, as well as the software vendor, are happy with it.

It was really straightforward. The process for installing and commissioning the services was easy.

We are using our own teams for installation. We are quite autonomous on it. We internally have the knowledge to do the job. We are happy with it.

Our infrastructure team is managing all the hardware, virtual machines, and operating systems. We have around 2,000 servers. We don't have a dedicated team for Apollo. We have a team that takes care of all the generations of servers, including Apollo.

I can recommend this solution. It is easy to maintain. If you have an infrastructure team, you won't have any problem with it.

I would rate HPE Apollo a nine out of ten.

We're using the Apollo 4200 as a data capture system. The most important things for us are the amount of storage on there, the ability to configure it, and change the configuration so we could do the network captures we need at very high data rates. It meets our network requirement of being able to capture up to 40-gig with a small form factor.

We are moving from existing 10-gig environments to a 40-gig environment. The ability to capture those high data rates is really important to us. We need to know what's going on in the network. We need to be able to explain to our customers any issues or problems, and where they might have occurred.

We're looking for faster capability to write to drives. We're fully loaded with all the small form factor drives loaded into the system. It is practically at the limit of the capability supported by the architecture. So we need new solutions, new types of drive capabilities, and faster bus speeds.

It is good in terms of stability. We are struggling a little bit with some of the configuration we need to do, particularly with write capability to drives. That's the only part where we struggle with getting the solution going; but we've had significant conversations with HPE, and worked through a load of issues. We are actually getting the solution that gets to our capabilities.

We tend to only use a single rack-mount server for what we're trying to do. The ability to keep it small, reduce the footprint and reduce costs are the most important things that the Apollo 4200 gives us.

Technical support has been very good. We've been given access to senior HP personnel in America. They've given us lots of guidance and help in actually configuring the system.

We were previously using the older DL 380's with MSA drives. We knew their limitations using the fiber channel in terms of the transfer rates we could get out of it, for example, but we needed something that would work with the move to a 40-gig network environment.

The initial setup was fairly straightforward. What we're trying to do with the solution added to the complexity; so we needed some guidance, mainly on how to configure the way the drives and everything were allocated to enable us to actually do the captures. From that initial build to where we are now, it's taken a little while to get there; but it is a fairly complex system.

We looked at four or five different vendors. Some of them were talked about very expensive solutions. The HPE solution cost about one-third less. Taking into consideration the cost, HPE gave us the ability to actually do what we wanted to do. Also, the relationship and being able to talk to them was important in our decision. Getting access to their technical people is very important to us. We've been an HP user for many years.

Not many companies will have a similar type of requirements as we do. But if you need a low cost solution with a low footprint, then the Apollo 4200 is an ideal system for that.

The HPE Apollo is used as a server for our system clusters.

HPE Apollo's most valuable feature is the ability to expand our storage capacity.

I have been using HPE Apollo for approximately one year.

HPE Apollo is stable.

The scalability of HPE Apollo is good.

We have approximately 10 clients using this solution.

The support from HPE Apollo could be better, they are making knowledgeable.

There is an annual license required to use HPE Apollo.

I would recommend the solution to others.

I rate HPE Apollo an eight out of ten.

We use three Apollo 2600 enclosures with a total of 12 servers as a Splunk cluster for all our log handling. 

In the beginning we used Splunk in a virtual environment and the performance was quite hard on that system. So when we moved to the Apollo and all flash drives, we gained a lot of performance on that.

It is quite simple when you get it going. I like the blade concept that makes is so much easier to handle the servers.

We unfortunately have tried to used standardization using Ubuntu Linux and it's been hard. They had some difficulties getting the RAID configuration up and running because there are no drivers for it. It's not supported by HPE.

Very much a stable solution. No downtime yet. I think it's a configuration issue on our end but we have burned through quite a lot of the NVM system drives. The system does some swapping somewhere, so that has caused some issues.

It will meet our needs, definitely, going forward.

They have been very responsive and knowledgeable. As I say, we have mostly had trouble with the drives, and we have received the help and the replacement parts that we need.

From my end, I like that we get everything from HPE. So it's quite easy to point at HPE if something breaks. We have the switches from HPE, we have the storage from HPE, the service from HPE. So it's quite easy to get their help when something breaks, because they are responsible for all the parts in our datacenter.

We primarily use it for high-performance computing. Our customers really do like it because of the density they can achieve in the racks. Apollo provides so much compute power and storage as well.

It's performing extremely well.

It enables us to implement software defined solutions very easily, because Apollo servers are certified for use with Linux systems, which is really a big thing for us.

High compute density and high storage density at a reasonable cost

Obviously I would like to see the cost go down. That speaks for itself. 

We would like to see improved cooling because that is quite an issue. If you put that much compute power into a single rack, cooling really becomes an issue. And there is room for improvement there.

Extremely reliable. We've been using it for three years now, and it's been in production without any downtime yet.

Especially if you use software defined storage, for instance, scalability is just great.

We have not use HPE support. We have our own engineers, so we're really proficient enough. And it's really easy to use. So it's not a big deal.

We actually had a business case. We were looking to address this business case with standard IT storage solutions but they were way too pricey for us. So we figured we needed a way to use a standard service, make the most of these standard services, and came across Apollo Systems. Apollo Systems provide stuff that standard services do not. More HTDs, more compute power, at very reasonable pricing.

It was straightforward.

We do look to Super Micro whenever price is king. But if we are looking for reliability, then HPE is the way to go.

Our most important criterion when selecting a vendor is reliability. We need a vendor to be there for us, even when the product is already three or four years old. That's a big thing for us.

I give it an eight out of 10. It does what we expect it to do. As I said, cooling is still an issue, you really have to keep that in mind if you implement the solution. But aside from that, we're really happy with it.

Talk to a partner who has implemented a solution with HPE Apollo, talk to customers who have actually used it in the field. It's really simple to do.

We're using it for big data and storage servers. So mostly Hadoop for big data, Hadoop elastic search, and Ceph storage for our OpenStack private cloud.

The Apollo is performing fairly well. We've run into minor issues, but overall it does the job and we feel it's a good product for the money. 

It's allowed us to benefit from IP-based storage instead of using only fiber channel SAN storage. Also, I don't think we could have afforded that quantity of storage in a SAN array.

It's pretty flexible. You can choose how much storage you put on the server. You can have one to three nodes, depending on whether you want more CPU or storage. And we can use the same platform for several use cases: Hadoop, Ceph, and we are considering the server for another use case right now. It's a single solution, we only have to integrate it once and we can use it for several technologies.

There should be truly independent nodes for your rack, which can contain three different servers. I like to make sure when a component fails, I don't have to take down all three nodes. This is especially true as we usually have replication between these nodes. It would be a great asset to be able to contain the downtime to one of the nodes.

It's pretty stable. We've only had very minor issues with it. No major downtime. 

The only issues we've really run into so far is that there is a shared battery for all cache controllers in the node. When you have to replace that element, you have to take down all three nodes and not just one. That's something of a design flaw, but it's the only real issue we've had so far.

Yes, we've called tech support. Mostly for hardware faults.

When selecting a vendor the most important criteria include

• overall trust in the company
• the financial side, of course, the price of the hardware 
• the quality of the support we can expect.

I rate it at eight out of 10. As I said, true independence between the nodes would be an improvement. At least make sure that the nodes aren't dependent on each other. Also, we've had a few difficulties integrating it at first, so I'll stay with an eight.

Test the solution and do a proof of concept until it works with your own integration procedures, the way you install systems, that kind of thing.

We are running Apollo with SL-series servers and the best thing about them is the density of the storage area available. Regarding TCO, total cost of ownership, per terabyte, they are now the best on the market.

Connectivity to the outside of the server needs to be improved at the same time the network is improving. This would give us more IO. Of course, this is a firmware lifecycle management issue; there is work to do. Vendors should test the firmware before they are delivered to customers.

Stability is good enough.

Scalability is fine because with this kind of service we can easily scale horizontally. We are more or less satisfied.

The technical support in Finland is fine.

We made a transformation from enterprise storage to an open-source distributed storage architecture. We switched because the pricing is better.

The initial setup was business as usual. It's not so complicated, but of course it takes time.

The price is not significantly lower than the competition, but it's lower than the standard price.

We looked at Dell and Super Micro. They are both on the market in Finland.

You should run the stable firmwares on a test platform for about a month before you roll them out. This is something we have to do that right now.