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.

We have been working with the Pittsburgh Supercomputing Center for around ten years. They are picking the hardware and they had picked this hybrid system. It has several different kinds of components in the system and we had worked with them for a long time. We knew that they were picking the stake of that stuff so that's why we selected this solution.

It's very hard for a professor to amass the supercomputing resources, so I've been very fortunate to have that level of supercomputing at our disposal and that has really enabled us to do the world's leading superhuman AI research. That is what we did, we actually beat the best heads up in all Texas, holding human players in the world this January. So, we're at a superhuman level in the strategic reasoning.

One thing that we are looking for is the better stability of the Lustre file system, it could be improved. I have heard that they are coming out with a better memory bandwidth, so that's good or maybe, it's already there in System 10.

In that case, of course, then there is need for more CPUs, more storage and all of that.

It has been fairly reliable. In the beginning, of course not, but then we were a “baiter customer”, so in the beginning, there was nothing, literally there was nothing in the racks. We've been with it from the beginning and of course, in the beginning, it was less stable. However, it became more stable over time.

If there's anything that hasn't been that stable, then it is the Lustre file system. I would say that they have made some improvements with that but this is not just a problem with bridges. We have computed the other supercomputing centers like San Diego Supercomputing Center in the past as well and Lustre seems to be just a little bit unstable overall.

It's going to meet our needs moving forward, it is scalable. Having said that, our algorithms are very compute-hungry and storage-hungry, so more is more and there's no limit as to how much our algorithms can use. The more compute and the more storage they have, the better they will perform.

I would support the Pittsburgh Supercomputing Center (PSC) support; they gave us the support and their support has been awesome. We don't directly contact HPE, they contact HPE if needed.

The PSC installed everything, i.e., both hardware and software. So we didn't do any of that; from our perspective, it has been easy to use.

Whilst looking for a vendor, we do not look at the brand name at all. Instead what we look for are just reliability and raw horsepower.

It has been great. The Pittsburgh Supercomputing Center guys have been great in supporting us very quickly and sometimes even at night or on weekends. I've been very fortunate as a professor to get this level of supercomputing, so we've been able to do the world's leading research in this area. The only things that I would improve are the ones that I have mentioned before, i.e., the Lustre file system, and maybe, the memory access from the CPU.

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.

The solution could improve the hardware, such as the motherboard or servers. We have had hardware faults in the past.

I have been using HPE Apollo for approximately 10 years.

The technical support from HPE has always been good in my experience.

I have used Dell solutions.

The price of the solution is more expensive than Dell which is their main competitor. However, there are times we have managed to receive a comparable price.

I rate HPE Apollo an eight out of ten.

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.

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 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 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.