ch01.htm

this describes managing multivendor networks

and also offers collaborative computing facilities. The 200 is a somewhat lower-cost,
entry-level product, but also offers the 64-bit computing environment, at speeds
up to 233 MHz. On the high end are the AlphaStation 600 systems, which are the fastest
and most ideal for high-end scientific research projects that involve complex visualization
and calculation.</P>
<P>The AlphaStation 500 (see Figure 2.1) is well-suited for higher-end CAD applications
or memory-intensive and CPU-intensive multimedia projects. The system runs the Alpha
21164 processor at 333, 400, or 500 MHz.
<H3><A NAME="Heading6"></A><FONT COLOR="#000077">Midrange Offerings</FONT></H3>
<P>The PDP-11 line, until it was discontinued, filled the lower end of the spectrum,
if for no other reason than by virtue of being a 16-bit machine. The 32-bit VAX,
on the other hand, was offered in a broad range of models, starting from the diminutive
MicroVAX extending to the mainframe-oriented VAX 9000.</P>
<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch02/02fig01.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/ch02/02fig01.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch02/02fig01.gif"><B>FIG. 2.1</B></A> <I>Digital Equipment Alpha 500 Workstation</I></P>
<P>Both lines shared the dubious honor of using multiple bus designs. The three most
common bus architectures are as follows:

<UL>
	<LI><I>UNIBUS.</I> The architecture used in the original PDP-11 and VAX-11 and at
	the high end of other VAX and PDP offerings.<BR>
	<BR>
	
	<LI><I>Q-Bus.</I> Used in the lower end of both the PDP-11 and VAX lines.<BR>
	<BR>
	
	<LI><I>VAXBI. </I>Unlike the Q-bus and Unibus architectures that were open to third-party
	vendors for the development of controllers and peripherals, the VAXBI is a closed
	architecture. Although this bus structure is specific to the higher end of the VAX
	line, it also supports the older Unibus design. Other buses, including the MASSBUS
	and the XMI and industry-standard VME bus, have also been used by Digital. Presently,
	Digital offers a PCI-VME Adapter for OpenVMS, for workstations and servers running
	OpenVMS Alpha but have the PCI I/O bus. This device bridges Alpha environments to
	the VME bus environment. Of special note is the XMI bus developed for the VAX 9000
	and briefly discussed in the next section.
</UL>

