Flash has been quite the interesting party animal in the world of infrastructure and has managed to permeate nearly every piece of technology, although a bit slower than I had hoped. One of the most interesting places that I see it used (from a design perspective) is directly inside a hypervisor – I’ll limit this article to VMware vSphere, but it really doesn’t have to end there. While I’ve written on various producers of server side caching solutions in the past (such as PernixData, SanDisk, NetApp, and thanks to some user comments I will soon cover Proximal Data), I felt it worth the time to look further into the reasons why it has changed from a “cool science project” to what will soon be a staple in server design and virtualization architecture.

Not If, But When

The fact that a flash device, be it an SSD or PCIe card, will be a standard part of future server virtualization builds is simply a matter of time. We’re still in the hey-thats-cool-but-I-don’t-trust-it phase of reality for a lot of organizations, and that’s a well grounded fear built on past experience and a dose of common sense. Early adopters of this technology will be looking for breaking “Chris’ 50% rule” that I made up some time ago. It basically states that companies are typically not interested in adopting risk for anything less than a 50% gain in performance | reliability | pick your verb here.

Cheap Bang for the Buck

The really neat thing about server side caching is that it typically offers at least a 100% increase in overall performance – and that’s a very conservative number. In a write-through model, where writes are still committed on the back end disk array itself, the gains are realized when data is later read from the write-through flash device. Obviously a heavy read environment will drive more of a gain than a heavy write environment, but typical workloads are 60% reads or higher. To be fair, I use the term typical – we’re not talking the transaction log files of a database here (100% sequential writes).

Still, droping latency to near 0 and offering thousands of IOPS for 60%+ of your disk commands isn’t too shabby. Add to the equation a flash device in the $1000-2000 range and a license to run someone’s server side caching software and you’re looking at a relatively cheap cost to entry for a significant gain.

Workload Predictions

The real underlining point for having server side caching become a necessity is due to how our workloads are changing. I see this really going two different ways: next generation server technology allowing us to cram more VMs on a host, and Phase 2 virtualization for Virtual Business Critical Apps (VBCA). In either scenario, the bottleneck continues to be storage related for the vast majority of cases. Without any form of server cache, there’s either not enough IOPS available on the downstream device, the server HBA is being brutalized by IOPS, or the round trip latency is too high for a VBCA. A flash device will absolutely need to be in the server, with further options existing in the array itself (such as controller cache) or surrounding the disk groups (such as a disk cache).

Thoughts

Server side caching addresses a lot of low hanging fruit performance issues. For many commercial and enterprise sized organizations, it provides a low cost way to soak up a significant amount of unnecessary IOPS to the array without being a headache to manage. Most of the market players I’ve mentioned in this post have shown me some really neat ways to non-invasively provide a hypervisor layer cache that virtual workloads are completely unaware exist (one of them still seems to think that guest agents make sense – no!).

I’m looking forward to seeing more advancement in this space, especially around the concept of responsible write-back caching that provides against single points of failure. Kudos to PernixData on that one so far, but I think others will either get there eventually or have some rationale against it.

The post Server Side Caching Is Quickly Becoming a Necessity appeared first on Wahl Network.

I’m spending the day at VMware’s beautiful Palo Alto campus headquarters to attend and discuss the launch of their new vCloud Hybrid Service offering. Both Pat Gelsinger, CEO, and Bill Fathers, GM, Hybrid Cloud Services are giving the press, users, investors, and even many of their employees a first look at the future of VMware’s software defined data center solution (SDDC). Not be confused with the VMware Cloud Evaluation, which was made available to the public in a “test drive” mode earlier this year, the vCloud Hybrid Service (vCHS or a slang version being “vChess”) offering is fully production ready and offers two different consumption models: Dedicated Cloud and Virtual Private Cloud. During the presentation, Gelsinger noted that he expects consumption of both offerings in parallel by customers.

Note: All travel and incidentals were paid for by VMware to attend this event. No other compensation was received.

Cloud Offering Details

