openvms system management a different perspective by andy park truebit b.v
TRANSCRIPT
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.
