SettingUpLustreSystem.xml

   1 <?xml version='1.0' encoding='UTF-8'?>
   2 <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US" xml:id="settinguplustresystem">
   3   <title xml:id="settinguplustresystem.title">Determining Hardware Configuration Requirements and
   4     Formatting Options</title>
   5   <para>This chapter describes hardware configuration requirements for a Lustre file system
   6     including:</para>
   7   <itemizedlist>
   8     <listitem>
   9       <para>
  10           <xref linkend="dbdoclet.50438256_49017"/>
  11       </para>
  12     </listitem>
  13     <listitem>
  14       <para>
  15           <xref linkend="dbdoclet.50438256_31079"/>
  16       </para>
  17     </listitem>
  18     <listitem>
  19       <para>
  20           <xref linkend="dbdoclet.50438256_84701"/>
  21       </para>
  22     </listitem>
  23     <listitem>
  24       <para>
  25           <xref linkend="dbdoclet.50438256_26456"/>
  26       </para>
  27     </listitem>
  28     <listitem>
  29       <para>
  30           <xref linkend="dbdoclet.50438256_78272"/>
  31       </para>
  32     </listitem>
  33   </itemizedlist>
  34   <section xml:id="dbdoclet.50438256_49017">
  35       <title><indexterm><primary>setup</primary></indexterm>
  36   <indexterm><primary>setup</primary><secondary>hardware</secondary></indexterm>
  37   <indexterm><primary>design</primary><see>setup</see></indexterm>
  38           Hardware Considerations</title>
  39     <para>A Lustre file system can utilize any kind of block storage device such as single disks,
  40       software RAID, hardware RAID, or a logical volume manager. In contrast to some networked file
  41       systems, the block devices are only attached to the MDS and OSS nodes in a Lustre file system
  42       and are not accessed by the clients directly.</para>
  43     <para>Since the block devices are accessed by only one or two server nodes, a storage area network (SAN) that is accessible from all the servers is not required. Expensive switches are not needed because point-to-point connections between the servers and the storage arrays normally provide the simplest and best attachments. (If failover capability is desired, the storage must be attached to multiple servers.)</para>
  44     <para>For a production environment, it is preferable that the MGS have separate storage to allow future expansion to multiple file systems. However, it is possible to run the MDS and MGS on the same machine and have them share the same storage device.</para>
  45     <para>For best performance in a production environment, dedicated clients are required. For a non-production Lustre environment or for testing, a Lustre client and server can run on the same machine. However, dedicated clients are the only supported configuration.</para>
  46     <warning><para>Performance and recovery issues can occur if you put a client on an MDS or OSS:</para>
  47     <itemizedlist>
  48       <listitem>
  49         <para>Running the OSS and a client on the same machine can cause issues with low memory and memory pressure. If the client consumes all the memory and then tries to write data to the file system, the OSS will need to allocate pages to receive data from the client but will not be able to perform this operation due to low memory. This can cause the client to hang.</para>
  50       </listitem>
  51       <listitem>
  52         <para>Running the MDS and a client on the same machine can cause recovery and deadlock issues and impact the performance of other Lustre clients.</para>
  53       </listitem>
  54     </itemizedlist>
  55         </warning>
  56     <para>Only servers running on 64-bit CPUs are tested and supported. 64-bit CPU clients are
  57       typically used for testing to match expected customer usage and avoid limitations due to the 4
  58       GB limit for RAM size, 1 GB low-memory limitation, and 16 TB file size limit of 32-bit CPUs.
  59       Also, due to kernel API limitations, performing backups of Lustre software release 2.x. file
  60       systems on 32-bit clients may cause backup tools to confuse files that have the same 32-bit
  61       inode number.</para>
  62     <para>The storage attached to the servers typically uses RAID to provide fault tolerance and can
  63       optionally be organized with logical volume management (LVM), which is then formatted as a
  64       Lustre file system. Lustre OSS and MDS servers read, write and modify data in the format
  65       imposed by the file system.</para>
  66     <para>The Lustre file system uses journaling file system technology on both the MDTs and OSTs.
  67       For a MDT, as much as a 20 percent performance gain can be obtained by placing the journal on
  68       a separate device.</para>
  69     <para>The MDS can effectively utilize a lot of CPU cycles. A minimum of four processor cores are recommended. More are advisable for files systems with many clients.</para>
  70     <note>
  71       <para>Lustre clients running on architectures with different endianness are supported. One limitation is that the PAGE_SIZE kernel macro on the client must be as large as the PAGE_SIZE of the server. In particular, ia64 or PPC clients with large pages (up to 64kB pages) can run with x86 servers (4kB pages). If you are running x86 clients with ia64 or PPC servers, you must compile the ia64 kernel with a 4kB PAGE_SIZE (so the server page size is not larger than the client page size). </para>
  72     </note>
  73     <section remap="h3">
  74         <title><indexterm>
  75           <primary>setup</primary>
  76           <secondary>MDT</secondary>
  77         </indexterm> MGT and MDT Storage Hardware Considerations</title>
  78       <para>MGT storage requirements are small (less than 100 MB even in the largest Lustre file
  79         systems), and the data on an MGT is only accessed on a server/client mount, so disk
  80         performance is not a consideration.  However, this data is vital for file system access, so
  81         the MGT should be reliable storage, preferably mirrored RAID1.</para>
  82       <para>MDS storage is accessed in a database-like access pattern with many seeks and
  83         read-and-writes of small amounts of data. High throughput to MDS storage is not important.
  84         Storage types that provide much lower seek times, such as high-RPM SAS or SSD drives can be
  85         used for the MDT.</para>
  86       <para>For maximum performance, the MDT should be configured as RAID1 with an internal journal and two disks from different controllers.</para>
  87       <para>If you need a larger MDT, create multiple RAID1 devices from pairs of disks, and then make a RAID0 array of the RAID1 devices. This ensures maximum reliability because multiple disk failures only have a small chance of hitting both disks in the same RAID1 device.</para>
  88       <para>Doing the opposite (RAID1 of a pair of RAID0 devices) has a 50% chance that even two disk failures can cause the loss of the whole MDT device. The first failure disables an entire half of the mirror and the second failure has a 50% chance of disabling the remaining mirror.</para>
  89       <para condition='l24'>If multiple MDTs are going to be present in the system, each MDT should be specified for the anticipated usage and load.</para>
  90       <warning condition='l24'><para>MDT0 contains the root of the Lustre file system. If MDT0 is unavailable for any reason, the
  91           file system cannot be used.</para></warning>
  92       <note condition='l24'><para>Additional MDTs can be dedicated to sub-directories off the root file system provided by MDT0.
  93           Subsequent directories may also be configured to have their own MDT. If an MDT serving a
  94           subdirectory becomes unavailable this subdirectory and all directories beneath it will
  95           also become unavailable. Configuring multiple levels of MDTs is an experimental feature
  96           for the Lustre software release 2.4.</para></note>
  97     </section>
  98     <section remap="h3">
  99       <title><indexterm><primary>setup</primary><secondary>OST</secondary></indexterm>OST Storage Hardware Considerations</title>
 100       <para>The data access pattern for the OSS storage is a streaming I/O pattern that is dependent on the access patterns of applications being used. Each OSS can manage multiple object storage targets (OSTs), one for each volume with I/O traffic load-balanced between servers and targets. An OSS should be configured to have a balance between the network bandwidth and the attached storage bandwidth to prevent bottlenecks in the I/O path. Depending on the server hardware, an OSS typically serves between 2 and 8 targets, with each target up to 128 terabytes (TBs) in size.</para>
 101       <para>Lustre file system capacity is the sum of the capacities provided by the targets. For
 102         example, 64 OSSs, each with two 8 TB targets, provide a file system with a capacity of
 103         nearly 1 PB. If each OST uses ten 1 TB SATA disks (8 data disks plus 2 parity disks in a
 104         RAID 6 configuration), it may be possible to get 50 MB/sec from each drive, providing up to
 105         400 MB/sec of disk bandwidth per OST. If this system is used as storage backend with a
 106         system network, such as the InfiniBand network, that provides a similar bandwidth, then each
 107         OSS could provide 800 MB/sec of end-to-end I/O throughput. (Although the architectural
 108         constraints described here are simple, in practice it takes careful hardware selection,
 109         benchmarking and integration to obtain such results.)</para>
 110     </section>
 111   </section>
 112   <section xml:id="dbdoclet.50438256_31079">
 113       <title><indexterm><primary>setup</primary><secondary>space</secondary></indexterm>
 114           <indexterm><primary>space</primary><secondary>determining requirements</secondary></indexterm>
 115           Determining Space Requirements</title>
 116     <para>The desired performance characteristics of the backing file systems on the MDT and OSTs
 117       are independent of one another. The size of the MDT backing file system depends on the number
 118       of inodes needed in the total Lustre file system, while the aggregate OST space depends on the
 119       total amount of data stored on the file system. If MGS data is to be stored on the MDT device
 120       (co-located MGT and MDT), add 100 MB to the required size estimate for the MDT.</para>
 121     <para>Each time a file is created on a Lustre file system, it consumes one inode on the MDT and one inode for each OST object over which the file is striped. Normally, each file&apos;s stripe count is based on the system-wide default stripe count. However, this can be changed for individual files using the <literal>lfs setstripe</literal> option. For more details, see <xref linkend="managingstripingfreespace"/>.</para>
 122     <para>In a Lustre ldiskfs file system, all the inodes are allocated on the MDT and OSTs when the file system is first formatted. The total number of inodes on a formatted MDT or OST cannot be easily changed, although it is possible to add OSTs with additional space and corresponding inodes. Thus, the number of inodes created at format time should be generous enough to anticipate future expansion.</para>
 123     <para>When the file system is in use and a file is created, the metadata associated with that file is stored in one of the pre-allocated inodes and does not consume any of the free space used to store file data.</para>
 124     <note>
 125       <para>By default, the ldiskfs file system used by Lustre servers to store user-data objects
 126         and system data reserves 5% of space that cannot be used by the Lustre file system.
 127         Additionally, a Lustre file system reserves up to 400 MB on each OST for journal use and a
 128         small amount of space outside the journal to store accounting data. This reserved space is
 129         unusable for general storage. Thus, at least 400 MB of space is used on each OST before any
 130         file object data is saved.</para>
 131     </note>
 132     <para condition="l24">With a ZFS backing filesystem for the MDT or OST,
 133     the space allocation for inodes and file data is dynamic, and inodes are
 134     allocated as needed.  A minimum of 2kB of usable space (before RAID) is
 135     needed for each inode, exclusive of other overhead such as directories,
 136     internal log files, extended attributes, ACLs, etc.
 137     Since the size of extended attributes and ACLs is highly dependent on
 138     kernel versions and site-specific policies, it is best to over-estimate
 139     the amount of space needed for the desired number of inodes, and any
 140     excess space will be utilized to store more inodes.</para>
 141     <section>
 142       <title><indexterm>
 143           <primary>setup</primary>
 144           <secondary>MGT</secondary>
 145         </indexterm>
 146         <indexterm>
 147           <primary>space</primary>
 148           <secondary>determining MGT requirements</secondary>
 149         </indexterm> Determining MGT Space Requirements</title>
 150       <para>Less than 100 MB of space is required for the MGT. The size is determined by the number
 151         of servers in the Lustre file system cluster(s) that are managed by the MGS.</para>
 152     </section>
 153     <section xml:id="dbdoclet.50438256_87676">
 154         <title><indexterm>
 155           <primary>setup</primary>
 156           <secondary>MDT</secondary>
 157         </indexterm>
 158         <indexterm>
 159           <primary>space</primary>
 160           <secondary>determining MDT requirements</secondary>
 161         </indexterm> Determining MDT Space Requirements</title>
 162       <para>When calculating the MDT size, the important factor to consider is the number of files
 163         to be stored in the file system. This determines the number of inodes needed, which drives
 164         the MDT sizing. To be on the safe side, plan for 2 KB per inode on the MDT, which is the
 165         default value. Attached storage required for Lustre file system metadata is typically 1-2
 166         percent of the file system capacity depending upon file size.</para>
 167       <para>For example, if the average file size is 5 MB and you have 100 TB of usable OST space, then you can calculate the minimum number of inodes as follows:</para>
 168       <informalexample>
 169         <para>(100 TB * 1024 GB/TB * 1024 MB/GB) / 5 MB/inode = 20 million inodes</para>
 170       </informalexample>
 171       <para>We recommend that you use at least twice the minimum number of inodes to allow for future expansion and allow for an average file size smaller than expected. Thus, the required space is:</para>
 172       <informalexample>
 173         <para>2 KB/inode * 40 million inodes = 80 GB</para>
 174       </informalexample>
 175       <para>If the average file size is small, 4 KB for example, the Lustre file system is not very
 176         efficient as the MDT uses as much space as the OSTs. However, this is not a common
 177         configuration for a Lustre environment.</para>
 178       <note>
 179         <para>If the MDT is too small, this can cause all the space on the OSTs to be unusable. Be sure to determine the appropriate size of the MDT needed to support the file system before formatting the file system. It is difficult to increase the number of inodes after the file system is formatted.</para>
 180       </note>
 181     </section>
 182     <section remap="h3">
 183         <title><indexterm>
 184           <primary>setup</primary>
 185           <secondary>OST</secondary>
 186         </indexterm>
 187         <indexterm>
 188           <primary>space</primary>
 189           <secondary>determining OST requirements</secondary>
 190         </indexterm> Determining OST Space Requirements</title>
 191       <para>For the OST, the amount of space taken by each object depends on the usage pattern of
 192         the users/applications running on the system. The Lustre software defaults to a conservative
 193         estimate for the object size (16 KB per object). If you are confident that the average file
 194         size for your applications will be larger than this, you can specify a larger average file
 195         size (fewer total inodes) to reduce file system overhead and minimize file system check
 196         time. See <xref linkend="dbdoclet.50438256_53886"/> for more details.</para>
 197     </section>
 198   </section>
 199   <section xml:id="dbdoclet.50438256_84701">
 200       <title>
 201           <indexterm><primary>file system</primary><secondary>formatting options</secondary></indexterm>
 202           <indexterm><primary>setup</primary><secondary>file system</secondary></indexterm>
 203           Setting File System Formatting Options</title>
 204     <para>By default, the <literal>mkfs.lustre</literal> utility applies these options to the Lustre
 205       backing file system used to store data and metadata in order to enhance Lustre file system
 206       performance and scalability. These options include:</para>
 207         <itemizedlist>
 208             <listitem>
 209               <para><literal>flex_bg</literal> - When the flag is set to enable this
 210           flexible-block-groups feature, block and inode bitmaps for multiple groups are aggregated
 211           to minimize seeking when bitmaps are read or written and to reduce read/modify/write
 212           operations on typical RAID storage (with 1 MB RAID stripe widths). This flag is enabled on
 213           both OST and MDT file systems. On MDT file systems the <literal>flex_bg</literal> factor
 214           is left at the default value of 16. On OSTs, the <literal>flex_bg</literal> factor is set
 215           to 256 to allow all of the block or inode bitmaps in a single <literal>flex_bg</literal>
 216           to be read or written in a single I/O on typical RAID storage.</para>
 217             </listitem>
 218             <listitem>
 219               <para><literal>huge_file</literal> - Setting this flag allows files on OSTs to be
 220           larger than 2 TB in size.</para>
 221             </listitem>
 222             <listitem>
 223               <para><literal>lazy_journal_init</literal> - This extended option is enabled to
 224           prevent a full overwrite of the 400 MB journal that is allocated by default in a Lustre
 225           file system, which reduces the file system format time.</para>
 226             </listitem>
 227         </itemizedlist>
 228     <para>To override the default formatting options, use arguments to
 229         <literal>mkfs.lustre</literal> to pass formatting options to the backing file system:</para>
 230     <screen>--mkfsoptions=&apos;backing fs options&apos;</screen>
 231     <para>For other <literal>mkfs.lustre</literal> options, see the Linux man page for
 232         <literal>mke2fs(8)</literal>.</para>
 233     <section xml:id="dbdoclet.50438256_pgfId-1293228">
 234       <title><indexterm>
 235           <primary>inodes</primary>
 236           <secondary>MDS</secondary>
 237         </indexterm><indexterm>
 238           <primary>setup</primary>
 239           <secondary>inodes</secondary>
 240         </indexterm>Setting Formatting Options for an MDT</title>
 241       <para>The number of inodes on the MDT is determined at format time based on the total size of
 242         the file system to be created. The default <emphasis role="italic"
 243           >bytes-per-inode</emphasis> ratio ("inode ratio") for an MDT is optimized at one inode for
 244         every 2048 bytes of file system space. It is recommended that this value not be changed for
 245         MDTs.</para>
 246       <para>This setting takes into account the space needed for additional metadata, such as the
 247         journal (up to 400 MB), bitmaps and directories, and a few files that the Lustre file system
 248         uses to maintain cluster consistency.</para>
 249     </section>
 250     <section xml:id="dbdoclet.50438256_53886">
 251       <title><indexterm>
 252           <primary>inodes</primary>
 253           <secondary>OST</secondary>
 254         </indexterm>Setting Formatting Options for an OST</title>
 255       <para>When formatting OST file systems, it is normally advantageous to take local file system
 256         usage into account. When doing so, try to minimize the number of inodes on each OST, while
 257         keeping enough margin for potential variations in future usage. This helps reduce the format
 258         and file system check time and makes more space available for data.</para>
 259       <para>The table below shows the default <emphasis role="italic">bytes-per-inode
 260         </emphasis>ratio ("inode ratio") used for OSTs of various sizes when they are formatted. </para>
 261       <para>
 262         <table frame="all">
 263           <title xml:id="settinguplustresystem.tab1">Inode Ratios Used for Newly Formatted
 264             OSTs</title>
 265           <tgroup cols="3">
 266             <colspec colname="c1" colwidth="3*"/>
 267             <colspec colname="c2" colwidth="2*"/>
 268             <colspec colname="c3" colwidth="4*"/>
 269             <thead>
 270               <row>
 271                 <entry>
 272                   <para><emphasis role="bold">LUN/OST size</emphasis></para>
 273                 </entry>
 274                 <entry>
 275                   <para><emphasis role="bold">Inode ratio</emphasis></para>
 276                 </entry>
 277                 <entry>
 278                   <para><emphasis role="bold">Total inodes</emphasis></para>
 279                 </entry>
 280               </row>
 281             </thead>
 282             <tbody>
 283               <row>
 284                 <entry>
 285                   <para> over 10GB </para>
 286                 </entry>
 287                 <entry>
 288                   <para> 1 inode/16KB </para>
 289                 </entry>
 290                 <entry>
 291                   <para> 640 - 655k </para>
 292                 </entry>
 293               </row>
 294               <row>
 295                 <entry>
 296                   <para> 10GB - 1TB </para>
 297                 </entry>
 298                 <entry>
 299                   <para> 1 inode/68kiB </para>
 300                 </entry>
 301                 <entry>
 302                   <para> 153k - 15.7M </para>
 303                 </entry>
 304               </row>
 305               <row>
 306                 <entry>
 307                   <para> 1TB - 8TB </para>
 308                 </entry>
 309                 <entry>
 310                   <para> 1 inode/256kB </para>
 311                 </entry>
 312                 <entry>
 313                   <para> 4.2M - 33.6M </para>
 314                 </entry>
 315               </row>
 316               <row>
 317                 <entry>
 318                   <para> over 8TB </para>
 319                 </entry>
 320                 <entry>
 321                   <para> 1 inode/1MB </para>
 322                 </entry>
 323                 <entry>
 324                   <para> 8.4M - 134M </para>
 325                 </entry>
 326               </row>
 327             </tbody>
 328           </tgroup>
 329         </table>
 330       </para>
 331       <para>In environments with few small files, the default inode ratio may result in far too many
 332         inodes for the average file size. In this case, performance can be improved by increasing
 333         the number of <emphasis role="italic">bytes-per-inode</emphasis>.To set the inode ratio, use
 334         the <literal>-i</literal> argument to <literal>mkfs.lustre</literal> to specify the
 335           <emphasis role="italic">bytes-per-inode</emphasis> value. </para>
 336       <note>
 337         <para>File system check time on OSTs is affected by a number of  variables in addition to
 338           the number of inodes, including the size of the file system, the number of allocated
 339           blocks, the distribution of allocated blocks on the disk, disk speed, CPU speed, and the
 340           amount of RAM on the server. Reasonable file system check times are 5-30 minutes per
 341           TB.</para>
 342       </note>
 343       <para>For more details about formatting MDT and OST file systems, see <xref
 344           linkend="dbdoclet.50438208_51921"/>.</para>
 345     </section>
 346     <section remap="h3">
 347       <title><indexterm>
 348           <primary>setup</primary>
 349           <secondary>limits</secondary>
 350         </indexterm><indexterm xmlns:xi="http://www.w3.org/2001/XInclude">
 351           <primary>wide striping</primary>
 352         </indexterm><indexterm xmlns:xi="http://www.w3.org/2001/XInclude">
 353           <primary>xattr</primary>
 354           <secondary><emphasis role="italic">See</emphasis> wide striping</secondary>
 355         </indexterm><indexterm>
 356           <primary>large_xattr</primary>
 357           <secondary>ea_inode</secondary>
 358         </indexterm><indexterm>
 359           <primary>wide striping</primary>
 360           <secondary>large_xattr</secondary>
 361           <tertiary>ea_inode</tertiary>
 362         </indexterm>File and File System Limits</title>
 363
 364          <para><xref linkend="settinguplustresystem.tab2"/> describes
 365      file and file system size limits.  These limits are imposed by either
 366      the Lustre architecture or the Linux virtual file system (VFS) and
 367      virtual memory subsystems. In a few cases, a limit is defined within
 368      the code and can be changed by re-compiling the Lustre software.
 369      Instructions to install from source code are beyond the scope of this
 370      document, and can be found elsewhere online. In these cases, the
 371      indicated limit was used for testing of the Lustre software. </para>
 372
 373       <table frame="all">
 374         <title xml:id="settinguplustresystem.tab2">File and file system limits</title>
 375         <tgroup cols="3">
 376           <colspec colname="c1" colwidth="3*"/>
 377           <colspec colname="c2" colwidth="2*"/>
 378           <colspec colname="c3" colwidth="4*"/>
 379           <thead>
 380             <row>
 381               <entry>
 382                 <para><emphasis role="bold">Limit</emphasis></para>
 383               </entry>
 384               <entry>
 385                 <para><emphasis role="bold">Value</emphasis></para>
 386               </entry>
 387               <entry>
 388                 <para><emphasis role="bold">Description</emphasis></para>
 389               </entry>
 390             </row>
 391           </thead>
 392           <tbody>
 393             <row>
 394               <entry>
 395                 <para> Maximum number of MDTs</para>
 396               </entry>
 397               <entry>
 398                 <para> 1</para>
 399                 <para condition='l24'>4096</para>
 400               </entry>
 401               <entry>
 402                 <para>The Lustre software release 2.3 and earlier allows a maximum of 1 MDT per file
 403                   system, but a single MDS can host multiple MDTs, each one for a separate file
 404                   system.</para>
 405                 <para condition="l24">The Lustre software release 2.4 and later requires one MDT for
 406                   the filesystem root. Up to 4095 additional MDTs can be added to the file system and attached
 407                   into the namespace with remote directories.</para>
 408               </entry>
 409             </row>
 410             <row>
 411               <entry>
 412                 <para> Maximum number of OSTs</para>
 413               </entry>
 414               <entry>
 415                 <para> 8150</para>
 416               </entry>
 417               <entry>
 418                 <para>The maximum number of OSTs is a constant that can be changed at compile time.
 419                   Lustre file systems with up to 4000 OSTs have been tested.</para>
 420               </entry>
 421             </row>
 422             <row>
 423               <entry>
 424                 <para> Maximum OST size</para>
 425               </entry>
 426               <entry>
 427                 <para> 128TB (ldiskfs), 256TB (ZFS)</para>
 428               </entry>
 429               <entry>
 430                 <para>This is not a <emphasis>hard</emphasis> limit. Larger OSTs are possible but
 431                   today typical production systems do not go beyond the stated limit per OST. </para>
 432               </entry>
 433             </row>
 434             <row>
 435               <entry>
 436                 <para> Maximum number of clients</para>
 437               </entry>
 438               <entry>
 439                 <para> 131072</para>
 440               </entry>
 441               <entry>
 442                 <para>The maximum number of clients is a constant that can be changed at compile time. Up to 30000 clients have been used in production.</para>
 443               </entry>
 444             </row>
 445             <row>
 446               <entry>
 447                 <para> Maximum size of a file system</para>
 448               </entry>
 449               <entry>
 450                 <para> 512 PB (ldiskfs), 1EB (ZFS)</para>
 451               </entry>
 452               <entry>
 453                 <para>Each OST or MDT on 64-bit kernel servers can have a file system up to the above limit. On 32-bit systems, due to page cache limits, 16TB is the maximum block device size, which in turn applies to the size of OST on 32-bit kernel servers.</para>
 454                 <para>You can have multiple OST file systems on a single OSS node.</para>
 455               </entry>
 456             </row>
 457             <row>
 458               <entry>
 459                 <para> Maximum stripe count</para>
 460               </entry>
 461               <entry>
 462                 <para> 2000</para>
 463               </entry>
 464               <entry>
 465                 <para>This limit is imposed by the size of the layout that needs to be stored on disk and sent in RPC requests, but is not a hard limit of the protocol.</para>
 466               </entry>
 467             </row>
 468             <row>
 469               <entry>
 470                 <para> Maximum stripe size</para>
 471               </entry>
 472               <entry>
 473                 <para> &lt; 4 GB</para>
 474               </entry>
 475               <entry>
 476                 <para>The amount of data written to each object before moving on to next object.</para>
 477               </entry>
 478             </row>
 479             <row>
 480               <entry>
 481                 <para> Minimum stripe size</para>
 482               </entry>
 483               <entry>
 484                 <para> 64 KB</para>
 485               </entry>
 486               <entry>
 487                 <para>Due to the 64 KB PAGE_SIZE on some 64-bit machines, the minimum stripe size is set to 64 KB.</para>
 488               </entry>
 489             </row>
 490             <row>              <entry>
 491                 <para> Maximum object size</para>              </entry>
 492               <entry>
 493                 <para> 16TB (ldiskfs), 256TB (ZFS)</para>
 494               </entry>
 495               <entry>
 496                 <para>The amount of data that can be stored in a single object. An object
 497                   corresponds to a stripe. The ldiskfs limit of 16 TB for a single object applies.
 498                   For ZFS the limit is the size of the underlying OST.
 499                   Files can consist of up to 2000 stripes, each stripe can contain the maximum object size. </para>
 500               </entry>
 501             </row>
 502             <row>
 503               <entry>
 504                 <para> Maximum <anchor xml:id="dbdoclet.50438256_marker-1290761" xreflabel=""/>file size</para>
 505               </entry>
 506               <entry>
 507                 <para> 16 TB on 32-bit systems</para>
 508                 <para>&#160;</para>
 509                 <para> 31.25 PB on 64-bit ldiskfs systems, 8EB on 64-bit ZFS systems</para>
 510               </entry>
 511               <entry>
 512                 <para>Individual files have a hard limit of nearly 16 TB on 32-bit systems imposed
 513                   by the kernel memory subsystem. On 64-bit systems this limit does not exist.
 514                   Hence, files can be 2^63 bits (8EB) in size if the backing filesystem can support large enough objects.</para>
 515                 <para>A single file can have a maximum of 2000 stripes, which gives an upper single file limit of 31.25 PB for 64-bit ldiskfs systems. The actual amount of data that can be stored in a file depends upon the amount of free space in each OST on which the file is striped.</para>
 516               </entry>
 517             </row>
 518             <row>
 519               <entry>
 520                 <para> Maximum number of files or subdirectories in a single directory</para>
 521               </entry>
 522               <entry>
 523                 <para> 10 million files (ldiskfs), 2^48 (ZFS)</para>
 524               </entry>
 525               <entry>
 526                 <para>The Lustre software uses the ldiskfs hashed directory code, which has a limit
 527                   of about 10 million files depending on the length of the file name. The limit on
 528                   subdirectories is the same as the limit on regular files.</para>
 529                 <para>Lustre file systems are tested with ten million files in a single
 530                   directory.</para>
 531               </entry>
 532             </row>
 533             <row>
 534               <entry>
 535                 <para> Maximum number of files in the file system</para>
 536               </entry>
 537               <entry>
 538                 <para> 4 billion (ldiskfs), 256 trillion (ZFS)</para>
 539                 <para condition='l24'>4096 times the per-MDT limit</para>
 540               </entry>
 541               <entry>
 542                 <para>The ldiskfs file system imposes an upper limit of 4 billion inodes. By default, the MDS file system is formatted with 2KB of space per inode, meaning 1 billion inodes per file system of 2 TB.</para>
 543                 <para>This can be increased initially, at the time of MDS file system creation. For more information, see <xref linkend="settinguplustresystem"/>.</para>
 544                                 <para condition="l24">Each additional MDT can hold up to the above maximum number of additional files, depending
 545                   on available space and the distribution directories and files in the file
 546                   system.</para>
 547               </entry>
 548             </row>
 549             <row>
 550               <entry>
 551                 <para> Maximum length of a filename</para>
 552               </entry>
 553               <entry>
 554                 <para> 255 bytes (filename)</para>
 555               </entry>
 556               <entry>
 557                 <para>This limit is 255 bytes for a single filename, the same as the limit in the underlying file systems.</para>
 558               </entry>
 559             </row>
 560             <row>
 561               <entry>
 562                 <para> Maximum length of a pathname</para>
 563               </entry>
 564               <entry>
 565                 <para> 4096 bytes (pathname)</para>
 566               </entry>
 567               <entry>
 568                 <para>The Linux VFS imposes a full pathname length of 4096 bytes.</para>
 569               </entry>
 570             </row>
 571             <row>
 572               <entry>
 573                 <para> Maximum number of open files for a Lustre file system</para>
 574               </entry>
 575               <entry>
 576                 <para> No limit</para>
 577               </entry>
 578               <entry>
 579                 <para>The Lustre software does not impose a maximum for the number of open files,
 580                   but the practical limit depends on the amount of RAM on the MDS. No
 581                   &quot;tables&quot; for open files exist on the MDS, as they are only linked in a
 582                   list to a given client&apos;s export. Each client process probably has a limit of
 583                   several thousands of open files which depends on the ulimit.</para>
 584               </entry>
 585             </row>
 586           </tbody>
 587         </tgroup>
 588       </table>
 589       <para>&#160;</para>
 590       <note>
 591         <para condition="l22">In Lustre software releases prior to release 2.2, the maximum stripe
 592           count for a single file was limited to 160 OSTs. In Lustre software release 2.2, the large
 593             <literal>xattr</literal> feature ("wide striping") was added to support up to 2000 OSTs.
 594           This feature is disabled by default at <literal>mkfs.lustre</literal> time. In order to
 595           enable this feature, set the "<literal>-O large_xattr</literal>" or "<literal>-O ea_inode</literal>"
 596           option on the MDT either by using <literal>--mkfsoptions</literal> at format time or by using
 597             <literal>tune2fs</literal>. Using either "<literal>large_xattr</literal>" or "<literal>ea_inode</literal>"
 598           results in "<literal>ea_inode</literal>" in the file system feature list.</para>
 599       </note>
 600     </section>
 601   </section>
 602   <section xml:id="dbdoclet.50438256_26456">
 603     <title><indexterm><primary>setup</primary><secondary>memory</secondary></indexterm>Determining Memory Requirements</title>
 604     <para>This section describes the memory requirements for each Lustre file system component.</para>
 605     <section remap="h3">
 606         <title>
 607             <indexterm><primary>setup</primary><secondary>memory</secondary><tertiary>client</tertiary></indexterm>
 608             Client Memory Requirements</title>
 609       <para>A minimum of 2 GB RAM is recommended for clients.</para>
 610     </section>
 611     <section remap="h3">
 612         <title><indexterm><primary>setup</primary><secondary>memory</secondary><tertiary>MDS</tertiary></indexterm>MDS Memory Requirements</title>
 613       <para>MDS memory requirements are determined by the following factors:</para>
 614       <itemizedlist>
 615         <listitem>
 616           <para>Number of clients</para>
 617         </listitem>
 618         <listitem>
 619           <para>Size of the directories</para>
 620         </listitem>
 621         <listitem>
 622           <para>Load placed on server</para>
 623         </listitem>
 624       </itemizedlist>
 625       <para>The amount of memory used by the MDS is a function of how many clients are on the system, and how many files they are using in their working set. This is driven, primarily, by the number of locks a client can hold at one time. The number of locks held by clients varies by load and memory availability on the server. Interactive clients can hold in excess of 10,000 locks at times. On the MDS, memory usage is approximately 2 KB per file, including the Lustre distributed lock manager (DLM) lock and kernel data structures for the files currently in use. Having file data in cache can improve metadata performance by a factor of 10x or more compared to reading it from disk.</para>
 626       <para>MDS memory requirements include:</para>
 627       <itemizedlist>
 628         <listitem>
 629           <para><emphasis role="bold">File system metadata</emphasis> : A reasonable amount of RAM needs to be available for file system metadata. While no hard limit can be placed on the amount of file system metadata, if more RAM is available, then the disk I/O is needed less often to retrieve the metadata.</para>
 630         </listitem>
 631         <listitem>
 632           <para><emphasis role="bold">Network transport</emphasis> : If you are using TCP or other network transport that uses system memory for send/receive buffers, this memory requirement must also be taken into consideration.</para>
 633         </listitem>
 634         <listitem>
 635           <para><emphasis role="bold">Journal size</emphasis> : By default, the journal size is 400 MB for each Lustre ldiskfs file system. This can pin up to an equal amount of RAM on the MDS node per file system.</para>
 636         </listitem>
 637         <listitem>
 638           <para><emphasis role="bold">Failover configuration</emphasis> : If the MDS node will be used for failover from another node, then the RAM for each journal should be doubled, so the backup server can handle the additional load if the primary server fails.</para>
 639         </listitem>
 640       </itemizedlist>
 641       <section remap="h4">
 642         <title><indexterm><primary>setup</primary><secondary>memory</secondary><tertiary>MDS</tertiary></indexterm>Calculating MDS Memory Requirements</title>
 643         <para>By default, 400 MB are used for the file system journal. Additional RAM is used for caching file data for the larger working set, which is not actively in use by clients but should be kept &quot;hot&quot; for improved access times. Approximately 1.5 KB per file is needed to keep a file in cache without a lock.</para>
 644         <para>For example, for a single MDT on an MDS with 1,000 clients, 16 interactive nodes, and a 2 million file working set (of which 400,000 files are cached on the clients):</para>
 645         <informalexample>
 646           <para>Operating system overhead = 512 MB</para>
 647           <para>File system journal = 400 MB</para>
 648           <para>1000 * 4-core clients * 100 files/core * 2kB = 800 MB</para>
 649           <para>16 interactive clients * 10,000 files * 2kB = 320 MB</para>
 650           <para>1,600,000 file extra working set * 1.5kB/file = 2400 MB</para>
 651         </informalexample>
 652         <para>Thus, the minimum requirement for a system with this configuration is at least 4 GB of RAM. However, additional memory may significantly improve performance.</para>
 653         <para>For directories containing 1 million or more files, more memory may provide a significant benefit. For example, in an environment where clients randomly access one of 10 million files, having extra memory for the cache significantly improves performance.</para>
 654       </section>
 655     </section>
 656     <section remap="h3">
 657       <title><indexterm><primary>setup</primary><secondary>memory</secondary><tertiary>OSS</tertiary></indexterm>OSS Memory Requirements</title>
 658       <para>When planning the hardware for an OSS node, consider the memory usage of several
 659         components in the Lustre file system (i.e., journal, service threads, file system metadata,
 660         etc.). Also, consider the effect of the OSS read cache feature, which consumes memory as it
 661         caches data on the OSS node.</para>
 662       <para>In addition to the MDS memory requirements mentioned in <xref linkend="dbdoclet.50438256_87676"/>, the OSS requirements include:</para>
 663       <itemizedlist>
 664         <listitem>
 665           <para><emphasis role="bold">Service threads</emphasis> : The service threads on the OSS node pre-allocate a 4 MB I/O buffer for each ost_io service thread, so these buffers do not need to be allocated and freed for each I/O request.</para>
 666         </listitem>
 667         <listitem>
 668           <para><emphasis role="bold">OSS read cache</emphasis> : OSS read cache provides read-only
 669             caching of data on an OSS, using the regular Linux page cache to store the data. Just
 670             like caching from a regular file system in the Linux operating system, OSS read cache
 671             uses as much physical memory as is available.</para>
 672         </listitem>
 673       </itemizedlist>
 674       <para>The same calculation applies to files accessed from the OSS as for the MDS, but the load is distributed over many more OSSs nodes, so the amount of memory required for locks, inode cache, etc. listed under MDS is spread out over the OSS nodes.</para>
 675       <para>Because of these memory requirements, the following calculations should be taken as determining the absolute minimum RAM required in an OSS node.</para>
 676       <section remap="h4">
 677         <title><indexterm><primary>setup</primary><secondary>memory</secondary><tertiary>OSS</tertiary></indexterm>Calculating OSS Memory Requirements</title>
 678         <para>The minimum recommended RAM size for an OSS with two OSTs is computed below:</para>
 679         <informalexample>
 680           <para>Ethernet/TCP send/receive buffers (4 MB * 512 threads) = 2048 MB</para>
 681           <para>400 MB journal size * 2 OST devices = 800 MB</para>
 682           <para>1.5 MB read/write per OST IO thread * 512 threads = 768 MB</para>
 683           <para>600 MB file system read cache * 2 OSTs = 1200 MB</para>
 684           <para>1000 * 4-core clients * 100 files/core * 2kB = 800MB</para>
 685           <para>16 interactive clients * 10,000 files * 2kB = 320MB</para>
 686           <para>1,600,000 file extra working set * 1.5kB/file = 2400MB</para>
 687           <para> DLM locks + file system metadata TOTAL = 3520MB</para>
 688           <para>Per OSS DLM locks + file system metadata = 3520MB/6 OSS = 600MB (approx.)</para>
 689           <para>Per OSS RAM minimum requirement = 4096MB (approx.)</para>
 690         </informalexample>
 691         <para>This consumes about 1,400 MB just for the pre-allocated buffers, and an additional 2 GB for minimal file system and kernel usage. Therefore, for a non-failover configuration, the minimum RAM would be 4 GB for an OSS node with two OSTs. Adding additional memory on the OSS will improve the performance of reading smaller, frequently-accessed files.</para>
 692         <para>For a failover configuration, the minimum RAM would be at least 6 GB. For 4 OSTs on each OSS in a failover configuration 10GB of RAM is reasonable. When the OSS is not handling any failed-over OSTs the extra RAM will be used as a read cache.</para>
 693         <para>As a reasonable rule of thumb, about 2 GB of base memory plus 1 GB per OST can be used. In failover configurations, about 2 GB per OST is needed.</para>
 694       </section>
 695     </section>
 696   </section>
 697   <section xml:id="dbdoclet.50438256_78272">
 698     <title><indexterm>
 699         <primary>setup</primary>
 700         <secondary>network</secondary>
 701       </indexterm>Implementing Networks To Be Used by the Lustre File System</title>
 702     <para>As a high performance file system, the Lustre file system places heavy loads on networks.
 703       Thus, a network interface in each Lustre server and client is commonly dedicated to Lustre
 704       file system traffic. This is often a dedicated TCP/IP subnet, although other network hardware
 705       can also be used.</para>
 706     <para>A typical Lustre file system implementation may include the following:</para>
 707     <itemizedlist>
 708       <listitem>
 709         <para>A high-performance backend network for the Lustre servers, typically an InfiniBand (IB) network.</para>
 710       </listitem>
 711       <listitem>
 712         <para>A larger client network.</para>
 713       </listitem>
 714       <listitem>
 715         <para>Lustre routers to connect the two networks.</para>
 716       </listitem>
 717     </itemizedlist>
 718     <para>Lustre networks and routing are configured and managed by specifying parameters to the
 719       Lustre networking (<literal>lnet</literal>) module in
 720         <literal>/etc/modprobe.d/lustre.conf</literal>.</para>
 721     <para>To prepare to configure Lustre networking, complete the following steps:</para>
 722     <orderedlist>
 723       <listitem>
 724         <para><emphasis role="bold">Identify all machines that will be running Lustre software and
 725             the network interfaces they will use to run Lustre file system traffic. These machines
 726             will form the Lustre network .</emphasis></para>
 727         <para>A network is a group of nodes that communicate directly with one another. The Lustre
 728           software includes Lustre network drivers (LNDs) to support a variety of network types and
 729           hardware (see <xref linkend="understandinglustrenetworking"/> for a complete list). The
 730           standard rules for specifying networks applies to Lustre networks. For example, two TCP
 731           networks on two different subnets (<literal>tcp0</literal> and <literal>tcp1</literal>)
 732           are considered to be two different Lustre networks.</para>
 733       </listitem>
 734       <listitem>
 735         <para><emphasis role="bold">If routing is needed, identify the nodes to be used to route traffic between networks.</emphasis></para>
 736         <para>If you are using multiple network types, then you will need a router. Any node with
 737           appropriate interfaces can route Lustre networking (LNET) traffic between different
 738           network hardware types or topologies --the node may be a server, a client, or a standalone
 739           router. LNET can route messages between different network types (such as
 740           TCP-to-InfiniBand) or across different topologies (such as bridging two InfiniBand or
 741           TCP/IP networks). Routing will be configured in <xref linkend="configuringlnet"/>.</para>
 742       </listitem>
 743       <listitem>
 744         <para><emphasis role="bold">Identify the network interfaces to include in or exclude from LNET. </emphasis>
 745     </para>
 746         <para>If not explicitly specified, LNET uses either the first available interface or a pre-defined default for a given network type. Interfaces that LNET should not use (such as an administrative network or IP-over-IB), can be excluded.</para>
 747         <para>Network interfaces to be used or excluded will be specified using the lnet kernel module parameters networks and <literal>ip2netsas</literal> described in <xref linkend="configuringlnet"/>.</para>
 748       </listitem>
 749       <listitem>
 750         <para><emphasis role="bold">To ease the setup of networks with complex network configurations, determine a cluster-wide module configuration.</emphasis></para>
 751         <para>For large clusters, you can configure the networking setup for all nodes by using a single, unified set of parameters in the <literal>lustre.conf</literal> file on each node. Cluster-wide configuration is described in <xref linkend="configuringlnet"/>.</para>
 752       </listitem>
 753     </orderedlist>
 754     <note>
 755       <para>We recommend that you use &apos;dotted-quad&apos; notation for IP addresses rather than host names to make it easier to read debug logs and debug configurations with multiple interfaces.</para>
 756     </note>
 757   </section>
 758 </chapter>