13.2 Planning OES File Storage

13.2.1 Directory Structures

To plan the directory structures you need on OES 11 SP3, see Understanding Directory Structures in Linux POSIX File Systems in the OES 11 SP3: File Systems Management Guide.

13.2.2 File Service Support Considerations

Figure 13-2 shows which file services can access which volume types.

Figure 13-2 File Services Supported on Volume Types

13.2.3 General Requirements for Data Storage

Finding the right storage solution requires you to identify your data storage requirements. You might want to compare your list of requirements against those described in Storage Solutions in the OES 11 SP3: Storage and File Services Overview.

13.2.4 OES 11 SP3 Storage Planning Considerations

Not all data is the same. Not all workloads are the same. Not all file systems are the same. Matching your data and workloads to the available file systems and their capabilities lets you build efficient, scalable, and cost-effective solutions. This section discusses issues to consider when planning your file systems on OES 11 SP3 servers, and includes the following topics:

The Workgroup Environment

When selecting a file system, it is important to understand the environment in which it operates. For OES 11 SP3, the primary target environment is the workgroup, which requires the following:

  • A shared file system for Linux, Macintosh, and Windows desktops. Think of this as a NAS (network-attached storage) for desktops.

  • A rich, flexible permissions model to maintain security while providing for the management of many different users with different permissions throughout the file system. The permissions must be granular, allow for delegation of permission management, and ease the administrative burden in an environment where change is constant.

  • A robust enterprise-wide identity management system tied into authentication and file system permissions is a must.

  • The capabilities for correcting end user mistakes that are made daily (accidental overwrites, deletes, etc.).

  • Integration with collaboration tools.

  • Data encryption on an individual user or group basis for compliance and security.

  • Departmental Web servers and databases.

  • SAN support to provide flexible storage management.

  • Backup support for both desktop and server data, with rich tools for monitoring the health of the backup system and quickly locating and repairing problems with data protection.

  • Regulatory compliance. Regulatory requirements are now pushing new models of protecting and storing employee-generated data that is in LAN systems. It is important to apply correct regulatory requirements only on those users to which they must be applied, and then to produce audits showing compliance.

  • Highly available collaboration (e-mail) services, with rich tools to monitor, audit, and trend resource usage.

File System Support

OES 11 offers support for five file systems: Novell Storage Services (NSS), Ext 2, Ext3, Reiser, and XFS. Following is an explanation of each file system and the pros and cons of using them in the workloads supported by OES 11.

Novell Storage Services (NSS)

  • Supported only through NSS management tools; not supported through native Linux Management tools.

  • Best for shared LAN file serving; excellent scalability in the number of files

  • Journaled

  • Novell Trustee Model and NSS directory and file attributes (such as Rename Inhibit) provide access control that is much richer than POSIX and Linux access control lists (ACLs)

The Novell Storage Services file system is used in NetWare 5.0 and above, is included in the Novell Open Enterprise Server.

The NSS file system is unique in many ways, especially in its ability to manage and support shared file services from simultaneous different file access protocols. It is designed to manage access control (using a unique model, called the Novell Trustee Model, that scales to hundreds of thousands of different users accessing the same storage securely) in enterprise file sharing environments.

NSS and its predecessor NWFS are the only file systems that can restrict the visibility of the directory tree based on the user ID accessing the file system. NSS and NWFS have built-in ACL (access control list) rights inheritance. NSS includes mature and robust features tailored for the file-sharing environment of the largest enterprises. The file system also scales to millions of files in a single directory. NSS also supports multiple data streams and rich metadata; its features are a superset of existing file systems on the market for data stream, metadata, name space, and attribute support.

Btrfs

  • Writable snapshots that allow you to easily roll back your system if needed after applying updates, or to back up files.

  • Multiple device support that allows you to grow or shrink the file system.

  • Compression to efficiently use storage space.

  • Different RAID levels for metadata and user data.

  • Different checksums for metadata and user data to improve error detection.

  • Integration with Linux Logical Volume Manager (LVM) storage objects.

  • Integration with the YaST Partitioner on SUSE Linux.

