CLARiiON

You are currently browsing articles tagged CLARiiON.

Technology Short Take #12: Storage Edition

Sunday, May 8, 2011 in Storage by slowe | 4 comments

I’m so far behind in my technology reading that I have this massive list of blog posts and links that I would normally put into an issue of Technology Short Takes. However, people are already “complaining” that my Short Takes aren’t all that short. To keep from overwhelming people, I’m breaking Technology Short Take #12 into three editions: Virtualization, Storage, and Networking.

Here’s the “Storage Edition” of Technology Short Take #12!

  • When planning storage details for your vSphere implementation, be sure to keep block size in mind. Duncan Epping’s post on the performance impact of the different datamovers in a Storage vMotion operation should bring to light why this is an important storage detail to remember. (And read this post if you need more info on the different datamovers.)
  • Richard Anderson of EMC (aka @storagesavvy) posted a “what if” about using cloud storage as a buffer with thin provisioning and FAST VP. It’s an interesting idea, and one that will probably see greater attention moving forward.
  • Richard also shared some real-world results on the benefits of using FAST Cache and FAST VP on a NS-480 array.
  • Interested in using OpenFiler as an FC target? Have a look here.
  • Nigel Poulton posted an analysis of EMC’s recent entry in the SPC benchmarketing wars in which he compares storage benchmarking to Formula 1 racing. I can see and understand his analogy, and to a certain extent he has a valid point. On the other hand, it doesn’t make sense to submit a more “mainstream” configuration if it’s a performance benchmark; to use Nigel’s analogy, that would be like driving your mini-van in a Formula 1 race. Yes, the mini-van is probably more applicable and useful to a wider audience, but a Formula 1 race is a “performance benchmark,” is it not? Anyway, I don’t know why certain configurations were or were not submitted; that’s for far more important people than me to determine.
  • Vijay (aka @veverything on Twitter) has a good deep dive on EMC storage pools as implemented on the CLARiiON and VNX arrays.
  • Erik Smith has a couple of great FCoE-focused blog posts, first on directly connecting to an FCoE target and then on VE_Ports and multihop FCoE. Both of these posts are in-depth technical articles that are, in my opinion, well worth reading.
  • Brian Norris posted about some limitations with certain FLARE 30 features when used in conjunction with Celerra (DART 6.0). I know that at least one of these limitations—the support for FAST VP on LUNs used by Celerra—are addressed in the VNX arrays.
  • Brian also recently posted some good information on a potential login issue with Unisphere; this is caused by SSL certificates that are generated with future dates.
  • J Metz of Cisco also has a couple of great FCoE-focused posts. In To Tell the Truth: Multihop FCoE, J covers in great detail the various topology options and the differences in each topology. Then, in his post on director-class multihop FCoE, J discusses the products that implement multihop FCoE for Cisco.
  • If you’ve never used EMC’s VSI (Virtual Storage Integrator) plug-in for vCenter Server, have a look at Mike Laverick’s write-up.

OK, that does it for the Storage Edition of Technology Short Take #12. Check back in a couple of days for the Networking Edition of Technology Short Take 12.

Tags: , , , ,

Technology Short Take #11

Thursday, February 17, 2011 in Networking, Storage, Virtualization by slowe | 6 comments

That’s right folks, it’s time for another installation of Technology Short Takes. This is Technology Short Take #11, and I hope that you find the collection of items I have for you this time around both useful and informative. But enough of the introduction—let’s get to the good stuff!

Networking

  • David Davis (of Train Signal) has a good write-up on the Petri IT Knowledgebase on using a network packet analyzer with VMware vSphere. The key, of course, is enabling promiscuous mode. Read the article for full details.
  • Jason Nash instructs you on how to enable jumbo frames on the Nexus 1000V, in the event you’re interested. Jason also has good coverage of the latest release of the Nexus 1000V; worth reading in my opinion. Personally, I’d like Cisco to get to version numbers that are a bit simpler than 4.2(1) SV1(4).
  • Now here’s a link that is truly useful: Greg Ferro has put together a list of Cisco IOS CLI shortcuts. That’s good stuff!
  • There are a number of reasons why I have come to generally recommend against link aggregation in VMware vSphere environments, and Ivan Pepelnjak exposes another one that rears its head in multi-switch environments in this article. With the ability for vSphere to utilize all the uplinks without link aggregation, the need to use link aggregation isn’t nearly as paramount, and avoiding it also helps you avoid some other issues as well.
  • Ivan also tackles the layer 2 vs. layer 3 discussion, but that’s beyond my pay grade. If you’re a networking guru, then this discussion is probably more your style.
  • This VMware KB article, surprisingly enough, seems like a pretty good introduction to private VLANs and how they work. If you’re not familiar with PVLANs, you might want to give this a read.

