December 2010

You are currently browsing the monthly archive for December 2010.

Technology Short Take #9

Wednesday, December 29, 2010 in Networking, Storage, Virtualization by slowe | 17 comments

Welcome to Technology Short Take #9, the last Technology Short Take for 2010. In this Short Take, I have a collection of links and articles about networking, servers, storage, and virtualization. Of note this time around: some great DCI links, multi-hop FCoE finally arrives (sort of), a few XenServer/XenDesktop/XenApp links, and NTFS defragmentation in the virtualized data center. Here you go—enjoy!

Networking

Brad Hedlund has a great post discussing Nexus 7000 connectivity options for Cisco UCS. I’ll include it in this section since it focuses more on the networking aspect rather than UCS. I haven’t had the time to read the full PDF linked in Brad’s article, but the other topics he discusses in the post—FabricPath networks, F1 vs. M1 linecards, and FCoE connectivity—are great discussions. I’m confident the PDF is equally informative and useful.
This UCS-specific post describes how northbound Ethernet frame flows work. Very useful information, especially if you are new to Cisco UCS.
Data Center Interconnect (DCI) is a hot topic these days considering that it is a key component of long-distance vMotion (aka vMotion at distance). Ron Fuller (who I had the pleasure of meeting in person a few weeks ago, great guy), aka @ccie5851 on Twitter and one of the authors of NX-OS and Cisco Nexus Switching: Next-Generation Data Center Architectures (available from Amazon), wrote a series on the various available DCI options such as EoMPLS, VPLS, A-VPLS, and OTV. If you’re considering DCI—especially if you’re a non-networking guy and need to understand the impact of DCI on the networking team—this series of articles is worth reading. Part 1 is here and part 2 is here.
And while we are discussing DCI, here’s a brief post by Ivan Pepelnjak about DCI encryption.
This post was a bit deep for me (I’m still getting up to speed on the more advanced networking topics), but it seemed interesting nevertheless. It’s a how-to on redistributing routes between VRFs.
Optical or twinax? That’s the question discussed by Erik Smith in this post.
Greg Ferro also discusses cabling in this post on cabling for 40 Gigabit and 100 Gigabit Ethernet.

Servers

As you probably already know, Cisco released version 1.4 of the UCS firmware. This version incorporates a number of significant new features: support for direct-connected storage, support for incorporating C-Series rack-mount servers into UCS Manager (via a Nexus 2000 series fabric extender connected to the UCS 61×0 fabric interconnects), and more. Jeremy Waldrop has a brief write-up that lists a few of his favorite new features.
This next post might only be of interest to partners and resellers, but having been in that space before joining EMC I fully understand the usefulness of having a list of references and case studies. In this case, it’s a list of case studies and references for Cisco UCS, courtesy of M. Sean McGee (who I hope to meet in person in St. Louis in just a couple of weeks).

Storage

This could go in either the Networking or Storage sections, but I was alerted via Twitter (can’t remember who pointed this out, sorry) that the NX-OS 5.0(2)N2(1) release includes support for VE Ports (see the “New and Changed Features” section of the release notes). VE Ports are important because they enable you to interconnect multiple Fibre Channel Forwarders (FCFs) together over a lossless Ethernet fabric. In other words, they enable multi-hop FCoE. Obviously, you’d need support for VE Ports on all interconnected FCFs, which today means multi-hop FCoE with Nexus 5000 series switches.
I wrote a piece on configuring SAN port channels from a Nexus to an MDS a short while ago, and now here’s a post on configuring SAN port channels from a Nexus when in NPV mode. Good stuff.
Here’s a post I found that discusses bad flash recovery and HDD replacement on an Iomega. Not exactly data center-class equipment, I know, but I also know that a great many readers and fellow geeks have this sort of equipment in their home labs. This might be useful information.
I think it was Nigel Poulton who mentioned this post by Hu Yoshida regarding Hitachi’s “global pool of processors” approach with the VSP. Based on what I read there, it sounds like the VSP and the VMAX share some architectural similarities in this regard. If I’m incorrect in that regard, I’d love to hear your thoughts why in the comments.
Fellow vSpecialist Clint Kitson has a good discussion of LUN trespassing and VMware multipathing over at the Everything VMware at EMC community.
Richard Anderson has a comparison of using VPLEX for SQL database resiliency versus SQL database mirroring.

