PSARC Questions Version 1.17 PSARC inception review material for PSARC/2007/249, pNFS ------------------------------------------------------------------------ 1. What specifically is the proposal that we are reviewing? This project delivers pNFS into the ON consolidation of Solaris Nevada. pNFS is parallel NFS. NFS file data, which was traditionally stored on a single server, can now be split up onto multiple "data servers" and a meta-data server. pNFS clients can then access the data in parallel for high through-put. Parallelized, high through-put file I/O over a network is a requirement for the high performance computing (HPC) market segment. pNFS is a part of the NFSv4.1 specification. The project team shall deliver all of the necessary NFSv4.1 extensions to enable pNFS. 2. Describe how your project changes the user experience, upon installation and during normal operation. The project team shall deliver an implementation which is is backward compatible with existing NFS protocols. Client systems with pNFS installed will continue to access non-PNFS aware systems in the usual way. Server systems will continue to offer NFS service with the usual port, program, and version numbers. A pNFS aware client will negotiate the NFS minor version number with the server, beginning with major version 4 & minor version 1, then proceeding down the minor version number chain, then the major version chain until a compatible pair is discovered. This version negotiation mechanism is subject to the administrative controls currently in place. 3. What is its plan? The I-team currently has a well developed prototype which includes client & server side implementations of pNFS as well as the necessary pieces of NFSv4.1. This has served as the basis of our interoperability testing at Connectathon and other NFS testing events. 4. Are there related projects in Sun? There are no other NFSv4.1 project in progress at Sun. The project team will not be making changes to areas owned by other groups. 5. How is the project delivered into the system? The project team will deliver modifications to the existing NFS packages: SUNWnfscr, SUNWnfscu, SUNWnfssr, and SUNWnfssu. No new packages are planned. 6. Describe the project's hardware platform dependencies. pNFS will run on both SPARC and x86 platforms and has no hardware platform dependencies. pNFS will use the RDMA capabilities of IB hardware, if it is present. 7. System administration The administration of a pNFS enabled client is similar to for existing NFS clients. The "-o vers=X" option of the mount command is extended. "-o vers=41" will force the client to use NFSv4.1 and fail it if is not available. In the absence of this option, the client shall negotiate the version and minor version as described above. The mount command shall also be extended to provide an "-o nopnfs" option. This option shall disable the client's use of pNFS while still allowing it to use NFSv4.1. Both of these options may be controlled system wide via configuration variables stored in /etc/default/nfs. A project is underway to convert all parameters in /etc/default/nfs into SMF properties; please see PSARC/2007/393 for more details. The mount command line options take precedence over these properties, as they do today. New commands are added to enable the administration of a pNFS server community and the file layout policies. Details are provided in the functional specification. 8. Reliability, Availability, Serviceability (RAS) The pNFS meta-data server shall have improved availability characteristics using an "active-passive" availability model. 9. Observability The nfsstat command shall be extended to provide visibility into the NFSv4.1 protocol. Static Dtrace probes will be added to the client, data server, and meta-data server to provide additional observability. These probes will dove-tail with a project already in progress (by the Beijing ERI) to implement an dtrace NFS provider. Further details are available here: http://opensolaris.org/os/project/nfs4trace/ 10. What are the security implications of this project? pNFS will use the existing RPCSEC_GSS security mechanisms to provide strong authentication, integrity, and privacy to NFS requests via Kerberos V5. Use of these mechanisms is optional, a system administrator may choose to use the traditional "auth_sys" mechanism. RPCSEC_GSS may also be used to secure the control protocol. NFSv4.1 does not extend the existing NFSv4.0 access control mechanisms in any significant way. Access control via ACLs will be available. The project will deliver Trusted Solaris labeling in a manner which is functionally equivalent to NFSv4.0. 11. What is its UNIX operational environment: pNFS will become an integral part of the Solaris NFS implementation; the overall operation environment of NFS is unchanged. 12. What is its window/desktop operational environment? The project does not deliver any windowing or desktop capabilities or components. 13. What interfaces does your project import and export? A detailed interface table is provided in the functional specification included with this case. 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? This project delivers a project private, control protocol between the meta-data server and the data servers. Details of this protocol are provided in the functional specification. 15. Is the interface extensible? How will the interface evolve? The primary interface to pNFS is the traditional SUS file API. No extensions are planned or needed. Extensions to the NFS protocol itself will be done using the major and minor version number mechanism defined by the working group. These extensions would be implemented in a way to provide backward compatibility. The control protocol can be extended via the RPC version mechanism. Backward compatibility will be maintained, as needed, by supporting multiple version numbers, just as nfsd does with various versions of the NFS protocol which Solaris supports today. 16. How do the interfaces adapt to a changing world? As an open protocol, NFS is controlled by the diligent engineers that participate in the IETF. It is this open process that will allow NFS to adapt to changing requirements. 17. Interoperability NFSv4.1 is an open protocol. Interoperability with other implementations is vitally important. The project team is fully engaged with other implementors in interoperability test events such as Connectathon and NFSv4 bake-a-thons as recently as June 2007, hosted at the Austin Sun site. The project team actively participates in the development of protocol in the NFSv4 working group. The control protocol between the meta-data server and the data servers is not a standardized protocol and no interoperability between Solaris and non-Solaris meta-data and data servers is provided. 18. Performance The goal of pNFS is to deliver near linear scalability of I/O through-put as data servers are added to the community. The PRD/PCD refines this requirement for a 4 data-server configuration as being "at least 3.3x the throughput of a single server". Detailed performance requirements are further enumerated in the PRD/PCD. In general, the performance of NFSv4.1 (without pNFS) will be comparable to that of NFSv4.0. 19. Please identify any issues that you would like the ARC to address. None. 20. Appendices to include Documents provided: One-Pager Functional Specification NFSv4.1 draft 11 PRD/PCD @(#)pnfs-20q.txt 1.5 07/07/03