Flexible Initialization
The original o2cb.init script was very tied to the module set and configuration of the o2cb stack. We now need it to handle the classic o2cb stack and the new cman stack. As a side effect, we'll gain the flexibility to handle the heartbeat2 stack from SuSE.
Existing Limitations
The o2cb.init script has some locked-in limitations:
- An explicit list of modules to start.
- It cannot handle complied-in drivers.
It explicitly uses o2cb_ctl.
- It expects the existing heartbeat environment.
We need to lift or change these limitations to support cman.
Better Driver Loading
The original script had a hardcoded list of modules to load, and it always tried to load them. It would explode if the module was compiled in to the kernel. While this is just fine for the enterprise environments - we control them - it doesn't work well for mainline hackers.
The loading code has been changed to rely on starting the filesystems. There are two pseudo-filesystems that are used by the stack, configfs and ocfs2_dlmfs. If both filesystems are present, we know all the stack modules are loaded. Thus, we can check for them in /proc/filesystems. This check works whether the drivers are modules or compiled in. We let modprobe(8) do the heavy lifting for us when it comes to dependant modules.
In addition, we are much smarter about unloading configfs. If it's in use by someone else, we don't unload it!
Cluster Stack Configuration
The o2cb configuration in kernel can now be backed by the classic o2cb stack, the cman stack, or the heartbeat2 stack. However, we have to tell the startup code which one we're using. The o2cb.init script will now ask in the configure step. It stores the backing stack in /etc/sysconfig/o2cb or the equivalent.
During startup/shutdown of the stack, it uses this value to choose what drivers to load and how to initialize the stack state. More on that below.
Heartbeat Driver
The new kernel driver set supports multiple heartbeat methods. The classic method is o2cb disk heartbeating, and this is used when the classic o2cb cluster stack is configured. Both heartbeat2 and cman do heartbeating in userspace, and so there is a new user heartbeat method written by SuSE. This driver allows userspace programs to fill in node membership.
The o2cb.init script knows which heartbeat method to configure based on the stack configuration. During startup it will load the appropriate driver, and at shutdown it will unload it. When it checks for a live heartbeat, it can handle either method.
Bringing the Stack On and Offline
The classic o2cb stack uses the o2cb_ctl program to fill in node information and bring the cluster online. This also works for heartbeat2, as it requires the cluster configuration be mirrored both in heartbeat2 and in /etc/ocfs2/cluster.conf. This doesn't work for cman, as it stores cluster information in its own place. The cman configuration is dynamic, and is controlled by two daemons, o2cb_controld and ocfs2_controld. The new o2cb.init starts these daemons to bring the cluster online and stops them to bring it offline. The daemons must be live while a heartbeat region is active, so the region check described above is made before any daemon is stopped.
Compatibility
This init script should work just fine with the ocfs2 1.2 drivers. It can only work with the classic o2cb stack, but it will correctly configure that stack, mount the filesystems, and unmount them.