The Dedicated Cloud offers a nice chunk of compute and storage in an isolated environment for a customer that has a use case that requires it. The Virtual Private Cloud, on the other hand, is a multitenant environment with burstable compute. Both plans offer similar production support but the dedicated model requires a subscription investment of 12 months or more. Some ideas for use cases could be a Dedicated Cloud area for more stable, predictable workloads, with the Virtual Private Cloud offering a landing point for more dynamic applications or new development.

You can take a look at all of the pricing options on this page.

The Razzle Dazzle

During a very impressive live demo, held by Mathew Lodge ,Vice President, Cloud Services, we saw a Hybrid Migration via a Stretched Deploy. In the demo, a virtual machine was migrated from on premise private infrastructure over to the vCloud Hybrid Service. While the audience did not get to actually see that the networking was operational both before and after, I will give a lot of kudos to the fact that the entire workflow was relatively straight forward. Additionally, the entire process was executed via a connector within the vSphere Web Client.

A look at the vCHS panel for Virtual Datacenters

I’m also quite pleased to see that vCHS will be available via the channel, especially since my employer (Ahead) is part of the Lighthouse program. This will mean that I’ll get my hands dirty with the service with my role as a Technical Architect when a client can benefit from extending their private infrastructure (or cloud) into a hybrid cloud model. In the long run, many companies that use VMware virtualization products have worked to develop a strong relationship with a member of the channel, and it’s a smart move on VMware’s part to allow that interaction to continue with vCloud Hybrid Service.

The Q&A panel answering questions after the announcement
Pictured: Raghu Raghuram, Carl Eschenbach, Bill Fathers, Pat Gelsinger

Public Cloud with vCloud Service Providers

There’s still a very long list of service providers who provide public cloud fueled by vCloud. In fact, a large chunk of them also offer a test drive to get exposure to what the vCloud Powered Service looks and feels like before cutting a PO. One example, Bluelock, has both produced training materials for a TrainSignal course entitled “VMware vCloud Director Organizations” (kudos to Jake Robinson) along with a nifty Recovery-as-a-Service offering that leverages Zerto, whom I have written about from a past Tech Field Day event.

Want to get some great video training on vCloud Director 5.1? I have created a course entitled VMware vCloud Director 5.1 Essentials with TrainSignal with hours of in depth technical content in a live lab format!

Thoughts

vCloud Hybrid Service has the ability to really fill a void that has existed for consumers of VMware vSphere and vCloud – a mostly non-invasive solution that enables them to change from a builder to a broker of IT services. As Pat Gelsinger stated, “Hybrid cloud is all about bridging the line of business needs and IT needs” – I believe this is a goal of most shops.

It was also quite nice to get some time with Pat and my fellow vExperts for a brief chat on the announcement and a quick photo opportunity. He made a point to make sure we all had some input and obviously is well versed with the vExpert program, which is a very awesome thing to behold.

Pictured: Rick Schlander, Bob Plankers, Pat Gelsinger, Chris Wahl, Gurusimran Khalsa

A cool sign holding our seats at the event

The post vCloud Hybrid Service Offering Extends Your Software-Defined Data Center appeared first on Wahl Network.

The idea behind a management cluster is to form a pool of compute that manages the other pool of compute. Much like a tug boat pulling along some massive tanker, it exists as a separate entity to provide management in an out-of-band fashion. These are often a great idea, akin to the rationale of sticking iLO cards on an HP server – sometimes bad things happen, and you need a way to fix them that don’t exist inside of the smoking crater that was decimated. But there is no reason to reserve this idea to only large scale, production ready, enterprise environments – your own home lab can (and should) enjoy these features!

Here are three big reasons to have a management cluster, be it one standalone hosts or an HA pair of them, for your home lab.

1) Home Labs Explode … Often

In fact, that’s sort of the point of a home lab. Unlike a real, production environment, a lab is an area where you can go in with guns blazing and have no fear of causing harm. If something breaks, you’ve learned a valuable lesson that will save you the same headache, usually amplified, in your production environment. But there’s a darker side to this – what if you broke your storage array and lost all your data? Re-building an entire lab environment, even from backups, is a non-trivial amount of time in most cases. You have to have all of the software and/or ISOs available, potentially rebuild a domain controller or two, re-create accounts – the list goes on.

