Then they added some of their best sales people to the mix including engineers and then went knocking on the doors of every large company in the world in a “no large customer left untouched” blitzkrieg of one on one marketing.

So What is Acadia made of ?

Acadia is offering a package of actual products (not PowerPoint releases) from EMC, Cisco and VMware using a marketing strategy called Vblock. At Boston Gestalt IT Field Day, we received an excellent presentation on the details around the Vblock package from Ed Sai and Scott Lowe that sparked a heated response. I felt that the key issues were around two points:

• Why are the Vblocks so Large ?
• What happens if you exceed the operational parameters of a Vblock ?

Because there was much discussion about why the Vblock that have some strict limitations, I wanted to look into why these limitations exist and why people would object so vehemently to them. And also talk around the question for why Vblocks are big. Too big for most people to buy.

Comprehending the Limits on the joint venture

Acadia is not a merger (yet) of EMC and Cisco, but a partnership focused on the Data Centre. The partnership only promotes selected product groups from each company and even specific products within those group. For example, a Vblock does not include a Nexus 7000 switch, only the Nexus 5000 / 6000 / 2000 as the edge switches. ( You would use your own backbone to connect to your Ethernet network and legacy FibreChannel network ). VMware does not offer VDI solutions. EMC offers CLARiiON in Vblock1, and Symmetrix in Vblock2.

These limits may mean that your choices are limited. Some people regard this as as major concern. I regard this as a reasonable trade off – good service, easy marketing against lack of choice and flexibility.

Other Companies

It’s worth remembering that the joint venture is not exclusive. Both EMC and Cisco are free to pursue partnerships with other companies, and both are actively seen partnering in the market with other companies. Thus recent Cisco / NetApp and EMC/IBM announcements could create a confusing picture for some people who don’t understand these dynamics. That said, from what I’ve seen the Acadia partnership seems to be a “big deal” for both sides with a lot of passion, commitment and, most importantly, significant amounts of cash that fund expensive marketing campaigns. In this case, marketing that seems to actually be relevant and useful.

Selected Products

Acadia only works with selected products from both Cisco, EMC and VMWare. That is, they only offers products from the Data Centre Business Unit from Cisco, selected products Centerra and Celera at EMC and VMWare vSphere. The product is positioned in the market as a private cloud so any technology not relevant to that message isn’t going to be considered eg. No firewalls, no edge routers, no wireless, no backup software, no deduplication,.

My perception is that clear business goals drive this logic:

• Market clarity – limiting the product set allows Acadia to have a highly targeted product message, especially with the “cloud” buzzword attached.
• Technical capacity to deliver an effective sales force
• Leaves space for ‘other partners’ to have similar relationships with customers and not ‘upset’ the reseller marketplace
• minimise the business impact if the project fails
• customer want guarantees that it will work which should get better sales results.
• Acadia has to deliver the solution and deliver the support promise. Not easy when so many technologies are involved, with so many competing interests

I particularly want to focus on the Technical Capacity and Customer Guarantees elements of the argument. If you figure that EMC, Cisco and VMware are bringing a group of vendor engineers together, think about the problems you might have: engineers may have little or no expertise outside of their own company or worked in a cross-functional team. To overcome these problems I would go for a narrow product selection and then expand it over time.

Remember that large companies create significant opportunities for ineptitude and incapacity. Layers of management can create indirection and misalignment just as easily as they can create opportunity and focus. Bringing together teams from three large companies could easily go wrong (case study – HP and it’s many divisions that are rarely coherent).

There are other topics, such as upsetting the resellers, market clarity are all pretty obvious and shouldn’t need discussion.

What are Vblocks ?

The Vblock components are the cumulative permissions of what the marketing and business limitations will allow. There are no technical limits to what equipment could be in a Vblock except for the ability of Acadia to provide a good level of support. These limits are somewhat onerous but not entirely unreasonable. There are currently two Vblocks defined (and more are planned) – known as Vblock 1 and Vblock Two, they are designed, tested and (as is the fashion) certified to within certain, rigidly defined performance levels.

