home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / isis / 208 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  7.3 KB

  1. Path: sparky!uunet!zephyr.ens.tek.com!uw-beaver!cornell!ken
  2. From: ken@cs.cornell.edu (Ken Birman)
  3. Newsgroups: comp.sys.isis
  4. Subject: Re: A question about network partition on process groups
  5. Message-ID: <1992Jul25.004433.3234@cs.cornell.edu>
  6. Date: 25 Jul 92 00:44:33 GMT
  7. References: <1992Jul23.190006.3551@fig.citib.com>
  8. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  9. Lines: 123
  10.  
  11. In article <1992Jul23.190006.3551@fig.citib.com> kpt@fig.citib.com (Kevin P. Tyson) writes:
  12. >I am very new to ISIS so please forgive me if this is a FAQ.  I am interested
  13. >in using ISIS to implement replicated resource managers.  My understanding is
  14. >that the Client-Server Group mechanism is the technique to use for this type
  15. >of processing and that the logging facility is the mechanism to use when new
  16. >replicas need to be added to the group.
  17.  
  18. It depends on what you are trying to do.  The logging tool is normally
  19. NOT needed, because most services of this sort don't need to preserve
  20. state across total failures.  Instead, they tend to restart a failed
  21. server on some reasonable machine (perhaps picking it with the "network
  22. resource manager") and the new server does a pg_join and becomes part
  23. of the service group in that way.
  24.  
  25. As for this being a client-server group: this would certainly be a group
  26. with clients.  However, they might not be registered using the ISIS pg_client
  27. system call.  For example, I know that Citibank is a DCE user, and for
  28. your setting it might be preferable to use a DCE RPC to talk to a
  29. server within the group, perhaps the one on your file server or otherwise
  30. picked to be in a sensible place, and this might use ISIS internally to
  31. maintain synchronized state wrt. other members of the service.  So, you
  32. would see a standard DCE interface from the outside, but could use ISIS
  33. on the inside.  Since ISIS can run under pthreads, this should work
  34. smoothly with no special problems relative to the DCE startup sequence...
  35.  
  36. Generally, the case where we use the term "client-server group" and where
  37. you need to call pg_client in the client program is when the client will
  38. receive diffusion multicasts from the group, or will need to multicast
  39. atomically into the group, say if it was going to subdivide the search
  40. of a database among its members.  Here, the pg_client call is necessary
  41. because the multicast will otherwise take an inefficient route, and over
  42. time you would prefer not to pay that inefficiency repeatedly.
  43.  
  44. One annoyance with ISIS is that it offers a lot of options.  In principle,
  45. you should be able to implement any architecture that appeals to you and
  46. that makes sense...
  47. >
  48. >My question concerns the effect of network partition on the server members of
  49. >the process group.  Suppose we have a server process group running on four
  50. >nodes on a single ethernet segment.  Each node has at least the Protos process
  51. >and the server process running.  Each server process is responding to all rpc
  52. >calls made to the group.  At some point the segment is split into two segments
  53. >of two nodes each.  I assume that the Protos processes on each node will
  54. >detect the missing nodes and on the segment which now lacks the primary server
  55. >will promote one of the two remaining server processes to the role of primary.
  56. >The result of this will be two server process groups, each of which will
  57. >continue to operate.
  58.  
  59. Actually, no.  In this situation ISIS will only allow the partition with
  60. the most nodes (or the heaviest "weight", if you use the new "weight="
  61. feature in the sites file), to continue execution.  The nodes that are
  62. partitioned away will see a disconnect from the system, e.g. their 
  63. isis_failed() procedures will be called, and will need to reconnect to the
  64. system later when the partition heals.  This is illustrated in the manual.
  65. The point is that ISIS will never allow the same group to be duplicated by
  66. a partition.
  67.  
  68. If you are looking at a setting where partition is a real risk, the
  69. solution is to run ISIS separately on each of the two (or more) chunks.
  70. Each ISIS can independently support an instance of your service, say a
  71. "wide-area database service", and with the wide-area tools you can
  72. then multicast to the set of groups. 
  73.  
  74. A simpler way to deal with a WAN, however, is to use the NEWS system
  75. as a wide-area communication tool, since it is easy to run NEWS in a WAN
  76. configuration.  Processes in the various LAN systems would monitor the
  77. important WAN topics and, for example, update the local database using
  78. what they see.
  79.  
  80. One can't do better: Skeen proved this a few years ago.  There is
  81. a basic choice between waiting for the partition to heal and making
  82. progress during a partition, and the cost we pay for going the latter
  83. route is that we can't allow a group to straddle a partition.
  84.  
  85. On the other hand, we could hide this better.  In the future (1993 or 1994)
  86. we will introduce a new ISIS system that will have a more uniform interface
  87. regardless of whether you work in the LAN or WAN setting.  This will
  88. at least look better, although it won't actually overcome Skeen's 
  89. impossibility results.  Databases have the same problem, by the way.
  90.  
  91. >
  92. >At some point the segments will have to be re-united.  What support is there
  93. >in ISIS for detecting the changes that may have gone to one but not both of
  94. >the server groups while the network was partitioned?  What support is there
  95. >for merging the two server groups into a single server group?
  96. >
  97.  
  98. Well, if you use my recommendation -- WAN news -- you have a very strong
  99. guarantee that when the partition merges, stacked up messages will be
  100. despooled and replayed into the local representative for each group.
  101. So, with WAN news, you know that important data always gets through
  102. eventually, in the order sent, and without duplication or other errors.
  103. You can also get the equivalent behavior at a lower level, using the
  104. WAN interfaces to the spooler.
  105.  
  106. On the other hand, if you are really in a LAN system and, say, we
  107. are looking at one machine that lost its connection to the local ether,
  108. the partitioned programs will have been out of touch and will look
  109. like newly created programs when they reconnect.  They need to rejoin
  110. process groups, resubscribe to news topics, etc.  In this setting,
  111. the program that was disconnected can save up things to play into the
  112. system (e.g. trades that your brokers and bankers entered while in
  113. disconnected mode) but can't be sure, without checking, what the outcome
  114. was on a trade that was in progress when the connection failed.
  115. News will save up and replay messages, under your control.  But,
  116. since the process is treated like a new arrival, you don't see a
  117. guarantee that when the connection is restored everything that you
  118. would have seen gets replayed.
  119.  
  120. One reason is sheer volume of data.  I don't know what citibank is]
  121. like, but we are talking to places with 100's or 1000's of transactions
  122. per second, system wide, and a program partitioned away could have
  123. missed megabytes while disconnected.  Isis doesn't have a good place
  124. to save all that stuff... if you ask news to do so, it will, but this
  125. makes it your decision to save it, and your problem to find space, and
  126. your responsibility to say how long to keep it...
  127.  
  128. Hope this helps!  Feel free to ask for clarification.  I'm sure a lot
  129. of people are interested in issues like this.
  130. -- 
  131. Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
  132. 4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
  133. Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
  134.