Virtualization

Using XenServer and need to support multicast? Look to this article for the information on how to enable multicast with XenServer.
A couple of colleagues over at Intel (I worked with Brian on one of his earlier white papers) forwarded me the link to their latest Ethernet virtualization white paper, which discusses the use of 10 Gigabit Ethernet with VMware vSphere. You can find the link to the latest paper in this blog entry.
Bhumik Patel has a good write-up on the “behind-the-scenes” technical details that went into the Cisco-Citrix design guides around XenDesktop/XenApp on Cisco UCS. Bhumik provides the details on things like how many blades were using in the testing, what the configuration of the blades was, and what sort of testing was performed.
Thinking of carving your storage up into guest OS datastores for VMware? You might want to read this first for some additional considerations.
I know that this has seen some traffic already, but I did want to point out Eric Sloof’s post on the Xenoss XenPack for ESXTOP. I haven’t had the opportunity to use it yet, but would certainly love to hear from anyone who has. Feel free to share your experiences in the comments.
As is usually the case, Duncan Epping has had some great posts over the last few weeks. His post on shares set on resource pools highlights the need to adjust the shares value (and other resource constraints) based on the contents of the pool, something that many people forget to do. He also provides a breakdown of the various vCenter memory statistics, and discusses an issue with binding a Provider vDC directly to an ESX/ESXi host.
PowerCLI 4.1.1 has some improvements for VMware HA clusters which are detailed in this VMware vSphere PowerCLI Blog entry.
Frank Denneman has three articles which have caught my attention over the last few weeks. (All his stuff is good, by the way.) First is his two-part series on the impact of oversized virtual machines (part 1 and part 2). Some of the impacts Frank discusses include memory overhead, NUMA architectures, shares values, HA slot size, and DRS initial placement. Apparently a part 3 is planned but hasn’t been published yet (see some of the comments in part 2). Also worth a read is Frank’s recent post on node interleaving.
Here’s yet another tool in your toolkit to help with the transition to ESXi: a post by Gabe on setting logfile location, swap file, SNMP, and vmkcore partition in ESXi.
Here’s another guide to creating a bootable ESXi USB stick (on Windows). Here’s my guide to doing it on Mac OS X.
Jon Owings had an idea about dynamic cluster pooling. This is a pretty cool idea—perhaps we can get VMware to include it in the next major release of vSphere?
Irritated that VMware disabled copy-and-paste between the VM and the vSphere Client in vSphere 4.1? Fix it with these instructions.
This white paper on configuration examples and troubleshooting for VMDirectPath was recently released by VMware. I haven’t had the chance to read it yet, but it’s on my “to read” list. I’ll just have a look at that in my copious free time…
David Marshall has posted on VMblog.com a two-part series on how NTFS causes I/O bottlenecks on virtual machines (part 1 and part 2). It’s a great review of NTFS and how Microsoft’s file system works. Ultimately, the author of the posts (Robert Nolan) sets the readers up for the need for NTFS defragmentation in order to reduce the I/O load on virtualized infrastructures. While I do agree with Mr. Nolan’s findings in that regard, there are other considerations that you’ll also want to include. What impact will defragmentation have on your storage array? For example, I think that NetApp doesn’t recommend using defragmentation in conjunction with their storage arrays (I could be wrong; can anyone confirm?). So, I guess my advice would be to do your homework, see how defragmentation is going to affect the rest of your environment, and then proceed from there.
Microsoft thinks that App-V should be the most important tool in your virtualization tool belt. Do you agree or disagree?
William Lam has instructions for how to identify the origin of a vSphere login. This might not be something you need to do on a regular basis, but when you do need to do it you’ll be thankful you have the instructions how.

I guess it’s time to wrap up now, since I have likely overwhelmed you with a panoply of data center-related tidbits. As always, I encourage your feedback, so please feel free to speak up in the comments. Thanks for reading!

Tags: Cisco, Citrix, FCoE, Microsoft, Networking, Nexus, Storage, UCS, Virtualization, VMware, vSphere, Windows

Merry Christmas!

Saturday, December 25, 2010 in General by slowe | 5 comments

I’d like to take this moment to wish all of my readers a very happy, very joyous, and very blessed Christmas holiday. Don’t forget the reason for the season (Luke 2:10-11)!