Basic Components

The Vblock architecture is reduced to five layers of physical infrastructure and roughly shown in this diagram taken from “Vblock Infrastructure Packages Reference Architecture” released in 2010.


Outline Bill of Materials

From this, you can see there is a fair amount of variation within the Vblock parts list to cater for your specific requirements. To quote Acadia :

A Vblock consists of a minimum and maximum amount of components that offer balanced I/O, bandwidth, and storage capacity relative to the compute and storage arrays offered. Each Vblock is a fully redundant autonomous system that has 1+1 or N+1 redundancy enabled by default.

In practice, Vblock 1 storage is scaled to deliver from ~42 TB/41000 IOPS (Min) to ~68 TB/ 50000 IOPS (Max). Vblock 2 storage is scaled to deliver from ~140 TB/92000 IOPS (Min) to ~211 TB/140000 IOPS (Max). The hardware is selected to match your performance requirements.

Other flexibilities

Some other quotes from the Cisco / EMC / VMware reference architecture guide:

For Vblock 1, there are no hard disks on the B-200 series blades as all boot services and storage are provided by the SAN. Hawever a snall hard drive may be installed if local page memory is required for vSphere.

For Vblock 2, each B-200 series blade module has 72GB SATA drive for page memory purposes. If required, these can be removed to reduce power and cooling overhead, increase MTBF or save costs.

The MDS9506 switches are recommended, but may optionally be changed for 9509 or 9513 to scale capacity or reduced to an MDS 9222i is less density is required

Inflexibilties

For Vblock 1, there are no hard disks on the B-200 series blades as all boot services and storage are provided by the SAN. Hawever a snall hard drive may be installed if local page memory is required for vSphere. If the local disk is user for main storage or operating system storage, it is not considered a Vblock and is a custom implementation at this point.

It is also acceptable for operating system and applications to be run directly on the B-200 series blades. It should be noted that other hypervisors are not supported by Vblocks and invalidate the Vblock support agreement (my emphasis)

The Limits are arbitrary, practical and mainly marketing

At the Boston Tech Field Day, we saw a number of questions on why there are limits, and what happens if you exceed the solution parameters. I believe it is a simple marketing reason – simple products, simple factors, easy to comprehend makes for a product that is easy for sales to sell, and even easier for customers to buy. Pricing is clear and unambiguous, and sales peoples will attempt to focus the customers away from price onto other topics. Like low power, special UCS features, ease of operation, etc etc.

The key factor is that the Cisco UCS server will be perceived by many as unproven. You can be sure that HP / IBM / Dell are going to work that Fear / Uncertainty / Doubt in a competitive situation.

Exceeding the Limits – You Certainly SHOULD

If you choose to exceed the offered the solution, then that is a simple choice. It’s not something to be particularly concerned about. Currently, we all build stacks of servers, storage and networks and provide our own support. Why would buying a guaranteed stack make any difference ?

These limits are to ensure that service guarantees can be met. The service guarantee exists to help customer to buy these products., it does not exist to make the products work. However, when the CIO is about to approve a purchase order for half million pounds they will be looking for a comfort level that it’s going to work. Those Cisco UCS servers are new and you want some assurance.

So once the system is working, feel free to head out in your own direction. Meeting the requirements of your business is more important that having a an end-to-end guarantee in overall picture. Remember, Cisco / EMC / VMware is still going to support each product using the same process that we have today.

The Fear of Lock In

My concern with the Vblock bundle is fear of lock in. The Cisco UCS product is a closed solution within the racks. Across the backbone of the Data Centre will also be Cisco Nexus 7000 switches for “best compatibility”. All server components must be purchased from Cisco who will be able to arbitrarily set the price. All and any server upgrades, and extra server must come from Cisco.

All storage vendors are an effective lock in today. The so-called “certification programs” ensure that EMC and other “chosen few” are restricted to the supply of drives and accessories.

