I was advised the other day that a certain manufacturer was adopting a rather interesting model for Fibre Channel over Ethernet CNA licensing.  Rather than simply purchasing a FCoE CNA with all the features (10GbE, iSCSI, and FCoE) turned on, they were going to adopt some sort of staggered licensing model that put each of those features as an option that you could license (and pay for) at a later date.

When I read this, the analogy that sprung to mind was one of, well, cake.  (I’m not a foodie, I just tend to think abstractly of food.) How many people go to a bakery and buy a plain cake that isn’t frosted and that has a payment plan against it?   You’re going to buy a cake that fits with the mindset of what a cake should be; that is, something that is complete and “ready to eat.”  Additionally, you’re probably not going to be interested in a plain cake where the end cost is greater than a pre-frosted cake!  Why would you buy something that required an order of magnitude more effort to get to a final, workable order?  You’d consider someone who bought into this idea as somewhat of a lunatic.

Expanding the analogy into the FCoE space, anyone can cobble together an FCoE solution.  Gen1 CNA products pointed this out.  You mux together a series of ASICs that were designed for specific purposes and pray that the end result justified the means of integration.  This “vanilla cake approach” is serviceable, for sure, but ugly.  Taking it even further, you could technically run the FCoE stack as software-only and get a similar result, albeit probably not what you expected by way of performance.  The point here is that the maturity model on Gen2 CNAs puts the cake and icing together in a rather pleasing and edible package  versus how Gen1 CNAs glommed everything together. Why on earth would you want to split that up by separately licensing features?!?

The point is, just like the plain vanilla cake, you buy the CNAs with the expectation that it will work for whatever you put it to use for.  You don’t extraneous crap that adds little to the value proposition of FCoE (or any sort of storage/communication fabric for that matter). You want a product that works from the onset, thatyou don’t have to worry about another CapEx consideration a year into the implementation process.  When you buy a CNA, you want the entire cake (and preferably at a price point that doesn’t require a 2nd mortgage).

I really do respect this particular manufacturer and I know they’ve spent a lot of time making sure everything works together.  They have an amazing commitment to quality but  I just am puzzled by this apparent aberration in the CNA market.  Am I missing something here?

Comments welcome.

If you follow me on Twitter at all, you’ll know that I’m a big fan of Qlogic.  I appreciate the functional simplicity of what Qlogic designs encompass as well as the “get business done” attitude that they bring to their switches, HBAs, NICs, and CNAs.  Imagine my happiness, then, when I got ahold of one of their latest “edge” fibre channel switches, the SANbox 5802V.  The SANbox 5802V follows the typical edge-switch formula: 20 SFP ports for either 4Gb/s SFPs or 8Gb/s SFP+, 4 stacking ports that default at 10Gb/s Fibre Channel connection and can be upgraded to 20Gb/s FC when additional bandwidth is needed, a serial and IP-based management port setup, and dual redundant power supplies (the 5802V ships with 2 PSUs; the 5800V model ships with only 1).

SANbox 5802V

Specifications

As I listed above, the quick specs on the 5802V switch are:

• 20 ports of SFP/SFP+ FC connectivity for 2, 4, and 8Gb/s FC connectivity (8 standard; licensed in 4 port increments)
• 4 ports of Xpak ISL/Stacking ports that run at 10Gb/s (std) or 20Gb/s (optional)
• Stacking of up to 8 x 5802 switches for an aggregate port count of 160 ports
• Serial, IP, and in-band FC management capabilities
• Dual redundant hot-swap PSUs (5802V only) or single, chassis cold-swap PSU (5800)
• 544 Gbps chassis bandwidth (no port is oversubscribed; stark contrast to Cisco MDS series)
• 1 Rack unit in height

Front Panel Overview

The SANbox 5802V is a relatively understated piece of hardware.  One of the first things you see are the rather sizable stacking ports on the right hand side of the switch.

Rather than impinge upon the total port count for ISLs and potentially running into bandwidth issues, Qlogic chose to dedicate ports for ISL and stacking.  Each of these stacking ports utilizes a propietary Xpak connector (seen below) that allows the 5802V to communicate via 10Gb/s Fibre Channel as an ISL/stacking protocol.  These Xpak connectors ship with each switch (just 1 connector) and using 2 of these connectors nets a channel that is 20Gb/s in total.  Optionally, you can purchase a licensing upgrade that will turn each of these ports into a 20Gb/s pipe.  With only two switches, your ISL could scale from 20Gb/s to 40Gb/s without having to take away ports from your storage or hosts. This allows you to scale your interswitch traffic on demand without additional ISL or Fabric licensing costs.