If you don’t celebrate Christmas, then I wish you a very happy holiday season!

Tags: Personal

An Introduction to the VPLEX CLI

Wednesday, December 22, 2010 in Storage by slowe | 3 comments

The VPLEX command line interface (CLI) is a bit different than a lot of other CLIs with which I’ve worked. In some respects, it’s similar to the scope-based CLI that Cisco uses with Unified Computing System (UCS). In this post, I’d like to explore the VPLEX CLI a bit and provide a brief introduction to the VPLEX CLI. Keep in mind that this is just an introduction—for a complete reference to the VPLEX CLI, I’ll refer you to the VPLEX product area on EMC PowerLink where a complete VPLEX CLI User’s Guide is available in PDF.

In my opinion, there are two things to know about the VPLEX CLI that will help you understand how to use it:

First, the CLI is a lot like navigating a directory tree, except that you’re navigating through contexts instead of directories. In the VPLEX CLI, you move between contexts using the cd command and list the contents of a context using the ls and ll commands. Just as with a typical filesystem, if you’re in the right context, you can just run a command (say, like the unclaim command). If you’re not in the right context, you simply specify the full context before the command (I’ll show you some examples later in this post).
Second, the VPLEX CLI supports wildcards and globbing, much like a typical filesystem. Use the asterisk (*) character to represent anything in a context, and use the double asterisk (**) to represent multiple matches across multiple contexts. You can use regular expressions as well.

With these concepts in mind, the real key to using the VPLEX CLI is simply learning where all the various objects reside. For example, in an earlier post on VPLEX storage objects, I discussed the building blocks of storage in a VPLEX environment: storage volumes, extents, devices, and virtual volumes. These reside in different places in the VPLEX contextual tree:

Storage volumes: /clusters/<cluster name>/storage-elements/storage-volumes
Extents: /clusters/<cluster name>/storage-elements/extents
Devices: /clusters/<cluster name>/devices
Distributed devices: /distributed-storage/distributed-devices
Virtual volumes: /clusters/<cluster name>/virtual-volumes

Within each of these contexts, you can use the ls and ll commands to view the contents of that context. The help command will show you what other commands are available in each context.

Here’s my first example. When you first log into the VPLEX CLI, you’ll get dropped into a “root context”. Running ls here will produce output something like this:

VPlexcli:/> ls clusters data-migrations distributed-storage engines management-server monitoring notifications system-defaults

Let’s take a look at a few more examples. For example, the following two sets of commands will produce the same output:

cd /clusters ll

and

ll /clusters

Remember that specifying the context in the command is the same as changing into that context and then running the command. That is why these two commands produce the same output.

To view the list of directors in a cluster:

ll /engines/*/directors

This is an example of using the asterisk to represent a wildcard that matches all entries in that context.

Let’s look at another example of two different commands that produce the same output. To view the status of the ports on a particular director in a cluster, you could use either of these two commands:

ll /engines/<engine name>/directors/<director name>/hardware/ports

cd /engines/<engine name>/directors/<director name>/hardware/ports ll

By the way, if you haven’t figured it out yet, you can easily get the names of the engines (or the directors) by simply running the ll command against the engines context or the directors context within a specific engine.

But what if you wanted to see the status of the ports across multiple directors? Now you won’t want to use the cd command. You’ll want to use globbing with wildcards instead, like this:

ll /engines/**/ports

While the single asterisk matches anything within a context, the double asterisk matches across multiple contexts. So, in this case, it ends up matching multiple engines and directors within those engines.

And if you wanted to see only some of the front-end ports on all directors:

ls /engines/**/hardware/ports/*1-FC0[0-3]

In some cases, you might need to set an attribute on an object within a context. For example, you might need to enable a port by setting the enabled attribute on that port to True. Here’s how you would do that:

set /engines/<engine name>/directors/<director name>/hardware/ports/A0-FC00::enabled true

If you think about it, you could easily combine some globbing to enable multiple ports at the same time:

set /engines/**/hardware/ports/A0-FC0[0-3]::enabled true

You can then verify the operation by using the -t parameter to the ls command, which instructs it to include attributes:

ls -t /engines/**/hardware/ports/A0-FC0[0-3]::enabled

There are many, many more examples I could share with you, but this should get you started for now. I hope to have a post up soon with a CLI guide to setting up storage volumes, extents, devices, and virtual volumes.