If Cisco / EMC achieves a dominant position then they have the ability to control pricing. Since both companies are already dominant in their respective markets, and tend to “reassuringly expensive” price models, this is a well founded concern.

What does a Vblock physically look like ?

While every Data Centre is different, every rack looks pretty much the same. During my research, I have realised that a Vblock takes very little space in the data centre. In fact, it’s not until you see the amount of space that you realise the impact to

Vblock 1 – Racked

This is a front view of the Vblock 1 with storage, servers and switches.

Caption Text.(Click for a full size image)

And this is the rear view. Notice how few cables are used for physical connections here.

Caption Text.(Click for a full size image)

Vblock 2 Racked

A Vblock 2 is quite a bit larger and needs more storage. The server blades are larger (more CPU, more RAM per blade). I believe that the increased IOPS for the storage subsystem means that bigger storage units are needed. I think five racks is at the smaller side of the Vblock 2 possibilities.

Caption Text.(Click for a full size image)



Realising the dream – no cables

Caption Text.(Click for a full size image)

Vblock expansion

Even though the Vblock is modular, you can bet that Acadia has a nice little pitch around expansion. Sure enough, it is spelled out in the Architecture Reference:

Caption Text.(Click for a full size image)

As Vblocks are adde, the capacity of the Vblock scales either as an aggregated pool, whereby any ICS blade can access any storage disks n the SAN or as an isolated silo. For example, it is perfectly acceptable to aggragte to Vblock 1′s to provide capacity for 6000 VMs that can share common storage capacity… As long as storage capacity is added in conjunction with compute capacity to maintain balanced performance as published within the Vblock, the system does not require any additional validation .

Heh, you bet they want to sell you lots more so of course there is an answer for this. Once you have made the first purchase, you are likely to come back for more. Lets make it easy for the customer to do that.

So, Why are vBlocks so Large ?

A Vblock 1 is expected to support from 800 to 3000 VMs, and a VBlock 2 is expected to support 3000 to 6000 virtual machines. Since I started writing this post, a Vblock 0 has been announced that supports 300 to 800 VMs.

You might think that 800 is a lot of VMs. You might think that the price of a Vblock is too much. In which case, you aren’t someone who is going to buy it. If you can’t scratch together the several hundred thousand in single purchase order, you do’t understand the question. Today, many companies buy infrastructure as part of the project. If a project needs a server and a switch then that is funded. If a project needs a data centre, then a data centre is built. If a project needs fifty servers, then they MIGHT consider using VMware. Mostly we wait a few years and then have a big project to clear up the mess created by project funding of infrastructure.

Cisco and EMC don’t want to sell this product to small business. Cisco in particular wants to establish themselves in the marketplace as quickly as possible. Therefore selling to big companies, who are doing the “big cleanup project”, who are taking the time to evaluate the whole cost of ownership cycle, implementing with a full cycle approach is what Cisco wants. This is important.

Why ? Because Cisco wants to be able to produce white papers claiming the “huge cost reductions”, and “radical operations alignment” and “enabling technologies” etc etc. These white papers have real impact on the analysts and customers who figure that if they buy the product they will get those benefits. All these great stories, so loved by ‘journalists’ convince the middle sized market to buy Cisco servers.

What does EMC get ? EMC gets to move into the mid-sized market right alongside Cisco. EMC has been targeting the high end of the market, and they need new markets. A move down into the mid-sized market must not damage the high end products and branding (since this could affect profits), and attaching to a “differentiated” product will keep the premium marketing message intact.

EtherealMind View

Basically, I view the Acadia partnership as an upmarket fancy marketing campaign with extensive tie-ins. It’s “dressed up with a little black dress and killer set of heels” and well funded to boot. This type of thing normally makes me distrustful as many of these initiatives have turned out to be one night stands with an uncomfortable and unhappy morning after.

On the other hand, both Cisco and EMC have attached their corporate goodwill to this program in a major way. If Acadia fails, both companies will suffer significant image loss. It’s not marriage, but they are definitely living together.

The Challenge to the Status Quo

