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: