The OSDL Carrier-Grade
is slowly working toward making Linux suitable for
high-stakes telecommunications deployments. To that end, the group has
been working on a set of requirements that Linux must meet before it is
suitable for such use. The version 2 specification is, with this
of the CGL
clustering requirements, now complete. The full documents are available on
the project's web site. For the busier people among us, here is a quick
summary of some of the kernel-oriented requirements.
- Persistent device naming; a device should have the same name
regardless of how many times it has been connected and removed.
- Live software upgrades including kernel upgrades; it should
be possible to put in a new kernel with less than a minute of downtime.
The kexec patch should be helpful in this regard.
- Multi-node volume management that works across a cluster.
- Enhanced panics; it should be possible to configure what
happens when the system panics, chosing between halting, rebooting,
power-cycling components, etc.
- Fault injection, allowing the simulation of hardware and
- Page flushing, similar to that provided by the fsync()
system call, but under the control of the system administrator rather
than the specific application.
- POSIX timers, presumably like those currently found in 2.5.
- User-space semaphores and spinlocks; the 2.5 FUTEX capability
should take care of this one.
- Low-level asynchronous events in a scalable manner - like the
2.5 epoll() capability.
- SVR4 streams, required by some applications. "Keeping it
separate from the base kernel ... also would be the prudent thing to
do, as providing streams in the kernel got an unfavorable reception in
the past in the LKML."
- Linux security module support as found in 2.5.
- IPSec for IPv4, also as found in 2.5.
- DRM stuff, such as checking binaries for a signature before
- Atomic checkpoint support which, among other things, allow
services to be quickly moved across a cluster if a node fails.
- Failing node isolation so that a confused cluster node cannot
- Cluster messaging which offers "better quality of service than
TCP/IP." Latency is of particular concern.
- Storage replication over the network. Multipath storage access
is also required.
All together, it is a lengthy list which will not be fully supported by
Linux for quite some time yet. Knowing where you want to go is always an
important first step, however.
to post comments)