BtrFS creates a default subvolume in its assigned pool of space. It allows you to create additional subvolumes that act as individual file systems within the same pool of space. The number of subvolumes is limited only by the space allocated to the pool.

If BtrFS is used for the root (/) file system, you can cover any subdirectory as a subvolume as you might normally do. You should also consider covering the following subdirectories in separate subvolumes because they contain files that you might prefer not to snapshot for the reasons given:

Path

Reason to Cover as a Subvolume

/opt

Contains third-party add-on application software packages.

/srv

Contains http and ftp files.

/tmp

Contains temporary files.

/var/log

Contains log files.

/var/opt

Contains run-time variable data for /opt.

/var/run

Contains run-time variable data.

/var/spool

Contains data that is awaiting processing by a program, user, or administrator, such as news, mail, and printer queues.

/var/tmp

Contains temporary files or directories that are preserved between system reboots.

Ext2

  • Legacy file system

  • Not journaled

  • POSIX access control

Ext2 does not maintain a journal, so it is generally not desirable to use it for any server that needs high availability, with one important exception. If a paravirtualized server is running as a Xen VM guest, you should format the /boot partition with Ext2 as explained in Section 9.4, Xen VMs Need Ext2 for the System /Boot Volume.

Ext3

  • Most popular Linux file system; limited scalability in size and number of files

  • Journaled

  • POSIX extended access control

The Ext3 file system is a journaled file system that has the widest use in Linux today. It is the default file system for SUSE Linux 11 distributions. It is quite robust and quick, although it does not scale well to large volumes or a great number of files.

A scalability feature has been added called H-trees, which significantly improved Ext3's scalability. However, it is still not as scalable as some of the other file systems. With H-trees, it scales similarly to NTFS. Without H-trees, Ext3 does not handle more than about 5,000 files in a directory.

Reiser

  • Best performance and scalability when the number of files is great and/or files are small

  • Journaled

  • POSIX extended access control

Reiser was designed to remove the scalability and performance limitations that exist in Ext2 and Ext3 file systems.

Reiser scales and performs extremely well on Linux, outscaling Ext3 with H-trees. In addition, Reiser was designed to use disk space very efficiently.

XFS

  • Best for extremely large file systems, large files, and lots of files

  • Journaled (an asymmetric parallel cluster file system version is also available)

  • POSIX extended access controls

The XFS file system is open source and is included in major Linux distributions. It originated from SGI (Irix) and was designed specifically for large files and large volume scalability.

Video and multimedia files are best handled by this file system. Scaling to petabyte volumes, it also handles very large amounts of data. It is one of the few file systems on Linux that supports HSM data migration.

File Access Protocol Support

OES 11 SP3 offers support for a variety of file access protocols.

  • AFP: The Apple Filing Protocol (AFP) is a network protocol that offers file services for Mac OS X and the original Mac OS.

  • CIFS (Novell CIFS and Novell Samba): The Common Internet File Services (CIFS) protocol is the protocol for Windows networking and file services.

    Novell CIFS is a ported version of the CIFS file service traditionally available only on NetWare. It supports Novell Trustee model access for NSS volumes and Dynamic Storage Technology shadow volumes

    Novell Samba is a Novell’s customized version of an open source software version of CIFS developed after extensive use and analysis of the wire protocol of Microsoft Windows machines.

  • FTP: The File Transfer Protocol (FTP) is one of the most common and widely used simple protocols in the Internet. Virtually all platforms and devices support FTP at some level, but it is a very simple protocol, only allowing for uploading and downloading of files. OES provides FTP functionality similar to that available on NetWare. For more information, see Section 18.5, Novell FTP (Pure-FTPd) and OES 11 SP3.

  • HTTP: The Hypertext Transfer Protocol (HTTP) is the dominant protocol on the World Wide Web today, and is the one “spoken” by Web browser clients and Web servers. It is like FTP in being designed strictly for transfers of HTML (Hypertext Markup Language) and additional markup languages that have been invented, such as XML (Extensible Markup Language).

  • NCP: The NetWare Core Protocol (NCP) is the client server protocol that was developed by Novell for supporting DOS, Windows, OS/2, Macintosh, UNIX (UnixWare), and Linux for shared file services.

    The NCP Server included in OES features emulation of the Novell Trustee Model and inheritance plus visibility when it runs on traditional POSIX file systems such as Ext3, Reiser, and XFS. When it runs on NSS, these capabilities are synchronized with the NSS File system and its extended directory and file attributes, such as Rename Inhibit.

