diff options
Diffstat (limited to 'docs/Samba-Guide/Chap11-HighAvailability.xml')
| -rw-r--r-- | docs/Samba-Guide/Chap11-HighAvailability.xml | 766 |
1 files changed, 766 insertions, 0 deletions
diff --git a/docs/Samba-Guide/Chap11-HighAvailability.xml b/docs/Samba-Guide/Chap11-HighAvailability.xml new file mode 100644 index 0000000000..d81164a8ee --- /dev/null +++ b/docs/Samba-Guide/Chap11-HighAvailability.xml @@ -0,0 +1,766 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ + + <!-- Stuff for xincludes --> + <!ENTITY % xinclude SYSTEM "../entities/xinclude.dtd"> + %xinclude; + + <!-- entities files to use --> + <!ENTITY % global_entities SYSTEM '../entities/global.entities'> + %global_entities; + +]> + +<chapter id="HA"> + <title>Performance, Reliability, and Availability</title> + + <para><indexterm> + <primary>performance</primary> + </indexterm><indexterm> + <primary>reliability</primary> + </indexterm><indexterm> + <primary>availability</primary> + </indexterm> + Well, you have reached the chapter before the Appendix. It is customary to attempt + to wrap up the theme and contents of a book in what is generally regarded as the + chapter that should draw conclusions. This book is a suspense thriller and since + the plot of the stories told mostly lead you to bigger, better Samba-3 networking + solutions, it is perhaps appropriate to close this book with a few pertinent comments + regarding some of the things everyone can do to deliver a reliable Samba-3 network. + </para> + + <blockquote><attribution>Anonymous</attribution><para> + In a world so full of noise, how can the sparrow be heard? + </para></blockquote> + +<sect1> + <title>Introduction</title> + + <para><indexterm> + <primary>clustering</primary> + </indexterm> + The sparrow is a small bird whose sounds are drowned out by the noise of the busy + world it lives in. Likewise, the simple steps that can be taken to improve the + reliability and availability of a Samba network are often drowned out by the volume + of discussions about grandiose Samba clustering designs. This is not intended to + suggest that clustering is not important, because clearly it is. This chapter does not devote + itself to discussion of clustering because each clustering methodology uses its own + custom tools and methods. Only passing comments are offered concerning these methods. + </para> + + <para><indexterm> + <primary>cluster</primary> + </indexterm><indexterm> + <primary>samba cluster</primary> + </indexterm><indexterm> + <primary>scalability</primary> + </indexterm> +<ulink url="http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=samba+cluster&btnG=Google+Search">A search</ulink> + for <quote>samba cluster</quote> produced 71,600 hits. And a search for <quote>highly available samba</quote> + and <quote>highly available windows</quote> produced an amazing number of references. + It is clear from the resources on the Internet that Windows file and print services + availability, reliability, and scalability are of vital interest to corporate network users. + </para> + + <para><indexterm> + <primary>performance</primary> + </indexterm> + So without further background, you can review a checklist of simple steps that + can be taken to ensure acceptable network performance while keeping costs of ownership + well under control. + </para> + +</sect1> + +<sect1> + <title>Dissection and Discussion</title> + + <para><indexterm> + <primary>simple</primary> + </indexterm><indexterm> + <primary>complexities</primary> + </indexterm> + If it is your purpose to get the best mileage out of your Samba servers, there is one rule that + must be obeyed. If you want the best, keep your implementation as simple as possible. You may + well be forced to introduce some complexities, but you should do so only as a last resort. + </para> + + <para> + Simple solutions are likely to be easier to get right than are complex ones. They certainly + make life easier for your successor. Simple implementations can be more readily audited than can + complex ones. + </para> + + <para><indexterm> + <primary>broken behavior</primary> + </indexterm><indexterm> + <primary>poor performance</primary> + </indexterm> + Problems reported by users fall into three categories: configurations that do not work, those + that have broken behavior, and poor performance. The term <emphasis>broken behavior</emphasis> + means that the function of a partciluar Samba component appears to work sometimes, but not at + others. The resulting intermittent operation is clearly unacceptable. An example of + <emphasis>broken behavior</emphasis> known to many Windows networking users occurs when the + list of Windows machines in MS Explorer changes, sometimes listing machines that are running + and at other times not listing them even though the machines are in use on the network. + </para> + + <para><indexterm> + <primary>smbfs</primary> + </indexterm><indexterm> + <primary>smbmnt</primary> + </indexterm><indexterm> + <primary>smbmount</primary> + </indexterm><indexterm> + <primary>smbumnt</primary> + </indexterm><indexterm> + <primary>smbumount</primary> + </indexterm><indexterm> + <primary>front-end</primary> + </indexterm> + A significant number of reports concern problems with the <command>smbfs</command> file system + driver that is part of the Linux kernel, not part of Samba. Users continue to interpret that + <command>smbfs</command> is part of Samba, simply because Samba includes the front-end tools + that are used to manage <command>smbfs</command>-based file service connections. So, just + for the record, the tools <command>smbmnt, smbmount, smbumount,</command> and <command>smbumnt</command> are front-end + facilities to core drivers that are supplied as part of the Linux kernel. These tools share a + common infrastructure with some Samba components, but they are not maintained as part of + Samba and are really foreign to it. + </para> + + <para><indexterm> + <primary>cifsfs</primary> + </indexterm> + The new project, <command>cifsfs</command>, is destined to replace <command>smbfs</command>. + It, too, is not part of Samba, even though one of the Samba Team members is a prime mover in + this project. + </para> + + <para> + The following table lists typical causes of: + </para> + + <itemizedlist> + <listitem><para>Not Working (NW)</para></listitem> + <listitem><para>Broken Behavior (BB)</para></listitem> + <listitem><para>Poor Performance (PP)</para></listitem> + </itemizedlist> + + + <table id="ProbList"> + <title>Effect of Common Problems</title> + <tgroup cols="4"> + <colspec align="left"/> + <colspec align="center"/> + <colspec align="center"/> + <colspec align="center"/> + <thead> + <row> + <entry><para>Problem</para></entry> + <entry><para>NW</para></entry> + <entry><para>BB</para></entry> + <entry><para>PP</para></entry> + </row> + </thead> + <tbody> + <row> + <entry><para>File Locking</para></entry> + <entry><para>-</para></entry> + <entry><para>X</para></entry> + <entry><para>-</para></entry> + </row> + <row> + <entry><para>Hardware Problems</para></entry> + <entry><para>X</para></entry> + <entry><para>X</para></entry> + <entry><para>X</para></entry> + </row> + <row> + <entry><para>Incorrect Authentication</para></entry> + <entry><para>X</para></entry> + <entry><para>X</para></entry> + <entry><para>-</para></entry> + </row> + <row> + <entry><para>Incorrect Configuration</para></entry> + <entry><para>X</para></entry> + <entry><para>X</para></entry> + <entry><para>X</para></entry> + </row> + <row> + <entry><para>LDAP Problems</para></entry> + <entry><para>X</para></entry> + <entry><para>X</para></entry> + <entry><para>-</para></entry> + </row> + <row> + <entry><para>Name Resolution</para></entry> + <entry><para>X</para></entry> + <entry><para>X</para></entry> + <entry><para>X</para></entry> + </row> + <row> + <entry><para>Printing Problems</para></entry> + <entry><para>X</para></entry> + <entry><para>X</para></entry> + <entry><para>-</para></entry> + </row> + <row> + <entry><para>Slow File Transfer</para></entry> + <entry><para>-</para></entry> + <entry><para>-</para></entry> + <entry><para>X</para></entry> + </row> + <row> + <entry><para>Winbind Problems</para></entry> + <entry><para>X</para></entry> + <entry><para>X</para></entry> + <entry><para>-</para></entry> + </row> + </tbody> + </tgroup> + </table> + + <para><indexterm> + <primary>network hygiene</primary> + </indexterm> + It is obvious to all that the first requirement (as a matter of network hygiene) is to eliminate + problems that affect basic network operation. This book has provided sufficient working examples + to help you to avoid all these problems. + </para> + +</sect1> + +<sect1> + <title>Guidelines for Reliable Samba Operation</title> + + <para><indexterm> + <primary>resilient</primary> + </indexterm><indexterm> + <primary>extreme demand</primary> + </indexterm> + Your objective is to provide a network that works correctly, can grow at all times, is resilient + at times of extreme demand, and can scale to meet future needs. The following subject areas provide + pointers that can help you today. + </para> + + <sect2> + <title>Name Resolution</title> + + <para> + There are three basic current problem areas: bad hostnames, routed networks, and network collisions. + These are covered in the discussion below. + </para> + + <sect3> + <title>Bad Hostnames</title> + + <para><indexterm> + <primary>DHCP</primary> + <secondary>client</secondary> + </indexterm><indexterm> + <primary>netbios name</primary> + </indexterm><indexterm> + <primary>localhost</primary> + </indexterm><indexterm> + <primary>/etc/hosts</primary> + </indexterm><indexterm> + <primary>NetBIOS</primary> + </indexterm> + When configured as a DHCP client, a number of Linux distributions set the system hostname + to <constant>localhost</constant>. If the parameter <parameter>netbios name</parameter> is not + specified to something other than <constant>localhost</constant>, the Samba server appears + in the Windows Explorer as <constant>LOCALHOST</constant>. Moreover, the entry in the <filename>/etc/hosts</filename> + on the Linux server points to IP address <constant>127.0.0.1</constant>. This means that + when the Windows client obtains the IP address of the Samba server called <constant>LOCALHOST</constant>, + it obtains the IP address <constant>127.0.0.1</constant> and then proceeds to attempt to + set up a NetBIOS over TCP/IP connection to it. This cannot work, because that IP address is + the local Windows machine itself. Hostnames must be valid for Windows networking to function + correctly. + </para> + + <para><indexterm> + <primary>digits</primary> + </indexterm> + A few sites have tried to name Windows clients and Samba servers with a name that begins + with the digits 1-9. This does not work either because it may result in the client or + server attempting to use that name as an IP address. + </para> + + <para><indexterm> + <primary>DNS</primary> + <secondary>name lookup</secondary> + </indexterm><indexterm> + <primary>resolve</primary> + </indexterm> + A Samba server called <constant>FRED</constant>, in a NetBIOS Domain called <constant>COLLISION</constant> + in a network environment that is part of the fully qualified Internet domain name space known + as <constant>parrots.com</constant>, results in DNS name lookups for: <constant>fred.parrots.com</constant> + and <constant>collision.parrots.com</constant>. It is, therefore, a mistake to name the Domain + (workgroup) <constant>collision.parrots.com</constant> since this results in DNS lookup + attempts to resolve: <constant>fred.parrots.com.parrots.com</constant>, which most likely + fails given that you probably do not have this in your DNS name space. + </para> + + <note><para><indexterm> + <primary>Active Directory</primary> + <secondary>realm</secondary> + </indexterm><indexterm> + <primary>ADS</primary> + </indexterm><indexterm> + <primary>DNS</primary> + </indexterm> + An Active Directory realm called <constant>collision.parrots.com</constant> is perfectly okay, + although it too must be capable of being resolved via DNS, something that functions correctly + if Windows 200x ADS has been properly installed and configured. + </para></note> + + </sect3> + + <sect3> + <title>Routed Networks</title> + + <para><indexterm> + <primary>NetBIOS</primary> + </indexterm><indexterm> + <primary>UDP</primary> + <secondary>broadcast</secondary> + </indexterm><indexterm> + <primary>broadcast</primary> + </indexterm> + NetBIOS networks (Windows networking with NetBIOS over TCP/IP enabled) makes extensive use + of UDP-based broadcast traffic. You saw that during the exercises in Chapter 1. + </para> + + <para><indexterm> + <primary>routers</primary> + </indexterm><indexterm> + <primary>forwarded</primary> + </indexterm><indexterm> + <primary>multi-subnet</primary> + </indexterm> + UDP broadcast traffic is not forwarded by routers. This means that NetBIOS broadcast-based + networking cannot function across routed networks (i.e., multi-subnet networks) unless + special provisions are made: + </para> + + <itemizedlist> + <listitem><para><indexterm> + <primary>LMHOSTS</primary> + </indexterm><indexterm> + <primary>remote announce</primary> + </indexterm><indexterm> + <primary>remote browse sync</primary> + </indexterm> + Either install on every Windows client an LMHOSTS file (located in the directory + <filename>C:\windows\system32\drivers\etc</filename>). It is also necessary to + add to the Samba server &smb.conf; file the parameters: <parameter>remote announce</parameter> + and <parameter>remote browse sync</parameter>. For more information, refer to the on-line + manual page for the &smb.conf; file. + </para></listitem> + + <listitem><para><indexterm> + <primary>WINS</primary> + <secondary>server</secondary> + </indexterm> + Or configure Samba as a WINS server, and configure all network clients to use that + WINS server in their TCP/IP configuration. + </para></listitem> + </itemizedlist> + + <note><para><indexterm> + <primary>WINS</primary> + <secondary>name resolution</secondary> + </indexterm><indexterm> + <primary>DNS</primary> + </indexterm> + The use of DNS is not an acceptable substitute for WINS. DNS does not store specific + information regarding NetBIOS networking particulars that does get stored in the WINS + name resolution database, and that Windows clients require and depend on. + </para></note> + + </sect3> + + <sect3> + <title>Network Collisions</title> + + <para><indexterm> + <primary>network</primary> + <secondary>collisions</secondary> + </indexterm><indexterm> + <primary>network</primary> + <secondary>tiemouts</secondary> + </indexterm><indexterm> + <primary>collision rates</primary> + </indexterm><indexterm> + <primary>network</primary> + <secondary>load</secondary> + </indexterm> + Excessive network activity causes NetBIOS network time-outs. Time-outs may result in + blue screen of death (BSOD) experiences. High collision rates may be caused by excessive + UDP broadcast activity, by defective networking hardware, or through excessive network + loads (another way of saying that the network is poorly designed). + </para> + + <para> + The use of WINS is highly recommended to reduce network broadcast traffic, as outlined + in Chapter 1. + </para> + + <para><indexterm> + <primary>netbios forwarding</primary> + </indexterm><indexterm> + <primary>broadcast storms</primary> + </indexterm><indexterm> + <primary>performance</primary> + </indexterm> + Under no circumstances should the facility be supported by many routers, known as <constant>NetBIOS + forwarding</constant>, unless you know exactly what you are doing. Inappropriate use of this + facility can result in UDP broadcast storms. In one case in 1999, a university network became + unusable due to this being enabled on all routers. The problem was discovered during performance + testing of a Samba server. The maximum throughput on a 100-Base-T (100 MBit/sec) network was + less than 15 KBytes/sec. After the NetBIOS forwarding was turned off, file transfer performance + immediately returned to 11 MBytes/sec. + </para> + + </sect3> + + </sect2> + + <sect2> + <title>Samba Configuration</title> + + <para> + As a general rule, the contents of the &smb.conf; file should be kept as simple as possible. + No parameter should be specified unless you know it is essential to operation. + </para> + + <para><indexterm> + <primary>document the settings</primary> + </indexterm><indexterm> + <primary>documented</primary> + </indexterm><indexterm> + <primary>optimized</primary> + </indexterm> + Many UNIX administrators like to fully document the settings in the &smb.conf; file. This is a + bad idea because it adds content to the file. The &smb.conf; file is re-read by every <command>smbd</command> + process every time the file time stamp changes (or, on systems where this does not work, every 20 seconds or so). + </para> + + <para> + As the size of the &smb.conf; file grows the risk of introduction of parsing errors increases also. + It is recommended to keep a fully documented &smb.conf; file on hand, and then to operate Samba only + with an optimized file. + </para> + + <para><indexterm> + <primary>testparm</primary> + </indexterm> + The preferred way to maintain a documented file is to call it something like <filename>smb.conf.master</filename>. + You can generate the optimized file by executing: +<screen> +&rootprompt; testparm -s smb.conf.master > smb.conf +</screen> + You should carefully observe all warnings issued. It is also a good practice to execute the following + command to confirm correct interpretation of the &smb.conf; file contents: +<screen> +&rootprompt; testparm +Load smb config files from /etc/samba/smb.conf +Can't find include file /etc/samba/machine. +Processing section "[homes]" +Processing section "[print$]" +Processing section "[netlogon]" +Processing section "[Profiles]" +Processing section "[printers]" +Processing section "[media]" +Processing section "[data]" +Processing section "[cdr]" +Processing section "[apps]" +Loaded services file OK. +'winbind separator = +' might cause problems with group membership. +Server role: ROLE_DOMAIN_PDC +Press enter to see a dump of your service definitions +</screen> + <indexterm> + <primary>fatal problem</primary> + </indexterm> + You now, of course, press the enter key to complete the command, or else abort it by pressing Ctrl-C. + The important thing to note is the noted Server role, as well as warning messages. Noted configuration + conflicts must be remedied before proceeding. For example, the following error message represents a + common fatal problem: +<screen> +ERROR: both 'wins support = true' and 'wins server = <server list>' +cannot be set in the smb.conf file. nmbd will abort with this setting. +</screen> + </para> + + <para><indexterm> + <primary>performance degradation</primary> + </indexterm><indexterm> + <primary>socket options</primary> + </indexterm><indexterm> + <primary>socket address</primary> + </indexterm> + There are two parameters that can cause severe network performance degradation, <parameter>socket options</parameter> + and <parameter>socket address</parameter>. The <parameter>socket options</parameter> parameter was often necessary + when Samba was used with the Linux 2.2.x kernels. Later kernels are largely self-tuning and seldom benefit from + this parameter being set. Do not use either parameter unless it has been proven necessary to use them. + </para> + + <para><indexterm> + <primary>strict sync</primary> + </indexterm><indexterm> + <primary>sync always</primary> + </indexterm><indexterm> + <primary>severely degrade</primary> + </indexterm><indexterm> + <primary>network</primary> + <secondary>performance</secondary> + </indexterm> + Another &smb.conf; parameter that may cause severe network performance degradation is the + <parameter>strict sync</parameter> parameter. Do not use this at all. There is no good reason + to use this with any modern Windows client. The <parameter>strict sync</parameter> is often + used together with the <parameter>sync always</parameter> parameter. This, too, can severely + degrade network performance, so do not set it or if you must, do so with caution. + </para> + + <para><indexterm> + <primary>opportunistic locking</primary> + </indexterm><indexterm> + <primary>file caching</primary> + </indexterm><indexterm> + <primary>caching</primary> + </indexterm><indexterm> + <primary>oplocks</primary> + </indexterm> + Finally, many network administrators deliberately disable opportunistic locking support. While this + does not degrade Samba performance, it significantly degrades Windows client performance because + this disables local file caching on Windows clients and forces every file read and written to + invoke a network read or write call. If for any reason you must disable oplocks (opportunistic locking) + support, do so on the share on which it is required only. That way, all other shares can provide + oplock support for operations that are tolerant of it. See <link linkend="ch12dblck"/> for more + information. + </para> + + </sect2> + + <sect2> + <title>Use and Location of BDCs</title> + + <para><indexterm> + <primary>BDC</primary> + </indexterm><indexterm> + <primary>PDC</primary> + </indexterm><indexterm> + <primary>routed network</primary> + </indexterm><indexterm> + <primary>wide-area network</primary> + </indexterm><indexterm> + <primary>network segment</primary> + </indexterm> + On a network segment where there is a PDC and a BDC, the BDC carries the bulk of the network logon + processing. If the BDC is a heavily loaded server, the PDC carries a greater proportion of + authentication and logon processing. When a sole BDC on a routed network segment gets heavily + loaded, it is possible that network logon requests and authentication requests may be directed + to a BDC on a distant network segment. This significantly hinders wide-area network operations + and is undesirable. + </para> + + <para><indexterm> + <primary>Domain Member</primary> + </indexterm><indexterm> + <primary>Domain Controller</primary> + </indexterm> + As a general guide, instead of adding Domain Member servers to a network, you would be better advised + to add BDCs until there are fewer than 30 Windows clients per BDC. Beyond that ratio, you should add + Domain Member servers. This practice ensures that there is always sufficient Domain Controllers + to handle logon requests and authentication traffic. + </para> + + </sect2> + + <sect2> + <title>Use One Consistent Version of MS Windows Client</title> + + <para> + Every network client has its own peculiarities. From a management perspective, it is easier to deal + with one version of MS Windows that is maintained to a consistent update level, than it is to deal + with a mixture of clients. + </para> + + <para> + On a number of occasions, particular Microsoft service pack updates of a Windows server or client + have necessitated special handling from the Samba server end. If you want to remain sane, keep you + client workstation configurations consistent. + </para> + + </sect2> + + <sect2> + <title>For Scalability, Use SAN Based Storage on Samba Servers</title> + + <para><indexterm> + <primary>SAN</primary> + </indexterm><indexterm> + <primary>synchronization</primary> + </indexterm> + Many SAN-based storage systems permit more than one server to share a common data store. + Use of a shared SAN data store means that you do not need to use time- and resource-hungry data + synchronization techniques. + </para> + + <para><indexterm> + <primary>load distribution</primary> + </indexterm><indexterm> + <primary>clustering</primary> + </indexterm> + The use of a collection of relatively low-cost front-end Samba servers that are coupled to + a shared backend SAN data store permits load distribution while containing costs below that + of installing and managing a complex clustering facility. + </para> + + </sect2> + + <sect2> + <title>Distribute Network Load with MSDFS</title> + + <para><indexterm> + <primary>MSDFS</primary> + </indexterm><indexterm> + <primary>distributed</primary> + </indexterm> + Microsoft DFS (distributed file system) technology has been implemented in Samba. MSDFS permits + data to be accessed from a single share and yet to actually be distributed across multiple actual + servers. Refer to <emphasis>TOSHARG</emphasis>, Chapter 16, for information regarding implementation of an MSDFS installation. + </para> + + <para><indexterm> + <primary>front-end</primary> + <secondary>server</secondary> + </indexterm><indexterm> + <primary>MSDFS</primary> + </indexterm> + The combination of multiple back end servers together with a front-end server and use of MSDFS + can achieve almost the same as you would obtain with a clustered Samba server. + </para> + + </sect2> + + <sect2> + <title>Replicate Data to Conserve Peak-Demand Wide-Area Bandwidth</title> + + <para><indexterm> + <primary>replicate</primary> + </indexterm><indexterm> + <primary>rsync</primary> + </indexterm><indexterm> + <primary>wide-area network</primary> + </indexterm> + Consider using <command>rsync</command> to replicate data across the wide-area network during times + of low utilization. Users can then access the replicated data store rather than needing to do so + across the wide-area network. This works best for read-only data, but with careful planning can be + implemented so that modified files get replicated back to the point of origin. Be careful with your + implementation if you choose to permit modification and return replication of the modified file; + otherwise, you may inadvertently overwrite important data. + </para> + + </sect2> + + <sect2> + <title>Hardware Problems</title> + + <para><indexterm> + <primary>hardware prices</primary> + </indexterm><indexterm> + <primary>hardware problems</primary> + </indexterm><indexterm> + <primary>NICs</primary> + </indexterm><indexterm> + <primary>defective</primary> + <secondary>hubs</secondary> + </indexterm><indexterm> + <primary>defective</primary> + <secondary>switches</secondary> + </indexterm><indexterm> + <primary>defective</primary> + <secondary>cables</secondary> + </indexterm> + Networking hardware prices have fallen sharply over the past five years. A surprising number + of Samba networking problems over this time have been traced to defective network interface + cards (NICs) or defective hubs, switches, and cables. + </para> + + <para><indexterm> + <primary>corrective action</primary> + </indexterm> + Not surprising is the fact that network administrators do not like to be shown to have made + a bad decision. Money saved in buying low-cost hardware may result in high costs incurred + in corrective action. + </para> + + <para><indexterm> + <primary>intermittent</primary> + </indexterm><indexterm> + <primary>data corruption</primary> + </indexterm><indexterm> + <primary>slow network</primary> + </indexterm><indexterm> + <primary>low performance</primary> + </indexterm><indexterm> + <primary>data integrity</primary> + </indexterm> + Defective NICs, hubs, and switches may appear as intermittent network access problems, intermittent + or persistent data corruption, slow network throughput, low performance, or even as blue-screen-of-death (BSOD) + problems with MS Windows clients. In one case, a company updated several workstations with newer, faster + Windows client machines that triggered problems during logon as well as data integrity problems on + an older PC that was unaffected so long as the new machines were kept shut down. + </para> + + <para> + Defective hardware problems may take patience and persistence before the real cause can be discovered. + </para> + + <para><indexterm> + <primary>RAID controllers</primary> + </indexterm> + Networking hardware defects can significantly impact perceived Samba performance, but defective + RAID controllers as well as SCSI and IDE hard disk controllers have also been known to impair Samba server + operations. One business came to this realization only after replacing a Samba installation with MS + Windows Server 2000 running on the same hardware. The root of the problem completely eluded the network + administrator until the entire server was replaced. While you may well think that this would never + happen to you, experience shows that given the right (unfortunate) circumstances, this can happen to anyone. + </para> + + </sect2> + + <sect2> + <title>Key Points Learned</title> + + <para> + This chapter has touched in broad sweeps on a number of simple steps that can be taken + to ensure that your Samba network is resilient, scalable, and reliable, and that it + performs well. + </para> + + <para> + Always keep in mind that someone is responsible to maintain and manage your design. + In the long term, that may not be you. Spare a thought for your successor and give him or + her an even break. + </para> + + <para><indexterm> + <primary>assumptions</primary> + </indexterm> + Last, but not least, you should not only keep the network design simple, but it should + be well documented. This book may serve as your pattern for documenting every + aspect of your design, its implementation, and particularly the objects and assumptions + that underlie it. + </para> + + </sect2> + +</sect1> + +</chapter> + |