- 2.1 Storage Hardware
- 2.2 Storage Attachment
- 2.3 Storage Software
- 2.4 Management Techniques
- 2.5 Assembling a Storage Network
- 2.6 Inside the Federated Management Architecture
- 2.7 Conclusion
- 2.8 Exercises
2.6 Inside the Federated Management Architecture
The first thing to keep in mind with FMA and Jiro is that no single piece of hardware or communication protocol is "the best" for a particular class of device. All the protocols and devices have a place and a need to fill. Direct attach storage is fast for a workstation user but unrealistic when placed in the context of an enterprise network that has hundreds of users accessing the shared data. Parallel SCSI architectures can deliver great bandwidth over a short distance for servers, but they do not address the flexibility that storage networks offer. Storage networks—specifically, SANs—can address limitations in DAS and parallel SCSI architectures but are more costly to implement. Unfortunately, the use of each type of device and software leads to a management challenge.
The realization that a variety of management styles exist in a storage network is the driving factor behind the Federated Management Architecture. FMA is an umbrella management architecture that allows heterogeneous storage resources to coexist without increasing the complexity of management.
To that end, FMA provides programmers with facilities for dynamic discovery and expansion of the software used to manage storage. It also provides a common architecture and services for use in building software components that manage software and hardware in the storage network. The architecture is built so as to provide component reuse at different levels.
Here's an example of how to use an SRM built with the Federated Management Architecture:
Coffee House Inc. owns a switch from switch vendor A, disk arrays from Sun Microsystems, and Sun Solaris and Windows NT servers.
A series of Jiro FederatedBeans components are deployed on the Sun Solaris machine and the Windows NT servers. These components manage resources that are physically attached to the machine, such as any direct attach storage, file systems, or volume managers. Components deployed on these systems also manage devices that have control points accessible to the machine but may not be capable of running a JVM for hosting a FederatedBean of its own. An example of this scenario is a fibre channel switch that has a port with a Web server for out-of-band management. The Jiro FederatedBean that manages the switch actually exists on the Sun Solaris machine. Calls to the bean are forwarded to the switch via the Web interface on the switch.
A second set of Jiro FederatedBeans components deployed on the servers adds policy-based management capabilities to the "pass-through" nature of the beans discussed in point 2.
A storage resource manager dynamically discovers the Jiro FederatedBeans components in the network and provides the status of the storage network and the policies that are running in the network. The user of the SRM can modify the storage network and policy rules from the SRM user interface.
Coffee House Inc. purchases a new disk array and attaches it to the fibre channel switch.
Because this disk array is from a new vendor (a cost decision on the part of Coffee House Inc.), a new Jiro FederatedBean is deployed to both the Windows NT server management domain and the Solaris management domain. The FederatedBean was supplied by the disk array vendor along with deployment instructions. 6 The SRM does not have to be used in this step unless it makes the installation easier than that of the vendor that provided the Jiro FederatedBeans. For example, the SRM may be able to recognize the new device in the network (through one of its own Jiro FederatedBean policy components) and download a Jiro FederatedBean from the vendor's Web site.
A Jiro FederatedBean policy on the Windows NT server and a similar one on the Sun Solaris server recognize the addition of a RAID device via an event from the Jiro FederatedBean managing the switch. The policies negotiate with each other based on predicted storage need. The "winner" then calls the Jiro FederatedBean responsible for the switch to allocate the array (zone) to the Solaris host. After zoning is complete, the policy calls the volume manager FederatedBean and the file system FederatedBean to make the space on the new disk array usable by clients.
In this scenario, the SRM software is merely a client to the many continuously running software components that manage the servers and connected hardware. You can have the SRM software take on many different forms—Web-based, application-based—by adapting the user interface rather than rewriting the software. Because Jiro FederatedBeans are remote objects, you can bring up the SRM from any location in the network for management of all storage resources that have Jiro FederatedBeans representations. You may be able to develop generic FederatedBeans for devices that do not have beans already built for them, depending on how well those devices fit to standards. For example, you would not have to build a FederatedBean for a device that exposes all control points via a standardized WBEM model.
With this scenario in mind, let's look briefly at what Sun's Java, Jini, and Jiro architectures can bring to the table in terms of programming environment, programming model, and architecture and design. This discussion is very high-level because the implementation of this discussion is the topic of the book as a whole.
2.6.1 The Java Programming Language
Simply put, creating management applications for heterogeneous environments would be difficult, if not impossible, without the Java programming language. The following strengths of Java are leveraged in creating a solution in the scenario described in Section 2.6:
Platform independence. The Coffee House scenario has two operating systems and processor architectures involved for servers: Windows NT and Sun's Solaris operating system. Because of Java's Virtual Machine, the differences between the platforms are nullified from a programmer's perspective.
Network capabilities. Java's distributed object technology, RMI, enables distributed object management by piggybacking onto Java's platform independence. The data streams passed to and from distributed objects on different operating systems and hardware architectures contain data that is formatted according to the JVM specification and not according to the underlying platform architecture.
Portable code. Java's remote codebase capabilities allow classes that do not exist in the space of one JVM to be loaded dynamically from a remote Web server. This makes implementation code extremely portable and dynamic; as long as interfaces are known at programming time, new implementations can be deployed during runtime of the system.
Simply put, Java is the most advanced platform-independent object-oriented programming language available. Every year Java becomes faster, more stable, and more feature-rich. Other object infrastructures could handle a heterogeneous distributed management environment, but there are no others that allow code to be moved over as wide of a range of operating systems and hardware architectures as Java. This is a critical point when you're looking at how to create a management environment that truly handles heterogeneous managed resources.
2.6.2 The Jini Platform
Jini combines with the distributed object capabilities of Java to create a truly dynamic service environment. An oversimplified description of Jini is to compare it to Web search engine services. Jini leverages the multicast network capability to discover lookup services (the search engine). After you've found a lookup service, you can construct a query to submit to the lookup service, and the lookup service returns network proxies to the services that fit the query. You can then use the remote service from the client to query data.
Because Java can move code to a client during runtime via the remote codebase, your management program can use a service that is found in a Jini lookup server that you may not have known about when you wrote your program. The disk array added in the Coffee House scenario can be installed, discovered by your client, and managed without the need to restart the management client or any of the servers.
Jini is also a well-behaved system. If a server were to crash, the Jini group would remove services that are no longer available using its landlord/lease mechanism (see section 5.3).
2.6.3 The Federated Management Architecture and Jiro
Even with Java and Jini available, the technology is still applicable to a very broad domain. Java can be used to solve virtually any computing problem, and Jini is a platform to create self-healing groups and federations of devices and services. The Federated Management Architecture defines specific services that are required to be available in a Jini group as well as behaviors of components that exist to manage resources. These services and behaviors are defined specifically to address the needs of the domain of management application programming.
For Coffee House, FMA defines the architecture of the components to represent the managed resources and also defines how those components should be deployed, where they should run in the network, and how they can be found in Jini. A specific example of how FMA ties into the Coffee House scenario can be found in the handling of the addition of a new disk array. Policies exist on both the NT machine and the Solaris machine. Upon entering the network, the disk array delivers an event for which both policy components listen. This event can be consumed by the first policy that receives the event, or the policies could simply observe the event and construct a separate negotiation mechanism. The event chaining and delivery mechanism that enables either behavior is defined by FMA.
Jiro implements the behaviors defined by FMA. The Jiro implementation also adds many helper capabilities and tools to ease creation and adherence to FMA.