On 2016-08-19 01:39:23 +0000, Arne Vajh j said:
> On 8/18/2016 12:47 PM, Kerry Main wrote:
>> Imho, designing stateful applications could be one of the
>> differentiators for OpenVMS clusters - especially with the new file
>> system now cooking.
>>
>> Numerous new application groups are looking to develop stateful
>> applications as a means to create next generation applications.
>
> ????
>
> Stateful applications are totally industry standard today.
>
> IBM WXS, Oracle Coherence, JBoss Infinispan, Hazelcast, memcached, redis etc..
>
> It is off the shelf functionality.
Ayup. Been that way for a while, too.
Or about how to build or buy a modern cluster, depending on how you read it.
>> Question - Why do current apps need Redis distributed cache solutions?
As mentioned... redis is a distributed memory database. So it can
work for caching, or general database operations, or whatever.
>> So instead of large numbers of small core, low memory servers (each of
>> which have separate system and appl local disks to manage / upgrade),
>> why not use the best of both distributed and centralized models? What
>> about an approach that uses much fewer scale up first big core (32+)
>> servers with big memory (TB+), then scale out.
With AMD's recent demonstration, 32 cores is soon to be a single-socket
configuration.
http://www.pcworld.com/article/3109327/hardware/let-the-cpu-wars-begin-amd-shows-its-zen-cpu-can-compete-with-intels-best.html
That design is supposedly due 2017, which means Intel will be up in
that range just as soon as they can manage that.
All discussions of adding cores and clock rate and aggregate
performance TDP aside — variable clock rates are now common, and having
more cores active means more heat, which means throttling can be
necessary.
>> In addition, use a common file system (think new file system being
>> developed) across all nodes in both sites (if DT/DR required)?
If looking for speed, why would anybody hit a file system for anything
other than recovery, and then only after mirroring the data to a remote
and battery-protected server?
> Few high end systems are much more expensive than many low end systems.
>
> For many cases it is simply not competitive.
Ayup. HPE folks were reporting 80% of their server sales were
two-socket boxes, too. Increasing core counts means smaller and
denser boxes and fewer sockets overall, too. Yes, there'll always be
bigger boxes and specialized boxes available. But AFAIK OpenVMS I64
never got around to supporting SD2, and other high-end support was via
HPVM and that's now not current versions. Which certainly implies
that there wasn't much demand for such configurations with OpenVMS; of
configurations with 32+ cores and TB-sized memory. In short, I'd
expect VSI is looking at two-socket x86-64 server boxes as their
biggest potential hardware market. That'll likely get them 64 cores
and 128 threads as soon as next year, too.
>> The state can be maintained on the local file system, so no matter
>> which server node in what DC the session is directed to, the state is
>> available locally via direct reads to local HW cache or the local file
>> system that is common to both sites.
>
> Accessing cache servers with in memory databases will be a couple of
> magnitudes faster than a shared file system and lock manager.
LAN latency is pretty good, even compared with local SSD:
https://gist.github.com/jboner/2841832
Most folks that want persistence in addition to server-level
replication and something akin to RDMA are be looking at SSD data
storage — if they can't afford full-on flash, soon at the 3D XPoint
stuff — and maybe also at something akin to PostgreSQL BDR for asynch
replication. Rempote synch replication means having the data across
the LAN link, so a typical OpenVMS cluster with shadowing is going to
take the hit of LAN traffic and synchronous completion for all writes.
HBVS also has the issue of not compressing the data — it'll be
interesting to see if the new file system provides that for RMS and XQP
operations on disk, and whether OpenVMS uses memory compression to
speed paging and swapping operations — and then there's that HBVS and
RAID-1 in general doesn't have a good way to reduce the volume of data
replicated and then shuffled around as the disks get larger.
OpenVMS has no support for checkpointing for backups or replication or
such, so you're rolling your own using existing APIs (DECdtm, HBVS, I/O
flush calls, etc), or you're using a database that has these
capabilities integrated, or maybe some of the third-party add-on code
that ties into RMS and the XQP for related purposes. That code tends
to be tricky, too.
>> You can further reduce the overall latency by installing the App, DB
>> and middleware all on the same OS instance to take advantage of the big
>> memory, large HW caches. This also enhances server utilization levels.
>
> Poor security and a performance benefit that decreases with scale out
> and a risk for interference between applications is not an attractive
> solution.
That, and — if I'm looking seriously at reducing application latency —
why would I want to share the processor caches among disparate
applications? That's just asking for contention and unpredictable and
odd performance characteristics. NUMA maybe, but you're still dealing
with the cache coordination across all processors in a NUMA box that'll
support OpenVMS.
But the design all depends on the parameters, and most folks doing
high-end configurations probably aren't using OpenVMS in any case.
The folks looking for entry-level configurations definitely aren't.
--
Pure Personal Opinion | HoffmanLabs LLC