One of the most exciting (to my mind) aspects of the Vblock concept, is the potential to change the purchasing cycle of IT Projects. Many companies fund new purchases from projects only. This tends to create an inherently failed infrastructure buildout where each project buys what it needs. Project “cost controls” mean that infrastructure is rarely purchased to outside the project requirements. That is, buying additional disk drives or edge switches is easy, but buying additional arrays or core switches is almost impossible.

A Vblock could represent a “once a year” purchase of server infrastructure. Much easier than endlessly integrating, and reintegrating a hodge podge of servers, memory, disk drives and accessories into some sort of complete system. Compare this with the HP C-Class chassis concept which requires endless upgrades to scale into new and more useful configurations.

Most importantly, once engineers are freed from mundane tasks of installing memory and disk drives, they can move to focussing on the management platforms and dramatically enhancing the business value of computing. Tasks such as automating software and OS deployment, automated failure responses, performance analysis and

Cisco needs to buy EMC

Ultimately I remain convinced that Cisco must and will buy EMC to compete with HP and IBM. The Acadia joint venture looks a lot like a trial or temporary position while the market reaction is gauged. EMC has a marcap of USD$34 billion and revenue of USD$14 billion while Cisco has marcap of USD$154 billion on revenue of USD$35.5 billing. Cisco appears capable of acquiring EMC and is believed to have sufficient cash reserves to make a substantial cash rich offer. EMC probably has pretentions to be a lot bigger and don’t want to be bought right now. EMC egos are well known for their ‘capacity’ and they work hard at that. Combine that with a Wall Street that is anti-acquisition at the moment, and Cisco can’t make a move right now.

Public Clouds are not ready for the Enterprise

Public Clouds are fine for people that are not conducting serious business today. Dot Com startups, marketing pushes, publicity campaigns and other low vitality requirements could be considered for cloud infrastructure due to their trivial nature, but serious business applications are unlikely to move into the cloud with the current level of capability.

However, private clouds are practical today. To me, Vblock looks like an early mover in the Private Cloud space for IaaS. The option for a corporate IT department to build a three rack system that hosts between 300 to 700 servers is an exciting development. If I can reduce the amount of time my operations teams spend doing trivial and repetitive tasks and move them into systems automation on the management platforms, then we are moving to better place.

Technology Acceptance

There are no technology issues in this stack. In general, people perceive that Cisco and EMC are market leaders in their respective spaces, and the corporately the two companies fit well together. Unlike other stacks, there doesn’t appear to be a product that is less than excellent. In this sense, few people will dismiss the Acadia solution on technology grounds.

Conclusion

Convincing IT Management to take on the change put forward by Cisco / EMC is going to require a lot of marketing and sales. And that’s exactly what Acadia is all about. The technology takes care of itself here, Acadia is just marketing exercise, but a good one.

© Etherealmind for Gestalt IT, 2010. | Market positioning Acadia, EMC, Cisco and the whole vBlock Idea
Read more posts categorized as Cloud Computing, Featured, Networking, Server Virtualization, Storage, Top Story

EMC Symmetrix BIN file, largely an unknown topic in the storage industry and practically there is no available information related to it. This post is just an attempt to shed some light as to what a BIN file is, how it works, what’s in it and why is it essential with the Enginuity code. Some EMC folks have capitalized on the BIN file as to the personality it brings to the Symmetrix, while the EMC competition always uses it against them as it introduces complexities in the storage environment with management and change control.

Personally I feel a Symmetrix wouldn’t be a Symmetrix if the BIN file weren’t there. The personality, characteristics, robustness, compatibility, flexibility, integration with OS’s, etc wouldn’t be there if the BIN file didn’t exist.

With the total number of OS’s, device types, channel interfaces and flags it supports today, sort of making it one of the most compatible storage arrays in the market. The configuration and compatibility on the Symmetrix can be verified using the E-Lab navigator available on Powerlink.

So here are some facts about the BIN file

