EOF - Carrier Grade Linux
In January 2002, the Open Source Development Labs (OSDL, www.osdl.org) established the Carrier Grade Linux (CGL) Working Group. This initiative was intended to enhance the Linux kernel to achieve a highly available, secure, scalable and easily maintained open-source platform suitable for carrier grade systems.
Many companies joined the CGL initiative, and today the CGL is composed of member companies that work together contributing to the CGL requirement definition, helping current and starting new open-source projects to meet these requirements. Many CGL member companies already have contributed pieces of various technologies to open source to make the Linux kernel a more viable option for telecom platforms. CGL activities are providing momentum for Linux in the telecom space, allowing it to be an alternative to proprietary operating systems.
Gateways, signaling and management servers are the three main areas into which the CGL Working Group expects the majority of applications implemented on CGL platforms to fall. In addition to specifying the requirements, the Working Group also identifies existing open-source projects supporting the road map, implementing required components and interfaces of the platform. When an open-source project does not exist to support a CGL requirement, the Working Group launches or supports new projects to implement the missing functionality.
The scope of the CGL Working Group covers two main areas, carrier grade enhancements to the kernel and development tools. Kernel enhancements cover availability, security, scalability and reliability, as well as changes to interfaces for hardware, user-level code, application code and development and debugging tools. Software development tools covered by CGL include debuggers and analyzers.
The CGL Requirements Definition Version 2.0, released October 9, 2003, divides the requirements into the following main categories:
Clustering supports the use of multiple carrier server systems providing higher levels of service availability through redundant resources and recovery capabilities.
The security requirements aim at maintaining a certain level of security while not endangering the goals of high availability, performance and scalability. These requirements support the use of additional security mechanisms to protect the systems and provide special mechanisms at kernel level to be used by telecom applications.
Standards: CGL specifies standards to which compliance is required, including the Linux Standard Base, POSIX standards and a number of Internet RFCs.
CGL specifies platform requirements that support interactions with the hardware making up carrier grade systems. Examples of platform requirements include: hot insert, hot remove, remote boot support, boot cycle detection and support for diskless systems.
Availability requirements support heightened availability of carrier grade systems, such as improving the robustness of software components or by supporting recovery from failure of hardware or software. Examples include support for watchdog timer interface, disk and volume management, Ethernet link aggregation and link failover and application heartbeat monitor.
Serviceability requirements support the availability of applications and the operating system. Examples include support for producing and storing kernel dumps, dynamic debug of the kernel and running applications, platform signal handler and remote access to event logs.
Performance requirements support performance levels necessary for the environments a carrier grade system would encounter. Examples include support for application (pre) loading, soft real-time performance, kernel preemption and RAID 0 support.
Scalability requirements support vertical and horizontal scaling of carrier server systems, such as the addition of hardware resources to result in acceptable increases in capacity and throughput.
Tools requirements provide capabilities to facilitate diagnosis, such as the support for a kernel debugger, kernel dump analysis and the capability to debug multi-threaded programs.
Many individuals within the CGL initiative are active participants in the main-line Linux development community. In addition, the implementations providing the carrier grade enhancements to the kernel are open-source projects and are planned for integration with the Linux kernel. All of the enhancements are available from their respective project Web sites; please refer to the OSDL Web site for links.
As of January 2004, the CGL Working Group is developing CGL version 3.0. The group expects to release the final official version by October 2004. The participation in OSDL CGL is open to everyone. For more information, please visit the OSDL Web site.
Ibrahim Haddad, contributing editor to LJ, is a Researcher at the Ericsson Research & Innovation Department in Montréal, Canada.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide