HPE Apollo Systems Reviews

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.

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.

Apollo's most valuable features for us are its density and storage capabilities.

We're trying to keep all log files in our Hadoop server, which amounts to several terabytes a day of locked data that we need to analyze. Apollo allows us to use as few nodes as possible for this so that we have as much direct space capacity as possible. It gives us much more space per gigabyte.

It's a very good system when you need a lot of disk capacity. But it's unclear whether the performance of the IO will be sufficient when calculating the theoretical amount of time to read all the disc space. If the workload is not purely sequential, then performance in the IO is less than optimal because it's optimized for streaming processing.

We have no issues with deployment.

We installed it in place about a week ago, and it's been running without problems.

We have probably some 6,000 or 7,000 physical cells already and are planning more.

We have technical account managers who work with us. It's pretty much a direct line to HP without having to dial the general support number.

We previously used the DL380s. Compared to those, Apollo has roughly four times the amount of space per server, which means we can really do a lot. We technically could have four DL380s, but the licensing cost would have been significantly more.

The initial setup was straightforward, and we've been happy about it.

For us, the most valuable features are the price and density. We have very limited space and we're able to fit four servers into our data center's rack space. Although I think a lot of the servers from different vendors are going to be very similar because they all use Intel chips, making them essentially the same, it's the HP management software that makes it better than the competition.

The biggest benefit for us is a physical benefit in that we can save our very limited space. Again, it's a dense product, meaning we can fit several servers into our rack space.

The licensing could be greatly improved, I think. We have a very hard time tracking it because we have to get a license for every server and machine. We have to click in our email, then go to the site, then login to HP, then download the license, then we have to do it all again for each server and machine, and we have to know which server or machine the license is for and give the license to the installer. It's inefficient, overly complicated, and should be simpler and pain free.

We haven't had any issues with deploying it.

It's been stable so far, but we've only had it a few weeks.

We have six racks and we can fit another. At the moment, we have sixteen Apollo servers and we're going to put 40 in as we have the space for that.

We've signed up with a third-party management service. They've been really good so far.

The initial setup was simple for us. HP came in, they racked and stacked it, and the software guys came in. This took a day or two and they were all done with the image. The whole process including hardware and software stack took about two weeks.

It gives us the density of a blade without the issue of shared IO, and a good price point for object storage.

It's allowed us to compete with cloud storage providers like AWS to put together a scalable on-premises solution of more than 20PB at a similar pricepoint.

Direct integration with software (Cleversafe, Scality, Ceph) for a purpose-built object store appliance. Stay closer to the current rev of processors. I know it is a heating/cooling issue, but being a couple of revs back is problematic when comparing consolidation of workloads with standard intenl servers running the latest chips.

We have implemented this for a few client over the past three years.

Big stability issues with the CPU on the first generation which made them virtually unusable. HP has done a better job of regression testing against software (hypervisors and big data platforms specifically) in the recent generations.

It's got better in the past year and in line with other major manufacturers (Cisco, EMC).

Standard Proliant servers (DL380s) with internal storage. We also looked at SAN and NAS solutions, as well as VSAN technologies from VMware, HP, and Citrix. None could hit the pricepoint to compete with AWS S3.

Standard server technology. Some initial issues with flashing FW, but the rest was straightforward.

We were the vendor.

Great solution for object stores. Consolidation ratio on compute doesn’t make it a great alternative for virtualization hosts, but could be a decent hyperconverged platform. HP is utilizing SL technology for their CS-250 Hyperconverged appliance.

The most valuable feature is the amount of programming storage available.

The predictive analysis feature could be improved. We would like the solution to be able to implement automatically in the next release. 

We have been using the solution for about two months. We are currently using version eight, and it is based on-premises.

This product is scalable. A large team is currently using it.

The customer service and support are available 24/7.

This is the only solution we have used. It was implemented from the beginning.

The initial setup was straightforward. The solution is well documented in a data sheet.

The deployment was done through a third party.

I cannot comment on the licensing costs as a different department handles it.

I rate this solution a ten out of ten. Unfortunately, I have been working with it for only two months, so I cannot give advice to others. However, the solution is good and can be improved by including automatic implementation in the next update.