My setup is as follows:
The stores can be managed on either of the two cluster hosts, and usually this results in a splitting of the load. The first requirement was, of course, to enlarge the RAID store. That was easy as mdadm. Second was to resize the two logical volumes that are used as backing stores for the DRBD devices, via LVM. Next, DRBD had to be told to resize each volume, which predictably caused a resync event to occur. Once that was finished, it was time to notify the initiators.
This is where a little trickery had to take place. So far I've not really found anything that made it easy to tell ietd to "rescan" itself or to otherwise realize that its underlying target devices might have changed their sizes. About the only thing I could really find was to basically remove and re-add the target, or restart it if you will.
Not really a fun idea, but at least Pacemaker gave me an out. Instead of shutting down each target, I migrated each target and then unmigrated it back:
crm resource migrate g_iscsistore0
crm resource unmigrate g_iscsistore0
It's important to realize that you must wait for the migration to actually complete before un-migrating. The un-migrate is used to remove the constraint that was automatically generated to force the migration. This effectively causes the target restart I needed, and because the cluster is properly configured no initiators realized the connection was ever terminated. This was important because the targets are very live and it's not easy to shut them down without shutting down several other machines. This will probably be a problem for me in the future when I go to upgrade both the VM cluster that relies on these stores, and the storage cluster that serves them, to a newer release of Ubuntu Server.
In the meantime, I have now effectively resized the targets, and the next step is obviously the initiators. I have this script to check for a resized device by occasionally asking open-iscsi to rescan:
rescan-iscsi.sh
#!/bin/bash
/sbin/iscsiadm -m node -R > /dev/null
This is actually set up as a cron job on the initiators, to run every 15 minutes. By now all the machines in the cluster should have recognized the new device sizes. I can now perform the resize online from one of the initiators:
tunefs.ocfs2 -v -S /dev/sdc
The resize should be transparent and non-interrupting. It only took a few minutes for each store to complete. I now have two 500G iSCSI targets, ready for more data!
One thing I'd really like to do in the future is have my initiators NOT use /dev/sd? names. I'm not quite sure yet how to do that. I have run into problems where smartd would try to access the iSCSI targets via the initiator connection and cause the SAN nodes to die horrific deaths. Not sure what that's about, either.
No comments:
Post a Comment