Servers

  • Want to become more familiar with Cisco UCS, but don’t have an actual UCS to use? Don’t feel bad, I don’t either. But you can use the Cisco UCS Emulator, which is described in a bit more detail by Marcel here. Very handy!

Storage

  • Ever find yourself locked out of your CLARiiON because you don’t know or can’t remember the username and password? OK, maybe not (unless you inherited a system from your predecessor), but in those instances this post by Brian Norris will come in handy.
  • Fabio Rapposelli posted a good write-up on the internals of SSDs, in case you weren’t already aware of how they worked. As SSDs gain traction in many different areas of storage, knowing how SSDs work helps you understand where they are useful and where they aren’t.
  • Readers that are new to the storage space might find this post on SAN terminology helpful. It is a bit specific to Cisco’s Nexus platform, but the terms are useful to know nevertheless.
  • If you like’s EMC’s Celerra VSA, you’ll also like the new Uber VSA Guide. See this post over at Nick’s site for more details.
  • Fellow vSpecialist Tom Twyman posted a good write-up on installing PowerPath/VE. It’s worth reading if you’re considering PP/VE for your environment.
  • Joe Kelly of Varrow posted a quick write-up about VPLEX and RecoverPoint, in which he outlines one potential issue with interoperability between VPLEX and RecoverPoint: how will VPLEX data mobility affect RP? For now, you do need to be aware of this potential issue. For more information on VPLEX and RecoverPoint together, I’d also suggest having a look at my write-up on the subject.
  • I won’t get involved in the discussion around Open FCoE (the software FCoE stack announced a while back); plenty of others (J Metz speaks out here, Chad Sakac weighed in here, Ivan Pepelnjak offers his opinions here, and Wikibon here) have already thrown in. Instead, I’ll take the “Show me” approach. Intel has graciously offered me two X520 adapters, which I’ll run in my lab next to some Emulex CNAs. From there, we’ll see what the differences are under the same workloads. Look for more details from that testing in the next couple of months (sorry, I have a lot of other projects on my plate).
  • Jason Boche has been working with Unisphere, and apparently he likes the Unisphere-VMware integration (he’s not alone). Check out his write-up here.

Virtualization

  • For the most part, a lot of people don’t have to deal with SCSI reservation conflicts any longer. However, they can happen (especially in older VMware Infrastructure 3.x environments), and in this post Sander Daems provides some great information on detecting and resolving SCSI reservation conflicts. Good write-up, Sander!
  • If you like the information vscsiStats gives you but don’t like the format, check out Clint Kitson’s PowerShell scripts for vscsiStats.
  • And while we’re talking vscsiStats, I would be remiss if I didn’t mention Gabe’s post on converting vscsiStats data into Excel charts.
  • Rynardt Spies has decided he’s going Hyper-V instead of VMware vSphere. OK, only in his lab, and only to learn the product a bit better. While we all agree that VMware vSphere far outstrips Hyper-V today, Rynardt’s decision is both practical and prudent. Keep blogging about your experiences with Hyper-V, Rynardt—I suspect there will be more of us reading them than perhaps anyone will admit.
  • Brent Ozar (great guy, by the way) has an enlightening post about some of the patching considerations around Azure VMs. All I can say is ouch.
  • The NIST has finally issued the final version of full virtualization security guidelines; see the VMBlog write-up for more information.
  • vCloud Connector was announced by VMware last week at Partner Exchange 2011 in Orlando. More information is available here and here.
  • Arnim van Lieshout posted an interesting article on how to configure EsxCli using PowerCLI.
  • Sander Daems gets another mention in this installation of Technology Short Takes, this time for good information on an issue with ESXi and certain BIOS revisions of the HP SmartArray 410i array controller. The fix is an upgrade to the firmware.
  • Sean Clark did some “what if” thinking in this post about the union of NUMA and vMotion to create VMs that span multiple physical servers. Pretty interesting thought, but I do have to wonder if it’s not that far off. I mean, how many people saw vMotion coming before it arrived?
  • The discussion of a separate “management cluster” has been getting some attention recently. First was Scott Drummonds, with this post and this follow up. Duncan responded here. My take? I’ll agree with Duncan’s final comment that “an architect/consultant will need to work with all the requirements and constraints”. In other words, do what is best for your situation. What’s right for one customer might not be right for the next.
  • And speaking of vShield, be sure to check out Roman Tarnavski’s post on extending vShield.
  • Interested in knowing more about how Hyper-V does CPU scheduling? Ben Armstrong is happy to help out, with Part 1 and Part 2 of CPU scheduling with Hyper-V.
  • Here’s a good write-up on how to configure Pass-Through Switching (PTS) on UCS. This is something I still haven’t had the opportunity to do myself. It kind of helps to actually have a UCS for stuff like this.

