RH436 pdf

1
II
a
II
1
1
1
1
1
e
1
e
1
1
1
e
• RH436
I/ Red Hat Enterprise Clustering and Storage
Management
10
RH436-RHEL5u4-en-17-20110428
1
1

11 Table of Contents
e RH436 - Red Hat Enterprise
III
Clustering and Storage Management
e RH436: Red Hat Enterprise Clustering and Storage Management
Copyright ix
110 Welcome x
Red Hat Enterprise Linux xi
o Red Hat Enterprise Linux Variants xii
Red Hat Subscription Model xiii
Contacting Technical Support xiv
e Red Hat Network xv
Red Hat Services and Products xvi
e
Fedora and EPEL xvii
Classroom Setup xviii
Networks xix
Notes on Intemationalization xx
II Lecture 1 - Storage Technologies
Ilb
Objectives
The Data 2
Data Storage Considerations 3
IP Data Availability 4
Planning for the Future 5
11/
The RHEL Storage Model 6
Volume Management 7
SAN versus NAS 8
11> SAN Technologies 9
Fibre Channel 10
I Host Bus Adapter (HBA) 11
Fibre Channel Switch 12
Internet SCSI (iSCSI) 13
10 End of Lecture 1 14
Lab 1: Data Management and Storage
I Lab 1.1: Evaluating Your Storage Requirements 15
Lab 1.2: Configuring the Virtual Cluster Environment 17
• Lecture 2 - iSCSI Configuration
110 Objectives
Red Hat iSCSI Driver 20
II>
iSCSI Data Access
iSCSI Driver Features
21
22
iSCSI Device Names and Mounting 23
10
iSCSI Target Naming 24
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / rh436-main

e
e
e
e
•
•
•
••
•
Objectives
udev Features 42
Event Chain of a Newly Plugged-in Device 43 •
/sys Filesystem 44
udev 45
•Configuring udev 46
udev Rules 47
udev Rule Match Keys 48 •
Finding udev Match Key Values 49
udev Rule Assignment Keys 50
•udev Rule Substitutions 51
udev Rule Examples 52
udevmonitor 53
Dynamic storage management 54
Tuning the disk queue 55
•Tuning the deadline scheduler 56
Tuning the anticipatory scheduler 57
Tuning the noop scheduler 58 111
Tuning the (default) cfq scheduler 59
Fine-tuning the cfq scheduler 60
•End of Lecture 3 61
Lab 3: udev and device tuning
Lab 3.1: Persistent Device Naming 62 •
Lecture 4 - Device Mapper and Multipathing
Objectives
Device Mapper 65
Device Mapping Table 66
dmsetup 67
Mapping Targets 68
Mapping Target - linear 69
Mapping Target - striped 70
Mapping Target - error 72
Mapping Target - snapshot-origin 73
Configuring iSCSI Targets 25
Manual iSCSI configuration 26
Configuring the iSCSI Initiator Driver 27
iSCSI Authentication Settings 28
Configuring the open-iscsi Initiator 29
First-time Connection to an iSCSI Target 30
Managing an iSCSI Target Connection 31
Disabling an iSCSI Target 32
End of Lecture 2 33
Lab 2: iSCSI Configuration
Lab 2.1: iSCSI Software Target Configuration 34
Lab 2.2: iSCSI Initiator Configuration 35
Lecture 3 - Kernel Device Management

111/ Mapping Target - snapshot 74
LVM2 Snapshots 75
e LVM2 Snapshot Example 76
Mapping Target - zero 78
e
Device Mapper Multipath Overview 80
Device Mapper Components 81
Multipath Priority Groups 82
II Mapping Target - mult ipath 83
Setup Steps for Multipathing FC Storage 84
Multipathing and iSCSI 85
Multipath Configuration 86
Multipath Information Queries 88
III End of Lecture 4 90
Lab 4: Device Mapper Multipathing
11)
Lab 4.1: Device Mapper Multipathing 91
II>
Lecture 5 - Red Hat Cluster Suite Overview
Objectives
11,
What is a Cluster? 103
Red Hat Cluster Suite 104
111>
Cluster Topology 105
Clustering Advantages 106
Advanced Configuration and Power Interface (ACPI) 107
e Cluster Network Requirements 108
Broadcast versus Multicast 109
Ethernet Channel Bonding 110
I, Channel Bonding Configuration 111
Red Hat Cluster Suite Components 112
110
Security 113
Cluster Configuration System (CCS) 114
11,
CMAN - Cluster Manager 115
Cluster Quorum 116
OpenAIS 117
I,
rgmanager - Resource Group Manager 118
The Conga Project 119
IP
luci
ricci
120
121
Deploying Conga 122
11, lucí Deployment Interface 123
Clustered Logical Volume Manager (CLVM) 124
Distributed Lock Manager (DLM) 125
II/ Fencing 126
End of Lecture 5 127
10 Lab 5: Cluster Deployment using Conga
Lab 5.1: Building a Cluster with Conga 128
II> Lecture 6 - Logical Volume Management
Objectives

•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
An LVM2 Review 138
LVM2 - Physical Volumes and Volume Groups 139
LVM2 - Creating a Logical Volume 140
Files and Directories Used by LVM2 141
Changing LVM options 142
Moving a volume group to another host 143
Clustered Logical Volume Manager (CLVM) 144
CLVM Configuration 145
Lab 6: Clustered Logical Volume Manager
Lab 6.1: Configure the Clustered Logical Volume Manager 147
Lecture 7 - Global File System 2
Objectives
Global File System 2 150
GFS2 Limits 151
GFS2 Enhancements 152
Creating a GFS2 File System 153
Lock Managers 154
Distributed Lock Manager (DLM) 155
Mounting a GFS2 File System 156
Journaling 157
Quotas 158
Growing a GFS2 File System 159
GFS2 Super Block Changes 160
GFS2 Extended Attributes (ACL) 161
Repairing a GFS2 File System 162
Lab 7: Global File System 2
Lab 7.1: Creating a GFS2 file system with Conga 164
Lab 7.2: Create a GFS2 filesystem on the commandline 165
Lab 7.3: GFS1: Conversion 168
Lab 7.4: GFS2: Working with images 169
Lab 7.5: GFS2: Growing the filesystem 170
Lecture 8 - Quorum and the Cluster Manager
Objectives
Cluster Quorum
Cluster Quorum Example
Modifying and Displaying Quorum Votes
CMAN - two node cluster
CCS Tools - ccs_tool
cluster. conf Schema
Updating an Existing RHEL4 cluster. conf for RHEL5
cman_tool
cman_tool Examples
CMAN - API
CMAN - libcman
r,,rmrinht"9n11 ph.d 1-Int Int,
182 e183
184
111186
187
188 •
189
190
4B191
192
193
id-cm-17-9M 1 flA9R / rhtilA-main

II, End of Lecture 8 194
Lab 8: Adding Cluster Nodes and Manually Editing cluster .conf
Lab 8.1: Extending Cluster Nodes 195
Lab 8.2: Manually Editing the Cluster Configuration 197
110 Lab 8.3: GFS2: Adding Journals 198
e
Lecture 9 - Fencing and Failover
Objectives
11/ No-fencing Scenario 207
Fencing Components 208
1
Fencing Agents 209
Power Fencing versus Fabric Fencing 210
SCSI Fencing 211
Fencing From the Command Line 212
The Fence Daemon - fenced 213
IP
Manual Fencing 214
Fencing Methods 215
Fencing Example - Dual Power Supply 216
11/ Handling Software Failures 217
Handling Hardware Failures 218
11,
Failover Domains and Service Restrictions 219
Failover Domains and Prioritization 220
NFS Failover Considerations 221
111/ clusvcadm 222
e
Lab 9: Fencing and Failover
Lab 9.1: Node Priorities and Service Relocation 224
11, Lecture 10 - Quorum Disk
11 Objectives
Quorum Disk 229
e
Quorum Disk Communications 230
Quorum Disk Heartbeating and Status 231
Quorum Disk Heuristics 232
11/
Quorum Disk Configuration 233
Working with Quorum Disks 234
•
Example: Two Cluster Nodes and a Quorum Disk Tiebreaker 235
Example: Keeping Quorum When All Nodes but One Have Failed 236
10 Lab 10: Quorum Disk
Lab 10.1: Quorum Disk 238
11>
Lecture 11 - rgmanager
• Objectives
Resource Group Manager 244
10 Cluster Configuration - Resources 245

•
e
e
•
Resource Groups 247
•Start/Stop Ordering of Resources 248
Resource Hierarchical Ordering 249 111
NFS Resource Group Example 250
Resource Recovery 251
Service Status Checking 252
Custom Service Scripts 253
Displaying Cluster and Service Status 254 II
Cluster Status (luc i) 255
•
Cluster Status Utility (clustat) 256
Cluster Service States 257
Cluster SNMP Agent 258
Starting/Stopping the Cluster Software on a Member Node 260 •
Cluster Shutdown Tips 261
•
Troubleshooting 262
Logging 263
Lab 11: Cluster Manager •
Lab 11.1: Adding an NFS Service to the Cluster 265
•
Lab 11.2: Configuring SNMP for Red Hat Cluster Suite 266
Lecture 12 - Comprehensive Review
•Objectives
Start from scratch 274 •
Lab 12: Comprehensive Review
Lab 12.1: Rebuild your environment 276 •
Lab 12.2: Setup iscsi and multipath 277
Lab 12.3: Build a three node cluster 278 •
Lab 12.4: Add a quorum-disk 279
Lab 12.5: Add a GFS2 filesystem 280
Lab 12.6: Add a NFS-service to your cluster 281 1111
Appendix A - Advanced RAID •
Objectives
Redundant Array of Inexpensive Disks 291
RAIDO 292
RAID1 293
RAID5 294
RAID5 Parity and Data Distribution 295
RAID5 Layout Algorithms 296
RAID5 Data Updates Overhead 297
RAID6 298
RAID6 Parity and Data Distribution 299
RAID10 300
Stripe Parameters 301
/proc/mdstat 302
Verbose RAID Information 303