By protecting the guts of your home lab with a management cluster, you can focus on just fixing the broken bits and not an entire infrastructure. It has the added bonus of giving you an even more warm and fuzzy feeling when you are running head long into a brand new process that may cause a spectacular level of lab failure.

2) Rebuild Time

This somewhat ties into the previous statement, but is more focused on the rebuild time to get the lab back to the way it was before you did an update. Let’s take an example of providing some sort of application that needs to talk directly to one of your management servers, such as a domain controller or vCenter. If you only have one layer – in this case the server or a single domain – then an upgrade will affect your entire lab. Even the bits that you don’t want to affect (such as vCloud or View, perhaps?).

Instead, having a management cluster with a unique domain and/or vCenter server will give you a way to still manage your hardware and domain accounts even if your lab was ruined by a faulty application. Additionally, if the application was in fact attached successfully, you can more easily roll it back to repeat the process (I tend to do this frequently for documenting steps, working with beta builds, and writing blog posts).

One caveat to this is that you will need more evaluation licenses for VMware products – this really does suck and is another great point for bringing back the VMTN subscription! It’s less of a headache for Microsoft applications, as their TechNet is awesome and I recommend having a subscription. I’ve had mine for something like 8 years now; it’s worth every penny.

3) Maintenance and Upgrades

The final reason to have a management cluster is to make maintenance and upgrades a simple routine. If you need to run a new bit of code, you can literally power off the entire lab cluster and do that without fear of causing issues with your management layer. And there’s no need to play whack-a-mole with your vCenter server because it lives on a management cluster. Additionally, you’ll have much less need to connect to a host directly, or worry about having to down a domain controller or database server that is used by a number of other services.

It’s definitely nice to put an entire lab into maintenance mode for when you want to go to vSphere version .Next, especially if Update Manager (VUM) is also included in your management cluster!

Thoughts

I happen to use an HP N40L Microserver for my management cluster (here’s how to stick 16 GB of RAM in it), which makes it a “standalone server” model. I’m fine with this risk for the home lab. Even if the drives fail inside of it, I still use Veeam to backup the VMs on a daily basis (although very little changes on there). The huge benefit here is that the N40L is amazingly cheap, often in the $100-200 range, and is a great way to put vCenter, SQL, Active Directory, and VUM into a nice little box.

An example management cluster arrangement with a single vCenter controlling the entire infrastructure

Another idea is just running vCenter from VMware Workstation and and the rest of the lab on physical hardware (I used to do this back in the day). This can work for a budget constrained lab and lets you tinker with the physical hosts as needed. I’m open to other options as well – comment below?

The post Three Reasons To Have A Management Cluster For Your vSphere Home Lab appeared first on Wahl Network.

The use of a Link Aggregation Group (LAG) with Link Aggregation Control Protocol (LACP) is rather standard with converged infrastructure northbound uplinks. This grants additional link redundancy and avoids the need for minor levels of interruption in the event of a single link failure, and when coupled with a virtual port channel (vPC) it can also provide protection against switch failure. However, I have found that the use of a LAG, often referred to as a port channel, can cause some confusion when configuring the vSphere switch side of the equation. Nearly all documentation in the wild focuses on the need to use an IP Hash teaming policy whenever a LAG is present.

Does this also mean that you have to use IP Hash for vSphere switches inside of converged infrastructure, such as Cisco UCS or HP Virtual Connect?

Design Variations

With traditional rack mount server design, a port channel is created between the upstream switch and the vSphere host itself. 2 or more NICs that live inside the hypervisor become member ports in the port channel. In this case, yes, you would need to use the IP Hash teaming policy. This is because the vSphere switch is responsible for handling the load distribution for the port channel.

Converged Infrastructure Differences

With most typical configurations of converged infrastructure, the need for IP Hash is eliminated. The blade switch or interconnect switch handles the northbound connectivity out of the system. Here’s a visual I’ve created for Cisco UCS. In this case, the LAG exists between the upstream switch (not shown) and the uplink ports on the Fabric Interconnects. LACP sends LACPDUs no further than the Fabric Interconnect to form the LAG (port channel). The underlying vNICs on the vSphere switch and hypervisor are unaware that they are ultimately using a LAG for northbound traffic forwarding. The vNICs are connected to a vEth port (in the case of Cisco UCS), which the Fabric Interconnects dynamically pin to the uplink or uplink port channel of their choosing.

