Managing the Game
By st0rage on Feb 02, 2008
Spring is almost here and it’s time to get in shape and get ready for the season. If you don’t get your base established, you can’t manage the game when you need to.
Speaking of managing the game, let’s talk a bit about how storage management is achieve in Solaris. This has not been the strongest play for Sun in the past, but the mindset and software have shifted over time. Solaris is in great shape, with several projects just finished, several that are imminent, and future investments that will pay large dividends.
Now, a good management scheme is only as good as its base. If you have complex software with many knobs, it’s very difficult to manage this complexity in management software. Management starts with development and user interface design. Similarly, there can’t be disparate management stacks to manage similar hardware components unless you are talking about fast-moving components such as disk drives, host bus adapters and the like. In other words: you have to consider the whole system experience, not just point products, but be realistic and add value when it matters.
There is also a difference between element management and distributed management. Element management means managing a single component, typically one directly attached to a host. Examples of element management in Solaris are fcinfo, which uses the FC HBA API. Distributed management is when you manage several components through one host. An example here would be Sun StorageTek Operations Manager Software, which provides Storage Area Network (SAN) management. This software discovers, visualizes, monitors, and provisions complex multi-vendor storage environments from a single console.
Standards can also play a big role in management by establishing an API for either element management or distributed management. This can pay huge dividends by offering:
• Information Independence
• Vendor Choice
• Easier ISV qualification
• Simple universal administration
• Easier migration
• Agnostic attach to applications, hardware, etc.
• Quicker time to market development/enhancement
The element APIs generally start in the kernel. These are important building blocks for larger scale management applications. A few of these useful APIs available in Open Solaris are:
• IMA – iSCSI Management API
• FC HBA API – Fibre Channel HBA API (Soon to be SM HBA API)
• MMA – Multipath Management API
To manage larger SANs, the prominent protocols use the Common Information Model which allows each resource to be instrumented in a common way, yet extended to cover the complete functionality of the resource. The CIM-XML protocol has been around for a number of years and is widely deployed, while the WS-Management is another protocol just now being deployed. Larger SAN management is achieved in many ways, but typically involves a CIMOM and, more recently, one with support for the Storage Management Initiative Specification at its base.
Our management strategy is to provide component management based on standards where possible, but also to bring in the Open Pegasus CIMOM, which comes with SMI-S. This involves adding providers to our current APIs (IMA, FC HBA and HDR), thus populating the SMI-S schema. This will allow choice for our customers through a standard interface that many distributed applications can use, including some of our own products…
No score yet, the season hasn’t started, but I think we have our base. Once the season starts, I’ll talk through a couple of targeted management schemes we have in place that have and will providing scoring opportunities.