• Only used with Symmetrix systems (Enginuity Code)
• BIN file stands for BINARY file
• BIN file holds all information about the Symmetrix configuration
• One BIN file per system serial number is required
• BIN file was used with Symmetrix Gen 1 in 1990 and is still used in 2010 with Symmetrix V-Max systems
• BIN file holds information on SRDF configurations, total memory, memory in slots, serial number of the unit, number of directors, type of directors, director flags, engines, engine ports, front end ports, back end ports, drives on the loop, drives on the SCSI bus, number of drives per loop, drive types in the slots, drive speeds, volume addresses, volume types, meta’s, device flags and many more settings
• The setup for host connection if the OS is Open Systems or Mainframe environments using FICON, ESCON, GbE, FC, RF, etc is all defined in the BIN file. Also director emulations, drive formats if OSD or CKD, format types, drive speeds, etc is all defined in the BIN file
• BIN file is required to make a system active. It is created based on customer specifications and installed by EMC during the initial setup
• Any ongoing changes in the environment related to hardware upgrades, defining devices, changing flags, etc is all accomplished using BIN file changes
• BIN file changes can be accomplished 3 ways.
  • BIN file change for hardware upgrades is typically performed by EMC only
  • BIN file change for other changes that are device, director, flags, meta’s, SRDF configurations etc is either performed through the SYMAPI infrastructure using SymCLI or ECC (Now Ionix) or SMC (Symmetrix Management Console) by the customer. (Edited based on the comments: Only some changes now require traditional BIN file change, typically others are performed using sys calls in enginuity environment)
• Solutions enabler is required on the Symcli, ECC, SMC management stations to enable SYMAPI infrastructure to operate
• VCMDB needs to be setup on the Symmetrix for SymCLI, ECC, SMC related changes to work
• Gatekeeper devices need to be setup on the Symmetrix front end ports for SymCLI, ECC, SMC changes to work
• For Symmetrix Optimizer to work in your environment, you need DRV devices setup on your Symmetrix.(Edited based on comments: Only required until DMX platform. Going forward with DMX3/4 & V-Max platforms it uses sys calls to perform Optimizer changes).

Back in the day

All and any BIN file changes on the Symmetrix 3.0, Symmetrix 4.0 used to be performed by EMC from the Service Processor. Over the years with introduction of SYMAPI and other layered software products, now seldom is EMC involved in the upgrade process.

Hardware upgrades

BIN File changes typically have to be initiated and performed by EMC, again these are the hardware upgrades. If the customer is looking at adding 32GB’s of Cache to the existing DMX-4 system or adding new Front End connectivity or upgrading 1200 drive system to 1920 drives, all these require BIN file changes initiated and performed by EMC. To my understanding the turn around time is just a few days with these changes, as it requires change control and other processes within EMC.

Customer initiated changes

Configuration changes around front end ports, creating volumes, creating meta’s, volume flags, host connectivity, configuration flags, SRDF volume configurations, SRDF replication configurations, etc can all be accomplished through the customer end using the SYMAPI infrastructure (with SymCLI or ECC or SMC). These are performed through Sys calls and not necessarily using traditional BIN changes DMX-3 systems onwards.)

Enginuity upgrade

Upgrading the microcode (Enginuity) on a DMX or a V-Max is not a BIN file change, but rather is a code upgrade. Back in the days, many upgrades were performed offline, but in this day and age, all changes are online and accomplished with minimum pains.

Today

So EMC has moved quite ahead with the Symmetrix architecture over the past 20 years, but the underlying BIN file change requirements haven’t changed over these 8 generations of Symmetrix.

Any and all BIN file changes are recommended to be done during quite times (less IOPS), at schedule change control times. Again these would include the ones that EMC is performing from a hardware perspective or the customer is performing for device/flag changes.

The process

During the process of a BIN file change, the configuration file typically ending with the name *.BIN is loaded to all the frontend directors, backend directors, including the global cache. After the upload, the system is refreshed with this new file in the global cache and the process makes the new configuration changes active. This process of refresh is called IML (Initial Memory Load) and the BIN file is typically called IMPL (Initial Memory Program Load) file.

