Operating Systems

One of the topics all the major hardware manufacturers have been touting is competition for the structure of the next generation data center. There’s been a lot of sound and fury about “green,” as well as different degrees of virtualization—in the network, in storage systems, and in processor architecture and emulation. Naturally, the output of each vendor’s studies and marketing material tends to favor that vendor’s own proposed structure, but there’s a part missing from all the discussions: How does one actually deploy and manage a next generation data center in a way that’s measurable and can provide direct metrics on both technical operation and business value? Another problem these approaches don’t address is how we can understand well enough what we have in order to know how effectively it’s being used.

An interesting approach to this problem is in test in some of our research projects. The idea is to develop a model of treating the data center as a set of federated “service” providers. The concept is borrowed from some early 1970s research at Xerox PARC on modeling applications as network access points and providing a set of directory services to build relationships between objects, both hardware and software. This approach to data center design allows system managers and operations staff to use configuration data that can be incrementally assembled, then federated to provide a consistent overview of the operation and relationships of servers, storage, network allocations, applications, and business processes as they’re developed. This approach doesn’t require the global, monolithic Configuration Management Database (CMDB) approach currently maintained by the large system management vendors. Without that requirement, we can think about these federated components as a way to build application subsystems from discrete building blocks, and then compose the building blocks into larger and larger relationships.

A “service-oriented” approach implies a catalog or resolution capability to locate not only hosts, but also application instances. Services use a capability called multicast DNS (mDNS) to advertise themselves by name, which is resolved to a combination of host names and TCP ports by the mDNS server. The use of IP multicast allows applications to listen for different groups of applications with a minimum of network traffic; IP multicast traffic is designed to be sent once on a network segment but received by multiple destinations (it’s a common method used to deliver point-to-multipoint audio and video streams to multiple clients in a network-efficient manner).

Apple, and others, have latched on to this approach as a way to provide zero-configuration services via implementations of the Bonjour suite of service advertisement tools, and the independent UNIX and Linux implementation such as Avanti and the mDNS project to provide multicast-based announcements of local and distributed network services. mDNS is an open source implementation of the multicast DNS service.

These tools fit together to create one of the building blocks of an evolution to a new data center model. We need the capability to simplify the location of information and resources as workloads become more mobile and more dynamic in nature. The Linux implementations of these services are a great way to start providing the ability to publish and manage configuration and load information in a manner that can start treating individual systems, resources, and applications in a similar way as the self-identification that IBM added to most hardware devices a few years back. Once we know what we have to work with, we can start to think about smarter ways to assemble and connect it to solve a business problem.

From the Linux perspective, this kind of service-oriented approach maps well into the ability to have systems advertise their capabilities to the management and assembly infrastructure for larger composite services. We have the ability to publish usage, configuration, and available resources—a wide number of things that can deliver the data that a system management regimen needs to make decisions about what components can be assembled into usable data center services. It will be interesting to see what the system management product vendors can do with this capability. Much of what has been discussed in public seems to ignore the complexity of building a management infrastructure, but we’ll look at that in the next issue.