Friday Feb 15, 2008

Open Season

The STK 5800 has open-sourced the code base to three different open source communities:


This includes all of the source code as well as the XAM VIM associated with the XAM interface that enables the standard interface for the appliance.  It doesn’t include the GUI or hardware-specific code, but the guts of the box and the client library code are included.

What can you do with this? 

You can run it, modify it, and contemplate the future of storage that is a very different paradigm from what we know today:

  • Reliable – Long-term archive, calculated to have a mean time to data loss of over 2 million years!
  • Scaleable – Add boxes on the fly without losing performance, in fact you are adding processing nodes, with each additional node sharing the overall task load by design.
  • Manageable – No system administration tasks necessary when adding new cells, no provisioning, no zoning, etc.
  • Native metadata and query capable – Built-in database allowing on-board query of metadata with user-defined schema, no separate database or compute power required.
  • Built on OpenSolaris

Try it, it’s a new play that matches well with the amount of fixed content that is coming our way.

Score and hat trick.

Saturday Feb 02, 2008

Managing the Game

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
•    Interoperability
•    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.




« September 2016