DOCSLIB.ORG

Implementing Nfsv4 in the Enterprise: Planning and Migration Strategies

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Front cover Implementing NFSv4 in the Enterprise: Planning and Migration Strategies Planning and implementation examples for AFS and DFS migrations NFSv3 to NFSv4 migration examples NFSv4 updates in AIX 5L Version 5.3 with 5300-03 Recommended Maintenance Package Gene Curylo Richard Joltes Trishali Nayar Bob Oesterlin Aniket Patel ibm.com/redbooks International Technical Support Organization Implementing NFSv4 in the Enterprise: Planning and Migration Strategies December 2005 SG24-6657-00 Note: Before using this information and the product it supports, read the information in “Notices” on page xi. First Edition (December 2005) This edition applies to Version 5, Release 3, of IBM AIX 5L (product number 5765-G03). © Copyright International Business Machines Corporation 2005. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . xi Trademarks . xii Preface . xiii The team that wrote this redbook. xiv Acknowledgments . xv Become a published author . xvi Comments welcome. xvii Part 1. Introduction . 1 Chapter 1. Introduction. 3 1.1 Overview of enterprise file systems. 4 1.2 The migration landscape today . 5 1.3 Strategic and business context . 6 1.4 Why NFSv4? . 7 1.5 The rest of this book . 8 Chapter 2. Shared file system concepts and history. 11 2.1 Characteristics of enterprise file systems . 12 2.1.1 Replication . 12 2.1.2 Migration . 12 2.1.3 Federated namespace . 13 2.1.4 Caching . 13 2.2 Enterprise file system technologies. 13 2.2.1 Sun Network File System (NFS) . 13 2.2.2 Andrew File System (AFS) . 14 2.2.3 Distributed Computing Environment/Distributed File System . 15 2.3 General considerations when using enterprise file systems . 16 Part 2. NFSv4 on AIX 5L V5.3. 19 Chapter 3. NFSv4 implementation . 21 3.1 Implementation of the NFSv4 protocol in AIX 5L V5.3 . 22 3.2 NFSv4 features supported in the initial AIX 5L V5.3 release . 22 3.2.1 External namespace (exname) support . 23 3.2.2 FSIDs and file handles . 25 3.3 Features introduced in AIX 5L V5.3 RML03 . 26 3.3.1 Delegation . 27 © Copyright IBM Corp. 2005. All rights reserved. iii 3.3.2 Referral . 30 3.3.3 Replication . 36 3.4 List of NFSv4 features supported in AIX 5L V5.3 . 50 Chapter 4. Using NFSv4 with JFS2 or GPFS . 53 4.1 AIX 5L enhanced journaled file system (JFS2) . 54 4.1.1 Comparing JFS2 with JFS . 56 4.1.2 JFS2 advanced features . 57 4.1.3 Using JFS2 with NFSv4 . 59 4.1.4 JFS2 ACLs versus NFSv4 ACLs. 59 4.1.5 How do we implement inheritance NFSv4 ACLs? . 62 4.2 General Parallel File System (GPFS) . 63 4.2.1 Why GPFS? . 66 4.2.2 GPFS advantages. 67 4.2.3 When to consider GPFS . 70 4.2.4 Planning considerations for GPFS . 70 4.2.5 Using NFSv4 with GPFS. 70 4.2.6 NFSv4 export considerations for GPFS . 72 4.2.7 NFS usage of GPFS cache. 72 4.2.8 NFSv4 ACL administration . 72 4.2.9 NFS client with stale inode data . 79 4.3 Backup considerations . 79 Chapter 5. Using NFSv4 features. 81 5.1 Using the cache file system (CacheFS) . 82 5.1.1 CacheFS performance benefits . 82 5.1.2 CacheFS performance impacts. 83 5.1.3 Configuring CacheFS . 84 5.2 Managing LDAP automount maps . 85 5.3 Pseudo file system . 87 5.4 NFSv4 ACLs . 90 5.4.1 NFSv4 ACLs: ACL evaluation . 95 5.4.2 NFSv4 ACLs: Administration. 98 5.4.3 NFSv4 ACLs: ACL inheritance and umask . 103 5.4.4 NFSv4 ACLs: Permissions scenarios . 110 5.4.5 NFSv4 ACLs: ACL evaluation flowchart for NFSv4 . 112 5.4.6 NFSv4 ACLs: NFSv3 clients . 114 Part 3. Preparing to use NFSv4 . 115 Chapter 6. Building an NFSv4 environment . 119 6.1 Environment used for demonstration scenarios . 120 6.2 Infrastructure setup flow . 120 6.3 Network Time Protocol (NTP) configuration . 122 iv Implementing NFSv4 in the Enterprise: Planning and Migration Strategies 6.4 IBM Tivoli Directory Server V5.2 . 122 6.4.1 Preparing the system for IBM Tivoli Directory Server installation . 124 6.4.2 Installing IBM Tivoli Directory Server . 126 6.4.3 Configuring IBM Tivoli Directory Server . 127 6.4.4 Configuring Tivoli Directory Server to be a client of itself . 133 6.5 IBM Network Authentication Services (Kerberos V5) server installation. 134 6.5.1 Setting up the environment . 134 6.5.2 Configuring the NAS server . 134 6.6 IBM Tivoli Directory Server client configuration. 140 6.7 IBM Network Authentication Services client install and configuration . 141 6.7.1 Integrated login (single sign-on) . 141 6.7.2 Standard login . 143 6.7.3 Adding NAS users. 144 6.7.4 Migrating existing users into NAS . 147 6.7.5 Installation details . 149 6.8 Installing GPFS . 150 6.8.1 Preparing the GPFS nodes for installation . 151 6.8.2 Creating the GPFS directory . 151 6.8.3 Creating the GPFS installation table of contents file. 152 6.8.4 Installing GPFS through the network . 152 6.8.5 Verifying the GPFS installation . 153 6.9 Configuring GPFS ..
Recommended publications
  • A Versatile Persistent Caching Framework for File Systems Gopalan Sivathanu and Erez Zadok Stony Brook University

    A Versatile Persistent Caching Framework for File Systems Gopalan Sivathanu and Erez Zadok Stony Brook University

    A Versatile Persistent Caching Framework for File Systems Gopalan Sivathanu and Erez Zadok Stony Brook University Technical Report FSL-05-05 Abstract IDE RAID array that has an Ext2 file system can cache the recently-accessed data into a smaller but faster SCSI We propose and evaluate an approach for decoupling disk to improve performance. The same could be done persistent-cache management from general file system for a local disk; it can be cached to a faster flash drive. design. Several distributed file systems maintain a per- The second problem with the persistent caching sistent cache of data to speed up accesses. Most of these mechanisms of present distributed file systems is that file systems retain complete control over various aspects they have a separate name space for the cache. Hav- of cache management, such as granularity of caching, ing the persistent cache directory structure as an exact and policies for cache placement and eviction. Hard- replica of the source file system is useful even when coding cache management into the file system often re- xCachefs is not mounted. For example, if the cache has sults in sub-optimal performance as the clients of the file the same structure as the source, disconnected reads are system are prevented from exploiting information about possible directly from the cache, as in Coda [2]. their workload in order to tune cache management. In this paper we present a decoupled caching mech- We introduce xCachefs, a framework that allows anism called xCachefs. With xCachefs, data can be clients to transparently augment the cache management cached from any file system to a faster file system.
  • Fragmentation in Large Object Repositories

    Fragmentation in Large Object Repositories

    Fragmentation in Large Object Repositories Experience Paper Russell Sears Catharine van Ingen University of California, Berkeley Microsoft Research [email protected] [email protected] ABSTRACT 1. INTRODUCTION Fragmentation leads to unpredictable and degraded application Application data objects continue to increase in size. performance. While these problems have been studied in detail Furthermore, the increasing popularity of web services and other for desktop filesystem workloads, this study examines newer network applications means that systems that once managed static systems such as scalable object stores and multimedia archives of “finished” objects now manage frequently modified repositories. Such systems use a get/put interface to store objects. versions of application data. Rather than updating these objects in In principle, databases and filesystems can support such place, typical archives either store multiple versions of the objects applications efficiently, allowing system designers to focus on (the V of WebDAV stands for “versioning” [25]), or simply do complexity, deployment cost and manageability. wholesale replacement (as in SharePoint Team Services [19]). Similarly, applications such as personal video recorders and Although theoretical work proves that certain storage policies media subscription servers continuously allocate and delete large, behave optimally for some workloads, these policies often behave transient objects. poorly in practice. Most storage benchmarks focus on short-term behavior or do not measure fragmentation. We compare SQL Applications store large objects as some combination of files in Server to NTFS and find that fragmentation dominates the filesystem and as BLOBs (binary large objects) in a database. performance when object sizes exceed 256KB-1MB. NTFS Only folklore is available regarding the tradeoffs.
  • ECE 598 – Advanced Operating Systems Lecture 19

    ECE 598 – Advanced Operating Systems Lecture 19

    ECE 598 { Advanced Operating Systems Lecture 19 Vince Weaver http://web.eece.maine.edu/~vweaver [email protected] 7 April 2016 Announcements • Homework #7 was due • Homework #8 will be posted 1 Why use FAT over ext2? • FAT simpler, easy to code • FAT supported on all major OSes • ext2 faster, more robust filename and permissions 2 btrfs • B-tree fs (similar to a binary tree, but with pages full of leaves) • overwrite filesystem (overwite on modify) vs CoW • Copy on write. When write to a file, old data not overwritten. Since old data not over-written, crash recovery better Eventually old data garbage collected • Data in extents 3 • Copy-on-write • Forest of trees: { sub-volumes { extent-allocation { checksum tree { chunk device { reloc • On-line defragmentation • On-line volume growth 4 • Built-in RAID • Transparent compression • Snapshots • Checksums on data and meta-data • De-duplication • Cloning { can make an exact snapshot of file, copy-on- write different than link, different inodles but same blocks 5 Embedded • Designed to be small, simple, read-only? • romfs { 32 byte header (magic, size, checksum,name) { Repeating files (pointer to next [0 if none]), info, size, checksum, file name, file data • cramfs 6 ZFS Advanced OS from Sun/Oracle. Similar in idea to btrfs indirect still, not extent based? 7 ReFS Resilient FS, Microsoft's answer to brtfs and zfs 8 Networked File Systems • Allow a centralized file server to export a filesystem to multiple clients. • Provide file level access, not just raw blocks (NBD) • Clustered filesystems also exist, where multiple servers work in conjunction.
  • Fortran Reference Guide

    Fortran Reference Guide

    FORTRAN REFERENCE GUIDE Version 2018 TABLE OF CONTENTS Preface............................................................................................................ xv Audience Description......................................................................................... xv Compatibility and Conformance to Standards............................................................ xv Organization................................................................................................... xvi Hardware and Software Constraints...................................................................... xvii Conventions................................................................................................... xvii Related Publications........................................................................................ xviii Chapter 1. Language Overview............................................................................... 1 1.1. Elements of a Fortran Program Unit.................................................................. 1 1.1.1. Fortran Statements................................................................................. 1 1.1.2. Free and Fixed Source............................................................................. 2 1.1.3. Statement Ordering................................................................................. 2 1.2. The Fortran Character Set.............................................................................. 3 1.3. Free Form Formatting..................................................................................
  • Ext4 File System and Crash Consistency

    Ext4 File System and Crash Consistency

    1 Ext4 file system and crash consistency Changwoo Min 2 Summary of last lectures • Tools: building, exploring, and debugging Linux kernel • Core kernel infrastructure • Process management & scheduling • Interrupt & interrupt handler • Kernel synchronization • Memory management • Virtual file system • Page cache and page fault 3 Today: ext4 file system and crash consistency • File system in Linux kernel • Design considerations of a file system • History of file system • On-disk structure of Ext4 • File operations • Crash consistency 4 File system in Linux kernel User space application (ex: cp) User-space Syscalls: open, read, write, etc. Kernel-space VFS: Virtual File System Filesystems ext4 FAT32 JFFS2 Block layer Hardware Embedded Hard disk USB drive flash 5 What is a file system fundamentally? int main(int argc, char *argv[]) { int fd; char buffer[4096]; struct stat_buf; DIR *dir; struct dirent *entry; /* 1. Path name -> inode mapping */ fd = open("/home/lkp/hello.c" , O_RDONLY); /* 2. File offset -> disk block address mapping */ pread(fd, buffer, sizeof(buffer), 0); /* 3. File meta data operation */ fstat(fd, &stat_buf); printf("file size = %d\n", stat_buf.st_size); /* 4. Directory operation */ dir = opendir("/home"); entry = readdir(dir); printf("dir = %s\n", entry->d_name); return 0; } 6 Why do we care EXT4 file system? • Most widely-deployed file system • Default file system of major Linux distributions • File system used in Google data center • Default file system of Android kernel • Follows the traditional file system design 7 History of file system design 8 UFS (Unix File System) • The original UNIX file system • Design by Dennis Ritche and Ken Thompson (1974) • The first Linux file system (ext) and Minix FS has a similar layout 9 UFS (Unix File System) • Performance problem of UFS (and the first Linux file system) • Especially, long seek time between an inode and data block 10 FFS (Fast File System) • The file system of BSD UNIX • Designed by Marshall Kirk McKusick, et al.
  • Introduction to Linux on System Z

    Introduction to Linux on System Z

    IBM Linux and Technology Center Introduction to Linux on System z Mario Held IBM Lab Boeblingen, Germany © 2009 IBM Corporation IBM Linux and Technology Center Trademarks The following are trademarks of the International Business Machines Corporation in the United States, other countries, or both. Not all common law marks used by IBM are listed on this page. Failure of a mark to appear does not mean that IBM does not use the mark nor does it mean that the product is not actively marketed or is not significant within its relevant market. Those trademarks followed by ® are registered trademarks of IBM in the United States; all others are trademarks or common law marks of IBM in the United States. For a complete list of IBM Trademarks, see www.ibm.com/legal/copytrade.shtml: *, AS/400®, e business(logo)®, DBE, ESCO, eServer, FICON, IBM®, IBM (logo)®, iSeries®, MVS, OS/390®, pSeries®, RS/6000®, S/30, VM/ESA®, VSE/ESA, WebSphere®, xSeries®, z/OS®, zSeries®, z/VM®, System i, System i5, System p, System p5, System x, System z, System z9®, BladeCenter® The following are trademarks or registered trademarks of other companies. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
  • AIX Migration to Cloud with IBM Power Virtual Server

    AIX Migration to Cloud with IBM Power Virtual Server

    AIX Migration to Cloud with IBM Power Virtual Server An IBM Systems Lab Services Tutorial Aaron Bolding Berjis Patel Vess Natchev [email protected] TABLE OF CONTENTS CHAPTER 1: SOLUTION OVERVIEW............................. 1 Introduction ................................................................................ 1 Use Cases .................................................................................. 1 Migration via PowerVC OVA ..................................................... 1 Transfer System Backup Using the Public Internet ..................... 2 Transfer System Backup Using Cloud Object Storage ................. 2 Solution Components and Requirements ........................................ 2 Components .......................................................................... 2 Migration via PowerVC OVA ..................................................... 2 Transfer System Backup Using the Public Internet ..................... 2 Transfer System Backup Using Cloud Object Storage ................. 2 Requirements ........................................................................ 3 Solution Diagrams ....................................................................... 3 Transfer System Backup Using the Public Internet ..................... 3 Transfer System Backup Using Cloud Object Storage ................. 4 CHAPTER 2: IMPLEMENTATION .................................. 5 Migration via PowerVC OVA .......................................................... 5 Procedure to Configure IBM Cloud Object Storage .....................
  • RACF Command Tips

    RACF Command Tips

    RACF Command Tips SHARE ‐ March 2015 Session 18875 RSH Consulting ‐ Robert S. Hansel RSH Consulting, Inc. is an IT security professional services firm established in 1992 and dedicated to helping clients strengthen their IBM z/OS mainframe access controls by fully exploiting all the capabilities and latest innovations in RACF. RSH's services include RACF security reviews and audits, initial implementation of new controls, enhancement and remediation of existing controls, and training. • www.rshconsulting.com • 617‐969‐9050 Robert S. Hansel is Lead RACF Specialist and founder of RSH Consulting, Inc. He began working with RACF in 1986 and has been a RACF administrator, manager, auditor, instructor, developer, and consultant. Mr. Hansel is especially skilled at redesigning and refining large‐scale implementations of RACF using role‐based access control concepts. He is a leading expert in securing z/OS Unix using RACF. Mr. Hansel has created elaborate automated tools to assist clients with RACF administration, database merging, identity management, and quality assurance. • 617‐969‐8211 • [email protected] • www.linkedin.com/in/roberthansel • http://twitter.com/RSH_RACF RACF Command Tips SHARE 2 © 2016 RSH Consulting, Inc. All Rights Reserved. March 2016 Topics . User Commands . Group Commands . Dataset Command . General Resource Commands . PERMIT Command . Generic Profile Refresh . List Commands . SEARCH Command . Console Command Entry . Building Commands with Microsoft Excel RACF and z/OS are Trademarks of the International Business Machines Corporation RACF Command Tips SHARE 3 © 2016 RSH Consulting, Inc. All Rights Reserved. March 2016 User Commands . ADDUSER Defaults: • OWNER ‐ Creator's ID • DFLTGRP ‐ Creator's Current Connect Group • PASSWORD ‐ Pre‐z/OS 2.2: Default Group z/OS 2.2: NOPASSWORD • Always specify when creating new ID .
  • Filesystem Considerations for Embedded Devices ELC2015 03/25/15

    Filesystem Considerations for Embedded Devices ELC2015 03/25/15

    Filesystem considerations for embedded devices ELC2015 03/25/15 Tristan Lelong Senior embedded software engineer Filesystem considerations ABSTRACT The goal of this presentation is to answer a question asked by several customers: which filesystem should you use within your embedded design’s eMMC/SDCard? These storage devices use a standard block interface, compatible with traditional filesystems, but constraints are not those of desktop PC environments. EXT2/3/4, BTRFS, F2FS are the first of many solutions which come to mind, but how do they all compare? Typical queries include performance, longevity, tools availability, support, and power loss robustness. This presentation will not dive into implementation details but will instead summarize provided answers with the help of various figures and meaningful test results. 2 TABLE OF CONTENTS 1. Introduction 2. Block devices 3. Available filesystems 4. Performances 5. Tools 6. Reliability 7. Conclusion Filesystem considerations ABOUT THE AUTHOR • Tristan Lelong • Embedded software engineer @ Adeneo Embedded • French, living in the Pacific northwest • Embedded software, free software, and Linux kernel enthusiast. 4 Introduction Filesystem considerations Introduction INTRODUCTION More and more embedded designs rely on smart memory chips rather than bare NAND or NOR. This presentation will start by describing: • Some context to help understand the differences between NAND and MMC • Some typical requirements found in embedded devices designs • Potential filesystems to use on MMC devices 6 Filesystem considerations Introduction INTRODUCTION Focus will then move to block filesystems. How they are supported, what feature do they advertise. To help understand how they compare, we will present some benchmarks and comparisons regarding: • Tools • Reliability • Performances 7 Block devices Filesystem considerations Block devices MMC, EMMC, SD CARD Vocabulary: • MMC: MultiMediaCard is a memory card unveiled in 1997 by SanDisk and Siemens based on NAND flash memory.
  • External Flash Filesystem for Sensor Nodes with Sparse Resources

    External Flash Filesystem for Sensor Nodes with Sparse Resources

    External Flash Filesystem for Sensor Nodes with sparse Resources Stephan Lehmann Stephan Rein Clemens Gühmann stephan.lehmann@tu- stephan.rein@tu- clemens.guehmann@tu- berlin.de berlin.de berlin.de Wavelet Application Group Department of Energy and Automation Technology Chair of Electronic Measurement and Diagnostic Technology Technische Universität Berlin ABSTRACT for using just a few kilobytes of RAM, the source data must This paper describes a free filesystem for external flash mem- be accessible. Another memory intensive task concerns long- ory to be employed with low-complexity sensor nodes. The term sensor logs. system uses a standard secure digital (SD) card that can be easily connected to the serial port interface (SPI) or any A cost effective solution of this memory problem could be general input/output port of the sensor’s processor. The external flash memory. Flash memory is non-volatile and filesystem is evaluated with SD- cards used in SPI mode and therefore power failure safe. Flash memory can be obtained achieves an average random write throughput of about 40 either as raw flash or as standard flash devices such as USB- kByte/sec. For random write access throughputs larger than sticks or SD- cards. Raw flashes are pure flash chips which 400 kByte/sec are achieved. The filesystem allows for stor- do not provide a controller unit for wear levelling- that is, age of large amounts of sensor or program data and can assist a technique for prolonging the service life of the erasable more memory expensive algorithms. It requires 7 kByte of storage media - or garbage collection.
  • Total Defrag™ 2009

    Total Defrag™ 2009

    Total Defrag™ 2009 User Manual Paragon Total Defrag™ 2009 2 User Manual CONTENTS Introduction ............................................................................................................................. 3 Key Features ............................................................................................................................ 3 Installation ............................................................................................................................... 3 Minimum System Requirements ....................................................................................................................3 Installation Procedure .....................................................................................................................................4 Basic Concepts ......................................................................................................................... 5 A Hard Disk Layout.........................................................................................................................................5 File Fragmentation...........................................................................................................................................6 Defragmentation ..............................................................................................................................................7 Interface Overview.................................................................................................................. 7 General
  • System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 15 SP1

    System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 15 SP1

    SUSE Linux Enterprise Server 15 SP1 System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 15 SP1 An administrator's guide for problem detection, resolution and optimization. Find how to inspect and optimize your system by means of monitoring tools and how to eciently manage resources. Also contains an overview of common problems and solutions and of additional help and documentation resources. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xii 1 Available Documentation xiii