The virtual switch (shown in green) can use whatever teaming policy that you wish to give it (although I don’t recommend IP Hash). If your virtual switch is a Distributed Switch (VDS) you can also choose to do Load Based Teaming (LBT) which is called the “route by physical NIC load” teaming policy.

It’s really up to you what makes the most sense based on your network topology – you may even want to pin traffic (here’s a vMotion example). The takeaway here is that you do not need to use IP Hash as the LAG does not touch the virtual switch.

Not All Created Equal

If you are using some sort of direct pass-thru device, which exposes the hypervisor directly to the northbound (upstream) networking infrastructure, you would then indeed need to use IP Hash. There is no “middle man” switch performing the dynamic pinning of vNICs from the host to the converged infrastructure switch. An example of this would be an Ethernet Pass-Thru Module for an HP c7000.

Thoughts

I definitely advise using LAGs on your converged infrastructure deployments for a large number of positive reasons: redundancy, throughput aggregation, better failure handling, etc. Brad Hedlund has some older, but still quite awesome, videos on Cisco UCS on his website here that go deeper into the product. If you have an HP Virtual Connect deployment, you can also find a pile of technical gold on VC 4.X here.

The post How Link Aggregation Affects vSphere Teaming Policies with Converged Infrastructure appeared first on Wahl Network.

Virtual environments are excellent at providing an elastic, scalable environment for a myriad of workloads to thrive. Unfortunately, it’s often too easy to over-provision resources or leave discarded and unwanted workloads, fostering a constrained environment due to virtual sprawl. However, did you know that this can also negatively impact the performance and growth of your critical workloads?

I’d like to extend a welcome to all of my readers (and your friends!) to pop on over to BrightTALK and register for my upcoming presentation entitled “The Devastating Impacts of Virtual Sprawl And Ways To Mitigate Them“ – it kicks off at 3PM CST on Thursday, May 16th. The high level agenda includes:

• Identify virtual sprawl using advanced technical methods
• Dig into performance related issues that can be caused by imbalanced or top heavy provisioning
• Understand how to translate real world sprawl data into a solid business case for change
• Exercise recommended practices to avoid falling deeper into the virtual sprawl trap

I’ve also embedded the webinar below - hope to see you online!

The post The Devastating Impacts of Virtual Sprawl appeared first on Wahl Network.

It’s interesting to watch the position of flash technology among various vendor stacks, along with the messaging and goals. One of the final presentations at Storage Field Day 3 was by a well known storage company: NetApp. This is a nice change of pace from a partial week spent with a heavy presence of start-up companies that are looking to change the world with radical new designs, and I found myself really looking forward to seeing exactly how NetApp wanted to improve their OnTAP design with flash.

There are many places you can put flash to accelerate performance: in the server for server-side caching, in the array to provide write-back or write-through caching, or even the creation of an entirely flash based array. NetApp seems to believe that they can offer solutions in all of these places – but is this reality?

Note: All travel and incidentals were paid for by Gestalt IT to attend Storage Field Day 3. No other compensation was given.

Creating a Hybrid Flash Array

NetApp has enjoyed a lot of success with their use of Flash Cache technology. This is the process of putting a PCIe card inside of a traditional FAS storage array and using it to cache hot read data, thus alleviating the amount of spindle activity necessary to serve up read IOs. This has an added bonus of giving those same spindles additional time to serve up write IOs. As a former NetApp customer, I definitely used Flash Cache in my arrays to offload 20%+ of my spindle activity to the cache.

What I didn’t realize until the Storage Field Day 3 presentation was that the technology uses a first-in-first-out (FIFO) eviction method – I’m still not entirely sure why this was chosen over something like least-frequently-read (LFR or sometimes called LFU for “used”), as FIFO means that a frequently read “hot” block could be ejected to make room for a less important block. However, the hot ejected block would end up coming back into cache on the next read and start the whole cycle over again.

One could argue if this is truly a hybrid flash array. I’d tend to think that NetApp would lean towards “no” as it leads towards their next topic – accelerating storage pools with SSD.

