If you are following Cisco Unified computing solution, here is some good news. The latest firmware version 1.4 is officially support direct attach FCoE Storage protocol without require the additional SAN switch as previous version. Both Netapp and EMC are officially supported and certified to direct attach with the Cisco UCS without a SAN switch require. This will reduce the complex layer it require to deploy especially for those environment who are not FC users previously.

I found some very good post over the internet, you can refer the URL below for more information about the new update provided in Firmware 1.4

Unified Computing Blog

M. Sean McGee

Unified Storage………Sounds new to you? or sounds familiar to you? No right or wrong answer here, but it had become the dream of every storage vendor to offer this to their client especially in mid range, enterprise and virtualization environment. I remembered Netapp was the 1st started this, follow by other competitors in the market.

What is unified storage?

A single platform support multi-protocol such as FC, ISCSI, NFS, CIFS, FCoE and etc. It also support file, volume and block level data access.

You will able to get the unified box from either Netapp, EMC and HDS in the market now.

Well, seems like all the major storage players are aligned and agreed with the Unified Storage architecture now. Let’s share some of my personal experiences here. For my pass experience as an end users, I had met up with numbers of Storage experts from different principle. I often received those comments as Unified storage will slow down the performance, not efficient and they are not block base solution from multiple experts. No right or wrong for what they had commented, but with the storage trend today, they may need to reconsider the statements they had put in front to the customers previously.

Personal opinion, the storage transformation majority are caused by Virtualization and cloud computing as you could easily decide the protocol or methodology for different deployment, which had forced the storage vendor to re-consider their approach for SAN offer to support unified protocol in single platform.

Today, on SAN business, they rely on the OEM partner EMC, which also direct compete with many of the EMC partner at the same time. Equallogic became 2nd option to offer to DELL customers, but we do not see huge pickup in large enterprise environment due to limited protocol supported in single platform, as we are heading to UNIFIED Storage era. Overall, I think this could be visionary bid for DELL to move forward to offer more option to their customers.

View the full reports from here.

Traditional legacy or standalone environment, we often realize there are many solutions perform replication from primary data center to DR center via host base, storage base or image base replication. All of them has the pros & cons depend what is the objective of the specified DR project users are looking at. DR consistency and usability during DR scenario & practices always the biggest challenge in every IT department today.

In virtual environment, hypervisor will encapsulate the entire virtual system in to multiple files. These files are usually located on the Shared storage environment & replicated across to DR center via storage replication. Of course, this solution are come with a cost, may not apply to every environment. Well, my intention is to compare the simplicity of DR in virtual compare to physical environment. Since everything are on SAN or NAS in virtual environment, everything could had just taken care by the storage and replicated over to DR center. With VMware Site Recovery Manager solution, extra management capability had built in allow users to predefine the DR policy to ensure VMs are ready to production in DR scenario. The entire state of the virtual machine include operating system, application data, and databases are fully replicated across to DR center in this case.

In physical environment, we always had challenges to maintain consistency on the operating system & application, which may not running on SAN, unless all systems are on SAN boot environment without local hard drive. Due to complexity and cost concerns, not many of the enterprise IT today will have SAN boot environment. For anything is not on SAN, may require 3rd party solution or customize solutions to ensure consistency over the DR.

A re-design or DR solution due to virtualization adoption, may bring more benefits to the IT and business unit by reducing the complexity compare to the physical environment.

General de-duplication solution:

1. Primary SAN de-duplication
2. Appliance target base de-duplication
3. Host base de-duplication
4. Software base de-duplication

I may had missed out some of them, but these should cover majority of the de-deduplication solution in the market today.

Primary SAN de-duplication allow dedupe happens on the primary SAN,  where most of the active data were stored. This should be the highest cost / GB that running in your environment.  Primary SAN de-dupe happen on Netapp and EMC storage today. While both claim they are doing de-duplication, you may need to take note the block base de-dedupe and file base de-dupe are different approach.

Primary SAN de-dupe allow you to achieve disk space saving up to 50% or more, especially in virtualization environment. As we all are familiar with the virtual machine deployment, most of the virtual machines are usually cloned or deploy from the standard template, which will contains numbers of duplicated block data on the primary storage. De-duplication allow administrator to re-claim more space from the primary SAN, and reduce the TCO of overall virtualization strategy. I will suggest de-dupe to be enable for virtualization deployment and exclude the volume or LUN that require high I/O performance especially for Databases.

Appliance base de-deuplication – example Data Domain VTL, Quantum VTL and etc. These solution will be more specified to backup and recovery. As an example, it allows users to perform daily full backup with minimal disk space consumption with de-deduplication on virtual tape library. This is not on primary SAN as your VTL are not the primary SAN where the data are stored

Host base de-duplication – Avamar. This is another great solution in the market; allow data to be de-dupe before process over for local or remote backup. As an example, it will allow users to minimize the bandwidth requirement for remote office or location, and centralize manage the backup and recovery on primary data center.

Software base de-duplication which allows users to convert direct attach, NAS, tape or SAN attach storage, to be target base deduplication machine. This is heavily relying on the management software to perform the data de-duplication and not the hardware appliance itself.

No right or wrong, just to share the different in general how you should consider about de-duplication solution today in the market. Each of them has the unique position in the market for different perspective.

Here show the plug-in which integrated the the vi-client directly

The plug-in support all the EMC SAN product range from Clariion, Celerra to Symmetrix

