This is an update and bit of a rewrite of an earlier post I made here.  I wanted to add more detail and information now that I’ve worked with the Nexus 1000v more.

If you’ve read a lot of the Varrow blogs you’ll see information and talk about Cisco’s Nexus technology and products.  To be blunt, it can be confusing and a bit convoluted.  The hardware products, the Nexus 5000 and 7000, have been out for a little while now and we’re seeing more and more interest in those as companies see the need for high speed connectivity and the benefits of FCoE, especially now that FCoE is a standard.  But I think the Nexus 1000v is still a mystery to a lot of people.  There is a lot of “It’s really cool!” information out there but not a lot on how it really works.  One thing I’ve found is that the concept of the 1000v is very nebulous to many customers.  I can white board out how it works, the pieces, how they talk but it’s hard to “get it” without seeing it.  For that reason I created a nice demonstration video that is here.  If you’re new to the 1000v I highly suggest you check it out and see if it makes things click a little better for you.

Now let’s get in to some specifics.

The New Distributed Switch

Before getting in to the 1000v you first need to understand the new distributed switch in vSphere.  The Nexus 1000v uses this framework to provide much of its functionality.  In fact, from within vCenter the 1000v looks very much like the standard shipping distributed switch (dvSwitch).  But, while you can make changes to the dvSwitch in the vCenter GUI you can’t do that with the 1000v.  All changes to that must be done via the Nexus-OS command-line environment.  The idea behind the distributed switch is you now have one place to do the configuration and management of the network connectivity for your entire ESX cluster.  In the past you had to manually create vSwitches and Port Groups on every ESX server you brought up in the cluster.  With the distributed switch you configure your Port Groups just like you want in vCenter.  When a new ESX server moves in to the cluster and is joined to the dvSwitch (distributed virtual switch) it automatically sees the configuration in place.  It’s really great.  I’d say network configuration is the hardest part of the install for most VMware administrators and often a point of contention between the server admins and the network admins..maybe almost as bad as the contention between server guys and storage guys!

The benefit for organizations with separate teams, such as network and server admins, is that this moves “the line” back.  Before we virtualized everything the demarcation point between the server and the network was pretty simple, it was at the switch port.  Now that we’ve virtualized that has moved and sits somewhere in the ESX server so now a lot of that responsibility falls, correctly or not, on to the server admin.  They are the ones configuring networking and networking policies.  While the Nexus 1000v doesn’t move the line back to the physical switch port it gives the network team a virtual switch in the cluster that looks, feels, and acts like a hardware Cisco switch just like they are used to managing.

Components of the Nexus 1000v

When deploying the 1000v there are a few moving parts, not a lot but a couple.  The two primary pieces are the Virtual Supervisor Module (VSM) and the Virtual Ethernet Module (VEM). One thing that helps a lot of people is to imagine the 1000v like a multi-slot chassis switch such as a 6509 or a 4507R.  The VSMs are the supervisor management modules and the VEMs are the I/O port blades that provide connectivity.  The 1000v can have up to two VSMs and 64 VEMs which equates to a 66-slot chassis switch.  That’s a big switch!

So let’s look at the components in a bit more detail.  First is the VSM as it is the central management authority.

Virtual Supervisor Module

The VSM is a virtual version of a hardware supervisor module.   Some switches have redundant modules and the Nexus 1000v is no different.  The VSM runs as a virtual machine  on an ESX server in the cluster.  To provide fault tolerance you can run a second VSM in a standby role.  The secondary VSM will take over if the primary should fail.  Like a physical Supervisor Module there really isn’t any extra maintenance or management needed to run the second one.  Any configuration change on the primary is automatically replicated to the secondary.  So…I don’t see why you wouldn’t run two.  Also like many physical switches the supervisor modules do not have stateful failover, meaning they don’t share current information.  When the primary supervisor fails the secondary reboots, reads in the configuration, and starts working.

It’s important to note that the VSM is not in the data path.  That means it does not stop data flow through the cluster if the VSM should go down.  You won’t be able to make management changes but your VMs will continue to talk.  As of the latest version, 4.0(4)SV1(1),  you can now vMotion the VSMs around as long as it’s on an ESX server with a VEM installed that the VSM itself manages.  Just be sure to exclude it from DRS so you know when it moves!

Virtual Ethernet Module

This is where it gets really cool.  On each vSphere server in the cluster you install the Nexus 1000v VEM.  This is a piece of software that ties that server in to the distributed switch of the Nexus 1000v.  When you install and attach the VEM to the VSM for the cluster that ESX server’s VEM appears as a module on the switch.  So just like you log in to a Cisco chassis switch and do a “show module” you’ll do the same here.  Each ESX server will be its own module.  And that’s why it’s called a Virtual Ethernet Module.  There is an example of the “show module” output below.

How the Modules Communicate

So you have one or more VSMs installed as the brains of the switch and you also have some VEMs installed on ESX servers to act as the access port modules.  How do they talk to each other?  This is an important thing to understand as you need to get this before you start rolling out your VSMs.  Basically the Nexus 1000v uses a couple of VLANs as layer 2 communication channels.  These are the control and packet VLANs.  Their purpose is:

• The Packet VLAN is used by protocols such as CDP, LACP, and IGMP.

The Control VLAN is used for the following:

• VSM configuration commands to each VEM, and their responses.

• VEM NetFlow exports are sent to the VSM, where they are then forwarded to a NetFlow Collector.

• VEM notifications to the VSM, for example a VEM notifies the VSM of the attachment or detachment of ports to the distributed virtual switch (DVS).

Cisco recommends that the Control VLAN and Packet VLAN be separate VLANs; and that they also be on separate VLANs from those that carry data.  In the original version of the 1000v the VSMs and VEMs had to be on the same layer 2 network.  As of version 1.2 you can have layer 3 connectivity from the VSMs to the VEMs.  Just be sure all of the VEMs that are managed by these VSMs can talk via layer 3.  To put it simply, the VSM can be on another network but all the VEMs it manages must be together.  With Cisco releasing a hardware VSM appliance you’ll see more use cases for this functionality.  The vCenter server can be on a different layer 3 network than the VSM, that doesn’t matter.  Before you start deploying VSMs and VEMs you need to decide which VLANs you plan to use for packet and control and then create them on your physical switches that connect ESX servers.  To reiterate, the Control and Packet VLANs are for layer 2 communication.  This means that no IP addresses or default gateway needs to be assigned to these VLANs so just pick any unused VLAN numbers and get them going.

Deploying the Components

This particular post is not meant to be an in-depth guide to installing the 1000v.  Cisco offers their documentation here.  The point of this post is to give you a deeper understanding of how everything fits together so you better understand the function of the 1000v and how it integrates in to your environment.

Deploying the VSM is very simple.  It’s distributed as a ..ova/ovf file set and is easily added to the cluster via the vCenter client. Version 1.2 and above make installation even easier than the original version.  On the original you just imported the .ovf and booted the VSM.  Once booted you were presented the familiar “basic setup” Cisco walkthrough.  As of 1.2 you import the VSM appliance using a .ova file which walks you through a GUI wizard to configure those same items.  It just makes it simpler and faster than before.  In the wizard you’ll be asked for the packet and control VLANs as well as a “domain ID”.  This just defines the VSMs and VEMs that are working together.  Pick an unused number, I start with 1, and continue.  If you have multiple 1000v installations you’ll need to assign unique Domain IDs to each one.