<P>Because of its roots as an interactive multiprocessing system, the PDP-11 supported
a variety of operating systems. The RSX line (RSX-11M, RSX-11M-PLUS, and RSX-11s)
provided multiprocessing capabilities under priority-driven and/or real-time constraints.
In contrast, RT-11 was at the low end, offering multiprocessing in a single-user
environment.</P>
<P>While the PDP-11 maintained a respectable position at Digital until it was discontinued,
the favorite offspring is still the VAX. The first VAX offering was the VAX-11 line,
released in 1977. Whereas the PDP-11 was oriented more to the technical market, the
VAX was suited better for the commercial and business markets. The primary operating
system, VMS (Virtual Memory System), is a multiprocessing, interactive environment
well suited to multi-user business applications. The secondary operating system,
ULTRIX, is Digital's implementation of UNIX for the VAX. A real-time operating system,
VAXELN, is also available (primarily as a migration tool for PDP-11 users).</P>
<P>The VAX product line contains two segments: the Q-Bus MicroVAX line and the VAXBI
line. The MicroVAX line starts with the relatively old MicroVAX I and progresses
to the MicroVAX 2000 (which, unlike other MicroVAX systems, uses its own bus structure);
the MicroVAX II and the MicroVAX 3300, 3400, 3800, and MicroVAX 3900. These machines
are targeted to smaller businesses and departments and are also a bridge from PDP
to VAX technology.</P>
<P>With an eye to replacing the MicroVAX name and line, Digital introduced the VAX
4000 Series in 1990. These machines are positioned between the MicroVAX line and
the low end of the VAX line, and functioned as uniprocessing departmental servers
or high-end CAD workstations. From a performance perspective, the VAX 4000 Series
offers a price/performance ratio that is significantly better than the high end of
the MicroVAX line, while providing performance similar to the low end of the VAX
series. This overlap is part of Digital's strategy to reposition the low end of its
product line with its higher performance offerings.</P>
<P>In the big leagues, VAXBI systems start with the VAX 8200 Series, and then advance
into the 8300, 8500, 8600, 8700, 8800, and 8900 Series. In recent years, Digital
introduced the VAX 6200, 6300, and 6400 Series as the de facto replacements for the
low end of the 8000 Series (the 8200 and 8300). In fact, the 6000 Series was designed
to accommodate the multithreading of online transaction processing (OLTP). Additional
requirements for OLTP are addressed by the VAXft 3000, a fault-tolerant system based
on dual-processor MicroVAX 3000 technology.</P>
<P>At the top of the VAXBI line are the VAX 8600, 8700, 8800, and 8900 Series; the
9000 Series; and VAXclusters. While the high-end models of the older 8000 Series
approached mainframe capabilities, they had some difficulty maintaining fast access
to large capacities of memory and disk storage. These deficiencies were corrected
in the VAX 9000.</P>
<P>Most of the VAX series are upgradable to the newer Alpha AXP architecture, and
capable of running the OpenVMS or Digital UNIX operating systems. The Alpha AXP architecture
afforded a new 64-bit architecture that can directly address up to 1G of real memory.</P>
<P>The AlphaServer 2000 series (see Figure 2.2), based on Digital's new 64-bit RISC
technology, offers highly compact SMP servers with up to four processors; they are
used primarily as departmental or LAN servers. The 2000 series runs the DECchip 21064
CPU at 150MHz, and supports DEC OSF/1 AXP, OpenVMS AXP, and Windows NT. The 3000
Series, running the 21064 CPU at 175MHz, offer extensive memory and storage capabilities,
and is an excellent choice as a server for X Window terminals.</P>
<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch02/02fig02.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/ch02/02fig02.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch02/02fig02.gif"><B>FIG. 2.2</B></A> <I>Digital Equipment AlphaServer Family</I></P>
<P>The 64-bit design of the Alpha AXP architecture provides much more power to the
midrange, as well as added networking capacity and more file storage.
<H3><A NAME="Heading7"></A><FONT COLOR="#000077">Top-End Offerings</FONT></H3>
<P>Announced in 1989, the 64-bit VAX 9000 Series is Digital's best performing system,
offering mainframe-level performance. Using a combination of CISC and RISC technology,
the new processor and bus design (XMI) gave the 9000 a significant increase in data
processing speed. To achieve compatibility with the mainstream midrange machines,
the VAX 9000 also supports the VAXBI bus interface.</P>
<P>In addition to the main CISC/RISC system processor, the VAX 9000 supports specialized
vector processors for parallel operations. The Star Coupler CI interface was enhanced
for direct support of the XMI bus, and the resulting interface, termed <I>CIXCD,</I>
brings higher throughput and new configuration options to VAXclusters. In the most
general sense, the VAX 9000 was designed with one eye on compatibility between VMS
and the existing VAX line, while the other eye focused on optimization and mainframe-class
performance.</P>
<P>The RISC-based AlphaServer 8000 line has the ability to run up to 12 300-MHz 21164
Alpha processors, and combines the benefits of the mainframe with those of an open,
client/server system. It can accommodate a 10-terabyte cluster storage, and is usable
as a high-availability database server or OLTP server. This line includes the 8200,
which is scalable up to six 300 MHz processors, and can run both Digital UNIX and
OpenVMS. The 8200 and 8400 are the high end of the 8000 line, and are the first of
the AlphaServer 8000 series which Digital plans to extend through three generations
of products.</P>
<P>In designing the 8000 series, Digital had several goals, including support for
legacy I/O subsystems and DEC 7000/10000 AXP compatibility. The 8000 series doubles
the performance of the 7000/10000 AXP server line while providing a viable and fairly
straightforward upgrade path. In designing the 8000, Digital's design team conducted
a thorough analysis and performance study of the 7000/10000 systems. After the analysis,
Digital decided that system data bandwidth and memory read latency goals were critical
to their new design.</P>
<P><I>Read latency</I> is the amount of time required for a CPU to read a piece of
data into a register in response to a load instruction. <I>Cache memory</I> is a
common way to minimize read latency. Latency tends to degrade as the number of processors
is increased, and latency will improve as the amount of available bandwidth is increased.
Comparable systems from HP and IBM do not stress low-memory latency in the design
of the RISC System/6000 or the PA-8000 SMP systems. Although the older 7000/10000
AXP systems were comparable to the RS/6000 and PA-8000 in terms of latency, the AlphaServer
8000 was developed with an emphasis on low-memory read latency. The 7000/1000s had
a latency of 560 nanoseconds, comparable to the ratings of the RS/6000 and PA-8000.
On the 8000 platform, however, Digital achieved a read latency of 200 nanoseconds.
In its design of the 8000 series, Digital pinpointed low latency as a major factor
in high system performance.
<H3><A NAME="Heading8"></A><FONT COLOR="#000077">Symmetric Multiprocessing and VMSclustering</FONT></H3>
<P>Previously known as VAXclustering, <I>VMSclustering</I> is executed with Digital's
OpenVMS Cluster Software. The software establishes an integrated OpenVMS environment,
which can be distributed over multiple Alpha and VAX CPUs. VMSclusters can include
both VAX and Alpha CPUs in the same cluster system.</P>
<P>To obtain high performance and greater computing capacity, Digital engineered
two optional processing configurations: <I>symmetric multiprocessing</I> (SMP) and
<I>clustering.</I> Both offer significant processing improvements.</P>
<P>SMP uses multiple processors sharing resources within a single VAX or Alpha AXP
system. The SMP architecture enables the system to break up functions and process
them independently. Thus, a disk access can be handled by one of the processors while
another performs a CPU-intensive calculation. The number of processors available
depends on the base model (note that not all models are capable of being used in
SMP mode).</P>
<P>Although SMP does provide some benefits based on its architecture alone, applications
must be specifically written (rewritten, or <I>DEComposed</I> as Digital calls it)
for the SMP environment. One final advantage of the SMP approach is that it makes
the system more fault-tolerant; if one processor malfunctions, the system can be
restarted and instructed to ignore the faulty processor. While this is far from an
online recovery operation, it sure beats being down until the hardware engineer arrives.</P>
<P>In contrast to SMP, clusters enable multiple systems to share disk storage in
a highly opti-mized manner. Clusters use a common piece of hardware, called a <I>Star</I>
<I>Coupler,</I> to provide a physically common point of contact between the multiple
VAXs or Alpha AXPs and the disk subsystem (see Figure 2.3). A VMScluster system can
contain an unlimited number of star couplers; the number of star couplers connected
to a CPU is limited only by the number of adapters provided by the CPU. A single
Star Coupler can interface multiple systems to one or more Hierarchical Storage Controllers
(HSC) which, in turn, control multiple physical disk drives. The interface between
the computers and the Star Coupler is referred to as the <I>interconnect,</I> a high-speed
link designed for fault tolerance. If there is an interconnect failure, the VMScluster
software will automatically resort to an alternate interconnect. The VMScluster software
will support any combination of these interconnects:</P>
<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch02/02fig03.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/ch02/02fig03.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch02/02fig03.gif"><B>FIG. 2.3</B></A> <I>Sample VAXcluster</I>