True Hybrid with Flash Pools

Flash Pool is the new slick term for NetApp’s ability to front a pool of spinning disk with SSDs. In a nutshell, the storage engineer must create a storage pool that contains a RAID group of SSDs, which then perform caching duties for all of the volumes within that pool made up of spinning disk. The goal of Flash Pool is to soak up both random reads and random writes, which are brutal on a spinning disk because they have an actual hardware arm that must seek out data on the platter. Sequential writes are sent to spinning disk. NetApp supports a variety of SSD capacities (100, 200, and 800 GB) to help properly size your Flash Pool to what type of workload you are caching.

Because the cache data lives on an actual SSD drive, the information survives a controller (head) failure or restart. I think this is an important point to make because many of the folks who use NetApp storage are aware that the NVRAM is mirrored between controllers, effectively limiting usage to half of the available NVRAM in order to protect the data. Thankfully, this is not the case with the SSDs inside of a Flash Pool.

I will call shenanigans on the other marketing term for the Flash Pool, which is “Virtual Storage Tiering”. I get the reason behind it (gotta check the Tiering box somewhere) but honestly, the idea of traditional tiering of data seems so old school. I’d definitely advise listening to storage Jedi Howard Marks chat about this in more detail.

Server-Side Caching with Flash Accel

Another bit of NetApp’s flash story revolves around server-side caching. I’m very happy to see so much energy around this type of technology, as I had already heard from both PernixData and SanDisk on this very same topic. In the case of NetApp, Flash Accel is being offered for free to existing NetApp customers. Just pop in an SSD or PCIe flash card and off you go – this sounds great, right?

Woah, slow down there my friend. Flash Accel is only specifically supported with VMware vSphere 5.0 on VM guests running Windows Server 2008 R2. Now, that’s not too bad for a first release, as both the hypervisor and guest OS supported are very, very popular. If you don’t believe me, go look at vOpenData showing 26.3% of all environments uploaded running Server 2008 R2. However, the really bad news is that you have to install a host agent in all of your hypervisors, a guest agent in every VM, and then a Flash Accel management console.

As an industry, we’ve spent a lot of our time trying to remove agents from the guest (think antivirus for starters). I think this will be a hard limit, or at least a hard sell, for many administrators in the field. Time will tell.

NetApp All Flash Arrays

An interesting bit of tech called the EF540 was shown towards the end of the session, which is NetApp’s all flash array offering. Rather than using OnTAP, this system runs SANtricity OS. This makes sense to me – OnTAP really wasn’t designed for handling an array composed of all SSDs. The system promises to provide around 300,000 IOPS at 1ms of latency when benched using a 4KB, 100% random 100% read test. No other bench performances were given for a real world scenario (100% reads is a very silly bench), which was disappointing.

The enclosure is a 2U, 24-drive shelf system made up of 800 GB SSDs. It also allows the consumer to pick from a variety of connection types – FC (standard), SAS, iSCSI, or InfiniBand (IB). I found the canned video demo of SANtricity to reveal that the interface looks rather complicated and clunky. You can make the judgement for yourself by watching the video below.

FlashRay

Unfortunately, the section devoted to FlashRay last all of about 5 minutes and was limited to purely marketing ideals of what an all flash array should be.

Thoughts

The technologies behind Flash Cache and Flash Pools sound like an easy win for the enterprise data center consumer. Flash Cache has been proven over the years to be a big win for a lot of environments (including mine) and Flash Pools is a nifty idea that helps extend the life of OnTAP into one that handles mixed storage device types. However, Flash Accel needs to get rid of the agent requirement and have support for a wider variety of guest OS types (including Linux) before it will gain relevance in the market.

The EF540 and FlashRay should have some relatively early success in the market due to having an enterprise storage company’s name on the box, but I wonder how they stand up to the more modern all flash architectures that have been baking over the past 1-3 years (Pure Storage and XtremeIO comes to mind).

The post NetApp’s Flash Game: Do They Hold Pocket Aces? appeared first on Wahl Network.

