| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1049.1 | ex | 29067::BUTTERWORTH | Gun Control is a steady hand. | Wed Oct 18 1995 13:42 | 33 |
| > We are hoping to use AlphaStations 3000-900 and the question of
> clustering the two stations at each site has come up. Unfortunately
> SCSI clusters are not supported on the 3000-900. So the only option
> left is to use them in a LAVC type arrangement.
> Will all of the event files be common to the two nodes or do they need
> to be different.
Will the systems be monitoring two different sets of nodes or is one
to function as the hot backup to the other?
If the latter, there is an inherint problem in that there is not a
shared disk that each node has a physical path. This means that each
node is serving it's disks to the other. If you install the software
on only one disk then and if the node that serves that disk is down the
other node has no access to. Volume shadowing could solve that problem
but introduces another. If all your logfiles are on shadowed disks where
at least one member is located on each system and one node is shut down
followed by the other node at some later time you must reboot that last
node you shutdown first! This is because he was up longer and the
logfiles on it' shadow-set member are more current. if you rebooted the
first node you shutdown first, the second nodes member that has more
current files would be overwritten via a shadow copy!!
> Anything else we should consider ?
Without further knowledge as to what your goals are I can only offer
the above. So if can provide some input on your project goals we can
help you a lot more.
Regards,
Dan
|
| 1049.2 | More info for our PCM Cluster | 58633::FERRO | Rick Ferro | Mon Oct 23 1995 09:21 | 22 |
| Hello Dan,
Thanx for the quick reply. Based on your input we ae now considering
using AlphaStations 400 and establishing SCSI Clusters to get over the
disadvantages of not being able to share disks connected via a direct
physical path.
This brings me to the question of commonality of files. In your
question wheteher one system would be a hot backup for the other ? The
answer is yes. Both stations at each site are presently monitoring the
same systems on a primary/backup arrangement.
Because we are running gaming software that is fairly critical we
cannot afford not to have a console at any time. Connecting a terminal
to the console port of the systems in question, should the VCS station
fail, is not a tenable proposition, ergo the need for redundancy.
With the above in mind can you suggest anything else we should consider
? Will the arrangement provide us with the resilience we need ? What
will happen to the event files when the primary node goes down ?
Regards
|
| 1049.3 | | 29067::BUTTERWORTH | Gun Control is a steady hand. | Mon Oct 23 1995 17:01 | 28 |
| > With the above in mind can you suggest anything else we should consider
> ?
If you intend to use a quorum disk, bear in mind that a shadow-set
may not act as a quorum disk.
>Will the arrangement provide us with the resilience we need ?
It certainly should. You may want to consider tweeking SYSGEN param
RECNXINTERVAL to keep your cluster state transitions down.
> What will happen to the event files when the primary node goes down ?
If the logfiles are on a common disk then the secondary member will
open the same logfiles as the secondary used.
This brings to mind one other issue and that is time syncronization.
It's not absolutely critical but the closer the clocks are on the
PCM engines, the better off you are. Imagine a secondary PCM engine with
a one hour time difference from the primary. The primary goes down
and the secondary takes over. Soon after some problem occurs on one of
the monitored systems and you try to use EXTRACT interface. You could
hunt all over and not find what you want quickly.
Regs,
Dan
|