It’s time to wrap up now; I think I’ve managed to throw out a few links and articles that someone should find useful. As always, feel free to speak up in the comments below.

Tags: , , , , , , , , , ,

Fixing Inactive New Paths on an EMC CLARiiON

Friday, August 20, 2010 in Storage by slowe | 8 comments

I ran into an issue in the lab today with some VMware ESX 4.0 hosts and some older CLARiiON CX3 arrays. I’d been working to fix up the lab so that it more properly reflects a “best practices” configuration with dual SAN fabrics, dual-homed HBAs and CNAs, network connections spread across multiple physical switches, etc.—you know, all the wonderful things that we recommend to our customers.

As a result of cross-connecting both the HBAs and the CLARiiON’s storage processors to both SAN fabrics, I ended up with more paths to the LUNs than I had previously. This was, of course, fully expected. Upon browsing the properties for the datastore in the vSphere Client, however, I still saw only four paths—two target ports on each storage processor—when I expected to see more. Upon closer inspection, I determined that I wasn’t seeing the ports on the array that I had recently connected to the second fabric.

My first thought was that the SAN zoning incorrect. I went back and double-checked the SAN zoning to ensure that all the initiators were, in fact, zoned to see all the targets. OK, so the zoning is correct. Why didn’t the extra paths show up?

I double-checked the physical layer; everything was fine there.

That left only the array itself. Logging into Navisphere, I saw in the Connectivity Status window that all the initiators were logged in and registered. (It turns out there is something else in the Connectivity Status window that I should have noticed, but didn’t. Read on to find out what I missed.) Hmmm…so that’s not it. I manually edited the initiators in the Connectivity Status window so that all the paths were linked to the same host, thinking perhaps that would resolve the problem, but it didn’t help. So, thinking that perhaps de-registering and re-registering the initiators might help, I enabled engineering mode in Navisphere so I could do just that. After enabling engineering mode but before I de-registered the initiators, I poked around to see if anything else stuck out at me.

(If you’re not familiar with engineering mode on a CLARiiON, just look at the results from a Google search like this. It should give you all the information you need.)

While browsing through Navisphere with engineering mode enabled, I noticed something I hadn’t noticed before: the VMware ESX host I was troubleshooting was showing up in two different storage groups. This is an error, as a host is only allowed to be in a single storage group at a time. In this case, some of the initiators were showing up in the desired storage group, but two of the initiators were showing up in the ~management storage group. Ah ha! Those initiators were my missing paths. But how to fix it?

It turns out that by looking at the properties of the storage group and then looking at the Hosts tab, there is now (with engineering mode enabled) an Advanced button that allows you to select the specific paths for each host that should be enabled for that storage group. When I opened the Advanced Properties dialog box for the storage group, there’s a separate tab for each host in the storage group that lists all the connection paths that should be included. And, sure enough, my two missing paths were there, unchecked! When I checked them and then went back to review the paths from the VMware ESX host, all six expected paths were now present and accounted for.

Now, I’m told that removing the host from the storage group and then re-adding it to the storage group would accomplish the same effect. That, however, is a disruptive process; this method is non-disruptive (as far as I can tell). I’m also told that the Reconnect button—found in the Host Connectivity status window, accessible by right-clicking a specific host and selecting Connectivity Status—will accomplish the same result as well. I can’t speak for either of these two options, but I do know that entering engineering mode and enabling all the paths works and works without disruption.

Oh, and remember how I mentioned that there was something I overlooked in the Connectivity Status window? I learned after the fact—after I’d already fixed the problem—that initiators that are blue in the Connectivity Status window are initiators that are not in a storage group. I don’t think knowing that up front would have helped all that much, but it’s still handy to know.

So there you have it: if you enable new paths from a host to a storage array and the paths don’t show up, use engineering mode to ensure that all the paths are enabled for the host in the storage group.

I encourage you to speak up in the comments if you have additional information or other tips/tricks pertaining to this issue. Thanks for reading!

UPDATE: A reader has posted in the comments that the Reconnect option will reestablish all paths to the host without disruption. Thanks, Tim!

Tags: , , ,

Changing IP Addresses on an EMC Celerra NS-960

Monday, April 12, 2010 in Storage by slowe | 7 comments

