info-vax@ucbvax.UUCP (12/04/85)
A friend of mine is part of a project which needs a computer or set of networked computers to allow at first 140, and later 180, simultaneous users to access and update a single database. The system needs to be fast, since the users will be updating the database as they talk on the telephone; and it needs to be extremely reliable. The database is something like 300 Mbytes. A UNIX system is desired, but any modern OS such as VMS is preferred to the alternative, which is doing it on an IBM mainframe. My friend is looking for recommendations on both hardware and database software. Recommendations are desired from vendors and from anyone with experience doing something like this. Please mail recommendations to me. I will forward results to my friend and summarize to the net. ---- Sam Kendall allegra \ Delft Consulting Corp. seismo!cmcl2 ! delftcc!sam (212) 243-8700 ihnp4 / ARPA: delftcc!sam@nyu-cmcl2.EDU or @nyu.EDU
info-vax@ucbvax.UUCP (12/10/85)
I know little about IBM mainframes, but here is a solution to the problem for VAX or PDP-11 users. Rather than buy a more expensive processor, one solution is to add one or more similar processors to the same system. This, however, introduces a further problem. All processors in the configuration must share the same database if they are to appear (from a user or application program's point of view) as a single system. System Industries (Milpitas, California) has a controller (the 9920) that allows multiple CPUs to access a single disk storage device. However, unless there is some form of communication between the CPUs, it would be difficult (!!) to maintain the data integrity on the disk. POSSIBLE SOLUTIONS: LAN METHOD: The following figure shows that all requests for access to the common disk are processed by a single CPU on the LAN. This CPU treats all service requests simply as another local user. This provides a limited increase in processing power because each sattelite CPU can handle its own front end processing. BUT, the single CPU still has to handle all disk access requests which can create quite a bottleneck. +--------------------------------------+ | network | +--------------------------------------+ | | | +--------+ +----------+ +---------+ | cpu a | | cpu b | | cpu c | +--------+ +----------+ +---------+ | +----------------+ | controller | +----------------+ | +-----------------+ | common database | | disk | +-----------------+ While networks are useful for remote access, they introduce an overhead in both CPU time and I/O throughput. They provide only a limited degree of system integration and need special prorocols to access the data. File transfers may also have to pass over other hosts before reaching their destination. As a rule, it's not worth the cost to use a network to merely access a file system. MULTI PORTED CONTROLLER SOLUTION: The next figure shows a dual port controller configuration. Two CPUs are connected to a dual ported controller which in turn is directly connected to the disk. +----------------+ +------------------+ | cpu a | | cpu b | +----------------+ +------------------+ | | +-----+ +----+ | | +-------+--------------+-----------+ | controller | +----------------------------------+ | +--------------------+ | disk | +--------------------+ This configuration is fine except that it is possible for two CPUs to have write access to the disk and neither will know of the modifications the other is making to it. CPU A could allocate a block to one file and CPU B could allocate the same block to an entirely different file. This of course would corrupt the volume's structure. THE SIMACS SOLUTION from System Industries: In a situation like the one in the last illustration, the System Industries 9920 controller can define one semaphore for each CPU. If the semaphore is not set, any CPU can request that the controller set it. The controller does this and remembers which CPU made the request, and refuses requests from any other CPU until the semaphore is released. By agreement between cooperating programs, the semaphore gives each CPU exclusive access to the disk structure for the period of time that the CPU owns the semaphore. During this time, critical updates to the disk structure can be protected, and yet shared access for OTHER disk I/O's that do NOT alter disk structure is still allowed. The controller also allows one CPU to RESERVE the semaphore for its use. The controller will inform any other CPU requestor that the semaphore is already in use, and will inform the owner that a request has been made. Thus, the owner CPU can release the disk for others to use. It is necessary to make modifications to the operating system software to ensure that the disk structure is left in an integral state before ownership of the semaphore is relinquished. It is also essential for the CPUs to cooperate with each other, since the controller does not physically lock out or prevent other CPUs from accessing the reserved data. In UNIX OS's, the kernal in each CPU makes sure it owns the sempahore before performing any I/O operations which could be vulnerable to the actions of another CPU, or which could corrupt another CPUs disk structure. Before relinquishing the semaphore, a CPU makes sure that it has written the altered buffers, the inodes and superblocks to the disk. After regaining ownership of the semaphore, it checks to see if the superblock shows a new version number (thus indicating that another CPU has made changes to the disk). If so, it refreshes buffers, in-core inodes etc. BSD 4.2 SIMACS must also flush and refresh the cylinder group information summary and the disk quota information if the QUOTA option has been selected at configuration time. UNIX OS kernal has no central place to put the logic that controls the reserve and release of the semaphore. Instead, SIMACS contains two routines called sirelease() and sireserve(). SIMACS brackets critical code anywhere in the kernal with calls to these routines. As a general rule, a CPU must own the semaphore before the kernal locks an inode, and may release the semaphore after unlocking the inode. Also, the kernal must own the semaphore in other critical places before making reference to an inode or superblock. FILE LOCKING IN SIMACS: Althoug UNIX allows more than one user to open a file for write, SIMACS provides file locking as an option. If the System Manager has not selected file locking, simultaneous reading and writing is allowed. Simultaneous processes writing to a file must cooperate with one another to maintian data integrity. But, with file locking selected: - If a regular file is opened for read, SIMACS allows any number of other readers to have read access, but denies access to writers. - If a regular file is open for write or read/write, SIMACS allows no other reader OR writer to have access. ALL CPUs on a SIMACS system must be consistent in this respect. That is, either ALL must select file locking, or NONE may select file locking. Normally, alll this is transparent to the users. If a user tries to open a locked file, the SIMACS software will wait until the file is available, and then open it. Or, a no-delay option can be specified, which will return an error status if a process tries to open a locked file. This little dissertaion on SIMACS barely scratches the surface on the features and capabilities of the system. What it boils down to in a sentence is: You can have up to eight CPUs channeled through one controller to one data disk that is shared by ALL, and maintain volume and data integrity for all read and write operations. Phew. If you want more info on this, don't send mail..I won't get it. (I'm working on it). Instead, the person to talk to at System Industries is Dr. Paul Ramsay (UNIX) or Dr. Albert Chu (VMS). Their number is (408) 942-1212. Please feel free to leave any comments, messages or questions for me as a public message....as I said...I can't receive mail here (no one can). Good luck... Jim Bauman System Industries (sivax)
garry@LASSPVAX.TN.CORNELL.EDU (Garry Wiegand) (12/14/85)
In a recent article Jim Bauman of System Industries said: > > I know little about IBM mainframes, but here is a solution > to the problem for VAX or PDP-11 users. > >... [long description of System Industries product follows] > Two comments: 1) Everyone contributes financially to keep this network alive; one of the generally agreed rules is that people DON'T want to be supporting direct advertising. It's hard to resist - I know I'd love to be able to talk about my own software. You have to hope that one of your customers will be inspired to bring you up independently. 2) The solution offered seems crude compared with the speediness, transparency, and record-locking abilities of a VAX cluster running VMS. There have been rumors in here recently of a "poor man's" cluster machine: a microvax III. (Query: Does DEC (or anyone) support Unx on a cluster?) garry wiegand
info-vax@ucbvax.UUCP (12/16/85)
In response to the sales pitch from the man at System Industries -
I am an experienced SIMACS user. I work on a government cluster of
VAXes where disks were purchased from the lowest bidder. Before
purchasing a SIMACS product try to resolve the answers to the following
questions:
Did DEC really throw SI a curve when they put the disk ACP in each user
process? Causing much software complexity for SI and the users? Resulting
in the most amazing bugs with V4.0/1/2 like SET VERIFY not working in DCL?
How much additional memory and software installation time does the SI product
require?
What are the benefits of SIMACS over DEC disk clusters besides cost?
What kind of training program does SI have for its field engineers? What
sort of liability do they assume when one of them wipes out the data on
your disk accidentally? Does this sort of thing happen often?
What measurements do they have from field sites of data integrity and
reliability? Over the past year how many bugs have they found which
caused the clobbering of user files by their software? What was their
severity?
What evidence can they give that their product has stabilized and that
their plan for VMS compatibility is working?
Does the lower hardware cost of the SIMACS system offset any foreseeable
personnel, software development and data recovery costs?
Of course you would want to ask these questions of DEC and any other vendor,
considering:
"Corporations cannot commit trespass nor be outlawed nor excommunicate,
for they have no souls." - Lord Coke's Reports, Part x. p. 32.
-------------------
John Pierceinfo-vax@ucbvax.UUCP (12/19/85)
Garry: Regarding comment no. 1 concerning SIMACS: What you read was the mail message I sent directly to the person who posted the original query. I would never post such a blow-your-own -horn article. Someone made a decision to post that, I suspect whoever moderates this forum, or the recipient of my mail. Perhaps you can set the record straight? AND, regarding comment 2: You are RIGHT, BUT (and a big but it is too), SIMACS may be crude (only by comparison) but the cost is incredibly cheap. The results are the same, and that is what counts. AND, regarding comment 1 again: I DIDN'T DO IT!!!! Jim Bauman