Sunday, July 29, 2012

Setting up vSphere Active / Active iSCSI connections to a NetApp FAS2040

I recently had the opportunity to architect a solution consisting of 3 vSphere 5 boxes connecting to a NetApp FAS2040.  Storage connectivity would be via iSCSI.  The storage network would be running off of 2 Cisco 2960G switches, soon to be replaced by stacked Cisco 3750’s. 

The requirements were stock standard, as high a throughput as possible, with as much redundancy as possible.  This meant going active active on the iSCSI links.  Here is how I did it.

NetApp FAS2040 Configuration

This little SAN has 8 1GB Ethernet ports.  Due to the fact that the Cisco 2960G switches does not support multi-link switch aggregation (this is where the 3750’s will come in) I had to come up with a simpler design – what NetApp terms a Single-Mode design.  My design allows for:

  • Two active connections to each controller, thus a total of four active sessions
  • Storage path HA
  • Load balancing across links
  • Uses vSphere storage MPIO as opposed to switch-side configuration

Virtual Interface (VIF) Configuration:

All Vif's are single-mode / active passive
Cont1_Vif01 - e0a/e0b (e0a will be active, connected to switch 1 / e0b passive connected to switch 2) IP –
Cont1_Vif02 - e0c/e0d (e0c will be active, connected to switch 2 / e0d passive connected to switch 1) IP –
Cont2_Vif01 - e0a/e0b (e0a will be passive, connected to switch 1 / e0b active connected to switch 2) IP –
Cont2_Vif02 - e0c/e0d (e0c will be passive, connected to switch 2 / e0d active connected to switch 1) IP –

This image, courtesy of NetApp, explains it infinitely better than my wall of text:-)


I also configured partner takeover for all VIF.  In case of controller failure it allows the remaining controller to take over the VIFs.

Ethernet Storage Network Configuration

On the storage network I had to configure 2 critical settings:

  • Spanning Tree Portfast
  • Jumbo Frames

When connecting ESX and NetApp storage arrays to Ethernet storage networks, NetApp highly recommends configuring the Ethernet ports to which these systems connect as RSTP edge ports.  This is done like so:

Switch2960(config)# interface gigabitethernet2/0/2
Switch2960(config-if)# spanning-tree portfast

Next up, Jumbo Frames:

Switch2960(config)# system mtu jumbo 9000
Switch2960(config)# exit
Switch2960# reload

vSphere Configuration

I am in love with vSphere 5, and one of the biggest reasons for that is the fact that a lot of the configuration parameters that used to be command-line only has been moved into the GUI.  Another reason is Multiple TCP Session Support for iSCSI.  This feature enables round robin load balancing using VMware native multipathing and requires a VMkernel port to be
defined for each physical adapter port assigned to iSCSI traffic.  That said, let’s get configuring:

  1. Open your vCenter Serve
  2. Select an ESXi host
  3. In the right pane, click the Configuration tab
  4. In the Hardware box, select Networking
  5. In the upper-right corner, click Add Networking to open the Add Network wizard
  6. Select the VMkernel radio button and click Next
  7. Configure the VMkernel by providing the required network information.  NetApp requires separate subnets for active/active iSCSI connections, therefore we will create two VMkernels, on the 192.168.1.x and 192.168.2.x subnets respectively.
  8. Configure each VMkernel to use a single active adapter that is not used by any other iSCSI VMkernel. Also, each VMkernel must not have any standby adapters. If using a single vSwitch, it is necessary to override the switch failover order for each VMkernel port used for iSCSI. There must be only one active vmnic, and all others should be assigned to unused
  9. The VMkernels created in the previous steps must be bound to the software iSCSI storage adapter. In the Hardware box for the selected ESXi server, select Storage Adapters.
  10. Right-click the iSCSI Software Adapter and select properties. The iSCSI Initiator Properties dialog box appears
  11. Click the Network Configuration tab
  12. In the top window, the VMkernel ports that are currently bound to the iSCSI software interface are listed
  13. To bind a new VMkernel port, click the Add button. A list of eligible VMkernel ports is displayed. If no eligible ports are displayed, make sure that the VMkernel ports have a 1:1 mapping to active vmnics as described earlier
  14. Select the desired VMkernel port and click OK.
  15. Click Close to close the dialog box
  16. At this point, the vSphere Client will recommend rescanning the iSCSI adapters. After doing this, go back into the Network Configuration tab to verify that the new VMkernel ports are shown as active, as per the image below.


