Re: Quo vadis Galaxy or VMS (a bit rambling)

From: Glenn Everhart (Everhart_at_gce.com)
Date: 09/27/05 

Date: Mon, 26 Sep 2005 22:00:10 -0400

Re the VMware comments below: VMware gets used to provide isolation
and greater security where underlying OS is inadequate. Even so, there is
coupling of some file systems with VMware, and they act as though there
is network coupling also. This in the presence of a weak underlying OS
protective mechanism, I would argue, still gives weak (though not quite as
weak as bare os) protection. Generally VMS is a different kind of animal
because it provides better protections by itself, and does not really need
virtual machine layers in addition to its own mechanisms.

All very nice: will HP sell it?

Main, Kerry wrote:

>>-----Original Message-----
>>From: Glenn Everhart [mailto:Everhart@gce.com]
>>Sent: September 25, 2005 7:41 PM
>>To: Info-VAX@Mvb.Saic.Com
>>Subject: Quo vadis Galaxy or VMS (a bit rambling)
>>
>>When Galaxy was thought of, the idea was that it was/is where
>>the future of
>>computing needs to go. Now granted, the focus was on
>>enterprise problems
>>that require large scale computing with hefty guarantees
>>about data safety,
>>security, and high throughput. There are many apps (and some
>>of what I have
>>worked with lately in concept will add to them) where these
>>characteristics
>>have been needed.
>>
>>However the Marvel boards have been announced (though
>>enumbrated by the
>>planned termination of Alpha) and much effort has gone into
>>moving VMS to
>>IA64, which certainly is not the Evident Next Big Thing In
>>Computing (at least
>>not yet, if it ever becomes so).
>>
>>I wonder if Galaxy is still seen as where future systems will
>>need to be?
>>
>>If not there are a few things I could imagine as interesting,
>>though probably
>>not possible and most likely good for a laugh...
>>
>>Things like deciding that the next big architecture may come
>>from the game console
>>space (sort of a karmic reincarnation of Amiga?) and
>>designing a descendant, with
>>VMS ancestry and culture, for such architectures?
>>
>>If Microsoft is serious about rebuilding its internal
>>architecture, they may
>>sometime take a look at all the calls layered on top of the
>>NT kernel which
>>pass null terminated buffers with nary a size and all the
>>assumptions around
>>everything being able to call everything else willy-nilly,
>>and decide that
>>they could just buy rights to VMS and see who'd be interested
>>in building
>>not Windows, nor VMS, but a successor to both that would be
>>driven this time
>>by VMS people to get the OS right, yet provide something
>>close enough to the
>>old APIs of both that recompilation would not always be
>>needed. I'd prefer to
>>see HP buying Windows for this (or having it belatedly
>>declared to have been
>>HP property all along) but am not good at imagining bobcats that could
>>swallow a rhinoceros.
>>
>>Galaxy has some scaling properties I still really like, and
>>the VMS layering
>>is such that some of what Microsoft has been speaking of looks pretty
>>straightforward. For example, if you wanted to put a DBMS
>>query language into
>>VMS filesystems, an optional layer that sat between RMS and
>>the XQP which
>>would recognize some special quoting characters in directory
>>names as queries
>>rather than names could be concocted to do DBMS searches
>>instead of directory
>>lookups, filling in the database with filenames and file IDs,
>>but also with
>>whatever else was convenient. It looked to me some years ago
>>like maybe a one
>>man year job to get it working on a single node (servable);
>>some more time to
>>solve cluster problems. The clustering issues might be
>>difficult, but such a
>>thing would be useful even while it ran only on one node.
>>Point is that the
>>VMS design is layered cleanly enough (and is probably cleaner
>>now than it was then)
>>that functional add-ins could be tried in such a way, without
>>taxing the
>>entire system with them.
>> The way Galaxy can move processors to load is also
>>impressive, esp. the more
>>extreme flavors of that design. I thought that telling people
>>they can buy,
>>say, 10 processors to do the work of 15 was a weak sell given
>>price drops, but
>>having a box that can put 100 processors to work on a very
>>parallel problem
>>one second and move them to 30 or 40 less parallel problems
>>the next second
>>is really impressive. You can buy 50% extra processors
>>easily, but scaling
>>by orders of magnitude in real time, and making it
>>unnecessary for humans to figure
>>out how this should be done, can be a Godsend.
>>
>> Is the vision of the future still Galaxy? Is anyone asking?
>>
>>Glenn Everhart
>>
>
>
> Glenn,
>
> While I am certainly *not* talking in any type of official capacity, I
> can provide some general insight into Galaxy and why customers are now
> looking much more today into similar virtualization technologies than
> they were when Galaxy was first introduced.
>
> First - OpenVMS Galaxy virtualization really was ahead of its time in
> terms of "non-mainframe" server technologies and being able to
> dynamically share CPU's between different OS instances.
>
> However, partitioning in general is not something new as the mainframe
> folks had this capability 20 years ago. What is new is that these
> technologies are now being introduced into the non-mainframe market.
>
> Why?
>
> Simple - the coyote ugly problem is that the average server cpu
> utilization during peak business periods of most Cust systems today is
> 10-20% (Windows) and 15-30% (UNIX). So, while these systems were
> typically justified using latest and greatest benchmarks and latest and
> greatest competitive speeds-n-feeds, the reality facing most Customers
> today is that these systems are, for the most part, grossly under
> utilized.
>
> The culprit is the one-app, many servers (dev, QA/test, prod) model that
> has sprung up over the last 10 years. When servers are refreshed, it is
> typically one-for-one and hence over the years the cpu speed has
> increased dramatically, but the workloads have remained relatively the
> same. Hence, the % utilization of each workload as a % of the server
> capability has been shrinking. This low utilization will continue to
> shrink unless a different model that the one-app, one server model
> (including refresh) is changed.
>
> This is why server consolidation, virtualization and workload management
> are so hot with most med-large Customer environments today. Their IT
> budgets are decreasing, their services requirements increasing and their
> head counts are being reduced (or at least not being increased to handle
> new service requests).
>
> Now, there are two primary types of virtualization - Application
> Stacking and OS Stacking.
>
> 1. Application stacking is the best financial and technical solution
> because it:
> - reduces OS instances and number of OS instances is tied to FTE counts
> which is by far the biggest IT expense in most companies.
> - reduces HW requirements of many smaller servers
> - small overhead
> - improves overall utilization
> - with OpenVMS, HP-UX and some other UNIX's, you can dynamically migrate
> CPU's between different OS instances as the load changes. With OpenVMS,
> these CPU's can be migrated between OS instances dynamically (based on
> business rules), manually (drag-n-drop) or even time-of-day.
>
> The down side to application stacking on Windows and to a bit of a
> lesser extent, many UNIX systems, is that the culture is very averse to
> sharing resources on the same system.
>
> "What, share my application with that other dept system? No way in hell
> will that happen.."
>
> In addition, in the case of Windows and Linux, the OS's really do not
> have the technical maturity yet to natively support application
> stacking.
>
> 2. OS stacking is the next best thing, and because of the technical and
> political challenges, is the reason why it is becoming so popular with
> Windows/Linux:
> - reduces HW requirements of many smaller servers
> - improves overall utilization
> - politically "easier" to implement
> - does *not* reduce OS instances, so does not impact FTE counts and will
> also add some additional costs in terms of server overhead and licensing
> (e.g. VMware)
> - does not allow one to dynamically move CPU's between different OS
> instances
>
> So, in summary, making much better use of server resources is a very
> high priority for most med-large Cust's today. IT shops are under
> extreme pressures to reduce costs and while OS stacking will gain some
> benefits, if the political issues of "one-app, many servers" model can
> be overcome, then even more cost reductions can be obtained with
> application stacking using virtualization (e.g. Galaxy, vPars etc) and
> various workload management (class scheduler) strategies.
>
> Regards
>
> Kerry Main
> Senior Consultant
> HP Services Canada
> Voice: 613-592-4660
> Fax: 613-591-4477
> kerryDOTmainAThpDOTcom
> (remove the DOT's and AT)
>
> OpenVMS - the secure, multi-site OS that just works.

Relevant Pages

  • RE: Quo vadis Galaxy or VMS (a bit rambling)
    ... Quo vadis Galaxy or VMS ... Simple - the coyote ugly problem is that the average server cpu ... Stacking and OS Stacking. ...
    (comp.os.vms)
  • Re: Banana Republic (was Re: OpenVMS Book Wins award)
    ... HP/VMS sees nothing wrong with prohibiting the run-time discovery of clients ... island that is VMS? ... Adobe/Flex also with long-term TCP/IP Socket support is standardizing ... Execution Server Processes re-usable on a transactional basis ...
    (comp.os.vms)
  • Re: Walk a mile in their thongs (Oz footware - if some find the imagery disturbing :-)
    ... There is a server having an SOAP API/interface ... You'd like your VMS server to act as a client ... Tier3 can't talk SOAP, XML/RPC, Java RMI, CORBA, or Swahili either. ... If gSOAP on VMS were to be restricted to client-only then maybe it'd go ...
    (comp.os.vms)
  • Re: Announcing: gSoap for OpenVMS blog
    ... I realy do not see why I should bother at all, ... services from your own VMS system? ... and yet I've implemented a very effective (although still crap) ... Which part of that requirement involved a new HTTP Web Server eh? ...
    (comp.os.vms)
  • Re: Is VMS losing the Financial Sector, also?
    ... On Behalf Of Bill Gunshannon ... Is VMS losing the Financial Sector, ... One of their Customers was running Windows Server and was down for 2 ...
    (comp.os.vms)