home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2001 May / SGI IRIX Base Documentation 2001 May.iso / usr / share / catman / p_man / cat5 / array_services.z / array_services
Encoding:
Text File  |  2001-04-17  |  14.3 KB  |  265 lines
  1.  
  2.  
  3.  
  4. aaaarrrrrrrraaaayyyy____sssseeeerrrrvvvviiiicccceeeessss((((5555))))                                            aaaarrrrrrrraaaayyyy____sssseeeerrrrvvvviiiicccceeeessss((((5555))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      array_services - overview of array services
  10.  
  11. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  12.      Along with the power and flexibility of clustered systems comes some
  13.      additional complexity in the area of administering and managing the array
  14.      as a whole.  IRIX provides several services to help ease this situation.
  15.      Some of these services revolve around the notion of an array session,
  16.      which is a set of processes, perhaps running on different nodes in an
  17.      array, that are conceptually related as a single "job".  Additional
  18.      services are provided by the array services daemon, which knows about the
  19.      configuration of an array and is therefore able to provide functions for
  20.      describing and administering it.
  21.  
  22.    AAAARRRRRRRRAAAAYYYY SSSSEEEESSSSSSSSIIIIOOOONNNNSSSS
  23.      A principal use of an array system is to run jobs that are large enough
  24.      to span two or more machines.  Unfortunately, the mechanisms that are
  25.      typically used to manage multiple related processes (for example: process
  26.      groups, terminal sessions) are limited in scope to a single machine.  As
  27.      a result, mundane tasks such as killing a job or accounting for all of
  28.      its resource usage can become very difficult when the job runs across
  29.      several machines.  Some means of correlating related processes on
  30.      different machines is required.  IRIX provides this function with the
  31.      notion of an "array session".
  32.  
  33.      In formal terms, an array session is a set of processes all related to
  34.      each other by a single unique identifier, the aaaarrrrrrrraaaayyyy sssseeeessssssssiiiioooonnnn hhhhaaaannnnddddlllleeee (ASH).
  35.      A child process ordinarily inherits the ASH of its parent when it is
  36.      created, thus becoming a member of its parent's array session.  However,
  37.      it is possible for a process to leave its parent's array session and
  38.      start a new one.  This would be done by programs such as _l_o_g_i_n(1) or
  39.      _r_s_h_d(1M) so that logging in to the system will effectively start a new
  40.      array session.  This is also done by programs like _c_r_o_n(1M) and _s_u(1M) so
  41.      that work done on behalf of another user will be done in its own array
  42.      session.  When the last process with a given ASH exits, a session
  43.      accounting record containing accumulated statistics for all of the
  44.      processes that ran in the array session is written and the array session
  45.      ceases to exist.
  46.  
  47.      The array session handle itself is a 64-bit value.  By default, a unique,
  48.      increasing value (similar to a process ID) is assigned to each new array
  49.      session as its handle.  This type of ASH is referred to as a llllooooccccaaaallll AAAASSSSHHHH:
  50.      although it is guaranteed to be unique on the local machine, it may also
  51.      be in use by a different session on another machine in the same array.
  52.      Because of this, a local ASH is not appropriate for identifying multi-
  53.      machine jobs.  However, there is a second type of ASH known as a gggglllloooobbbbaaaallll
  54.      AAAASSSSHHHH.  These are assigned by the array services daemon (see below) and _a_r_e
  55.      supposed to be unique across the entire array.  By arranging for the same
  56.      global ASH to be associated with each process in a job, it is possible to
  57.      treat the set of processes as a single entity, even though some of the
  58.      processes may be running on different machines.
  59.  
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. aaaarrrrrrrraaaayyyy____sssseeeerrrrvvvviiiicccceeeessss((((5555))))                                            aaaarrrrrrrraaaayyyy____sssseeeerrrrvvvviiiicccceeeessss((((5555))))
  71.  
  72.  
  73.  
  74.      The next trick is "arranging for the same global ASH to be associated
  75.      with each process in a job".  This involves several steps.  First, each
  76.      machine that is to run part of the job must start a new array session to
  77.      contain the related processes.  By default, this new array session will
  78.      only have a local ASH, so it must "upgrade" its handle to a global ASH.
  79.      If this is the first machine to run part of the job, it would need to
  80.      obtain a new global ASH from the array services daemon (this is done with
  81.      a single library call, _a_s_a_l_l_o_c_a_s_h(3X)).  Additional machines that are
  82.      called into service for the job would need to get a copy of the first
  83.      machine's global ASH; presumably this information would be passed along
  84.      at the same time as the rest of the information concerning the new job.
  85.      Once an appropriate global ASH has been settled upon, it can then be
  86.      assigned to the new array session, replacing the original local ASH.  The
  87.      process on each machine that started the new array session is now free to
  88.      fork off any number of children to do the required work.  These children
  89.      will all have the same ASH and can therefore be correlated with each
  90.      other for administrative tasks such as job control or accounting.
  91.  
  92.    AAAARRRRRRRRAAAAYYYY SSSSEEEERRRRVVVVIIIICCCCEEEESSSS DDDDAAAAEEEEMMMMOOOONNNN
  93.      Although being able to correlate related processes on different machines
  94.      in an array is necessary for the stated goal of administering an array in
  95.      a reasonable way, it is not sufficient: something still needs to find all
  96.      of those related processes and act upon them.  That is the job of the
  97.      array services daemon.
  98.  
  99.      Each machine in an array should have an array services daemon running on
  100.      it.  The array services daemon (arrayd) performs several different tasks:
  101.  
  102.      - It allocates global array session handles
  103.  
  104.      - It knows the current array configuration and can provide that
  105.        information to other commands and programs
  106.  
  107.      - It can determine which processes belong to a particular array session
  108.        and provide that information to other commands and programs
  109.  
  110.      - It can forward commands to all of the machines in an array
  111.  
  112.    GGGGlllloooobbbbaaaallll AAAArrrrrrrraaaayyyy SSSSeeeessssssssiiiioooonnnn HHHHaaaannnnddddlllleeeessss
  113.      As mentioned earlier, a global array session handle is important for
  114.      keeping track of jobs that run on several machines in an array.  Because
  115.      the array services daemon knows the configuration of an array, it is
  116.      better suited to providing a unique global ASH than the IRIX kernel,
  117.      which necessarily knows only about the local machine.
  118.  
  119.      When a program needs to allocate a global ASH it invokes a single library
  120.      call, specifying (optionally) which array the ASH is to be allocated for.
  121.      The library call, which is part of libarray (see below), takes care of
  122.      the pragmatic issues of contacting and communicating with the local array
  123.      services daemon.  The resulting global ASH can then be passed to the
  124.      _s_e_t_a_s_h(2) system call.  Note that while anybody can allocate a global
  125.      ASH, only a process with root privileges can actually change its ASH
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. aaaarrrrrrrraaaayyyy____sssseeeerrrrvvvviiiicccceeeessss((((5555))))                                            aaaarrrrrrrraaaayyyy____sssseeeerrrrvvvviiiicccceeeessss((((5555))))
  137.  
  138.  
  139.  
  140.      using setash.
  141.  
  142.      The global ASH itself is an "opaque" value: it does not necessarily have
  143.      any specific information embedded in it, other than to distinguish it
  144.      from a local ASH (a library function is provided to make this
  145.      distinction).  Nevertheless, the identity of the specific machine that
  146.      creates a global ASH and the array for which it is intended may play some
  147.      role in the generation of the ASH value itself.  System administrators
  148.      may specify particular values to be used for this purpose if desired.
  149.  
  150.    AAAArrrrrrrraaaayyyy CCCCoooonnnnffffiiiigggguuuurrrraaaattttiiiioooonnnn DDDDaaaattttaaaabbbbaaaasssseeee
  151.      Each array services daemon has knowledge about one or more arrays and the
  152.      machines that make up each of them.  This information can be provided to
  153.      other programs and commands with straightforward library calls in
  154.      libarray.  Ideally, this should make it unnecessary for other array-
  155.      oriented programs to maintain their own separate array configuration
  156.      data.
  157.  
  158.      An array services daemon obtains its configuration information from a
  159.      configuration file located in its local filespace.  Each daemon has its
  160.      own configuration file which must be synchronized by the system
  161.      administrator with configuration files on other machines in the array(s).
  162.  
  163.    AAAArrrrrrrraaaayyyy SSSSeeeessssssssiiiioooonnnn IIIInnnnffffoooorrrrmmmmaaaattttiiiioooonnnn
  164.      To take advantage of array sessions, it is necessary to be able to
  165.      enumerate the processes that are contained in a given array session.  For
  166.      certain applications (monitor programs for example) it may also be useful
  167.      to enumerate ALL of the known array sessions.  The array services daemon
  168.      can obtain both types of information and provide it to other programs via
  169.      libarray functions.
  170.  
  171.    CCCCoooommmmmmmmaaaannnndddd FFFFoooorrrrwwwwaaaarrrrddddiiiinnnngggg
  172.      Command forwarding pulls all of the other array services together: it
  173.      allows a user on one machine to issue a single command and have it
  174.      executed on all of the machines in an array, perhaps only affecting a
  175.      particular array session.  With the appropriate setup, this could be used
  176.      for such tasks as killing a runaway job or shutting down an entire array.
  177.  
  178.      Users use a simple client program (_a_r_r_a_y(1)) to specify the command they
  179.      want to execute, any arguments it may require and the array they want to
  180.      execute it on.  Such an array command might look like this:
  181.  
  182.           _aaaa_rrrr_rrrr_aaaa_yyyy _----_aaaa _DDDD_eeee_vvvv_AAAA_rrrr_rrrr_aaaa_yyyy _kkkk_iiii_llll_llll_aaaa_ssss_hhhh _1111_3333_5555_4444_3333_4444_2222_3333
  183.  
  184.      This example says "execute the command 'killash 13543423' on the machines
  185.      in the array 'DevArray'".  The command "killash" is not necessarily an
  186.      actual program on any machine in the array; instead it refers to an entry
  187.      in each machine's array configuration file.  The entry itself specifies
  188.      which program to execute, which arguments should be passed to it, which
  189.      user/group/project the command should be executed under, etc.  This
  190.      allows each machine in an array to handle a particular command
  191.      differently, or not handle it at all.
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. aaaarrrrrrrraaaayyyy____sssseeeerrrrvvvviiiicccceeeessss((((5555))))                                            aaaarrrrrrrraaaayyyy____sssseeeerrrrvvvviiiicccceeeessss((((5555))))
  203.  
  204.  
  205.  
  206.      The "array" program itself is fairly basic: it simply passes the user's
  207.      command to the local array services daemon.  The local array services
  208.      daemon forwards the command to each machine in the specified array, then
  209.      gathers the results which are then passed back to the "array" program and
  210.      then the user.
  211.  
  212. TTTTHHHHEEEE AAAARRRRRRRRAAAAYYYY SSSSEEEERRRRVVVVIIIICCCCEEEESSSS LLLLIIIIBBBBRRRRAAAARRRRYYYY
  213.      In general, users should never have any direct interaction with the array
  214.      services daemon.  Instead, all interaction with the array services daemon
  215.      is done through the array services library, _l_i_b_a_r_r_a_y.  libarray provides
  216.      functions for dealing with global ASH's, describing the current array
  217.      configuration, and executing array commands.
  218.  
  219.      There are a number of libarray functions, all of which are documented in
  220.      chapter 3X man pages.  Some of the libarray functions include:
  221.  
  222.          ASH Functions
  223.              _aaaa_ssss_aaaa_llll_llll_oooo_cccc_aaaa_ssss_hhhh       - Allocates a global ASH
  224.              _aaaa_ssss_aaaa_ssss_hhhh_iiii_ssss_gggg_llll_oooo_bbbb_aaaa_llll    - Indicates whether an ASH is global or local
  225.              _aaaa_ssss_llll_iiii_ssss_tttt_aaaa_ssss_hhhh_ssss______aaaa_rrrr_rrrr_aaaa_yyyy - Returns all global ASH's in specified array
  226.  
  227.          Configuration Functions
  228.              _aaaa_ssss_llll_iiii_ssss_tttt_aaaa_rrrr_rrrr_aaaa_yyyy_ssss     - Returns info on all known arrays
  229.              _aaaa_ssss_llll_iiii_ssss_tttt_mmmm_aaaa_cccc_hhhh_iiii_nnnn_eeee_ssss   - Returns info on all machines in specified array
  230.  
  231.          Command Forwarding
  232.              _aaaa_ssss_cccc_oooo_mmmm_mmmm_aaaa_nnnn_dddd        - Execute an array command
  233.  
  234. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  235.      array(1), arrayd(1M), newsess(1), asallocash(3X), asashisglobal(3X),
  236.      ascommand(3X), aslistarrays(3X), aslistashs_array(3X),
  237.      aslistashs_server(3X), aslistmachines(3X), arrayd.conf(4),
  238.      array_sessions(5).
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.                                                                         PPPPaaaaggggeeee 4444
  262.  
  263.  
  264.  
  265.