home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / protocol / tcpip / 6036 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  8.2 KB
  1. Xref: sparky comp.protocols.tcp-ip:6036 comp.protocols.nfs:3171
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!cronkite.Central.Sun.COM!texsun!exucom.exu.ericsson.se!exu.ericsson.se!exudnw
  3. From: exudnw@exu.ericsson.se (Dave Williams)
  4. Newsgroups: comp.protocols.tcp-ip,comp.protocols.nfs
  5. Subject: backbone routers and topology
  6. Keywords: FDDI ethernet router backbone topology performance routed
  7. Message-ID: <1993Jan20.181656.19870@exu.ericsson.se>
  8. Date: 20 Jan 93 18:16:56 GMT
  9. Sender: news@exu.ericsson.se
  10. Reply-To: exudnw@exu.ericsson.se (Dave Williams)
  11. Organization: Ericsson Network Systems
  12. Lines: 136
  13. Nntp-Posting-Host: floyd.exu.ericsson.se
  14. X-Disclaimer: This article was posted by a user at Ericsson.
  15.               Any opinions expressed are strictly those of the
  16.               user and not necessarily those of Ericsson.
  17.  
  18. This may be in some FAQ somewhere, but I can't find it.
  19.  
  20. I'd like to hear from any large sites that have routers configured as 
  21. backbones.  There's lots of marketing hype from the router companies
  22. on why you "need" to do this, but very little in the way of hard info
  23. on configuration, performance and pitfalls.
  24.  
  25. Our current configuration consists of about 400 SPARC clients fed by 13 Sun
  26. 4/490 servers. Each server has multiple NC400 Network Co-processors (one per
  27. client network), 2 IPI controllers and 6-8 IPI disks (sime Saber's, some Elites).
  28.  
  29. We are currently setup in a straight hierarchical topology that looks something 
  30. like this: 
  31.  
  32.                                                                            
  33.                             
  34.                    server backbone (ethernet)                                               
  35.      +-----------------------+----------------------+-----> to existing router 
  36.      |                       |                      |      (3270, x.25, etc.)
  37.      |                       |                      |        
  38.  +-------+               +-------+              +-------+   
  39.  | 490   |               |  490  |              |  490  |
  40.  |  1    |               |   2   |              |   n   |
  41.  +-+-+-+-+               +-+-+-+-+              +-+-+-+-+ 
  42.    | | |  NC400 I/F's      | | |                  | | |    
  43.  
  44.   client                   client                 client                         
  45.   networks                 networks               networks                                    
  46.                                                                            
  47.                                                                             
  48.                                                                                
  49. We typically put a maximum of 25 diskless w/s on each client network and get
  50. about 60 clients per server.  We run NIS, DNS, automounter, etc. and the whole
  51. thing works pretty well. We are currenly in the process of adding about 200 
  52. disks to make about half of our client population dataless, the remainder is 
  53. Sun SLC's :~(
  54.  
  55. We started questioning this layout when we noticed our "server backbone" was
  56. hitting high % of possible lan bandwidth at peak hours of the day. We already
  57. had common data replicated on multiple servers but it's too big to copy to
  58. all of them. We thought about this for a bit and came up with the following 
  59. possible solutions:
  60.  
  61. 1) Put a large router (Cisco AGS+, Alantec, Wellfleet, etc.) in place of the 
  62.    server backbone. These typically have near-gigabit backplanes and have *got* 
  63.    to be faster than our current Ethernet 10 MB/sec "governor".
  64.  
  65. 2) Connect the server's client networks to both the clients and the router
  66.    and turn off routing in the servers. We did some informal tests and found
  67.    that a single client could cause 10% server CPU load just routing a single 
  68.    "find" command. I've always heard that Suns made poor routers, but could 
  69.    never find any hard data on the subject.
  70.  
  71. 3) Use the router as an FDDI connection to a single server containing all 
  72.    replicated filesystems. We thought this could be a SS10/41 with multiple
  73.    fast SCSI disks. This would free up all the space currently taken up by
  74.    replicated data spread over all the servers while providing for faster 
  75.    access and better configuration control.
  76.  
  77.    One question that looms is whether the replicated (read mostly) data server
  78.    should use multiple ethernet I/F's, one to each client network (using more 
  79.    than one server) or use FDDI straight into the router.  We don't have a lot
  80.    of FDDI experience to guide us.
  81.  
  82.    Is the answer the same for database (read-write, non-NFS) servers as it is for 
  83.    "read mostly" (NFS) nodes?  Which is better (for NFS and/or socket DB access), 
  84.    multiple ethernet segments in a "matrix" topology spread over each client 
  85.    network or single FDDI interfaces from each server into the router?
  86.  
  87. We would end up with something like this:
  88.  
  89.                             
  90.                          "old" server backbone 
  91.            (Left intact for sanity and backup if router ever blows)                                               
  92.       +--------------------------+-------------------------+-------------+                                                                      
  93.       |                          |                         |             | 
  94.       |                          |                         |             |
  95.    +-------+                  +-------+                 +-------+        | 
  96.    | 490   |                  |  490  |                 |  490  |        |
  97.    |  1    |                  |   2   |                 |   n   |        |
  98.    +-+-+-+-+                  +-+-+-+-+                 +-+-+-+-+        |
  99.      | | |   NC400 I/F's        | | |                     | | |          |  
  100.     client                     client                    client          | 
  101.     networks                   networks                  networks        | 
  102.      | | |                      | | |                     | | |          |  
  103.  +---+-+-+----------------------+-+-+---------------------+-+-+----+     | 
  104.  |    enet                       enet                      enet    |     |
  105.  |                                                             enet+-----+
  106.  |                         router "backbone"                       |
  107.  |                                                      FDDI/CDDI  |
  108.  +-----------------------------+----------------------------++-----+ 
  109.                                |                            ||       
  110.                            X.25,3270                  +-----++----+ 
  111.                               etc.                    | replicated|
  112.                                                       |   data    |
  113.                                                       | server(s) |
  114.                                                       |           |
  115.                                                       +-----------+
  116.  
  117.  
  118. Are we on the trail of something good here or have we all been locked up in
  119. the hacketorium too long?  
  120.  
  121. Specifically:
  122.  
  123. 1) Is turning off routing on the servers a *good* thing?
  124.  
  125. 2) What will break?
  126.  
  127. 3) One question that looms is whether the replicated (read mostly) data server
  128.    should use multiple ethernet I/F's, one to each client network (using more 
  129.    than one server to cover all of the client networks) or use FDDI straight 
  130.    into the router.  We don't have a lot of FDDI experience to guide us.
  131.  
  132.    Is the answer the same for database (read-write) servers as it is for "read 
  133.    mostly" nodes?  Which is better (for NFS and/or socket DB access), multiple 
  134.    ethernet segments in a "matrix" topology spread over each client network
  135.    or a single FDDI interface into the router for each type of server?
  136.  
  137. 4) What are we overlooking?
  138.  
  139. 5) Are there any other large sites doing this kind of stuff?
  140.  
  141.  
  142. Any comments/suggestions appreciated.
  143.  
  144.  
  145. = exudnw@exu.ericsson.se       (214)907-7928                            =
  146. = David Williams              "You can't win, you can't break even,     =
  147. = Ericsson Network Systems     and you can't quit"                      =
  148. = Richardson, TX 75081                                  my opinions...  =    
  149. --
  150. = exudnw@exu.ericsson.se                                                =
  151. = David Williams              "You can't win, you can't break even,     =
  152. = Ericsson Network Systems     and you can't quit"                      =
  153. = Richardson, TX 75081                                  my opinions...  =
  154.