11> SYSFS Interface 304
/etc/mdadm.conf 305
Event Notification 306
Restriping/Reshaping RAID Devices 307
e
Growing the Number of Disks in a RAID5 Array 308
Improving the Process with a Critica) Section Backup 309
Growing the Size of Disks in a RAID5 Array 310
Sharing a Hot Spare Device in RAID 311
Renaming a RAID Array 312
1110
Write-intent Bitmap 313
Enabling Write-Intent on a RAID1 Array 314
Write-behind on RAID1 315
RAID Error Handling and Data Consistency Checking 316
Appendix A: Lab: Advanced RAID
I Lab A.1: Improve RAID1 Recovery Times with Write-intent Bitmaps 317
Lab A.2: Improve Data Reliability Using RAID 6 318
Lab A.3: Improving RAID reliability with a Shared Hot Spare Device 320
11> Lab A.4: Online Data Migration 321
Lab A.5: Growing a RAID5 Array While Online 322
11/
Lab A.6: Clean Up 323
Lab A.7: Rebuild Virtual Cluster Nodes 324
111>
1
1
1
I/
O
1
1
1
1
1
1
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / rfi436-main

Introduction
RH436: Red Hat Enterprise
Clustering and Storage Management
For use only by e student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publicetion may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training meteriels are being improperly usad,
copied, or distributed pleese email <training®redhat . com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 0ca8c908

Copyright 1
• The contents of this course and all its modules and related materials, including handouts to audience members,
are Copyright O 2011 Red Hat, Inc.
• No part of this publication may be stored in a retrieval system, transmitted or reproduced in any way, including,
but not limited to, photocopy, photograph, magnetic, electronic or other record, without the prior written
permission of Red Hat, Inc.
• This instructional program, including all material provided herein, is supplied without any guarantees from
Red Hat, Inc. Red Hat, Inc. assumes no liability for damages or legal action arising from the use or misuse of
contents or details contained herein.
• If you believe Red Hat training materials are being used, copied, or otherwise improperly distributed please
email training@redhat.com or phone toll-free (USA) +1 866 626 2994 or +1 919 754 3700.
For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red HM Certified Training Partner. No part of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior mitren consent of Red HM, Inc. ff you believe Red HM training materiats are being improperly used,
copied, or distributed pisase email <trainingeredhat. coa, or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright @ 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 216f53f8

Welcome 2
Please let us know if you need any special assistance while visiting our training facility.
Please introduce yourself to the rest of the class!
Welcome to Red Hat Training!
Welcome to this Red Hat training class! Please make yourself comfortable while you are here. If you have
any questions about this class or the facility, or need special assistance while you are here, please feel free
to ask the instructor or staff at the facility for assistance. Thank you for attending this course.
Telephone and network availability
Please only make telephone calls during breaks. Your instructor will direct you to the telephone to use.
Network access and analog phone lines may be available; if so, your instructor will provide information
about these facilities. Please turn pagers and cell phones to off or to silent or vibrate during class.
Restrooms
Your instructor will notify you of the location of restroom facilities and provide any access codes or keys
which are required to use them.
Lunch and breaks
Your instructor will notify you of the areas to which you have access for lunch and for breaks.
In Case of Emergency
Please let us know if anything comes up that will prevent you from attending or completing the class this
week.
Access
Each training facility has its own opening and closing times. Your instructor will provide you with this
information.
For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied,
duplicated, atorad in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used,
copiad, or distributed picase email <trainíngeredhat .coms or phone toll-free (USA) +1 (866) 626 2994 or +1 (919)754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / a8aa45c4

Red Hat Enterprise Linux 3
• Enterprise-targeted Linux operating system
• Focused on mature open source technology
• Extended release cycle between major versions
• With periodic minor releases during the cycle
• Certified with leading OEM and ISV products
• All variants based on the same code
• Certify once, run any application/anywhere/anytime
• Services provided on subscription basis
The Red Hat Enterprise Linux product family is designed specifically for organizations planning to use Linux
in production settings. All products in the Red Hat Enterprise Linux family are built on the same software
foundation, and maintain the highest level of ABI/API compatibility across releases and errata. Extensive
support services are available: a one year support contract and Update Module entitlement to Red Hat
Network are included with purchase. Various Service Level Agreements are available that may provide up
to 24x7 coverage with a guaranteed one hour response time for Severity 1 issues. Support will be available
for up to seven years after a particular major release.
Red Hat Enterprise Linux is released on a multi-year cycle between major releases. Minor updates to major
releases are released roughly every six months during the lifecycle of the product. Systems certified on
one minor update of a major release continue to be certified for future minor updates of the major release.
A core set of shared libraries have APIs and ABIs which will be preserved between major releases. Many
other shared libraries are provided, which have APIs and ABIs which are guaranteed within a major release
(for all minor updates) but which are not guaranteed to be stable across major releases.
Red Hat Enterprise Linux is based on code developed by the open source community and adds
performance enhancements, intensive testing, and certification on products produced by top independent
software and hardware vendors such as Dell, IBM, Fujitsu, BEA, and Oracle. Red Hat Enterprise Linux
provides a high degree of standardization through its support for five processor architectures (Intel x86-
compatible, AMD64/Intel 64, Intel Itanium 2, IBM POWER, and IBM mainframe on System z). Furthermore,
we support the 3000+ ISV certifications on Red Hat Enterprise Linux whether the RHEL operating system
those applications are using is running on "bare metal", in a virtual machine, as a software appliance, or in
the cloud using technologies such as Amazon EC2.
For use only by a student enrolled in a Red HM training course taught by Red HM, Inc. or a Red HM Certified Training Partner. No part of this publicaban may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. ff you believe Red Hat training materials are being improperly used,
copied, or distributed please amad ctraiaiageredhat . coa> or phone toil-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
RH436-RHEL5u4-en-17-20110428 / 9b4b75aeCopyright © 2011 Red Hat, Inc.
... . .. ,

Red Hat Enterprise Linux Variants 4
• Red Hat Enterprise Linux Advanced Platform
• Unlimited server size and virtualization support
• HA clusters and cluster file system
• Red Hat Enterprise Linux
Basic server solution for smaller non-mission-critical servers
• Virtualization support included
• Red Hat Enterprise Linux Desktop
• Productivity desktop environment
• Workstation option adds tools for software and network service development
• Multi-OS option for virtualization
Currently, on the x86 and x86-64 architectures, the product family includes:
Red Hat Enterprise Linux Advanced Platform: the most cost-effective server solution, this product includes
support for the largest x86-compatible servers, unlimited virtualized guest operating systems, storage
virtualization, high-availability application and guest fail-over clusters, and the highest levels of technical
support.
Red Hat Enterprise Linux: the basic server solution, supporting servers with up to two CPU sockets and up
to four virtualized guest operating systems.
Red Hat Enterprise Linux Desktop: a general-purpose client solution, offering desktop applications such
as the OpenOffice.org office suite and Evolution mail client. Add-on options provide support for high-end
technical and development workstations and for running multiple operating systems simultaneously through
virtualization.
Two standard installation media kits are used to distribute variants of the operating system. Red Hat
Enterprise Linux Advanced Platform and Red Hat Enterprise Linux are shipped on the Server media kit.
Red Hat Enterprise Linux Desktop and its add-on options are shipped on the Client media kit. Media kits
may be downloaded as ISO 9660 CD-ROM file system images from Red Hat Network or may be provided
in a boxed set on DVD-ROMs.
Please visit http : / /www . redhat . com/rhel/ for more information about the Red Hat Enterprise Linux
product family. Other related products include realtime kernel support in Red Hat Enterprise MRG, the thin
hypervisor node in Red Hat Enterprise Virtualization, and so on.
For use only by a student enrollad in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. 11 you believe Red Hat training material. are being Improperly usad,
copiad, or distributed please email <training@redhat . coz> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919)754 3700.
Copyright 02011 Red Hat, Inc. RH436-RHEL5u4-en-17-201 10428 / 47a77a3d
.•

Red Hat Subscription Model 5
• Red Hat sells subscriptions that entitie systems to receive a set of services that
support open source software
• Red Hat Enterprise Linux and other Red Hat/JBoss solutions and applications
• Customers are charged an annual subscription fee per system
• Subscriptions can be migrated as hardware is replaced
• Can freely move between major revisions, up and down
• Multi-year subscriptions are available
• A typical service subscription includes:
• Software updates and upgrades through Red Hat Network
• Technical support (web and phone)
• Certifications, stable APIs/versions, and more
Red Hat doesn't exactly sell software. What we seli is service through support subscriptions.
Customers are charged an annual subscription fee per system. This subscription includes the ability to
manage systems and download software and software updates through our Red Hat Network service; to
obtain technical support (through the World-Wide Web or by telephone, with terms that vary depending on
the exact subscription purchased), and extended software warranties and IP indemnification to protect the
customer from service interruption due to software bugs or legal issues.
In turn, the subscription-based model gives customers more flexibility. Subscriptions are tied to a service
levet, not to a release version of a product; therefore, upgrades (and downgrades!) of software between
major releases can be done on a customers own schedule. Management of versions to match the
requirements of third-party software vendors is simplified as well. Likewise, as hardware is replaced, the
service entitlement which formerly belonged to a server being decommissioned may be freely moved to a
replacement machine without requiring any assistance from Red Hat. Multi-year subscriptions are available
as well to help customers better tie software replacement cycles to hardware refresh cycles.
Subscriptions are not just about access to software updates. They provide unlimited technical support;
hardware and software certifications on tested configurations; guaranteed long-term stability of a major
release's software versions and APIs; the flexibility to move entitlements between versions, machines, and
in some cases processor architectures; and access to various options through Red Hat Network and add-
on products for enhanced management capabilities.
This aliows customers to reduce deployment risks. Red Hat can deliver new technology as it becomes
available in major releases. But you can choose when and how to move to those releases, wíthout needing
to relicense to gain access to a newer version of the software. The subscription model helps reduce
your financial risk by providing a road map of predictable IT costs (rather than suddenly having to buy
licenses just because a new version has arrived). Finally, it allows us to reduce your technological risk
by providing a stable environment tested with software and hardware important to the enterprise. Visit
http: //www. redhat .com/rhel/benefits/ for more information about the subscription model.
For use only by a student enrolled in a Red Hat training course taught by Red HM, Inc. or a Red HM Certified Training Partner. No parí of this publication may be photocopied,
duplicated, stored in a retrieval system, or othenvise reproduced without prior written consent of Red HM, Inc. It you believe Red HM training materials are being improperly usad,
copiad, or cfistributed picase email <trainingeredhat . coa> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
RH436-RHEL5u4-en-17-20110428 / f98c808cCopyright © 2011 Red Hat, Inc.
. . .

