From: Bill Todd [billtodd@foo.mv.com] Sent: Thursday, May 18, 2000 6:32 PM To: Info-VAX@Mvb.Saic.Com Subject: Re: "Modern" OpenVMS? Brian Schenkenberger, VAXman- <system@SendSpamHere.ORG> wrote in message news:009EA46D.3C204C4E@SendSpamHere.ORG... ... > When the unix (and NT) crowd can show me a "cluster" of more than 2 nodes > and both of them are actually doing something, then I might be more open > to the belly-aching anout VMS not having unixy features. While I realize that your ignorance may be a great comfort to you, it gets tedious correcting it. However, I will take you at your word above: if a turkey can be transformed into a productive member of society, it will be worth it. For starters, you set your bar 'way too low: even pathetic 2-node fail-over NT/W2K 'clusters' (and they'd be pathetic w.r.t. the state of the art even if that state had never heard of VMS) can have both nodes doing useful work - they just can't be accessing the same disks (unless they're running Oracle Parallel Server, but in that case NT has to share the credit with Oracle, so it really doesn't count). One node fails, the other picks up its disks (and its work, under application control similar to that required when a VMS node fails and other nodes can cover for it); fail-over can be relatively quick (a minute or so - unimpressive but generally adequate) as long as NTFS is used as the file system so no lengthy file system integrity scan is required on the take-over. Linux cluster approachs abound, but aren't really aimed at high availability (yet), so, while they definitely allow multiple nodes to do useful work - and even cooperate on a specific problem - I won't present them as satisfying what I tend to think you meant. Sun clusters come somewhere near competing with VMS clusters on features, though fall considerably short in elegance and performance. They share the same data throughout the cluster, but using NFS (which I likely don't appreciate any more than you do, but functionally it gets the job done) rather than a real cluster file system. Among other things, this severely limits their ability to cache data locally in shared-update situations (unlike VMS, though even VMS's ability to cache in a distributed manner is far from optimal). They do, however, have effective file and byte-range distributed lock management which can ride through failure of the lock server and reestablish the lock context on a new server, so *functionally* they don't look too bad. Their file system (which may be a Veritas derivative; I'm pretty sure HP's cluster file system is) can be broken into pieces (which the Unix 'mount' mechanism allows to be reassembled as sub-trees of a single system-wide directory structure), each managed by a single serving node on private disks which can fail over to another node if necessary (fail-over takes about a minute - less if it's a planned fail-over for, e.g., maintenance purposes). Until recently I think cluster size was limited to 4 nodes, but it may have just increased; in either case, since each node can be up to a 64-processor SMP, that's perfectly adequate for server configurations, though doesn't support workgroup-style workstation clustering as VMS does. Tru64 clusters in their newest release (5.0A) ported over a good deal of the base VMS cluster implementation to replace the considerably less robust prior (V4) approach. Their file system is home-grown (AdvFS, a journaling file system written by Chris Saether, one of the primary creators of the XQP, headed the design and implementation, along with Debbie Girdler, another long-time DECcie and still, last I knew, Cutler's significant other), but was not designed for clustering, so Tru64's 'cluster file system' is a served, fail-overable design rather than shared-disk (though it may just serve meta-data and allow direct shared-disk access to user data: if anyone happens to know, I'd appreciate details, since information on the system does not seem to be readily available). Under the file system is a cluster-aware version of Veritas' Logical Volume Manager, which gives AdvFS facilities (e.g., on-line capacity increases, transparent data-shuffling to alleviate hot spots) that ODS-x may lack, and the VMS Distributed Lock Manager was ported largely as-is to allow distributed caching (and the many other non-file-system-related jobs it also does). And since the platform is Alpha, you already know its range and capabilities. If you're looking for clustering implementations more than a few years old, try AIX on IBM's RS/6000 SP: they used to call it a massively-parallel architecture until 'clustering' became respectable. It started out aimed at high-end scientific applications, and the largest cluster in the field has (I believe) 512 nodes, each of which is an SMP, but it works just fine for commercial applications too. The traditional file system on it (JFS) is a journaling, served-data, fail-over implementation, but recently they added GPFS, which supports shared-disk access (actually, 'virtual shared disk', which is pretty much identical to a private VMS disk that its host serves to the rest of the cluster at the disk-access level as a 'cluster disk'). Or for clustering arguably older than VMS's, there's Tandem: it's 'loosely-coupled' multi-processor availability environment effectively constitutes a cluster, in which all nodes can perform productive work while remaining ready to pick up that of a failed comrade, and over time the emphasis on scalability has come to equal that devoted to availability. How about third-party implementations? Veritas markets a suite of cluster products that can make just about anyone's Unix clusterable (I think HP pretty much relies on them instead of any home-grown code, and it's possible that Sun may at least in part as well; don't know much about SCO Unix clustering, but it could too). IBM sells 'extensions' for Microsoft's cluster products that may significantly extend them (my impression is that they may be in part based on IBM's portable 'Phoenix' cluster architecture that it developed a few years ago). Compaq/Digital used to sell something called clustering on NT, but that's now gone. And since imitation is the sincerest form of flattery, it would be negligent to leave out IBM's System/390 Parallel Sysplex, a shared-disk implementation every bit as much as VMS's is, though in the mainframe idiom (hey, RMS was modeled in many ways on VSAM, so it can't be *all* bad). And yes, all of the above examples save for NT/W2K and maybe Linux support multiple nodes concurrently reading and updating the same data and cooperating on the same workload. W2K, Sun, and Tru64 cluster facilities (don't know about the others) support IP address take-over to provide transparent service continuation to external clients. Do I think that any of the above implementations is superior to VMS's in any significant way? No I do not. Do I think that many, maybe most of them can satisfy most customer needs in the area of clustering, albeit perhaps not as well as VMS can? Yes I do - and so apparently does most of the rest of the world. *That's* why it's important for VMS to be able to beat them at their own game: if it can't, for most purposes it will be ignored. - bill > > -- > VAXman- OpenVMS APE certification number: AAA-0001 VAXman@TMESIS.COM > > GNU Freeware -- What does the GNU *really* stand for? Garbage! Not Usable!