Congratulations, you now have active / active, redundant iSCSI sessions into your NetApp SAN!

Saturday, July 14, 2012

Credibility, Ethics and Bias


I've been working in IT for the best part of a decade, but only got into blogging and the whole social media thing in the last year or so.  I really love doing what I do and sharing it with others, but in putting yourself out there you begin to realise how important ethics are.  There is absolutely no difference between me and the next blogger, apart from the quality of the content one puts up and credibility.

Then something dawned on me, credibility is not just something that should shine through in what you put out there for the public to consume, it is even more important to apply those principles in your day to day dealings.  It was about at that time when I realised that true credibility is something that is exceedingly rare in IT, in my experience.

In my universe, a very quick way to loose credibility is to shoot down and bad mouth a product, vendor or technology you know nothing about.  An example - I am in the somewhat unique situation where my job involves presales and architecting products from the two biggest storage vendors out there, namely EMC and NetApp.  As if that's not enough, I also do the HP EVA portfolio.  The storage field is hugely competitive, and this shows.  I take my job seriously, so I make it my business to know the products I work with as well as possible. 

For me it really is all about analysing the customers technical and business needs and consequently the application of the best technology for their given needs.  And believe me, there is enough key differentiators between the various vendors, that when combined with the customers budgetary requirements that you will be able to determine a best-fit solution, and not this one-size-fits-all that most vendors fixate on.  Unfortunately the amount of FUD and misinformation I've heard from people who really should know better is absolutely astounding.  It gets to the point where the vendors are *actively* just advancing their own best interests with the client and their interests a distant second (or maybe I'm just naive, and that is how its supposed to work?).

As if that's not bad enough, I also do the entire lifecycle of both vSphere and Hyper-V, from pre-sales through to implementing and supporting.  The amount of garbage I hear sprouted is enough to fill a landfill.  Admittedly most of it comes from the vSphere-supporting side of the fence, but the Microsoft partners are quickly catching up.  a Couple of examples I've heard is "Hyper-V does not do the equivalent of vMotion" or "the ESXi hypervisor is 50% faster then Hyper-V".  Complete and utter bollocks in other words.  As I said, the MS camp is quickly catching up and with the confidence and maturity that Hyper-V 3 will bring we'll see the MS guys giving as good as they get.

That being said, there will always be a bit of bias inherent in everyone.  You will develop bias through your career, naturally leaning towards the solutions that you sell and implement.  That is normal and there is nothing wrong with it.  By all means do challenge the opposition's claims, ask them to backup their statements, ask for facts, see through the normal sales BS and question their value propositions.

What is not right is the stuff I was talking about earlier.  At the risk of repeating myself we should all try and avoid spreading FUD intentionally.  Spreading it unintentionally is only slightly worse, because one should always verify claims before repeating it as gospel yourself.  If NetApp, for example, tells me they scored eleventy billion marks on some benchmark whilst EMC flunked out I will investigate.  EMC does knows a thing or two about storage - so there is bound to be a story behind the story.  Conversely, if I hear a EMC partner starting with "No one can touch our Avamar / DataDomain dedupe / our ease of management / etc" my BS detector goes into overdrive.

The ultimate loser here is the customer who gets bombarded with noise and misinformation from all sides, whose job hinges on making the correct decision, who ultimately needs to put his trust in a vendor who is more interested in pushing a brand or technology which might or might not solve a problem and who needs to explain when a solution does not deliver. 

We need to start putting the customer first in everything we do.  In the short term it might not seem the easy / profitable thing to do, but in the long term you will be rewarded.  Credibility is truly priceless, and once you give it up it is very, very difficult to regain. 

Do The Right Thing.