April 2010

You are currently browsing the monthly archive for April 2010.

Continuing the Consolidation Discussion

Monday, April 26, 2010 in Virtualization by slowe | 8 comments

This is just a quick post inspired by Mike Laverick’s recent “Stupid IT” post, in which he weighed in on the blog discussion between Steve Chambers and I regarding “putting all your eggs in one basket,” the most common argument against high consolidation ratios and, in some cases, against consolidation in general.

Mike’s articles—part 1 and part 2—are excellent articles. The interesting thing here is that, when you really boil it down, my viewpoint is not that far off from both Steve and Mike (spoiler warning: Mike agrees with Steve). In my blog post, I tried to focus less on whether high consolidation ratios are good or bad but instead to focus on whether the high consolidation ratios—and the impact of the design decision to use high consolidation ratios—will satisfy the needs of the business.

I agree with a number of points from Steve’s post. For example, I agree the root cause of an outage is more likely to be human error than hardware outage. I also agree that building redundancy into the infrastructure helps further reduce the possibility of an outage. Mike makes the same argument:

The truth is that hardware and software components are so reliable and redundant they hardly ever fail. In fact, so much availability software is geared towards protecting the server from hardware failure that some of my peers are beginning to question why they even buy SKUs that contain VMware HA.

So if everything is so redundant and so stable, why do people buy VMware HA? Why do people use clustering solutions like Windows Failover Clustering? Why do people use VMware FT or Neverfail or any of the rest of it?

The answer is simple: fear. Businesses are afraid of their applications being unavailable. In some cases, this fear is irrational, and from this perspective I agree wholeheartedly with both Mike and Steve: don’t use the “all my eggs in one basket” argument with me just because it scares you, just because you’re afraid of running all your workloads together.

On the other hand, though, this fear might be justified. What if the application or applications in question are the very lifeblood of the business? If you are an online-only organization, the need for your web site to stay up and accessible is crucial. If the web site is down, lots of money gets lost. In this situation, the fear of being unavailable is justified. It’s not irrational—it’s based on a keen understanding of the needs of the business and the impact of the outage upon the business. And in those cases, where suppressing consolidation ratios is used deliberately in order to satisfy the needs of the business, I’ll accept the “all my eggs in one basket” argument.

Come to me with the “all my eggs in one basket” argument backed by irrational fear and a lack of information, and I’ll argue against it every time. Come to me with the “all my eggs in one basket” argument backed by an understanding of how IT aligns with the business and the impact of an outage on the business, and I’ll listen to—and possibly even agree with—your position. As I and so many others have stated on numerous occasions, don’t pursue high consolidation ratios for the sake of high consolidation ratios. Pursue them because it makes the most sense for the business.

In the end, I guess my point is that both Steve and Mike have missed the point. Not that their viewpoints are irrelevant; quite the opposite! Both of them make very good points that are quite relevant and pertinent to the discussion of “Why not higher consolidation ratios?” Unfortunately, that’s not the question that needs to be asked or answered. The question should be, “What is best for the business?” In that context, putting “all your eggs in one basket” isn’t always the best answer.

Courteous comments welcome!

Tags: , , , ,

Configuring Inter-VLAN Routing

Friday, April 23, 2010 in Networking by slowe | 8 comments

Yesterday I completed the configuration of inter-VLAN routing (aka “router on a stick”, or RoaS) as part of my ongoing CCNA preparation. A couple people mentioned that they would find the configuration useful, so I’m posting what I have. This is by no means a comprehensive treatise on the subject; for that, you should look elsewhere. Google can find you lots of sites with more in-depth and detailed information on the reasons behind the necessary configuration.

There are two primary components in a RoaS configuration:

  1. The configuration of the VLANs and VLAN trunking port on the switch
  2. The configuration of subinterfaces on the router

I describe how to configure each component below.

VLANs and VLAN Trunking

How to create VLANs varies between various switch types. On some switches, you’ll use the vlan database command in privileged EXEC mode. On other switches, you will use the vlan <VLAN ID> command while in global configuration mode. Regardless of which method is necessary for your particular Cisco switch, you will want to ensure that the switch has all the necessary VLANs defined.

After the VLANs have been defined, then you will need to configure the switch port connected to the router as a VLAN trunk port. This is pretty well covered elsewhere, but here is a quick review of the commands (these commands assume port 15 on module 0, a Fast Ethernet port):

switch(config)# int fa0/15
switch(config-if)# switchport trunk encapsulation dot1q
switch(config-if)# switchport mode trunk
switch(config-if)# switchport trunk allowed vlan 1,71-75
switch(config-if)# exit
switch(config)# exit
switch#