As usual, feel free to speak up in the comments if you have any questions or clarifications. Thank you!

Tags: CLI, EMC, Storage, VPLEX

Using VPLEX and Data Replication Together

Monday, December 20, 2010 in Storage by slowe | 4 comments

In my previous post on EMC VPLEX, I provided a review of the VPLEX storage objects. In that post, I discussed the difference between a storage volume, an extent, a device, and a virtual volume. If you are unclear on the distinctions between those terms, I suggest you go back and read that post again before proceeding.

The following diagram illustrates these various storage objects again:

As you can see from the diagram, VPLEX offers a number of different ways to combine these objects together:

You can slice a single storage volume into multiple extents, then use each of those extents to create a separate device (and then a virtual volume). The VPLEX device might only occupy one of the extents on the storage volume and other data might occupy other extents on the storage volume. This is the option on the left side of the figure.
You can combine extents from different storage volumes together into a single device (and then a virtual volume). This is the option on the right side of the figure.
Finally, you can create a single extent occupying all of a storage volume and use it to create a single device. This is the middle option illustrated above and, as you’ll see shortly, is the generally recommended way of doing it.

Now that I’ve reviewed the storage concepts again, let me delve into the real meat of this post. Since the introduction of EMC VPLEX and its storage federation functionality (which apparently I’m not supposed to call storage federation; see the comments here), organizations have another choice in their disaster avoidance/disaster recovery (DA/DR) plans. In addition to utilizing data replication solutions, organizations now have the option of integrating VPLEX’s data synchronization functionality into their DA/DR solution. Is there room for VPLEX in an organization’s DA/DR planning? The answer is yes! While there has been a great deal of confusion about how, if at all, VPLEX could be used in conjunction with (rather than instead of) existing replication solutions, it is possible and it is fully supported (with a few caveats). This post discusses how you can use both VPLEX and data replication in the same environment.

As a side note, a fair amount of the information in this post is derived from a white paper, published by EMC, on the use of array-based replication with EMC VPLEX. I do encourage you to read that white paper for more information and more details.

So what would a supported configuration that uses both VPLEX and replication look like? This diagram graphically depicts a supported solution that integrates both EMC VPLEX and a data replication solution such as SRDF or RecoverPoint:

The key to a supported solution that combines VPLEX and replication lies in the phrase “single extent/single device”. In order to use both replication as well as VPLEX in the same solution, you must use a 1:1:1 mapping between storage volumes, extents, and devices. In other words, you must use a “single extent/single device” approach, where each storage volume has only a single extent (occupying the entire storage volume), and devices are built from that single extent on a single storage volume.

If you think about it for a minute, you can easily see why this is the case. Let’s consider a scenario in which you are wishing to combine VPLEX with RecoverPoint:

What is the smallest unit of replication for RecoverPoint? A single LUN. Sure, you can replicate multiple LUNs or groups of LUNs, but the smallest unit of replication is a single LUN. You can’t replicate part of a LUN.
What is the smallest unit of federation for VPLEX? An extent, which might be part of a back-end storage volume (a LUN). You can federate multiple extents or groups of extents, but you can’t federate a part of an extent.
How do we get these two units lined up with each other? If RecoverPoint works only on entire LUNs and VPLEX works on extents, then the way to line them up is to ensure that each extent represents an entire LUN. This makes RecoverPoint’s basic unit (an entire LUN) the same as VPLEX’s basic unit (an entire LUN).

With your replication solution replicating entire LUNs and VPLEX working on entire LUNs, this creates the sort of situation where I/O can pass through VPLEX to the back-end array, where the replication solution can pick it up and replicate it off to a third location. This gives organizations the best of both worlds—support for disaster avoidance using VPLEX at synchronous distances and support for disaster recovery using a replication solution such as RecoverPoint or SRDF at longer distances.

Your feedback is always welcome! Post any questions, corrections, or clarifications in the comments below.

Tags: EMC, Storage, VPLEX

Technology Short Take #8

Friday, December 17, 2010 in Networking, Storage, Virtualization by slowe | No comments

Welcome to Technology Short Take #8, my latest collection of item from around the Internet pertaining to data center technologies such as virtualization, networking, storage, and servers. I hope you find something useful here!

Networking

A couple weeks ago I wrote about how to connect a Nexus 2148T to a Nexus 5010. What I haven’t actually done yet is connect the Nexus 2148T to dual Nexus 5010 upstream switches using virtual port-channels. This post offers a configuration for just such an arrangement (just be sure to read the follow-up post for a key command to include in the configuration).
And speaking of fabric extenders, Brad Hedlund recently posted a great article explaining QoS on the Cisco UCS fabric extender.
Erik Smith has posted part 2 of his series on FIP, FIP snooping bridges, and FCFs.
This post by Ethan Banks on the scaling limitations of EtherChannel reinforces what I’ve said before about the use of EtherChannel and VMware ESX/ESXi (see this post and this follow-up post). Apparently this misunderstanding about how link aggregation works isn’t just limited to virtualization folks.
This article on BPDU Guard and BPDU Filter is a bit deep for the non-expert networkers (like me), but is good reading nevertheless. Since it is recommended that you disable Spanning Tree Protocol for ports facing VMware ESX/ESXi hosts (and here’s the explanation why from our good friend Ivan “IOSHints” Pepelnjak), it’s good to understand which commands to use and at which scope to use them.
While link aggregation isn’t a panacea, it can be helpful in a number of situations. However, you really need to consider multi-chassis link aggregation in order to eliminate single points of failure. Ivan Pepelnjak posted a series of articles on multi-chassis link aggregation (MLAG): MLAG basics, MLAG via stacking, and MLAG external brains. I think there’s another post still coming, correct Ivan?
This post is written by networking guru Jeremy Gaddis, but it’s really more about UNIX and regular expressions. So in which category does it belong? (Does it really matter?) I guess since it deals with how to use UNIX tools and regular expressions to manipulate networking data I’ll put it in the networking category.
Here’s a good post on creating LAN-to-LAN tunnels between a Vyatta router and a Cisco ASA.
Joe Onisick has a good write-up on the behavior of inter-fabric traffic in UCS.

Servers

Still think that Cisco UCS requires 10Gb Ethernet and Cisco Nexus switches? You might want to read this. Seriously, go read it.
Jeff Allen has posted a good discussion of UCS BIOS policies.
In the past I’ve covered various integrations with RADIUS using Microsoft IAS (see here, here, and here for some examples). Here’s a post on how to use Microsoft IAS to integrate Cisco UCS into Active Directory.

Storage

It’s good to see more “virtualization” people getting into storage. Recently, Jon Owings (of “2vcps and a Truck” fame) posted two good articles on storage caching vs. tiering (part 1 and part 2). Jon provides a good vehicle to discuss these technologies, both of which are valuable and both of which have a place in many companies’ storage strategy.
Here’s another view on storage tiering vs. caching.
And speaking yet again of caching and tiering…here’s some info on FAST (tiering) and FAST Cache (caching).
Finally, rounding out this week’s caching and tiering discussions, I have Nigel Poulton’s post on sub-LUN tiering design considerations.

Virtualization

Noted virtualization performance guru Scott Drummonds posted a collection of thoughts regarding maximum hosts per cluster. Duncan Epping—who along with Frank Denneman recently published their HA and DRS Technical Deep Dive book—followed up with his own post on the matter. Both Scott and Duncan summarized some of the advantages and disadvantages of both large and small clusters. The real key to understanding the “right” cluster size is, as Duncan points out, an understanding of how best to meet the requirements of the environment.
Scott also posted this useful discussion on considerations around VMDK consolidation in virtualized environments.
Need to find the IP address of a VM from an ESX host? Try this article, which provides the steps and tools you need.
I saw a couple of good articles from Frank Denneman recently. One was on how to disallow multiple VM console sessions; the second was discussing disabling the balloon driver and why it’s generally not a good idea. Frank also posted a piece recently on the interaction between QoS and the adaptive algorithm that DRS uses to determine concurrent vMotions. While I agree that you don’t want to impact DRS’ ability to perform concurrent vMotions to restore cluster balance, it’s also critically important to ensure proper balance in network traffic. You don’t want a single type of network traffic to swamp others. As with many other things in the virtualization arena, just be sure to understand the impact of your decisions.
If you need to shape network traffic (like vMotion), here’s a how to document on how it’s done.
This article underscores the difficulty that many organizations have in adopting “the cloud”, at least as it pertains to public cloud-based services. Perhaps this is why VMware is so keen on embracing software development tools that help build cloud-enabled applications…
I think that esxtop remains an underestimated tool in troubleshooting. If you need to deepen your understanding of this very useful tool, a good place to start—among the many, many resources that are available—would be this presentation. Thanks for posting this, Alan!
William Lam has posted a thorough guide to using vi-fastpass with fpauth and adauth. As the vMA grows in importance with the transition to ESXi in the next major release of vSphere, tips and tricks such as this are going to be worth their words in gold. Good job William!
Remember how I’ve mentioned before that it’s funny when vendors taking existing technologies and rename them to include the word “virtualization”? That’s the feeling I get from reading this article on Microsoft’s user state virtualization.

