- More Network Computing, Please!
- Enter the Blade Server
- The Big Issue for Blade Servers: Management
- Towards Autonomic Computing
- Conclusion
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Big Issue for Blade Servers: Management
Currently, blades represent only a tiny fraction of the server market. Given the growing demands being placed on the data center, this situation is likely to change. Because data centers account for half of corporate IT budgets, this is potentially a very large market.
My own opinion about blade technology is that its success hinges on the availability of suitable effective, generic management technology. The telecom sector labors under the burden of non-interoperable management systems; it's essential that the same mistake not be made in the blade arena. This is particularly important in the data center, where there is a tradition of mixing and matching vendors, devices, and technologies.
Specifically, there is a need for comprehensive, vendor-independent blade server management systems. Interestingly, the requirements for blade server management are not dissimilar from those of network management [1] and include the following capabilities:
Facilitate the safe addition and removal of blades
Monitor the status of all blades
Provision a "service" across more than one blade
View the status of a multi-blade service
Interpret service-level blade events
Assure service levels across blades
Bill for blade resource consumption
Verify security levels across blades
Perform capacity planning for new and upgraded services
Let's take a brief look at these issues in the next few sections.
Adding and Removing Blades
Blade technology facilitates hot swapping of chassis blades. This has long been a telecom feature. (I recall working in a telecom company on the development of a PBX feature card for wireless telephony. While debugging the card, I needed to reboot it and pulled it from the live switch—an action that resulted in a few irate users whose calls were dropped. My defense was that it was a feature under development!) The management system should make cards safe for removal and insertion as necessary. If problems are occurring in the blade system, the management system should know about this by constantly monitoring the status, which should be reflected in some obvious fashion—perhaps color-coded GUI icons.
Blade Applications: The Role of Services
Online brokerages and Internet auction sites typically offer web-based front-end systems for traders. In this case, the service is composed of real-time (or near real-time) access to some combination of a web server and back-end database. Blade systems can be used here to aggregate user access into the back-end systems. This service is very important to the service provider, so provisioning and managing it in a virtualized fashion is a key requirement, particularly when the service involves many blades.
Service Manipulation
The ability to manipulate entire services rather than individual blade resources is a key management system feature. It becomes important to think about the service lifecycle, in which the service is initially conceptualized, designed, modeled, created, deployed, updated, and eventually retired.
After deployment on the blade servers, the manager wants to be able to monitor the overall service status. Hardware and software operate in the real world with service-affecting faults and bugs—any such events may have an effect on the service. Again, the network manager will want to see the effects—preferably before the service is affected; that is, she wants to ensure that the service remains operational.
Billing is always an important issue for service providers, so it's possible that the network manager may at some point want to be able to produce bills for blade resource use. Similarly, security of blade resources is important when blades are used by sensitive or mission-critical applications.
As the user population grows for blade-based services, the network manager will be faced with the problem of capacity planning. Again, if the service is virtualized across the blade resources and represented in the management system, the latter should provide a modeling facility in which the manager can carry out what-if tests, increasing capacity as required and verifying that the service is appropriately upgraded. Only when the modeling is complete would any changes be made in the blades.
Existing blade management systems don't fulfill many of these requirements, but it's important to keep them in mind prior to deploying the technology. In an ideal world, you should be able to mix-and-match blades from different suppliers and manage them all using a vendor-independent management system.
In addition, there are requirements that are specific to blade servers:
Backup and restore
Disk management
Patch distribution
License tracking
Virus checking
Antivirus software deployment
As for the service-level blade issues described earlier, the management system should facilitate these requirements.