Annotation of doc/gutshtml/SessionOne.html, revision 1.1
1.1 ! www 1: <html>
! 2: <head>
! 3: <meta name=Title
! 4: content="Session One: Intro/Demo, lonc/d, Replication and Load Balancing (Gerd)">
! 5: <meta http-equiv=Content-Type content="text/html; charset=macintosh">
! 6: <link rel=Edit-Time-Data href="Session%20One_files/editdata.mso">
! 7: <title>Session One: Intro/Demo, lonc/d, Replication and Load Balancing (Gerd)</title>
! 8: <style><!--
! 9: .Section1
! 10: {page:Section1;}
! 11: .Section2
! 12: {page:Section2;}
! 13: -->
! 14: </style>
! 15: </head>
! 16: <body bgcolor=#FFFFFF link=blue vlink=purple class="Normal" lang=EN-US>
! 17: <div class=Section1>
! 18: <h2>Session One: Intro/Demo, lonc/d, Replication and Load Balancing (Gerd)</h2>
! 19: <p> <img width=432 height=555
! 20: src="Session%20One_files/image002.jpg" v:shapes="_x0000_i1025"> <span
! 21: style='font-size:14.0pt'><b>Fig. 1.1.1</b></span><span style='font-size:14.0pt'>
! 22: Ð Overview of Network</span></p>
! 23: <h3><a name="_Toc514840838"></a><a name="_Toc421867040">Overview</a></h3>
! 24: <p>Physically, the Network consists of relatively inexpensive upper-PC-class
! 25: server machines which are linked through the commodity internet in a load-balancing,
! 26: dynamically content-replicating and failover-secure way. <b>Fig. 1.1.1</b><span style='font-weight:normal'>
! 27: shows an overview of this network.</span></p>
! 28: <p>All machines in the Network are connected with each other through two-way
! 29: persistent TCP/IP connections. Clients (<b>B</b><span
! 30: style='font-weight:normal'>, </span><b>F</b><span style='font-weight:normal'>,
! 31: </span><b>G</b><span
! 32: style='font-weight:normal'> and </span><b>H</b><span style='font-weight:normal'>
! 33: in </span><b>Fig. 1.1.1</b><span style='font-weight:normal'>) connect to the
! 34: servers via standard HTTP. There are two classes of servers, Library Servers
! 35: (</span><b>A</b><span
! 36: style='font-weight:normal'> and </span><b>E</b><span style='font-weight:normal'>
! 37: in </span><b>Fig. 1.1.1</b><span style='font-weight:normal'>) and Access Servers
! 38: (</span><b>C</b><span style='font-weight:normal'>, </span><b>D</b><span
! 39: style='font-weight:normal'>, </span><b>I</b><span style='font-weight:normal'>
! 40: and </span><b>J</b><span style='font-weight:normal'> in </span><b>Fig. 1.1.1</b><span
! 41: style='font-weight:normal'>). Library Servers are used to store all personal records
! 42: of a set of users, and are responsible for their initial authentication when
! 43: a session is opened on any server in the Network. For Authors, Library Servers
! 44: also hosts their construction area and the authoritative copy of the current
! 45: and previous versions of every resource that was published by that author.
! 46: Library servers can be used as backups to host sessions when all access servers
! 47: in the Network are overloaded. Otherwise, for learners, access servers are
! 48: used to host the sessions. Library servers need to be strong on I/O, while
! 49: access servers can generally be cheaper hardware. The network is designed
! 50: so that the number of concurrent sessions can be increased over a wide range
! 51: by simply adding additional Access Servers before having to add additional
! 52: Library Servers. Preliminary tests showed that a Library Server could handle
! 53: up to 10 Access Servers fully parallel.</span></p>
! 54: <p>The Network is divided into so-called domains, which are logical boundaries
! 55: between participating institutions. These domains can be used to limit the
! 56: flow of personal user information across the network, set access privileges
! 57: and enforce royalty schemes.</p>
! 58: <h3><a name="_Toc514840839"></a><a name="_Toc421867041">Example of Transactions</a></h3>
! 59: <p><b>Fig. 1.1.1</b><span style='font-weight:normal'> also depicts examples
! 60: for several kinds of transactions conducted across the Network. </span></p>
! 61: <p>An instructor at client <b>B</b><span style='font-weight:
! 62: normal'> modifies and publishes a resource on her Home Server </span><b>A</b><span
! 63: style='font-weight:normal'>. Server </span><b>A</b><span style='font-weight:
! 64: normal'> has a record of all server machines currently subscribed to this resource,
! 65: and replicates it to servers </span><b>D</b><span style='font-weight:
! 66: normal'> and </span><b>I</b><span style='font-weight:normal'>. However, server
! 67: </span><b>D</b><span
! 68: style='font-weight:normal'> is currently offline, so the update notification gets
! 69: buffered on </span><b>A</b><span style='font-weight:normal'> until </span><b>D</b><span
! 70: style='font-weight:normal'> comes online again.</span><b> </b><span
! 71: style='font-weight:normal'>Servers </span><b>C</b><span style='font-weight:
! 72: normal'> and </span><b>J</b><span style='font-weight:normal'> are currently not
! 73: subscribed to this resource. </span></p>
! 74: <p>Learners <b>F</b><span style='font-weight:normal'> and </span><b>G</b><span
! 75: style='font-weight:normal'> have open sessions on server </span><b>I</b><span
! 76: style='font-weight:normal'>, and the new resource is immediately available to
! 77: them. </span></p>
! 78: <p>Learner <b>H</b><span style='font-weight:normal'> tries to connect to server
! 79: </span><b>I</b><span style='font-weight:normal'> for a new session, however,
! 80: the machine is not reachable, so he connects to another Access Server </span><b>J</b><span style='font-weight:normal'>
! 81: instead. This server currently does not have all necessary resources locally
! 82: present to host learner </span><b>H</b><span style='font-weight:normal'>,
! 83: but subscribes to them and replicates them as they are accessed by </span><b>H</b><span
! 84: style='font-weight:normal'>. </span></p>
! 85: <p>Learner <b>H</b><span style='font-weight:normal'> solves a problem on server
! 86: </span><b>J</b><span style='font-weight:normal'>. Library Server </span><b>E</b><span style='font-weight:normal'>
! 87: is </span><b>H</b><span
! 88: style='font-weight:normal'>Õs Home Server, so this information gets forwarded
! 89: to </span><b>E</b><span style='font-weight:normal'>, where the records of
! 90: </span><b>H</b><span
! 91: style='font-weight:normal'> are updated. </span></p>
! 92: <h3><a name="_Toc514840840"></a><a name="_Toc421867042">lonc/lond/lonnet</a></h3>
! 93: <p><b>Fig. 1.1.2</b><span style='font-weight:normal'> elaborates on the details
! 94: of this network infrastructure. </span></p>
! 95: <p><b>Fig. 1.1.2A</b><span style='font-weight:normal'> depicts three servers
! 96: (</span><b>A</b><span style='font-weight:normal'>, </span><b>B</b><span
! 97: style='font-weight:normal'> and </span><b>C</b><span style='font-weight:normal'>,
! 98: </span><b>Fig. 1.1.2A</b><span style='font-weight:normal'>) and a client who
! 99: has a session on server </span><b>C.</b></p>
! 100: <p>As <b>C</b><span style='font-weight:normal'> accesses different resources
! 101: in the system, different handlers, which are incorporated as modules into
! 102: the child processes of the web server software, process these requests.</span></p>
! 103: <p>Our current implementation uses <span style='font-family:
! 104: "Courier New"'>mod_perl</span> inside of the Apache web server software. As an
! 105: example, server <b>C</b><span style='font-weight:normal'> currently has four
! 106: active web server software child processes. The chain of handlers dealing
! 107: with a certain resource is determined by both the server content resource
! 108: area (see below) and the MIME type, which in turn is determined by the URL
! 109: extension. For most URL structures, both an authentication handler and a content
! 110: handler are registered.</span></p>
! 111: <p>Handlers use a common library <span style='font-family:"Courier New"'>lonnet</span>
! 112: to interact with both locally present temporary session data and data across
! 113: the server network. For example, <span style='font-family:"Courier New"'>lonnet</span>
! 114: provides routines for finding the home server of a user, finding the server
! 115: with the lowest loadavg, sending simple command-reply sequences, and sending
! 116: critical messages such as a homework completion, etc. For a non-critical message,
! 117: the routines reply with a simple Òconnection lostÓ if the message could not
! 118: be delivered. For critical messages,<i> </i><span style='font-family:
! 119: "Courier New";font-style:normal'>lonnet</span><i> </i><span style='font-style:
! 120: normal'>tries to re-establish</span><i> </i><span style='font-style:normal'>connections,
! 121: re-send the command, etc. If no valid reply could be received, it answers
! 122: Òconnection deferredÓ and stores the message in</span><i> </i><span
! 123: style='font-style:normal'>buffer space to be sent</span><i> </i><span
! 124: style='font-style:normal'>at a later point in time. Also, failed critical messages
! 125: are logged.</span></p>
! 126: <p>The interface between <span style='font-family:"Courier New"'>lonnet</span>
! 127: and the Network is established by a multiplexed UNIX domain socket, denoted
! 128: DS in <b>Fig. 1.1.2A</b><span style='font-weight:normal'>. The rationale behind
! 129: this rather involved architecture is that httpd processes (Apache children)
! 130: dynamically come and go on the timescale of minutes, based on workload and
! 131: number of processed requests. Over the lifetime of an httpd child, however,
! 132: it has to establish several hundred connections to several different servers
! 133: in the Network.</span></p>
! 134: <p>On the other hand, establishing a TCP/IP connection is resource consuming
! 135: for both ends of the line, and to optimize this connectivity between different
! 136: servers, connections in the Network are designed to be persistent on the timescale
! 137: of months, until either end is rebooted. This mechanism will be elaborated
! 138: on below.</p>
! 139: <p>Establishing a connection to a UNIX domain socket is far less resource consuming
! 140: than the establishing of a TCP/IP connection. <span
! 141: style='font-family:"Courier New"'>lonc</span> is a proxy daemon that forks off
! 142: a child for every server in the Network. . Which servers are members of the
! 143: Network is determined by a lookup table, which <b>Fig. 1.1.2B</b><span
! 144: style='font-weight:normal'> is an example of. In order, the entries denote an
! 145: internal name for the server, the domain of the server, the type of the server,
! 146: the host name and the IP address.</span></p>
! 147: <p>The <span style='font-family:"Courier New"'>lonc</span> parent process maintains
! 148: the population and listens for signals to restart or shutdown, as well as
! 149: <i>USR1</i><span style='font-style:normal'>. Every child establishes a multiplexed
! 150: UNIX domain socket for its server and opens a TCP/IP connection to the </span><span style='font-family:"Courier New"'>lond</span>
! 151: daemon (discussed below) on the remote machine, which it keeps alive.<i> </i><span
! 152: style='font-style:normal'>If the connection is interrupted, the child dies, whereupon
! 153: the parent makes several attempts to fork another child for that server. </span></p>
! 154: <p>When starting a new child (a new connection), first an init-sequence is carried
! 155: out, which includes receiving the information from the remote <span style='font-family:"Courier New"'>lond</span>
! 156: which is needed to establish the 128-bit encryption key Ð the key is different
! 157: for every connection. Next, any buffered (delayed) messages for the server
! 158: are sent.</p>
! 159: <p>In normal operation, the child listens to the UNIX socket, forwards requests
! 160: to the TCP connection, gets the reply from <span
! 161: style='font-family:"Courier New"'>lond</span>, and sends it back to the UNIX socket.
! 162: Also, <span style='font-family:"Courier New"'>lonc</span> takes care to the
! 163: encryption and decryption of messages.</p>
! 164: <p><span style='font-family:"Courier New"'>lonc</span> was build by putting
! 165: a non-forking multiplexed UNIX domain socket server into a framework that
! 166: forks a TCP/IP client for every remote <span style='font-family:
! 167: "Courier New"'>lond</span>.</p>
! 168: <p><span style='font-family:"Courier New"'>lond</span> is the remote end of
! 169: the TCP/IP connection and acts as a remote command processor. It receives
! 170: commands, executes them, and sends replies. In normal operation,<i> </i><span
! 171: style='font-style:normal'>a </span><span style='font-family:"Courier New"'>lonc</span>
! 172: child is constantly connected to a dedicated <span style='font-family:"Courier New"'>lond</span>
! 173: child on the remote server, and the same is true vice versa (two persistent
! 174: connections per server combination). </p>
! 175: <p><span style='font-family:"Courier New"'>lond</span><i> </i><span style='font-style:normal'>listens
! 176: to a TCP/IP port (denoted P in <b>Fig. 1.1.2A</b></span>) and forks off enough
! 177: child processes to have one for each other server in the network plus two
! 178: spare children. The parent process maintains the population and listens for
! 179: signals to restart or shutdown. Client servers are authenticated by IP<i>.</i></p>
! 180: <br
! 181: clear=ALL style='page-break-before:always'>
! 182: <p><span style='font-size:14.0pt'> <img width=432 height=492
! 183: src="Session%20One_files/image004.jpg" v:shapes="_x0000_i1026"> </span></p>
! 184: <p><span style='font-size:14.0pt'><b>Fig. 1.1.2A</b></span><span
! 185: style='font-size:14.0pt'> Ð Overview of Network Communication</span></p>
! 186: <p>When a new client server comes online<i>,</i><span
! 187: style='font-style:normal'> </span><span style='font-family:"Courier New"'>lond</span>
! 188: sends a signal<i> USR1 </i><span style='font-style:normal'>to </span><span
! 189: style='font-family:"Courier New"'>lonc</span>, whereupon <span
! 190: style='font-family:"Courier New"'>lonc</span> tries again to reestablish all lost
! 191: connections, even if it had given up on them before Ð a new client connecting
! 192: could mean that that machine came online again after an interruption.</p>
! 193: <p>The gray boxes in <b>Fig. 1.1.2A</b><span style='font-weight:
! 194: normal'> denote the entities involved in an example transaction of the Network.
! 195: The Client is logged into server </span><b>C</b><span style='font-weight:normal'>,
! 196: while server </span><b>B</b><span style='font-weight:normal'> is her Home
! 197: Server. Server </span><b>C</b><span style='font-weight:normal'> can be an
! 198: Access Server or a Library Server, while server </span><b>B</b><span
! 199: style='font-weight:normal'> is a Library Server. She submits a solution to a homework
! 200: problem, which is processed by the appropriate handler for the MIME type ÒproblemÓ.
! 201: Through </span><span style='font-family:"Courier New"'>lonnet</span>, the
! 202: handler writes information about this transaction to the local session data.
! 203: To make a permanent log entry, <span style='font-family:"Courier New"'>lonnet
! 204: </span>establishes a connection to the UNIX domain socket for server <b>B</b><span
! 205: style='font-weight:normal'>. </span><span style='font-family:"Courier New"'>lonc</span>
! 206: receives this command, encrypts it, and sends it through the persistent TCP/IP
! 207: connection to the TCP/IP port of the remote <span style='font-family:"Courier New"'>lond</span>.
! 208: <span style='font-family:"Courier New"'>lond</span> decrypts the command,
! 209: executes it by writing to the permanent user data files of the client, and
! 210: sends back a reply regarding the success of the operation. If the operation
! 211: was unsuccessful, or the connection would have broken down, <span style='font-family:
! 212: "Courier New"'>lonc</span> would write the command into a FIFO buffer stack to
! 213: be sent again later. <span style='font-family:"Courier New"'>lonc</span> now
! 214: sends a reply regarding the overall success of the operation to <span
! 215: style='font-family:"Courier New"'>lonnet</span> via the UNIX domain port, which
! 216: is eventually received back by the handler.</p>
! 217: <h3><a name="_Toc514840841"></a><a name="_Toc421867043">Scalability and Performance
! 218: Analysis</a></h3>
! 219: <p>The scalability was tested in a test bed of servers between different physical
! 220: network segments, <b>Fig. 1.1.2B</b><span style='font-weight:
! 221: normal'> shows the network configuration of this test.</span></p>
! 222: <table border=1 cellspacing=0 cellpadding=0>
! 223: <tr>
! 224: <td width=443 valign=top class="Normal"> <p><span style='font-family:"Courier New"'>msul1:msu:library:zaphod.lite.msu.edu:35.8.63.51</span></p>
! 225: <p><span style='font-family:"Courier New"'>msua1:msu:access:agrajag.lite.msu.edu:35.8.63.68</span></p>
! 226: <p><span style='font-family:"Courier New"'>msul2:msu:library:frootmig.lite.msu.edu:35.8.63.69</span></p>
! 227: <p><span style='font-family:"Courier New"'>msua2:msu:access:bistromath.lite.msu.edu:35.8.63.67</span></p>
! 228: <p><span style='font-family:"Courier New"'>hubl14:hub:library:hubs128-pc-14.cl.msu.edu:35.8.116.34</span></p>
! 229: <p><span style='font-family:"Courier New"'>hubl15:hub:library:hubs128-pc-15.cl.msu.edu:35.8.116.35</span></p>
! 230: <p><span style='font-family:"Courier New"'>hubl16:hub:library:hubs128-pc-16.cl.msu.edu:35.8.116.36</span></p>
! 231: <p><span style='font-family:"Courier New"'>huba20:hub:access:hubs128-pc-20.cl.msu.edu:35.8.116.40</span></p>
! 232: <p><span style='font-family:"Courier New"'>huba21:hub:access:hubs128-pc-21.cl.msu.edu:35.8.116.41</span></p>
! 233: <p><span style='font-family:"Courier New"'>huba22:hub:access:hubs128-pc-22.cl.msu.edu:35.8.116.42</span></p>
! 234: <p><span style='font-family:"Courier New"'>huba23:hub:access:hubs128-pc-23.cl.msu.edu:35.8.116.43</span></p>
! 235: <p><span style='font-family:"Courier New"'>hubl25:other:library:hubs128-pc-25.cl.msu.edu:35.8.116.45</span></p>
! 236: <p><span style='font-family:"Courier New"'>huba27:other:access:hubs128-pc-27.cl.msu.edu:35.8.116.47</span></p></td>
! 237: </tr>
! 238: </table>
! 239: <p><span style='font-size:14.0pt'><b>Fig. 1.1.2B</b></span><span
! 240: style='font-size:14.0pt'> Ð Example of Hosts Lookup Table </span><span
! 241: style='font-size:9.0pt;font-family:"Courier New"'>/home/httpd/lonTabs/hosts.tab</span></p>
! 242: <p>In the first test,<span style='layout-grid-mode:line'> the simple </span><span style='font-family:"Courier New";layout-grid-mode:line'>ping</span><span
! 243: style='layout-grid-mode:line'> command was used. The </span><span
! 244: style='font-family:"Courier New";layout-grid-mode:line'>ping</span><span
! 245: style='layout-grid-mode:line'> command is used to test connections and yields
! 246: the server short name as reply. In this scenario, </span><span style='font-family:"Courier New";layout-grid-mode:
! 247: line'>lonc</span><span style='layout-grid-mode:line'> was expected to be the speed-determining
! 248: step, since </span><span style='font-family:"Courier New";
! 249: layout-grid-mode:line'>lond</span><span style='layout-grid-mode:line'> at the
! 250: remote end does not need any disk access to reply. The graph <b>Fig.
! 251: 1.1.2C</b></span><span style='layout-grid-mode:
! 252: line'> shows number of seconds till completion versus number of processes issuing
! 253: 10,000 ping commands each against one Library Server (450 MHz Pentium II in
! 254: this test, single IDE HD). For the solid dots, the processes were concurrently
! 255: started on <i>the same</i></span><span style='layout-grid-mode:
! 256: line'> Access Server and the time was measured till the processes finished Ð all
! 257: processes finished at the same time. One Access Server (233 MHz Pentium II
! 258: in the test bed) can process about 150 pings per second, and as expected,
! 259: the total time grows linearly with the number of pings.</span></p>
! 260: <p><span style='layout-grid-mode:line'>The gray dots were taken with up to seven
! 261: processes concurrently running on <i>different</i></span><span
! 262: style='layout-grid-mode:line'> machines and pinging the same server Ð the processes
! 263: ran fully concurrent, and each process finished as if the other ones were
! 264: not present (about 1000 pings per second). Execution was fully parallel.</span></p>
! 265: <p>In a second test, <span style='font-family:"Courier New"'>lond</span> was
! 266: the speed-determining step Ð 10,000 <span style='font-family:"Courier New"'>put</span>
! 267: commands each were issued first from up to seven concurrent processes on the
! 268: same machine, and then from up to seven processes on different machines. The
! 269: <span
! 270: style='font-family:"Courier New"'>put</span> command requires data to be written
! 271: to the permanent record of the user on the remote server.</p>
! 272: <p>In particular, one <span style='font-family:"Courier New"'>"put"</span>
! 273: request meant that the process on the Access Server would connect to the UNIX
! 274: domain socket dedicated to the library server, <span style='font-family:"Courier New"'>lonc</span>
! 275: would take the data from there, shuffle it through the persistent TCP connection,
! 276: <span style='font-family:"Courier New"'>lond</span> on the remote library
! 277: server would take the data, write to disk (both to a dbm-file and to a flat-text
! 278: transaction history file), answer "ok", <span
! 279: style='font-family:"Courier New"'>lonc</span> would take that reply and send it
! 280: to the domain socket, the process would read it from there and close the domain-socket
! 281: connection.</p>
! 282: <p><span style='font-size:14.0pt'> <img width=220 height=190
! 283: src="Session%20One_files/image005.jpg" v:shapes="_x0000_i1027"> </span></p>
! 284: <p><span style='font-size:14.0pt'><b>Fig. 1.1.2C</b></span><span
! 285: style='font-size:14.0pt'> Ð Benchmark on Parallelism of Server-Server Communication
! 286: (no disk access)</span></p>
! 287: <p>The graph <b>Fig. 1.1.2D</b><span style='font-weight:normal'> shows the results.
! 288: Series 1 (solid black diamond) is the result of concurrent processes on the
! 289: same server Ð all of these are handled by the same server-dedicated </span><span style='font-family:"Courier New"'>lond-</span>child,
! 290: which lets the total amount of time grow linearly.</p>
! 291: <p><span style='font-size:14.0pt'> <img width=432 height=311
! 292: src="Session%20One_files/image007.jpg" v:shapes="_x0000_i1028"> </span></p>
! 293: <p><span style='font-size:14.0pt'><b>Fig. 2D</b></span><span
! 294: style='font-size:14.0pt'> Ð Benchmark on Parallelism of Server-Server Communication
! 295: (with disk access as in Fig. 2A)</span></p>
! 296: <p>Series 2 through 8 were obtained from running the processes on different
! 297: Access Servers against one Library Server, each series goes with one server.
! 298: In this experiment, the processes did not finish at the same time, which most
! 299: likely is due to disk-caching on the Library Server Ð <span
! 300: style='font-family:"Courier New"'>lond</span>-children whose datafile was (partly)
! 301: in disk cache finished earlier. With seven processes from seven different
! 302: servers, the operation took 255 seconds till the last process was finished
! 303: for 70,000 <span style='font-family:"Courier New"'>put</span> commands (270
! 304: per second) Ð versus 530 seconds if the processes ran on the same server (130
! 305: per second).</p>
! 306: <h3><a name="_Toc514840842"></a><a name="_Toc421867044">Dynamic Resource Replication</a></h3>
! 307: <p>Since resources are assembled into higher order resources simply by reference,
! 308: in principle it would be sufficient to retrieve them from the respective Home
! 309: Servers of the authors. However, there are several problems with this simple
! 310: approach: since the resource assembly mechanism is designed to facilitate
! 311: content assembly from a large number of widely distributed sources, individual
! 312: sessions would depend on a large number of machines and network connections
! 313: to be available, thus be rather fragile. Also, frequently accessed resources
! 314: could potentially drive individual machines in the network into overload situations.</p>
! 315: <p>Finally, since most resources depend on content handlers on the Access Servers
! 316: to be served to a client within the session context, the raw source would
! 317: first have to be transferred across the Network from the respective Library
! 318: Server to the Access Server, processed there, and then transferred on to the
! 319: client.</p>
! 320: <p>To enable resource assembly in a reliable and scalable way, a dynamic resource
! 321: replication scheme was developed. <b>Fig. 1.1.3</b><span
! 322: style='font-weight:normal'> shows the details of this mechanism.</span></p>
! 323: <p>Anytime a resource out of the resource space is requested, a handler routine
! 324: is called which in turn calls the replication routine (<b>Fig. 1.1.3A</b><span style='font-weight:normal'>).
! 325: As a first step, this routines determines whether or not the resource is currently
! 326: in replication transfer (</span><b>Fig. 1.1.3A,</b><span style='font-weight:normal'>
! 327: </span><b>Step D1a</b><span
! 328: style='font-weight:normal'>). During replication transfer, the incoming data is
! 329: stored in a temporary file, and </span><b>Step D1a</b><span style='font-weight:
! 330: normal'> checks for the presence of that file. If transfer of a resource is actively
! 331: going on, the controlling handler receives an error message, waits for a few
! 332: seconds, and then calls the replication routine again. If the resource is
! 333: still in transfer, the client will receive the message ÒService currently
! 334: not availableÓ.</span></p>
! 335: <p>In the next step (<b>Fig. 1.1.3A, Step D1b</b><span
! 336: style='font-weight:normal'>), the replication routine checks if the URL is locally
! 337: present. If it is, the replication routine returns OK to the controlling handler,
! 338: which in turn passes the request on to the next handler in the chain.</span></p>
! 339: <p>If the resource is not locally present, the Home Server of the resource author
! 340: (as extracted from the URL) is determined (<b>Fig. 1.1.3A, Step D2</b><span style='font-weight:normal'>).
! 341: This is done by contacting all library servers in the authorÕs domain (as
! 342: determined from the lookup table, see </span><b>Fig. 1.1.2B</b><span style='font-weight:normal'>).
! 343: In </span><b>Step D2b</b><span style='font-weight:normal'> a query is sent
! 344: to the remote server whether or not it is the Home Server of the author (in
! 345: our current implementation, an additional cache is used to store already identified
! 346: Home Servers (not shown in the figure)). In Step </span><b>D2c</b><span
! 347: style='font-weight:normal'>, the remote server answers the query with True or
! 348: False. If the Home Server was found, the routine continues, otherwise it contacts
! 349: the next server (</span><b>Step D2a</b><span style='font-weight:normal'>).
! 350: If no server could be found, a ÒFile not FoundÓ error message is issued. In
! 351: our current implementation, in this step the Home Server is also written into
! 352: a cache for faster access if resources by the same author are needed again
! 353: (not shown in the figure). </span></p>
! 354: <br
! 355: clear=ALL style='page-break-before:always'>
! 356: <p><span style='font-size:14.0pt'> <img width=432 height=581
! 357: src="Session%20One_files/image009.jpg" v:shapes="_x0000_i1029"> </span></p>
! 358: <p><span style='font-size:14.0pt'><b>Fig. 1.1.3A</b></span><span
! 359: style='font-size:14.0pt'> Ð Dynamic Resource Replication, subscription</span></p>
! 360: <br
! 361: clear=ALL style='page-break-before:always'>
! 362: <p><span style='font-size:14.0pt'> <img width=432 height=523
! 363: src="Session%20One_files/image011.jpg" v:shapes="_x0000_i1030"> </span></p>
! 364: <p><span style='font-size:14.0pt'><b>Fig. 1.1.3B</b></span><span
! 365: style='font-size:14.0pt'> Ð Dynamic Resource Replication, modification</span></p>
! 366: <p>In <b>Step D3a</b><span style='font-weight:normal'>, the routine sends a
! 367: subscribe command for the URL to the Home Server of the author. The Home Server
! 368: first determines if the resource is present, and if the access privileges
! 369: allow it to be copied to the requesting server (</span><b>Fig. 1.1.3A, Step
! 370: D3b</b><span style='font-weight:normal'>). If this is true, the requesting
! 371: server is added to the list of subscribed servers for that resource (</span><b>Step
! 372: D3c</b><span style='font-weight:normal'>). The Home Server will reply with
! 373: either OK or an error message, which is determined in </span><b>Step D4</b><span style='font-weight:normal'>.
! 374: If the remote resource was not present, the error message ÒFile not FoundÓ
! 375: will be passed on to the client, if the access was not allowed, the error
! 376: message ÒAccess DeniedÓ is passed on. If the operation succeeded, the requesting
! 377: server sends an HTTP request for the resource out of the /</span><span style='font-family:"Courier New"'>raw</span>
! 378: server content resource area of the Home Server.</p>
! 379: <p>The Home Server will then check if the requesting server is part of the network,
! 380: and if it is subscribed to the resource (<b>Step D5b</b><span
! 381: style='font-weight:normal'>). If it is, it will send the resource via HTTP to
! 382: the requesting server without any content handlers processing it (</span><b>Step
! 383: D5c</b><span style='font-weight:normal'>). The requesting server will store
! 384: the incoming data in a temporary data file (</span><b>Step D5a</b><span
! 385: style='font-weight:normal'>) Ð this is the file that </span><b>Step D1a</b><span
! 386: style='font-weight:normal'> checks for. If the transfer could not complete, and
! 387: appropriate error message is sent to the client (</span><b>Step D6</b><span
! 388: style='font-weight:normal'>). Otherwise, the transferred temporary file is renamed
! 389: as the actual resource, and the replication routine returns OK to the controlling
! 390: handler (</span><b>Step D7</b><span style='font-weight:normal'>). </span></p>
! 391: <p><b>Fig. 1.1.3B</b><span style='font-weight:normal'> depicts the process
! 392: of modifying a resource. When an author publishes a new version of a resource,
! 393: the Home Server will contact every server currently subscribed to the resource
! 394: (</span><b>Fig. 1.1.3B, Step U1</b><span style='font-weight:normal'>), as
! 395: determined from the list of subscribed servers for the resource generated
! 396: in </span><b>Fig. 1.1. 3A, Step D3c</b><span style='font-weight:normal'>.
! 397: The subscribing servers will receive and acknowledge the update message (</span><b>Step
! 398: U1c</b><span
! 399: style='font-weight:normal'>). The update mechanism finishes when the last subscribed
! 400: server has been contacted (messages to unreachable servers are buffered).</span></p>
! 401: <p>Each subscribing server will check if the resource in question had been accessed
! 402: recently, that is, within a configurable amount of time (<b>Step U2</b><span style='font-weight:normal'>).
! 403: </span></p>
! 404: <p>If the resource had not been accessed recently, the local copy of the resource
! 405: is deleted (<b>Step U3a</b><span style='font-weight:normal'>) and an unsubscribe
! 406: command is sent to the Home Server (</span><b>Step U3b</b><span
! 407: style='font-weight:normal'>). The Home Server will check if the server had indeed
! 408: originally subscribed to the resource (</span><b>Step U3c</b><span
! 409: style='font-weight:normal'>) and then delete the server from the list of subscribed
! 410: servers for the resource (</span><b>Step U3d</b><span
! 411: style='font-weight:normal'>).</span></p>
! 412: <p>If the resource had been accessed recently, the modified resource will be
! 413: copied over using the same mechanism as in <b>Step D5a</b><span
! 414: style='font-weight:normal'> through </span><b>D7</b><span style='font-weight:
! 415: normal'> of </span><b>Fig. 1.1.3A</b><span style='font-weight:normal'> (</span><b>Fig.
! 416: 1.1.3B</b><span style='font-weight:normal'>, </span><b>Steps U4a </b><span
! 417: style='font-weight:normal'>through</span><b> U6</b><span style='font-weight:
! 418: normal'>).</span></p>
! 419: <p><span style='font-family:Arial'>Load Balancing</span></p>
! 420: <p><span style='font-family:"Courier New"'>lond</span> provides a function to
! 421: query the serverÕs current <span style='font-family:"Courier New"'>loadavg</span><span
! 422: style='font-size:14.0pt'>. </span>As a configuration parameter, one can determine
! 423: the value of <span style='font-family:"Courier New"'>loadavg,</span> which
! 424: is to be considered 100%, for example, 2.00. </p>
! 425: <p>Access servers can have a list of spare access servers, <span
! 426: style='font-size:9.0pt;font-family:"Courier New"'>/home/httpd/lonTabs/spares.tab</span>,
! 427: to offload sessions depending on own workload. This check happens is done
! 428: by the login handler. It re-directs the login information and session to the
! 429: least busy spare server if itself is overloaded. An additional round-robin
! 430: IP scheme possible. See <b>Fig. 1.1.4</b><span style='font-weight:normal'>
! 431: for an example of a load-balancing scheme.</span></p>
! 432: <p><span style='font-size:28.0pt;color:green'> <img width=241 height=139
! 433: src="Session%20One_files/image013.jpg" v:shapes="_x0000_i1031"> </span></p>
! 434: <p><span
! 435: style='font-size:14.0pt'><b>Fig. 1.1.4 Ð </b></span><span style='font-size:14.0pt'>Example
! 436: of Load Balancing</span><span style='font-size:14.0pt'> <b><i><br
! 437: clear=ALL style='page-break-before:always'>
! 438: </i></b></span></p>
! 439: </div>
! 440: <br
! 441: clear=ALL style='page-break-before:always;'>
! 442: <div class=Section2> </div>
! 443: </body>
! 444: </html>
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/back.gif){kind=icon}
Return to SessionOne.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [LON-CAPA] / doc / gutshtml