[Info-vax] Marketing ideas for VSI ?

[johnwallace4 at yahoo.co.uk]

On Saturday, 15 December 2018 15:35:06 UTC, Kerry Main  wrote:
> > -----Original Message-----
> > From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Bill
> > Gunshannon via Info-vax
> > Sent: December 14, 2018 9:45 PM
> > To: info-vax at rbnsn.com
> > Cc: Bill Gunshannon <bill.gunshannon at gmail.com>
> > Subject: Re: [Info-vax] Marketing ideas for VSI ?
> > 
> > On 12/14/18 9:46 AM, Jon Schneider wrote:
> > > On 14/12/2018 13:41, Simon Clubley wrote:
> > >> One idea I had was something along the lines of the disaster-proof
> > >> video showing what VMS clusters can do. I was thinking of a demo
> > >> something along these lines:
> > >
> > > I certainly get irritated by videos of people building clusters out of
> > > Raspberry Pis running SimH with presumably no more of a concept of
> > > what a cluster actually does from the client's point of view than I
> have.
> > >
> > > My understanding is it's maybe the (Files-11) filesystem and maybe RDB
> > > or something. But if that's it how is that useful in today's world
> > > when the clients are web browsers ?
> > >
> > > So please explain what clustering actually _does_ and sell me VMS (not
> > > that I am in a position to buy into it on behalf of anybody).
> > >
> > 
> > If it were me I would be pushing the concept of long distance clusters.
> > Machines geographically distant so as to survive major natural and man
> made
> > upheavals.  The biggest drawback I remember from when I was more up to
> > date on this was network latency and that has really become less of an
> issue
> > today.
> > 
> > bill
> > 
> 
> Actually network latency is primarily based on speed of light (hops also),
> and this has not changed since the speed of light was originally calculated.
> 
> Other factors to consider for long distance clusters and how far apart the
> can be is the R/W ration of the application This is because active-active
> clusters with load balancing across both sites requires  synch replication.
> A heavy write app will mean you will likely need to have sites closer
> together than the standard 100km rule of thumb that is usually stated in the
> context of long distance clusters. This causes performance issues if a heavy
> write bogs down the app while it is waiting for writes to occur at both
> sites before the update is considered complete at either site.
> 
> 
> Regards,
> 
> Kerry Main
> Kerry dot main at starkgaming dot com

Excessive write latency causing applications to 
perform below expectations is probably one of 
the reasons things like "optimistic locking" 
and "eventual consistency" became acceptable 
in certain circumstances.

While I'm here, a word on "uptime" vs
"service availability". There are very
few applications/services which are 
genuinely dependent on continuous years of
uptime, though as it happens a properly 
designed VMScluster setup can deliver that
if it's what's needed.

There are rather more applications which 
must be available when they are needed, 
otherwise business is at risk. One classic
example of that used to be the newspaper 
printing industry - a few hours a day, the
printing presses *must* run, or there's
nothing to sell; rest of the day, who 
cares. Sometimes the presses need to run
24 hours a day, if something big is going
on.

Newspaper printers as such are likely a 
dying industry, but there are are plenty 
of others without requirements for years 
of uptime but where a failure during a 
critical few hours or days would not be 
welcome.

A half decent AMD64 box these days should 
be able to deliver decent uptime, and 
multiples configured properly should be 
able to do even better, and might even be
able to cope with unplanned peaks in demand,
IF the software can cope too.

The commodity OSes as typically deployed
don't seem to be coping all that well with 
even that level of availability. I wonder
why that might be.



Back to performance/resilience/testing:
I used to know some folks who did 
performance testing for customers interested
in multi-site environments etc ("try before you
buy") back when sensible people understood
that a single-user single-machine demo for the 
CEO wouldn't necessarily scale up (to "web scale"
or whatever) in the real world. 
Especially if, e.g., systems had to be able to 
reliably recover from a network failure.

All their gear was actually in one datacentre
(these days it could be all in the back of a 
not very big bus). The various boxes were
interconnected by a fortune's worth of fibre 
still mostly on its reels. And disconnected 
too, to make sure error recovery behaves as 
required.

These days, in the UK at least, the "industry
default" procedures seem to be to roll it out
and see what happens and, if absolutely 
necessary, fix any problems afterwards.

Some people still like to try things out, but it 
seems to have become a minority sport, even in 
things like emergency services incident response 
and other critical-but-unpredictable stuff.

Anyway, back to latency arithmetic. Remember in 
particular that more bits per second does not 
of itself reduce the latency, and the required 
layers of buffering (and, if required, error
detection and correction) will inevitably 
increase the latency in some cases (e.g. where 
old-school TCP/IP is involved).

50km of fibre at (say) 200km per millisecond 
is 250 microseconds, one way (careful with 
the units and with the fact it's less than
3E8 m/s because it's not in free space).

10GBit/s is 10kbit/microsecond, right? For
simplicity let's say 1kbyte/microsecond.

So in 50km of 10Gbit fibre there's at least 
250 microseconds latency and therefore 
at least 250kbytes in flight, whose status
is unknown by the originating app/device 
until it's successfully acknowledged
(which presumably takes at least another 
250 us).

Increase the bit rate and the data at 
risk goes up correspondingly too. 

Shorten the distance and there's probably
a more interesting discussion to have,
which is why it's good to know that the 
100Gb stuff from Mellanox will be supported 
in VSIVMS V9 in due course but in the 
meantime no amount of marketing and 
modernising, not even an Intel-scale cash 
pile, can change the laws of physics.