A customer initiated BIN file works in a similar way, where the SYMAPI infrastructure that resides on the service processor allows the customer to interface with the Symmetrix to perform these changes. During this process, the scripts verify that the customer configurations are valid and then perform the changes and make the new configuration active.

To query the Symmetrix system for configuration details, reference the SymCLI guide. Some standard commands to query your system would include symcfg, symcli, symdev, symdisk, symdrv, symevent, symhost, symgate, syminq, symstat commands and will help you navigate and find all the necessary details related to your Symmetrix. Also similar information in a GUI can be obtained using ECC and SMC. Both will allow the customer to initiate SYMAPI changes.

Unless something has changed with the V-Max, typically to get an excel based representation of your BIN file, ask your EMC CE.

Issues

You cannot run two BIN files in a single system, though at times the system can end up in a state where you can have multiple BIN files on various directors. This phenomenon typically doesn’t happen to often, but an automated script when not finished properly can put the system in this state. At this point the Symmetrix will initiate a call home immediately and the PSE labs should typically be able to resolve these issues.

Additional software like Symmetrix Optimizer also uses the underlying BIN file infrastructure to make changes to the storage array to move hot and cold devices based on the required defined criteria. There have been quite a few known cases of Symmetrix Optimizer causing the above phenomenon of multiple BIN files. , Though many critics will disagree with that statement. (Edited based on comments: Only required until DMX platform. Going forward with DMX3/4 & V-Max platforms it uses sys calls to perform these Optimizer changes).

NOTE: One piece of advice, never run SYMCLI or ECC scripts for BIN file changes through a VPN connected desktop or laptop. Always run all necessary SymCLI / SMC / ECC scripts for changes from a server in your local environment. Very highly recommend, never attempt to administer your Symmetrix system with an iPhone or a Blackberry.

Hope in your quest to get more information on BIN files, this serves as the starting point..

Cheers
@storagenerve

NOTE: Read additional comments and clarifications on this topic at the Storagenerve Blog

© Devang for Gestalt IT, 2010. | EMC Symmetrix: Bin File
Read more posts categorized as Storage

Enhancements to EMC Symmetrix V-Max systems is possibly around the corner (FY09 Q4).

FAST (Fully Automated Storage Tiering) is due this quarter and will be one of the most awaited software release in the enterprise storage space by EMC.

Bundled together with FAST, possibly a new microcode version the enables FAST (its associated features) and other expected enhancements.

Though this will be a major software release and functionality upgrade, I don’t think this would qualify as a 2nd generation EMC Symmetrix V-Max system.

But fully expect EMC to release its FAST v2 and V-Max Gen2 (possibly named like V-Max II or V-Max Ext) somewhere around Mid year 2010.

Here are a few new features to possibly expect on the EMC Symmetrix V-Max Systems this quarter.

1. Introduction of FAST v1, which should allow automated data movement within a single Symmetrix V-Max system. Here are some features of FAST as discussed on GestaltIT and by Barry Burke (TSA) on his blog.

2. FAST v1 data movement should possibly be policy driven around factors like time (how old is the data), SLA (promised SLA’s), Tier (from Tier 0 to Tier 1 to Tier 2) and possibly I/O or IOPS based.

3. FAST v1 should allow automated policy based data movement or prompt a user for manual intervention for data movement.

4. Do not expect FAST v1 to come for free, it will possibly be licensed based on the total number of TB’s in the storage subsystem.

5. Expect some integration between the IONIX platform and FAST v1 and possibly some very tight integration with future releases of FAST and IONIX.

6. Expect FAST and IONIX to integrate very tightly with Atmos through API’s and policies. We should expect to see this with FAST v2 and not with FAST v1.

7. So when does EMC retire Symmetrix Optimizer, with FAST v1 probably not, with FAST v2 probably yes.

