HPE Apollo Reviews

We've only been using it for about a month so far. This is a system that's on loan to us from HPE. It's a Gen10 version with eight NVIDIA V100 GPUs and four nodes. We have already purchased the unit. This is on loan to us until we receive the Apollo 6500 that we ordered.

For storage we're using a Seagate SSD Array, all-flash array, as well as EL4000. The Apollo 6500 is for machine-learning, specifically for wafer generation, wafer analysis, for one of our operations sites in Minnesota.

I would want to see the flexibility of being able to run various network protocols including InfiniBand, Fibre Channel, as well as iSCSI, with iSCSI going up to 100 gigabytes per second -that would be outstanding. That in conjunction with what Mellanox offers would provide us with a very high-speed networking interface.

The other thing is we may could, perhaps, use more GPUs in the future, go from eight to 16 GPUs per instance. That could run head-to-head against the DGX-1, the DGX-2 that NVIDIA has developed in their own chassis. That would be interesting to see.

Excellent product. It's extremely reliable so far. The loan-er model we have is excellent. We have had no problems with it.

In some ways, we think it may go beyond what we need moving forward. We don't know yet. We're going to buy another Apollo 6500. We may configure it with half the number of GPUs because that may be all we need. In a sense, we can see the Apollo 6500 being so powerful that we only need half the GPU capability that we have now. But that's what we think we're going to end up seeing as we continue to go through this process of machine-learning.

Tech support has been outstanding. In fact, what HPE is doing is helping us develop the software stack for us to be able to move forward with this whole approach. Our intent is to develop a machine-learning and inference capability within all of Seagate operations, which include eight sites around the world.

My expectation is that this is going to be a rather huge improvement in our operations process. It takes about six months for us to build a single hard drive, and we sell millions of them per year. So you can imagine how important it is for us to develop an analytics capability that HPE is offering us. So it isn't just the Apollo 6500, it's also the software stack that runs on top of it.

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

I specifically purchased it to address a need I have for DPM. I needed DPM to back up to a specific location in both of my datacenters that I have in Ireland. I needed just a lump of slow storage, but that was big, to take 30-day disk backups before they were offloaded to tape. In that sense, it ticked all the boxes and it's been working fine for that.

Now, I'm moving on to StoreOnce, but I'm going to repurpose the Apollos after this. I don't know what I'm going to use them for after this, because DPM is gone. Moving on to Veeam and StoreOnce.

It's really very clever the way it manages to hide the disks away. This idea of pulling out the little trays, I just think that's really, really clever. It's very reliable. I haven't had a single failure at all in the year and a half; not the slightest problem with it. It's been a pretty good product so far.

One drawback which I had: When I needed to expand storage on the Apollo, I had significant problems getting disks for it. It was a very long wait-time. So, if I were to give any advice in regards to improving this product, I would say make more of the 8TB disks available quicker. I ended up having a few issues because I ran out of space. There was a huge lead time while I waited for new disks to arrive here. It left me a bit exposed there for awhile.

But that's the only criticism. Other than that, I think it's a great product. It's really good. Really reliable. Very cleverly designed and I can't think of what better way they could pack more disks into such a small space, so all around it's a good product.

If I get through to the right person, support is very, very good. If I don't get through to the right person, it can be irritating and it can be cumbersome. So to me, the key is getting straight through to the person that's going to be able to help. I don't ring up for Mickey Mouse things. I just ring up when I need something bulked. I try my best to automate as much of the call logging because I have a lot of calls; it's much easier for me to do that online.

So that element generally works quite well, and generally I like the way it works. If I get a call logged online, it usually goes through to the right person, and I usually get a call back. I get actions done pretty quickly on that.

If, however, for whatever reason I have to ring up, I might get through to the wrong section. I've had some hit and miss affairs that have just irritated me. But when I do get through to the right person, I've found in the past, they're very good, generally speaking.

The Apollo was very straightforward. That was nice and easy. Some of my other products, my 3PARs and so on, a lot more complex. But the Apollo, that was nice and straight, easy.

We use the Apollo system for most of our branch offices. Our roadmap is to implement Apollo in all our branch offices by the end of 2018. So we will have something like 50 branch offices with Apollo.

We performed a PoC. We were very happy with it, so we decided to implement it in all the branches.

It's a compact system. We usually use three blades for two-rack units, and with enough storage, it's really a small system with a powerful CPU, powerful hard drives, powerful disks. So it provides enough performance in terms storage value. And the internal network, we are also very happy with it. So, for the branches for us, it's perfect.

The benefit is, as I said, we are compressing everything. In the past, we used StorageWorks P2000, plus SAN switches, plus three or four servers and so on. Now, we have two-rack units for everything. 

For a branch it's perfect because it's simplifying our life.

We would like to see SimpliVity on top of the Apollo.

Touch wood, it's perfect until now. Nothing to complain about.

We are not using it in that manner. We are not using it for the scalability. So the size, one Apollo for each branch, is perfect for us. We are not thinking about scalability.

As usual, with HPE, we are very happy with the support. Honestly, we used it only once for the Apollo system, but all our kits are HPE. So we use their support often and we haven't noticed any difference between Apollo versus C7000 or DL servers. So it's in line with the standard HPE support and we are happy with that.

We have a strong relationship with HPE. So HPE was proactive in proposing this solution. We had a PoC, as I said, and we were happy with it and decided to implement it. It satisfies all our needs and is the perfect solution.

