openvms system management a different perspective by andy park truebit b.v

OpenVMS System Management

A different perspective by

Andy Park

TrueBit b.v.

Andy Park

Daily life of a system manager?

• Installing some hardware

• Installing some software

• Adding a user

• Doing a backup

• Starting an application

• Booting a system

• Checking the network

Andy Park

There is more to it than that!

• Sorting out incidents, and problems.

• Making changes.

• Repetitive daily tasks.

• Writing scripts to aid with repetitive tasks.

• Department meetings.

• Etc...

Andy Park

But most of the time!

• A large proportion of the time of system managers goes into:– either doing repetitive daily tasks,– or maintaining scripts to do repetitive daily tasks.

• Usually each system has its own scripts.

Andy Park

But how many systems?

• Just one?

• Two perhaps?

• Ten?

• Hundreds???

Andy Park

Are you organized?

• Are the scripts the same on all systems?– You mean you have 10’s of procedures doing

the same thing!

• What do you do when you get another system?

• What do you do when an application moves from one system to another?

Andy Park

Get organized!

• Manage all systems as a whole, not each system individually.

• Scripts should be able to run on any system without any modification.

Andy Park

Create flexible scripts

• No embedded data.

• Maintain the environment, on exit:– Reset privileges,– Reset messages,– Reset defaults.

• Keep on top of errors.

• Allow for different modes of operation.

Andy Park

Isolate the scripts

• Don’t keep scripts in user directories.– Users come and go.

• Put them on a separate (logical) disk.– MANAGEMENT_DISK:

• And those that must be in SYS$MANGER?– I’ll come back on that.

Andy Park

Standardize scripts

• Create a number of templates to use for making scripts, which include for example:– An introduction. (date, description, changes, etc.)– Code to save current environment.– Some space for the real work.– Code for error handling.– Code to restore saved environment.

Andy Park

Management layers

• Are you aware of the ICT management layers?– User Management– Application Management– Data Management– System Management– Network Management

• If not, that’s a different presentation.

Andy Park

Make top level directories to match

• [USER]

• [APPLICATION]

• [DATA]

• [SYSTEM]

• [NETWORK]

Andy Park

Subdivide layers

• Each management layer involves many tasks for example:– User account management– Mail management– Backup– System startup– Check network counters

Andy Park

Create products

• Group together the scripts for each function.

• Create products (or packages)

• For example– [USER.ACCOUNT_MANAGEMENT]

• May contain:– add_user, remove_user, modify_user ...

Andy Park

You modify scripts on??

• Production system – Your kidding me!

• Test System– Surely not!

• Development system– Getting better but...

Andy Park

Master Node

• Chose one system as “master node”.

• Keep your templates there.

• Make all changes to scripts there.

• It could be your development system.

• But its better if its a separate system.

Andy Park

And distribution then?

• Done with:– UPDATE– BACKOUT– CLEAN

Andy Park

UPDATE

• Creates [.OLD] sub-directory.

• Moves current version of product to [.OLD].

• Copies product from master node to this node.

• Executes product install procedure to:– Put files is special places like sys$manager,– (Re-) start batch jobs,– Do what needs to be done.

Andy Park

Note:

• All of the current product is moved to [.OLD]

• Therefor:– Keep “permanent” files in subdirectories:

› [.LOG]

› [.DAT]

› [.HISTORY]

› [.XYZ]

Andy Park

BACKOUT

• Deletes current product.

• Moves [.OLD] back to current.

• Executes product install procedure.

Andy Park

CLEAN

• Delete contents of [.OLD].

Andy Park

DIRTY

• Only our minds?

Andy Park

Also needed:

• Product.VERSION

• Product.RELEASE_NOTES

• Product.DOCUMENTATION

Andy Park

Clusters

• In a cluster only one management_disk:.

• UPDATE gets new version.

• UPDATE runs product install on all nodes.

Andy Park

On all nodes?

• But I only need it to run on one node in the cluster!

• For that matter, just specific systems out of all the systems we have!

• Now we come back to how to control the scripts.

Andy Park

Data for the scripts

• Scripts must remain identical on all nodes.

• Use data to determine what they should do.

• An easy source of data is logical names.

Andy Park

Logical names

• You can put a lot of information in logical names.

• You have fast access (they are in memory).

• Easily accessed by scripts and programs.

• But you will need a lot of them.

Andy Park

Separate table

• Create a separate logical name table:– Ensures you can not interfere with others.– No one else can interfere with you.

• I call it the “FINGER PRINT” for a node.– Identifies exactly what the system is supposed

to do, when, how….

Andy Park

An example

$ ASSIGN/TABLE=FPT 1,”00:30:00”,-

”VOLUME_REBUILD,SHOW_USED” -NODE_HAS_DISK_CHECK

1 = Disk check runs on this node

“00:30:00” = early in the morning

and of all the functions it can do just do the volume rebuild and show used disk space

Andy Park

Not only your product info

• For each product you create there will be an entry in the table.

• Also for each manageable object there can be an entry:– Could be software from others.– Could be hardware.– Could be people.

Andy Park

Software

• You need to know which software packages are on each system.– Someone will have to start them when the

system boots.– The products you make will interact with

layered products and applications from other sources.

Andy Park

Hardware

• Which disks do I have?– they need mounting, backup-ing, checking,

defragmenting,

• Which tapes do I have?– Are they used by backup?

• Any special I/O devices?

• Even something as trivial as the system serial number can be in the finger print.

Andy Park

People

• Mail account of system manager

• “When you got a problem, who do you call?”

Andy Park

How do you fill the table?

• Several possibilities:– Node specific command procedure.– Procedure that processes node specific data file.

• I make it using:– Site wide command procedure (sets defaults).– Then call cluster wide procedure.– Then call node specific procedure.

Andy Park

When do you make it?

• As soon as possible.

• There are several call-outs in the startup of OpenVMS to site specific procedures.– SYCONFIG is currently the first.– Use it to set up your finger print i.e. your

configuration.

Andy Park

Which means:

• One of your first products will be– [SYSTEM.STARTUP]

• Containing:– the procedures to make the fingerprints– the site specific startup procedures which:

› use the finger print to start the system.

Andy Park

Still with me?

• Standard directory structure.

• Standard style scripts. (Templates)

• Standard “products” created on master node.– Distributed using product “UPDATE”

• Each node has a finger print specifying its role in the world.– Distributed in product “STARTUP”

Andy Park

One job less for the system manager

• Did you notice that log files were in [.LOG]?

• It is now easy to make a product that scans management_disk:[*.*.log]*.log for all of those “-F-” ’s and “-E-” ’s, and mail the results back to the system manager.

Andy Park

Still with me?

• You now have standard error checking.

Andy Park

Scheduling

• Did you notice that there were time specifications in the finger print?

• Your next project is to make a simple scheduler product to run the jobs of all the other products.

Andy Park

I’m out of breath

• You have a standard environment on all of your systems.– A set of software “products”

• Each system has a finger print which tells the products what they should, or should not, do.

Andy Park

Any Questions?

• The simple ones I’ll answer now.

• The complex ones you can take up with TrueBit.

Andy Park

Thanks for listening!

• A.Park@truebit.nl