source: trunk-3.0/docs/htmldocs/Samba3-HOWTO/SambaHA.html@ 101

Last change on this file since 101 was 44, checked in by Paul Smedley, 18 years ago

Update source to 3.0.25b
File size: 21.3 KB
Line 
1<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 32. High Availability</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.71.0"><link rel="start" href="index.html" title="The Official Samba-3 HOWTO and Reference Guide"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="prev" href="Backup.html" title="Chapter 31. Backup Techniques"><link rel="next" href="largefile.html" title="Chapter 33. Handling Large Directories"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 32. High Availability</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="Backup.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="largefile.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="SambaHA"></a>Chapter 32. High Availability</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email">&lt;<a href="mailto:jht@samba.org">jht@samba.org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jeremy</span> <span class="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email">&lt;<a href="mailto:jra@samba.org">jra@samba.org</a>&gt;</code></p></div></div></div></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="SambaHA.html#id428263">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="SambaHA.html#id428370">Technical Discussion</a></span></dt><dd><dl><dt><span class="sect2"><a href="SambaHA.html#id428402">The Ultimate Goal</a></span></dt><dt><span class="sect2"><a href="SambaHA.html#id428524">Why Is This So Hard?</a></span></dt><dt><span class="sect2"><a href="SambaHA.html#id429188">A Simple Solution</a></span></dt><dt><span class="sect2"><a href="SambaHA.html#id429261">High-Availability Server Products</a></span></dt><dt><span class="sect2"><a href="SambaHA.html#id429390">MS-DFS: The Poor Man's Cluster</a></span></dt><dt><span class="sect2"><a href="SambaHA.html#id429423">Conclusions</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id428263"></a>Features and Benefits</h2></div></div></div><p>
2<a class="indexterm" name="id428271"></a>
3<a class="indexterm" name="id428278"></a>
4<a class="indexterm" name="id428285"></a>
5Network administrators are often concerned about the availability of file and print
6services. Network users are inclined toward intolerance of the services they depend
7on to perform vital task responsibilities.
8</p><p>
9A sign in a computer room served to remind staff of their responsibilities. It read:
10</p><div class="blockquote"><blockquote class="blockquote"><p>
11<a class="indexterm" name="id428303"></a>
12<a class="indexterm" name="id428310"></a>
13<a class="indexterm" name="id428316"></a>
14<a class="indexterm" name="id428323"></a>
15All humans fail, in both great and small ways we fail continually. Machines fail too.
16Computers are machines that are managed by humans, the fallout from failure
17can be spectacular. Your responsibility is to deal with failure, to anticipate it
18and to eliminate it as far as is humanly and economically wise to achieve.
19Are your actions part of the problem or part of the solution?
20</p></blockquote></div><p>
21If we are to deal with failure in a planned and productive manner, then first we must
22understand the problem. That is the purpose of this chapter.
23</p><p>
24<a class="indexterm" name="id428342"></a>
25<a class="indexterm" name="id428349"></a>
26<a class="indexterm" name="id428356"></a>
27Parenthetically, in the following discussion there are seeds of information on how to
28provision a network infrastructure against failure. Our purpose here is not to provide
29a lengthy dissertation on the subject of high availability. Additionally, we have made
30a conscious decision to not provide detailed working examples of high availability
31solutions; instead we present an overview of the issues in the hope that someone will
32rise to the challenge of providing a detailed document that is focused purely on
33presentation of the current state of knowledge and practice in high availability as it
34applies to the deployment of Samba and other CIFS/SMB technologies.
35</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id428370"></a>Technical Discussion</h2></div></div></div><p>
36<a class="indexterm" name="id428378"></a>
37<a class="indexterm" name="id428385"></a>
38<a class="indexterm" name="id428392"></a>
39The following summary was part of a presentation by Jeremy Allison at the SambaXP 2003
40conference that was held at Goettingen, Germany, in April 2003. Material has been added
41from other sources, but it was Jeremy who inspired the structure that follows.
42</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id428402"></a>The Ultimate Goal</h3></div></div></div><p>
43<a class="indexterm" name="id428410"></a>
44<a class="indexterm" name="id428416"></a>
45<a class="indexterm" name="id428423"></a>
46 All clustering technologies aim to achieve one or more of the following:
47 </p><div class="itemizedlist"><ul type="disc"><li><p>Obtain the maximum affordable computational power.</p></li><li><p>Obtain faster program execution.</p></li><li><p>Deliver unstoppable services.</p></li><li><p>Avert points of failure.</p></li><li><p>Exact most effective utilization of resources.</p></li></ul></div><p>
48 A clustered file server ideally has the following properties:
49<a class="indexterm" name="id428461"></a>
50<a class="indexterm" name="id428468"></a>
51<a class="indexterm" name="id428475"></a>
52<a class="indexterm" name="id428482"></a>
53 </p><div class="itemizedlist"><ul type="disc"><li><p>All clients can connect transparently to any server.</p></li><li><p>A server can fail and clients are transparently reconnected to another server.</p></li><li><p>All servers serve out the same set of files.</p></li><li><p>All file changes are immediately seen on all servers.</p><div class="itemizedlist"><ul type="circle"><li><p>Requires a distributed file system.</p></li></ul></div></li><li><p>Infinite ability to scale by adding more servers or disks.</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id428524"></a>Why Is This So Hard?</h3></div></div></div><p>
54 In short, the problem is one of <span class="emphasis"><em>state</em></span>.
55 </p><div class="itemizedlist"><ul type="disc"><li><p>
56<a class="indexterm" name="id428543"></a>
57 All TCP/IP connections are dependent on state information.
58 </p><p>
59<a class="indexterm" name="id428554"></a>
60 The TCP connection involves a packet sequence number. This
61 sequence number would need to be dynamically updated on all
62 machines in the cluster to effect seamless TCP failover.
63 </p></li><li><p>
64<a class="indexterm" name="id428569"></a>
65<a class="indexterm" name="id428576"></a>
66 CIFS/SMB (the Windows networking protocols) uses TCP connections.
67 </p><p>
68 This means that from a basic design perspective, failover is not
69 seriously considered.
70 </p><div class="itemizedlist"><ul type="circle"><li><p>
71 All current SMB clusters are failover solutions
72 they rely on the clients to reconnect. They provide server
73 failover, but clients can lose information due to a server failure.
74<a class="indexterm" name="id428598"></a>
75 </p></li></ul></div><p>
76 </p></li><li><p>
77 Servers keep state information about client connections.
78 </p><div class="itemizedlist"><a class="indexterm" name="id428615"></a><ul type="circle"><li><p>CIFS/SMB involves a lot of state.</p></li><li><p>Every file open must be compared with other open files
79 to check share modes.</p></li></ul></div><p>
80 </p></li></ul></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id428636"></a>The Front-End Challenge</h4></div></div></div><p>
81<a class="indexterm" name="id428643"></a>
82<a class="indexterm" name="id428650"></a>
83<a class="indexterm" name="id428657"></a>
84<a class="indexterm" name="id428664"></a>
85<a class="indexterm" name="id428671"></a>
86<a class="indexterm" name="id428678"></a>
87<a class="indexterm" name="id428684"></a>
88 To make it possible for a cluster of file servers to appear as a single server that has one
89 name and one IP address, the incoming TCP data streams from clients must be processed by the
90 front-end virtual server. This server must de-multiplex the incoming packets at the SMB protocol
91 layer level and then feed the SMB packet to different servers in the cluster.
92 </p><p>
93<a class="indexterm" name="id428697"></a>
94<a class="indexterm" name="id428704"></a>
95 One could split all IPC$ connections and RPC calls to one server to handle printing and user
96 lookup requirements. RPC printing handles are shared between different IPC4 sessions it is
97 hard to split this across clustered servers!
98 </p><p>
99 Conceptually speaking, all other servers would then provide only file services. This is a simpler
100 problem to concentrate on.
101 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id428722"></a>Demultiplexing SMB Requests</h4></div></div></div><p>
102<a class="indexterm" name="id428730"></a>
103<a class="indexterm" name="id428737"></a>
104<a class="indexterm" name="id428744"></a>
105<a class="indexterm" name="id428750"></a>
106 De-multiplexing of SMB requests requires knowledge of SMB state information,
107 all of which must be held by the front-end <span class="emphasis"><em>virtual</em></span> server.
108 This is a perplexing and complicated problem to solve.
109 </p><p>
110<a class="indexterm" name="id428766"></a>
111<a class="indexterm" name="id428773"></a>
112<a class="indexterm" name="id428779"></a>
113 Windows XP and later have changed semantics so state information (vuid, tid, fid)
114 must match for a successful operation. This makes things simpler than before and is a
115 positive step forward.
116 </p><p>
117<a class="indexterm" name="id428791"></a>
118<a class="indexterm" name="id428798"></a>
119 SMB requests are sent by vuid to their associated server. No code exists today to
120 effect this solution. This problem is conceptually similar to the problem of
121 correctly handling requests from multiple requests from Windows 2000
122 Terminal Server in Samba.
123 </p><p>
124<a class="indexterm" name="id428810"></a>
125 One possibility is to start by exposing the server pool to clients directly.
126 This could eliminate the de-multiplexing step.
127 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id428821"></a>The Distributed File System Challenge</h4></div></div></div><p>
128<a class="indexterm" name="id428828"></a>
129 There exists many distributed file systems for UNIX and Linux.
130 </p><p>
131<a class="indexterm" name="id428839"></a>
132<a class="indexterm" name="id428846"></a>
133<a class="indexterm" name="id428853"></a>
134<a class="indexterm" name="id428860"></a>
135<a class="indexterm" name="id428866"></a>
136<a class="indexterm" name="id428873"></a>
137 Many could be adopted to backend our cluster, so long as awareness of SMB
138 semantics is kept in mind (share modes, locking, and oplock issues in particular).
139 Common free distributed file systems include:
140<a class="indexterm" name="id428882"></a>
141<a class="indexterm" name="id428889"></a>
142<a class="indexterm" name="id428895"></a>
143<a class="indexterm" name="id428902"></a>
144 </p><div class="itemizedlist"><ul type="disc"><li><p>NFS</p></li><li><p>AFS</p></li><li><p>OpenGFS</p></li><li><p>Lustre</p></li></ul></div><p>
145<a class="indexterm" name="id428933"></a>
146 The server pool (cluster) can use any distributed file system backend if all SMB
147 semantics are performed within this pool.
148 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id428943"></a>Restrictive Constraints on Distributed File Systems</h4></div></div></div><p>
149<a class="indexterm" name="id428951"></a>
150<a class="indexterm" name="id428958"></a>
151<a class="indexterm" name="id428965"></a>
152<a class="indexterm" name="id428972"></a>
153 Where a clustered server provides purely SMB services, oplock handling
154 may be done within the server pool without imposing a need for this to
155 be passed to the backend file system pool.
156 </p><p>
157<a class="indexterm" name="id428983"></a>
158<a class="indexterm" name="id428990"></a>
159 On the other hand, where the server pool also provides NFS or other file services,
160 it will be essential that the implementation be oplock-aware so it can
161 interoperate with SMB services. This is a significant challenge today. A failure
162 to provide this interoperability will result in a significant loss of performance that will be
163 sorely noted by users of Microsoft Windows clients.
164 </p><p>
165 Last, all state information must be shared across the server pool.
166 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id429006"></a>Server Pool Communications</h4></div></div></div><p>
167<a class="indexterm" name="id429014"></a>
168<a class="indexterm" name="id429021"></a>
169<a class="indexterm" name="id429028"></a>
170<a class="indexterm" name="id429034"></a>
171 Most backend file systems support POSIX file semantics. This makes it difficult
172 to push SMB semantics back into the file system. POSIX locks have different properties
173 and semantics from SMB locks.
174 </p><p>
175<a class="indexterm" name="id429046"></a>
176<a class="indexterm" name="id429053"></a>
177<a class="indexterm" name="id429060"></a>
178 All <code class="literal">smbd</code> processes in the server pool must of necessity communicate
179 very quickly. For this, the current <em class="parameter"><code>tdb</code></em> file structure that Samba
180 uses is not suitable for use across a network. Clustered <code class="literal">smbd</code>s must use something else.
181 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id429088"></a>Server Pool Communications Demands</h4></div></div></div><p>
182 High-speed interserver communications in the server pool is a design prerequisite
183 for a fully functional system. Possibilities for this include:
184 </p><div class="itemizedlist"><a class="indexterm" name="id429100"></a><a class="indexterm" name="id429107"></a><ul type="disc"><li><p>
185 Proprietary shared memory bus (example: Myrinet or SCI [scalable coherent interface]).
186 These are high-cost items.
187 </p></li><li><p>
188 Gigabit Ethernet (now quite affordable).
189 </p></li><li><p>
190 Raw Ethernet framing (to bypass TCP and UDP overheads).
191 </p></li></ul></div><p>
192 We have yet to identify metrics for performance demands to enable this to happen
193 effectively.
194 </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id429138"></a>Required Modifications to Samba</h4></div></div></div><p>
195 Samba needs to be significantly modified to work with a high-speed server interconnect
196 system to permit transparent failover clustering.
197 </p><p>
198 Particular functions inside Samba that will be affected include:
199 </p><div class="itemizedlist"><ul type="disc"><li><p>
200 The locking database, oplock notifications,
201 and the share mode database.
202 </p></li><li><p>
203<a class="indexterm" name="id429162"></a>
204<a class="indexterm" name="id429169"></a>
205 Failure semantics need to be defined. Samba behaves the same way as Windows.
206 When oplock messages fail, a file open request is allowed, but this is
207 potentially dangerous in a clustered environment. So how should interserver
208 pool failure semantics function, and how should such functionality be implemented?
209 </p></li><li><p>
210 Should this be implemented using a point-to-point lock manager, or can this
211 be done using multicast techniques?
212 </p></li></ul></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id429188"></a>A Simple Solution</h3></div></div></div><p>
213<a class="indexterm" name="id429196"></a>
214<a class="indexterm" name="id429203"></a>
215<a class="indexterm" name="id429210"></a>
216 Allowing failover servers to handle different functions within the exported file system
217 removes the problem of requiring a distributed locking protocol.
218 </p><p>
219<a class="indexterm" name="id429221"></a>
220<a class="indexterm" name="id429228"></a>
221 If only one server is active in a pair, the need for high-speed server interconnect is avoided.
222 This allows the use of existing high-availability solutions, instead of inventing a new one.
223 This simpler solution comes at a price the cost of which is the need to manage a more
224 complex file name space. Since there is now not a single file system, administrators
225 must remember where all services are located a complexity not easily dealt with.
226 </p><p>
227<a class="indexterm" name="id429248"></a>
228 The <span class="emphasis"><em>virtual server</em></span> is still needed to redirect requests to backend
229 servers. Backend file space integrity is the responsibility of the administrator.
230 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id429261"></a>High-Availability Server Products</h3></div></div></div><p>
231<a class="indexterm" name="id429269"></a>
232<a class="indexterm" name="id429276"></a>
233<a class="indexterm" name="id429283"></a>
234<a class="indexterm" name="id429289"></a>
235<a class="indexterm" name="id429296"></a>
236 Failover servers must communicate in order to handle resource failover. This is essential
237 for high-availability services. The use of a dedicated heartbeat is a common technique to
238 introduce some intelligence into the failover process. This is often done over a dedicated
239 link (LAN or serial).
240 </p><p>
241<a class="indexterm" name="id429309"></a>
242<a class="indexterm" name="id429315"></a>
243<a class="indexterm" name="id429322"></a>
244<a class="indexterm" name="id429329"></a>
245<a class="indexterm" name="id429336"></a>
246 Many failover solutions (like Red Hat Cluster Manager and Microsoft Wolfpack)
247 can use a shared SCSI of Fiber Channel disk storage array for failover communication.
248 Information regarding Red Hat high availability solutions for Samba may be obtained from
249 <a href="http://www.redhat.com/docs/manuals/enterprise/RHEL-AS-2.1-Manual/cluster-manager/s1-service-samba.html" target="_top">www.redhat.com</a>.
250 </p><p>
251<a class="indexterm" name="id429354"></a>
252 The Linux High Availability project is a resource worthy of consultation if your desire is
253 to build a highly available Samba file server solution. Please consult the home page at
254 <a href="http://www.linux-ha.org/" target="_top">www.linux-ha.org/</a>.
255 </p><p>
256<a class="indexterm" name="id429372"></a>
257<a class="indexterm" name="id429379"></a>
258 Front-end server complexity remains a challenge for high availability because it must deal
259 gracefully with backend failures, while at the same time providing continuity of service
260 to all network clients.
261 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id429390"></a>MS-DFS: The Poor Man's Cluster</h3></div></div></div><p>
262<a class="indexterm" name="id429398"></a>
263<a class="indexterm" name="id429404"></a>
264 MS-DFS links can be used to redirect clients to disparate backend servers. This pushes
265 complexity back to the network client, something already included by Microsoft.
266 MS-DFS creates the illusion of a simple, continuous file system name space that works even
267 at the file level.
268 </p><p>
269 Above all, at the cost of complexity of management, a distributed system (pseudo-cluster) can
270 be created using existing Samba functionality.
271 </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id429423"></a>Conclusions</h3></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>Transparent SMB clustering is hard to do!</p></li><li><p>Client failover is the best we can do today.</p></li><li><p>Much more work is needed before a practical and manageable high-availability transparent cluster solution will be possible.</p></li><li><p>MS-DFS can be used to create the illusion of a single transparent cluster.</p></li></ul></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="Backup.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="largefile.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 31. Backup Techniques </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 33. Handling Large Directories</td></tr></table></div></body></html>
Note: See TracBrowser for help on using the repository browser.