Contacting Technical Support 6
• Collect information needed by technical support:
• Define the problem
• Gather background information
• Gather relevant diagnostic information, if possible
• Determine the severity level
• Contacting technical support by WWW:
• http://www.redhat.com/support/
• Contacting technical support by phone:
• Seehttp://www.redhat.com/support/policy/sla/contact/
• US/Canada: 888-GO-REDHAT (888-467-3342)
Information on the most important steps to take to ensure your support issue is resolved by Red Hat as
quickly and efficiently as possible is available at http : //www.redhat .com/support/process/
production/. This is a brief summary of that information for your convenience. You may be able to
resolve your problem without formal technical support by looking for your problem in Knowledgebase
(http://kbase.redhat.com/).
Define the problem. Make certain that you can articulate the problem and its symptoms before you contact
Red Hat. Be as specific as possible, and detail the steps you can use (if any) to reproduce the problem.
Gather background information. What version of our software are you running? Are you using the latest
update? What steps led to the failure? Can the problem be recreated and what steps are required? Have
any recent changes been made that could have triggered the issue? Were messages or other diagnostic
messages issued? What exactly were they (exact wording may be critical)?
Gather relevant diagnostic information. Be ready to provide as much relevant information as possible; logs,
core dumps, traces, the output of sosreport, etc. Technical Support can assist you in determining what is
relevant.
Determine the Severity Level of your issue. Red Hat uses a four-level scale to indicate the criticality of
issues; criteria may be found at http: //www.redhat .com/support/policy/GSS_severity.html.
Red Hat Support may be contacted through a web form or by phone depending on your support level.
Phone numbers and business hours for different regions vary; see http://www.redhat .com/support/
policy/sla/contact/ for exact details. When contacting us about an issue, please have the following
information ready:
Red Hat Customer Number
Machine type/model
Company name
Contact name
Preferred means of contact (phone/e-mail) and telephone number/e-mail address at which you can be reached
Related product/version information
Detailed description of the issue
Severity Level of the issue in respect to your business needs
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materiele are being Improperly ueed,
copiad, or distributed picase email <training0redhat .com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright ©2011 . Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / c12d09d3

Red Hat Network 7
• A systems management platform providing lifecycle management of the operating
system and applications
• Installing and provisioning new systems
• Updating systems
• Managing configuration files
• Monitoring performance
• Redeploying systems for a new purpose
• "Hosted" and "Satellite" deployment architectures
Red Hat Network's modular service model allows you to pick and choose the features you need to manage
your enterprise.
The basic Update service is provided as part of all Red Hat Enterprise Linux subscriptions. Through it,
you can use Red Hat Network to easily download and install security patches and updates from an RHN
server. All content is digitally signed by Red Hat for added security, so that you can ensure that packages
actually carne from us. The yum (or older up2date) utility automatically resolves dependencies to ensure
the integrity of your system when you use it to initiate an update from the managed station itself. You can
also log into a web interface on the RHN server to remotely add software or updates or remove undesired
software packages, or set up automatic updates to allow systems to get all fixes immediately.
The add-on Management module allows you to organize systems into management groups and perform
update or other management operations on all members of the group. You can also set up subaccounts ín
Red Hat Network which have access to machines in some of your groups but not others. Powerful search
capabilities allow you to identify systems based on their packages or hardware characteristics, and you can
also compare package profiles of two systems.
The Provisioning module makes it easier for your to deploy new systems or redeploy existing systems
using predetermined profiles or through system cloning. You can use RHN to store, manage, and deploy
configuration files as well as software package files. You can use tools to help write automated installation
Kickstart configurations and apply them to selected systems. You can undo problematic changes through
a roll-back feature. Management and Provisioning modules are included as part of a Red Hat Enterprise
Linux Desktop subscription at no additional fee.
Monitoring module is only available with RHN Satellite, and allows you to set up to dozens of low-impact
probes for each system and many applications (including Oracle, MySQL, BEA, and Apache) to track
availability and performance.
RHN is initially deployed in a "hosted" model, where the central update server is located at a Red Hat
facility and is contacted over the Internet using HTTP/SSL. To reduce bandwidth, you can site a RHN Proxy
Server at your facility which caches packages requested by your systems. For maximum flexibility, you may
use RHN Satellite, which places the RHN server at your site under your control; this can run disconnected
from the Internet, or may be connected to the Internet to download update content from the official hosted
RHN servers to populate its service channels.
For use only by a student enrolled in a Red HM training course taught by Red HM, Inc. or a Red HM Certified Training Partner. No part of this publicaban may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red HM, Inc. tf you believe Red HM training materials are being improperly usad,
copiad, or distributed Meses email <trainiageredhat . coa> or phone toil-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 93398b3e
--•

Red Hat Services and Products 8
• Red Hat supports software products and services beyond Red Hat Enterprise Linux
• JBoss Enterprise Middleware
• Systems and Identity Management
• Infrastructure products and distributed computing
• Training, consulting, and extended support
• http://www.redhat.com/products/
Red Hat offers a number of additional open source application products and operating system
enhancements which may be added to the standard Red Hat Enterprise Linux operating system. As with
Red Hat Enterprise Linux, Red Hat provides a range of maintenance and support services for these add-
on products. Installation media and software updates are provided through the same Red Hat Network
interface used to manage Red Hat Enterprise Linux systems.
For additional information, see the following web pages:
• General product information: http: //www.redhat .com/products/
• Red Hat Solutions Guide: http: //www.redhat .com/solutions/guide/
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used,
copied, or distributed please amad <trainingeredhat . con» or phone to1I-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright O 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 64968772

Fedora and EPEL 9
• Open source projects sponsored by Red Hat
• Fedora distribution is focused on latest open source technology
• Rapid six month release cycle
• Available as free download from the Internet
• EPEL provides add-on software for Red Hat Enterprise Linux
• Open, community-supported proving grounds for technologies which may be used
in upcoming enterprise products
• Red Hat does not provide formal support
Fedora is a rapidly evolving, technology-driven Linux distribution with an open, highly scalable development
and distribution model. It is sponsored by Red Hat but created by the Fedora Project, a partnership of free
software community members from around the globe. It is designed to be a fully-operational, innovative
operating system which also is an incubator and test bed for new technologies that may be used in later
Red Hat enterprise products. The Fedora distribution is available for free download from the Internet.
The Fedora Project produces releases of Fedora on a short, roughly six month release cycle, to bring the
latest innovations of open source technology to the community. This may make it attractive for power users
and developers who want access to cutting-edge technology and can handle the risks of adopting rapidly
changing new technology. Red Hat does not provide formal support for Fedora.
The Fedora Project also supports EPEL, Extra Packages for Enterprise Linux. EPEL is a volunteer-based
community effort to create a repository of high-quality add-on packages which can be used with Red
Hat Enterprise Linux and compatible derivatives. It accepts legally-unencumbered free and open source
software which does not conflict with packages in Red Hat Enterprise Linux or Red Hat add-on products.
EPEL packages are built for a particular major release of Red Hat Enterprise Linux and will be updated by
EPEL for the standard support lifetime of that major release.
Red Hat does not provide commercial support or service level agreements for EPEL packages. While
not supported officially by Red Hat, EPEL provides a useful way to reduce support costs for unsupported
packages which your enterprise wishes to use with Red Hat Enterprise Linux. EPEL allows you to distribute
support work you would need to do by yourself across other organizations which share your desire to
use this open source software in RHEL. The software packages themselves go through the same review
process as Fedora packages, meaning that experienced Linux developers have examined the packages for
issues. As EPEL does not replace or conflict with software packages shipped in RHEL, you can use EPEL
with confidence that it will not cause problems with your normal software packages.
For developers who wish to see their open source software become part of Red Hat Enterprise Linux, often
a first stage is to sponsor it in EPEL so that RHEL users have the opportunity to use it, and so experience is
gained with managing the package for a Red Hat distribution.
Visit http: / / fedoraproj ect .org/ for more information about the Fedora Project.
Visit http: //fedoraproject.org/wiki/EPEL/ for more information about EPEL.
For use only by a student enroIled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperty used,
copied, or chstributed piense email <trainiagerecthat • coa> or phone toII-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
RH436-RHEL5u4-en-17-20110428 / 8744dbe2Copyright 2011 Red Hat, Inc.
. . .

Classroom Setup lo
• Instructor machine: instructor . example . com, 192.168.0.254
• provides DNS, DHCP, Internet routing
• Class material: /var/f tp/pub/
• Student machines: stationX. example . com , 192.168.0.X
• Provide virtual machines, iSCSI storage
• Uses multiple internal bridges for cluster traffic
• Virtual machines: node0, node 1, node2, node3
• nade() is kickstarted as a template
• nodel- 3 are snapshots of node O
The instructor system provides a number of services to the classroom network, including:
• A DHCP server
• A web server. The web server distributes RPMs at http: //instructor. example . com/pub.
• An FTP server. The FTP server distributes RPMs at f tp : / / instructor . example . com/pub.
• An NFS server. The NFS server distributes RPMs at nfs : //instructor . example . com/var/ftp/
pub.
• An NTP (network time protocol) server, which can be used to assist in keeping the clocks of classroom
computers synchronized.
In addition to a local classroom machine virtual machines will be used by each students The physical host
has a script (rebuild-cluster) that is used to create the template virtual machine. The same script is
used to create the cluster machines, which are really logical volume snapshots of the Xen virtual machine.
For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publicetion may be photocopied,
duplicated, stored in a retrievel system, or otherwise reproduced without prior written consent of Red Hat, Inc. II you believe Red Hat training material. are being improperly usad,
copiad, or distributed please email < t rainingOredhat .com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919)754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 0419b024

Networks 11
• 192.168.0.0/24
• classroom network
• instructor.example.com eth0 192.168.0.254
• stationX.example.com eth0 192.168.0.X
• 172.16.0.0/16
• public application network
• bridged to classroom net
• Instructor: instructor.example.com eth0:1 172.16.255.254
• Workstatíon: cXn5.example.com eth0:0 172.16.50.X5
• Virtual Nodes: cXnN example.com eth0 172.16.50. XN
• 172.17.X.0/24
• prívate cluster network
• intemal bridge on workstations
• Workstation: dom0.clusterX.example.com cluster 172.17.X.254
• Virtual Nodes: nodeN.clusterX.example.com ethl 172.17. X.N
• 172.17.100+X.0/24
• first iscsi network
• Workstation: storagel.clusterX.example.com storagel 172.17.100+X.254
• Virtual Nodes: nodeN-storagel.clusterX.example.com eth2 172.17. 100+X.N
• 172.17.200+X.0/24
• second iscsi network
• Workstation: storage2.clusterX.example.com storage2 172.17. 200+X. 254
• Virtual Nodes: nodeN-storage2.clusterX.example.com eth3 172.17. 200+X. N
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red HM, Inc. tt you believe Red Hat training meteríais are being improperly usad,
copiad, or clkstributed pisase email <trainingersdhat COZ> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
RH436-RHEL5u4-en-17-20110428 / 0e761625Copyright @ 2011 Red Hat, Inc.
. .

Notes on Internationalization 12
• Red Hat Enterprise Linux supports nineteen languages
• Default system-wide language can be selected
• During installation
• With system- config- Ianguage (System->Administration->Language)
• Users can set personal language preferences
• From graphical login screen (stored in -1. dmrc)
• For interactive shell (with LANG environment variable in -/ bashrc)
• Alternate languages can be used on a per - command basis:
[user@host LANG=j UTF - 8 date
Red Hat Enterprise Linux 5 supports nineteen languages: English, Bengali, Chinese (Simplified), Chinese
(Traditional), French, German, Gujarati, Hindi, Italian, Japanese, Korean, Malayalam, Marathi, Oriya,
Portuguese (Brazilian), Punjabi, Russian, Spanish and Tamil. Support for Assamese, Kannada, Sinhalese
and Telugu are provided as technology previews.
The operating system's default language is normally set to US English (en_US.UTF-8), but this can be
changed during or after installation. To use other languages, you may need to install extra packages to
provide the appropriate fonts, translations and so forth. These can be selected during system installation or
with system-config-packages (Applications->Add/Remove Software).
A system's default language can be changed with system-config-language ( System->Administration-
>Language), which affects the /etc/sysconfig/il 8n file.
Users may prefer to use a different language for their own desktop environment or interactive shells than is
set as the system default. This is indicated to the system through the LANG environment variable.
This may be set automatically for the GNOME desktop environment by selecting a language from the
graphical login screen by clicking on the Language item at the bottom left comer of the graphical login
screen immediately prior to login. The user will be prompted about whether the language selected should
be used just for this one login session or as a default for the user from now on. The setting is saved in the
user's -/ . dmrc file by GDM.
If a user wants to make their shell environment use the same LANG setting as their graphical environment
even when they login through a text console or over ssh, they can set code similar to the following in their
-/ .bashrc file. This will set their preferred language if one is saved in -/ . dmrc and use the system
default if not:
i=$(grep 'Language=' ${HOME}/.dmrc I sed 's/Language=//')
if [ "$i" I= "" ]; then
export LANG=$i
fi.
Languages with non-ASCII characters may have problems displaying in some environments. Kanji
characters, for example, may not display as expected on a virtual console. Individual commands can be
made to use another language by setting LANG on the command-line:
[userhost. -i$ LANG=frFR.UTF-8 date
For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No pare of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hal training materials are being improperly used,
copied, or distributed please email <training@redhat cm, or phone MII-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 8a224f80

mer. aoút 19 17:29:12 CDT 2009
Subsequent commands will reved to using the system's default language for output. The locale command
can be used to check the current value of LANG and other related environment variables.
SCIM (Smart Common Input Method) can be used to input text in various languages under X if the
appropriate language support packages are installed. Type Ctrl-Space to switch input methods.
duplicated, atorad in a retrievaI system, or otherwise reproduced without prior written consent of Red Hat, Inc. ff you believe Red Hat trainíng materias are being improperly used,
copiad, or cfistributed pisase email <traiairrgdzedhat . coa> or phone toII-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 8a224f80

Lecture 1
Storage Technologies
Upon completion of this unit, you should be able to:
• Define storage technologies
• Describe Red Hat Storage Model
• Connect to and configure lab environment equipment
For use only by a student enrolled in a Red HM training course taught by Red Hat, Inc. or a Red Hat Certffied Treining Partner. No par, of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior vnitt' en consent of Red HM, Inc. I1 you believe Red Hat training material are being improperly used,
copied, or chstributed pisase email ctrainingeredhat. con> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
RH436-RHEL5u4-en-17-20110428 / 6f0a110dCopyright © 2011 Red Hat, Inc.
. .

The Data 1-1
• User versus System data
• Availability requirements
• Frequency and type of access
• Directory location
• /home versus /var/spool/mail
• Application data
• Shared?
• Host or hardware-specific data
User data often has more demanding requirements and challenges than system data. System data is
often easily re-created from installation CDs and a relatively small amount of backed-up configuration files.
System data can often be reused for similar architecture machines, whereas user data is highly specific to
each user.
Some user data lies outside of typical user boundaries, like user mailboxes.
Would the data ideally be shared among many machines?
is the data specific to a specific type of architecture?
For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No parí of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materiale are being improperly ueed,
copied, or distributed please email <training@redhat .0016> or phone toll-free (USA) +1 (855) 626 2994 or +1 (919)754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / c59804d9

Data Storage Considerations 1 -2
• Is it represented elsewhere?
• Is it private or public?
• Is it nostalgic or pertinent?
• Is it expensive or inexpensive?
• Is it specific or generic?
Is the data unique, or are there readily-accessible copies of ít elsewhere?
Does the data need to be secured, or is it available to anyone who requests it?
Is the data stored for historical purposes, or are old and new data being accessed just as frequently?
Was the data difficult or expensíve to obtain? Could it just be calculated from other already-available data,
or is it one of a kind?
Is the data specific to a particular architecture or OS type? Is it specific to one application, or one version of
one application?
For use only by a student enrollad in a Red Hat training course taught by Red Hat, Inc. or a Red HM Certifled Training Partner. No pan of this publícation may be photocopied,
duplicated, stored in a retrieval system, or othenvise reproduced without prior written consent of Red HM, Inc. It you believe Red HM training materials are being impropedy usad,
copiad, or cfistributed please email <training@redhat.coa> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 9864cabd

Data Availability 1 -3
• How available must it be?
• Data lifetime
• Archived or stored?
• Frequency and method of access
• Read-only or modifiable
• Application-specific or direct access
• Network configuration and security
• Is performance a concern?
• Applications "data starved"?
• Where are my single points of failure (SPOF)?
What happens if the data become unavailable? What is necessary to be done in the event of data
downtime?
How long is the data going to be kept around? Is it needed to establish a historical profile, or is it no longer
valid after a certain time period?
Is this data read-only, or is it frequently modified? What exactly is modified? Is modification a privilege of
only certain users or applications?
Are applications or users limited in any way by the performance of the data storage? What happens when
an application is put into a wait-state for the data it needs?
With regard to the configuration environment and resources used, where are my single points of failure?
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly usad,
copied, or distributed please email trainíng•redhat com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Coovriaht © 2011 Red Hat. Inc. RH436-RHEL5u4-en-17-20110428 / be32bccb

Planning for the Future 1 -4
• Few data requirements ever diminish
• Reduce complexity
• Increase fiexibility
• Storage integrity
Few data requirements ever diminish: the number of users, the size of stored data, the frequency of access,
etc.... What mechanisms are in place to aid this growth?
A reduction in complexity often means a simpler mechanism for its management, which often leads to less
error-prone tools and methods.
For use only by a student enrollad in a Red Hat training course taught by Red HM, Inc. or a Red HM Certified Training Partner. No part of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red HM, Inc. H you believe Red HM training materials are being improperly usad,
copiad, or cHstributed pisase email <traiaing•reclhat . coa, or phone toil-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 18fa55f5

The RHEL Storage Model 1 -5
Ale System Driver
Block Device Driver
Volume
The Red Hat Enterprise Linux (RHEL) Storage Model for an individual host includes physical volumes,
kernel device drivers, the Virtual File System and Appiication data structures. All file access is managed
similarly, and by the same, unique kernel I/O system, both the data, and the meta-data organizing the data.
RHEL includes many computing applications each with its own file, or data structure, including network
services, document processing, database and other media. With respect to data storage, the file type is
less dependent on the way it is stored, but the method by which an application at this layer accesses it.
The Virtual File System, or VFS, layer is the interface which handles file system related system calls for the
kernel. It provides a uniform mechanism for these calls to be passed to any one of a variety of different file
system implementations in the kernel such as ext3, msdos, GFS, NFS, CIFS, and so on. For example, if
a file on an ext3-formatted file system is opened by a program, VFS transparently passes the program's
open() system call to the kernel code (device driver) implementing the ext3 file system.
The file system device driver then typically sends low-level requests to the device driver implementing the
block device containing the filesystem. This could be a local hardware device (IDE, SCSI), a logical device
(software RAID, LVM), or a remote device (iSCSI), for example.
Volumes are contrived through device driver access. Whether the volume is provided through a local
system bus, or over an IP network infrastructure, it always provides logical bounds through which a file (or
record) data structure is accessible. Volumes do not organize data, but provide the logical "size" of such an
organizing structure.
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials ere being improperly usad,
copied, or distributed pisase email <training9reculat . coz> or phone toll-free (USA) +1 (886)626 2994 or +1 (919) 754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 5973e514

Volume Management 1-6
• A volume defines some forro of block aggregation
• Many devices may be combined as one
• Optimized through low-Ievel device configuration (often in hardware)
• Striping, Concatenation, Parity
• Consistent name space
• LUN
• UUID
A volume is a some forro of block aggregation that describes the physical bounds of data. These bounds
represent physical constraints of hardware and its abstraction or virtualization. Device capabilities,
connectivity and reliabílity all influence the availability of this data "container." Data cannot exceed these
bounds; therefore, block aggregation must be flexible.
Often times, volumes are made highly available or are optimized at the hardware level. For example,
specialty hardware may provide RAID 5 "behind the scenes" but present simple virtual SCSI devices to be
used by the administrator for any purpose, such as creating logical volumes.
If the RAID controller has multi-LUN support (is able to simulate multiple SCSI devices from a single one
or aggregation), larger storage volumes can be carved finto smaller pieces, each of which is assigned a
unique SCSI Logical Unit Number (LUN). A LUN is simply a SCSI address used to reference a particular
volume on the SCSI bus. LUNs can be masked, which provides the ability to exclusively assign a LUN to
one or more host connections. LUN masking does not use any special type of connection, it simply hides
unassigned LUNs from specific hosts (similar to an unlisted telephone number).
The Universally Unique IDentifier (UUID) is a reasonably guaranteed-to-be-unique 128 bit number used
to uniquely identify objects within a distributed system (such as a shared LUN, physical volume, volume
group, or logical volume).
UUIDs may be viewed using the blkid command:
# blkid
/dev/mapper/VolGroup0O-LogVo101: TYPE="swap"
/dev/mapper/VolGroup0O-LogVo100: UUID="9924e91b-le5c-44e2-bd3c-dlfbc82ce488" Ié
SEC_TYPE="ext2" TYPE="ext3"
/dev/sdal: LABEL="/boot" UUID="e000084b-26b9-4289-b1d9-efae190c22f5" SEC_TYPE="ext2" be
TYPE="ext3"
/dev/VolGroup0O/LogVo101: TYPE="swap"
/dev/sdbl: UUID="111a7953-85a5-4b28-9cff-b622316b789b" SEC_TYPE="ext2" TYPE="ext3"
For use only by a student enrollad in a Red Hat training course taught by Red HM, Inc. or a Red HM Certified Training Partner. No part of this publicano(' may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red HM, Inc. if you betieve Red HM training materials are being improperly used,
copiad, or cfistributed please ornan ctrainiageredhat . con> or phone ton-free (USA) +1 (1366) 626 2994 or +1 (919) 754 3700.
Copyright(?) 2011 Red Hat, Inc.
. .
RH436-RHEL5u4-en-17-20110428 / b3f8d9b5
7

SAN versus NAS 1 -7
• Two shared storage technologies trying to accomplish the same thing -- data
delivery
• Network Attached Storage (NAS)
• The members are defined by the network
• Scope of domain defined by IP domain
• NFS/CIFS/HTTP over TCP/IP
Delivers file data blocks
• Storage Area Network (SAN)
• The network is defined by its members
• Scope of domain defined by members
• Encapsulated SCSI over fibre channel
Delivers volume data blocks
Often used one for the other, Storage Area Network(SAN) and Network Accessed Storage (NAS) differ.
NAS is best described as IP network access to File/Record data. A SAN represents a collection of
hardware components which, when combined, present the disk blocks comprising a volume over a fibre
channel network. The iSCSI-SCSI layer communication over IP also satisfies this definition: the delivery of
low-level device blocks to one or more systems equally.
NAS servers generally run some form of a highly optimized embedded OS designed for file sharing. The
NAS box has direct attached storage, and clients connect to the NAS server just like a regular file server,
over a TCP/IP network connection. NAS deals with files/records.
Contrast this with most SAN implementations in which Fibre-channel (FC) adapters provide the
physical connectivity between servers and disk. Fibre-channel uses the SCSI command set to handle
communications between the computer and the disks; done properly, every computer connected to the disk
view it as if it were direct attached storage. SANs deal with disk blocks.
A SAN essentially becomes a secondary LAN, dedicated to interconnecting computers and storage
devices. The advantages are that SCSI is optimized for transferring large chunks of data across a reliable
connection, and having a second network can off-load much of the traffic from the LAN, freeing up capacity
for other uses.
duplicated, *torrad in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training material* are being improperly usad,
copied, or distributed please email < training*redhat com> or phone toll-free (USA) +1 (866) 628 2994 or +1 (919) 754 3700.
Copyright 02011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 631 ba8c2

SAN Technologies 1 -8
• Different mechanisms of connecting storage devices to machines over a network
• Used to emulate a SCSI device by providing transparent delivery of SCSI protocol
to a storage device
• Provide the illusion of locally-attached storage
• Fibre Channel
• Networking protocol and hardware for transporting SCSI protocol across fiber optic equipment
• Internet SCSI (iSCSI)
• Network protocol that allows the use of the SCSI protocol over TCP/IP networks
• "SAN via IP"
• Global Network Block Device (GNBD)
• Client/Server kernel modules that provide block-level storage access over an Ethernet LAN
• Deprecated by iSCSI, included for compatibility only,
Most storage devices use the SCSI (Small Computer System Interface) command set to communicate.
This is the same command set that was developed to control storage devices attached to a SCSI parallel
bus. The SCSI command set is not tied to the originally-used bus and is now commonly used for all storage
devices with all types of connections, including fibre channel. The command set is still referred to as the
SCSI command set.
The LUN on a SCSI parallel bus is actually used to electrically address the various devices. The concept of
a LUN has been adapted to fibre channel devices to allow multiple SCSI devices to appear on a single fibre
channel connection.
It is important to distinguish between a SCSI device and a fibre channel (or iSCSI, or GNBD) device. A fibre
channel device is a abstract device that emulates one or more SCSI devices at the lowest leve) of storage
virtualization. There is not an actual SCSI device, but one is emulated by responding appropriately to the
SCSI protocol.
SCSI over fibre channel is similar to speaking a language over a telephone connection. The low level
connection (fibre channel) is used to transpon the conversation's language (SCSI command set).
For use only by a student enrolled in a Red HM training course taught by Red HM, Inc. or a Red HM Certified Training Partner. No part of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red HM, Inc. tf you believe Red HM training material are being improperly used,
copiad, or cfistributed pelase email ctrainiageredhat . coa> or phone to1I-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright O 2011 . Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 4ddab820

Fibre Channel 1-9
Common enterprise-class network connection to storage technology
• Major components:
• Fiber optic cable
• Interface card (Host Bus Adaptor)
• Fibre Channel switching technology
Fibre Channel is a storage networking technology that provides flexible connectivity options to storage
using specialized network switches, fiber optic cabling, and optic connectors.
While a common connecting cable for fibre channel is fiber-optic, it can also be enabled over twisted pair
copper wire, despite the implied limitation of the technology's name. Transmitting the data via light signals,
however, allows the cabling lengths to far exceed that of normal copper wiring and be far more resistant to
electrical interference.
The Host Bus Adaptor (HBA), in its many forms, is used to convert the light signals transmitted over the
fiber-optic cables to electrical signals (and vice-versa) for interpretation by the endpoint host and storage
technologies.
The fibre channel switch is the foundation of a fibre channel network, defining the topology of how the
network ports are arranged and the data path's resistance to failure.
For use only by a student enrolled in a Red HM training course taught by Red Het, Inc. or e Red Hat Certified Training Partner. No part of this publication mey be photocopied,
duplicated, stored in e retrievel system, or otherwise reproduced without prior written consent of Red Het, Inc. If you believe Red Het training meteriale ere being improperly used,
copied, or distributed please emeil < t reining0redhat com> or phone toIl-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 78crif51

Host Bus Adapter (HBA) 1-10
• Used to connect hosts to the fibre channel network
• Appears as a SCSI adapter
• Relieves the host microprocessor of data I/O tasks
• Multipathing capable
An HBA is simply the hardware on the host machine that connects it to, for example, a fibre channel
networked device. The hardware can be a PCI, Sbus, or motherboard-embedded IC that transiates signals
on the local computer to frames on the fibre channel network.
An operating system treats an HBA exactly like it does a SCSI adapter. The HBA takes the SCSI
commands it was sent and transiates them into the fiber channel protocol, adding network headers and
error handling. The HBA then makes sure the host operating system gets return information and status
back from the storage device across the network, just like a SCSI adapter would.
Some HBAs offer more than one physical pathway to the fibre channel network. This is referred to as
multipathing.
While the analogy can be drawn to NICs and their purpose, HBAs tend to be far more intelligent: switch
negotiation, tracking devices on the network, I/O processing offloading, network configuration monitoring,
load balancing, and failover management. Critica! to the HBA is the driver that controls it and communicates
with the host operating system.
In the case of iSCSI-like technologies, TCP Offloading Engine (TOE) cards can be used instead of ordinary
NICs for performance enhancement.
For use onty by a student enrollad in a Red HM training course taught by Red HM, Inc. or a Red HM Certified Training Partner. No pan of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red HM, Inc. If you believe Red HM training materials are being improperly usad,
copied, or cfistributed pisase email ctrainingaredhat coa> or phone tdt-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright (?) 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 2dbdf27c
• •

Fibre Channel Switch
• Foundation of a Fibre channel SAN, providing:
• High-speed non-blocking interconnect between devices
• Fabric services
• Additional ports for scalability
• Linking capability of the SAN over a wide distance
• Switch topologies
• Point-to-Point - A simple two-device connection
• Arbitrated loop - All devices are arranged in a loop connection
• Switched fabric - All devices are connected to one or more interconnected Fibre Channel switches,
and the switches manage the resulting "fabric" of communication channels
The fibre channel fabric refers to one or more interconnected switches that can communicate with each
other independently instead of having to share the bandwidth, such as in a looped network connection.
Additional fiber channel switches can be combined into a variety of increasingly complex wired connection
patterns to provide total redundancy so that failure of any one switch will not harm the fabric connection and
still provide maximum scalability.
Fibre channel switches can provide fabric services. The services provided are conceptually distributed
(independent of direct switch attachment) and include a login server (fabric device authentication), name
server (a distributed database that registers all devices on a fabric and responds to requests for address
information), time server (so devices can maintain system time with each other), alias server (like a name
server for multicast groups), and others.
Fibre channel is capable of communicating up to 100km.
duplicated, atorad in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used,
copied, or distributed please email < t redningeradhat . coa> or phone toll-f res (USA) +1 (855) 826 2994 or +1 (919) 754 3700.
Copyright O 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 2c3a168e

Internet SCSI (iSCSI) 1-12
• A protocol that enables clients (initiators) to send SCSI commands to remote
storage devices (targets)
• Uses TCP/IP (tcp : 3260, by default)
• Often seen as a low-cost alternatíve to Fibre Channel because ít can run over
existing switches and network infrastructure
iSCSI sends storage traffic over TCP/IP, so that inexpensive Ethernet equipment may be used instead
of Fibre Channel equipment. FC currently has a performance advantage, but 10 Gigabit Ethernet will
eventually allow TCP/IP to surpass FC in overall transfer speed despíte the additional overhead of TCP/IP
to transmit data. TCP offload engines (TOE) can be used to remove the burden of doing TCP/IP from the
machines using iSCSI. iSCSI is routable, so it can be accessed across the Internet.
For use only by a atudent enrollad in a Red HM training course taught by Red Hat, Inc. or a Red HM Certified Training Partner. No part of this publication may be photocopied,
duplicated, atorad in a retrieval system, or otherwise reproduced without prior written consent of Red HM, Inc. It you betieve Red HM training materiafs are being improperly usad,
copiad, or distributed pisase email <trainingeredhat con or phone toil-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
RH436-RHEL5u4-en-17-20110428 / 59b9f233Copyright © 2011 Red Hat, Inc.
. . . • /1

End of Lecture 1
• Questions and Answers
• Summary
• How best to manage your data
• Describe Red Hat Storage Model
• Explain Common Storage Hardware
For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No parí of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you betieve Red Hat training material. are being improperly usad,
copied, or distributed please email <training.redhat . coxa> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright O 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-201 10428 / 6f0a110d
- •

Lab 1.1: Evaluating Your Storage Requirements
Instructions:
1. What is the largest amount of data you manage, including all types and all computing
platforms?
2. What is the smallest significant group of data that must be managed?
3. How many applications require access to your largest data store? Are these applications running
on the same computing platform?
4. How many applications require access to your smallest data store? Are these applications
running on the same computing platform?
5. How would you best avoid redundancy of data stored while optimizing data access and
distribution? How many copies of the same data are available directly to each host? How many
are required?
6. When was the last time you reduced the size of a data storage environment, including the
amount of data and the computing infrastructure it supported? Why was this necessary?
7. Which data store is the most unpredictable (categorize by growth, access, or other means)?
What accounts for that unpredictability?
8. Which is the most predictable data store you manage? What malees this data store so
predictable?
9. List your top five most commonly encountered data management issues and categorize them
according to whether they are hardware, software, security, user related, or other.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 3dfc33ae

10. What does data unavailability "cost" your organization?
11. What percentage of your data storage is archived, or "copied" to other media to preserve its
state at a point in time? Why do you archive data? What types of data would you never archive,
and why? How often do you archive your data?
12. What is the least important data store of your entire computing environment? What makes it
unimportant?
r,nnvrinht n 9(111 Pori Hat Inr n, 1A 17 nni i nAno I

1
Lab 1.2: Configuring the Virtual Cluster Environment
Scenario: The root password is redhat for your classroom workstation and for a11
virtual machines.
11>
Deliverable: Create, instan, and test the virtual cluster machines hosted by your
workstation.
1
Instructions:
1. Configure your physical machine to recognize the hostnames of your virtual machines:
1,
stationX# cat RH436/HelpfulFiles/hosts - table » /etc/hosts
2. The virtual machines used for your labs still need be created. Execute the script rebuild-
c luster -m. This script will build a master Xen virtual machine (cXnO . example.com,
172.16.50. X0, hereafter referred to as 'node0') within a logical volume. The node O Xen
virtual machine will be used as a template to create three snapshot images. These snapshot
images will, in turn, become our cluster nodes.
111 stationX# rebuild-cluster -m
This will create or rebuild the template node (node0).
Continue? (y/N): y
If you are logged in graphically a virt- viewer will automatically be created, otherwise your
IP terminal will automatically become the console window for the instan.
The installation process for this virtual machine template will take approximately 10-15
IIP minutes.
3. Once your nade O installation is complete and the node has shut down, your three cluster
nodes:
cXnl.example.com 172.16.50.X1
cXn2.example.com 172.16.50.X2
cXn3.example.com 172.16.50.X3
can now be created. Each cluster node is created as a logical volume snapshot of nade O.
The pre-created rebuild- cluster script simplifies the process of creating and/or
rebuilding your three cluster nodes. Feel free to inspect the script's contents to see what it is
11)
doing. Passing any combination of numbers in the range 1 -3 as an option to rebui ld-
c lus ter creates or rebuilds those corresponding cluster nodes in a process that takes only a
few minutes.
10
At this point, create three new nodes:
stationX# rebuild-cluster -123
This will create or rebuild node(s): 1 2 3
Continue? (y/N): y
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 1ccafc0b

•Monitor the boot process of one or all three nodes using the command:
st ionX# xm console nodeN
where N is a node number in the range 1-3. Console mode can be exited at any time with the
411keystroke combination: Ct rl - ] .
To rebuild only node3, execute the following command (Do not worry if it has not finished
•booting yet):
st at rebuild - cluster - 3 1111
Because the cluster nodes are snapshots of an already-created virtual machine, the rebuilding
process is dramatically reduced in time, compared to building a virtual machine from scratch, as •
we did with node0.
•You should be able to log into all three machines once they have completed the boot process.
For your convenience, an /et c/host s table has already been preconfigured on your cluster 11/nodes with name-to-IP mappings of your assigned nodes.
If needed, ask your instructor for assistance.
•
1
111
•
•Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 1ccafc0b

Lecture 2
iSCSI Configuration
Upon completion of this unit, you should be able to:
• Describe the iSCSI Mechanism
• Define iSCSI Initiators and Targets
• Explain iSCSI Configuration and Tools
For use only by a student enrollad in a Red HM training course taught by Red HM, Inc. or a Red HM Certified Training Partner. No part of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red HM, Inc. 1f you betieve Red HM training materiMs are being improperly usad,
copiad, or distributed piense email <trainingeredhat. coa> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 2276845b

Host Appitcatioris
~II
SCSI Driver
iSCSI Driver
TCP/IP
Network Drivers
Storage Router or
Gateway
SCSt or PC
Adepter Driver
Red Hat iSCSI Driver 2-1
• Provides a host with the ability to access storage via IP
• iSCSI versus SCSI/FC access to storage:
The iSCSI driver provides a host with the ability to access storage through an IP network.
The driver uses the iSCSI protocol (IETF-defined) to transport SCSI requests and responses over an IP
network between the host and an iSCSI target device. For more information about the iSCSI protocol, refer
to RFC 3720 (http: //www.ietf .org/rfc/rfc3 7 2 O .txt).
Architecturally, the iSCSI driver combines with the host's TCP/IP stack, network drivers, and Network
Interface Card (NIC) to provide the same functions as a SCSI or a Fibre Channel (FC) adapter driver with a
Host Bus Adapter (HBA).
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly usad,
copied, or distributed piense email ctrainingersdhat . coa> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 765b832c

iSCSI Data Access 2-2
• Clients (initiators) send SCSI commands to remote storage devices (targets)
• Uses TCP/IP (t cp : 3260, by default)
• Initiator
• Requests remote block device(s) via discovery process
• iSCSI device driver required
• iscs i service enables target device persistence
• Package:iscsi-initiator-utils-*.rpm
• Target
• Exports one or more block devices for initiator access
• Supported starting RHEL 5.3
• Package:scsi-target-utils-*.rpm
An initiating device is one that actively seeks out and interacts with target devices, while a target is a
passive device.
The host ID is unique for every target. The LUN ID is assigned by the iSCSI target.
The iSCSI driver provides a transport for SCSI requests and responses to storage devices via an IP
network instead of using a direct attached SCSI bus channel or an FC connection. The Storage Router, in
turn, transports these SCSI requests and responses received via the IP network between it and the storage
devices attached to it.
Once the iSCSI driver is installed, the host will proceed with a discovery process for storage devices as
follows:
• The iSCSI driver requests available targets through a discovery mechanism as configured in the /etc/
iscsi/iscsid . conf configuration file.
• Each iSCSI target sends available iSCSI target names to the iSCSI driver.
• The iSCSI target accepts the login and sends target identifiers.
• The iSCSI driver queries the targets for device information.
• The targets respond with the device information.
• The iSCSI driver creates a table of available target devices.
Once the table is completed, the iSCSI targets are available for use by the host using the same commands
and utilities as a direct attached (e.g., via a SCSI bus) storage device.
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training material are being improperly usad,
copiad, or distributed pisase email <training•redhat . coro or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / a8c0b9ed
rs 4

•
•
•
•
•
e
e
.
.
•
•
iSCSI Driver Features 2-3
• Header and data digest support
• Two way CHAP authentication
• R2T flow control support with a target
• Multipath support (RHEL4-U2)
• Target discovery mechanisms
• Dynamic target discovery
• Async event notifications for portal and target changes
• Immediate Data Support
• Dynamic driver reconfiguration
• Auto-mounting for iSCSI filesystems after a reboot
Header and data digest support - The iSCSI protocol defines a 32-bit CRC digest on an iSCSI packet to
detect corruption of the headers (header digest) and/or data (data digest) because the 16-bit checksum
used by TCP is considered too weak for the requirements of storage on long distance data transfer.
Two way Challenge Handshake Authentication Protocol (CHAP) authentication - Used to control access to
the target, and for verification of the initiator.
Ready-to-Transfer (R2T) flow control support - A type of target communications flow control.
Red Hat multi-path support - iSCSI target access via multiple paths and automatic failover mechanism.
Available RHEL4-U2.
Sendtargets discovery mechanisms - A mechanism by which the driver can submit requests for available
targets.
Dynamic target discovery - Targets can be changed dynamically.
Async event notifications for portal and target changes - Changes occurring at the target can be
communicated to the initiator as asynchronous messages.
Immediate Data Support - The ability to send an unsolicited data burst with the iSCSI command protocol
data unit (PDU).
Dynamic driver reconfiguration - Changes can be made on the initiator without restarting all iSCSI sessions.
Auto-mounting for iSCSI filesystems after a reboot - Ensures network is up before attempting to auto-mount
iSCSI targets.
•
•
e
•
e
eFor use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are beIng improperly used,
copied, or distributed please email <trainingeredhat .com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Coovriaht © 2011 Red Hat. Inc. RH436-RHEL5u4-en-17-20110428 / 32798410
•

iSCSI Device Names and Mounting 2-4
• Standard default kemel names are used for iSCSI devices
• Linux assigns SCSI device names dynamically whenever detected
• Namíng may vary across reboots
• SCSI commands may be sent to the wrong logical unit
• Persistent device naming (2.6 kernel)
• udev
• UUID and LABEL-based mounting
• Important /etc/fstab option: _netdev
• Without this, rc.sysinit attempts to mount target before network or iscsid services have started
The iSCSI driver uses the default kernel names for each iSCSI device the same way it would with other
SCSI devices and transports like FC/SATA.
Since Linux assigns SCSI device nodes dynamically whenever a SCSI Iogical unit is detected, the mapping
from device nodes (e.g., /dev/sda or /dev/sdb) to iSCSI targets and Iogical units may vary. Factors
such as variations in process scheduling and network delay may contribute to iSCSI targets being mapped
to different kernel device names every time the driver is started, opening up the possibility that SCSI
commands might be sent to the wrong target.
We therefore need persistent device naming for iSCSI devices, and can take advantage of some 2.6 kernel
features to manage this:
udev - udev can be used to provide persistent names for all types of devices. The scsi_id program, which
provides a serial number for a given block device, is integrated with udev and can be used for persistence.
UUID and LABEL-based mounting - Filesystems and LVM provide the needed mechanisms for mounting
devices based upon their UUID or LABEL instead of their device name.
For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publicaban may be photocopiad,
duplicated, stored in a retrievat system, or otherwise reproduced without prior written consent of Red Hat, Inc. It you believe Red Hat training materials are being improperly used,
copiad, or distributed pisase email ctraining•redhat . con» or phone toll-free (USA) +1 (886) 626 2994 or +1 (919) 754 3700.
RH436-RHEL5u4-en-17-20110428 / 4c5159dbCopyright © 2011 Red Hat, Inc.
. .

iSCSI Target Naming 2-5
• iSCSI Qualified Name (IQN)
• Must be globally unique
• The IQN string format:
iqn <datecode>.<reversed domain> <string>[:<substring>]
• The IQN sub-fields:
• Required type designator (iqn)
• Date code (yyyy-mm)
• Reversed domain name (t/d.domain)
• Any string guaranteeing uniqueness (string [ [ string] . . .])
• Optional colon-delimited sub-group string ( [ : substring] )
• Example:
iqn.2007-01.com.example.sales:sata.rack2.diskl
The format for the iSCSI target name is required to start with a type designator (for example, 'iqn', for
'iSCSI Qualified Name') and must be followed by a multi-field (delimited by a period character) unique
name string that is globally unique. There is a second type designator we won't discuss here, eui, that
uses a naming authority similar to that of Fibre Channel world-wide names (an EUI-64 address in ASCII
hexadecimal).
The first sub-field consists of the reversed domain name owned by the person or organization creating the
iSCSI name. For example: com . example.
The second sub-field consists of a date code in yyyy - mm format. The date code must be a date during
which the naming authority owned the domain name used in this format, and should be the date on which
the domain name was acquired by the naming authority. The date code is used to guarantee uniqueness in
the event the domain name was transferred to another party and both barbes wish to use the same domain
name.
The third field is an optional string identifier of the owner's choosing that can be used to guarantee
uniqueness. Additional fields can be used if necessary to guarantee uniqueness.
Delimited from the name string by a colon character, an optional sub-string qualifier may also be used to
signify sub-groups of the domain.
See the document at http: //www3 ietf .org/proceedings/Oldec/I-D/draft-ietf -ips-
iscsi-name-disc- 03 .txt for more details.
For use only by a student enrollad in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No parí of thls publication may be photocopled,
duplicated, atorad in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. 11 you believe Red Hat training materials are being improperly used,
copiad, or distributed piense email trainingOredhat com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919)754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / ea325263

