Archive for the ‘linux-lvm’ Category

Graphing data obtained from the zyxel zynos ras interface in cacti

Monday, December 27th, 2010

After a brief IRC session on ADSL and noise levels with some former colleagues, I decided to graph the line quality of my ADSL connection using cacti. This blog post will briefly explain how to graph any data that can be obtained from the zyxel zynos ras interface. The data will be graphed using cacti and this blog assumes that a working cacti installation already is running.

The task at hand can be split into two:

  1. Obtaining data from a zyxel device (a P-2602R in my case)
  2. Graphing the data in cacti

Obtaining data from a zyxel device

I attacked the first problem by doing an snmpwalk of the zyxel device. A normal consumer zyxel ADSL router like the P-2602R will export two MIB trees:

  1. The normal iso.3.6.1.2.1 tree
  2. The private iso.3.6.1.4.1.890 tree

This can be seen by doing a normal SNMP walk of the device:

edison%  snmpwalk -v1 -c public 192.168.1.1 | head -2
iso.3.6.1.2.1.1.1.0 = STRING: "P-2602R-D1A"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.890

A quick browse of the two MIB trees made it clear that not all values and parameters inside zynos was exported through SNMP.  I had to find another way of obtaining the values that I needed.

Besides utilizing SNMP one, can make a telnet session to the zyxel device, whereby you end up at a RAS prompt. From there you can interface and control a zyxel device in great detail. You will probably need a password for this to work. Living in denmark, having telenor as my ISP,  it is actually fairly easy as I, as  a customer, has access to all the information needed, ie. ipaddress of the ADSL router, the password and port information. Using this information, I logged into the router

telnet 192.168.1.1 23023
Trying 192.168.1.1…
Connected to 192.168.1.1.
Escape character is ‘^]’.
Password: **********

Copyright (c) 1994 – 2008 ZyXEL Communications Corp.

ras>

From there it was fairly easy to find the information that I was looking for

ras> wan adsl linedata near
noise margin downstream: 22 db
output power upstream: 15 db
attenuation downstream: 12 db

Now I just needed be able to do this automatically. I used the unix tool expect in the form of the nice and easy to use Expect.pm perl module. After 15-20 minutes of coding, I ended up with a little script that will fetch whatever values from the zynos ras prompt your heart desires in one go. Example usage of the script (XXXXXXX denotes the secret password)

edison% ./query_zynos_ras.pl 192.168.1.1 23023 XXXXXXXX "wan adsl  linedata near" "noise margin downstream:" "attenuation downstream:"

noise:22 attenuation:12

Graphing the data in cacti

Now that the data collection had been scripted the data had to be graphed in cacti. This involved defining

  • a data input method
  • a data template and
  • a graph template.

Quick and dirty screendumps on how to do it:

data input method

data template

graph template

After a day or so, you get a graph like the following

From the graph I could see that my telephone line is very stable and that I should be able to get far better speeds if my current employer would pay telenor to provide it to me.

Fixing dying ssh connections through iptables based firewalls

Wednesday, December 22nd, 2010

I recently came across a setup where my ssh connections were torn down when inactive. This is a great nuisance for a sysadmin. The reasons are quite well known. Out of the box, the Linux iptables code will tear down/close inactive TCP connections after 30 minutes of inactivity. The TCP implementation in the Linux kernel however, normally default to a TCP keep-alive timer of 120 minutes.

Thus the iptables code will take the ssh connection down one and a half hour before the TCP stack starts to try to keep the connection alive. Not very handy to say the least. To remedy the situation and keep your ssh sessions alive even though the are inactive, a possible solution could be to lower the Linux TCP keep-alive timer to ie 15 minutes. You would do that with

echo 900 > /proc/sys/net/ipv4/tcp_keepalive_time

All done. Not rocket science at all, just a little useful piece of information.

About growing logical volumes, md devices, partitions and filesystems in Ubuntu 10.10

Monday, November 15th, 2010

Recently I found myself in a situation, where I was running out of space in my server. Luckily for me, the disks was not 100% utilized. On the positive side, that meant, that I had the possibility to extend my system without buying new hardware. On the negative side it meant that I had to fool around with my precious data. Normally I do this for a living, but on my job it is just customer data. In this case we are talking about pictures of the kids and wife….. Much more important stuff for sure :-)

So my setup

  • / mounted as an ext3 fs on top of an logical volume (LVM2) called lvroot in vg000
  • /boot mount as an ext3 fs directly on /dev/md0
  • vg00 has one physical volume called /dev/md1
  • /dev/md0 is a RAID1 device on /dev/sda1 and /dev/sdb1
  • /dev/md1 is a RAID1 device on /dev/sda2 and /dev/sdb2

