Using different HW Features in a Box

I wrote a small article for my company how you could use Oracle’s new SPARC hardware for different layers in your datacentre… original in German, could be found on SPARC T7-1 testing In-Memory, DAX and Crypto Engines
Some findings and interesting points translated for my blog:

So what I thought about are classic tasks normally found on several servers, build in one box. All of them could benefit from different features which come with M7 or S7 chips.
The database in the backend will profit from the big memory bandwidth and the SQL Offload Engines called DAX, data analytics accelerators. In the combination Oracle says in their PowerPoints the database could scan up to 170 billion rows per second with those streaming engines with a measured bandwidth from 160GB/sec per socket. Wow… and that’s measurement; the M7 processor hardware facts are talking about 4 memory controller units per socket which could handle 333 GB/sec raw memory bandwidth per processor. (It seems that DDR4 is the “bottleneck” not the CPU…) compared to the latest Xeon E7 88xx v4 (Q2/16) with 102GB/sec mentioned on Intel’s ARK technical details pages.

The next layer could be the application itself. With 8 threads per core a perfect fit for a high user load and with critical threads the process has more exclusive access to the hardware. Perfect for running a wide mix of workloads, some will be designed for throughput, others for low latency.

The third level could be something like a reverse proxy with a SSO backend or something. The proxy could take the application sessions if not already encrypted and use the build in cryptographic accelerators on the processor to encrypt. Solaris itself and some standard applications using these engines already, like Apache, IPsec, Java, KSSL, OpenSSL, ZFS Crypto. But not only Oracle software like the database and WebLogic are supporting Solaris’ Crypto Framework, also IBM with DB2, Informix, IBM HTTP Server or WebSphere are certified with IBM Global Security Kit to use SPARC’s hardware encryption (IBM GSKit v8).

Oracle SPARC processors can handle 15 industry standard algorithms and a bunch of random number generators (AES, Camellia, CRC32c, DES, 3DES, DH, DSA, ECC, MD5, RSA, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512). (BTW; Xeons would have 7 crypto instructions and 5 on-chip accelerated algorithms; IBM Power8 = 6 instructions and 8 accelerated.)

The last level could be the way to the internet, separated to the other domains. Solaris offers a build-in firewall, load-balancer or other web utilities to handle the connections. Having Solaris on SPARC in the front helps you easily to prevent so called script-kiddies using their found hacks and attacks because on one side SPARC is big endian based, so standard attacks will run into the “wrong direction” compared to little endian on x86. On the other side the new SPARC processors are protected by “silicon-secure-memory”. When an application requests some new memory to use via malloc(), the operating system tags the block of memory with a version number, and gives the app a pointer to that memory. Whenever a pointer is used to access a block of memory, the pointer’s version number must match the memory block’s version number, or an exception will be triggered. The version numbers are checked in real-time by the processor with a tiny overhead – an extra one percent of execution time, according to Oracle’s benchmarks. (more infos at theregister )
So imaging using all of these features a whole datacentre could be hosted on a single server or if it comes down to availability you could build a cluster with failover or live migration between the servers.