Server side caching is one of those neat technology concepts that has captured my attention and imagination for the past few years. The idea of locally serving blocks of data has definitely been through a number of rounds of architecture, with the initial primary offering being a way to shift commonly read “hot” block reads closer to the server workload. VMware View’s CBRC (Content Based Read Cache) does this using the host’s RAM, but the concept of server side caching is the same – as read/write IO is brought into a workload, the local cache (be it PCIe flash, SSD, or RAM) holds on to the data and serves it locally if the blocks are requested a second time. This is a sort of “slam dunk” when we’re talking about virtual desktops with a common workload profile, but can still be quite impressive for disparate server workloads.

SanDisk has a few great ideas in mind with their FlashSoft product and went into some extremely deep dive details during their presentation at Storage Field Day 3.

Note: All travel and incidentals were paid for by Gestalt IT to attend Storage Field Day 3. No other compensation was given.

Various Architectures – One Approach

I’ve seen many different ways to implement flash in a server, and so has the FlashSoft team. They’ve thrown out a lot of methods that both their engineers and customers have found a distaste for – including guest agents (bleh!) and gateway virtual appliances. FlashSoft leverages a kernel-level loadable module in VMware, which gives it the bonus advantage of being able to support both VMFS and NFS storage at a very granular extent level, and requires a flash device in the host for caching. The architecture supports all of the features an enterprise should expect – HA, vMotion, Snapshots, Clones, Storage vMotion, etc. – and can be accessed via a vSphere Client plugin.

Here’s a graphic look at their architecture from the “SanDisk FlashSoft for VMware vSphere“ video presentation at Storage Field Day 3.

Log Structured Cache

The FlashSoft design is based on the concept of a circular buffer with a variable block size, which offers some interesting advantages. The design eliminates need for garbage collection.

The process of garbage collection involves reading and rewriting data to the flash memory. This means that a new write from the host will first require a read of the whole block, a write of the parts of the block which still include valid data, and then a write of the new data. (source)

With FlashSoft, all writes are collected, sequentialized (in the case of random writes), and ultimately written to all pages within a block on an SSD. The product also claims to only consume about 140 MB of memory footprint to hold the metadata cache and less than 3% of the CPU (I assume one core).

FlashSoft Snapshots Anyone?

These probably aren’t the snapshots you’re thinking of, but are instead a mechanism that FlashSoft uses to get you back up and running in the event of a host server failure. Periodically, the software writes a “snapshot” of the metadata to the SSD. If you’ll recall from above, the metadata cache is stored in the host’s memory. So, if a host needs to recover from a failure, the FlashSoft software can reach out to a snapshot on the SSD, load the metadata from that point, and then find the missing writes to map into the metadata cache. This allows the system to get back into a hot, usable state within milliseconds.

Thoughts

You’ve now seen a good amount of data on the FlashSoft version 3.1 solution, but based on our offline discussion, more is definitely on the way! It’s my opinion that having server-side flash (PCIe or SSD depending on use case) will become as common as a NIC or CPU in future server design – it will just be a question of what type and how much.

The price point of the SanDisk FlashSoft solution is quite reasonable for the various ways to drive performance from a local cache, and offers engineers and architects yet another way to help shift that IO bottleneck away from storage. This may be especially crucial in a virtual desktop situation, but could also really help reduce stress on the SAN for traditional server environments in a variety of factors – such as the OS and any common applications.

Want More?

Feel free to check Enrico Signoretti‘s post “When flash and cache are synonyms!” or Ilja Coolen‘s post “Flash Cache Acceleration with Pernixdata & SANDisk FlashSoft“. I’m also adding the video presentation below that reviewed some impressive performance testing using FlashSoft.

The post SanDisk’s FlashSoft Paints a Bullseye on Server Side Caching appeared first on Wahl Network.

It’s difficult to spend an entire day in a room with a “mystery box” shrouded with a sheet, especially when it is called out and you are asked not to peek. This accurately describes the time I spent at Storage Field Day 3, all the while wondering what was in the mystery box without giving into the temptation of pulling back the sheet.

My patience was rewarded when the Cisco Data Center (Cisco DC) team arrived – it was the new Cisco MDS 9710 Director! Sitting at an impressive 14 RU, which is the same as its older brother the 9513, this new SAN Director has a lot of neat features that put it into the “Monster SAN” category in my mind.

