molson@apollo.COM (Margaret Olson) (12/06/88)
Folks,
There have been some questions in the group about why application
licenses are locked to NLS servers. I'll try to explain the
tradeoffs we faced and why we picked to do things the way we did.
In designing the license server, we had the following concerns:
-scalability
-availability
-response time
-security
If licenses could be freely moved from one server to another there
would be no real security in the network licensing system: users could
just move licenses from one server to another, and then restart the
original server from the original database (or passwords). This would
allow the unscrupulous to increase the number of licenses at will.
In order to provide adequate security AND moveable licenses, you need
strongly consistent replicated databases. Licenses would be locked to
a *group* of replicated servers, rather than to one server. Although
this would provide continued service in the unlikely event that a server
fails, it has serious problems. First of all, no operation on the
server could occur without the notification of all of the other servers.
This would be quite expensive. Secondly, in the event of a network
partition replicas in the minority partition would have to shut down.
You could solve this problem by having several sets of replicated
servers, but then you just have essentially the same arrangement that
NLS has now - staticly paritioned licenses.
In the end, we felt that replicated servers would solve a problem
that occurs very rarely (failed disks) and was not worth the runtime
expense. Replicated servers do nothing to solve the problems of network
partitions, which in a large network are quite frequent.
By the way, in the unlikely event that a server node dies, I believe that
your service rep can move the nodeid prom to a new machine. This will
allow you to move your license database to this new machine. Since the
prom can only be in one place at a time, there is no security hole here.
Margaret Olson
Apollo R & D
molson@apollo.comkrowitz@RICHTER.MIT.EDU (David Krowitz) (12/07/88)
Actually, between crashes due to bugs in Domain/OS, servers getting wedged and refusing to die when SIGP'ed, GPIO/DMA bugs causing illegal page faults, and users filling up all of the disk space and crashing the node, our machines have unscheduled downtime at least once a month, not including hardware problems (which, as you've pointed out are not too much of a problem on the newer machines). It generally takes half a day for a repairman to reach our site after we call in a problem, and we are only half an hour from our field service office in Framingham (and only 45 minutes from Chelmsford). If a problem occurs in the evening, it takes 12 to 16 hours to get someone on site. That's an awfully long period to be without our software licences. It's bad enough when we lose a node/disk just prior to a major scientific conference, but I can always grab the backup tapes and restore files to another disk. If we were to lose our network wide software licenses on, for instance, the night before the American Geophysical Union is to start, and it took 12 to 16 hours to get them back, I'd lose my job. Our Ricoh copier broke (again) last week. It took them a day to get here. The AGU meeting started this Monday. Ricoh will not get our business in the future. I think Apollo needs to take a second look at having the licenses node locked. If Apollo can find no alternative, then they should supply instructions and tools for moving the node ID prom in an emergency. One alternative which comes to mind is something someone came up with for the PC market -- a module which plugged into an RS232 port and served as a software license for the machine. It allowed PC users to move their software from machine to machine, have multiple copies for backup purposes, and still only have a single usable software license. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
kirk@oakhill.UUCP (Kirk Livingston) (12/08/88)
In article <4014e53a.1837d@apollo.COM> molson@apollo.com writes: > > In designing the license server, we had the following concerns: > -scalability > -availability > -response time > -security > > In order to provide adequate security AND moveable licenses, you need > strongly consistent replicated databases. Licenses would be locked to > a *group* of replicated servers, rather than to one server. > What's wrong with this. If your central server goes down you can at least continue to use the software you had purchased. > In the end, we felt that replicated servers would solve a problem > that occurs very rarely (failed disks) and was not worth the runtime > expense. But when the disk goes down all of our NLS licensed software would go down with it. Seriously crippling our work until the service man can repair the machine or provide an alternate server. No thanks!! Speed is not the only issue here. NLS must be tolerant to the failure of the server. > By the way, in the unlikely event that a server node dies, I believe that > your service rep can move the nodeid prom to a new machine. This is not a good solution why solve a software problem with a hardware solution. By the way did anyone at apollo ever ask any of the apollo customers what they would prefer?? From the number of complaints so far I doubt it. Kirk Livingston Motorola Inc. The opinions expressed are my own and not of motorola.
dennis@peanuts.nosc.mil (Dennis Cottel) (12/09/88)
In article <4014e53a.1837d@apollo.COM> molson@apollo.com writes about
the NLS server being node locked, and how it can't be done otherwise...
Several places in this message, Ms. Olson refers to how unlikely it
is for a node to be down. Nevertheless, it *will* happen -- and at an
extremely inconvenient time, no doubt. You must design for the worst
case.
Apollo has the most advanced networking capabilites available. They
have to be designing and building workable solutions to the new
problems that this technology brings. Of course, I suppose a viable
company can't be marketing products that are still research issues,
but I've been disappointed that Apollo hasn't been more imaginative in
taking advantage of the network possibilities.
Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152
(619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennisgiebelhaus@hi-csc.UUCP (Timothy R. Giebelhaus) (12/14/88)
In article <1730@sol.oakhill.UUCP> kirk@sol.UUCP (Kirk Livingston) writes: > >What's wrong with this. If your central server goes down you can >at least continue to use the software you had purchased. Who says you have to put you all you NLS servers on the server? You can place an NLS server on each node you use the software. This would approach a node locked piece of software. It would provide a little more as other nodes could use the software when the node which had the NLS server on it was not using it. >But when the disk goes down all of our NLS licensed software >would go down with it. Seriously crippling our work until the >service man can repair the machine or provide an alternate server. >No thanks!! Again, why have only one NLS server? Spread out you licenses as much as you like. >Speed is not the only issue here. NLS must be tolerant to the >failure of the server. As already described, NLS has to be secure else why bother to introduce the overhead at all. If anyone can think of a better secure scheme, please send in an apr or ucr. >By the way did anyone at apollo ever ask any of the apollo >customers what they would prefer?? From the number of >complaints so far I doubt it. Sure, a mass mailing survey went out. I'll bet most people remember the survey. -- UUCP: uunet!hi-csc!giebelhaus UUCP: tim@apollo.uucp ARPA: hi-csc!giebelhaus@umn-cs.arpa ARPA: tim@apollo.com Tim Giebelhaus, Apollo Computer, Regional Software Support Specialist. My comments and opinions have nothing to do with work.
dennis@peanuts.nosc.mil (Dennis Cottel) (12/15/88)
In article <403bace5.12c4f@hi-csc.UUCP> giebelhaus@hi-csc.UUCP (Timothy R. Giebelhaus) writes: >Who says you have to put you all you NLS servers on the server? >You can place an NLS server on each node you use the software. >This would approach a node locked piece of software. It would >provide a little more as other nodes could use the software when >the node which had the NLS server on it was not using it. But my understanding is that each application is aimed at a particular license server; there isn't a way for the application to query multiple servers trying to find one that has a license available. Is this correct? Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennis
holbrook@apollo.COM (Alan R. Holbrook) (12/21/88)
In a recent article, Dennis Cottel @ Naval Ocean Systems Center, San Diego writes: >But my understanding is that each application is aimed at a >particular license server; there isn't a way for the application to >query multiple servers trying to find one that has a license >available. Is this correct? No, this is _not_ correct. Vendor licenses (those licenses sold by the software supplier to authorize access to his product) may be installed on any license server in your network. When an application requests a license to run, the license system _can_ ,and _does_, query as many license servers on the network as it needs to until it finds a license for that application or runs out of servers. Alan Holbrook Program Manager, Distributed Computing