Changing the IP addresses on an EMC Celerra unified storage array is generally a pretty straightforward process. EMC supplies a script called clariion_mgmt that you can use to change the IP addresses on the back-end CLARiiON storage processors (SPs). In the large majority of cases, the process for changing the IP addresses on an EMC Celerra using this script looks something like this:

  1. Change the IP address of the Control Station using Celerra Manager.
  2. Use the clariion_mgmt script to update the IP addresses on the back-end CLARiiON SPs.

As with all things in the IT field, this straightforward process sometimes becomes a bit more convoluted. If you are attempting to change the IP addresses on an EMC Celerra using the clariion_mgmt script and having some problems, I hope that the information provided in this post is helpful to you. I gathered this information during an instance in which I ran into a series of problems changing the IP addresses on a partner’s EMC NS-960 after they re-addressed their lab.

The first step is to change the IP address of the Control Station. This is readily accomplished using Celerra Manager, but remember that you will need to authenticate as “root” and not as “nasadmin”. Otherwise, you won’t have the right to modify the IP address. Also keep in mind that because the Control Station is separate from the network interfaces on the data movers, changing the IP address on the Control Station won’t affect network connectivity to/from the data movers.

Once the Control Station’s IP address has been changed, the next step would be to use the clariion_mgmt script. The general use of the clariion_mgmt script involves the use of the “‑modify” parameter to change the IP addresses on the back-end CLARiiON SPs. Instead of using the “‑modify” parameter, the only blog post I found on this process recommended the use of the “‑stop” parameter, like this:

/nasmcd/sbin/clariion_mgmt -stop

This command resets the IP addresses on the CLARiiON SPs back to their default IP addresses (out of the 128.221.x.x range). From there, the next step is supposed to be using the clariion_mgmt script again like this:

/nasmcd/sbin/clariion_mgmt -start -spa_ip A.B.C.D -spb_ip W.X.Y.Z -use_proxy_arp

If this command works—and it usually does—you’re good to go. Of course, it didn’t work in my case. This is where things start to get interesting. Assuming that the clariion_mgmt -stop command worked, you now have two SPs that are not reachable from the network. In order to change their IP addresses, you need to connect to them over the network. Obviously, you can see the problem. EMC provides two answers to this potential problem:

  1. You can use the EMC-supplied serial cable to establish a PPP over serial connection to the SP. Devang (aka @StorageNerve) has an article that provides more details on the settings for dialup PPP into a CLARiiON. Once you’ve connected via PPP over serial, you can access the SP using http://192.168.1.1/setup in a web browser. This will take you to a screen where you can set the SP’s IP address.
  2. Every CLARiiON SP also has a LAN service port to which you can connect using a standard straight-through Ethernet cable. The default IP addresses for the LAN service ports are 128.221.1.250 for SPA and 128.221.1.251 for SP B. (These are documented on EMC PowerLink; see EMC Knowledgebase article emc199379.) Once you’ve connected using the LAN service port, then you can access the SP using http://<default LAN service port address>/setup to change the SP’s IP address. (Changing the IP address of the SP does not affect the IP address of the LAN service port, so your own network connectivity is not affected.)

In this particular case, I was able to successfully connect to SP A using PPP over serial and change the IP address. For some reason, SP B would not establish a PPP over serial connection, so I had to use the LAN service port. It took only a couple of minutes to change the IP address on my laptop so that I could connect via the LAN service port and change SP B’s IP address as well.

Because the clariion_mgmt script didn’t work, I now needed to update some configuration files on the Celerra so that it would know how to communicate with the back-end CLARiiON SPs. (The clariion_mgmt script does this for you.) The specific information on which files need to be modified and the changes that need to be made are found in EMC Knowledgebase articles emc196029. I found that by following all the steps except step 6 I was able to get the Celerra talking to the back-end CLARiiON SPs. I verified this by using the clariion_mgmt script again as follows:

/nasmcd/sbin/clariion_mgmt -info

The script returned a correct proxy ARP configuration. In addition, the SPs were pingable both from the Celerra Control Station as well as across the network, and Navisphere worked as expected when accessing the SPs directly via a web browser.

The final step was to verify that the Celerra was properly configured for the updated back-end CLARiiON SPs. To do that, I used information found in EMC Knowledgebase article emc220238; specifically, I used the nas_storage command to rediscover back-end storage and ensure that no errors were reported. (By the way, emc220238 also contains information on which files on the Celerra Control Station need to be modified when the back-end SPs have their addresses changed.)

Remember, in the majority of cases the clariion_mgmt script will work just fine and it is the preferred method of changing the IP addresses on an integrated Celerra like the NS-960. These other steps are only necessary when the clariion_mgmt script does not work, or when you find yourself needing to recover a botched IP address change.

Additional information from those familiar with these technologies and processes is always welcome!

Tags: , , , ,