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