XPak Connector

Moving over to the left side of the switch, we get to the management ports.  Qlogic provides both a serial connection as well as a gigabit ethernet based management ports along with a series of LED lights noting power on, heartbeat, and maintence button (recessed so that you don’t do something inexplicably stupid).

Management Ports

Finally, we’ve got the front end data ports which feature port status and link activity lights as well.  These can be helpful for determining whether or not links are active (in case you didn’t already know via SNMP traps or array/host reporting) as well as link activity (helpful for determining path management activity).

SANbox 5802v FC Ports

Back Panel Overview

The back panel of the 5802V is rather simple.  Dual hot-swappable power supplies that feature status lights to quickly determine online/offline status.  Again, handy if you’re in the data center for those quick rack surveys that we all do.

Power Supplies

It’s worth noting here that the 5800 features a single, embedded power supply that requires switch servicing if the power supply fails.

Next steps

In additional articles, I’ll be diving into the interface of the 5802V to show you some of the cool features that make this, in my humble opinion, the class-leading departmental/edge fibre channel switch.  Stay tuned, you’re not going to want to miss this!!

For more information on the SANbox 5802V, please visit Qlogic’s website here.  Any comments or feedback on what you want to see, let me know….here’s a teaser image for part 2…

SANBox Gui

Related articles by Zemanta

• QLogic gets another CNA kiss from IBM (theregister.co.uk)

In my first post on policy, i tried to show what policy’s influence would be like from a top-level standpoint. We see that policy can start from a localized array standpoint and “fix” performancing or hotspot issues based on key LUN migration technologies (like EMC’s FAST promises to do; Compellent already does this) while allowing business processes to continue “unharmed.” To a certain extent, the LUN migrations of yesteryear were an act of policy, if only to show the level of manual involvement required in order to manage a SAN. What I’d like to look at today is the concept of extending policy BEYOND a localized resource or array and looking at its impact in a global storage environment.

Why use Policy?

As i’ve noted numerous times, there is a time and a place to staff up to handle data challenges but there’s also a time to look at the inherent inefficiences of processes and procedures that are implemented in a data centre. The overarching goal here is to help the business succeed, not fetter it with burdensome management workloads and complex architectural banalities. (yes, folks, I came up with that phrase myself…I AM a word-smith. ) Net result for policy enactment via some level of automation is a decrease in the amount of time to market for internal/external product, a decrease in the provisioning and SAN/NAS performancing routines, as well as a “watchdog” that tracks activity (or whatever metrics you’re enacting policy on) and can implement change.

Where Policy is going

Policy is, with notably few exceptions, relegated to on-array management and utility tasks. FAST v1, for example, is siloed to an array. Same goes for Compellent and other competing technologies. While this is good for tasks and single-array companies, it doesn’t take into consideration the other dependencies that rely on extant data to complete. Again, if the array itself is unaware of anything but the data that it manages, it will only act along that parallel, not in cohort with other systems. We’re definitely seeing an emergence of this awareness, most notably (to me, at least) the CLARiiON CX4 “VMware-aware” FLARE 29 operating system.  Not only does FLARE 29 give you bottom-up visibility to the VMware ESX host layer, it also goes to the host dependency tree and looks at the virtual machines running within them. Further, anytime a LUN is added to a storage group, it automatically rescans against the ESX host’s attached HBAs to allow these new luns to be recognized. That level of automation, while perhaps small and insignificant, cuts down the time to provision and report against the physical ESX host quite dramatically. The policy behind this is rather simple: if a LUN is added to a storage group and the hosts are VMware ESX based, then force bus rescan. Simplistic but powerful. This level of awareness, then, is the next baby-steps for policy-based array development.

Taking it a different direction, EMC’s Atmos product has approached policy with the understanding that nothing is ever done in isolation. In a global economy with global IT infrastructures, it makes sense to understand your data in a global fashion and enact change in the same way. Atmos’ policy engine, then, is tuned both at an installed level (e.g. for our product that sits on-premises) as well as from a distributed level. Let me give you an example of this (please be kind…).