A couple notes about these commands:

  • Some switches only accept 802.1Q VLAN encapsulation; therefore, the switchport trunk encapsulation dot1q command isn’t supported because that’s the only encapsulation supported. So, the support for this command will vary from switch to switch.
  • You will want to specify the correct VLANs for your environment in the switchport trunk allowed vlan command.

At this point, the switch is configured correctly; now it’s time to move to the router.

Subinterfaces on the Router

For each VLAN that needs to be routed, you will need to create a subinterface on the router. Creating a subinterface is pretty easy, the commands look something like this:

router(config)# int fa0/0.1
router(config-if)# encapsulation dot1q 1 native
router(config-if)# ip address 192.168.1.1 255.255.255.0
router(config-if)# exit
router(config)# exit
router#

As before, there are a few notes to consider about these commands:

  • The number of the subinterface (the “1″ in fa0/0.1 above) is only locally significant and doesn’t need to match the VLAN ID, but matching the VLAN ID makes it easier to associate the subinterface with its configured VLAN ID. Again, as stated earlier, you’ll need a separate subinterface for each VLAN that you want to route.
  • Only specify the native keyword on the encapsulation dot1q command if this is the native VLAN on the switch side as well. Otherwise, the trunk won’t form as expected.
  • The IP address specified here will be the IP address of the default gateway for that VLAN/subnet.

For the physical interface itself, the interface needs to be up (so don’t issue a shutdown command), but the interface does not need to have any IP address associated with it.

With this configuration in place, you should be able to route between the VLANs; just specify the IP address of the subinterface on the router for that VLAN as the default gateway of the systems on that VLAN and you should be good to go.

If I’ve missed anything glaring please speak up in the comments and let me know.

Tags: , , ,

Setting up a CCNA Study Environment with GNS3 and VMware

Thursday, April 22, 2010 in Linux, Networking, Virtualization by slowe | 16 comments

If you were following my tweets over the last few days, you probably already know that I have been working on setting up a CCNA study environment using Ubuntu Linux, GNS3, and VMware Workstation. After a couple days of difficulties, I finally managed to make it work last night. Here are the steps that I took to make it work.

Before we start, there is the standard disclaimer: these are the steps that worked for me; these steps might or might not work for you, and are almost guaranteed not to work with different Linux distributions or different versions of the associated software.

Here are the software components and versions that I am using in my environment:

  • Ubuntu Linux 8.04.4 LTS, 32 bit
  • GNS3 0.6.1
  • Dynamips 0.2.8-RC2
  • Dynagen 0.10.1.090807
  • VMware Workstation 7.0.1 for Linux, 32 bit

I won’t go into great detail on setting up Ubuntu Linux as there are plenty of resources available for that portion of this environment. You will need to be at least vaguely familiar with the Linux command-line interface (CLI) and basic Linux commands, or you’ll find this process a bit difficult.

Once you have Ubuntu Linux installed and configured appropriately, the first step is to go ahead and install some dependencies using apt-get:

sudo apt-get install dynagen python-qt4

This should download and install both Dynagen and the Python-QT4 libraries. Next, you’ll need to download and install GNS3 0.6.1. There are newer versions of GNS3 available, but earlier attempts to get this environment running with the newer version of GNS3 resulted in problems. Again, your results might differ. Version 0.6.1 of GNS3 is available from the GNS3 SourceForge site.

Once you have GNS3 downloaded, extract it into the directory of your choice (I chose to use /opt/GNS3).

After you’ve downloaded and extracted GNS3, create the following directories under the directory where GNS3 is found:

<GNS3 directory>/project
<GNS3 directory>/ios
<GNS3 directory>/cache
<GNS3 directory>/tmp
<GNS3 directory>/dynamips

Use the chmod and chown commands as necessary to ensure that your user account has full read/write permissions all of these directories except the dynamips directory.

Download a copy of Dynamips (it’s generally available here), put it into the dynamips directory you created, and use the chmod command to make it executable. I also found it necessary to set the Dynamips binary’s SUID bit so that it would always run as root; I know this is not best practice but I could not find any other workaround. (Without setting it SUID, GNS3 would always report an error when trying to launch Dynamips.)

Now launch GNS3 and use the Preferences in the application to set the correct path to your project directory (<GNS3 directory>/project) and the IOS/PIX directory (<GNS3 directory>/ios), the correct path to the Dynamips binary (<GNS3 directory>/dynamips), the correct path to the working directory (<GNS3 directory>/tmp), and the working directory for capture files (set it to your project directory).