OES 11 SP3 Workloads

Each file system has its strengths and weaknesses depending on the workload the file system supports. This section gives some guidelines for picking and building the right file system for a given workload. In determining which file system to use for a particular workload, consider your environment and the following explanation of each workload to determine which file system best meets your workload environment.

Table 13-2 File System Support per Workload

Workload Type

NSS File System

Btrfs

Ext3 File System

Reiser File System

XFS File System

AFP (Novell AFP)

Supported

Not Supported

Not Supported

Not Supported

Not Supported

CIFS (Novell CIFS)

Supported

Not Supported

Not Supported

Not Supported

Not Supported

Cluster Services

Recommended

Supported

Recommended

Recommended

Recommended

Collaboration (GroupWise)

Supported

Supported

Recommended

Supported

Supported

Dynamic Storage Technology

Supported

Not Supported

Not Supported

Not Supported

Not Supported

File serving – Application server

Supported

Supported

Supported

Recommended

Recommended

iFolder

Recommended

Supported

Supported

Recommended

Recommended

NCP (Novell Client)

Recommended

Supported

Supported

Supported

Supported

NetStorage

Recommended

Supported

Recommended

Recommended

Recommended

Printing (iPrint)

Recommended

Supported

Recommended

Recommended

Recommended

PureFTP

Recommended

Supported

Recommended

Recommended

Recommended

The following sections provide a brief summary of considerations for the workload types listed in Table 13-2.

Collaboration (GroupWise)

GroupWise deals with many little files. Because only the application process is accessing the file system, the added overhead of the rich ACL and file attributes found in NSS is redundant. The necessary characteristics are a file system whose performance remains relatively constant regardless of the number of files that are in the volume, and that performs well with small files. GroupWise recommends the Ext3 file system. NSS and Reiser are also supported.

Dynamic Storage Technology

Dynamic Storage Technology does not depend on a particular file system in principle; however, it is currently supported only on NSS volumes.

File Serving

Generally there are two types of NAS use cases: Serving files to application servers in a tiered service oriented architecture (SOA), and serving files to end user desktops and workstations. The former has minimal access control requirements. The latter has quite heavy access control requirements.

Typically for serving files to application servers (traditional NAS), you would choose a file system that is scalable and fast. Reiser and XFS would be good choices in this environment. For file serving to end user workstations, the access control and security management capabilities of the NSS file systems with AFP, CIFS, and NCP file access protocols are important.

The NSS model does better than the other file systems for very large numbers of users. It allows for security between users and also allows for very fine granular sharing between given users and groups. NSS includes a visibility feature implemented in the file system that prevents unauthorized users from even seeing subdirectory structures they don't have rights to access.

iFolder

Novell iFolder does not depend on a particular file system. Based on the client workload, the file system should be chosen at the server side. Because it mostly serves user data, a file system that can scale with a large number of files is the best suited in most deployments, making Reiser and NSS the best bets. Novell iFolder maintains its own ACL, so having an NSS file system that supports a rich ACL might be redundant.

Novell Cluster Services

Novell Cluster Services does not depend on a particular file system. For shared storage, the file systems software must be available from node to node. For example, if you are using NSS on one node, you need to use NSS on the failover node as well.

Printing (iPrint)

iPrint is file system agnostic. There is no noticeable difference in performance or reliability on any of the file systems.

13.2.5 NSS Planning Considerations

To plan for NSS volumes—including prerequisites and security considerations—see Planning NSS Storage Solutions in the OES 11 SP3: NSS File System Administration Guide for Linux.