Note: All travel and incidentals were paid for by Gestalt IT to attend Storage Field Day 3. No other compensation was given.

Notable MDS Improvements

From a hardware perspective, I immediately liked the fact that the MDS 9710 uses front-to-back airflow. This avoids needing to burn up extra tile space in a co-location on side-to-side airflow with a 4 post rack, or purchasing a special purpose cabinet with the airflow cowling.

Additionally, the supervisor modules are next to each other and consume a half-width slot instead of eating up an entire full-width slot, which allows for a more compact design. They are also much more beefy than the 9500 Series Sup-2As, packing 4x more memory (8GB instead of 2GB) and 4x more CPU cores (4 cores instead of 1 core) at a higher clock speed. This makes obvious sense (as newer hardware is released at price points palatable to both Cisco and the consumer) but it’s nice to see it’s more than an incremental improvement: 4x more is pretty beefy.

Cisco definitely had redundancy in mind with the 9710 chassis, as everything about it comes in N+1 or Grid redundancy levels. For example: the front side, bottom portion houses a total of 8 power supplies rated at 3000W each, which equates to 3 power supplies with an additional spare for each PDU (power fabric). There’s also room for 3 fan trays on the rear, with each tray housing 4 fans, that sit over the fabric modules.

I’m including a video below of the components introduced with the 9710 at Storage Field Day 3, or you can watch any of the other videos from Cisco DC’s presentation.

The 9710 Provides 16Gb FC Line Rate … Everywhere

The MDS 9710 uses up to 6 crossbar switching fabric slots on the rear of the chassis. This really boils down to the idea of using line rate for every port when at least 3 fabric modules are installed. I would imagine that a lot of storage engineers are excited to hear this, because the previous model was to stagger connected ports to monopolize the speed provided by the underlying ASICs to avoid oversubscription. The 9710 supports the use of 16Gb FC ports on their 48-port line card, arranged in 12 4-port port groups. Ports can be sent to a variety of speeds, including 4, 8, 10, and 16 Gb FC.

Cisco also provided details on a new FCoE native line card that will be released in the near future. It will also be a 48-port line card and can be mixed with the 16Gb FC cards if that meets your design needs or use case.

What’s In A Speed? FC vs Ethernet Data Rates

One final note of mention is in the labeling of port speeds vs data bandwidth. It strongly smacks of the days when a controversy arose over how to measure CRT computer monitors: viewable size or physical size? (Spoiler: Ultimately the number that was larger was chosen). In the case of a SAN, Ethernet speeds are true to their name, while FC speeds are misleading. Cisco has decided to “talk about FC bandwidth as front panel FC bandwidth, but fabric module bandwidth in actual data bandwidth” if you read their presentation materials.

Note: 16Gb FC really only operates at data rate of 13.6Gb. To put in perspective, 8Gb FC has a data rate of 6.8Gb. 10Gb Ethernet (FCoE) operates at a speed of 10Gb. See how this can get confusing?

I would tend to agree with Cisco. Now that we’re mixing Ethernet and FC, the fabric modules will have speeds represented in actual data bandwidth instead of FC front slot port speeds. Kudos on them. This also means that a fabric module may have a data bandwidth of 220 Gb per slot, but in “FC land” it would be 256 Gb of front panel FC bandwidth.

Suffice to say, having 3 fabric modules is enough to ensure there is no overcommit necessary for line rate speeds on all front side 16Gb FC ports. Additional fabric cards provide redundancy and increased bandwidth for future port speeds and types.

Thoughts

There are many non-trivial improvements with the 9710 that really make it attractive for anyone who has a 9500 coming off maintenance soon, or for those interested in building out a SAN in a greenfield environment. Once the announced FCoE line cards are released, SAN engineers will have some very nifty tools at their disposal for designing a storage network that accomplishes their goals. Just make sure to have a friend or two help you rack this thing – it’s over 400 pounds fully loaded.

The post Building a Monster SAN with the Cisco MDS 9710 Director appeared first on Wahl Network.