At this point you should have a working GNS3 installation. You’ll still need to locate IOS images to use; once you have valid IOS images, place them in the ios directory you created earlier and configure them within GNS3 as needed. You should then be able to create a router instance, boot it, and access the router console from within GNS3.

You could stop there and have a pretty cool environment, but I wanted to go a step further. I also installed VMware Workstation 7.0.1 (I won’t go into detail here, it’s a pretty simple process) and then used the Virtual Network Editor to create some additional host-only networks (in addition to the default vmnet1). Again, this is well-documented already, so I won’t discuss the process in any length. Where it gets interesting is in how you connect GNS3 and these host-only networks so that VMs can be incorporated into your GNS3 router topology.

Here’s how you connect GNS3 and the VMware Workstation host-only networks:

  1. In GNS3, add a cloud object to the topology.
  2. Right-click the cloud object and select Configure.
  3. On the NIO Ethernet tab in the Generic Ethernet NIO section, select one of the host-only networks (like vmnet1) and click Add. This creates a link between the cloud object and the selected host-only network.

At this point, you can attach a VM to the selected host-only network, attach a router to the cloud, and be able to pass traffic from the VM to the router. Pretty cool, huh?

What I’ve done so far is create a simple network with two VMs attached to two different host-only networks which are in turn connected to two different cloud objects and two different routers. Then I created a “serial WAN link” between the two routers (GNS3 won’t, as far as I can tell, actually simulate WAN links with bandwidth limits and latency) and configured everything so that I could pass traffic from one VM to the second VM across the “virtual WAN”. The plan is to increase the network complexity—as much as my poor little Dell laptop will allow given its limited CPU and RAM—and work through the various CCNA study guides in preparation for my exam.

One other quick note about this setup (and the reason why I chose Linux as my host platform): by setting up SSH on the Linux system (with a simple sudo apt-get install openssh-server), I can now SSH into the Linux host system and then use Telnet from there to access all the various routers. In addition, because I’m using OpenBSD as the guest OS on my VMs, I can also SSH from the Linux host to the OpenBSD VMs (assuming my GNS3 network is configured correctly). I’m also thinking that there’s a way I can leverage some VNC connectivity through Workstation to access the VMs as well, but I’ll need to research that a bit to see how it works.

I would be remiss if I did not point out a couple of sites that were extremely helpful in getting this setup up and running. First, this site provided an excellent overview of the GNS3 installation on Ubuntu. Although the walk-through was for a newer version of Ubuntu, the instructions worked perfectly on 8.04.4 LTS. Second, this site gave me the “missing link” on how to connect GNS3 and VMware Workstation’s host-only networks so that you could mix the two environments. Thank you to both sites for outstanding information!

If you are a GNS3 expert or have some additional tips or tricks to share, please add them in the comments below so that all readers can benefit. Courteous comments are always welcome.

Tags: , , , , , , ,

Thinking Out Loud: What is multi-hop FCoE?

Wednesday, April 21, 2010 in Networking by slowe | 10 comments

It’s been a while since I last posted a “Thinking Out Loud” post, but a Twitter discussion this morning prompted me to post this one. Last night, I posted a question to Brad Hedlund (@bradhedlund on Twitter and a great data center networking resource) regarding the Nexus 2232PP fabric extender. My tweet to Brad was this: does the Nexus 2232PP make “multi-hop FCoE” possible via NIV?

(If you haven’t already read my post on the relationship between FCoE and NIV, go read it now as it provides a good background and context for this discussion.)

Brad responded, confirming my assessment and stating that FIP snooping wasn’t necessary. I wasn’t sure about the FIP snooping part but after seeing the response I now understand. In any event, a number of others starting questioning my use of “multi-hop FCoE” in conjunction with the 2232PP fabric extender, stating that it wasn’t a hop because ti does not actually switch any traffic.

Strictly speaking, all of these individuals are absolutely correct; for more information, go read this post on NIV. In this case, the Nexus 5000 is the interface virtualization (IV)-capable bridge and the Nexus 2232PP is the interface virtualizer (IV). The IV doesn’t switch any traffic; all switching occurs on the IV-capable bridge. Therefore, from a switching perspective, a Nexus 5000 and any or all associated fabric extenders are a single hop.

My response is this: what is multi-hop, anyway? Is it the presence of multiple switches in a data path between an initiator and a target? Or is it the presence of multiple physical devices, chained together, between an initiator and a target? In the first definition, using a fabric extender isn’t multi-hop; in the second definition, it is. More to the point, should a customer really care which definition is correct? Why is multi-hop FCoE important, anyway? I would say the answer to that question is scalability. Customers want to be able to scale the FCoE fabrics larger than they can today. Multi-hop FCoE—however you want to define it—makes that possible. So does it really matter how we get there? Besides which point, using the fabric extender approach means only a single point of management instead of multiple points of management. Isn’t that better?

