HP OpenVMS Systems

The OpenVMS Cluster technology provides unique features in the standard distribution of the operating system. One can very easily create highly available, highly scalable, and highly secure configurations.

This article shows how to set up an electronic mail system to meet the multifarious needs of companies, starting with small business and ending in typical enterprise solutions.

While knowledge of OpenVMS is a plus, this article's intention points to a broad audience.

The reading of Keith Parris's article, Using OpenVMS Clusters for Disaster Tolerance (http://h71000.www7.hp.com/openvms/journal/v1/disastertol.htm), is a must for a deeper understanding of the capabilities of OpenVMS.

If you're not familiar with the IP world, you'll find a very comprehensive introduction in TCP/IP Services for OpenVMS Concepts and Planning (http://h71000.www7.hp.com/doc/73FINAL/6523/6523pro.html).

A good, hands-on practice book, Linux and OpenVMS Interoperability, by John Robert Wisniewski, is available from Digital Press.

Electronic Mail has changed to one of the most important forms of communication. Everyone who had to turn down using email half a day did experience this the hard way.

Most smaller email server installations do meet the need of their operators, but with ascending demands even the smallest risk has to be avoided.

To analyze your needs you can use a matrix of the possible failures to your setup and the available counter measures. Table 1 shows possible failures and counter measures.

Many more failures are possible; the mileage of your experience shows it.

Many vendors do provide counter measures mentioned above, but many of them are very costly and often you have to do a complete redesign combined with a major migration project to scale up your environment.

The IP protocol suite has a couple of services. The services needed for an email server are:

SMTP (Simple Mail Transfer Protocol)

Usually tied to the port 25 of a given IP host this protocol is the core for most of all mail transfers. Being created in the "dark ages" of electronic communication, people suffer under the design flaws made in the past. The most "popular" suffering is called SPAM.

Only a few commands are needed to create an email (to illustrate the use of SMTP):

VMAL06 $ telnet /port=25 vmcl02.progis.net
%TELNET-I-TRYING, Trying ... 194.49.54.3
%TELNET-I-SESSION, Session 01, host vmcl02.progis.de, port 25
220 vmal06.progis.de V5.3-18E, OpenVMS V7.3 Alpha ready at Sun, 
11 May 2003 18:03:09 +0200 (MET DST) 
hello
250 vmal06.progis.de Hello vmcl02, pleased to meet you, friend
mail from:afassl@progis.net
250 ... Sender OK
rcpt to:afassl@progis.net
250 ... Recipient OK
data
354 Start mail input; end with .
 

Short Message
.
250 OK
quit
221 vmal06.progis.de Service closing transmission channel
%TELNET-S-REMCLOSED, Remote connection closed
-TELNET-I-SESSION, Session 01, host vmcl02.progis.de, port 25

Due to this easiness, SMTP had to be extended many times to fight misuse.

Be very careful while setting up an SMTP service attached to the internet - an improper configuration will make your (or your company's) mail server to another SPAM provider. There are many automatic robots scanning around to find active SMTP-ports and probing them to determine their usability for spammers' needs.

Spammers are very creative in their work. A new way observed recently uses an improper proxy configuration of a web server to use a local web server as a relay to a local mail server. The local mail server will accept mail this way because it has been identified the local web server as a trusted source.

The "guest" will leave marks like this:

      64.70.45.253 - - [13/Apr/2003:07:47:43 +0200] "
      CONNECT 64.12.138.89:25 HTTP/1.0" 200 8959 "-" "-"

This is just an example to remind you - NEVER believe your system (even if it's OpenVMS) is 100% secure.

Keep in mind - OpenVMS engineering uses a very secure-wise approach while designing a new piece of software. When using IP based protocols it always implies inheriting security problems.

A more detailed discussion about this topic you'll find in the previous mentioned book "Linux & OpenVMS Interoperability".

Read more about SMTP on OpenVMS, see HP TCP/IP Services for OpenVMS Management (http://h71000.www7.hp.com/doc/73final/6526/6526pro_030.html#smtp_chap)

If you need more features and a very extensive solution, I'll recommend Madgoat Software's MX package. It isn't very expensive; more information can be found at:

http://www.madgoat.com/mx053.html

Via POP3, Email clients connect to a server supporting this protocol on port 110. The Emails are downloaded to the client and can optionally be deleted on the server after download. Usually POP3 is used for clients who are not online all the time.

Read more about POP3 on OpenVMS, see the HP TCP/IP Services for OpenVMS Management manual:

http://h71000.www7.hp.com/doc/732final/6526/6526pro_041.html#pop_chap

IMAP is the most sophisticated non-proprietary Email protocol. IMAP4 (using port 143) is a client/server application offering lots of features to govern Email. The protocol has been implemented in TCP/IP-Services for OpenVMS.

Read more about IMAP4 on OpenVMS:

http://h71000.www7.hp.com/doc/732final/6526/6526pro_043.html

TCP/IP-Services Version 5.4 supports Version 9.2.1 of the BIND protocol.

Read more about DNS Load Balancing on OpenVMS, see "Using DNS to Balance Work Load" in the HP TCP/IP Services for OpenVMS Management manual:

http://h71000.www7.hp.com/doc/732final/6526/6526pro_016.html

• Most attacks are done by insiders.
• Most successful attacks are using (unknown) flaws within the application (buffer overflow e.g.)

In other words - it is verisimilar a firewall is defenseless. You never are discharged from security liabilities just by setting up a firewall. Actually a good secure application server without a firewall is even superior to an unsecured application server protected by a perfect firewall.

With a simple accounting/summary you'll see, for example, the trails of the attempts to misuse an ftp server (users like: admin, ftproot, informix, linux, lizdy, oracle, pwrchute, rethat, suese, sybase, win2000,etc.)

Single node

Figure 1: Single Node Configuration

To increase availability, one can configure Volume Shadowing for the system and the data disks. This will minimize the risk of failing disks. For more information, see HP OpenVMS Volume Shadowing,

http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/aa-pvxmj-te.HTML

The configuration consists of a simple OpenVMS installation using a plain SMTP/IMAP4/POP3 setup.

Dual Node

A dual node configuration will reduce the risk of a failing system.

Figure 2: Dual Node Configuration

The configuration uses OpenVMS Cluster Technology, but you have to consider some additional requirements.

Cluster Shared Environment

Most resources can be shared in an OpenVMS Cluster environment. For more information, see "Preparing a Shared Environment" in HP OpenVMS Cluster Systems,

http://h71000.www7.hp.com/doc/731FINAL/4477/4477pro_006.html#startup_ch

This must be done for all user data.

Quorum Disk

To ensure the clusters integrity, especially in a small cluster setup, you have to configure a quorum disk. For more information, see "OpenVMS Cluster Concepts" in HP OpenVMS Cluster Systems, (http://h71000.www7.hp.com/doc/731FINAL/4477/4477pro_002.html#connection_management)

The quorum disk must be accessible for both members directly. Reliable solutions are based on HSx-controller technology with the corresponding interface cards in the nodes. Please never use unsupported configurations. The components have a higher price with a reason. If you're lucky, it will work. If not, no one will (and can) help you. Don't think about standards when talking about SCSI or Fibre Channel, there are so many proprietary enhancements. This is unavoidable to implement the features customers want like improved monitoring, fault detection, etc. The standards don't include those requirements, so every company has to develop and verify their own supported configuration for a comparable small market. This means lower trade volumes, higher prices.

Configuration of the IP Services

http://h71000.www7.hp.com/doc/73final/6526/6526pro_008.html#config_cluster

In this small configuration a simple cluster IP-address should be sufficient.

Both nodes have a node-specific IP-address and a cluster-wide IP-address:

VMAL06 $ mc sysman
SYSMAN> set env/clus
SYSMAN> do tcpip show inter/clus
%SYSMAN-I-OUTPUT, command execution on node VMAL05
                                                           Packets
Interface   IP_Addr         Network mask          Receive          Send     MTU
 
 LO0        127.0.0.1       255.0.0.0                 107           107    4096
 WE0        194.49.54.1     255.255.255.0          324377        203105    1500
   Cluster  194.49.54.3     255.255.255.0    
 
%SYSMAN-I-OUTPUT, command execution on node VMAL06
                                                           Packets
Interface   IP_Addr         Network mask          Receive          Send     MTU
 
 LO0        127.0.0.1       255.0.0.0                2003          2003    4096
 WE2        194.49.54.2     255.255.255.0         1210418        988863    1500
   Cluster  194.49.54.3     255.255.255.0   Impersonator

If a client program connects to a cluster address, it will get typically (due to certain limitations in the implementation) only one node.

At the latest from this stage on OpenVMS will show it's power. You can take over the complete configuration of the single node solution as it is and you only need to move it in a cluster shared directory.

A single line in your SMTP Startup (for the TCPIP Services SMTP)

$ DEFINE/SYSTEM TCPIP$SMTP_COMMON cluster_device:<clusterdir>

represents the major changes to your configuration.

Multi Node

Figure 3: Multi Node Configuration

To eliminate this bottleneck, you have to choose the next complex solution.

To be honest, this is a setup needing a very careful engineering, but it is possible with justifiable effort. The most expensive part of this configuration are fibre channel links that have to configured, providing possible line lengths up to 100 kilometers per link, using single-mode fiber and up to 600 kilometers per link with FC/ATM links.

And - most important - you don't need to reengineer your previous setup - you can use all the setup, all the user data, all the files without any changes.

The former Netscape Server development had a customer oriented stress test called Mstone.

Mstone is a multi-protocol stress and performance measurement tool. Mstone can test multiple protocols simultaneously and measures the performance of every transaction. The performance can be graphed throughout the duration of the test.

Where To Get Mstone

Surf to: http://www.mozilla.org/projects/mstone/

Supported Operation Systems

Installation

The easieast way to install mstone is to use a linux box. In a later step we will provide a OpenVMS port of mstone.

Setting CVSROOT

$ CVSROOT=":pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot"
$ export CVSROOT

The password for user anonymous is anonymous.

Getting the Source

$ cvs co mozilla/mstone 
cvs server: Updating mozilla/mstone
U mozilla/mstone/Building 

$ cd mozilla/mstone
$ gmake rpackage

You should now have a complete runnable tree under a platform-specific directory under build/package.

Initial Configuration

The machine starting the test may also be a client. For accurate results, clients should not be run on the test mailserver machine (or its directory server). If all the client machines are not running the same operating system version, see "Configuring Client Machines" below to configure for different OSes.

Setup only configures the most important parameters. If you have more advanced needs, edit conf/general.wld appropriately.

Run "mstone setup". It will now push the necessary files to each client machine. If there are problems (i.e. with rsh permissions), fix them and re-run "mstone setup" until everything works.

Install Test Accounts

$ ! DCL-Script to generate MSTONE Test-Accounts
$ !
$ !
$ ! Start User Number
$ NUM=1
$ ! Start Group
$ START_GROUP=%o4000*%o200000
$ loop:
$ ! Create an username based on num
$ USERNAME="MST_''num'"
$ ! Calculate the UIC
$ uic = f$fao("!%I",START_GROUP + NUM)
$ write sys$output "Creating User : ''USERNAME'"
$ mc authorize add /UIC='uic' 'USERNAME'/owner=mstone/account=MBench/ -
  dev=$100$dka0:/dir=[mstone.accounts.'username']
$ create/dir/owner='username' $100$dka0:[mstone.accounts.'username']
$ num=num+1
$ if num.lt.100 then goto loop
$ exit

And with this one you can dump them

$ ! DCL-Script to remove MSTONE Test-Accounts
$ !
$ !
$ ! Start User Number
$ NUM=1
$ ! Start Group
$ START_GROUP=%o4000*%o200000
$ loop:
$ ! Create an username based on num
$  USERNAME="MST_''num'"
$ ! Calculate the UIC
$ uic = f$fao("!%I",START_GROUP + NUM)
$ write sys$output "del User : ''USERNAME'"
$ mc authorize rem  'USERNAME'
$ num=num+1
$ if num.lt.100 then goto loop
$ exit

If you want to, you can do some more programming to be more flexible with your test setup, for the start this will be enough.

mstone smtp -t 30s

The script will tell you how many processes and threads it is running on each system and where errors are logged. At the end of the test, it will print out a URL for the test results and an indication of the size of the errorlog file (stderr).

The results of the mstone run will display statistics for each protocol that was tested. The results are presented in both a HTML web page and a text file. The text file is simple and uniform, while the web page is more user readable. The web page has links to the test configuration files, error log, and the text version.

What you have to watch:

• TCPIP-Ressources like per process memory
• IO-Saturation
• CPU-Load

You can use the basic tools like MONITOR, switching over to more sophisticated tools like the „Availability Manager" or for more professional (but costly) analysis use products like CAs performance advisor (formerly known as Polycenter Performance Advisor). The newer (and free) ECP (Enterprise Capacity Planner) should be worth a look as well.

All switches can be overridden on the command line to facilitate easier testing. The exact configuration (include command line overrides) is stored with the results from each test.

Use "mstone cleanup" to remove the files created by "mstone setup". After the test is finished, the directories under "tmp/" can be compressed or deleted to save space. All the information about a test run is stored in the "results/" directories.

The total number of processes and threads that can be supported on a client is dependent on the number of commands in the test, the OS, and available memory. Check the stderr log for messages about not being able to create processes or threads. Check on the client machines during the test and make sure they aren't running out of CPU. The UNIX programs "top" and "vmstat" are good for this. If the client CPU is more than 75% busy, use more machines. Also watch out for network saturation. You may have to use machines with separate networks to the server to reach full server load.

• Easy to design
• Easy to implement
• Easy to maintain

If you start your configuration with the smallest cluster configuration, the biggest advantage you'll get is an environment, that will have no down time, especially for:

• OS Upgrades
• HW-Upgrade of single nodes
• Adding additional nodes
• Doing site movements

These are the great demands companies have on IT solutions. OpenVMS meets the demands, and more ...

This configuration can be used for many other IP-based services.

To name only a few of them:

• NTP (for high reliable time stamps)
• NFS (as a 100% available UNIX file server)
• SMB (as a 100% available windows file server)

ProGIS Software & Beratung
Dipl.Ing. Andreas Fassl
Spichernstraβe 59
50672 Köln
Deutschland

http://www.progis.de

mailto:afassl@progis.de