Installing the VEMs isn’t much more difficult.  You have the option of doing it manually on each ESX server or using Update Manager.  The choice is yours.  Manually is easy as it’s a single command once you get the package file on the server.  There is no manual configuration needed on each VEM.  Everything will come from the VSM or vCenter.  If you scp the .vib file to the ESX server all you need to type to install it is:

esxupdate -b *.vib update

Once that is done you can check the installation by using the “vem status” command, such as:

[root@labclt-esx01 ~]# vem status

VEM modules are loaded

Switch Name    Num Ports   Used Ports  Configured Ports  MTU     Uplinks
vSwitch0       32          10          32                1500    vmnic0
DVS Name       Num Ports   Used Ports  Configured Ports  Uplinks
nexus1kv       256         51          256               vmnic1

VEM Agent (vemdpa) is running

That’s it.  Nothing else to do on each system.  Going forward I recommend updating the VEMs using Update Manager.  You can just add a repository in to Update Manager to get patches for the VEMs.  Makes it very easy.  The VSMs take a bit more work to update…but we’ll cover that in another post soon.

The final piece is some configuration in vCenter.  You have to install the Nexus 1000v plugin as well as perform some configuration on the VSM to connect it to vCenter.  This is easily done by opening a web browser and pointing it to the IP of the VSM you installed.  From there you can install the plugin, which is just a simple XML file to allow communication between the VSMs and vCenter.  When that happens your new distributed switch appears and the real fun begins….

Beyond Installation

Assuming everything went well and all the pieces are talking you are ready for configuration.  The first step is to bring each ESX host in the cluster and assign some unused NICs to uplink ports. You can kind of think of uplinks like vSwitches in the normal vSwitch that we are all used to.  Basically, an uplink defines which traffic goes over which physical NICs.  These are how you separate traffic.  So if you want vMotion over one set of NICs and VM Network traffic over another set you’d create two uplinks and assign the appropriate NICs to each.  Here is an example config for an uplink:

port-profile type ethernet system-uplink
 vmware port-group
 switchport mode trunk
 switchport trunk allowed vlan 20-30
 no shutdown
 system vlan 10-12
 state enabled

This is a very simple uplink called system-uplink.  It is allowed to carry all VLANs so all traffic in all port-groups will flow over any NICs assigned to this uplink.  Notice the “system vlan” option.  This specifies that the special VLANs such as Control and Packet can flow over this uplink.   You need to do this if you’re going to move those to the dvSwitch, which you’ll probably eventually do.  One thing worth mentioning is the “switchport trunk allowed vlan” command.  This tells the switch which VLANs can ride of this uplink.  This is how you relate port-groups to uplinks.  So a port-group used for VM traffic on VLAN 21 will ride over this uplink and these NICs.  If another port-group is used for VM traffic or a service console on VLAN 40 it will not go over this uplink and you’d need to define another uplink that could service that VLAN.  If you assign more than one they must be in a channel group.  The Nexus 1000v does not run spanning tree and therefore doesn’t like loops and will disable the connections if it sees duplicates.

If you’re using 10Gb CNA adapters you may only have two ports on the server which means, usually, everything will ride over a single uplink with redundant connections.  If you’re concerned about bandwidth problems due to heavy traffic features such as vMotion or FT you can use QoS to alleviate that.  If you’re in a legacy type configuration with 6 or 8 Gb connections you’ll probably have multiple uplinks just like you had multiple vSwitches before the move to the dvSwitch.  Some of the best practices we’ve had for a while still apply here, they may just be implemented a little differently.

Now that all hosts are attached to the distributed switch you can start creating port groups.  Creating port groups is done from the VSM via the Cisco NX-OS command-line.  NX-OS is the Nexus OS and is very similar to IOS.  Anyone used to IOS should feel at home and will find many nice enhancements.  Within NX-OS you create Port Profiles, which turn in to port groups within vCenter and the distributed switch.  Below is an example configuration for a Port Profile used to let VMs talk to the network.

 port-profile VM_VLAN300
 vmware port-group
 switchport mode access
 switchport access vlan 300
 no shutdown
 state enabled

In many ways it is similar to a port configuration on a physical switch.  This creates a port group in vCenter named VM_VLAN300 that lets VMs talk to other devices on VLAN 300.  Below is a screenshot showing this port group available in the settings for a VM.

Behind the scenes the VMs and port groups act like Cisco devices.  As mentioned before, each ESX server is like a switch module.  For example:

vc4labsw# show mod
Mod  Ports  Module-Type                      Model              Status
---  -----  -------------------------------- ------------------ ------------
1    0      Virtual Supervisor Module        Nexus1000V         active *
3    248    Virtual Ethernet Module          NA                 ok
4    248    Virtual Ethernet Module          NA                 ok

Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    10.13.7.49       NA                                    NA
3    10.13.7.53       33393935-3234-5553-4539-32344e36464b  vc4lab1.varrow.com
4    10.13.7.52       33393935-3234-5553-4539-32344e36464c  vc4lab2.varrow.com

From that you can see there are two VEMs installed.  One on vc4lab1 and the other on vc4lab2, my two vSphere servers in this lab.  When a new connection is made to the dvswitch, whether it’s a VM or something like a Service Console, that connection is given a Virtual Ethernet interface or port assignment.  The connection will always keep the same port number no matter where it lives in the cluster.  Example again:

vc4labsw# show int bri

--------------------------------------------------------------------------------
Interface     VLAN   Type Mode   Status  Reason                   MTU
--------------------------------------------------------------------------------
Veth1         300    virt access up      none                     1500
Veth2         300    virt access up      none                     1500
Veth3         1      virt access up      none                     1500
Veth4         1      virt access up      none                     1500
Veth5         400    virt access up      none                     1500
Veth6         400    virt access up      none                     1500

vc4labsw# show int ve3

Vethernet3 is up
 Port description is JN_Win2k8, Network Adapter 1
 Hardware is Virtual, address is 0050.568a.31cf
 Owner is VM "JN_Win2k8", adapter is Network Adapter 1
 Active on module 3
 VMware DVS port 352
 Port-Profile is VM_VLAN1
 Port mode is access
 Rx
 13616 Input Packets 13220 Unicast Packets
 23 Multicast Packets 373 Broadcast Packets
 1039898 Bytes
 Tx
 198323 Output Packets 87263 Unicast Packets
 13016 Multicast Packets 98044 Broadcast Packets 19 Flood Packets
 80092259 Bytes
 8 Input Packet Drops 0 Output Packet Drops

In the example I performed a “show int brief” to get a concise list.  Notice it shows the interface and VLAN but not the type of connection.  If I narrow it down and look at ve3, Virtual Ethernet 3, I see that this is my Windows 2008 server named JN_Win2K8.  Notice the information displayed.  Very similar to a port on a physical switch.  No matter where this machine goes those statistics and information follow it.

Conclusion

There isa lot of good information out there on the Nexus 1000v now.  Cisco has a very good community site here.  If you’re starting out with the new virtual switch hopefully this post was useful and filled in some of the gaps.  Take a look at the video referenced above as well as the documentation from Cisco.  Cisco has very good documentation and install guides that will walk you through a normal deployment.  The key is to extrapolate what you need from those documents and fit it in to your environment.