It was straightforward.

We always have an HPE engineer on our site, close to us. But usually, we prefer to do this kind of setup, at least the first time, to put our hands on the device itself, by ourselves. So the setup was done 95% without the support of this engineer. And maybe 5% for optimization with the support of this guy.

Our most important criteria when selecting a vendor include, of course, the experience of the technician, then the support. With HPE as I said, we have a strong relationship. So there is a priority channel for HPE versus other vendors. We always perform a PoC, we compare the vendors. But we were happy with HPE so we have no reason to change right now.

I rate it eight out of 10 right now. It will be a 10 when SimpliVity will be on top of it.

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.

A primary benefit is high reliability. They have very good price performance and configuration options. Being able to configure them in different ways, for different node types, was something we needed.

In referring to the Apollos, what we liked about them was:

• A combination of the density
• The flexibility to run dual CPU nodes or add GPUs to other nodes
• Absolutely being able to mount into Omni-Path architecture, HFIs on those nodes, because we were the very first site in the world
• Being able to connect those in large quantities
• In Bridges, we have 800 Apollo 2000 nodes, and they have been running extremely well for us

I think it's on a good track. What's coming out in Gen 10 is very strong in terms of additional security. Overall, I think those are well architected. They're a very flexible form factor for scale-out. Assuming ongoing support for the latest generation CPUs and accelerators, that will be something we'll keep following for the foreseeable future.

In Bridges we combine the different node types to create a heterogeneous, ideal system. Rather than wishing we had more features in a given node type, we integrate different types. We choose different products from the spectrum of HPE offerings to serve those needs optimally, rather than trying to push any given node in a direction it doesn't belong.

Stability has been extremely good. Jobs run for days to many weeks at a time. We recently supported a campaign for a research group in Oklahoma, who were forecasting severe storms, doing this for 34 days. They were running on 205 nodes.

The example we're featuring was a breakthrough in artificial intelligence where an AI first beat the world's best poker players. And for that one, we ran 20 days continuously, and of course, the nodes had to be up because players are playing the games and we were running that on 600 nodes of Apollos. That was just as seamless, and it was a resounding victory. So, I think that's the strongest win through Apollos in our system so far.

Scalability for us is limited only by budget. Using Omni-Path, we can scale our topology out with great flexibility. And so, scaling out workloads across Apollos has been seamless. We're running various protocols across them. We're running a lot of MPI, and they do spark their workloads. So the scalability has just been limited only by the size of our system.

We have an arrangement with HPE technical support. As our system does call on them on occasion, but the stability has been very high. Over the past year and four months that we've been running bridges, I think we have only had under 70 calls on the whole system.

We knew we had to invest in a new solution as we were looking at designing a system to serve the national research community. We knew what their application needs are, and what their scientific goals will be. So we were imagining what that system would have to deliver to meet those needs. So that's when they told us the kinds of servers we needed in the system. We have the Apollos, we have the L580s, with three terabytes of RAM, we have Superdome integrity with 12 terabytes of RAM, and we have a number of GL360 and other service nodes.

But it was really looking at the users requirements and looking at where high performance computing, high performance data analytics and artificial intelligence are going through about 2019, that that's what caused us to select the kinds of servers that we did, the ratios we did, and the topology we chose to connect them in.

It was the first Omni-Path installation in the world, so people were very careful. With that caveat, I think it was straightforward.

We always look at all vendors before reaching a conclusion. I don't want to name them here, but we're always aware of what's in the market. We evaluate these for each procurement. We pick the solution that's best. The competitive edge for HPE involves several things. These are not in any specific order, as they are hard to rank.

• HPE's strategic position in the marketplace. Being a close partner with Intel, we trust them when there's a new CPU. We can get it in an HPE server very early on.
• When something new comes out, like Omni-Path, it was brand new then. We trusted that HPE would be able to deliver that in a validated product very, very early.
• We are always pushing the time envelope. Their strategic alliance with other strong partners, gave us trust that we would be able to deliver on time, and we were. That's unusual in this field.
• They uniquely had very large memory servers so the Superdomes, and the bandwidth in those servers, was extremely good compared to anything else on the market. We wanted that, especially, for large scale genomics. Putting that in the solution was a big plus. I'd say these items together were the strongest determining factors, from a technical perspective.

I think the advice is to look at the workload very closely, understand what you want it to do, look at the product spectrum that's available here, and do the mix and match like we did. Build them together. There are software frameworks now that actually make it easier than when we did it, to stand up this sort of collection of resources, and to just go with what the workload needs.

It's a stable product; very reliable. It is a good basis upon which to build further. You see some evolution, but not too much. If you go to their events every year, you see an incremental evolution which is normal in that road.

I'm just a general manager and I’m not really technical. However, it gives you a nice, better flavor of the monitoring. I have heard that it provides better management and you can see the possibilities.

OpenView is a new product which does not support older versions of the hardware. This is an issue. That's why we cannot switch to the newer one. We continue using the older product, and that's working fine. I would like to see a bit more integration. This is the major topic.

It is stable and scalable, but the new product has some advantages which we like. However, we cannot switch because we have an issue between non-supported and supported devices.

When choosing another vendor, we look at the overall product and then the software product on top of that. Switching to another vendor is always a big step. We normally don't do that because it presents issues. Every solution will migrate to the same functionality. There is not a great difference between various solutions, but only an incremental one.

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.

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.