What do you think? Do your own “thinking out loud” in the comments below.

Tags: , , , ,

Am I Understanding RoCE Correctly?

Tuesday, April 20, 2010 in Networking by slowe | 8 comments

A couple of days ago I posted a tweet inquiring about RDMA (Remote Direct Memory Access) over Converged Ethernet, affectionately known as RoCE and even more affectionately pronounced “Rocky”. At the time I was unclear exactly what RoCE was and what it was trying to accomplish.

Since then, I’ve done a bit more research and I think that I have a better idea of RoCE now. In particular, this EE Times article provided some information that I found useful in putting the pieces together.

If I understand things correctly, RoCE does for InfiniBand what FCoE did for Fibre Channel—it replaces the physical transport mechanism with 10 Gigabit Ethernet. More specifically, Converged Ethernet, which is the particular flavor of 10Gb Ethernet that supports the IEEE Data Center Bridging (DCB) standards like Priority-Based Flow Control (802.1Qbb), Enhanced Transmission Selection (802.1Qaz), and Congestion Notification (802.1Qau). These DCB standards are intended to make Ethernet less “lossy” and “chatty” and more reliable, predictable, and lossless like Fibre Channel (or InfiniBand).

Fibre Channel over Ethernet (FCoE) took the physical transport layers of traditional Fibre Channel and replaced them with Ethernet, and the IEEE created the DCB efforts to make sure that the underlying Ethernet transport was reliable and lossless so that it could support FCoE. Because it still “looked” like Fibre Channel at the upper layers, there is a great deal of interoperability between Fibre Channel and FCoE.

In a similar fashion, RDMA over Converged Ethernet (RoCE) does the same sort of thing, but for the RDMA interfaces that are common to InfiniBand. It takes RDMA and puts it on Ethernet, again relying upon the IEEE DCB standards to make Ethernet reliable and lossless with predictable latencies. No more proprietary fabrics; with RoCE-capable adapters, you’ll be able to reap the ultra-low latency benefits of InfiniBand over standards-based 10Gb Converged Ethernet.

At least, that’s how I understand it. Anyone else have a better explanation?

Tags: ,

Another Collection of UCS Posts

Monday, April 19, 2010 in Virtualization by slowe | 1 comment

It’s been a couple of months since I posted my last collection of UCS-related posts. Since that time, I’ve collected a few more posts, so here’s another collection of UCS posts (in no particular order).

The State of Statelessness: Cisco UCS vs. HP Virtual Connect
Gestalt IT Tech Field Day – On Cisco and UCS
How Cisco UCS Deals with Split Brains
L2 Forwarding Rules in UCS EHV Mode
Scalability Study for Deploying VMware View on Cisco UCS and EMC Symmetrix V-Max Systems
Cisco C200M1 CIMC Update Process

As I uncover more UCS posts, I’ll bring them to your attention here. If you have some useful UCS information or useful UCS posts, please feel free to add them to the comments below (with full vendor disclosure, please). Thanks!

Tags: , ,

Virtualization Short Take #38

Saturday, April 17, 2010 in Storage, Virtualization by slowe | 2 comments