With the emergence of infrastructure unification, Fibre Channel over Ethernet (FCoE) has reached the point where it’s time to consider Planning for FCoE. After a proper testing cycle what are the first steps in an eventual deployment plan? What IT professionals need is a strategy by which they can begin to plan to deploy this new technology.

Just as when data centers began to deploy data deduplication, you should consider deploying FCoE where it will deliver the most return on investment. In deduplication, that meant using the technology as a target for backup data where successive full backup jobs created incredibly high storage efficiencies. This would be like potentially storing 50TBs worth of backup data on 5TBs of physical storage and delivering a high return on investment.

Where FCoE could potentially deliver the highest return on its investment is in reducing the cabling count going into physical hosts in a virtual server infrastructure, as well as decreasing management complexity. The typical virtual host will have a minimum of two quad-port Ethernet cards and two dual-port Fibre Channel SAN cards. That is approximately 12 cables per host; which, in a fully built-out rack, could be up to 100 cables just for server connectivity. It becomes very challenging (and expensive) to identify which cables go to which servers and from which storage arrays, etc. In short, this becomes a time-consuming mess.

Alternatively, with FCoE in that same configuration, we will be able to reduce that cable count to two cables per server and potentially 10 to 20 for the entire rack. A single cable pair, for redundancy, would carry all the storage traffic. With the 10GbE bandwidth available in FCoE, we can eliminate the need for quad-port Ethernet cards altogether. And of course, FCoE already has the storage protocol built in.

For these reasons when you are ready to start deploying FCoE, potentially the best way to start deploying it is a rack at a time, as virtualized server infrastructures are started or expanded. Ideally, it’s recommended that as a new rack is built out, you implement the new virtualized hosts with two converged network adapters (CNA) in each server for redundancy. Then, use FCoE-quality cables from those servers to a Top-of-Rack (TOR) switch. From that TOR switch, make the connections out to the main IP, as well as the Fibre Channel, storage infrastructure. The result is: there are only two cables per server running down the rack and the cable cluster is limited to the TOR switch itself.

Potentially, as this rack is built out, there may be a server that, for some reason, can’t go into the combined infrastructure. For example, it may need dedicated 8 Gig Fibre Channel performances or the higher-end performance of IP cards.

This is a reason why it’s important that your infrastructure providers remain fully committed to both traditional IP and FC technologies. Planning for FCoE allows to you begin to build an FCoE infrastructure that, over the next year or so, will progressively get less expensive on a per-rack basis as market adoption increases. By being better prepared for FCoE now, your data center will be better positioned for a more aggressive rollout, as prices come down and capabilities increase, than those data centers that wait and don’t even think about FCoE for the next few years.

Some key advantages of FCoE:
1. FCoE has higher throughput, wasted bandwidth has never been a problem. The internet itself is testimony to this.
2. FCoE has lower latency, and the network does not need to route IP packets, but forward Ethernet frames which is inherently quicker and less latent.
3. FCoE uses less CPU than IP encapsulations, as the segmentation of data and encapsulation of data into Ethernet frames requires less CPU than the creation of a TCP packet AND an Ethernet packet.

Some Business Benefits of FCoE converged networks for data center managers:
1. Lowers the cost and complexity of interconnect media by providing a single shared infrastructure;
2. Provides a seamless migration path by allowing networks to be migrated to a converged network without doing a rip and replace disruptive migration;
3. Preserves current investments in media while setting a strategic foundation for a future converged network by acquiring new servers with FCoE initiators;
4. Simplifies management by providing centralized network management.

Planning for FCoE allows to you begin to build an FCoE infrastructure that, over the next year or so, will progressively get less expensive on a per-rack basis as market adoption increases. By being better prepared for FCoE now, your data center will be better positioned for a more aggressive rollout, as prices come down and capabilities increase, than those data centers that wait and don’t even think about FCoE for the next few years.

Article by Satheeshiyer.

On December 15th and 16th, Cisco will be hosting a virtual trade show to highlight the Journey to the Virtualized Data Center.  Cisco has brought together 11 partners to share with you the best ways to solve the toughest data center challenges in networking, storage, applications, and physical infrastructure technologies.

Chris Carrier, Director of Marketing for EMC’s virtualization practice and I will be doing a Live Chat (Tuesday, December 15th, 1pm Eastern, 10am Pacific) from the EMC booth in the virtual trade show.  In addition to the top ten considerations for virtualization from Chris and the top ten considerations for networking from me, we look forward to answering your questions.

It’s been a busy year in both the networking and virtualization spaces; as we wrap up 2009, we hope you’ll take the opportunity to join us for this discussion.

For more on the conference, see Cisco’s Data Center Networks blog and register at the DCoF site.

If you are interested in continuing the discussion on storage networking, please consider subscribing to this blog.

Stuart Miniman

http://blogstu.wordpress.com

Andy is an Infrastructure manager with 3 direct reports – Bob, Cecil, and Dan. Andy tells Bob he is responsible for purchasing a Blu-Ray player for Andy’s office with a budget of $300. Andy tells Cecil he is in charge of purchasing a Gaming console for Andy’s office, also with a $300 budget. Finally, Andy tells Dan is is in charge of purchasing a Netflix-streaming device for Andy’s office also with a $300 budget.

Each employee spends the full $300. Bob purchases a Samsung Blu-Ray player and gives it to Andy. Cecil purchases an X-Box for $300 and gives it to Andy. Dan purchases a DVD player that can stream Netflix movies for $300 and gives it to Andy.

Anyone who follows the gaming console market is probably thinking to themselves, wow; a PS3 costs $250, plays blu-rays, is a gaming console, and can stream netflix so Andy could have just gotten one of those and saved himself $650. That’s an obviously valid point, but Andy doesn’t know that. Andy deferred to his “experts” and each one of them chose the product they thought best fit Andy’s needs. Bob, Cecil, and Dan did the job that was asked of them and successfully delivered a solution that was within budget and met Andy’s requirements. Obviously though, the solution(s) could have been more “cost-effective.”

If Andy had brought Bob, Ceil, and Dan together and let them talk through the products at which they were looking, they probably would have noticed that the PS3 showed up on each of their lists. While it might not have been the top item on any of their lists, it more than likely would have became the overwhelming favorite due to the huge cost-savings involved. Since Andy didn’t know such a device existed, he didn’t think his team needed to work together.

It’s that type of thinking that slows innovation. Andy would have been much better served putting his 3 employees in a room to discuss what they were working on. By encouraging collaboration, even though it didn’t seem necessary, the team would have delivered an adequate solution at 30% of budget. Alternatively, if such a solution didn’t exist, the team would have merely lost a bit of time. Over-communication is almost always preferred to under-communicating.

How does this relate to IT and networking? As Unified Communications, VoIP, Virtualization, and SAN technologies continue to change, vendors are having to rethink their solutions. Once upon a time, a vendor would sell both switches and routers to a customer in hopes of getting all of their business. Both sides quickly realized though that devices such as routing switches held a tremendous value. While it’s a good example of convergence, the team to whom a vendor was selling the equipment was typically still the networking team. As vendors have recognized the convergence of storage and networking via technologies like FCoE, they’ve begun offering solutions that consolidate the two functions. The problem now though is that the vendor needs to sell two separate teams (storage and networking) on its product. Since each team usually has its own budget, lifecycle roadmap, and vision/strategy, this presents a problem. Being an expert at either storage or networking usually requires that you spend a fair amount of time in your cube researching, testing, piloting, and implementing new technologies in your own arena.

