docs/Samba-Guide/Chap11-HighAvailability.xml

   1 <?xml version="1.0" encoding="iso-8859-1"?>
   2 <!DOCTYPE book PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
   3
   4 <chapter id="HA">
   5   <title>Performance, Reliability, and Availability</title>
   6
   7     <para><indexterm>
   8         <primary>performance</primary>
   9       </indexterm><indexterm>
  10         <primary>reliability</primary>
  11       </indexterm><indexterm>
  12         <primary>availability</primary>
  13       </indexterm>
  14         Well, you have reached the chapter before the Appendix. It is customary to attempt
  15         to wrap up the theme and contents of a book in what is generally regarded as the
  16         chapter that should draw conclusions. This book is a suspense thriller and since
  17         the plot of the stories told mostly lead you to bigger, better Samba-3 networking
  18         solutions, it is perhaps appropriate to close this book with a few pertinent comments
  19         regarding some of the things everyone can do to deliver a reliable Samba-3 network.
  20         </para>
  21
  22         <blockquote><attribution>Anonymous</attribution><para>
  23         In a world so full of noise, how can the sparrow be heard?
  24         </para></blockquote>
  25
  26 <sect1>
  27         <title>Introduction</title>
  28
  29       <para><indexterm>
  30           <primary>clustering</primary>
  31         </indexterm>
  32         The sparrow is a small bird whose sounds are drowned out by the noise of the busy
  33         world it lives in. Likewise, the simple steps that can be taken to improve the
  34         reliability and availability of a Samba network are often drowned out by the volume
  35         of discussions about grandiose Samba clustering designs. This is not intended to
  36         suggest that clustering is not important, because clearly it is. This chapter does not devote
  37         itself to discussion of clustering because each clustering methodology uses its own
  38         custom tools and methods. Only passing comments are offered concerning these methods.
  39         </para>
  40
  41       <para><indexterm>
  42           <primary>cluster</primary>
  43         </indexterm><indexterm>
  44           <primary>samba cluster</primary>
  45         </indexterm><indexterm>
  46           <primary>scalability</primary>
  47         </indexterm>
  48 <ulink url="http://www.google.com/search?hl=en&amp;lr=&amp;ie=ISO-8859-1&amp;q=samba+cluster&amp;btnG=Google+Search">A search</ulink>
  49         for <quote>samba cluster</quote> produced 71,600 hits. And a search for <quote>highly available samba</quote>
  50         and <quote>highly available windows</quote> produced an amazing number of references.
  51         It is clear from the resources on the Internet that Windows file and print services
  52         availability, reliability, and scalability are of vital interest to corporate network users.
  53         </para>
  54
  55       <para><indexterm>
  56           <primary>performance</primary>
  57         </indexterm>
  58         So without further background, you can review a checklist of simple steps that
  59         can be taken to ensure acceptable network performance while keeping costs of ownership
  60         well under control.
  61         </para>
  62
  63 </sect1>
  64
  65 <sect1>
  66         <title>Dissection and Discussion</title>
  67
  68       <para><indexterm>
  69           <primary>simple</primary>
  70         </indexterm><indexterm>
  71           <primary>complexities</primary>
  72         </indexterm>
  73         If it is your purpose to get the best mileage out of your Samba servers, there is one rule that
  74         must be obeyed. If you want the best, keep your implementation as simple as possible. You may
  75         well be forced to introduce some complexities, but you should do so only as a last resort.
  76         </para>
  77
  78         <para>
  79         Simple solutions are likely to be easier to get right than are complex ones. They certainly
  80         make life easier for your successor. Simple implementations can be more readily audited than can
  81         complex ones.
  82         </para>
  83
  84       <para><indexterm>
  85           <primary>broken behavior</primary>
  86         </indexterm><indexterm>
  87           <primary>poor performance</primary>
  88         </indexterm>
  89         Problems reported by users fall into three categories: configurations that do not work, those
  90         that have broken behavior, and poor performance. The term <emphasis>broken behavior</emphasis>
  91         means that the function of a partciluar Samba component appears to work sometimes, but not at
  92         others. The resulting intermittent operation is clearly unacceptable. An example of
  93         <emphasis>broken behavior</emphasis> known to many Windows networking users occurs when the
  94         list of Windows machines in MS Explorer changes, sometimes listing machines that are running
  95         and at other times not listing them even though the machines are in use on the network.
  96         </para>
  97
  98       <para><indexterm>
  99           <primary>smbfs</primary>
 100         </indexterm><indexterm>
 101           <primary>smbmnt</primary>
 102         </indexterm><indexterm>
 103           <primary>smbmount</primary>
 104         </indexterm><indexterm>
 105           <primary>smbumnt</primary>
 106         </indexterm><indexterm>
 107           <primary>smbumount</primary>
 108         </indexterm><indexterm>
 109           <primary>front-end</primary>
 110         </indexterm>
 111         A significant number of reports concern problems with the <command>smbfs</command> file system
 112         driver that is part of the Linux kernel, not part of Samba. Users continue to interpret that
 113         <command>smbfs</command> is part of Samba, simply because Samba includes the front-end tools
 114         that are used to manage <command>smbfs</command>-based file service connections. So, just
 115         for the record, the tools <command>smbmnt, smbmount, smbumount,</command> and <command>smbumnt</command> are front-end
 116         facilities to core drivers that are supplied as part of the Linux kernel. These tools share a
 117         common infrastructure with some Samba components, but they are not maintained as part of
 118         Samba and are really foreign to it.
 119         </para>
 120
 121       <para><indexterm>
 122           <primary>cifsfs</primary>
 123         </indexterm>
 124         The new project, <command>cifsfs</command>, is destined to replace <command>smbfs</command>.
 125         It, too, is not part of Samba, even though one of the Samba Team members is a prime mover in
 126         this project.
 127         </para>
 128
 129         <para>
 130         The following table lists typical causes of:
 131         </para>
 132
 133         <itemizedlist>
 134                 <listitem><para>Not Working (NW)</para></listitem>
 135                 <listitem><para>Broken Behavior (BB)</para></listitem>
 136                 <listitem><para>Poor Performance (PP)</para></listitem>
 137         </itemizedlist>
 138
 139
 140         <table id="ProbList">
 141                 <title>Effect of Common Problems</title>
 142                 <tgroup cols="4">
 143                         <colspec align="left"/>
 144                         <colspec align="center"/>
 145                         <colspec align="center"/>
 146                         <colspec align="center"/>
 147                         <thead>
 148                                 <row>
 149                                         <entry><para>Problem</para></entry>
 150                                         <entry><para>NW</para></entry>
 151                                         <entry><para>BB</para></entry>
 152                                         <entry><para>PP</para></entry>
 153                                 </row>
 154                         </thead>
 155                         <tbody>
 156                                 <row>
 157                                         <entry><para>File Locking</para></entry>
 158                                         <entry><para>-</para></entry>
 159                                         <entry><para>X</para></entry>
 160                                         <entry><para>-</para></entry>
 161                                 </row>
 162                                 <row>
 163                                         <entry><para>Hardware Problems</para></entry>
 164                                         <entry><para>X</para></entry>
 165                                         <entry><para>X</para></entry>
 166                                         <entry><para>X</para></entry>
 167                                 </row>
 168                                 <row>
 169                                         <entry><para>Incorrect Authentication</para></entry>
 170                                         <entry><para>X</para></entry>
 171                                         <entry><para>X</para></entry>
 172                                         <entry><para>-</para></entry>
 173                                 </row>
 174                                 <row>
 175                                         <entry><para>Incorrect Configuration</para></entry>
 176                                         <entry><para>X</para></entry>
 177                                         <entry><para>X</para></entry>
 178                                         <entry><para>X</para></entry>
 179                                 </row>
 180                                 <row>
 181                                         <entry><para>LDAP Problems</para></entry>
 182                                         <entry><para>X</para></entry>
 183                                         <entry><para>X</para></entry>
 184                                         <entry><para>-</para></entry>
 185                                 </row>
 186                                 <row>
 187                                         <entry><para>Name Resolution</para></entry>
 188                                         <entry><para>X</para></entry>
 189                                         <entry><para>X</para></entry>
 190                                         <entry><para>X</para></entry>
 191                                 </row>
 192                                 <row>
 193                                         <entry><para>Printing Problems</para></entry>
 194                                         <entry><para>X</para></entry>
 195                                         <entry><para>X</para></entry>
 196                                         <entry><para>-</para></entry>
 197                                 </row>
 198                                 <row>
 199                                         <entry><para>Slow File Transfer</para></entry>
 200                                         <entry><para>-</para></entry>
 201                                         <entry><para>-</para></entry>
 202                                         <entry><para>X</para></entry>
 203                                 </row>
 204                                 <row>
 205                                         <entry><para>Winbind Problems</para></entry>
 206                                         <entry><para>X</para></entry>
 207                                         <entry><para>X</para></entry>
 208                                         <entry><para>-</para></entry>
 209                                 </row>
 210                         </tbody>
 211                 </tgroup>
 212         </table>
 213
 214       <para><indexterm>
 215           <primary>network hygiene</primary>
 216         </indexterm>
 217         It is obvious to all that the first requirement (as a matter of network hygiene) is to eliminate
 218         problems that affect basic network operation. This book has provided sufficient working examples
 219         to help you to avoid all these problems.
 220         </para>
 221
 222 </sect1>
 223
 224 <sect1>
 225         <title>Guidelines for Reliable Samba Operation</title>
 226
 227       <para><indexterm>
 228           <primary>resilient</primary>
 229         </indexterm><indexterm>
 230           <primary>extreme demand</primary>
 231         </indexterm>
 232         Your objective is to provide a network that works correctly, can grow at all times, is resilient
 233         at times of extreme demand, and can scale to meet future needs. The following subject areas provide
 234         pointers that can help you today.
 235         </para>
 236
 237         <sect2>
 238         <title>Name Resolution</title>
 239
 240         <para>
 241         There are three basic current problem areas: bad hostnames, routed networks, and network collisions.
 242         These are covered in the discussion below.
 243         </para>
 244
 245                 <sect3>
 246                 <title>Bad Hostnames</title>
 247
 248           <para><indexterm>
 249               <primary>DHCP</primary>
 250               <secondary>client</secondary>
 251             </indexterm><indexterm>
 252               <primary>netbios name</primary>
 253             </indexterm><indexterm>
 254               <primary>localhost</primary>
 255             </indexterm><indexterm>
 256               <primary>/etc/hosts</primary>
 257             </indexterm><indexterm>
 258               <primary>NetBIOS</primary>
 259             </indexterm>
 260                 When configured as a DHCP client, a number of Linux distributions set the system hostname
 261                 to <constant>localhost</constant>. If the parameter <parameter>netbios name</parameter> is not
 262                 specified to something other than <constant>localhost</constant>, the Samba server appears
 263                 in the Windows Explorer as <constant>LOCALHOST</constant>. Moreover, the entry in the <filename>/etc/hosts</filename>
 264                 on the Linux server points to IP address <constant>127.0.0.1</constant>. This means that
 265                 when the Windows client obtains the IP address of the Samba server called <constant>LOCALHOST</constant>,
 266                 it obtains the IP address <constant>127.0.0.1</constant> and then proceeds to attempt to
 267                 set up a NetBIOS over TCP/IP connection to it. This cannot work, because that IP address is
 268                 the local Windows machine itself. Hostnames must be valid for Windows networking to function
 269                 correctly.
 270                 </para>
 271
 272           <para><indexterm>
 273               <primary>digits</primary>
 274             </indexterm>
 275                 A few sites have tried to name Windows clients and Samba servers with a name that begins
 276                 with the digits 1-9. This does not work either because it may result in the client or
 277                 server attempting to use that name as an IP address.
 278                 </para>
 279
 280           <para><indexterm>
 281               <primary>DNS</primary>
 282               <secondary>name lookup</secondary>
 283             </indexterm><indexterm>
 284               <primary>resolve</primary>
 285             </indexterm>
 286                 A Samba server called <constant>FRED</constant>, in a NetBIOS Domain called <constant>COLLISION</constant>
 287                 in a network environment that is part of the fully qualified Internet domain name space known
 288                 as <constant>parrots.com</constant>, results in DNS name lookups for: <constant>fred.parrots.com</constant>
 289                 and <constant>collision.parrots.com</constant>. It is, therefore, a mistake to name the Domain
 290                 (workgroup) <constant>collision.parrots.com</constant> since this results in DNS lookup
 291                 attempts to resolve: <constant>fred.parrots.com.parrots.com</constant>, which most likely
 292                 fails given that you probably do not have this in your DNS name space.
 293                 </para>
 294
 295           <note><para><indexterm>
 296                 <primary>Active Directory</primary>
 297                 <secondary>realm</secondary>
 298               </indexterm><indexterm>
 299                 <primary>ADS</primary>
 300               </indexterm><indexterm>
 301                 <primary>DNS</primary>
 302               </indexterm>
 303                 An Active Directory realm called <constant>collision.parrots.com</constant> is perfectly okay,
 304                 although it too must be capable of being resolved via DNS, something that functions correctly
 305                 if Windows 200x ADS has been properly installed and configured.
 306                 </para></note>
 307
 308                 </sect3>
 309
 310                 <sect3>
 311                 <title>Routed Networks</title>
 312
 313           <para><indexterm>
 314               <primary>NetBIOS</primary>
 315             </indexterm><indexterm>
 316               <primary>UDP</primary>
 317               <secondary>broadcast</secondary>
 318             </indexterm><indexterm>
 319               <primary>broadcast</primary>
 320             </indexterm>
 321                 NetBIOS networks (Windows networking with NetBIOS over TCP/IP enabled) makes extensive use
 322                 of UDP-based broadcast traffic. You saw that during the exercises in Chapter 1.
 323                 </para>
 324
 325           <para><indexterm>
 326               <primary>routers</primary>
 327             </indexterm><indexterm>
 328               <primary>forwarded</primary>
 329             </indexterm><indexterm>
 330               <primary>multi-subnet</primary>
 331             </indexterm>
 332                 UDP broadcast traffic is not forwarded by routers. This means that NetBIOS broadcast-based
 333                 networking cannot function across routed networks (i.e., multi-subnet networks) unless
 334                 special provisions are made:
 335                 </para>
 336
 337                 <itemizedlist>
 338             <listitem><para><indexterm>
 339                   <primary>LMHOSTS</primary>
 340                 </indexterm><indexterm>
 341                   <primary>remote announce</primary>
 342                 </indexterm><indexterm>
 343                   <primary>remote browse sync</primary>
 344                 </indexterm>
 345                         Either install on every Windows client an LMHOSTS file (located in the directory
 346                         <filename>C:\windows\system32\drivers\etc</filename>). It is also necessary to
 347                         add to the Samba server &smb.conf; file the parameters: <parameter>remote announce</parameter>
 348                         and <parameter>remote browse sync</parameter>. For more information, refer to the on-line
 349                         manual page for the &smb.conf; file.
 350                         </para></listitem>
 351
 352             <listitem><para><indexterm>
 353                   <primary>WINS</primary>
 354                   <secondary>server</secondary>
 355                 </indexterm>
 356                         Or configure Samba as a WINS server, and configure all network clients to use that
 357                         WINS server in their TCP/IP configuration.
 358                         </para></listitem>
 359                 </itemizedlist>
 360
 361           <note><para><indexterm>
 362                 <primary>WINS</primary>
 363                 <secondary>name resolution</secondary>
 364               </indexterm><indexterm>
 365                 <primary>DNS</primary>
 366               </indexterm>
 367                 The use of DNS is not an acceptable substitute for WINS. DNS does not store specific
 368                 information regarding NetBIOS networking particulars that does get stored in the WINS
 369                 name resolution database, and that Windows clients require and depend on.
 370                 </para></note>
 371
 372                 </sect3>
 373
 374                 <sect3>
 375                 <title>Network Collisions</title>
 376
 377           <para><indexterm>
 378               <primary>network</primary>
 379               <secondary>collisions</secondary>
 380             </indexterm><indexterm>
 381               <primary>network</primary>
 382               <secondary>tiemouts</secondary>
 383             </indexterm><indexterm>
 384               <primary>collision rates</primary>
 385             </indexterm><indexterm>
 386               <primary>network</primary>
 387               <secondary>load</secondary>
 388             </indexterm>
 389                 Excessive network activity causes NetBIOS network time-outs. Time-outs may result in
 390                 blue screen of death (BSOD) experiences. High collision rates may be caused by excessive
 391                 UDP broadcast activity, by defective networking hardware, or through excessive network
 392                 loads (another way of saying that the network is poorly designed).
 393                 </para>
 394
 395                 <para>
 396                 The use of WINS is highly recommended to reduce network broadcast traffic, as outlined
 397                 in Chapter 1.
 398                 </para>
 399
 400           <para><indexterm>
 401               <primary>netbios forwarding</primary>
 402             </indexterm><indexterm>
 403               <primary>broadcast storms</primary>
 404             </indexterm><indexterm>
 405               <primary>performance</primary>
 406             </indexterm>
 407                 Under no circumstances should the facility be supported by many routers, known as <constant>NetBIOS
 408                 forwarding</constant>, unless you know exactly what you are doing. Inappropriate use of this
 409                 facility can result in UDP broadcast storms. In one case in 1999, a university network became
 410                 unusable due to this being enabled on all routers. The problem was discovered during performance
 411                 testing of a Samba server. The maximum throughput on a 100-Base-T (100 MBit/sec) network was
 412                 less than 15 KBytes/sec. After the NetBIOS forwarding was turned off, file transfer performance
 413                 immediately returned to 11 MBytes/sec.
 414                 </para>
 415
 416                 </sect3>
 417
 418         </sect2>
 419
 420         <sect2>
 421         <title>Samba Configuration</title>
 422
 423         <para>
 424         As a general rule, the contents of the &smb.conf; file should be kept as simple as possible.
 425         No parameter should be specified unless you know it is essential to operation.
 426         </para>
 427
 428         <para><indexterm>
 429             <primary>document the settings</primary>
 430           </indexterm><indexterm>
 431             <primary>documented</primary>
 432           </indexterm><indexterm>
 433             <primary>optimized</primary>
 434           </indexterm>
 435         Many UNIX administrators like to fully document the settings in the &smb.conf; file. This is a
 436         bad idea because it adds content to the file. The &smb.conf; file is re-read by every <command>smbd</command>
 437         process every time the file time stamp changes (or, on systems where this does not work, every 20 seconds or so).
 438         </para>
 439
 440         <para>
 441         As the size of the &smb.conf; file grows the risk of introduction of parsing errors increases also.
 442         It is recommended to keep a fully documented &smb.conf; file on hand, and then to operate Samba only
 443         with an optimized file.
 444         </para>
 445
 446         <para><indexterm>
 447             <primary>testparm</primary>
 448           </indexterm>
 449         The preferred way to maintain a documented file is to call it something like <filename>smb.conf.master</filename>.
 450         You can generate the optimized file by executing:
 451 <screen>
 452 &rootprompt; testparm -s smb.conf.master > smb.conf
 453 </screen>
 454         You should carefully observe all warnings issued. It is also a good practice to execute the following
 455         command to confirm correct interpretation of the &smb.conf; file contents:
 456 <screen>
 457 &rootprompt; testparm
 458 Load smb config files from /etc/samba/smb.conf
 459 Can't find include file /etc/samba/machine.
 460 Processing section "[homes]"
 461 Processing section "[print$]"
 462 Processing section "[netlogon]"
 463 Processing section "[Profiles]"
 464 Processing section "[printers]"
 465 Processing section "[media]"
 466 Processing section "[data]"
 467 Processing section "[cdr]"
 468 Processing section "[apps]"
 469 Loaded services file OK.
 470 'winbind separator = +' might cause problems with group membership.
 471 Server role: ROLE_DOMAIN_PDC
 472 Press enter to see a dump of your service definitions
 473 </screen>
 474           <indexterm>
 475             <primary>fatal problem</primary>
 476           </indexterm>
 477         You now, of course, press the enter key to complete the command, or else abort it by pressing Ctrl-C.
 478         The important thing to note is the noted Server role, as well as warning messages. Noted configuration
 479         conflicts must be remedied before proceeding. For example, the following error message represents a
 480         common fatal problem:
 481 <screen>
 482 ERROR: both 'wins support = true' and 'wins server = &lt;server list&gt;'
 483 cannot be set in the smb.conf file. nmbd will abort with this setting.
 484 </screen>
 485         </para>
 486
 487         <para><indexterm>
 488             <primary>performance degradation</primary>
 489           </indexterm><indexterm>
 490             <primary>socket options</primary>
 491           </indexterm><indexterm>
 492             <primary>socket address</primary>
 493           </indexterm>
 494         There are two parameters that can cause severe network performance degradation, <parameter>socket options</parameter>
 495         and <parameter>socket address</parameter>. The <parameter>socket options</parameter> parameter was often necessary
 496         when Samba was used with the Linux 2.2.x kernels. Later kernels are largely self-tuning and seldom benefit from
 497         this parameter being set. Do not use either parameter unless it has been proven necessary to use them.
 498         </para>
 499
 500         <para><indexterm>
 501             <primary>strict sync</primary>
 502           </indexterm><indexterm>
 503             <primary>sync always</primary>
 504           </indexterm><indexterm>
 505             <primary>severely degrade</primary>
 506           </indexterm><indexterm>
 507             <primary>network</primary>
 508             <secondary>performance</secondary>
 509           </indexterm>
 510         Another &smb.conf; parameter that may cause severe network performance degradation is the
 511         <parameter>strict sync</parameter> parameter. Do not use this at all. There is no good reason
 512         to use this with any modern Windows client. The <parameter>strict sync</parameter> is often
 513         used together with the <parameter>sync always</parameter> parameter. This, too, can severely
 514         degrade network performance, so do not set it or if you must, do so with caution.
 515         </para>
 516
 517         <para><indexterm>
 518             <primary>opportunistic locking</primary>
 519           </indexterm><indexterm>
 520             <primary>file caching</primary>
 521           </indexterm><indexterm>
 522             <primary>caching</primary>
 523           </indexterm><indexterm>
 524             <primary>oplocks</primary>
 525           </indexterm>
 526         Finally, many network administrators deliberately disable opportunistic locking support. While this
 527         does not degrade Samba performance, it significantly degrades Windows client performance because
 528         this disables local file caching on Windows clients and forces every file read and written to
 529         invoke a network read or write call. If for any reason you must disable oplocks (opportunistic locking)
 530         support, do so on the share on which it is required only. That way, all other shares can provide
 531         oplock support for operations that are tolerant of it. See <link linkend="ch12dblck"/> for more
 532         information.
 533         </para>
 534
 535         </sect2>
 536
 537         <sect2>
 538         <title>Use and Location of BDCs</title>
 539
 540         <para><indexterm>
 541             <primary>BDC</primary>
 542           </indexterm><indexterm>
 543             <primary>PDC</primary>
 544           </indexterm><indexterm>
 545             <primary>routed network</primary>
 546           </indexterm><indexterm>
 547             <primary>wide-area network</primary>
 548           </indexterm><indexterm>
 549             <primary>network segment</primary>
 550           </indexterm>
 551         On a network segment where there is a PDC and a BDC, the BDC carries the bulk of the network logon
 552         processing. If the BDC is a heavily loaded server, the PDC carries a greater proportion of
 553         authentication and logon processing. When a sole BDC on a routed network segment gets heavily
 554         loaded, it is possible that network logon requests and authentication requests may be directed
 555         to a BDC on a distant network segment. This significantly hinders wide-area network operations
 556         and is undesirable.
 557         </para>
 558
 559         <para><indexterm>
 560             <primary>Domain Member</primary>
 561           </indexterm><indexterm>
 562             <primary>Domain Controller</primary>
 563           </indexterm>
 564         As a general guide, instead of adding Domain Member servers to a network, you would be better advised
 565         to add BDCs until there are fewer than 30 Windows clients per BDC. Beyond that ratio, you should add
 566         Domain Member servers. This practice ensures that there is always sufficient Domain Controllers
 567         to handle logon requests and authentication traffic.
 568         </para>
 569
 570         </sect2>
 571
 572         <sect2>
 573         <title>Use One Consistent Version of MS Windows Client</title>
 574
 575         <para>
 576         Every network client has its own peculiarities. From a management perspective, it is easier to deal
 577         with one version of MS Windows that is maintained to a consistent update level, than it is to deal
 578         with a mixture of clients.
 579         </para>
 580
 581         <para>
 582         On a number of occasions, particular Microsoft service pack updates of a Windows server or client
 583         have necessitated special handling from the Samba server end. If you want to remain sane, keep you
 584         client workstation configurations consistent.
 585         </para>
 586
 587         </sect2>
 588
 589         <sect2>
 590         <title>For Scalability, Use SAN Based Storage on Samba Servers</title>
 591
 592         <para><indexterm>
 593             <primary>SAN</primary>
 594           </indexterm><indexterm>
 595             <primary>synchronization</primary>
 596           </indexterm>
 597         Many SAN-based storage systems permit more than one server to share a common data store.
 598         Use of a shared SAN data store means that you do not need to use time- and resource-hungry data
 599         synchronization techniques.
 600         </para>
 601
 602         <para><indexterm>
 603             <primary>load distribution</primary>
 604           </indexterm><indexterm>
 605             <primary>clustering</primary>
 606           </indexterm>
 607         The use of a collection of relatively low-cost front-end Samba servers that are coupled to
 608         a shared backend SAN data store permits load distribution while containing costs below that
 609         of installing and managing a complex clustering facility.
 610         </para>
 611
 612         </sect2>
 613
 614         <sect2>
 615         <title>Distribute Network Load with MSDFS</title>
 616
 617         <para><indexterm>
 618             <primary>MSDFS</primary>
 619           </indexterm><indexterm>
 620             <primary>distributed</primary>
 621           </indexterm>
 622         Microsoft DFS (distributed file system) technology has been implemented in Samba. MSDFS permits
 623         data to be accessed from a single share and yet to actually be distributed across multiple actual
 624         servers. Refer to <emphasis>TOSHARG</emphasis>, Chapter 16, for information regarding implementation of an MSDFS installation.
 625         </para>
 626
 627         <para><indexterm>
 628             <primary>front-end</primary>
 629             <secondary>server</secondary>
 630           </indexterm><indexterm>
 631             <primary>MSDFS</primary>
 632           </indexterm>
 633         The combination of multiple back end servers together with a front-end server and use of MSDFS
 634         can achieve almost the same as you would obtain with a clustered Samba server.
 635         </para>
 636
 637         </sect2>
 638
 639         <sect2>
 640         <title>Replicate Data to Conserve Peak-Demand Wide-Area Bandwidth</title>
 641
 642         <para><indexterm>
 643             <primary>replicate</primary>
 644           </indexterm><indexterm>
 645             <primary>rsync</primary>
 646           </indexterm><indexterm>
 647             <primary>wide-area network</primary>
 648           </indexterm>
 649         Consider using <command>rsync</command> to replicate data across the wide-area network during times
 650         of low utilization. Users can then access the replicated data store rather than needing to do so
 651         across the wide-area network. This works best for read-only data, but with careful planning can be
 652         implemented so that modified files get replicated back to the point of origin. Be careful with your
 653         implementation if you choose to permit modification and return replication of the modified file;
 654         otherwise, you may inadvertently overwrite important data.
 655         </para>
 656
 657         </sect2>
 658
 659         <sect2>
 660         <title>Hardware Problems</title>
 661
 662         <para><indexterm>
 663             <primary>hardware prices</primary>
 664           </indexterm><indexterm>
 665             <primary>hardware problems</primary>
 666           </indexterm><indexterm>
 667             <primary>NICs</primary>
 668           </indexterm><indexterm>
 669             <primary>defective</primary>
 670             <secondary>hubs</secondary>
 671           </indexterm><indexterm>
 672             <primary>defective</primary>
 673             <secondary>switches</secondary>
 674           </indexterm><indexterm>
 675             <primary>defective</primary>
 676             <secondary>cables</secondary>
 677           </indexterm>
 678         Networking hardware prices have fallen sharply over the past five years. A surprising number
 679         of Samba networking problems over this time have been traced to defective network interface
 680         cards (NICs) or defective hubs, switches, and cables.
 681         </para>
 682
 683         <para><indexterm>
 684             <primary>corrective action</primary>
 685           </indexterm>
 686         Not surprising is the fact that network administrators do not like to be shown to have made
 687         a bad decision. Money saved in buying low-cost hardware may result in high costs incurred
 688         in corrective action.
 689         </para>
 690
 691         <para><indexterm>
 692             <primary>intermittent</primary>
 693           </indexterm><indexterm>
 694             <primary>data corruption</primary>
 695           </indexterm><indexterm>
 696             <primary>slow network</primary>
 697           </indexterm><indexterm>
 698             <primary>low performance</primary>
 699           </indexterm><indexterm>
 700             <primary>data integrity</primary>
 701           </indexterm>
 702         Defective NICs, hubs, and switches may appear as intermittent network access problems, intermittent
 703         or persistent data corruption, slow network throughput, low performance, or even as blue-screen-of-death (BSOD)
 704         problems with MS Windows clients. In one case, a company updated several workstations with newer, faster
 705         Windows client machines that triggered problems during logon as well as data integrity problems on
 706         an older PC that was unaffected so long as the new machines were kept shut down.
 707         </para>
 708
 709         <para>
 710         Defective hardware problems may take patience and persistence before the real cause can be discovered.
 711         </para>
 712
 713         <para><indexterm>
 714             <primary>RAID controllers</primary>
 715           </indexterm>
 716         Networking hardware defects can significantly impact perceived Samba performance, but defective
 717         RAID controllers as well as SCSI and IDE hard disk controllers have also been known to impair Samba server
 718         operations. One business came to this realization only after replacing a Samba installation with MS
 719         Windows Server 2000 running on the same hardware. The root of the problem completely eluded the network
 720         administrator until the entire server was replaced. While you may well think that this would never
 721         happen to you, experience shows that given the right (unfortunate) circumstances, this can happen to anyone.
 722         </para>
 723
 724         </sect2>
 725
 726         <sect2>
 727                 <title>Key Points Learned</title>
 728
 729                 <para>
 730                 This chapter has touched in broad sweeps on a number of simple steps that can be taken
 731                 to ensure that your Samba network is resilient, scalable, and reliable, and that it
 732                 performs well.
 733                 </para>
 734
 735                 <para>
 736                 Always keep in mind that someone is responsible to maintain and manage your design.
 737                 In the long term, that may not be you. Spare a thought for your successor and give him or
 738                 her an even break.
 739                 </para>
 740
 741         <para><indexterm>
 742             <primary>assumptions</primary>
 743           </indexterm>
 744                 Last, but not least, you should not only keep the network design simple, but it should
 745                 be well documented. This book may serve as your pattern for documenting every
 746                 aspect of your design, its implementation, and particularly the objects and assumptions
 747                 that underlie it.
 748                 </para>
 749
 750         </sect2>
 751
 752 </sect1>
 753
 754 </chapter>
 755