You’re in luck! I’ve submitted a proposal, session number 4518, to VMworld’s Call for Papers that is being voted on to cover some of experiences and recommended practices around creating an efficient and highly available NFS network. I think those with NFS storage networks, or those who are interested in deploying one, will gain significant value from this session. If you feel the same, make sure to click the “thumbs up” button in the VMworld Public Voting page before the deadline on Monday, May 6th at 5:00 PM PDT.

The abstract for this session is as follows:

NFS is becoming more widely accepted as a critical storage platform for vSphere environments, but presents some unique design challenges to ensure availability and performance. In this session, attendees will learn the most common pitfalls for enterprise deployments of NFS with vSphere, along with how to overcome them. Cutting edge deployment scenarios using converged infrastructure, blade technologies, and rack mount servers will all be discussed.

Ask the Expert VCDX’s (Session 4570)

Additionally, I am participating in a panel session with some really awesome technical folks – Matt Cowger and Rick Scherer from EMC, Chris Colotti from VMware, and Jason Nash from Varrow. Here’s the skinny:

One of the highest rated sessions at VMworld is back for its sixth year. Come get interactive with a panel of five VMware Certified Design Experts, they’ll answer your questions live. Experts in Cloud, Application Modernization and End User Computing are here to help.

I appreciate your support for these two high quality sessions and look forward to seeing everyone at the 10th VMworld US this August.

The post Interested In A Technical Deep Dive on NFS Network Design? appeared first on Wahl Network.

One virtual switch security policy that tends to trip folks up is the idea of rejecting or accepting MAC address Forged Transmits. To simplify the idea behind the policy, a Forged Transmit occurs when a network adapter starts sending out traffic that identifies itself as someone else. This security policy compares the Effective Address of the virtual network adapter and the source address inside of an 802.3 Ethernet frame generated by the virtual machine to make sure they match. If they don’t match, a Forged Transmit has occurred – sometimes this is known as MAC impersonation. If the security policy for Forged Transmits is set to Reject, the frame will be dropped.

The key thing to note about Forged Transmits is that the security policy is only policing the Effective Address of the network adapter, which is the address set by the guest OS. The policy does not compare the virtual machine’s configured MAC address, also called the Initial Address, as that duty is handled by the MAC Address Changes policy.

The host compares the Effective Address to the 802.3 Source Address generated by the virtual machine

When Does A Forged Transmit Make Sense?

A common poster child for Forged Transmits is the use of Microsoft’s Network Load Balancing (NLB) unicast mode configuration.

Stay away from my transmits!

In this scenario, multiple virtual machines are participating in the NLB cluster and all have the same MAC address. Other cases revolve around the concept of utilizing a common MAC address to own a cluster resource when one or more nodes fail. Realistically, you won’t encounter all that many use cases that require Forged Transmits, and the default distributed switch security setting is to Reject any MAC impersonations (the standard switch still Accepts them by default).

Prime Example: Nested Virtualization

A much more common scenario today is the situation where a virtual machine is hosting traffic for a variety of other workloads, such as with a virtual ESXi server running nested virtual guests. In this case, multiple MAC addresses will appear in the Source Address 802.3 field, as each virtual workload hosted by the VM would need to communicate using the virtual ESXi network adapter. You would need to Accept Forged Transmits in order for a nested virtual guest to communicate outside of the virtual ESXi host.

Take this example scenario below. A virtual ESXi VM has been created with a MAC address of “D” (not valid, but pretend it is). The virtual ESXi server is running three nested VMs with a MAC address of A, B, and C. When any of the VMs attempt to talk to the outside network via the virtual ESXi network adapter, the virtual switch will check the source address of the 802.3 Ethernet frame. Because the source address does not match the Effective Address of the virtual ESXi server, the frames will treated like a Forged Transmit and subsequently dropped.

Thoughts

If you’re still stuck on Forged Transmits vs MAC Address Changes, I invite you to read my post on rejecting MAC Address Changes. The two security policies are complimentary and can lend a hand to one another. When used together, MAC Address Changes ensure that the guest OS is unable to modify its Effective Address, and Forged Transmits prohibits the actual 802.3 Ethernet frames from containing any source MAC address other than the Effective Address.

The post How The VMware Forged Transmits Security Policy Works appeared first on Wahl Network.