It’s time to wrap up now, so I’ll just say that I welcome any feedback, corrections, clarifications, or additions in the comments below. I hope you’ve found something helpful. Thanks!

Tags: Cisco, EMC, Microsoft, Networking, Nexus, Storage, UCS, Virtualization, VMware

Some EMC Product Updates

Thursday, December 16, 2010 in Storage, Virtualization by slowe | 4 comments

There have been a few important EMC product updates over the last few days that I thought I might highlight here real quick:

Replication Manager has been bumped up to version 5.3.1 (also referred to as 5.3 SP1), which adds several new features. One of the more notable features is the ability to do file-level restores from both VMFS and NFS datastores. Other new features include the ability to create SnapView snaps or clones from RecoverPoint targets and expanded host and application support.
EMC has released the Virtual Storage Integrator (VSI) 4.0 for VMware vSphere. This is a new release, with new functionality, of our previous generation vCenter plug-in. This new release offers comprehensive discovery and mapping of storage resources, including support for discovery and mapping of VPLEX devices; a single vCenter interface for EMC storage devices of all types; centralized monitoring and control of host-based path management (both PP/VE and NMP); and expanded storage provisioning support from within vCenter Server.
EMC also released a new version of the Site Recovery Manager SRA for SRDF. Co-worker Itzik Reich has a great write-up of the new features of the SRDF SRA on his blog.

If PowerLink has not already been updated with information on these new releases, those updates should happen very soon so check PowerLink for more details. Thanks!

Tags: EMC, Storage, Virtualization, VMware

FCoE through a Nexus to a MDS-Attached Storage Array

Wednesday, December 15, 2010 in Interoperability, Storage by slowe | 11 comments

In this post, I want to pull together all the steps necessary to take a Converged Network Adapter (CNA)-equipped server and connect it, using FCoE, to a Fibre Channel-attached storage array. There isn’t a whole lot of “net new” information in this post, but rather I’m summarizing previous posts, organizing the information, and showing how these steps relate to each other. I hope that this helps someone understand the “big picture” of how FCoE and Fibre Channel relate to each other and how they interoperate (which, quite frankly, is one of the key factors for the adoption of FCoE).

The steps involved come from an environment with the following components:

A Dell PowerEdge R610 server running VMware ESXi and containing an Emulex CNA
A Cisco Nexus 5010 switch running NX-OS 4.2(1)N1(1).
A Cisco MDS 9134 Fibre Channel switch running NX-OS 5.0(1a).
An older EMC CX3-based array with Fibre Channel ports in the storage processors.

We’ll start at the edge (the host) and work our way to the storage. All these steps assume that you’ve already taken care of the physical cabling.

Depending upon how old the software is on your hosts, you might need to install updated drivers for your CNA, as I described here. If you’re using newer versions of software, the drivers will most likely work just fine out of the box.
The closest piece to the edge is the FCoE configuration on the Nexus 5010 switch. Here’s how to setup FCoE on a Nexus 5000. Be sure that you map VLANs correctly to VSANs; for every VSAN that needs to be accessible from the FCoE-attached hosts, you’ll need a matching VLAN. Further, as pointed out here, the VLAN and VLAN trunking configuration is critical to making FCoE work properly anyway.
The next step is connecting the Nexus 5010 to the MDS 9134 Fibre Channel switch. Read this to see how to configure NPV on a Nexus 5000 if you are going to use NPV mode (and read this for more information on NPV and NPIV). Using NPV or not, you’ll also need to setup connections between the Nexus and the MDS; here’s how to setup SAN port channels between a Cisco Nexus and a Cisco MDS.
Once the Nexus and the MDS are connected, then you’ll need to perform the necessary zoning so that the hosts can see the storage. Before starting the zoning, you might find it helpful to set up device aliases. After your device aliases are defined, you can create the zones and zonesets. This post has information on how to create zones via CLI; this post has information on how to manage zones via CLI.

