CU Norlin Library Linux training

From FnordWiki
Jump to navigation Jump to search

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.
  • 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 and sdb.
    • The first partitions of each are sda1 and sdb1. These partitions are small, 512Mbytes
    • sda1 and sdb1 are made into MD software RAID-1 mirrors, which is accessed as md127
    • A second partitions is created on each drive, sda2 and sdb2. 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 as sda2_plain and sdb2_plain.
    • Now the sda2_plain and sdb2_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 like raid1oncrypteddisks_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?
    • Put physical volume structures on the new disks:
      pvcreate /dev/sdb; pvcreate /dev/sdc
      - OR -
      pvcreate /dev/sdb /dev/sdc
    • Create a volume group using one of the new physical volumes:
      vgcreate --physicalextentsize 256M --verbose --metadatatype 2 trainingvg /dev/sdb
      - OR -
      vgcreate -s 256M -v trainingvg /dev/sdb
    • See some info on our new volume group:
      vgdisplay trainingvg
    • More info on our new volume group:
      vgdisplay -v trainingvg
    • Create a logical volume:
      lvcreate --verbose --size 1G --name mynamevol trainingvg
      - OR -
      lvcreate -v -L 1024M -n mynamevol trainingvg
      - OR -
      lvcreate -v -l 4 -n mynamevol trainingvg
    • Put a filesystem on it:
      mkfs.ext4 /dev/trainingvg/mynamevol
    • Mount it to make it usable by programs running on the system:
      mount /dev/trainingvg/mynamevol /mydir
    • Got an error message? Mounting a filesystem on a directory requires the directory to exist. Try this:
      mkdir /mydir
      mount /dev/trainingvg/mynamevol /mydir
    • How big is it?
      df /mydir
    • What is in it?
      ls -la /mydir
    • Need more room in there? It's a two step process:
      lvextend -L +5G /dev/trainingvg/mynamevol
      resize2fs /dev/trainingvg/mynamevol # will grow to size of block device by default
    • Is there more space now?
      df /mydir
  • Also demonstrate:
    • unmounting
    • shrinking filesystem
    • shrinking logical volume
    • removing logical volume
    • adding a physical volume to the OS installed volume group
    • renaming an in-use volume group (will require a reboot, single user shell, and some flying by the seat of the pants
  • Benefits of LVM:
    • Runtime flexibility
  • Costs:
    • Performance hit (not measurable unless handling major OLTP workload)
    • Additional complexity to manage
  • 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/

Let's set up a software RAID 5 device

  • Linux's software RAID layer is called "md". We talked about it a bit last week.
  • Every common RAID geometry is supported: RAID0 (striped), RAID1 (mirrored), RAID5 (stripes + parity), RAID6 (stripes + two parity)
  • So let's create a 3 disk RAID5
mdadm --create librhel15_raid5 --chunk 128 --level 5 --raid-devices=3 --run --name=librhel15_raid5 /dev/sdb /dev/sdc /dev/sdd
That was easy, huh?

Redundant networking

  • Whatever for?
    • UgradOps student pulled the wrong wire
    • switches failing (but that would never happen)
    • NICs dying (but, really, that would never happen)
    • More bandwidth (but, really, are you sure you're network constrained?)
  • General rules:
    • You'll want advice of your network team:
      • Do they care at all about simple link state failover connections to a server?
      • If they're a Cisco shop, do they like Etherchannel?
      • Do they prefer 802.3ad Link Aggregation Control Protocol (LACP)?
    • Measure network usage first
    • Let the hypervisor take care of it for you -- all VMs on that host will benefit
    • Put each leg of a teamed (bonded, aggregated) Ethernet interface on a separate physical card. This removes a single point of failure at the PCI/PCI-X/PCIe slot level.
    • On the network team side: put each leg on a separate line card (blade) in a chassis switch or a separate member switch in a stack (but first confirm the switch vendor supports this configuration for aggregated links)
  • Relevant RedHat documentation:
    https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sec-Using_Channel_Bonding.html
    https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-networkscripts-interfaces-chan.html
  • Linux kernel calls these things "bonded" interfaces and they are named bond# starting at bond0.
  • Make sure you have console access: High possibility of things going wrong here.
  • RedHat setup goes like so:
    • Create an /etc/sysconfig/network-scripts/ifcfg-bond0 reading like so:
DEVICE=bond0
IPADDR=128.138.154.222    # or as assigned by network team
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none   
USERCTL=no
NM_CONTROLLED=no
BONDING_OPTS="bonding parameters separated by spaces"
We'll get back to BONDING_OPTS shortly
  • Change /etc/sysconfig/network-scripts/ifcfg-eth0 like so:
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
NM_CONTROLLED=no
IP addressing info has moved from eth0 to bond0 and eth0 is now a slave of bond0.
  • BONDING_OPTS settings
    • Settings for the bonded (master) interface
    • For now, set it to "mode=active-backup primary=eth0 miimon=200". This will set up a failover-only bond, check the link status 5 times per second, and use over another slave interface if eth0 goes down.
  • On the console, run "service networking stop; sleep 5; service networking start" to bring the interfaces down, let things settle, then bring up the bond interface.
  • Check network connectivity with ping, traceroute, etc.
  • Check DNS resolution with "ping www.google.com"
Retrieved from "https://wiki.fnord.greeley.co.us/mediawiki/index.php?title=CU_Norlin_Library_Linux_training&oldid=648"