Internet DRAFT - draft-faibish-nfsv4-pnfs-block-disk-protection
draft-faibish-nfsv4-pnfs-block-disk-protection
NFSv4 Working Group S. Faibish
Internet-Draft EMC Corporation
Intended status: draft J. Glasgow
Expires: March 28, 2012 Google
Updates: 5663 D. Black
Intended Status: Proposed Standard EMC Corporation
September 27, 2011
pNFS block disk protection
draft-faibish-nfsv4-pnfs-block-disk-protection-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 28, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Faibish et al. Expires March 27, 2012 [Page 1]
Internet-Draft pNFS block disk protection September 2011
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to
enable direct client access to file data on storage, bypassing the
NFSv4 server. This can increase both performance and parallelism,
but requires additional client functionality, some of which depends
upon the type of storage used. The pNFS specification for block
storage (RFC 5663) describes how clients can identify the volumes
used for pNFS, but this mechanism requires communication with the
NFSv4 server. This document adds a mechanism to RFC 5663 that
enables identification of block storage devices used by pNFS file
systems without communicating with the server. This enables clients
to control access to pNFS block devices when the client initially
boots, as opposed to waiting until the client can communicate with
the NFSv4 server.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................4
3. GPT Partition Table Entry......................................4
4. Security Considerations........................................5
5. IANA Considerations............................................5
6. Conclusions....................................................5
7. References.....................................................5
7.1. Normative References......................................5
Authors' Addresses................................................6
Faibish et al. Expires March 27, 2012 [Page 2]
Internet-Draft pNFS block disk protection September 2011
1. Introduction
Figure 1 shows the overall architecture of a Parallel NFS (pNFS)
system:
+-----------+
|+-----------+ +-----------+
||+-----------+ | |
||| | NFSv4.1 + pNFS | |
+|| Clients |<------------------------------>| MDS |
+| | | |
+-----------+ | |
||| +-----------+
||| |
||| |
||| Storage +-----------+ |
||| Protocol |+-----------+ |
||+----------------||+-----------+ Control |
|+-----------------||| | Protocol |
+------------------+|| Storage |------------+
+| Devices |
+-----------+
Figure 1 pNFS Architecture
In this document, "storage device" is used as a general term for a
data server and/or storage server for any pNFS layout type. The
MetaData Server (MDS) is the NFSv4 server that provides pNFS layouts
to clients and handles operations on file metadata (e.g., names,
attributes).
For the pNFS block protocol as specified in [RFC5663], client
identification of pNFS storage devices requires contacting the MDS to
obtain device signature information. It is not possible for a pNFS
client to reliably identify pNFS block storage devices without
contacting the MDS because the device signature location and contents
may vary among devices and servers; both device signature location
and contents are determined by the MDS, not the client.
Typical operating system (OS) boot functionality scans and activates
block devices (e.g., SCSI) before activating the NFS client
(including pNFS functionality). That sequence of operations creates
a window of time during which the client OS may modify a pNFS block
device without contacting the server (e.g., by attempting to mount or
initialize a local physical filesystem). This document specifies an
Faibish et al. Expires March 27, 2012 [Page 3]
Internet-Draft pNFS block disk protection September 2011
identification mechanism for pNFS block storage devices that can be
used by an OS implementation to remove this window of vulnerability.
Many storage area network (SAN) storage systems provide quasi-static
access control mechanisms (e.g., Logical Unit Number (LUN) mapping
and/or masking) that operate at the granularity of individual hosts.
While it is feasible to use such mechanisms to remove this window
(e.g., by only enabling a client to access pNFS block storage devices
after the client has contacted the responsible MDS), that usage is
undesirable and potentially problematic. This is because the storage
access control mechanisms are quasi-static; they are typically
configured once to allow client access to the block pNFS storage
devices and not reconfigured dynamically (e.g., based on crashes and
reboots). Block storage access controls can be changed to respond to
unusual circumstances (e.g., to fence [remove access from] an
uncooperative pNFS client), but should not be used as part of routine
client operations (e.g., reboot). A different mechanism is needed.
This document specifies an entry in the GUID partition table (GPT)
that can be used to identify pNFS devices. This GPT entry is intended
for shared storage devices that are accessible to pNFS clients and
servers, and that may be accessible to other hosts or systems.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
3. GPT Partition Table Entry
The following mechanism enables pNFS clients to identify pNFS block
storage devices without contacting the server:
- Each block storage device dedicated to pNFS includes a GUID
partition table (GPT) [GPT].
- The pNFS Block Storage partitions are identified in the GPT with
GUID e5b72a69-23e5-4b4d-b176-16532674fc34. This GUID has been
generated by one of the draft authors for this purpose.
This mechanism enables an operating system to prevent non-pNFS access
to pNFS block storage immediately upon boot. Servers that support
pNFS block layouts SHOULD use the GPT and this GUID for all pNFS
block storage devices.
Faibish et al. Expires March 27, 2012 [Page 4]
Internet-Draft pNFS block disk protection September 2011
A pNFS client operating system that supports block layouts SHOULD
recognize this GUID and use its presence to prevent data access to
pNFS block devices until a layout that includes the device is
received from the MDS.
Data stored on pNFS block layout storage devices can be better
protected by incorporating checks for this GUID into other hosts and
systems that do not support pNFS block layouts. If pNFS block
storage devices are presented to such hosts or systems by mistake,
the check for presence of this GUID can be used to prevent writes
that could otherwise corrupt stored pNFS data.
As of 2011 many current operating system versions support GPT
including FreeBSD, Linux and Solaris [GPT].
4. Security Considerations
The pNFS block layout security considerations in [RFC5663] apply to
this document.
5. IANA Considerations
There are no IANA considerations in this document.
6. Conclusions
This document specifies an identification mechanism for pNFS block
storage devices that can be used to protect those devices during
operating system boot before the pNFS meta data server can be
contacted.
7. References
7.1. Normative References
[GPT] http://en.wikipedia.org/wiki/GUID_Partition_Table
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5663] Black, D., Glasgow, J., Fridella, S., "Parallel NFS (pNFS)
Block/Volume Layout", http://tools.ietf.org/html/rfc5663,
January 2010.
This document was prepared using 2-Word-v2.0.template.dot.
Faibish et al. Expires March 27, 2012 [Page 5]
Internet-Draft pNFS block disk protection September 2011
Authors' Addresses
Sorin Faibish (editor)
EMC Corporation
228 South Street
Hopkinton, MA 01748
US
Phone: +1 (508) 305-8545
Email: sfaibish@emc.com
Jason Glasgow
Google
5 Cambridge Center, Floors 3-6
Cambridge, MA 02142
US
Phone: +1 (617) 575 1599
Email: jglasgow@google.com
David L. Black
EMC Corporation
176 South Street
Hopkinton, MA 01748
US
Phone: +1 (508) 293-7953
Email: david.black@emc.com
Faibish et al. Expires March 27, 2012 [Page 6]