Say your company has 3 different locations across the United States and Europe (San Franscisco, Boston, and London). In each of these offices, you’re generating massive sets of unstructured data that need to be protected and available to all within your company. Not only that, but due to international policies/law, some of these documents cannot be shared across the entities but still need the same level of protection and availability. With Atmos, you can set policies that dictate data flow based on any number of criteria (such as, document extensions, origin, etc.) and set replication levels against these objects to ensure data dissemination. Let’s assume that I created a Word document called “Chris Evans – CV.doc” in London and I needed to ensure that it was accessible throughout the entire company. I could set my Atmos data policies to push asynchronous copies of the CV.doc to Boston and San Fransisco on ingest as well as ensuring that a copy was available on Atmos Online. To kick things up another notch, I can enable this policy through both the central administration portal as well as through my document processing application (provided they’ve integrated the Atmos API). That level of flexibility between systems is key to moving to a private or hybrid cloud model.

Conclusion

The net result of policy-based storage engines becoming more and more critical to the success of a business is not to be overlooked. There are definite areas of overlap, perhaps, when looking at data management policies but there’s nothing to prevent layering global policies on top of  localized array policies.  The result of that symbiotic relationship would allow for a fine-tuned global data management practice and that’s nothing to sneeze at. So, where are you going with policy?  what roles/benefits do you see in your organization for policy? Let me know!

As many of you may know, I work for EMC’s Cloud Infrastructure Group as part of the Atmos solution team. In this role, I’ve been blessed with getting a closer look at where the future of cloud storage is going as well as some of the drivers that will get it there. In this post, I’d like to talk a bit about policy and how this will shape the future of storage. I’m going to keep this as abstracted from product as possible, but where appropriate, I’ll try to show you how products are implementing this technology TODAY.

What is Policy?

By definition, policy is “[an] action or procedure conforming to or considered with reference to prudence or expediency” (dictionary.com for that definition).  When viewed in the context of storage systems and management, policy, then, is the actions (scripted or otherwise) that influence data to provide for retrieval, performance, or manipulation by systems.  In other words, policy is an engine that manages data from start to finish.  Why this is important requires us to look at what the typical management stack looks like today.

Data is created by users accessing programs that are tied to physical and virtual resources.  This generated data is then processed and stored by the programs and their underlying storage I/O layers (LVMs, hypervisor I/O stacks, etc.) onto some sort of storage device (SAN, NAS, DAS, etc.) where it sits until next access.  In essence, once data is created it is considered to be “at rest” until it is next accessed (if ever).  Within this data generation and storage continuum, the process is fundementally simple as generated data is put directly to storage.  However, if the data continues to sit in the same place endlessly, it’s typically inefficient to retrieve and access.  Managing this data was typically a manual process where data, LUNs, and their topologies had to be moved around using array or host-based tools to provide better “fit” for data at rest or data accesses for performance.  This is where policy steps in.

Policy uses hooks into data (also known as metadata) in order to enact controls.  Please see this post for more detailed explanation of metadata.

Why use Policies?

If the previous example shows anything, it’s that the management of data is fundementally…well, boring and manual.  Policy provides a method of controlling the stack of data ingest AND data management while allowing business to continue to generate, retrieve, and manipulate data.  For example, a simple policy that could be enacted against data could be as follows:

if data < 14 days old, store on EFD drives, LUN 11; if > 14 days old, store on SATA drives, LUN 33

Obviously, that’s a high-level abstraction of what the actual process for data control would look like but drives the point home.  What used to be a manual LUN migration policy to “performance” or “store” data now is set based on a logical control structure that can be automagically enacted on the storage system itself.  A working example of this type of policy can be seen in the tiering provided by Compellent and EMC’s FAST systems for storage management.  Pretty cool, huh?

An alternative method of control that isn’t necessary tied to the storage array is the recent introduction of VMware’s Storage DRS (Dynamic Resource Scheduling) which is enacted against the storage I/O stack of VMware’s vSphere hypervisor.

The Future of Policy

Obviously, my examples are very simplistic in nature but hopefully, they make the policy technology somewhat more accessible.  As far as policy futures are concerned, this is where storage technologies (and even host process management) will be going.  In the future, simple policy creation and enforcement will be a necessary part of storage pool creation and integration as well as the ongoing maintenance and support of storage arrays.

As always, feedback is welcome!

edit: 9/21/09: removed a mis-aligned reference to Atmos storage policy.

Related articles by Zemanta

• VirtenSys virtualises RAID controllers (theregister.co.uk)
• EMC demos cloak of storage invisibility (theregister.co.uk)
• Cluster Migrations using Open Migrator-Rolling with my Demons (virtualtacit.com)

