 |
The Question is:
1) Can VMS Clusters support the sharing of RMS files across a cluster? My main
concern here is the whole approach to record locking, lock manager, etc.
2) Are their specific application requirements in order for clustering to work
properly with RMS?
3) I read in the FAQ that a RMS file can grow to one terabyte; however, is
their a "known" size limit where indexing, performance, backups, reorgs, etc.
become not practical from a support perspective? For example, MS Access is
great for small database a
pplications; however, it would not be considered for databases larger than
100Mb. I know MS Access is not in the same league, I am just using as an
example.
4) What part of the Compaq organization should be contacted for very complex
consulting engagements related to RMS?
Staffmark is the seventh largest staffing company in the US and we operate our
business on a packaged application called TempWare V from a company named
Caldwell Spartin in Atlanta, GA. The entire application is operating on RMS
files. We have over 17 d
atabases for the business today that are made up of approx 30 different RMS
files each. We would like to go to one database for the entire company. My
concerns in the one database solution are the ongoing maintenance support for
such large files, the ab
ility to recover from hardware failures, scalability, performance, backups,
reorgs, etc. I have inquired with Caldwell Spartin about a migration to
Oracle; however, it is impractical for them to support. I need to know how to
navigate the Compaq organiz
ation to help us determine if it is possible for us to consider the one "big"
database. I believe our total database size would be in excess of 80Gb of
disk. Not pushing the limits by any means. But I know the support
requirements would be much greater
and more complex. The reason for all of this is that TempWare is responsible
for the payroll of 135,000 plus employees across the US plus the billing of
$600 million in revenue. As long as I can run payroll and print invoices I
sleep well at night. To
day we have six geographicaly placed Alpha VMS servers that "share" the load.
Having multiple databases and multiple servers minimizes the impact of any
corruptions, downtime, etc.
Thanks for allowing me to use this forum to ask these questions. I have been
unable to find the correct resource to contact within Compaq through Caldwell
Spartin so I thought I would give this a shot.
Please feel free to contact by phone if you feel that email is not the
appropriate medium to respond.
Sincerely,
Kevin Brown
VP Information Systems
Staffmark
234 E. Millsap Road
Fayetteville, AR 72703
(501) 973-6088 Voice
(501) 973-6019 Fax
kbrown@staffmark.com
The Answer is :
1) Sharing RMS files is one of the major purposes of a cluster.
2) Correct behavior across a cluster is supported for all RMS operations.
Functionally, one can not distinguish access from node, or an other node.
From a performance perspective, it is advantages to focus access to a
specific set of files to a specific node. For example, If user group A
works with fileset A and usergroup B works with fileset B, you could
choose to balance the users of both between the cluster nodes and that
would work fine, but if you can nudge the users A all to one node and
users B to the other node, your system performance is likely better.
3) Performance issues are highly dependant on application design, hardware
configurations, predictability of traffic rate and other local factors.
Flaws in application design in a worst case scenario can lead to a
1000:1 performance degradation on identical hardware.
In practice individual RMS files in the 10 - 50GB region have proven to be
managable, but do warrant detailed attention. In the proper operating
environment (sufficient scratch disks, I/O hose throughput) one can convert
such file in less than an hour. However, in a poorly thought through setup,
even a simple 1GB file may take a day to convert.
4) Compaq Professional Services can help in this regard.
Just like you would for an database (Oracle) solution, you should
establish a small team of (mostly self trained?!) RMS file
administrators. They should have access to a modest test environment
to pre-stage file maintenance operations. Just because the product (RMS)
is free, does not mean that the operation is free. In fact one might
argue, that a free product will need more attention.
Please be sure to send a representative to the Compaq CETS2000 (DECUS)
conference(s). There will be VMS tunings sessions, and at least one
workshop dealing with RMS indexed files.
You might also consider the issue "why change" if your current arrangement
is working well. If a tornado hits one of your geographically separated
data centers, at least 5/6 of those on the payroll will not be upset.
Avoiding that problem with a centralized database can be done with
disaster tolerant clusters, but the effort to manage it is probably
more than for your six separate data centers.
|
|
|
|
|
