No Slide TitleTechnology Overview...
Hello, I am ____________________. It is a pleasure to be here with you today to describe the concepts and functionality of an evolution in the OpenVMS Operating System: “Galaxy Software Architecture on OpenVMS”
As you will see from the presentation, OpenVMS is alive and well and we have continued to develop new OpenVMS features to enhance our enduring and proud heritage as a bullet-proof, enterprise-class operating system. The focus for OpenVMS is to constantly meet the your needs for a continuous computing environment 24 hours a day, 365 days a year.
The acronym “STARS” in the lower left corner is intended to emphasize that:
Whether starting with today’s version of the AlphaServer 8400, 8200 or 4100 systems, or when you upgrade to the Speed of the next generation Alpha chips, install faster memory, or when you move up to the AlphaServer systems of the future, OpenVMS Galaxy is ready when you are and your investment is protected… as always.
Total cost of ownership is impacted by providing you with a way to do more with the same number of systems or to meet the need for highly scalable growth
OpenVMS Galaxy provides greater Availability in a single computer.
*
( SPEAKER NOTE: This slide builds from left to right,…)
We worked with customers and business partners to identify the key requirements of their computing environments and they boil down to three categories that I think you can easily relate to in your own data center:
Your need for expansion of the existing computing environment; to stretch the capacity of your existing systems and to easily add new systems to the environment.
Your need for business flexibility that allows the computing system to “wrap around” your business to make it easier for you to run your business. You went into business to manufacture products, or provide services, or to produce pharmaceuticals, etc., and you need a computing environment that helps make you competitive.
And, your need to consolidate older system technology from time to time to take advantage of newer and faster systems and to conserve floor space, power, etc.
Our customer sessions uncovered two basic issues in our “focus group” studies…
OpenVMS Galaxy must provide the computing environment and workload necessary to operate your business. That is, the environment must:
Allow you to expand your work capacity without system stoppage.
And, allow you to modularize and adapt the system to support better availability and utilization of resources
As Customers, you are wary of buying dedicated application systems
Your sites are multi-application environments
Your sites have multi-vendor databases
*
Isolationist
Hard partitioning
Soft or application partitioning
Only the monitor directly controls resources
OpenVMS Galaxy: soft partitions, multiple cooperating instances, each directly controls hardware
9
High commercial
application performance
Dynamic resource
Ability to consolidate distributed cluster applications
Ability for mixed versions and rolling upgrades
Galaxy solves High-End Server (multi-cpu, memory & I/O)
scaling and cluster interconnect bottlenecks
APMP with Galaxy Software Architecture
Instance A Private Memory
Compaq Galaxy Software Architecture
The picture on the screen now shows a three instance OpenVMS Galaxy and reminds us that CPUs can be reassigned as necessary.
The basic concepts of OpenVMS Galaxy can best be described with a picture. On the screen, the large outer rectangle illustrates a single computer that is configured as an OpenVMS Galaxy platform. In our example, we are assuming the computer is an AlphaServer 8400. We have three separate and independent instances of OpenVMS, Version 7.2 of course, running in the same computer.
We use the term “instances” because we have not clustered them together, yet! It’s not until they are in a cluster, either internally within this computer, or connected to an external cluster, that we would refer to the individual instances as “nodes”.
Each instance has its own dedicated “private” memory, but there is only one contiguous memory component in our system. We have the ability to dedicate sections of memory to each operating system and then we use the remaining memory as “shared memory” that all the instances can utilize. We can use shared memory as a cluster interconnect within the system box and achieve orders of magnitude of performance improvement.
*
Application
Application
Application
Application
Application
Application
Application
Adaptive Partitioned Multi-Processing (APMP) A new model of computing in which multiple instances of operating systems execute cooperatively in a single computer. With APMP, physical resources such as CPUs, system memory and I/O are partitioned into multiple instances of operating systems. In our example on the screen, we are illustrating three software partitions with an independent instance of OpenVMS running in each partition. This computing environment can be dynamically adapted to changing application needs.
Galaxy Software Architecture The complementary operating system software that leverages Adaptive Partitioned Multi-Processing (APMP) capabilities. OpenVMS Galaxy provides the software structure and operational components in OpenVMS Alpha Version 7.2 that exploit the APMP computing model.
*
Instance A
Instance C
Instance B
“Shared Nothing” Computing with ability to reassign CPUs from one instance to another
Instance A Private Memory
Instance C Private Memory
Instance B Private Memory
I/O
I/O
I/O
Let’s take a look at how you might apply a “Shared Nothing” computing model in your OpenVMS Galaxy. The three instances of OpenVMS shown here are completely independent of each other and are only connected through networking; just as they might be if they were in three separate system cabinets at opposite ends of your data center. The white outline is symbolic of the fact that we have all three instances running simultaneously in a single computer - an AlphaServer 8400 system, for example.
Through software partitioning, we have allocated all of the available memory into “private memory” for each instance of the operating system. That’s the bottom bar on the screen and notice how it is segmented by dotted lines… The dotted lines indicate that the allocations were done by software and can be reconfigured if necessary. Each instance of OpenVMS in this drawing also has its own set of CPUs and an appropriate amount of I/O resources assigned to it. This configuration simply allows you to take advantage of consolidation by placing the instances in a smaller footprint area, consuming less power than three separate systems, and, perhaps, using newer advances in chip technology for greater speed. Each instance of the operating system can be optimally “tuned” for the workload of each computing environment so you can make maximum use of your available resources. Another advantage that this configuration offers is the ability to reassign CPUs from one instance of the operating system to another to meet the needs of your peak workload demands. More on that subject a little later.
Because you have three separate and independent instances of the operating system running simultaneously, you can achieve greater availability within the computer system than if only one copy of OpenVMS were running; if one instance of the operating system fails, the other two remain operational. Remember, for fault tolerance and disaster tolerance, you still need two systems.
*
Inter-Instance Communication to Manage System Resources
“Shared Partial” Computing with ability to reassign CPUs from one instance to another and each instance has access to shared memory
I/O
I/O
I/O
The next computing model that you could choose to implement is the “shared partial” computing environment. The difference in the drawings is that you now have a much larger memory component in this view of the system. A portion of system memory is designated as “shared memory” that each instance of the operating system can access. We have not clustered the instances together, not yet!
Code and data for the operating systems, as was the case for the shared nothing computing model, is contained in the “Private Memory” components of the system for the independent operations of each instance of OpenVMS. However, only data that is shared by your applications in each instance of OpenVMS is stored in shared memory.
*
Inter-Instance Communication to Manage System Resources
“Shared Everything” Computing with ability to reassign CPUs, shared memory, and all the attributes of OpenVMS Clusters in a single system
I/O
I/O
I/O
So now, let’s cluster it all together and take advantage of the full strength the availability and scalability features of OpenVMS Clusters. We have basically the same drawing her but now we are clustering each of the instances together and with an existing cluster in your data center. Remember, you could choose to leave one instance as a stand-alone shared nothing operation by clustering only the desired instances - internally or externally to suit your needs. And, look at the shared memory component on this slide. Through OpenVMS Galaxy software, you can utilize shared memory as the internal cluster interconnect. With Memory Channel you transfer messages between nodes in a cluster at 5 usec per transfer. With a shared memory interconnect, you transfer at nanosecond rates giving you a magnitude of performance improvement for cluster aware applications without making any change to the applications.
Each instance can also share a region of memory with Galaxy-wide Global Sections to provide greater flexibility and performance for applications and operating system use. In the future we will be putting things like the Distributed Lock Manager and the File System Cache in shared memory, too, for even more efficiency and overall performance improvement.
*
Shared Memory
I/O
I/O
I/O
We’ve talked about the “Partitioned” part of Adaptive Partitioned Multiprocessing. Now, let’s talk about why it’s “Adaptive”. Let’s assume that the middle instance in this illustration is the one that runs your primary business application; say, your order entry system. Wouldn’t it be nice if you could add CPUs to that system whenever it was under duress due to increased workload requirements? That could mean increased revenues! You probably already know what it feels like to experience one of these conditions in today’s environment… You can’t keep up with demand, your pager is constantly going off and, well, you get the picture.
In an OpenVMS Galaxy platform, you can dynamically move system resources like CPUs in one of four ways:
By clicking on an item and dragging it to another instance with a mouse
By using DCL commands to reassign resources.
By using the API for managing system resources in batch jobs
Or, by using the “Galaxy Configuration Utility” to view and control the OpenVMS Galaxy environment. You can even create “templates” of the desired configuration that can be used to automatically reconfigure your OpenVMS Galaxy based on business rules or threshold level criteria.
You can move the resources back to their original instances when you have addressed the peak workload requirement and need them elsewhere.
*
System parameter GALAXY set to 1
System boots as single-instance OpenVMS Galaxy complete with “shared memory”
It is not a simulator: it is the real code
Allows OpenVMS Galaxy application development and testing
68
Compatibility
No software changes are needed to run in an OpenVMS Galaxy instance
Existing command procedures run unchanged
Existing applications run unchanged
upgrade software versions
*
Scalability
multiple instances can make better use of the machine’s resources
CPUs - distribute the SMP overhead
I/O - distribute the interrupt processing
*
CPUs
management requirements
floor space
AlphaServer 8400 (3 instances), 8200 (2), 4100 (2)
Reassignment of CPUs (a.k.a. migration)
GUI for configuration management
Cluster interconnect over shared memory
Cluster instances with non-Galaxy systems
APIs: shared memory global sections, locking for synch, CPU management, event notification, configuration info
Single-instance OpenVMS Galaxy on any Alpha system
OpenVMS Galaxy Guide
AlphaServer 8400
AlphaServer 8200
AlphaServer 4100
We announced OpenVMS Galaxy with support on the AlphaServer 8400, AlphaServer 8200, and AlphaServer 4100 platforms. OpenVMS Galaxy running on an AlphaServer 8400 will support three instances of the operating system. AlphaServer 8200 and AlphaServer 4100 systems support two instances.
While the Galaxy Software Architecture on OpenVMS was designed with future AlphaServers in mind, all three of these existing platforms can take advantage of the flexibility and functionality of OpenVMS Galaxy TODAY.
*
Continued Enhancements to
Mid-Range Server Family
Now
This chart shows the evolution of our Alpha chip technology. No, DIGITAL did not sell Alpha to Intel. We sold the fabrication plant and process and now have one of the biggest chip manafacturers in the world as our supplier. We retained all engineering and the technology for the Alpha chip and dramatically reduced our manufacturing costs. Incidently, one of the results of the deal with Intel is that we will receive the newer Alpha chips almost two years ahead of schedule.
Long term availability of the Alpha chip (and, thus for OpenVMS) because the agreement with Intel is a long term commitment to the availability of Alpha chips and from Digital/Compaql, Alpha systems for OpenVMS customers.
Fits with OpenVMS focus on being best server platform - Alpha provides scalability and performance for OpenVMS to excel
What about applications? - the Affinity strategy is the way to ensure new applications on OpenVMS - combining strengths of OpenVMS with Windows NT. This is the track we have been on for close to 3 years now. The Intel settlement did not affect this.
*
Up to 32 CPUs
Up to 8 CPUs
Up to 32GB memory
Up to 16 CPUs
Common
Components
Enterprise Apps
OpenVMS Galaxy will run on a future AlphaServer product designed to be modular and very scalable.
Common components to choose from in building your configuration
*
OpenVMS Galculator
*
Which means:
One OpenVMS Base Operating System License required (BAU)
One SMP Extension License for each CPU after the first (BAU)
One OpenVMS Galaxy License for each CPU
No change to how Compaq layered products are licensed
One capacity license per system (BAU)
One user license per use required (BAU)
So to create an OpenVMS Galaxy on an existing system:
Just add one OpenVMS Galaxy license for each CPU
Simple…
NEW
3 OpenVMS Cluster Licenses 1
7 SMP Extension Licenses 9
OpenVMS Galaxy Licenses 10
10 CPU’s 10
3 AlphaServer 8400 systems 1
Galaxy Software Architecture
QL-66XAA-3B Galaxy OpenVMS 1 CPU license $4,500
QL-66XAA-3C Galaxy OpenVMS 2 CPU license $9,000
QL-66XAA-3D Galaxy OpenVMS 4 CPU license $18,000
QL-66XAA-3E Galaxy OpenVMS 8 CPU license $36,000
Economic…
ISS System Cost
VMS Cluster Software
39% Lower ISS Costs
Let’s take a look at the cost implications of implementing OpenVMS Galaxy…
Assume that you have an opportunity to add three nodes in an existing, multi-node OpenVMS Cluster. You can add three separate AlphaServer 8400’s with 3 or 4 CPUs each to the cluster or you could add one AlphaServer 8400 with 10 CPUs, running OpenVMS Galaxy. ( REMEMBER that we do NOT RECOMMEND replacing a three node cluster with a single system running OpenVMS Galaxy. No single system can provide the availability features of separate physical nodes…) So, suppose we choose to add three new nodes in a single system running Galaxy.
This cost comparison includes the cost of acquiring the hardware, operating system software, clustering licenses, etc.
This simple example shows that a 39% savings is possible while meeting the expansion requirements that would have necessitated acquiring three separate systems. This is real cost-of-ownership advantage. And, remember, the three operating systems in the OpenVMS Galaxy platform can share CPU resources to address peak workload demands and use shared memory as an internal cluster interconnect for significant performance improvements.
Customers asked us to keep the licensing simple. The licensing structure for OpenVMS Galaxy is quite simple and very competitive. You buy a single system license of OpenVMS Version 7.2 and, similar to SMP, there is a Galaxy adder per CPU that allows you to install multiple copies of OpenVMS, reassign CPUs. Etc. The Galaxy license is $4500 per CPU.
You license by “Galaxy System” not by each instance which can save you a great deal of money. Only one base operating system license is required. One SMP extension license is required for each CPU after the first (business as usual). There is no change to how Compaq layered products are licensed… one capacity license per system(business as usual).
*
OpenVMS Galaxy Future Directions
Support OpenVMS Galaxy on new AlphaServer platforms and new hardware features when introduced
Insure OpenVMS Galaxy will Scale as the size of the OpenVMS AlphaServer systems increase
*
CPU Hot Swap
LAN over shared memory
RAMdisk in shared memory
Distributed Lock Manager data in shared memory
More Instances
Database servers
Stock Exchanges handling unexpected trading volumes - revenue opportunities
Unanticipated Telesales Order Volumes in a retail operation - revenue opportunities
Call Center Operations handling sudden demands for support - customer satisfaction
Hospital Emergency Admission Systems responding to unforeseeable events - saving lives
Here are just a few examples of how we think its features can benefit our customers: Assume that you are running a three instance operation on an AlphaServer 8400 and the middle instance runs your business critical application..
STOCK EXCHANGE : Imagine you are running a stock exchange and normal trading hours are from 9:00am until 4:00pm Monday through Friday. It’s Monday morning at about 9:30 and trading is light. Some major news breaks about a new drug that the ABC company has just gotten approval on from the FDA for a cure for cancer that comes in pill form and has no side effects. Did I mention that the ABC company just went public last week and is now on your exchange? By 11:00am the four CPUs in Instance B can’t keep up any longer with the volume. If you didn’t have OpenVMS Galaxy, you’d start losing orders as your competition met the need from the trading floor. You are losing revenue. WITH OpenVMS Galaxy, you simply reassign CPUs from where they aren’t immediately needed, like mail and messaging, to where they are needed… like taking orders from the trading floor, to keep your revenue stream flowing and to retain customer satisfaction.
TELESALES : Similar scenario… You manufacture “Beanie Babies” and every kid in the world is hounding their parents to get them. Then, one day your marketing director says: “Hey, let’s ‘retire’ these puppies to create an after-market for our product. We can publish a directory of Beanie Babies and include an 800# for people to call to order the product…” Well, you get the picture. Call volumes go out of sight and you eventually need to reassign CPUs to meet demand.
CALL CENTER : Same story - just a different audience. Suppose that you an operating system for PC’s that used an almost universally accepted graphical user interface and you just released a new version. Try as you might, each new version has a few ’bugs’ that you didn’t eliminate. It sells like lemonade on a hot afternoon and suddenly, out of no where, people start calling your support line to get help…
*
OpenVMS Alpha Galaxy Guide
Describes how to create, manage, and use an OpenVMS Galaxy computing environment
See http://www.openvms.digital.com for updates: