Difference between revisions of "CU Norlin Library Linux training"
(Created page with "Outline of advanced session topics: == A Red Hat Enterprise Linux installation == * Minimum OS requirements:<br /> https://access.redhat.com/site/documentation/en-US/Red_Hat_...") |
|||
Line 62: | Line 62: | ||
* Definitions: |
* Definitions: |
||
** Physical volume: a disk drive (but it could also be a software mirror, or a RAM disk, or an encrypted device) |
** Physical volume: a disk drive (but it could also be a software mirror, or a RAM disk, or an encrypted device) |
||
− | ** Physical extent: a fixed size chunk of some disk drive like device that is then allocated to an abstracted logical volume. A physical extent cannot span more than one physical volume. Sizes range from |
+ | ** Physical extent: a fixed size chunk of some disk drive like device that is then allocated to an abstracted logical volume. A physical extent cannot span more than one physical volume. Sizes range from 1024 bytes and up by powers of 2. |
+ | ** Volume group: A collection of one or more physical volumes. On these physical volumes, extents may be provisioned into one or more logical volumes for use by other layers such as filesystems, swap space, virtual machine images, etc. |
||
− | |||
+ | ** Logical volume: a collection of logical extents |
||
⚫ | |||
+ | ** Logical extent: a block of data that is mapped to one (or more if mirroring with LVM) physical extent somewhere inside the volume group. Logical volumes may be striped using extents from more than one physical volume if desired. The can be snapshotted, created, and deleted as needed. |
||
+ | * Hands on: |
||
+ | ** Look what block devices we have listed in /proc/partitions |
||
+ | ** add 2 10Gbyte thin provisioned logical disks to each of our lab VMs |
||
+ | ** Look at kernel message buffer (<code>dmesg</code> and <code>/proc/partitions</code> after disks have been added. Was a reboot needed to find them? |
||
+ | ** Decided whether to partition these new disks. GPT or MBR partition? If creating partitions, was a reboot needed? |
||
⚫ | |||
Revision as of 19:58, 19 June 2014
Outline of advanced session topics:
A Red Hat Enterprise Linux installation
- Minimum OS requirements:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/chap-Virtualization_Host_Configuration_and_Guest_Installation_Guide-System_Requirements.html - Wrinkles added by virtualization:
- Possible virtual network card issues (but not with current RHEL)
- Virtual hard drives are easily expandable, so less need to take pains up front for disk sizing
- Console video can be slow and mouse can be painful
- If we can provide 2 Gbytes of RAM, a < 7 year old CPU, and 30+ Gbytes of disk, RHEL will be happy
- Apps are extra
- Gather requirements from application owners (or help them in talking to the vendors)
- How much RAM, disk, CPU is needed?
- Gather network info:
- IP address, netmask, default gateway
- DNS resolver config: name server IP addresses, and domain search path
- Will this machine be using NIS/YP, LDAP, some other network based directory service? No, not here at Norlin.
- Or just skip all that and rely on DHCP
- Create empty VM in HyperV
- Attach RHEL 6.5 DVD ISO image to VM's DVD drive
- Power it on
- Walk through installer one step at a time:
- Point out the advanced disk options, but save details for later
- Installation done. Reboot and log in on console
- Make sure hypervisor support package is installed
- Ping my router
- How do I find the router's IP? I got it by DHCP.
- Ping other machines on local subnet
- Ping machines on another subnet
ping www.google.com
and test our DNS setup in addition to our IP layer
A deeper look into block devices, LVM, and filesystems
- Block device? What's that?
- An array of bytes that can be read at an arbitrary offset
- So it's like RAM, except that reads and writes happen one block at a time instead of in 8-bit bytes, or various words of 16, 32, or 64 bits.
- And entire block must be read or written at once (a sector on a disk drive for instance)
- What block devices are attached to my Linux VM?
Look in/proc/partitions
- Quite a number are listed, one for each block device.
- Some commonly seen block devices:
- SCSI hard drives (
sda
). These include pretty much any hard drive that uses the SCSI command set: internal SATA drives from BestBuy, FibreChannel SAN LUNs, USB thumb drives, SAS disks from your server vendor, iSCSI arrays, etc. - Partitions on those drives (
sda#
) - CD or DVD ROM drives (
sr#
) - Metadisk/software RAID devices (
md###
) - Hardware RAID drives (
cciss/c#d#
) and partitions on those (cciss/c#d#p#
) - Device mapper (
dm-#
) - Device mapper has a number of modules. One implements LVM, another does disk encryption.
- SCSI hard drives (
- These devices can put together in interesting ways
- Let's have some tin foil hat paranoia.
- Imagine a server with two hard drives
- The physical drives are 1Tbyte SATA disks
sda
andsdb
. - The first partitions of each are
sda1
andsdb1
. These partitions are small, 512Mbytes sda1
andsdb1
are made into MD software RAID-1 mirrors, which is accessed asmd127
- A second partitions is created on each drive,
sda2
andsdb2
. These have the rest of the space on each drive, say 999Gbytes. - We're super paranoid, so these second partitions are encrypted. (cryptadm luksFormat used on
/dev/sda2
and/dev/sdb2
choosing a well-reviewed encryption algorithm and a large key size). We'll be able to use the plain-text versions of these partitions assda2_plain
andsdb2_plain
. - Now the
sda2_plain
andsdb2_plain
devices partitions can be mirrored, using the MD software RAID tools again.mdadm --create raid1oncrypteddisks --level=raid1 /dev/mapper/sda2_plain /dev/mapper/sdb2_plain
- The
raid1oncrypteddisks
device can be encrypted, choosing a different, but still well studied algorithm and a large key size) - The plaintext version of
raid1oncrypteddisks
, called something likeraid1oncrypteddisks_plain
- Which can then be used as an LVM physical volume.
- Which makes for a segue into the Logical Volume Manager layer
LVM, the logical volume manager
- Allows the sysadmin to create, resize, and remove block devices dynamically -- no reboot needed.
- Definitions:
- Physical volume: a disk drive (but it could also be a software mirror, or a RAM disk, or an encrypted device)
- Physical extent: a fixed size chunk of some disk drive like device that is then allocated to an abstracted logical volume. A physical extent cannot span more than one physical volume. Sizes range from 1024 bytes and up by powers of 2.
- Volume group: A collection of one or more physical volumes. On these physical volumes, extents may be provisioned into one or more logical volumes for use by other layers such as filesystems, swap space, virtual machine images, etc.
- Logical volume: a collection of logical extents
- Logical extent: a block of data that is mapped to one (or more if mirroring with LVM) physical extent somewhere inside the volume group. Logical volumes may be striped using extents from more than one physical volume if desired. The can be snapshotted, created, and deleted as needed.
- Hands on:
- Look what block devices we have listed in /proc/partitions
- add 2 10Gbyte thin provisioned logical disks to each of our lab VMs
- Look at kernel message buffer (
dmesg
and/proc/partitions
after disks have been added. Was a reboot needed to find them? - Decided whether to partition these new disks. GPT or MBR partition? If creating partitions, was a reboot needed?
- RedHat's documentation is quite good. See https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Logical_Volume_Manager_Administration/
Session 1
Introductions, get acquainted with students and their skill levels
Remote connections using SSH
disk and filesystem management
All about disks
disk interfaces (direct attached and network attached)
disk partitions, tools to create and manage them with Linux
disk based filesystems (ext2/ext3/ext4 family and others)
Logical volume manager
benefits of LVM
costs of LVM
LVM tools introduction
Session 2
configuration files
How to find what you're looking for
network setup
network interfaces
IP addressing
routing
DNS configuration and hosts file
Advanced network (if needed)
bonded network interfaces
iSCSI
What are initiators and targets?
find available iSCSI storgae
connecting your Linux system to a target
Log file locations and content overview
Install an RDP server on the Storehouse system
Session 3
Maintenance
RedHat support lifetime
RedHat Network
CU Boulder's RedHat Satellite server
Best practices
daily care and feeding of your Linux server
regular software maintenance
monitoring of system usage
unstructured Q&A