Configuring iSCSI Targets 2-6
• Install scsi-target-utils package
• Modify letc/tgt/targets . conf
• Start the tgtd service
• Verify configuration with tgt-admin -s
• Reprocess the configuration with tgt-admin --update
• Changing parameters of a 'busy' target is not possible this way
• Use tgtadm instead
Support for configuring a Linux server as an iSCSI target is supported in RHEL 5.3 onwards, based on the
scsi-target-utils package (developed at http : //stgt.berlios.de/).
After installing the package, the userspace tgtd service must be started and configured to start at boot.
Then new targets and LUNs can be defined using /etc/tgt/targets.conf. Targets have an iSCSI
name associated with them that is universally unique and which serves the same purpose as the SCSI ID
number on a traditional SCSI bus. These names are set by the organization creating the target, with the
iqn method defined in RFC 3721 being the most commonly used.
/etc/tgt/targets.conf:
Parameter
backing-store device
direct-store device
initiator-address address
íncominguser username password
outgoinguser username password
Example:
Description
defines a virtual device on the target.
creates a device that with the same VENDORID
and SERIAL_NUM as the underlying storage
Limits access to only the specified IP address.
Defaults to all
Only specified user can connect.
Target will use this user to authenticate against the
initiator.
<target iqn.2009-10.com.example.cluster20:iscsi>
# List of files to export as LUNs
backing-store /dev/volO/iscsi
initiator-address 172.17.120.1
</target>
For use only by a student enrollad in a Red Hat training course taught by Red HM, Inc. or a Red HM Certified Training Partner. No pan of this publication may be photocopied,
duplicated, stored in a relievel system, or otherwise reproduced without prior written consent of Red HM, Inc. ff you believe Red HM training material are being improperly used,
copiad, or cfistributed pleese email ctrainingOredhat . coa> or phone toil-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
RH436-RHEL5u4-en-17-20110428 / bfd4c00eCopyright @ 2011 Red Hat, Inc.
... . . . nc

Manual iSCSI configuration 2-7
• Create a new target
• # tgtadm --Ild iscsi --op new --mode target --tid 1 -T iqn.2008-02.cozn.exaznple:diskl
• Export local block devices as LUNs and configure target access
• # tgtadm --Ild iscsi --op new --mode logicalunit --tid 1 --Iun 1 -b /dev/v010/iscsil
• # tgtadm --Ild iscsi --op bind --mode target --tid 1-I 192.0.2.15
To create a new target manually and not persistently, with target ID 1 and the name
iqn.2008-02.com.example:diskl,Use:
frootstation51# tgtadm --11d iscsi --op new --mode target --tid 1 -T
ign.2008-02.com.example:diskl
Then that target needs to provide one or more disks, each assigned to a logical unit number or LUN. These
disks are arbitrary block devices which will only be accessed by iSCSI initiators and are not mounted as
local file systems on the target. To set up LUN 1 on target ID 1 using the existing logical volume /dev/
vol o/iscen as the block device to export:
[root9station5]# tgtadm --11d iscsi --op new --moda logicalunit --tid 1 ke
--lun 1 -b /dev/volO/iscsil
Finally, the target needs to allow access to one or more remote initiators. Access can be allowed by IP
address:
[rootstation5]# tgtadm --11d iscsi --op bind --mode target --tid 1 -I /
192.168.0.6
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training material. are being improperly usad,
copied, or distributed please email <training®redhat . com> or phone toll-free (USA) +1 (888) 628 2994 or +1 (919)754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / d86e078d

Configuring the iSCSI Initiator Driver 2-8
• /etc/iscsi/iscsid.conf
• Default configuration works unmodified (no authentication)
• Settings:
• Startup - automatic or manual
• CHAP - usernames and passwords
• Timeouts - connections, login/logout
• iSCSI - flow control, payload size, digest checking
The following settings can be configured in /etc/ scsi / iscsid . conf.
Startup settings:
node.startup
CHAP settings:
node.session.auth.authmethod
node.session.auth.username
node.session.auth.password
node.session.auth.username_in
node.session.auth.password_in
discovery.sendtargets.auth.authmethod
discovery.sendtargets.auth.username
discovery.sendtargets.auth.password
discovery.sendtargets.auth.username_in
discovery.sendtargets.auth.password_in
automatic Or manual
Enable CHAP authentication (cHAP). Default is
NONE.
CHAP username for initiator authentication by the
target
CHAP password for initiator authentication by the
target
CHAP username for target authentication by the
initiator
CHAP password for target authentication by the
initiator
Enable CHAP authentication (cHAP) for a discovery
session to the target. Default is NONE.
Set a discovery session CHAP username for the
initiator authentication by the target
Set a discovery session CHAP username for the
initiator authentícation by the target
Set a discovery session CHAP username for target
authentication by the initiator
Set a discovery session CHAP username for target
authentication by the initiator
For more information about iscsid. conf settings, refer to the file comments.
For use only by a student enrolled in a Red HM training course taught by Red HM, Inc. or a Red HM Certified Training Partner. No part of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red HM, Inc. If you believe Red HM training materials are being improperly usad,
copied, or cfistributed pisase email <training•redbat . coa> or phone toil-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 85675f28
• 7

iSCSI Authentication Settings 2-9
• Two-way authentication can be configured using CHAP
• Target must also be capable/configured
• No encryption of iSCSI communications
• Authentication based on CHAP implies that:
• Usemame and challenge is sent cleartext
• Authenticator is a hash (based on challenge and password)
• If username, challenge and authenticator is sniffed, offline brute force attack is possible
• Standard (RFC 3720) recommends use of IPSec
• Consider running on an isolated storage-only network
CHAP (Challenge Handshake Authentication Protocol) is defined as a one-way authentication method
(RFC 1334), but CHAP can be used in both directions to create two-way authentication.
The following sequence of events describes, for example, how the initiator authenticates with the target
using CHAP: After the initiator establishes a link to the target, the target sends a challenge message back
to the initiator. The initiator responds with a value obtained by using its authentication credentials in a
one-way hash function. The target then checks the response by comparing it to its own calculation of the
expected hash value. If the values match, the authentication is acknowledged; otherwise the connection is
terminated.
The maximum length for the username and password is 256 characters each.
For two-way authentication, the target will need to be configured also.
For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red HM Certified Training Partner. No parí of this publication may be photocopied,
duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red HM training materiale are being Improperly used,
copied, or distributed pisase email <training@redhat . com, or phone toll-free (USA) +1 (866) 626 2994 or +1 (919)754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 9648105a

Configuring the open-iscsi Initiator 2-10
• iscsiadm
• open - iscsi administration utility
• Manages discovery and login to iSCSI targets
• Manages access and configuration of open - iscsi database
• Many operations require the iscsid daemon to be running
• Files:
• /etc/iscsi/iscsid.conf - main configuration file
• /etc/iscsi/initiatorname.iscsi - sets initiator name and alias
• /var/lib/iscsi/nodes/ - node and target information
• /var/lib/iscsi/send_targets - portal information
/etc/iscsi/iscsid. conf - configuration file read upon startup of iscsid and iscsiadm
/etc/iscsi/initiatorname .iscsi - file containing the iSCSI InitiatorName and
InitiatorAlias read by iscsid and iscsiadm on startup.
/var/lib/iscsi/nodes/ - This directory describes information about the nodes and their targets.
/var/lib/iscsi/send_targets - This directory contains the portal information.
For more information, see the file /usr/share/doc/iscsi-initiator-utils- */README.
For use only by a student enrollad in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Cerfified Training Partner. No para of this publication may be photocopied,
duplicated, atorad in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. It you believe Red Hat training materials are being improperly usad,
copiad, or cfistributed pisase email ctraiaiageredfiat . con> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 87fb99cb
... . — , rara

First-time Connection to an iSCSI Target 2-11
• Start the initiator service:
• # service iscsi start
• Discover available targets:
• # iscsiadm -m discovery -t
172.16.36.71:3260,1 iqn.2007-01
• Login to the target session:
• # iscsiadm -m node -T iqn.2007-01.com
• View information about the targets:
• # iscsiadm -m node -P N (N=0, 1)
• # iscsiadm -m session -P N (N=0 - 3)
• # iscsiadm -m discovery -P N (N=0, 1)
.com.example:storage.diskl
.example:storage.diskl -p 172.16.36.1:3260 -I
sendtargets -p 172.16.36.1:3260
The iSCSI driver has a SysV initialization script that will report information on each detected device to the
console or in dmesg(8) output.
Anything that has an iSCSI device open must close the iSCSI device before shutting down iscsi. This
includes filesystems, volume managers, and user applications.
If iSCSI devices are open and an attempt is made to stop the driver, the script will error out and stop iscsid
instead of removing those devices in an attempt to protect the data on the iSCSI devices from corruption. If
you want to continue using the iSCSI devices, it is recommended that the iscsi service be started again.
Once Iogged into the iSCSI target volume, it can then be partitioned for use as a mounted filesystem.
When mounting iSCSI volumes, use of the netdev mount option is recommended. The _netdev
mount option is used to indicate a filesystem that requires network access, and is usually used as a
preventative measure to keep the OS from mounting these file systems until the network has been enabled.
It is recommended that all filesystems mounted on iSCSI devices, either directly or on virtual devices
(LVM, MD) that are made up of iSCSI devices, use the ' netdevl mount option. With this option, they will
automatically be unmounted by the net f s initscript (before iscsi is stopped) during normal shutdown, and
you can more easily see which filesystems are in network storage.
duplicated, stored in e retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training material, are belng Improperly used,
copied, or distributed oleosa email < t reining@recthat . cosa> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright © 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 9effb144
A II -• La-

Managing an iSCSI Target Connection 2-12
To disconnect from an iSCSI target:
• Discontinue usage
• Log out of the target session:
• # iscsiadm -m node -T iqn.2007-01.com.example:storage.disk1 -p 172.16.36.1:3260 -u
To later reconnect to an iSCSI target:
• Log in to the target session
• # iscsiadm -m node -T iqn.2007-01.com.example:storage.disk1 -p 172.16.36.1:3260 -1
or restart the iscsi service
• # service iscsi restart
The iSCSI initiator "remembers" previously-discovered targets. Because of this, the iSCSI initiator will
automatically Iog finto the aforementioned target(s) at boot time or when the iscsi service is restarted.
For use only by a student enrollad in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Cerlified Training Partner. No part of this publication may be photocopied,
duplicated, atorad in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly usad,
copiad, or distributed please email <training•redhat . coa> or phone toil-free (USA) +1 (666) 626 2994 or +1 (919) 754 3700.
Copyright e 2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / 16c7ae1c
... . , . , ni

Disabling an iSCSI Target 2-13
To disable automatic iSCSI Target connections at boot time or iscsi service restarts:
• Discontinue usage
• Log out of the target session
• # iscsiadm -m node -T iqn.2007-01.com.example:storage.diskl -p 172.16.36.1:3260 -u
• Delete the target's record ID
• # iscsiadm -m node -o delete -T iqn.2007-01.com.example:storage.disk1 -p 172.16.36.1:3260
Deleting the target's record ID will clean up the entries for the target in the /var/lib/iscsi directory
structure.
Alternatively, the entries can be deleted by hand when the iscsi service is stopped.
duplicated, atorad in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly usad,
copied, or distributed pisase email <training8redhat com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.
Copyright ©2011 Red Hat, Inc. RH436-RHEL5u4-en-17-20110428 / d9f1Oef6

End of Lecture 2
• Questions and Answers
• Summary
• Describe the iSCSI Mechanism
• Define iSCSI Initiators and Targets
• Explain iSCSI Configuration and Tools
For use ordy by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No para of this publication may be photocopied,
duplicated, atorad in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. H you believe Red Hat training material* are being improperly usad,
copied, or distributed picase email ctrainingWredhat . coa> or phone toll-free (USA) +1 (866)626 2994 or +1 (919) 754 3700.
RH436-RHEL5u4-en-17-20110428 / 2276845bCopyright 2011 Red Hat, Inc.
. . . 00

•
•
•
•
•
•
•
Lab 2.1: iSCSI Software Target Configuration
Scenario: For a test cluster you have been assigned to configure a software iSCSI
target as backend storage.
Deliverable: A working iSCSI software target we can use to practice configuration of an
iSCSI initiator.
•
•
•
•
•Instructions:
1. Instan the scsi -target - ut i I s package on your physical machine
2. Create a 5GiB logical volume named iscsi inside the vol O volumegroup to be exported as
the target volume.
3. Modify /e tc/tgt/target s . conf so that it exports the volume to the cluster nodes:
IQN iqn.2009-10.com.example.clusterx:iscsi
Backing Store klev/volOnscsi
Initiator Addresses 172.17. (1 00+x).1 ,
172.17. (1 00+X).3
172.17. (1 00+X).2 ,
4. Start the tgtd service and make sure that it will start automatically on reboot.
5. Check to see that the iSCSI target volume is being exported to the correct host(s).
•
•
•
••
•
••
•Coovriaht © 2011 Red Hat. Inc. P11-141A-1:11-1PI Fi id-on-17-9111 1 nA9sa h.gs:triniA

RH436 pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to RH436 pdf

Similar to RH436 pdf (20)

Recently uploaded

Recently uploaded (20)

RH436 pdf