| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 99.1 | Chapter 4 draft available for review | SUPER::MORGAN | | Fri Jul 26 1991 14:36 | 15 |
| A draft of the fourth Sysnet III chapter entitled:
Installing VAXcluster Nodes
is available for review in:
SUPER::ES$REVIEW:[SYSNET_III]SYSNETIII_CHAP4.ps
Bonnie
Comments on this chapter:
Pg. 1-29 We are looking for comments on whether the section "Changing Node
Characteristics with CLUSTER_CONFIG.COM" should be removed. The
section is currently 5 pages long.
|
| 99.2 | comments from DC | TEACH::WENDY | | Tue Aug 27 1991 13:05 | 22 |
|
SYSNETIII
Installing VAXcluster Nodes
The inrotuction and objectives are virtually one in the same.
1-17 I wouldnt call this table a summary because we havent looked at
Cluster_config yet. Acyually think about putting this at the end
of the discussion on cluster_config because they will see the menu picks
when we look at the example on running cluster_config.
1-19 good example for adding a satellite node.
1-23 I dont think the quorum disk info fits in here. I would do the CI
example first (1-25) then this stuff seeing as were looking at building
a cluster here. do this when looking at the cluster_config change options
on 1-27.
All the change option examples are good.
I think this module was preety good. Its pretty clear and concise
|
| 99.3 | Capitol Ideas | TEACH::LYNN | | Thu Aug 29 1991 19:17 | 18 |
| SYSNETIII - INSTALLING VAXCLUSTER NODES
CHAPTER 4
Page 10 You make reference to VMS Service Customer.
On the instructor's page could you please tell who
is a VMS Service Customer.
Page 27 Left column has a mistake. Tab over the following:
Set WINDOW_SYSTEM=0.
Overall comments Are you going to include any information for DSSI
configurations? In every cluster class I teach there
are customers with that kind of configuration.
Overall a well written chapter. Thanks!
Lynn White
Washington D.C.
|
| 99.4 | Review Cutoff Date | SUPER::MORGAN | | Thu Sep 19 1991 17:30 | 10 |
|
In order to make the pilot schedule, Monday 9/23/91 will be the
review cutoff date.
Any comments entered after that date will be considered after the
pilot.
Thanks for all of your comments,
Bonnie
|
| 99.5 | Network Items in the Cluster chapter | NWGEDU::RODENBURG | Ed. Services, The Netherlands | Thu Nov 07 1991 07:58 | 41 |
|
After having added my (network-related) comments on the Cluster
chapter, I am going through the revised material.
page 4-11:
Defining Cluster Alias Operations
Great!
One remark/error: in the last example on this page the command
NCP> SET EXECUTOR STATE SHUT
need to be changed into
NCP> SET EXECUTOR STATE OFF
Otherwise in several networkenvironments you can wait for months
before DECnet is down. The audience in this course will not know
what different products are running, using DECnet and keeping
logical links up and running.
page 4-23:
Restoring a Satellite's Network Data
Great!
Perfectly done
Two questions remain:
- after adding a new clustermember, often the object database is newly
created, but the default accounts are set up with wrong passwords in
the DECnet database. Do you need to discuss it here?
In my opinion the students will see it at home, during their own
work. I admit, it is a 'feature'/'unpleasant fact', but isn't it
necessary to talk about?
I propose to add a comment on the instructor page pointing to this
fact, but not to include it into the student course-handout.
- when the command MONITOR CLUSTER is used, the object VPM is used.
Is this info somewhere useful? I would like to add some info on the
instructor page on this subject.
Regards,
Joop
|
| 99.6 | remarks on cluster subjects | NWGEDU::APON | dubito ergo sum | Wed Nov 27 1991 06:53 | 218 |
| Hi,
Being a cluster instructor (amongst other tasks)
I have been asked to give my opinion on the cluster
chapter in sysnet III.
I must admit I have been away from review land a long time
but other tasks have prevented me from doing review work.
** I certainly realize my input is too late for the current
** version of the material, but perhaps it might be of
** use in any future changes to the course.
As input I used chapter 4 and the initial sysnet proposal document.
The original proposal states the following subjects/skills :
- configuring clusters
* where to find information
* adding a node to the cluster
* removing a node from the cluster
However, page 4-4 states far more objectives than just adding a node
and removing a node and finding the documentation.
First of all, to my opinion we should stick to not too difficult
subjects. I don't think we should try to build all types of
clusters, this one chapter simply won't do.
I suggest the contents should be :
* cluster principles (15 min)
- reference to documentation
- why a cluster
- how (general HW and SW options)
CI
DSSI
NI
FDDI
VAXcluster software
- definitions : bootnode, satellite, MSCP-server,HSC,ISE
* cluster integrity (25 min)
- risk of partitioning
- quorum scheme
- startup/shutdown in relation to the quorum scheme
(task oriented : include the IPC routine !)
* CLUSTER_CONFIG.COM and it's impact (15 min)
- description of the procedure in general (the menu options)
- explanation of the most important cluster system parameters
* add a satellite to an existing NI or MI cluster (15 min)
- demonstration CLUSTER_CONFIG to add a satellite
Leave the rest for the cluster manager training.
Why this ? Well, in the cluster manager training it takes 5 days
to give the people a thorough understanding of the cluster
concept and all the influences it has on the daily management
of their systems.
It would be arrogant to think we can do the same flawlessly in
a few hours.
I think at this stage the student should gain PASSIVE knowledge about :
- cluster concepts
- configuration types
- quorum scheme
- how a cluster is built
I think after this chapter the student should BE ABLE TO :
- add a satellite node to an existing NI or MI cluster
- startup/shutdown systems correcty in a cluster environment
- adapt the active quorumscheme correctly, using
* SET CLUSTER/EXPECTED_VOTES
* the IPC routine
So far my didactical issues. In the next part of my reply I'll
try to evaluate the material AS IT IS.
** However, please don't interpret this as my agreement on
** the choice and the amount of topics this
** chapter tries to cover.
************************************************************************
General impression :
* most material lifted straight from the cluster course,
without much adaptation
* lack of synchronization with sysnet I and II
example: startup/shutdown are covered only generally in sysnet I,
where is the task oriented explanation of the relation between
startup/shutdown , the quorum scheme , SET CLUST/EXPECT and
the IPC routine ???
* absolutely far from TASK-ORIENTED. Giving pages full of
CLUSTER_CONFIG listings is NOT what I call task oriented.
(While telling how to solve a state transition induced by a
crash or shutdown action very much is.....)
* a lot of technical terms are used that, as far as I could trace,
have never been (clearly) explained before
As a matter of fact a developer should consider constantly :
- has this been explained before ?
- has the student the right knowledge to grasp the meaning ?
BTW is there a list of
- what terms are covered in eg. sysnet I and II and
- to what extend they are covered
that the developer can lean on ?
* the students will drown in an overflow of information
* most information is technically correct, but could be refrased
in easier terms without loosing the correctness....
(think of foreign students using this book....)
*************************************************************************
remarks per page
4-3 8th bullet : remove members FROM the cluster
4-4 Mentioning so many books discourages people.
Bring priority into the list,
such as :
main manuals : VAXcluster manual
SHOW CLUSTER Utility
further reading : (the rest)
4-6 please explain words before using them :
state transition ?
SCS
Is this task oriented ? NO. Task oriented would be something like:
"If you mount a disk from two different systems (the disk
is connected to two adapters) disk corruption may occur if
updates form both systems are made on the disk without
synchronization. This is called (bold/partitioning).
The vaxcluster software uses a special component, which s
called the (bold/connection manager), to prevent this.
It is loaded at startup time when the system parameter
VAXCLUSTER > 1. This parameter will be set automatically
when you configure the node as a cluster member."
etcetc..
4-7 yes, technically correct, but again nonexplained terms...
4-13..4-17 lifted from cluster course, these are technically ok
4-18 this page should be brought up-to-date
How about this :
--------------------------------------------------------------
Getting the Ethernet address :
1) on a running system
$ RUN SYS$SYSTEM:NCP
NCP> SHOW KNOWN LINES CHAR
2) if other VAXes are on the same Ethernet and at least one
of these nodes has Network logging enabled on the console,
boot the target node via Ethernet and check the network messages on
the other console(s)
(at this point we could supply the NCP commands that are
used to enable NCP logging at the console for MOP service
messages)
3) issue the appropriate console commands for the target system,
for example :
microvax II and VAxstation II
>>> B/100 XQ
Bootfile: READ_ADDR
microvax 2000 and vaxstation 2000
>>> T 50
microvax 3xxx,4xxx,6xxx
>>> SHOW ETHERNET
*****************************************************************
4-19..4-27 technically correct, but too much info
4-28 correct but too complicated
4-35 idem
4-39 is rolling upgrade appropriate ? This is VERY cluster specific,
and certainly not sysnet-like. Besides, why now introduce
IPC, this should have been done much earlier....
Regards,
Fred Apon
|
| 99.7 | It's usable, but clumsy | SOAEDS::TRAYSER | Seniority means a bigger shovel! | Fri Feb 21 1992 08:07 | 108 |
| Interesting chapter. It starts off OK, but then wanders. The IPC stuff
isn't really needed in this course, nor is a rolling upgrade, these
belong in the VAXcluster specialty course (or an appendix). HOWEVER, it
is *MOST* important to get a good DSSI & HSC discussion in here. I teach
the Cluster course and over the last 6-9 month I haven't had a course
where students didn't want DSSI stuff or need to know how to SET HOST to
an HSC or ISE. We need to cover these topics in THIS course, at least
in an appendix!
Yeah, I know this might be covered in the previous course, but I've been
calling my students for next week's course and so far only one of them has
had SysNet I and/or II.
4-5, 4-6 --
This is a real waste of paper. 2 pages of outline that basically
says the same thing as 4-3. We don't need this size of an introduction!
What are we supposed to say here? Please either kill it or at least
compress it to a 1/2 page so I don't feel guilty skipping it.
4-8a --
Nicely written instructor's page. I found it useful and informative.
We need more pages like this throughout the book!
4-12 --
Entire page is rather bad. I can agree with point #1, but #2 leaves out
the most important step of enabling Ethernet communications on all the
CI/DSSI nodes. Without this it will never work. Page needs reworking.
4-13 --
A snap-shot of the first dozen lines of CLUSTER_CONFIG at the bottom of
this page would be a helpful teaching aid. (See page 4-20 to see what these
lines look like.)
4-15, 1st bullet --
According to an engineering lecture I attended, they suggested DSSI enable
Ethernet communications. The VAXcluster software automatically picks the
best transport for its messaging (DSSI in this case). Gotta find that
handout to remember why, but be aware of this 'option' that students might
mention.
last question --
What about a 6000 with both DSSI and HSC connections?
4-17a --
...or when enabling Ethernet Communications for the first time, i.e.
changing a CI cluster to an MI cluster.
4-19 --
This is the first time this picture is shown. I get question on this in
the CluMgt class. Why don't we eliminate the shaded areas entirely?
Having it in only gets annoying questions of "what's this shaded stuff?"
4-21a, 3rd statement --
NOT correct for uVAX II based systems like Lion which we are configuring.
uVAX II do NOT normally try to boot from their Ethernet automatically
unless F.S. has modified the boot ROM.
4-23 --
Example should be consistent and show LION::, BEAR::, etc.
4-27, Top line --
Same word-wrap problem as the VAXcluster Mgr course.
4-29a, 1st bullet --
Important point is that any time you need to run AUTOGEN a reboot will
be required. You do NOT have to use the REBOOT option from AUTOGEN. As
long as AUTOGEN successfully completes the SETPARAMS phase, the work has
been done. A reboot can be done at a more convenient time, as the best
time to run AUTOGEN isn't always the best time to reboot the system. But,
the reboot MUST be done before the changes actually take effect.
4-34 --
This material needs to be done earlier, as it would make a good
introduction. I'll probably introduce this page between 4-13 and 4-14.
4-38 --
Unless you have worked "in the field" some of this may be confusing to
some instructors and maybe some customers. Make sure you read the little
book that comes with the VMS DOC set on licensing, it helps explain many
of these concepts. Especially with our licenses which are UNLIMITED while
the customers have to worry about UNITS and USERS and the like.
4-41, 2nd bullet --
If I recall correctly, when I reboot my satellites after an upgrade, they
AUTOMAGICALLY run AUTOGEN.
4-41 - 4-43 --
It is not obvious here, but should be stated (on the instructor's pages)
that a Rolling upgrade requires 2 system disks -- one to do the upgrade
on and the other for the remaining systems to continue to run from.
In general these pages are rather weak. We either need to remove this
or fatten it up. Either way would be an improvement. If we fatten
it, then a brief scenario of a 3-node CI cluster explaining the
process of making the 2nd disk, booting 1 node from the new disk,
upgrading that disk, make 2nd VAX boot from that disk...get the idea?
4-42, #5 --
I guess you are referring to pages 2-10 - 2-13? If so, mention it in the
instructor pages. However, if you are, this isn't much help. I tried
going back to those pages and 'doing them' after I did page 4-42 stuff
and it really was clear what was still a valid step. Needs to be more
tutorial and explicit on these pages.
On to LATs....
$
|
| 99.8 | Ethernet boots should be auto. | MELKOR::SWIERKOWSKIS | | Mon Mar 09 1992 19:38 | 10 |
| >4-21a, 3rd statement --
> NOT correct for uVAX II based systems like Lion which we are configuring.
> uVAX II do NOT normally try to boot from their Ethernet automatically
> unless F.S. has modified the boot ROM.
>
Hmmmmmmm.....my uVAX II's do in fact boot over the Ethernet automatically when
I take the local system disk off-line (and my hardware guys swear they haven't
made any mod's).
Susan
|
| 99.9 | consistency please | MELKOR::SWIERKOWSKIS | | Mon Mar 09 1992 19:42 | 9 |
| >4-23 --
> Example should be consistent and show LION::, BEAR::, etc.
>
I couldn't agree more. I'm amazed by the number of students who really hate
our lack of consistency. Personally, I prefer lots of different examples
when I'm learning, but I have to defer to the customer on this and they are
quite adamant about it.
Susan
|
| 99.10 | Update...and a correction to my previous note... | SOAEDS::TRAYSER | Seniority means a bigger shovel! | Tue Mar 10 1992 00:35 | 37 |
| OK, since you asked I had to go and look at some old notes of mine...
The MicroVAX was the first VAX to use the sniffer boot. The oldest ROMs
didn't know about Ethernet, but these are *very* rare today. So normally
the system looks for ANY thing that has a file called SYSBOOT.EXE
(TAPEBOOT.EXE on some older ROMS) on devices in this order...
DISKS:
In controller order (A, then B,...)
removable first, fix next
in numeric order
sniffer boot limited to 0-3?
(manual boot limited to single digit unit number)
TAPES
In controller order (A, then B,...)
in numeric order
PROM
ETHERNET
In controller order (A, then B,...)
If ANY of these has a SYSBOOT (in [SYSEXE] on disk) then the search order
is terminated and a boot attempt it made. If you had an old system disk
and deleted the files, but this one remains, the boot will try this disk!
Read between the lines....if a REMOVABLE disk is on controller B, then
the FIXED disk on controller A will be tried first. Otherwise the
removable disk is tried.
Some Field Engineers had a floppy that had a program that pointed to the
preferred boot device -- this is how some of them 'reordered' the boot
process on these systems.
Now, for some reason my tape is tried on my uVAX-II (system V - RA60,
TK50, RA81, RX50, DEQNA) BEFORE the fixed disk is tried. Not sure why,
I'll need to test/research this more.
$
|
| 99.11 | How soon will this course be fixed?? | SOAEDS::TRAYSER | Seniority means a bigger shovel! | Wed Apr 15 1992 23:28 | 57 |
| In the middle of the 2nd teach of this course...
The cluster module leaves too much to the imagination. The tables on
pages 14 through 18 leave too many details uncovered:
"What is the device name of the system disk?"
The right column leads us to believe that the only thing being
changed is the network info for a satellite. In fact, it will
use this info to build a root on this disk. We need to make sure
to put this in the proper boot file later (R3).
"What is the name of the new system root?"
Same problem, same solution. Put this info in the boot file (R5).
"Will the node be a disk server?"
The boot server question isn't too hard, but now we introduce
MSCP_LOAD and MSCP_SERVE_ALL, neither the topic nor the parameters
have been discussed. What is MSCP? What is an MSCPserver? Sorry,
can't tell you -- not enough time.
"Will the node serve HSC or RF series disks?"
Hmmm. No picture to show how these are connected until page 25, and
that one 'shades out' the DSSI part of the cluster. No discussion
of the HSC or DSSI buses, their benefits or configurations. Yes, I
know, some of this was in SN2, but only 3 of my 13 students this week
have take SN2 -- 4 have NEVER taken an official System Manager I
course either! We *MUST* plan on covering basic configurations in
this module.
"What is the value for ALLOCLASS?"
Oops! Say, we haven't really talked about how to decide on whether
to even USE an ALLOCLASS, much less what it is and how it is used.
We need to cover a lot more VAXcluster concepts in this course! The
Students are asking for it! They don't want to know what the answers to the
questions on page 20 and 26 are supposed to be...they want to understand
*HOW* they are to figure out the proper answer for their configurations.
Here it is Wednesday night and I've just finished module 6. No way I'll
be able to finish all the material. We need to leave out the Performance
Stuff (put it back in the VMS Performance Management class) so we can add
the configuration stuff for VAXclusters (and DECnet).
I'm becoming disillusioned with this course. We tried to cram too much
stuff in one course and not cover anything to a reasonable level. After
teaching all the DECnet stuff (plus adding some of my own stuff) the
student asked me, "Is this all? Are we finished with Networks?" Sigh!
$
|
| 99.12 | I'd say it's past time to fix... | MELKOR::SWIERKOWSKIS | | Thu Apr 16 1992 13:02 | 26 |
|
I agree very strongly with Buck's previous note. I am also in the middle
of my second teach of this course. I finished Managing Disks last night
which means I still have Print Forms, Security, Monitoring and Performance
to cover in a day and a half of lecture. My students look gray (literally,
they have the pallor of someone who has pulled an all-nighter).
I put together my own labs for configuring DECnet nodes and VAXclusters so
they have actually been able to do the two builds (unlike the first time I
taught this). However, they are positively overwhelmed.
Now, back to a question I asked a long time ago.... Is the VAXcluster System
Manager class going away? If it is then we need to beef up the VAXcluster
module as Buck indicated. Obviously, since Network Management I is already
gone, the pathetic DECnet module in this course *MUST* be fixed immediately.
I pulled lots of material from the old Net Mgr class to make this week work.
Get rid of the performance module, but put the concepts in an earlier course
(people are teaching it anyway).
This curriculum has been out for 4 months now! Isn't it past time to
evaluate and fix!?
Susan
|
| 99.13 | Cluster config lab | MELKOR::SWIERKOWSKIS | | Thu Apr 23 1992 15:41 | 105 |
| Buck,
This is the VAXcluster lab that worked. One aside: exercise 1.B. requires
an alloclass of 1 on the boot server and a 0 on the satellite(s) simply
because of the way I put together the cluster section of our SYSTARTUP_V5
procedure a few years ago. If the students alter this part of the configur-
ation, the cluster won't boot properly. That section should be removed or
modified if not appropriate for your environment. Ditto, for using a local
disk for page/swap files. They are, of course, building an NI cluster. They
did the build on Tuesday afternoon, but did not do the last section of the lab
(common MODPARAMS.DAT etc. until Wednesday) because I didn't have time to
cover those topics in lecture on Tuesday.
Susan
__________________________________________________________________________
.NO NUMBER
.NO PAGING
.LITERAL
VAXcluster Configure Lab
Continue to work with your team. Depending on the size of the class and the
amount of hardware available, you may be asked to merge with a second team.
Elect a new typist.
1. Plan your VAXcluster configuration. Keep the same DECnet nodenames and
addresses from your Configure Network lab.
A. What system will you use for your boot server? Why?
B. Make sure you select an allocation class of 1 for your boot server and
an allocation class of 0 for your satellite(s). Why?
C. What is the Ethernet hardware address for your satellite(s)? How did
you find it/them?
D. Do NOT elect to use a local disk for page and swap files when you run
CLUSTER_CONFIG.COM. Your SYSTARTUP_V5.COM will invoke a procedure that
will create them for you.
2. Configure your VAXcluster. Log into the SYSTEM account on the node that
you chose for your boot server.
A. $ @SYS$MANAGER:CLUSTER_CONFIG will set the appropriate SYSGEN
parameters to convert your system into a boot server for a VAXcluster.
After AUTOGEN completes, shut down and reboot. If you did not do so
earlier, rename your remote node DECnet database and the object
database to the common directory.
B. $ @SYS$MANAGER:CLUSTER_CONFIG a second time will allow you to configure
in your first satellite. After you have answered the questions and
the configuration session completes, boot your satellite into the
VAXcluster. Your satellite will run AUTOGEN.COM and NETCONFIG.COM
automatically. After completion, the satellite will shut down and
attempt an automatic reboot. If the satellite has not been configured
to automatically boot into the VAXcluster, halt it and reboot.
3. Verify your configuration:
$ SHOW CLUSTER/CONTINUOUS
$ SET HOST satellite_nodename !from the boot server
$ SET HOST boot_server_nodename !from the satellite
$ MONITOR CLUSTER
4. Cleanup your VAXcluster.
A. Shut down the satellite and delete the page, swap and dump files in
[SYS10.SYSEXE]. BE SURE YOU DELETE THE CORRECT FILES; DO NOT DELETE
THE FILES FOR YOUR BOOT SERVER IN [SYS0.SYSEXE].
B. Create a common dumpfile.
C. Create a common modparams.dat file.
D. Create ANNOUNCE, WELCOME and STARTUP MESSAGE files. Use the files in
[SYS0.SYSMGR] as a template. Note that the STARTMESS.MAR file is macro
source code. You will need to recompile and link it after you edit it
to change the nodename.
.END LITERAL
|