Question
What do WebSphere Application Server V6.1, V7.0, V8.0, V8.5, and V8.5.5 require in terms of filesystem support on networks? How do networked filesystems affect the way IBM Support provides support for WebSphere Application Server products?
Cause
WebSphere Application Server is tested on operating systems which use local filesystems, meaning that the filesystems are located on disks which are directly attached to the physical hardware hosting the system.
There are other methods of attaching filesystems to a host system, such as using Networked Filesystems (NFS) on UNIX or Linux-based systems, Mapped Network Drives on Windows-based systems, or Storage Area Network (SAN) resources. This technote describes some general guidelines associated with installing the product in environments which use these filesystem solutions.
In general, WebSphere Application Server tolerates the use of these methods to attach filesystems to a host system. However, the filesystems must be attached to the host system in a manner which makes it appear indistinguishable from a local filesystem. The system administrators must be completely responsible for the configuration and maintenance of these filesystem solutions.
Please note that this article primarily applies to traditional WebSphere Application Server, and does not necessarily apply to Liberty Profiles.
In general, WebSphere Application Server tolerates the use of these methods to attach filesystems to a host system. However, the filesystems must be attached to the host system in a manner which makes it appear indistinguishable from a local filesystem. The system administrators must be completely responsible for the configuration and maintenance of these filesystem solutions.
Please note that this article primarily applies to traditional WebSphere Application Server, and does not necessarily apply to Liberty Profiles.
Answer
Network filesystem support
For the sake of brevity, the term Networked Filesystem (NFS) is used for representing a UNIX or Linux Networked Filesystem, a Windows Mapped Network Drive (or other Windows shared resource), a Storage Area Network (SAN), or any other configuration where files are hosted on a resource which is not considered "local" to the system it is running on.
WebSphere Application Server can be installed to or from a networked filesystem as long as the environment meets certain requirements. As stated below, these are fairly strict requirements, and it is entirely the responsibility of the system administrator to ensure that the filesystems behave properly.
If IBM Support suspects that a networked filesystem's behavior is causing an issue, IBM Support may ask for the problem to be reproduced using a local filesystem. If the problem cannot be reproduced on a local filesystem, IBM Support may ask the system administrator to address the root cause of the problem from the perspective of the network and filesystem.
Filesystem requirements for UNIX and Linux-based systems
WebSphere Application Server can be installed to or from a networked filesystem as long as the environment meets certain requirements. As stated below, these are fairly strict requirements, and it is entirely the responsibility of the system administrator to ensure that the filesystems behave properly.
If IBM Support suspects that a networked filesystem's behavior is causing an issue, IBM Support may ask for the problem to be reproduced using a local filesystem. If the problem cannot be reproduced on a local filesystem, IBM Support may ask the system administrator to address the root cause of the problem from the perspective of the network and filesystem.
Filesystem requirements for UNIX and Linux-based systems
- File locking and lock daemon processes:
The WebSphere Application Server installer requires the capability to lock files in the user's home directory, as well as files in the temporary directory and files in the targeted installation directory. If the network filesystem does not properly handle file locking, the product installer might hang on startup. For this reason, the NFS client must have file-locking capabilities. For some types of NFS, this means that you may need to run the lock daemon processes, such as lockd or nfslock, and statd. For more information, refer to technote 1316694. - Mount point permissions:
When a remote filesystem is mounted, it is typically attached to an empty directory which serves as the mount point. The user installing the software does not need read and write access to the mount point, they need read and execute permissions on the mount point. This lets them correctly enter and list the attributes of the mounted filesystem.The permissions of that empty directory mount point must allow the product's users to have appropriate read/execute access. The permissions on that empty directory mount point can affect access to files in the mounted filesystem, even though the permissions on the mount point become "hidden" when the filesystem is mounted. If the permissions are incorrect, this can cause issues with the product installer, such as the "Illegal character at index 18" error. For more information, refer to technote 1316005.
Filesystem requirements for Windows-based systems
- Do not use UNC paths with the product installer:
As stated in the Information Center article for installing WebSphere Application server (such as the article for V7.0 Network Deployment), the WebSphere Application Server installer has issues installing the product from UNC paths. When installing WebSphere Application Server from a networked filesystem that is accessed from a UNC path (for example, it is accessed using the convention \\ServerName\ShareName\Directory), some product files might not be installed. It is better to install WebSphere Application Server from a Mapped Network Drive if it is being installed from a network resource. - Use UNC paths after the product is installed:
Once the product is installed, it is best to avoid any further use of Mapped Network Drives. Instead, use UNC paths to reference networked locations after the product is installed. This recommendation stems from the fact that different Windows users do not have access to other users Mapped Network Drives, which can cause issues if the product is configured to run as a Windows Service. For more information, refer to technote 1316456.
Networked Filesystem (NFS) server requirements
- NFS availability must be consistent and uninterrupted:
The NFS server must be capable of providing uninterrupted connectivity to the filesystem which contains WebSphere Application Server. If the NFS connection is interrupted or the operating system reports a timeout while attempting to access the files on the NFS, then the product installation process will be interrupted. If an application server is running on an NFS and the connection is interrupted, then application server is at risk of hanging or crashing. From the perspective of the application server process, there is no way to mitigate the impact of interruptions to accessing the NFS. The NFS must be consistently available. - NFS server must be configured properly:
The system administrator must configure the NFS server, and understand how to configure elements such as /etc/exports, /etc/hosts.allow, /etc/hosts.deny, Windows file permissions, Windows domains, UNIX file permissions, and so on. Refer to the appropriate NFS documentation for handling this. IBM WebSphere Application Server support cannot assist with questions regarding NFS configuration or best practices. - NFS server permissions:
The application server installer must have complete read-write access to the directory that WebSphere Application Server will be installed to.
Networked Filesystem client requirements
- Concurrent file access:The product files must only be used by running server processes on one system at any given time. WebSphere Application Server does not support multiple systems running application servers or product tools from a single install located on a shared networked filesystem. In short, installing WebSphere Application Server once on an NFS and using multiple systems to run from that one install is not supported.
Note that it is possible to install WebSphere Application Server on a shared networked filesystem, then use high-availability software to allow one system in a high-availability cluster to run application servers. If a system in the cluster fails, then the high-availability software can shut down and disconnect one system from the shared networked filesystem, then connect a different system to the shared networked filesystem. The other system can then start and run application servers. This is acceptable because only one system is using the product files at any given time. For more information about support for high-availability solutions, see technote 1419214.
As noted earlier, this article is focused on support of traditional WebSphere Application Server, and not Liberty Profiles. In particular, the binaries in Liberty Profiles can be configured in a manner which allows shared concurrent file access. - Client software:
Be sure to run NFS client software which is up-to-date. Check with the operating system and filesystem vendor to ensure that the NFS software is appropriately updated. - Host access and firewalls:
The NFS client must run appropriate processes to establish the connection with the host, such as the portmap process. The NFS client must have appropriate consistent access through a firewall. - NFS client permissions:
The NFS client must have permission to access files on the host system. If the client and host are different operating system types (such as an AIX client accessing files shared on a Windows host, or a Windows client accessing files stored on a Solaris host), then the system administrator must ensure that file permissions and symbolic links are maintained consistently when the files are accessed using that client. - NFS client performance:
WebSphere administrators should be aware that running WebSphere Application Server from a networked filesystem can adversely affect is performance. The networked filesystem should allow access to the product files as quickly and consistently as possible, performing similarly to local filesystems.
댓글 없음:
댓글 쓰기