Let’s assume now that Andy leads an Infrastructure team. Bob is now a Network Engineer and Cletus is now a Storage Engineer. Andy simply tells Bob and Cletus that the network needs to keep networking and the SAN needs to keep storing. Andy doesn’t know switches exist that can help consolidate the two functions, and neither do Bob and Cletus. If Andy is leading his team properly, Bob isn’t just concerned with networking and Cletus isn’t just concerned with storage. Rather, Bob and Cletus are collectively concerned with Networking and Storage. It’s through that collaboration that companies can leverage the savings provided by convergence.

In my dream scenario, Andy actually leads an architecture team on which Ernest works as an Infrastructure architect. Since Ernest doesn’t have to spend as much time being locked into specific solutions, he is able to watch for the newest and greatest technologies so he can determine which could potentially provide value to the company. Ernest would be able to notice the potential savings brought about by these new switches and can tell Bob and Cletus to look into them. This way, Bob and Cletus are both able to continue being subject-matter experts while the organization is still able to derive value from new technologies.

La gamme Nexus est déclinée pour le blade center IBM qui peut ainsi bénéficier de l’apport du 10Gb et du FCoE

Voici quelques exemples de déploiements:

pour en savoir plus

First, if your interested in the new Cisco UCS blade system and haven’t checked out the Varrow channel on YouTube lately, you should.  We’ve added several new videos from a customer while doing their UCS install.  Pretty neat stuff.

Just finished up another video for our collection.  This one walks you through configuring Fibre Channel over Ethernet (FCoE) on a Cisco Nexus 5020 switch.  As you’ll hear me say several times in the video it’s not hard, especially if you know how to configure a Cisco MDS switch.  It’s very, very similar with just a few new steps on the front-end of the configuration.  In the demo I take a vSphere server with Emulex CNAs and connect it to an EMC CLARiiON array via FCoE over the Nexus 5020.

• YouTube Channel
• ScreenCast (higher resolution)

If there is anything that you’d like to see demonstrated on a video just let us know and we’ll do our best.

L’arrivée du FCoE et sa mise en oeuvre dans le switch d’accès Nexus 5000 permet de parler de “Unified Fabric Topology”. Ceci ouvre de nouvelles perspectives pour les datacenters et en particulier permet ,tout en offrant plus de bande passante aux serveurs ,de réduire considérablement le câblage, les cates adapteurs, la consommation éléctrique et les besoins en refroidissement.

Les projets de virtualisation de serveurs sont en général le bon moment de revoir la topologie des architectures car l’expérience a montré que pour aboutir , un projet de virtualisation doit avoir une vue holistique des ressources.

a lire ce document

