Data Center Advisors

Generally, I believe that the day went well, and I wanted to thank all of the attendees as well as the HDSers who provided their time.  There was a great deal of discourse, debate and Q&A. Two more interesting questions I wanted to highlight:

• Nigel Poulton – What happens if there is a misconfiguration in the tiered storage model that includes external and internal storage?
  • Answer: Yes the misconfiguration is possible and the way out of this is Tiered Storage Manager and Volume Migrator.  With the HTSM/VolMig combination it is possible to move out of a particular tier (including HDP pools) and not pay the penalty of having to suffer an application/OS outage to heal the storage configuration.
• StorageNerve  - Where is the Hitachi “binfile”?
  • Answer: Hitachi doesn’t have the concept of a “binfile.”

I think that overall there was a lot of uncovering what Hitachi can already do today, and there was a comment from the blogger attendees that HDS is clearly moving beyond just storage and the UCP announce was a part of that.  The team got to see the BladeSymphony platform tied to our storage environment which supports development of our Orchestration layer in the lab.  At that time I also mentioned that there were some cool features available such as SMP spanning multiple blades to create a single system, and further the I/O expansion capabilities which are already available in Japan that allows the servers to address more I/O cards.  (The other neat thing about this I/O expansion package is that it is capable of PCIe card hotplug with a pretty cool physical interface to allow for that…)

Now onto day 2 tomorrow.

Tweet

Posted in HDS Day 3 Comments »

Comments (3 )

Post Comment

With all due respect, EVERY intelligent storage array has the equivalent of the “binfile” (more properly, the “.BIN file”).

The BIN file is nothing more than the persistent configuration of the array (LUN id’s, security keys, device/port maps, cache partitions, access control lists, etc.), stored in a file. Without such, the system could not be rebooted or restored after a power failure.

To suggest that Hitachi arrays “don’t have the concept of a BIN file” is abjectly false and misleading. Pretty much the same as when Jim Allchin of Microsoft attested at its launch that Windows NT booted so fast because they had done away with CONFIG.SYS. As the urban legend goes, mere seconds later, the screen of the demo system he was booting up spewed page after page of configuration data (ostensibly NOT from CONFIG.SYS, but instead from AUTOEXEC.CMD, system.ini).

Today we all know that Windows maintains its persistent configuration data in The Registry, which has turned out to be FAR more complicated and confounding that CONFIG.SYS ever was.

So, indeed, the question should have been posed as “Where does the USP-V keep its persistent configuration data?”

Barry, HDS does not have the concept of a BIN file that statically maps the cache as EMC has with the DMX and the VMax.

Since the mid 1990′s with the introduction of the 7700 Freedom storage arrays, we store the configuration data in a mirrored control store which is accessible to the FED and BED on buses which are separate from the connections to the data store.We can change the configuration of the data cache simply by changing bits in the control store. This is how we are able to dynamically change configurations, do non disruptive maintenance and upgrades, and map cache to external storage for storage virtualization. Since EMC does not have a separate control store, you must store control information in the data store and keep “persistent data in a .BIN file”. Keeping control data in your data store creates three problems: 1) it creates a static cache configuration mapping 2) it impacts performance when your control data access contends with your data access, as in the case of the control data for your thin provisioning which resides in you data cache. 3) it is a security exposure for your call home maintenance. When your remote maintenance person accesses your control data for maintenance he also has access to user data. Since our control data is in a separate control store and is accessed over separate buses, there is no access contention and there is no security exposure.

There is “boot” information which we keep in Flash in the FED and BED and our control and data stores are backed up by batteries. This enables us to offer a diskless USP VM.

Do you still have to shut down your DMX and VMax when you update your BIN file?

[...] not to be”. There was no questions in Barry Burk’s mind when StorageNerve asked Michael Hay “ Where is the Hitachi BINfile” and Michael answered “Hitachi doesn’t have the concept of a [...]

Post a Comment