SGI Targets Oracle In-Memory On Big Iron
October 26, 2015 Timothy Prickett Morgan
For the past several years, SGI has been extending itself beyond its traditional supercomputing customer base out into the broader enterprise at large. And when we say at large, we really do mean large, and specifically SGI is peddling its “UltraViolet” line of shared memory systems to customers who have workloads where a traditional X86 cluster just can’t do the trick.
SGI offers the largest machines certified to run SAP’s HANA in-memory database, which has the potential to drive a lot of revenue for both SAP and SGI, and now the system maker is going after the equally vast base of Oracle database customers who want to host very large databases in memory using Oracle 12c.
Programming on a shared memory system is a whole lot easier than on a distributed cluster, which is the main benefit of symmetric multiprocessing (SMP) and non-uniform memory access (NUMA) architecture machines. NUMA is a bit tricky in that programmers do have to be cognizant of data placement for processing around the group of machines that are clustered together in a NUMA setup. But with the UV-300 series of machines that SGI launched last fall and enhanced back in July of this year, SGI has dropped the latency on the links between Xeon server nodes to new lows with its NUMALink 7 interconnect and has also made the latencies consistent so this NUMA box behaves, for all intents and purposes, as an SMP machine that doesn’t have to worry about data placement issues. In effect, a UV-300 machine looks like a giant workstation, albeit one that has up to 32 sockets and up to 24 TB of main memory.
For the majority of SAP HANA and Oracle 12c database customers wanting to do in-memory processing, a four-socket or eight-socket system based on Intel’s “Haswell” Xeon E7 v3 processors, launched in May, are plenty of enough compute and memory. But for a subset of these customer bases, bigger iron with more cores and, more importantly, a larger memory footprint is needed. Bill Dunmire, senior director of product marketing at SGI, tells The Next Platform that Oracle has about 310,000 customers running its eponymous relational database management system and that somewhere around 10 percent of them will need a larger memory footprint than can be handled using four-socket and eight-socket machines of any architecture. About 60 percent of Oracle’s customer base runs on X86 iron (predominantly Intel Xeon machines), and at OpenWorld this week Oracle CEO Mark Hurd confirmed that Intel and Oracle have over 200,000 common customers.
How much of a revenue opportunity Oracle in-memory processing is for SGI remains to be seen – particularly if non-volatile memory such as Diablo Technology’s Memory1 flash DIMMs, Intel’s 3D XPoint SSDs and DIMMs, and IBM’s coupling of flash-based storage arrays with main memory through its Coherent Accelerator Processor Interface (CAPI) interface on Power8 machines find their way into datacenters, effectively extending DRAM in systems with NVM. It will be interesting to see how SGI makes use of various memory-extending NVM technologies in its own UV shared memory and ICE X clusters, too.
The one thing that SGI has playing in its favor is that companies are loathe to hit up against the performance ceiling with any server technology, and with in-memory processing, that ceiling is relatively low at tens of terabytes for all databases at a company compared to disk-based databases that can scale into the petabytes. (Most databases themselves are pretty small, of course, unless you are talking about the ones at Facebook or Google and such.) The idea of running online transaction processing and ad hoc query workloads on the same systems is appealing, obviously, because it means customers do not have to perform extract-transform-load (ETL) operations. (That said, most enterprises with a data warehouse will continue to use them, as SAP itself does since switching over to HANA for its own internal transaction processing applications.)
The UV 300-RL machines that SGI is announcing today are based on the same UV 300 platform that SGI debuted a year ago, which come in an all-to-all topology rather than the NUMA topology of the UV 2000s and UV 3000s that use the prior-generation NUMALink 6 interconnect. NUMALink 7 has a 7.47 GB/sec bi-directional peak bandwidth, which is 11.4 percent higher than its predecessor, and the latency is lower, but SGI is not saying by how much because it is a trade secret.
The trick with the UV 300-RL machines to run Oracle 12c as an in-memory database, as it turns out, is getting the underlying operating system to scale. SGI has worked with Oracle to certify the 12c database and its in-memory columnar data store running atop Oracle’s own implementation of Linux, called Oracle Enterprise Linux and based on Red Hat’s Enterprise Linux but with Oracle’s own Unbreakable Enterprise Kernel. To be specific, the UV 300-RL machines are certified to run the UEK 7.1 kernel, which supports main memory addressing for Oracle 12c beyond 8 TB. If you use Oracle on X86 iron using another Linux distribution, says Dunmire, 8 TB is the upper limit, and as far as he knows, no other system vendor has certified UEK to run on their big NUMA machines for the purposes of supporting in-memory processing.
Hewlett-Packard’s “DragonHawk” Superdome X system has up to 16 processor sockets that support the “Ivy Bridge” Xeon E7 v2 or Haswell Xeon E7 v3 processors and up to 24 TB of main memory in its 384 memory slots. That configuration assumes very fat 64 GB memory sticks, which would be very pricey indeed. SGI’s UV 300 can get to 32 sockets and 24 TB using 32 GB memory sticks, and Dunmire says that for customers that need to push up to 48 TB of shared memory capacity, SGI can shift to 64 GB sticks, too. For customers who are willing to shift from all-to-all topology and pay a little latency penalty for their workloads (and have to possibly do a little NUMA tuning with their applications and databases), SGI will allow the UV 300 machines to scale up to 64 Xeon E7 sockets and up to 64 TB of total memory.
It is hard to quantify the total addressable market that SGI is chasing with its UV 300-RL machines running Oracle 12c running the database in memory. (Or at least some of the database in memory. Oracle 12c has a dual-format mode, with transaction processing being row-based and storing data on disks and flash and with analytics being columnar-based and stored in main memory.) Oracle has its own big SMP machines, the Sparc M6 and M7 servers, the latter of which will probably be divulged at OpenWorld this week. (The 32-core Sparc M7 processors were unveiled in August 2014 at Hot Chips and the “Sonoma” Sparc T7 chips with embedded InfiniBand networking were revealed at the Hot Chips this year, but systems have not been announced for these yet.) IBM Power System servers are also popular platforms for Oracle databases, and HP Itanium machines are still out there in the field, too, but are probably not going to remain there for many more years.
SGI’s efforts with SAP HANA will, perhaps, be enlightening in helping to understand how SGI can go to market and get some traction. First, SGI has inked a reseller deal with Dell, which does not sell Xeon E5 or E7 machines with more than four sockets, for SAP HANA and there is no reason why it can’t now do the same thing for Oracle 12c on UV 300 iron. SGI started shipping machines tuned for HANA a year ago, and now has over 50 customers with an aggregate of over 200 TB of main memory allocated to them for running HANA. That works out to around 4 TB of memory, and frankly that is not very much on average when you consider that a four-node Xeon E7 machine has 3 TB of memory. But this, oddly enough, is a good thing, because these 50 customers clearly are buying a machine that will let them scale up memory quickly, just by adding nodes, in the future. They do not want to run out of memory, and they are thinking ahead. (This is particularly true for customers looking at the S4HANA application suit, which requires it to be run on a single system with the HANA in-memory database.) Customers are, in fact, starting to expand the size of their machines, says Dunmire.
The same effect – customers start small with big iron so they have room to expand without worry – could happen with customers looking at Oracle 12c, provided Dell and Oracle help SGI do some selling. The 10 percent or so of the Oracle database space that will need fat memory machines is, for SGI, a very big target, although SGI has not put numbers on it. SGI’s latest projections put the total addressable market for SAP HANA on machines with four-sockets or more at around $350 million in 2015, growing to around $1 billion by 2018. SGI is expanding the database support for the UV machines because it wants to grow its shared memory revenues to account for around 10 percent of sales in the current fiscal year.
This could mean, of course, adding support for other databases and trying to drive deeper into enterprise accounts. Dunmire tells The Next Platform that some customers have asked for MySQL support on the UV iron, and that it is also keeping a keen eye on how it might deploy Microsoft’s SQL Server and make use of its “Hekaton” in memory features, too. At the moment, IBM’s DB2 with its BLU in memory extensions are not on its radar.
The UV 300-RL is available to early access customers now and will start shipping next month. The machines come preconfigured with Oracle Enterprise Linux 7.1, but do not include Oracle 12c database licenses, which customers have to acquire on their own. Incidentally, any Oracle database that is certified to run on its homegrown Linux will run on top of the SGI iron, but given the memory footprint, SGI is focused on 12c and it in memory features.
Incidentally, a few years back, SGI did a deal with the US Postal Service to create a postage fraud detection system based on big UV iron that used Oracle’s TimesTen in memory database, and this is also an option for customers. But given the 12c database’s capabilities, backing 12c makes more business sense than trying to push the TimesTen product against 12c.