At this point—if everything is working correctly—then you are done and you should be ready to present storage to the end hosts.

I hope this helps put the steps involved (all of which I’ve already written about) in the right order and in the right relationship to each other. If there are any questions, clarifications, or suggestions, please feel free to speak up in the comments.

Tags: Cisco, EMC, FCoE, FibreChannel, Interoperability, Networking, SAN, Storage

Allegations Regarding FBI Involvement with OpenBSD

Tuesday, December 14, 2010 in General, UNIX by slowe | 54 comments

Let’s get right to the point and set the record straight: I am not, nor have I ever been, affiliated with or employed by the FBI or any other government agency.

That’s why I was surprised when word surfaced that I had been implicated in some sort of conspiracy regarding a plan to place secret backdoors into an OpenBSD cryptographic framework, and that my recent advocacy of OpenBSD was based on my alleged involvement with the FBI.

I don’t know where the person who started this rumor got his information, but he is sadly mistaken regarding my involvement. Perhaps the other Scott Lowe is involved; I don’t know. What I do know is this: I’m not affiliated with, supported by, employed by, associated with, or in support of the FBI in any way, shape, form, or fashion. Quite simply, it wasn’t me.

Feel free to post any additional questions or courteous comments below. I’ll answer all relevant questions openly and honestly.

Tags: BSD, UNIX

A Quick Review of VPLEX Storage Objects

Monday, December 13, 2010 in Storage, Virtualization by slowe | 13 comments

Now that I’ve managed to get my VPLEX clusters up and running, I’m ready to start providing some posts on VPLEX and how it’s configured and used. To get things started, I want to first provide an overview of VPLEX storage objects and how they relate to each other.

<aside>The images shown in this post are being served from Dropbox. If your office blocks Dropbox (like EMC does), then these images might not appear. I apologize for the inconvenience.</aside>

Storage volumes: Storage volumes are the LUNs that are presented to the VPLEX back-end ports from the storage array. The screenshot below, taken from the VPLEX management GUI, shows a series of storage volumes taken from two separate back-end arrays.

Extents: Extents are created on storage volumes. You have the option of creating multiple extents on a single storage volume, but EMC generally recommends creating one extent per storage volume. (Future posts will discuss why this is beneficial.)

Devices: Devices are created from extents. You can combine multiple extents together to form a single device, or you can present a single extent up as a single device. As you can see in the screenshot, devices also have a geometry associated with them, like RAID-0 (no mirroring of devices together), RAID-1 (mirroring of devices), or RAID-C (concatenating devices).

Distributed devices: Distributed devices are mirrored devices that are spread across two VPLEX clusters connected together into a metro-plex. Distributed devices require extents from both VPLEX clusters in the metro-plex. Like “regular” devices, distributed devices also have a geometry. As far as I know, all distributed devices will automatically have a RAID-1 geometry. Note that because distributed devices aren’t confined to a single cluster, they reside in a different place in the hierarchy.

Virtual volume: Virtual volumes are built from devices. When a virtual volume is built from a device, it’s referred to just as a virtual volume. When the virtual volume is built from a distributed device, it’s referred to as a distributed virtual volume. Virtual volumes are what are exposed (exported in VPLEX parlance) to hosts via the VPLEX front-end ports.

In future VPLEX posts, I’ll provide information on managing these various storage objects (creating, renaming, and deleting objects) as well as information on integrating VPLEX with other data protection solutions. Stay tuned!

Tags: EMC, SAN, Storage, Virtualization, VPLEX

Presentations from Midwest Regional VMUG

Thursday, December 9, 2010 in Virtualization by slowe | 5 comments

This past Monday, December 6, I had the pleasure of speaking at the Midwest Regional VMUG held in Kansas City, Kansas. I delivered two presentations on Monday:

Next-Generation Best Practices for Storage and VMware (keynote)
Top 6 VMware vSphere Design Questions

A number of people asked me after my presentations about getting copies of the presentations, so I’m making them available here via Slideshare. Enjoy!