This was filmed Wednesday, September 2nd. Enjoy!

Yup, I’m at it again.  This tech minute recording was taken yesterday (September 1) and features the wonderful talents of Chad Sakac and Chris Hoff!  Enjoy!

Just a video from the Cisco Tech Minute filmed on Monday, August 31.  Enjoy!

One of the principle points of contention within the cloud storage space is what to do with metadata (literally: “data about data”).  There are several schools of thought regarding how metadata should be presented, protected and optimized but for the sake of this post, I’ll just tackle 2 of them.  These two thought processes are: (a) metadata appended directly to the objects that they represent and (b) metadata separated from the object and stored separately in a database or other type of referencable system object.  Let’s unpack some basic advantages/disadvantages of each approach.

Metadata wrapped directly around the object

Image by Matthew Bietz via Flickr

I’m going to refer to this first world view as the “bacon-wrapped scallops” worldview.  Objects (the scallop) are wrapped in their respective metadata references (the bacon). The benefit here is that the metadata becomes an intrinsic part of the object that’s being referenced.  Replication policies, etc. can be directly enacted on an object without much cause or care for concern.  Additionally, any loss of metadata reference affects a singular object only, not globally, thus restraining chain failures across a filesystem.

Issues with this approach are fundamentally tied to portability, corruption and performance.   Portability is a double-edged sword.  It’s great when you want to make sure that the object can exist in multiple locations but since the metadata is bound to an object, locality of reference can be skewed.  In other words, having an extant meta database provides simple records updating for replication and locality whereas bound meta requires updates to EACH replica object.  This also ties into performance as this update process across XXX of objects can take time as it’s a hunt operation within a matrix of (potentially) billions of files.  Corruption, finally, can potentially wreak havoc in a wrapped model because each object meta can be corrupted and, when sync’ed to replicas can pass on corruption.

Metadata as distinctly separate entity

Scallops with Creamed Corn, Asparagus, Pearl Onions and Coffee Cocoa Chile Butter

If metadata being wrapped to the object is the “bacon-wrapped scallops” approach, then the concept of keep metadata separate from the object is, well, “Scallops with Creamed Corn, Asparagus, Pearl Onions, and Coffee Cocoa Chile Butter.” (don’t laugh, you can find this recipe here).  Obviously, this is a more complicated recipe than just “bacon-wrapped scallops” but it does prove a certain point: separating metadata can have an obvious benefit of “improving” the base characterization of the underlying object while allowing for methods of portability (exemplified by the recipe above) and for customization that exceed meta-wrapped objects.  Advantages include the ability to provide UID reference points in an extant database that is subject to its own protection schemas (either by replication or otherwise), performancing (meta references need only be updated to the db by design, not to the object(s) present), and corruption prevention (object corruption occurs independent of meta and vice-versa).

Disadvantages would still be present as you now have to design for an extant meta database(s) to equalize performance across nodes (as noted in my master/slave node topology here).  Additionally, a protection mechanism for these databases could have performance implications (especially in synchronous, off-box schemas) as a vast number of records (potentially, again, billions) would have to be appended.  Another potential double-edge sword is the need to have some level of metadatabase replication in place to other nodes within the cloud storage platform in order to enforce meta-driven policies.  Since the reference model is based on object UID in the database, these databases have to be persistent through the entire platform, potentially driving up storage capacity utilization.

Hopefully, this makes sense and I’d appreciate any feedback that you might have!

Related articles by Zemanta

• NSA To Use Cloud Model For Intelligence Analysis (news.slashdot.org)
• PaaS and the Cloud Continuum (java.sys-con.com)

I’ve been ruminating on a conversation that I was part of at the recent Cloud Camp – Boston “un-conference.”  In this particular case, a customer (a VAR; NOT a manufacturer) was talking about leveraging cloud storage for a particular customer of theirs who had the following “essential criteria” that needed design help:  multiple petabytes of storage, significant unstructured data, low cost of entry, data primacy/ownership (e.g. privately controlled assets/data), and very little need for typical NAS/SAN implementations.  The questions that this VAR brought up were related to designing for this type of storage.  Let’s explore this a little more (remember, just thinking out loud here) by looking at retrofitting cloud-type storage (a la Atmos) versus looking at a “net new” installation of a completely cloud storage based infrastructure.

Retrofitment