Emulex and IBM announced today the availability of a new Emulex expansion card for blade servers that allows for up to 8 virtual nics to be assigned for each physical NIC.  The “Emulex Virtual Fabric Adapter for IBM BladeCenter (IBM part # 49Y4235)” is a CFF-H expansion card is based on industry-standard PCIe architecture and can operate as a “Virtual NIC Fabric Adapter” or as a dual-port 10 Gb or 1 Gb Ethernet card. 

When operating as a Virtual NIC (vNIC) each of the 2 physical ports appear to the blade server as 4 virtual NICs for a total of 8 virtual NICs per card.  According to IBM, the default bandwidth for each vNIC is 2.5 Gbps. The cool feature about this mode is that the bandwidth for each vNIC can be configured from 100 Mbps to 10 Gbps, up to a maximum of 10 Gb per virtual port.  The one catch with this mode is that it ONLY operates with the  BNT Virtual Fabric 10Gb Switch Module, which provides independent control for each vNIC.  This means no connection to Cisco Nexus…yet.  According to Emulex, firmware updates coming later (Q1 2010??) will allow for this adapter to be able to handle FCoE and iSCSI as a feature upgrade.  Not sure if that means compatibility with Cisco Nexus 5000 or not.  We’ll have to wait and see.

When used as a normal Ethernet Adapter (10Gb or 1Gb), aka “pNIC mode“, the card can is viewed as a  standard 10 Gbps or 1 Gbps 2-port Ethernet expansion card.   The big difference here is that it will work with any available 10 Gb switch or 10 Gb pass-thru module installed in I/O module bays 7 and 9.

So What?
I’ve known about this adapter since VMworld, but I haven’t blogged about it because I just don’t see a lot of value.  HP has had this functionality for over a year now in their VirtualConnect Flex-10  offering so this technology is nothing new.  Yes, it would be nice to set up a NIC in VMware ESX that only uses 200MB of a pipe, but what’s the difference in having a fake NIC that “thinks” he’s only able to use 200MB vs a big fat 10Gb pipe for all of your I/O traffic.  I’m just not sure, but am open to any comments or thoughts.

Il y a peu de temps j’évoquais sur ce blog l’arrivée des nouveaux Nexus 4000. Il est désormais annoncé chez IBM

<see updates at bottom>

Finally – information on the soon-to-be-released Cisco Nexus 4000 switch for IBM BladeCenter.  Apparently IBM is officially calling their version “Cisco Nexus Switch Module 4001I for the IBM BladeCenter.”  I’m not sure if it’s “officially” announced yet, but I’ve uncovered some details.  Here is a summary of the Cisco Nexus Switch Module 4001I for the IBM BladeCenter:

• Six external 10-Gb Ethernet ports for uplink
• 14 internal XAUI ports for connection to the server blades in the chassis
• One 10/100/1000BASE-T RJ-45 copper management port for out-of-band management link  (this port is available on the front panel next to the console port)
• One external RS-232 serial console port  (this port is available on the front panel and uses an RJ-45 connector)

More tidbits of info:

• The switch will be capable of forwarding Ethernet and FCoE packets at wire rate speed. 
• The six external ports will be SFP+ (no surprise) and they’ll support 10GBASE-SR SFP+, 10GBASE-LR SFP+, 10GBASE-CU SFP+ and GE-SFP.
• Internal port speeds can run at 1 Gb or 10Gb (and can be set to auto-negotiate); full duplex
• Internal ports will be able to forward Layer-2 packets at wire rate speed.
• The switch will work in the IBM BladeCenter “high-speed bays” (bays 7, 8, 9 and 10); however at this time, the available Converged Network Adapters (CNAs) for the IBM blade servers will only work with Nexus 4001I’s located in bays 7 and 9.

There is also mention of a “Nexus 4005I” from IBM, but I can’t find anything on that.  I do not believe that IBM has announced this product, so the information provided is based on documentation from Cisco’s web site.  I expect announcement to come in the next 2 weeks, though, with availability probably following in November just in time for the Christmas rush!

For details on the information mentioned above, please visit the Cisco web site, titled ”Cisco Nexus 4001I and 4005I Switch Module for IBM BladeCenter Hardware Installation Guide“. 

If you are interested in finding out more about configuring the NX-OS for the Cisco Nexus Switch Module 4001I for the IBM BladeCenter, check out the Cisco Nexus 4001I and 4005I Switch Module for IBM BladeCenter NX-OS Configuration Guide

 UPDATE (10/20/09): the IBM part # for the Cisco Nexus 4001I Switch Module will be 46M6071. 

 UPDATE # 2 (10/20/09,  17:37 PM EST): Found more Cisco links:
Cisco Nexus 4001I Switch Module At A Glance

Cisco Nexus 4001I Switch Module DATA SHEET

New Picture:

Las redes Ethernet son una parte imprescindible para el funcionamiento de cualquier empresa. Este protocolo, (Ethernet), inicialmente diseñado para permitir el intercambio de datos entre operadores, es desde hace tiempo el sistema mas utilizado a nivel mundial para la transmisión de datos.

Ethernet, cabe recordar que es “un protocolo”, que define el funcionamiento de las capas 1 y 2 del modelo OSI, y que no tiene porqué ir acompañado del TCP/IP (protocolos de capas superiores), aunque sea muy habitual.

Por otro lado, las redes de almacenamiento que inicialmente se crearon sobre interface SCSI, han ido migrando en los últimos años a fibre channel, gracias a su superioridad en todos los aspectos.

Fibre channel  (FC) es una forma de transferir los comandos SCSI, que gobiernan los sistemas de almacenamiento, mediante el envío de señales ópticas  a través de fibra.

El problema de este sistema radica en que son redes mas complicadas que las ethernet y su coste es mayor, dado que requieren de electrónica especializada  (normalente de gama alta) y precisan personal más especializado tanto para su implantación como para su gestión y optimización posteriores y futuras.

El protocolo iSCSI, nos ha venido a traer un sistema, para gama baja y media, que permite encapsular los comandos SCSI sobre tramas TCP/IP y sobre una red ethernet normal. Este sistema está muy bien, pero cuando se precisa un gran rendimiento y fiabilidad los sistemas de fibra siguen siendo superiores.

El mercado (por medio de un conjunto de 10  grandes empresas y varios organismos como el IEEE), ha buscado y finalmente desarrollado un nuevo sistema llamado CEE, que no es otra cosa que una nueva Ethernet (Convergence Enhanced Ethernet) que en su primera versión parte de velocidades de 10 Gb.

Significa que rinde mas que fibre channel?, no necesariamente en esta primera verión (las características para redes de almacenamienot de FC son dificilmente superables), si bien dispone de un roadmap que no ha hecho sino empezar a ser desarrollado.

CEE no es compatible con las redes Ethernet actuales y su implantación aun muy costosa. Únicamente, CPDs de gran tamaño y para una inicial implantación pueden beneficiarse del sistema dado que pueden disponer de una única red  para comunicaciones y almacenamiento en vez de las “dos” clásicas (FC_SAN+Ethernet).

La búsqueda de esta nueva tecnología, ha sufrido la presión de la evolución de las redes de almacenamiento que buscan sistemas mas económicos y flexibles que los actuales y aqui CEE viene a tapar ese hueco.

Debía ser un sistema que permita la convergencia de ambos sistema de red y les permita crecer de forma conjunta, y parece que puede ser el camino a seguir…en un futuro.

El problema que inicialmente aparece, radica en que las tramas FC son mayores que las Ethernet y por ello se utilizan tramas “Jumbo“, para encapsular las tramas FC. De este modo, la nueva red ethernet permite incorporar servicios de almacenamiento sobre el mismo canal que los datos de comunicaciones con rendimientos similares a los de FC y por tanto economizar, en un futuro, las infraestructuras de red de las empresas. A este sistema de encapsular FC sobre CEE, es a lo que se ha venido a denominar FCoE (Fibre channel over Ethernet), pero tiene que quedar claro que no es posible realizar este tipo de transmision sobre las redes ethernet “clásicas”.

En cualquier caso, la hegemonía de fibre channel como sistema lider de entornos de almacenamiento y ethernet clásico como sistema de red, aun perdurará durante una serie de años, porque los costes y rendimiento de CEE y FCoE, aun no son ni tan ventajosos ni aportan rendimiento como para que los CIO, los tengan entre sus posibles cambios a medio corto, y medio plazo.

A while back, I discussed speculation from EMC around Emulex’s proposed cloud-block storage appliance, E3s (Enterprise Elastic Storage).  With my current focus on Cloud Storage, I thought it would be good to delve a bit deeper into some of the aspects of why block-based cloud computing could prove tricky and why without an appliance it may be impossible.

Block Storage Legacy

Today, block-based I/O still uses the SCSI protocol to communicate between a host/server and a disk storage device.  SCSI has been around since 1981 when devices were physically connected to the server itself using a controller board and old-style ribbon cables.  Obviously we’ve progressed somewhat since then and seen the virtualisation of the physical SCSI interface into Fibre Channel and IP SCSI implementations (and in the future FCoE).  Both FC and iSCSI have removed the need for a dedicated SCSI controller card and replaced it with Host Bus Adaptors (HBAs) and Network Interface Cards (NICs).  Irrespective of this, the underlying communication protocol remains the same and the concept of the “Initiator” (host/server) and “Target” (storage device) persist today.  The Initiator starts (or initiates) an I/O request; the target services that request, reading or writing data.

Writing In Blocks

We need to focus for a moment on the concept of block-based I/O versus file-based I/O.  Block-based I/O has no concept of the format of the data being written to the block device (let’s call it a LUN).  This is in contrast to file-based I/O where the storage device understands the data format and manages the content accordingly, ensuring data access is serialised correctly and that files are held in a logical structure (a file system).  Unfortunately block-based I/O is just “dumb” storage and the host itself is responsible for overlaying a file system onto block-based devices.   These JBBDs (“Just a  Block-Based Device”) can be used singly or combined in complex ways to create the file system the host sees.  This combination can be achieved using native Logical Volume Managers (LVMs) on the operating system, or add-ons such as Veritas Volume Manager.  Consequently, an individual LUN could contain an entire file system or only a small component of one.  Either way, the host operating system depends on one feature of the storage device to ensure data integrity and that’s Write Order Consistency.

Write Order Consistency

Preserving the order in which data is written to disk is a fundamental requirement for modern Journalling file systems like NTFS.  Retaining write consistency ensures the file system can be recovered in the event of a server failure or failure of the link between server and disk.  Ordered writes are also essential where data is replicated from one storage array to another usually at a remote location.  In the event that the primary array is lost, the file system can be recovered in a consistent fashion on the remote device, even if it isn’t 100% up to date.

Remote replication can occur either synchronously or asynchronously.  In synchronous mode, I/Os are acknowledged from the remote array before the I/O is confirmed as completed to the host.  This ensures both the primary and remote copies are write-order consistent because the host doesn’t receive acknowledgement of I/O completion until both the local and remote copies are written.  Write-order consistency is implicitly guaranteed.  However, the penalty for this guarantee is the increase in latency (or host I/O response time) which results and increases with the distance between the two devices.  Asynchronous replication is slightly different.  Write I/Os to the primary array are acknowledged immediately, then queued up for writing to the remote device.  The delay in writing data to the remote location is dependent on the bandwidth available and the latency (effectively the distance) between the devices. In any event, as long as write-order is maintained, the remote copy can be recovered even if it doesn’t represent the absolute latest copy of data.  One last consideration.  We touched earlier on how LVMs can combine single LUNs to create complex file systems.  When asychronous replication is involved, write I/O for a single entity like a file system need to be treated together for write-order consistency.  Therefore Consistency Groups allow multiple LUNs to be grouped together for write ordering, ensuring that all I/O for the file system is ordered correctly.  This requirement doesn’t exist for synchronous replication as the consistency is guaranteed by ensuring the write I/O has completed on both the source and target array before acknowledgement to the host.

The Need for an Appliance

Knowing how write-ordering affects consistency is important in understanding how a block-based device would be replicated into “the cloud”.  Due to latency issues, it is unlikely that synchronous replication would be offered as a method of replicating data from a host server into Amazon S3 or EMC Atmos.  Instead, the most likely process will be asynchronous processing and that means installation of a dedicated appliance.  The question is, where in the data path should it sit?

The Splitter

There’s no requirement for a host/server to be connected into a storage array in order to utilise cloud storage.  Instead, at some point in the data path between host and local disk, a copy of the write I/O needs to be taken.  This could occur at the file system level using a host agent or in a SAN environment could happen in the fabric or from the array itself.  Wherever data is taken from, some form of “I/O splitter” is needed to capture write I/O as it is being transferred to disk.    This technology already exists today in products like EMC’s RecoverPoint and Brocade’s Data Mobility Manager.

So here are our requirements for a block-based storage protocol:

• Write Order Consistency
• Consistency groups
• An I/O splitter or replicator

A Theoretical Implementation

Here’s how I think block-based storage could be implemented.  I’ll use the Atmos and Amazon S3 protocols to demonstrate the process.  Firstly, data will be stored in blocks.  Both S3 and Atmos store data as objects and so each object will need to represent a block.  The file system structure can be used to store individual LUNs, with a directory representing a LUN.  For example LUN 12, block 12343 could have the object name:

\S3\Array1\LUN12\12343

It’s worth noting that there’s a distinct difference between the way Atmos and S3 implement updates to objects.  S3 replaces the entire object, whereas Atmos allows part of an object to be updated.  So, Atmos could store an entire LUN as an object whereas S3 can’t, unless the entire LUN is replaced on each write.  Clearly that’s impractical but does indicate that each API implementation will have certain benefits and disadvantages.

So, how big are these blocks going to be?  Ideally, they’d be as small as a typical hard drive block at 512 bytes, however blocks of this size will seriously hamper throughput if write consistency is to be maintained; imagine 5ms latency into the cloud; that’s only 200 IOPS and consequently a throughput of 100KB/s. What’s more practical is a block size matching the O/S  file system and/or database, say 8KB.  Even at this size, with 5ms latency and a single thread of I/O, that’s only 1.6MB/s throughput.

Obviously this level of throughput is not going to be acceptable and there’s a real sticking point here.  The cloud isn’t intelligent.  It will write data as it’s received.  There’s no locking control and the delivery mechanism could be unpredictable.  If writes are issued in parallel, there’s no way to guarantee the I/Os are written to the cloud in the right order.  So perhaps a different approach is required.  Data writes to the target LUN need to be written in a log format, with the name of the object comprising both the block number and a sequence number.  This could be something simple as follows:

\Atmos\Array1\LUN12\SequenceNumber-BlockNumber

e.g.   \Atmos\Array1\LUN12\123445343434366-12343

As the LUN is written to, the sequence number (unique to the LUN or consistency group) is incremented for each write.  The I/Os can then be written in parallel as the sequence numbers track what has and has not been received.  At this point there are two choices – retain all the block updates (unlikely due to the growth in storage usage) or post process the writes, deleting all the written blocks where another later copy exists and where there are no gaps in the sequence numbers.  If there is a gap, then the LUN writes are only guaranteed back to the point where the sequence number gap occurred.  Restoring the LUN for access means processing the LUN block data before it can be read again by the host.

Summary

OK, so this post presents an idea of some of the issues involved in writing block-level data into the cloud.  Data needs to retain integrity and consistency, but performance and throughput are an issue.  Cloud storage has no intelligence, so writing and managing data needs to be handled somewhere, probably using an appliance.  The appliance guarantees the data integrity which can’t be achieved with the cloud alone.  Each Cloud Storage API implementation will have similar features, so using generic CRUD (Create/Read/Update/Delete) commands on objects representing blocks means any service could be used to store data.  It also enables data to be replicated between services so vendor lock-in can be avoided.

I’d be interested in receiving feedback to see if anyone else has thought how block-based cloud storage could be achieved.

Here is the 3rd video in a series to help educate on Fibre Channel over Ethernet (FCoE):

For a full list of EMC FCoE resources, see my previous post The current state of FCoE.

Additionally, on the question of “end-to-end Ethernet”, see the discussion on Scott Lowe’s Why No Multi-Hop FCoE? blog post.

Both Cisco and Brocade have made announcements about new products for expanding the FCoE ecosystem.  Cisco’s Nexus 4000 provides the blade switch functionality that I discuss in the video.  They also have a whitepaper on FIP (FCoE initialization protocol) and FIP snooping which is part of what is needed for a multi-hop environment.  Brocade announced an FCoE blade for the DCX FC director product line.

Let me know if there are any related topics that you would like to see covered.

Comments are questions are always welcome and please consider subscribing to this blog.

Stuart Miniman

http://blogstu.wordpress.com

Our client is looking for a Storage Diagnostic Test Engineer.  This is a full time position in the San Francisco Bay Area.

This individual would be a principal diagnostic and test engineer for FCoE (Fibre Channel over Ethernet) development. This engineer will be responsible for Protocol conformance testing and test plan development and execution of a FCoE SAN Fabric designed around a converged NIC adaptor or CNA.

Description:

Major functions and duties:

• Debug issues with Fibre Channel , block devices, fabric switches and HBAs
• Develop test suites and code instrumentation to evaluate HBA performance and protocol conformance
• Interact with team in multiple locations
• Unit test and replicate SAN Fabric issues
• Design and communicate solutions and plans effectively

Detailed knowledge of:

• SCSI Protocol for block based devces
• Fibre channel protocol and SANs

Interactive Skills:

• Interact with the team, vendors and customers to replicate and solve issues rapidly and efficiently
• A pragmatic approach to prioritization of tasks
• Communicate clearly and succinctly solutions and analysis

Requirements:

• Minimum 10 yrs development experience.
  Fibre Channel expertise in SANs including debugging protocol problems a plus
• Masters Degree in Electrical Engineering and CS

If you are interested, please send your resume to kathy@mindsource.com.

Nigel Poulton has been posting some good articles about FCoE on http://blogs.rupturedmonkey.com/. It’s good to see a good discussion taking place, many people still don’t understand the basics, so it’s good to repeat and if you look at the details hopefully people will understand that FCoE shows great promise, with the caveat that we are still very early in the maturation of the technology.

A brief update on FCoE related standards

T11 FC-BB-5 has been ratified by T11 (so it is “done” although it still goes through some processing which is typically a “rubber stamp).

T11 FC-BB-6 is starting up and while the charter and timeline are not finalized, it will be discussing how to create larger FCoE configurations (allowing for creation of a “CEE Cloud”).

IEEE Data Center Bridging: the link level components (Priority Flow Control, Enhanced Transmission Selection and Data Center Bridging Exchange Protocol) are defined and should be ratified soon.  Congestion Notification is a 2010 target.  Layer 2 multipathing will be handled by the IETF TRILL standard which is defined, but not yet in products.

For more on the standards, see the presentations and papers below.

Product configuration today

EMC is supporting FCoE switches from Cisco and Brocade; Converged Network Adapters (CNA) from Emulex, QLogic and Brocade; OSes supported are Windows, Linux and VMware [as always, see the E-Lab Navigator for the latest]

Today, the configuration is from a CNA to FCoE switch (must have a switch, no support according to FC-BB-5 for server to storage w/o a switch; if you need this, use iSCSI) and from the switch you can then plug into the existing LAN and SAN.  Storage can either be plugged into the configuration via the SAN (through existing FC switches) or directly into the FCoE switch (today via FC or via FCoE when available).  Note that configurations of having FCoE traffic go through multiple FCoE (Ethernet) switches will require the updates which are being worked on in FC-BB-6 (although a small expansion of configurations specifically with blade servers should be able to be supported soon).  FCoE today is a consolidation at the server and access layer – full end-to-end solutions with larger aggregation will take time.

I have worked on a lot of FCoE collateral over the last year and thought it would be useful to create a list for reference:

YouTube

Intro to FCoE w/ EMC http://www.youtube.com/watch?v=EZWaOda8mVY – basic 101 of the technology

Deploying FCoE w/ EMC  http://www.youtube.com/watch?v=y6IHMXEGRXs – the new equipment that you’ll need including cables, adapters and switches

FCoE Ecosystem http://www.youtube.com/watch?v=ExxilbDvZ1g – see FCoE Ecosystem post for more details

FCoE discussions w/ Kash Sheik of Cisco on the Storage (http://www.youtube.com/watch?v=GTz9S0cSdNo) and Network (http://www.youtube.com/watch?v=r1mI-eB8-iE) implications of fcoe

Presentations

My EMC World 2009 presentation: Fibre Channel over Ethernet (FCoE), iSCSI and the Converged Data Center – http://www.slideshare.net/stuminiman/fibre-channel-over-ethernet-fcoe-iscsi-and-the-converged-data-center

Innovation Network Lecture – Journey Towards the Converged Data Center (archived webinar) https://community.emc.com/docs/DOC-4398

Papers

Introduction to Fibre Channel over Ethernet (FCoE) http://www.emc.com/collateral/hardware/white-papers/h5916-intro-to-fcoe-wp.pdf (Updated Nov ‘09)

Fibre Channel over Ethernet Techbook [from EMC E-Lab] http://www.emc.com/collateral/hardware/technical-documentation/h6290-fibre-channel-over-ethernet-techbook.pdf

The other day I wrote a bit about UCS and the idea behind it.  This time I want to go a little deeper in to the components that make up a UCS system and how they connect.  One thing about Cisco is they offer very modular solutions.  Usually this is great but it can be confusing on what actually makes up a complete solution.

5100 Blade Chassis

The first thing you need is a chassis to put all your parts in.  Without that..you just have a bunch of boards and nothing to do.  The 5100 Blade Chassis is the house for the system.  It’s a 6U (10.5″) enclosure that can hold 4 or 8 blades, depending on the configuration.  The image below shows a chassis with four half-width and two full-width blades.

If you look at the picture you’ll see four modules at the bottom.  Those are the power supplies and are, of course, hot swappable.  Power is plugged in the back and the supplies up front.  There are also 8-redundant hot swap fan modules.

B-Series UCS Blades

Blades are the servers of the system and what do the real work.  The UCS platform offers both half-width and full-width blades. This is a half-width blade.

The major difference between the two is in memory capacity.  The half-width has 12 DDR3 slots while the full-width has 48.  This lets you have more memory with lower density chips and therefore gives you support for more VMs per blade.  The full-width blade also gets a full 40Gb I/O connectivity where-as a half-width gets 20Gb.  This is due to the fact that the half-width has 1 mezzanine slot while the full has 2.  More on that below.  Both of them support two of the new Intel 5500 Nehalem CPUs.

UCS Network Adapter

We just mentioned mezzanine slots on the blades.  These go in those slots.  There are two types, dual-port 10Gb Ethernet and dual-port CNA (Converged Network Adapter) that offers FCoE (Fibre Channel over Ethernet).

As we mentioned earlier, the half-width card can support one of the interfaces and the full-width card can support two, and therefore gets more I/O capability.

2100 Series Fabric Extenders

This is the last piece that goes in the chassis and gives the entire unit outside connectivity.  Each 5100 chassis has two Fabric Extender module bays.

Each module has four 10Gb connections to give you a total of 80Gb of I/O throughput in and out of the chassis.  The modules handle all load-balancing and failover.  No separate fibre channel connectivity is needed, remember, we’re doing FCoE.

6100 Series Fabric Interconnects

At first thought you’d figure that a UCS Chassis would connect to one of the Cisco Nexus switches, and you’d be partially correct.  The 6100 Interconnect is basically a Nexus 5K but with some extra functionality for managing a UCS enabled fabric.

So each UCS chassis is connected to one, or preferably, two of these interconnects.  Much like the Nexus 5000 line there are two models, a 20-port 1RU and a 40-port 2 RU.  The 1RU has a single expansion module port while the 2RU has two…again, just like the 5K.  In that slot you can put your FC modules to enable FCoE.  Looks familiar.

Conclusion

So that’s it.  Those are the basic components of the integrated UCS blade system.  Remember that Cisco is also offering the UCS blades in a 1RU rack server solution without the blade chassis.

Oh yeah…if you’re a beer drinker, and you are…right?  I suggest you go enjoy the season’s new brews.  My recommendation right now is Weyerbacher Imperial Pumpkin Ale.  I love this time of year.  Also recommended is the Dogfish Head Punkin Ale.  Pumpkin muffins are also back at Starbucks…not a good thing for me.

I guess the topic of convergence is getting a lot of hype if even Dilbert is talking about it:

Sounds like they could use a private cloud solution.

Not only didn’t I need to make any edits to the strip to make it very relevant, but thanks to the wonders of the web, it is so easy to share or embed this without having to worry about copyright infringement.

∩ is the symbol for intersection.  As I always suspected, the intersection of innovation, social media, storage and virtualization is Dilbert.  Now I just need a good Venn diagram for the header for this blog – anyone with graphic talents want to help me make one?

There has been a lot of activity with Fibre Channel over Ethernet (FCoE) over the last couple of months.  In June, the T11 FC-BB-5 group ratified the standard.  Cisco has started shipping their Unified Computing System (UCS) which integrates FCoE – see EMC’s full support statement and a whitepaper showing UCS support with VMware and EMC Storage.

In examining FCoE, the technology maturation and cultural impacts of converged networking must be considered.  There are two upcoming webcasts that will examine these issues.

First, Dave Vellante of Wikibon will be hosting The Business Impact of Converged IT.

DATE: Tuesday, August 11, 2009; TIME: 12:00-1:00 pm PT / 3:00-4:00 pm ET

Free registration at http://info.emc.com/mk/get/AMA00017798_LP?reg_src=IN

It will be a discussion with customers looking at both the storage and networking groups and how convergence will affect their operations.  One of the great things about FCoE is that for customers that have Fibre Channel (FC) today, their current applications and storage management practices can continue unchanged; as shown in the diagram below, above the adapter and in the SAN, the packets are still FC.

In the second webcast, I will be presenting The Journey Towards the Converged Data Center: Fibre Channel over Ethernet (FCoE) and iSCSI.

DATE: Wednesday, September 2, 2009; TIME: 11:00 am-12:00 pm PT / 2:00-3:00 pm ET

Free registration at http://info.emc.com/mk/get/18233_raf_lp

It is the September installment of the EMC Innovation Lecture Series, you can find links for upcoming and archived presentations on the EMC Community Network site.  I will discuss the history of technologies that have attempted to provide a single network for all traffic, how we are now developing solutions that will allow us to reach this ultimate goal and how we expect the solutions to mature over time.  As noted futurist Paul Saffo has stated, change never happens linearly, it happens as an S-curve where we overestimate how fast change will start and underestimate how fast it will take off once it gets going.

For more FCoE information including videos and presentations, please see my old blog site http://nohype.tumblr.com/tagged/fcoe

If you are interested in continuing the discussion on FCoE, please consider subscribing to this blog.

Le Japon est sujet aux tremblements de terre, c’est sans doute cela qui a poussé SAP a tester dans son laboratoire de Tokyo les solutions de disaters recovery .

 Parmi les objectifs de ces tests il s’agissait entre autre :

de tester un DRP avec les solutions DR de VMware et du stockage de NetApp

d’améliorer les performances d’environnement virtualisé à l’aide de technologie Xeon 5500 d’Intel

de mesurer l’apport du FCoE

d’utiliser les technologies d’optimisation du WAN de Cisco.

plus de détail dans ce document.

http://www.latimes.com/business/la-fi-emulex10-2009jul10,1,1956828.story

“Broadcom originally launched its unsolicited bid for Emulex on April 21. The $9.25-a-share all-cash offer valued Emulex at $764 million. It raised its bid to $11-a-share, or $912 million, on June 29. The offer was set to expire on July 14.”

Also today, Emulex said non-GAAP earnings in their 4th fiscal quarter ended June 28 were at the high end of its forecast of 1 cent to 5 cents a share, excluding some costs. Sales were $78 million to $79 million.  Third quarter total net revenues were $78.6 million, a decrease of 39% from the comparable quarter of last year and a 28% sequential decrease.  Third quarter GAAP net loss was $6.0 million, or $0.07 per share, compared to GAAP net income of $15.5 million, or $0.19 per diluted share, reported in Q3 of fiscal 2008 and net income of $10.5 million, or $0.13 per diluted share, in Q2 of fiscal 2009.”  (source: Emulex press releases.)

Talks between the two companies opened in December, with Emulex responding in January that it “was not for sale.”  Pretty sure, as a public company, that it’s for sale 5 days a week.  Emulex then responded by writing a so-called “poison pill” into its bylaws in January, which in corporate governance circles is generally seen as an excellent way to entrench management at the expense of shareholders.  

No doubt Emulexis looking back to two years ago, when their stock peaked at $23, and saying that’s what we are worth.  I bet that Emulexemployees would like to take the same approach to their Southern California home values, but the marketplace doesn’t care about what something was worth before, the only thing that counts is now. 

Speaking of value, let’s do the math: The Emulexbusiness has declined sharply (they have lots of company in this) and is at present unable to generate a profit on a real basis.  FY 2008 sales were $488M, but FY 2009 sales are clocking in at around $379M, a 22% decrease.  Actual earnings for the year look to be $2.6M.  With a deal on the table at $912M, that works out to 2.4 times sales and an eye-popping P/E ratio of around 350!   ELX was trading at $6.61 prior to the original Broadcom offer back in April, so the final offer of $11 per share represented a 66% premium.  Shares have now dropped back to below $9. 

While it’s tempting to say that the Emulex board was negligent in their duties to the shareholders, in fact any small investor had plenty of opportunity in the open market to get the bid price.   Anyone who held out hoping for a third offer from Broadcom or for some undisclosed third party to enter the fray is licking their wounds today.

Market Movers by Will Swarts this morning: ” Bottom Line: Sell.  Emulex faces tough competition in a difficult environment, and investors should take whatever added speculative value remains in the aftermath of a busted deal.”

http://www.smartmoney.com/Investing/Short-Term-Investing/Stock-Picks-TGT-Up-ELX-Down/

Interestingly,  Needham & Co upgraded Emulex (NYSE: ELX) this morning from Hold to Buy, with a price target of  $11.50.   It’s hard to see how this could be based on the fundamentals, so they must believe there’s someone else out there that wants to make a run at ELX.

WII-FM: Emulex has long enjoyed a market position as the premium provider of Fibre Channel HBAs, especially in the largest IT shops.  This positioning is unlikely to be affected by the corporate maneuvers, and Emulex is working feverishly to maintain a premium position in the emerging FCoE market.  Emulex is likely to find that the new market will present both previous and some new competitors, although the transition to FCoE will take years to complete because of the huge inertia of the FC installed base.  On the shop floor, there should be no effect from Emulex turning away Broadcom.

Aloha!

La virtualisation des serveurs était souvent approchée comme un moyen d’optimiser les coûts de serveurs  sans analyser tous les impacts sur l’ensemble du data center que ce soit sur les méthodes de refroidissement, des procédures de reprises d’activité ou bien encore sur les architectures réseaux.

Depuis un an nous avons organisé en France, pour de nombreux clients, des « workshops  Data Center 3.0 »  présentant la vision Data Center de Cisco. Au cours de ces workshops nous avons expliqué les impacts de la virtualisation des serveurs sur les architectures réseaux. Dit autrement, le réseau peut être un frein au déploiement complet et rapide de la virtualisation s’il n’est pas intégré dès le début de la réflexion sur la virtualisation des serveurs ..  

  L’accueil fait au Nexus 1000 , m’a conforté sur l’importance du rôle du réseau dans la virtualisation des serveurs. Mais le rôle du réseau ne s’arrête pas au Nexus 1000 loin de là.

  Ce document  examine la virtualisation d’un Data Center d’un point de vue architectural , montre comment les différentes technologies réseau jouent un rôle et replace la virtualisation dans une perspective plus large.

pour ceux qui ont assisté à ITI forum voici la présentation faite par Thierry Lottin sur le FCoE

presentation_FCOE

Quelques minutes avant la table ronde de l’alliance VCE du premier juillet, j’ai interviewé Nasser Bagtache, le fondateur de SysConsult sur les avancées technologiques du stockage et leur impact réel dans les entreprises qu’il cotoie comme le groupe Schneider. Dans le cadre du projet GCS du groupe Français, il note que les data centers – situés en Asie et en Grande-Bretagne – restent fréquemment soumis à un manque de souplesse au niveau du provisioning des espaces de stockage. Nasser Bagtache attend une couche de virtualisation du stockage fiable et mûre capable d’encapsuler les équipements matériels d’EMC.
Selon lui, l’arrivée de la technologie SSD (solid state disc) simplifie les opérations d’accès aux grands gestionnaires de données. Les réseaux de stockage iSCSI et FCoE vont également jouer un rôle important, la convergence des réseaux permettant un transport unifié des requêtes (réseau et transport de données des disques) qui va simplifier le travail de l’intégrateur. A propos de l’alliance VCE, il s’interroge cependant : comment VMware, Cisco et EMC vont-ils coopérer pour rendre les données mobiles et la virtualisation complète et totale ? J’espère que les responsables présents ont pu lui répondre durant la soirée…

L’interview du fondateur de SysConsult en image :