Here is the business case: both /dev/sda2 and /dev/sdb2 was not fully utilized. /dev/sdb2 had 67GB unused and /dev/sda2 had around 250GB unused. That meant that I could resize / with 67GB up front, for free!

I startet out with this situation

root@edison:~# df -k /
Filesystem             1K-blocks      Used Available Use% Mounted on
/dev/mapper/vg000-root 240149008 232617156   2652288  99% /

So how do you do this, in an easy, controlled way, without taking time consuming backups of hundres of GB (I do make backups, so it is very easy for me to write this ;-) )? You can do it like I did below.

<DISCLAIMER>This is best-effort, free of charge information.  If you end up breaking your system into several pieces, it is your responsibility. I can and will not be held liable. You get to keep the pieces yourself! That will hopefully teach you not to trust ‘expert advice’ from some random internet place run by a random danish guy.</DISCLAIMER>

That said. Lets do some storage work

# First I fail /dev/sdb2
mdadm --fail /dev/md1 /dev/sdb2

# Then I remove /dev/sdb2 from the running config
mdadm --remove /dev/md1 /dev/sdb2
# Then we delete and recreate /dev/sdb2 with a larger size.
# Do a print beforehand to see the "before" values
fdisk /dev/sdb
Command (m for help): p

Disk /dev/sdb: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xa286eb78

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          26      208813+  fd  Linux raid autodetect
/dev/sdb2              27       30400   243979155   fd  Linux raid autodetect
# delete it
Command (m for help): d
Partition number (1-4): 2
# recreate with larger size and same type
Command (m for help): n
Command action
 e   extended
 p   primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (27-38913, default 27):
Using default value 27
Last cylinder, +cylinders or +size{K,M,G} (27-38913, default 38913):
Using default value 38913
Command (m for help): t
Partition number (1-4): 2
Hex code (type L to list codes): fd
Changed system type of partition 2 to fd (Linux raid autodetect)
# Write it
Command (m for help): w

If you are so lucky that you are not using the device for anything else (ie booting), the kernel can reread the modified partition table on the live system. If the system do use the device for something, you have to reboot the system. Which I had to do. Which I then did… By issuing the command:

reboot

When the server came back up, I assembled the /dev/md1 device again and waited for a resync. I speeded up the resync quite significantly by issuing the echo commands, which basically just tell md that it has to work as hard as it possibly can.

# Assemble again
mdadm --add /dev/md1 /dev/sdb2
# Speed up rebuild process
 echo 900000 > /proc/sys/dev/raid/speed_limit_min
 echo 900000 > /proc/sys/dev/raid/speed_limit_max
# watch status, eat pizze, drink a beer
watch cat /proc/mdstat

When the resync was done, I did it all over, replacing /dev/sdb2 with /dev/sda2.  After that,  I had grown the underlying partitions on my two drives, but both md and lvm had not noticed anything.

I made sure everything worked fine  and went onto the  next step – growing an md device on the fly.

# See current md device stats
root@edison:~# mdadm -D /dev/md1
/dev/md1:
 Version : 00.90
 Creation Time : Sat Jul 31 16:45:08 2010
 Raid Level : raid1
 Array Size : 243979072 (232.68 GiB 249.83 GB)
 Used Dev Size : 243979072 (232.68 GiB 249.83 GB)
 Raid Devices : 2
 Total Devices : 2
Preferred Minor : 1
 Persistence : Superblock is persistent

 Update Time : Mon Nov 15 20:16:27 2010
 State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
 Spare Devices : 0

 UUID : f510bad0:59d990c1:19dfcc76:62eb3300
 Events : 0.204498

 Number   Major   Minor   RaidDevice State
 0       8        2        0      active sync   /dev/sda2
 1       8       18        1      active sync   /dev/sdb2

# Grow the device to the max - took about 1-2 seconds, but see below
root@edison:~#  mdadm --grow --size=max /dev/md1
# Recheck the device stat.
root@edison:~# mdadm -D /dev/md1
/dev/md1:
 Version : 00.90
 Creation Time : Sat Jul 31 16:45:08 2010
 Raid Level : raid1
 Array Size : 312359744 (297.89 GiB 319.86 GB)
 Used Dev Size : 312359744 (297.89 GiB 319.86 GB)
 Raid Devices : 2
 Total Devices : 2