The concept of retrofitting is to shoehorn a “new” product into a space where “old” product was either unsatisfactory or incapable of servicing the ongoing data needs of a company’s infrastructure.  In this case, the goal is to use as much of the existing infrastructure as possible to minimize cost while at the same time providing the much-needed boost in management and capability brought to the table by the new technology.  In these type of cases, the ability of the storage product (in my case, Atmos) to integrate seemlessly is vital to bringing the “cloud” to the table.  Atmos, for what it’s worth, offers the ability to integrate into traditional NAS/SAN environments through CIFS, NFS, and IFS connectivity options (IFS is through a RHEL 5.x client) while also allowing the customer to develop connectivity and SOA options through REST/SOAP API interfaces.  This way, Atmos allows you to granularly “grow” into a API-based storage model without completely getting rid of (dare I say it? ) legacy NAS/SAN environments.

Net-New

The Net-New concept really thrives when the customer is at a cross-roads; the need for new technology and infra outstrips the need to preserve the current infrastructure (obviously not limited to just the infrastructure discussion ).  The idea here is that by adding a “cloud capable” infrastructure the company can look to potentially minimize the overall OpEx recidivism that they experience as part of their normal buy cycles. (that was a painful sentence to write.)  Objectively, a net-new architecture allows a clean-slate “ground-up”  approach to storage architecture where careful design and planning can be based around hybrid cloud capabilities (e.g. federation between Atmos and Atmos Online) as well as the scalable growth that is offered by those platforms.  Again, provision is made for integrating into the infrastructure where needed via the aforementioned NAS capabilities (CIFS/NFS/IFS) but the emphasis is placed on self-service through the API interface.

Your Choice

The cool part about this evolution is that the choice is ultimately up to you as to how and when you implement.  Having the capabilities of integrating and growing now cannot be overlooked but, obviously, there are challenges with any type of new integration.  Similarly, tossing out the old and bringing in the new has its own sets of challenges such as internal SLAs that IT has with it’s “internal customers” etc.

Comments and feedback (as always) are welcome!

Related articles by Zemanta

• Cloud Computing vs. SOA: Look For a Cross-over in Hype (java.sys-con.com)
• Transition to the Cloud (flickerdown.com)
• Avoiding Latency in the Cloud (gigaom.com)

Going along with the Cloud theme that I’m fortunate enough to be a part of, I’ve decided to use the “micro-burst” moniker to section off quick n’ dirty posts on a variety of cloud subjects that I don’t have time to dive into fully.  With that in mind, let’s get on with the show.

Master Node Topologies: Google File Systems

Today’s topic is based on the link here from The Register.  What I find fascinating is that Google has been able to manage their growth using a single master node topology for their filesystem.  To the article’s point, a single master node offers a single point of failure especially from a chunklet processing and scheduling standpoint.  Bandwidth would also be constrained seeing as how meta would have to pass through and be processed by a single  entity.  Since I’m unaware of the underlying hardware and scalability of their processing complex for this (though I’ve read through the articles that have attempted to explain it), these processing issues could reasonably be remedied by more powerful system hardware and/or software refinement.

It’s exciting to see that Google has thus far been able to move their GFS platform forward and embrace a horizontal scale-out mechanism for the revision 2 product.  Good luck to them as they continue to move their company forward!

Why a Master Node Plurality Makes Sense

When designing for any sort of scale-out filesystem (or what I’d consider a horizontally scalable file system), it makes sense to include the ability to scale the master node (or scheduler node) complexes.  The obvious reason behind this is filesystem growth, to be sure, but as metadata processing becomes increasingly complex (i.e. more FS abilities driven by custom meta), the need to ingest data at the same or higher rate as originally specified becomes critical.  By having a more robust front-end driven by more powerful master nodes with synchronous metadata indexes (or siloed masters with individual meta dbs), you can maintain latency (time to disk or time to commit) SLAs without completely crushing your cloud’s ability to service I/O operations in general. (see image below for conceptual diagram)

Multiple Masternode File system

Hopefully my musings on this subject make sense.  Let me know if you have any questions!

cheers,

Dave

Related articles by Zemanta

• NSA To Use Cloud Model For Intelligence Analysis (news.slashdot.org)
• App Server Cloud Architectures (caucho.com)
• Sparse Data Locality Invention from the Google (arnoldit.com)
• On Google File System (mt-soft.com.ar)
• Google File System II: Dawn of the Multiplying Master Nodes (theregister.co.uk)