Beside this, there are also the configuration wizard allow you to provision the datastore from the default storage pool which had been pre-assign from the SAN. The automation wizard will simplify the Datastore provisioning to the administrator. You will no longer require to rescan all HBA for every single host as the wizard will help you to do so during the provisioning process. 1 of the big improvement are the NFS datastore. Without the provision wizard, you may require log on to multiple console to export the NFS path and mount it to every single host 1 by 1, unless you do it with scripting method previously. You will no longer require to repeat the tire process of doing this as the automated wizard will help you to mount the NFS datastore to the cluster group automatically on the ESX host level.

Here is the NFS provision wizard. This is really helpful to simplify the process of NFS datastore provision on the ESX host.

The EMC plug-in is really helpful and I believe many of us will include this in our deployment in the future.

I further checked the virtual machines been power on in the ESX servers, which show all the VM were continue running without system crash or rebooted. Now I realize that the failure on SAN switch may not necessary result system crash or hung, in fact it may allow you resume the system state once the SAN switch are back online, of course, this is no guarantee assumption, just some surprise finding experienced yesterday would like to share here.

You may have 30 to 50 VMs into single host today due to high density server with more CPU core or more memory per single system. In the next second, you may face the hardware failure on 1 of the host, there will be around 50 VMs down at 1 time and require another 20 mins before all the virtual machine could be successful restarted on the surviving host. Some of them may consider this is high impact, therefore you decide to restrict the number of virtual machine in single host around 10 to 20 VM per ESX. What happen next, the TCO is high, and ROI is not efficient.  Is a tough point for most administrators to choose in this scenario. I will urge you to backward a little bit and look at the scenerio again. Before Virtualization, all the business system that only invested with standalone server without physical clustering, they do not entitle any HA as the aware off. If they want a HA in physical system, they will had to invest extra CAPEX and OPEX to maintain a same set of hardware and operating system, just for failover purpose. Again, even the operating system clustering does not provide 100% uptime.

When they adopted to Virtualization today, they do know how the HA will work, as I even personally demo to the business and explain how the HA work in ESX servers. Well, they pay less to the system cost VS Standalone servers but gain. They are happy and acceptable with the 20 mins recovery time if the host are failed due to the hardware failure on the ESX server.  Well, if 20 mins are not acceptable for them today, what about the users who even refuse to host their system in the virtual infrastructure today? There are still many of the systems are currently running on the standalone host without physical clustering. VMware had done the great job by providing ESX cluster and Virtual machine heartbeat monitoring. Users will not get this if they are still on standalone host today.

If you would like to minimize the system down time due to ESX host failure, you can always build the Microsoft cluster or Linux cluster on top of the virtual machines. Of course, this will require extra efforts to manage and maintain just like 2 physical system.  Another choice you may think of, is the Fault Tolerance function from VMware. Of course, you should always configure the policies to control the DRS activities to ensure all your same functionalities system are always split to multiple ESX hosts in the same cluster.

From my experience on deploying multi tier application system in x86 platform, I will say the application design are much critical to improve the uptime from time to time. Those intelligent application today, are able to scale dynamically from multi-tier perspective with auto failover and load balance mode enable. In the event of any application server are down, the users will be auto redirect to the available application server automatically. Well, even we had planned everything in place, there are still much more thing to be involved to prevent the single point of failure such as, SAN storage and Networking.

My opinion on high consolidation ratio in virtualization today, does not mean the risks are increasing. It is well depend on the architecture planning, consideration, design and implementation by the team.

Cisco UCS interconnect fabric switches are utilizing FC uplink to allow the Cisco Unified Computing System to get access to the SAN fabric environment.

Here is the architecture diagram you can refer to. In order to make this work, 1st requirement will be the NPIV.

What is NPIV? ( N_Port ID Virtualization or NPIV is a Fibre Channel facility allowing multiple N_Port IDs to share a single physical N_Port)

For more details information, you can refer to the URL HERE

Once the NPIV had been enabled on the SAN Switch, you just need to enable the FC uplink from the Interconnect Fabric by the UCS Manager or CLI mode. Now you should able to see the WWN login from the command prompt, device manager or fabric manager. Any 1 of the method will work. To simplify the setup for the UCS, you can consider port base zoning or WWN zoning. I had done both setup before with VSAN in place, it looks similar to me except from security stand point. If we are only connecting host and storage via the SAN, the port base zoning with the Storage host group features should able to manage the host group to access the correct LUN. If there are additional devices such as tape library, this may create another layer of confusion. At the end, I configured all the zoning base on WWN id, which are still the best configuration in most environment today to prevent any device, host or target conflict in the fabric environment. Not to say the port base zoning will not work, it just the WWN base is more secure and reliable.

I had done the test with the port base zoning and end up, the backup device will be visible even from my ESX server which run on top of Cisco UCS. This is not cool

In vSphere, the next version of ESX server, VMware had included the new features, which provide capability to rename the device’s name for each of the LUN been presented to the ESX hosts. This will provide alternative to keep track the physical LUNs which presented to ESX hosts and VMs too.

This show the device name had been modified to match with my datastore name. If you do assigned it to a virtual machine, you can easily rename it to the virtual machine name as you need.

Now the device name shown same as the datastore name. If you assign the LUNs to be a RDM on virtual machine, it will not able to be displayed on this screen. The only way to keep track is on the last screen shot which show the physical path which connected to the LUNs.