Preferred Minor : 1
 Persistence : Superblock is persistent

 Update Time : Mon Nov 15 20:17:21 2010
 State : active, resyncing
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
 Spare Devices : 0

 Rebuild Status : 78% complete

 UUID : f510bad0:59d990c1:19dfcc76:62eb3300
 Events : 0.204503

 Number   Major   Minor   RaidDevice State
 0       8        2        0      active sync   /dev/sda2
 1       8       18        1      active sync   /dev/sdb2

Notice how the drive went into sync state. Looking at mdstat confirms that. You can use the device before the mirroring is done. … or you can play it safe and wait. I decided to go ahead and use it before the sync was done. Living on the edge … this is not work. Only something your wife will never forgive you for ;-)

root@edison:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1]
[raid6] [raid5] [raid4] [raid10]

md1 : active raid1 sda2[0] sdb2[1]
 312359744 blocks [2/2] [UU]
 [===============>.....]  resync = 78.6% (245745600/312359744)
finish=21.2min speed=52265K/sec

md0 : active raid1 sdb1[1] sda1[0]
 208704 blocks [2/2] [UU]
unused devices: <none>

Next step. Making lvm aware of the change. Quite easy actually:

# Before
root@edison:~# pvdisplay /dev/md
 --- Physical volume ---
 PV Name               /dev/md1
 VG Name               vg000
 PV Size               232,68 GiB / not usable 832,00 KiB
 Allocatable           yes (but full)
 PE Size               4,00 MiB
 Total PE              59565
 Free PE               0
 Allocated PE          59565
 PV UUID               saiFOT-Dw2O-OnVv-rA4b-wZG3-OQHN-fFD1w

You then issue an pvresize on the pv  like this

root@edison:~# pvresize /dev/md1
 Physical volume "/dev/md1" changed
 1 physical volume(s) resized / 0 physical volume(s) not resized

And you end up with

root@edison:~# pvdisplay /dev/md1
 --- Physical volume ---
 PV Name               /dev/md1
 VG Name               vg000
 PV Size               297,89 GiB / not usable 2,62 MiB
 Allocatable           yes
 PE Size               4,00 MiB
 Total PE              76259
 Free PE               16694
 Allocated PE          59565
 PV UUID               saiFOT-Dw2O-OnVv-rA4b-wZG3-OQHN-fFD1wI

We are getting there? Now onto extending the volume. First peek at the current sizes/free space

root@edison:~# vgdisplay vg000
 --- Volume group ---
 VG Name               vg000
 System ID
 Format                lvm2
 Metadata Areas        1
 Metadata Sequence No  4
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                1
 Open LV               1
 Max PV                0
 Cur PV                1
 Act PV                1
 VG Size               297,89 GiB
 PE Size               4,00 MiB
 Total PE              76259
 Alloc PE / Size       59565 / 232,68 GiB
 Free  PE / Size       16694 / 65,21 GiB
 VG UUID               rL7lfw-H2FC-4ala-KVV3-bLIA-MbA9-co2n1O
root@edison:~# lvdisplay /dev/vg000/root
 --- Logical volume ---
 LV Name                /dev/vg000/root
 VG Name                vg000
 LV UUID                uDPn6b-AvyO-xH2n-zpXm-n0Xt-5g5n-aSdu4C
 LV Write Access        read/write
 LV Status              available
 # open                 1
 LV Size                232,68 GiB
 Current LE             59565
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           251:0

Then extend the volume

root@edison:~# lvextend -l 76259 /dev/vg000/root
Extending logical volume root to 297,89 GiB
Logical volume root successfully resized

One step left – resize the live filesystem

root@edison:~# resize2fs /dev/vg000/root
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/vg000/root is mounted on /; on-line resizing required
old desc_blocks = 15, new_desc_blocks = 19
Performing an on-line resize of /dev/vg000/root to 78089216 (4k) blocks.
The filesystem on /dev/vg000/root is now 78089216 blocks long.

How much did I gain:

root@edison:~# df -k /
Filesystem              1K-blocks      Used Available Use% Mounted on
/dev/mapper/vg000-root  307454080 232621080  68588172  78% /

Almost a walk in the park. I did actully run into a problem during this procedure. When I removed /dev/sdb2, grub would not reboot. Instead it gave me a grub rescue prompt.  I overcame this booting a rescue CD, starting up the system using that. I then added /dev/sdb2 into /dev/md1 from the rescue cd, waited for the mirroring and and rebooted again. When I did the same for /dev/sda2, grub was happy all along?! I have not bothered to figure out why grub misbehaved, I just put grub down as being like a teenager: unreliable and causing problems for no obvious reason ;-)