8. 2TB SATA II drives will be introduced (According to a Keynote from Joe Tucci in NYC), though Joe Tucci didn’t mention what platforms the 2TB SATA II drives will be available on, it seems the V-Max upgrade would be the most logical platform.

9. The 2TB SATA II drive upgrade should make the V-Max 4 PB total storage (2400 drives x 2TB), possibly the single largest storage subsystem at an enterprise level.

10. RapidIO speed upgrade from 2.5 Gbps to 4 Gbps (interconnects between the engines) upgraded either through MBIE (new processors) and / or through microcode upgrades. EMC currently uses Serial RapidIO which supports 1.25Ghz to 3.0Ghz clocking speeds and can scale upto 10 Gbps I/O though EMC currently utilizes 2.5 Gbps as its interconnect speeds for the engines.

11. Increased drive interconnect speeds. May be denser EFD’s, though I can’t speculate on it.

12. FC and FICON (Host Connects) port speeds upgrade from 4 Gbps to 8 Gbps

13. Interconnect between two separate Symmetrix V-Max Systems (8 Engines each per system) expanding into possibly 16 (max) engines. The more I think about this concept, the more it makes me feel that there are no added benefits of this architecture, rather it will add more complexities with data management and higher latency. Remember how the V-Max was initially marketed with having hundreds of engines and millions of IOPS, the only way to achieve that vision is through interconnects. The longer the distance, the more latency with cache and I/O. If Interconnects end up making in this release, limitation on the distance between two Symmetrix V-Max system bays would be around 100 feet.

14. To the point above, another way of possibly connecting these systems could merely be federation through external policy based engines. Ed Saipetch and myself have speculated that concept on GestaltIT.

15. With the use of larger drive size, possibly expect a cache upgrade. Currently the Symmetrix V-Max supports 1TB total cache (512GB usable), which may get upgraded to 2TB total cache (1024 GB usable).

16. New possible microcode version 5875 that will help bring features like FAST, SATA II drives and additional cache into the Symmetrix V-Max.

17. Processors: 4 x Quad Core Intel processors on V-Max engines may not get an upgrade in this release, it should possibly be with FAST v2 as a midlife enhancement next year.

18. Further enhancements related to FCoE support.

19. Upgrade of iSCSI interface on Symmetrix V-Max engines from 1GB to 10GB (is now available with the Clariion CX4 platforms).

20. Really do not expect this to happen, but imagine RapidIO interconnects change to FCoE. Really not sure what made EMC to go with RapidIO instead of Infiniband 40 Gbps (which most of the storage industry folks think is dead) or FCoE with Engine interconnects, but if the engineers at EMC thought of RapidIO as a means to connect the V-Max engines, there has to be a reason behind it. Enginuity more or less doesn’t care about the underlying switching technology, making a switch from RapidIO to FCoE or Infiniband can be accomplished without a lot of pains. Though for customers already invested into RapidIO technology (with existing V-Max systems), it might be offline time to change the underlying fabric, which in most cases is unacceptable.

21. Virtual Provisioning on Virtual LUNs which is currently not supported with the existing generation of Microcode on V-Max systems.

22. Atmos currently is running as a beta release and we should expect a market release this Quarter. Should we expect to see an integration between V-Max and Atmos. I am not sure of any integration today.

23. A very interesting feature to have in the EMC Symmetrix V-Max would be system partitioning, where you can run half the V-Max engines at a certain Microcode level with a certain set of features and other half can be treated as a completely separate system with its own identity (almost like a Mainframe environment). Shouldn’t this be a feature of a modular storage array.

24. Symmetrix Management Console (SMC) and Vmware integration (like VMware aware Navisphere and Navisphere aware VMware). There is already quite a bit of support related to VMware in SMC for provisioning and allocation.

25. Also a much tighter integration between IONIX, FAST, SMC, Navisphere and Atmos may after all be the secret sauce, which would enable workflow, dataflow and importantly automation. Though do not expect this integration now, something to look forward for the next year.

Summary

Though I am still a bit confused on where FAST will physically sit.