<UL>
	<LI>Computer Interconnect (CI)<BR>
	<BR>
	
	<LI>Digital Storage Systems Interconnect (DSSI)<BR>
	<BR>
	
	<LI>Small Computer Storage Interconnect (SCSI)<BR>
	<BR>
	
	<LI>Fiber Distributed Data Interface (FDDI)<BR>
	<BR>
	
	<LI>Ethernet
</UL>

<P>CI and DSSI are special-purpose interconnects, designed for CPUs and subsystems
in the VMSclusters. A maximum of 16 CPUs can be connected to a star coupler; a maximum
of four CPUs can be connected to a DSSI. The SCSI bus is not used for CPU-to-CPU
communications; therefore, CPUs connected to a multihost SCSI bus also require another
interconnect to provide this capability. The purpose of the SCSI bus is to provide
multihost access to SCSI storage devices.</P>
<P>Every aspect of a clustered system has built-in redundancy. And, the hardware-level
design can be enhanced further by doubling (or tripling in some cases) the number
of computers or amount of disk storage required. Overall, this makes for a highly
efficient, highly fault-tolerant hardware architecture. The cluster design provides
a self-contained backup system as well, and is an ideal solution to gradual expansion
because the cluster can be built one system at a time.</P>
<P>However, no degree of hardware tolerance can salvage the data damaged by an application
crashing or running amuck. And because the purpose of a cluster is to provide concurrent
access to a large pool of information, the integrity of that information is of paramount
importance--after all, there is no point in sharing a pool of garbage (unless you're
a goat).</P>
<P>To preserve the integrity of information, clusters can (and usually do) implement
the following safeguards: