diff options
Diffstat (limited to 'docs/Samba3-HOWTO/TOSHARG-HighAvailability.xml')
| -rw-r--r-- | docs/Samba3-HOWTO/TOSHARG-HighAvailability.xml | 87 |
1 files changed, 43 insertions, 44 deletions
diff --git a/docs/Samba3-HOWTO/TOSHARG-HighAvailability.xml b/docs/Samba3-HOWTO/TOSHARG-HighAvailability.xml index 385646d91f..3d91f2c356 100644 --- a/docs/Samba3-HOWTO/TOSHARG-HighAvailability.xml +++ b/docs/Samba3-HOWTO/TOSHARG-HighAvailability.xml @@ -80,7 +80,7 @@ from other sources, but it was Jeremy who inspired the structure that follows. <itemizedlist> <listitem><para>All clients can connect transparently to any server.</para></listitem> <listitem><para>A server can fail and clients are transparently reconnected to another server.</para></listitem> - <listitem><para>All servers server out the same set of files.</para></listitem> + <listitem><para>All servers serve out the same set of files.</para></listitem> <listitem><para>All file changes are immediately seen on all servers.</para> <itemizedlist><listitem><para>Requires a distributed file system.</para></listitem></itemizedlist></listitem> <listitem><para>Infinite ability to scale by adding more servers or disks.</para></listitem> @@ -103,7 +103,7 @@ from other sources, but it was Jeremy who inspired the structure that follows. <para> The TCP connection involves a packet sequence number. This sequence number would need to be dynamically updated on all - machines in the cluster to effect seamless TCP fail-over. + machines in the cluster to effect seamless TCP failover. </para> </listitem> <listitem> @@ -111,13 +111,13 @@ from other sources, but it was Jeremy who inspired the structure that follows. CIFS/SMB (the Windows networking protocols) uses TCP connections. </para> <para> - This means that from a basic design perspective, fail-over is not + This means that from a basic design perspective, failover is not seriously considered. <itemizedlist> <listitem><para> - All current SMB clusters are fail-over solutions + All current SMB clusters are failover solutions &smbmdash; they rely on the clients to reconnect. They provide server - fail-over, but clients can lose information due to a server failure. + failover, but clients can lose information due to a server failure. </para></listitem> </itemizedlist> </para> @@ -127,7 +127,7 @@ from other sources, but it was Jeremy who inspired the structure that follows. Servers keep state information about client connections. <itemizedlist> <listitem><para>CIFS/SMB involves a lot of state.</para></listitem> - <listitem><para>Every file open must be compared with other file opens + <listitem><para>Every file open must be compared with other open files to check share modes.</para></listitem> </itemizedlist> </para> @@ -140,13 +140,13 @@ from other sources, but it was Jeremy who inspired the structure that follows. <para> To make it possible for a cluster of file servers to appear as a single server that has one name and one IP address, the incoming TCP data streams from clients must be processed by the - front end virtual server. This server must de-multiplex the incoming packets at the SMB protocol + front-end virtual server. This server must de-multiplex the incoming packets at the SMB protocol layer level and then feed the SMB packet to different servers in the cluster. </para> <para> - One could split all IPC$ connections and RPC calls to one server to handle printing and user - lookup requirements. RPC Printing handles are shared between different IPC4 sessions &smbmdash; it is + One could split all IPC4 connections and RPC calls to one server to handle printing and user + lookup requirements. RPC printing handles are shared between different IPC4 sessions &smbmdash; it is hard to split this across clustered servers! </para> @@ -158,7 +158,7 @@ from other sources, but it was Jeremy who inspired the structure that follows. </sect3> <sect3> - <title>De-multiplexing SMB Requests</title> + <title>Demultiplexing SMB Requests</title> <para> De-multiplexing of SMB requests requires knowledge of SMB state information, @@ -174,7 +174,7 @@ from other sources, but it was Jeremy who inspired the structure that follows. <para> SMB requests are sent by vuid to their associated server. No code exists today to - affect this solution. This problem is conceptually similar to the problem of + effect this solution. This problem is conceptually similar to the problem of correctly handling requests from multiple requests from Windows 2000 Terminal Server in Samba. </para> @@ -196,7 +196,7 @@ from other sources, but it was Jeremy who inspired the structure that follows. <para> Many could be adopted to backend our cluster, so long as awareness of SMB - semantics is kept in mind (share modes, locking and oplock issues in particular). + semantics is kept in mind (share modes, locking, and oplock issues in particular). Common free distributed file systems include: <indexterm><primary>NFS</primary></indexterm> <indexterm><primary>AFS</primary></indexterm> @@ -229,9 +229,9 @@ from other sources, but it was Jeremy who inspired the structure that follows. <para> On the other hand, where the server pool also provides NFS or other file services, - it will be essential that the implementation be oplock aware so it can + it will be essential that the implementation be oplock-aware so it can interoperate with SMB services. This is a significant challenge today. A failure - to provide this will result in a significant loss of performance that will be + to provide this interoperability will result in a significant loss of performance that will be sorely noted by users of Microsoft Windows clients. </para> @@ -253,7 +253,7 @@ from other sources, but it was Jeremy who inspired the structure that follows. <para> All <command>smbd</command> processes in the server pool must of necessity communicate very quickly. For this, the current <parameter>tdb</parameter> file structure that Samba - uses is not suitable for use across a network. Clustered <command>smbd</command>'s must use something else. + uses is not suitable for use across a network. Clustered <command>smbd</command>s must use something else. </para> </sect3> @@ -262,22 +262,22 @@ from other sources, but it was Jeremy who inspired the structure that follows. <title>Server Pool Communications Demands</title> <para> - High speed inter-server communications in the server pool is a design prerequisite + High-speed interserver communications in the server pool is a design prerequisite for a fully functional system. Possibilities for this include: </para> <itemizedlist> <listitem><para> - Proprietary shared memory bus (example: Myrinet or SCI [Scalable Coherent Interface]). - These are high cost items. + Proprietary shared memory bus (example: Myrinet or SCI [scalable coherent interface]). + These are high-cost items. </para></listitem> <listitem><para> - Gigabit ethernet (now quite affordable). + Gigabit Ethernet (now quite affordable). </para></listitem> <listitem><para> - Raw ethernet framing (to bypass TCP and UDP overheads). + Raw Ethernet framing (to bypass TCP and UDP overheads). </para></listitem> </itemizedlist> @@ -292,8 +292,8 @@ from other sources, but it was Jeremy who inspired the structure that follows. <title>Required Modifications to Samba</title> <para> - Samba needs to be significantly modified to work with a high-speed server inter-connect - system to permit transparent fail-over clustering. + Samba needs to be significantly modified to work with a high-speed server interconnect + system to permit transparent failover clustering. </para> <para> @@ -309,8 +309,8 @@ from other sources, but it was Jeremy who inspired the structure that follows. <listitem><para> Failure semantics need to be defined. Samba behaves the same way as Windows. When oplock messages fail, a file open request is allowed, but this is - potentially dangerous in a clustered environment. So how should inter-server - pool failure semantics function and how should this be implemented? + potentially dangerous in a clustered environment. So how should interserver + pool failure semantics function, and how should such functionality be implemented? </para></listitem> <listitem><para> @@ -327,13 +327,13 @@ from other sources, but it was Jeremy who inspired the structure that follows. <title>A Simple Solution</title> <para> - Allowing fail-over servers to handle different functions within the exported file system + Allowing failover servers to handle different functions within the exported file system removes the problem of requiring a distributed locking protocol. </para> <para> - If only one server is active in a pair, the need for high speed server interconnect is avoided. - This allows the use of existing high availability solutions, instead of inventing a new one. + If only one server is active in a pair, the need for high-speed server interconnect is avoided. + This allows the use of existing high-availability solutions, instead of inventing a new one. This simpler solution comes at a price &smbmdash; the cost of which is the need to manage a more complex file name space. Since there is now not a single file system, administrators must remember where all services are located &smbmdash; a complexity not easily dealt with. @@ -347,32 +347,32 @@ from other sources, but it was Jeremy who inspired the structure that follows. </sect2> <sect2> - <title>High Availability Server Products</title> + <title>High-Availability Server Products</title> <para> - Fail-over servers must communicate in order to handle resource fail-over. This is essential - for high availability services. The use of a dedicated heartbeat is a common technique to - introduce some intelligence into the fail-over process. This is often done over a dedicated + Failover servers must communicate in order to handle resource failover. This is essential + for high-availability services. The use of a dedicated heartbeat is a common technique to + introduce some intelligence into the failover process. This is often done over a dedicated link (LAN or serial). </para> <para> <indexterm><primary>SCSI</primary></indexterm> - Many fail-over solutions (like Red Hat Cluster Manager, as well as Microsoft Wolfpack) - can use a shared SCSI of Fiber Channel disk storage array for fail-over communication. - Information regarding Red Hat high availability solutions for Samba may be obtained from: - <ulink url="http://www.redhat.com/docs/manuals/enterprise/RHEL-AS-2.1-Manual/cluster-manager/s1-service-samba.html">www.redhat.com.</ulink> + Many failover solutions (like Red Hat Cluster Manager and Microsoft Wolfpack) + can use a shared SCSI of Fiber Channel disk storage array for failover communication. + Information regarding Red Hat high availability solutions for Samba may be obtained from + <ulink url="http://www.redhat.com/docs/manuals/enterprise/RHEL-AS-2.1-Manual/cluster-manager/s1-service-samba.html">www.redhat.com</ulink>. </para> <para> The Linux High Availability project is a resource worthy of consultation if your desire is to build a highly available Samba file server solution. Please consult the home page at - <ulink url="http://www.linux-ha.org/">www.linux-ha.org/.</ulink> + <ulink url="http://www.linux-ha.org/">www.linux-ha.org/</ulink>. </para> <para> - Front-end server complexity remains a challenge for high availability as it needs to deal - gracefully with backend failures, while at the same time it needs to provide continuity of service + Front-end server complexity remains a challenge for high availability because it must deal + gracefully with backend failures, while at the same time providing continuity of service to all network clients. </para> @@ -386,12 +386,12 @@ from other sources, but it was Jeremy who inspired the structure that follows. <indexterm><primary>DFS</primary><see>MS-DFS, Distributed File Systems</see></indexterm> MS-DFS links can be used to redirect clients to disparate backend servers. This pushes complexity back to the network client, something already included by Microsoft. - MS-DFS creates the illusion of a simple, continuous file system name space, that even - works at the file level. + MS-DFS creates the illusion of a simple, continuous file system name space that works even + at the file level. </para> <para> - Above all, at the cost of complexity of management, a distributed (pseudo-cluster) can + Above all, at the cost of complexity of management, a distributed system (pseudo-cluster) can be created using existing Samba functionality. </para> @@ -402,9 +402,8 @@ from other sources, but it was Jeremy who inspired the structure that follows. <itemizedlist> <listitem><para>Transparent SMB clustering is hard to do!</para></listitem> - <listitem><para>Client fail-over is the best we can do today.</para></listitem> - <listitem><para>Much more work is needed before a practical and manageable high - availability transparent cluster solution will be possible.</para></listitem> + <listitem><para>Client failover is the best we can do today.</para></listitem> + <listitem><para>Much more work is needed before a practical and manageable high-availability transparent cluster solution will be possible.</para></listitem> <listitem><para>MS-DFS can be used to create the illusion of a single transparent cluster.</para></listitem> </itemizedlist> |