FAST v1 can merely be a feature integrated within the Microcode, configurable & driven through policy within the Symmetrix Management Console.

FAST v2 (Sometime Mid 2010) should support in-box and out-of-box (eg: Symmetrix to Clariion to Celerra to Centera) data movement through policy engine.

Ed Saipetch and myself have speculated on GestaltIT on how that may work. Though after some thoughts, I do believe a policy engine can merely be a VM or a vAPP sitting outside the physical storage system in the Storage environment.

To promote the sales of the EMC Symmetrix V-Max systems, Barry Burke in his blog post talks about Open Replicator, Open Migrator and SRDF / DM (Data mobility) are now available at no cost for customers purchasing a new EMC Symmetrix V-Max system, these are some of the incentives that EMC is offering and further promoting the sales of its latest generation Symmetrix technology.

It remains to be seen the path of success FAST will carve for Symmetrix V-Max systems.

© Devang for Gestalt IT, 2009. | Enhancements to EMC Symmetrix V-Max Systems coming!!
Read more posts categorized as Featured, Storage

Previously in one of the post on StorageNerve, I had explained the evolution of the EMC Clariion Technology including the AX products and the flare code that is associated with the success of this platform, to read the blog post.

The following are the 4 available models within the AX4 Platform; the naming conventions will explain it further.

• AX4-5F (Fiber Channel Host Connect)
• AX4-5FSC (Fiber Channel Host Connect, Single RAID Controller)
• AX4-5i (iSCSI Host Connect)
• AX4-5iSC (iSCSI Host Connect, Single Raid Controller)

Drives per DAE (Drive Array Enclosure): 12

Maximum DAE’s (Drive Array Enclosure) supported per System: 4

DPE (Disk Processor Enclosure): 12 drive per DPE

Maximum Drives Supported per System: 60

Minimum Drives Supported per System: 4 Drives including the Flare Drives (Flare code resides on the 1^st 4 drives of the DPE, with do not remove stickers).

Naming Convention for Drives:

1. Bus
2. Enclosure
3. Drive No

Possible Options

• Bus 0 and 1
• Enclosure 1, 2, 3, 4 (DPE becomes enclosure 0)
• Drive 0 through 11 (12 Drives total)

B0_E3_D11 becomes Bus 0, Enclosure 3 and Drive 12

The following are the disk drives that are supported with the AX4 Platforms.

As you notice above, only SAS and SATA drives are usable on an AX4 system with no support for FC or EFD’s.

Supported RAID Types with AX4 Systems

• RAID 0, RAID 0+1, RAID 3 and RAID 5 Technologies.
• CORRECTION: RAID 6 is now supported on AX-4 Platforms starting release 23 (Navisphere Express).

Supported Software on the AX4 Systems

• Navisphere Express included
• Navisphere Manager (Only with 2 Service Processors)
• Navisphere QoS
• Navisphere Analyzer
• SnapView
• MirrorView/S and /A
• SANCopy
• Ionix Control Center plug-in
• PowerPath
• RecoverPoint/SE and CDP/CRR
• Replication Manager

Host Type Supported

• Windows 2000/2003/2008
• Linux
• Solaris
• HP-UX
• AIX
• VMware

Some very important characteristics of the AX4 Platforms

• Very cost effective
• Completes in the SMB space with low end IBM and HP Storage
• Scales upto 60TB RAW Storage
• Supports upto 64 Host systems connected
• 1GB Cache per Service Processor, 2GB max for dual processors.
• 4GB FC connectivity to host (fiber ports to switch / host)
• You can run it with a single controller or dual controllers
• iSCSI Support
• SAS and SATA drives are supported
• All Clariion Software supported
• SPS (single included): Standby Power Supply – Battery allows the cache to destage during a forced shutdown resulting in no data loss
• MetaLUN Technology supported
• Virtual LUN Technology supported
• Snaps and Clones supported
• Supports Flare Release 23, 26 and 28.

© Devang for Gestalt IT, 2009. | EMC AX4 Platform
Read more posts categorized as All, Storage