I really should get into the habit of posting these short takes more often! It’s been a while since the last Virtualization Short Take and now I have a huge collection of items that I wanted to mention. Anyway, without further ado, here’s Virtualization Short Take #38!

  • If you are looking for some additional information on creating unattended installation scripts for VMware ESX 4.0, be sure to check out this post from Arne Fokkema. Arne’s post on hot adding or removing a VMDK with a Linux VM is worth a read, too.
  • Similarly, those of you interested in running ESXi on USB should be sure to check out Simon Seagrave’s article on the “official” way to install VMware ESXi 4.0 to a USB stick.
  • Maish has a couple of good posts that I picked up recently. First, he provides some step-by-step instructions on injecting VMware drivers into the source OS before performing a physical-to-virtual (P2V) conversion (here is the VMware KB article upon which Maish’s article is based). Next up is a good article on installing PowerPath/VE using VMware Update Manager (again, here’s the source VMware KB article).
  • For the ThinApp lovers out there (and what’s not to love?), this site has ThinApped versions of many open source software packages.
  • As is usually the case, Duncan Epping has a number of very informative articles. First, he lifts the veil on an upcoming feature to assist with VMware HA split brain scenarios. Next up is a great discussion about the virtue of reducing the I/O operations limit (for Round Robin multipathing using vSphere native multipathing) down to 1 (more information on this topic from Chad’s blog as well). Equally valuable as the article are the comments on the article! Finally Duncan also tackles the concept of VM disk alignment, which is not a new issue but it’s great to see it getting more attention. Keep up the great work Duncan!
  • Didier Pironet of DeinosCloud has information on how to increase the number of VMware HA primary nodes beyond 5. It’s very important to note that this is an unsupported configuration, but the article does provide a bit of insight on the configuration of VMware HA if nothing else.
  • Gabe brings to light a potential problem with the interaction between VMware DPM and VMware HA admission control (there’s also a VMware KB article about it). If you run VMware DPM and VMware HA with admission control disabled, be sure to have a look at these two resources for more information.
  • I also came across this article which describes some undocumented command-line paramters for the esxupdate command. Pretty handy!
  • Jason Boche describes a bug in the ESX(i) failback behavior (or, more appropriately, the no failback behavior) that could have some pretty serious side effects if you’re not careful with your design. Jason also has a good post on the manual steps required in order to use the WDDM video driver for Windows 7 and Windows Server 2008 R2.
  • As pointed out here, don’t forget to install the SQL Native Client if you’re running Windows Server 2008 R2 x64 for your vCenter Server; otherwise, you’ll find yourself unable to create a compatible DSN. Note that I think this applies to a few other versions of Windows as well; I know that I’ve had to do it a few times.
  • This post underscores the need to understand the relationships between all the various components of a VMware vSphere deployment and to understand the impact of various design decisions. The post outlines an issue where IP-based storage is used and memory pressures are forcing storage connectivity issues because of increased utilization of VM swap (which is also stored on the IP storage array). There are also follow up posts here and here with more information and results from some testing.
  • Microsoft recently released MED-V 1.0 SP1 and localized versions of App-V 4.6, as announced here.
  • In reviewing the weekly KB digests, I found a few interesting articles:
    Changing Parvirtualized SCSI Controller Queue Depth
    Guide to configure NTP on ESX servers
    Testing a VMware Fault Tolerance Configuration
    High rate of Fault Tolerance failovers on Intel Xeon Processor 3400, 6500, and 7500 series
  • Via this post by Frank Denneman, I learned of VMware KB article 1008205 on how to use esxtop to identify storage performance issues. Also be sure to check out a few of the other links in Frank’s article, all of which also provide good information.
  • VMware’s competitors love to harp on memory overcommitment, which can—if used improperly and inappropriately—have a negative impact on performance. As a result, I was glad to see this post by Scott Drummonds on using memory reservations to drive overcommitment for optimal utilization of memory on your ESX/ESXi hosts. Good post, Scott!

OK, that does it for this time around. As always, feel free to speak up in the comments if you have additional information, links, clarifications, or suggestions.

Tags: , , ,

The Everything VMware at EMC Community

Tuesday, April 13, 2010 in Storage, Virtualization by slowe | No comments

I think that Chad might have posted something about this new community, but I wanted to also mention it myself. The “Everything VMware at EMC” Community, part of the EMC Community Network (ECN), is a new online community that EMC has recently established. There’s a growing amount of content out there; here are a few notable items:

  • Copies of some of the recorded demos that the vSpecialist team has created, like a recorded demo of the NFS plugin for vCenter Server
  • A calendar of VMware-EMC events, including the weekly webcast
  • Useful technical documents, like this Vblock Reference architecture document

Of course, any community is only as useful as the members of that community. If you haven’t yet signed up to join the Everything VMware at EMC community, please do so! Let us know what sort of content you’d like to see so that we can make this community even more useful to you.

Tags: , ,

Some EMC Data Domain Announcements Today

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

EMC Data Domain made a couple of significant product announcements today. First, EMC announced the EMC Data Domain Global Deduplication Array (GDA). Second, EMC also announced a doubling of the logical capacity for the high-end Data Domain DD880.

The full press release for the GDA announcement is available here. The “speeds and feeds” of the new multi-controller architecture of the GDA include throughput of up to 12.8 TB/hour, up to 270 concurrent backup operations, and up to 14.2 PB (yes, petabytes) of logical storage capacity. That’s pretty impressive, if you ask me.

As for the doubling of capacity on the DD880, the full press release has all the details. In addition to greater capacity on the DD880 (up to 7.1 PB of logical storage capacity), the announcement also unveiled Data Domain encryption. This represents the industry’s first encryption of data at rest on deduplicated storage. Encryption occurs inline using administrator-selected 128-bit or 256-bit Advanced Encryption Storage (AES) algorithms.

Take a look at the full press releases for both these announcements for more information.

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: , , , ,

« Older entries