Sometimes very challenging problems will arise.  Things that make you scratch your head, want to hurl your coffee cup, or just have a nice cold adult beverage.  Customers can change a projects requirements mid-way through, a vendor’s storage array code upgrade can go awry, or a two can creep into the ones and zeros.

In this section, we present examples of those crazy situations with the hopes of helping out our fellow engineers in the field before they become as frustrated as we have!

Recently in working with a customer, the request was for a new cluster comprised of ESXi 4.1 hosts.  They would be using just two onboard NICs for the vmkernel and virtual machine traffic.  These two NICs would feed into a pair of Cisco Nexus 5020’s, using virtual port channel (VPC).

Because of the use of VPC, the virtual switch load balancing needs to be set to IP Hash for the NIC teaming policy.  Okay, no sweat!  After installing ESXi and completing the initial configuration on the hosts, it was time to add the second NIC to vSwitch0 and plug it in.  (Note this configuration is all being done on the hosts directly as no vCenter server has been built yet).  After adding the second adapter to the active section of vSwitch0, and changing the NIC teaming policy to IP hash, we plugged in the second cable.

The host immediately lost connection from our vSphere client, and dropped off entirely from being able to be contacted.  No ping, no nothing!  This was most puzzling indeed:  we unplugged the second cable and the host started to ping again.  We thought maybe there was something wrong with the NIC itself, and so setup a separate NIC to take its place.  This had the same result, and we then thought to look at the switch.  After discussing the current configuration with the network engineer, we felt that his configuration was correct.  The configuration (and more!) can be found in the white paper put out by Cisco and VMware: “Deploying 10 Gigabit Ethernet on VMware vSphere 4.0 with Cisco Nexus 1000V and VMware vNetwork Standard and Distributed Switches – Version 1.0” This doc has been a very helpful during the implementation of this project.

So!  With the network being deemed not the problem and wearing a sheepish smile on my face after the network guy commented “it’s always the network isn’t it?” I returned to the host.  I then tried setting up both NICs on a non-nexus switch that is being used for out of band management, and they worked just fine using virtual port id for NIC teaming.  So at that point, I fired up the googalizer and did some checking.  I came across this KB article from VMware:

VMware KB 1022751:  NIC teaming using EtherChannel leads to intermittent network connectivity in ESXi

Details:

When trying to team NICs using EtherChannel, the network connectivity is disrupted on an ESXi host. This issue occurs because NIC teaming properties do not propagate to the Management Network portgroup in ESXi.
When you configure the ESXi host for NIC teaming by setting the Load Balancing to Route based on IP hash, this configuration is not propagated to Management Network portgroup.

So, based on this very helpful information, I followed the instructions listed in the KB and had great success.  Now my ESXi hosts are talking on both NICs via IP Hash and life is good.

About Mike Mills

Mail | More Posts (20)

ONE]

The tight rope act begins with the storage array, our bright and shiny EVA.  At a fundamental level, an EVA is comprised of two controllers.  The operating environment of the EVA is such that it can, in a semi-intelligent fashion, manage vdisk ownership between the two controllers itself.  By default, vdisks are set to no preference for a failover/mode setting at the time of creation.   This means the EVA will decide which controllers get which vdisks when it (the EVA itself) boots.  Every vdisk is assigned to a controller (and only one controller).  If the non-owning controller is receiving the IO for a server(s) talking to a vdisk, it will after a period of time change the ownership of the vdisk.  This will reduce the load crossing the mirror ports.   While the EVA can run in this fashion, it is sub-optimal.

The other side of the tight rope of this balancing act is the hosts.  IO can walk many paths from host to array, some optimal and others not.  The start of such begins at the host’s adapter.  If it is a dual port (or multiple single port) host, then you have all the more paths to choose from.  Even in the case of a single port host, you can still cover multiple paths to arrive at the vdisk.  The handling of the proper path comes in the form of multipathing software.  From HP for Microsoft operating systems, we have Device Specific Module (DSM), which uses MS’s MPIO stack as its basis.  HP makes specific DSM’s for each of its line of arrays.  Without the MPIO stack, the host will see a drive presented once for each host port.  In an 8×00 series array, that is 8!  So clearly the MPIO software and HP’s DSM is needed for correct operation.  The default install does not enable Adaptive Load Balance (ALB).  This hampers read operations by not passing through the correct controller for a vdisk.  Note that non-MS based operating systems (like VMware) have their own multipathing stacks.  In the case of VMware ESX(i) 3.x, the options are fixed and mru.  In the case of vSphere, we get round robin added to the mix.  In pre-vSphere environments, the fixed path does not by default balance load across the host ports.  You can end up with all your VM traffic running over one host port!  Yikes!

TWO]

Now, to balance things out, let me start with the array.  A good habit to get into involves understanding your environment from an IO perspective.  You need to understand the profile, or workload, of your IO, so that you can balance between the controllers (among other things!).  Make sure to capture your performance data using evaperf (or other tools) to allow you the view of your controller’s current load.  As you add new vdisks, you can balance them by setting the failover/mode setting to the controller with failover + failback.  This will allow the balancing to remain should you lose and regain a controller.  Further, this specifies the controller for the vdisk in terms of mastership.  This helps from the host side as the controller it needs to talk through is clearly defined.  One thing to keep in mind also is the need to accept all load on one controller should failure occur.  This should be something you are aware of via your performance data.  A good rule of thumb is a controller should be no more than 30% ideally (at least in my experience).   And as always, have the latest Command View and XCS code.  One other thing to check for balance is to make sure the host ports are set to their top speed (4GB, except the very old EVA models) as well as properly balanced on the fabric (equal ports on both sides).  One customer I came across had all ports from controller A on fabric A and all ports of controller B on fabric B!  Definitely a big problem there!

For the host side, there is a bit more that can be done.  There is some work to be done on the array as well, which I will address.  The hosts should have the latest firmware, drivers, and software for their HBAs.  Additionally, make sure you have the latest HP DSM software.   Within the DSM software, you will want to enable Automatic Load Balancing.  As I stated before, this is not enabled by default.  To enable, just right click on each LUN (listed by WWN) that is listed and choose Enable ALB.

So, as a quick explanation:  write requests from hosts will hit the controller that owns the vdisk in question, but that write will propagate over the mirror link into both controllers’ cache.  This is in case a controller is lost, the write can still be committed.  Read requests will hit whichever controller, and if it is the wrong controller, will have to travel over the mirror ports to the correct controller.  This is sub-optimal, but is alleviated by enabling ALB.  ALB communicates with the array and will always communicate its read requests through the owning controller.  Very handy!

Now, from a VMware standpoint, let’s talk about fixed and then round robin (two most common multipathing situations found today).  For Fixed, you will need to balance IO to your datastores over the host ports of the controllers.  Also keep in mind which controller you selected at the array.  As an example, if I have 8 datastores of average IO (no virtualized heavy apps) then I would want 4 datastores on each controller.  To further balance, I would have each datastore talking over one of the host ports for each of the controllers (4 ports per controller x 2 controllers).  The IO is evenly balanced.  To set this, simply go into each datastore properties (via the VI Client) and pick the WWN for the corresponding host port).  Under heavy IO circumstances, you may not be able to move your traffic to a different host port.  Just try again at a later date.  When it comes to round robin, the IO works a bit differently.  Round Robin will send IO to each host port in turn after a certain amount of IOPS.   In the HP best practices for vSphere on the EVA, it states to change this value to 1 (and thus pushing even IOPS over every host port visible).  There was a bug which would, after a reboot of the ESX(i) host, reset this to a very high number.  I have found in my experience that leaving it as-is seems to work fairly well.  I would guess there is good reason that HP came up with that figure, and so at this point, with vSphere 4.1, I would suspect you could set this without issue.

Summary

Presented here are some of the findings I have come across in working with different customers.  I figure that having these kinds of storage discussions can help to make for a very engaging conversation.  Let me know what you think (and if I make any errors, which being human, am prone to!

About Mike Mills

Mail | More Posts (20)

How many times have you stood up a new environment, and migrated VMs, only to come across an old crusty Windows 2000 Advanced Server with Pervasive SQL (oh god, btrieve!) that still lurks in the lower regions of your vm sprawl. Yes, this lower denizen, or Zombie, had its roots in good intentions. You see, in the olden days, VMs sprung into consciousness for all sorts of development duties. However, due to a lack of regulation, and attention, they began to languish. Further, these zombie’s could be multi-headed (from decaying snapshots) and fiendishly hungry (4 vcpu’s for your cold fusion vm or 8GB ram for your 3 SQL instances that just have to mimic production). Before we dig out the shotgun and gas up the chainsaw, let’s look at the characteristics of a VM Zombie.

Know your Enemy: ZOMBIES!

First, it’s important to understand the distinction between a VM Zombie and a Zombie process. Think of them as greater and lesser zombies. A VM Zombie is a virtual machine that has been left to suck resources, yet perform no real task. Its idle hands merely wish to be used to devour tasty ram and cpu cycles. Let it also be known that VM Zombies can drop chunks of body parts (folders/vmdk/files) on your storage array as they stumble through your environment. Gross! A zombie process on an ESX host is a process that is dead, and you cannot kill the dead. We will be focusing on the VM Zombies, so grab your laptop (blunt object trauma!), survival rations (beer), and let’s learn about Virtualization’s Great Menace!

To kill zombies, we need tools. Big, sharp, loud, gunpowder-based tools. We’ve got two two great tools on tap: one paid and one free that I turn to in times of the undead feasting on the living flesh of my hosts. These tools are well known in the community and lots of information can be found about them.

VKERNEL – Optimization Pack

VKernel make a number of excellent tools, both paid for and free. When it comes to quality for decapitation of the Zombie Menace, I have to say I am very pleased with what this application brings to the table. First and foremost, as your virtual infrastructure scales (and sometimes sprawls), it can lead to lots of Zombie action. Wastefinder (a part of this pack) is absolutely brilliant J Not only does it help you find the roving Zombie hoard (snapshots included), it provides the empirical and historical data to validate. This goes hand in hand with rightsizing VMs, which can be troublesome if you get pushback from application owners, management, etc. Virtualizetips.com has had the privilege of previewing these tools, and I agree that their Gold award from VMworld 2010 is well deserved. Take that you brain-slurping bastards!

http://www.vkernel.com/products/optimization-pack

RVTOOLS

I have been using this tool in my home lab for quite some time, and also in my various locales of employ. Being free, this is a very solid app for tracking down zombie bits (both hunks of dead flesh on your storage array, and also snapshots and unregistered, rogue VMs). It will also export in a nice CSV format so you excel nerds can get your game on. I really like the quick and dirty view of an environment. It lets me zoom in and get what info I want quickly. At a glance, you get so much more also: build numbers, VMware Tools levels on your VMs, and all the hardware content for your VMs. This is a great keep-on-the-laptop tool if you have many clients to visit and need to get a quick assessment of their hotspots.

http://www.robware.net/

Coming in Part 2, more tools, tips, and survival tips to bring the fight to the Zombie Horde! Groovy!

About Mike Mills

Mail | More Posts (20)

As you can see from the image below our first line protector is ready to use the full power of our Monitoring and Chargeback tools to take down the Zombies. She is already waiting in the Datacenter to blast the offenders.

Also, big thanks for posting my email retort!

http://www.zombievm.org/contact.html

About Mike Mills

Mail | More Posts (20)

So last night I sat down and did some old fashioned thinking about how I can get the information I need, but easier and with less effort. I started toying with powershell as it’s a good friend in the VMware space. I have to confess though that I have a Mac. Yes, I enjoy monotasking. Nothing wrong with that I then realized (as I sometimes forget) that I had a whole delicious CLI on my mac. This includes great tools like grep and diff! Well and a lot more, but I’ll stick to those for now. (Note that you can get grep and diff for Windows, via either the Windows versions of those tools, or using Cygwin). Fear not win32 folks, you are covered!

Let me take a step back and cover the premise for wanting to gather information from SSSU. As we know, Command View is a web-based interface for communicating with the EVAs. While it does provide lots of information, it is troublesome to navigate around and get that information easily. One off kinds of things, certainly. But pulling in lots of info easily, I think not. One big flaw, in my mind, is that CV talks to the EVAs via the SAN, and not via IP. Why is this a flaw? Well, for instance, SSSU can’t talk directly to the EVAs themselves. Rather, it has to talk to the CV server (which is why it prompts you when you fire it up for a “manager”). This also means you can’t use SSSU to do anything if your CV server has bit the dust. But I digress.

From the arrays, I want to gather information on my vdisks, my controllers, snapshots, disks, and my disk groups. I want to gather some information once, some monthly, and some on a more regular basis.

For the vdisks, I run (via SSSU) this command: LS VDISK FULL > vdisk.txt (This will output the information into a text file in the directory where the sssu.exe is located) Then, I fire up my command line, and grep that sucker for some info:

grep “familyname\|allocatedcapacity\|redundancy\|diskgroupname” textfile > date_vdisk.txt

This output will give me a file with the date that has the information I am specifically looking for

As stated before, I am quite lazy and so I could use (or you could use) awk (another great command line text processor) to generate the output in a better format. But instead, I keep it like this. Note that allocatedcapacity is the vdisk size in GB. Now, since I’m generating these files monthly, I can use the diff command to compare two months and see what has changed (disk grows, adds, deletes, etc).

diff -y date_vdisk1.txt date_vdisk2.txt | grep “familyname\|allocatedcapacity”

Note the | in there. The older date is on the left, and the newer date is on the right. So it’s easy to see which has changed and by how much. Arguably you could make this even easier, but again, lazy. And this works for me, so your mileage may vary.

Since these are simple text files, it’s easy and pain free to keep them around. Overall, I use this information for vdisks to track growth, easy at a glance for what vdisk is what size/raid level, and you can also pull out info to find out what controller has what disks.

This leads me into talking about what information I grab from my controllers. Now, one thing to note: The EVA4400 series only has one listed Controller (in this case Controller 1). This is because of how it is designed: both controllers are in the same housing, sharing a back plane. We have three 8100 series, each having two physically separate controllers, listed as Controller 1 and Controller 2.

First, to find out ALL the info on your controllers, do LS CONTROLLER FULL in SSSU. The output will be big and full of interesting details. One other thing to note: SSSU denotes them as Controllers 1 and 2. Command View denotes them as Controllers A and B. Lame! For what I need, I don’t need to keep controller info like I do vdisk info. I will do an initial grab after an XCS code update to keep handy.

One pretty handy way to find out what snapshots you have on any given EVA for a point in time is to use LS SNAPSHOT. You can also do an LS SNAPSHOT FULL if you want the full info per snapshot (like the vdisk info). The key difference between a snapshot and a normal vdisk is the line item sharingrelationship. A normal vdisk will have none, but a snapshot will say snapshot

When it comes to gathering information on disks, I use this primarily to check firmware levels. If you are an EVA owner, you know that as part of the care and feeding of an EVA comes making sure all drives are at the most current level of firmware. Updates are also usually done and bundled with XCS updates. One thing to be aware is that with drive failures, replacements may not always come with the latest firmware. They should, but I have not always seen that. Thankfully firmware updates are non-invasive (for the most part). I will cover an XCS code upgrade in a future blog post (our EVA4400 is due).

So, if you do LS DISK FULL from SSSU, you will get all the info from each disk. You can then just grep for fun and profit!

grep “diskname\|firmware” disks.txt

So you are saying hey that’s great, but I have multiple kinds of disks in my EVA. So, you need to know what model of drive so you can keep things sorted as to what firmware is for what drive. Easy way is to just sort by disk group. Since you built your EVA correctly, you know only to put drives of the same type and speed into the same group right?

grep “diskname\|diskgroupname\|firmware” disks.txt

You can also grab the model number for the drives by tossing in modelnumber to the grep.

And finally, since you all are probably bored to tears now, I grab the size of the disk group to know what kind of overall growth or change occurs on each group. I can also use this information to plan out new server storage requests, and manage to 90% capacity. Easier to give management a shiny graph saying “Look, almost out of disk. Checkbook time!”

Okay, so that about wraps up what I use SSSU for. If I think about anything else neat that I do, I’ll be sure to blog about it. The next blog topic will be about WEBES, its use, the install, and the fact that it actually works pretty good. J

About Mike Mills

Mail | More Posts (20)

So it is with that preface that I arrive at discussing the SSSU: HP’s Storage Scripting System Utility. The premise of this utility is to allow command line access to an EVA. The idea is, at least from HP’s perspective, to use it for repetitious activities that would be otherwise tiresome in Command View. Additionally, you can also issue interactive commands like restarting a controller or changing mastership for disks between controllers manually. HP bundles the SSSU installer with Command View’s installer package. It carries the same versioning as Command View (so in my case, 9.1.0).

SSSU seems like a really great idea. I love the command line (being very partial to a bash shell ), but SSSU isn’t a real CLI in that sense. The first round of trouble is in the output: SSSU generates XML based output that a human can’t simply open up and read. This throws out a simple way to grab information that would otherwise take a lot of time via CV. This posting is an overview of SSSU, and I will write a follow up post that goes more into depth on what you can do with the output to make it actually usable in conjunction with Microsoft’s Logparser tool. Sad I know. You can pony up big $ to get actual tools but hey, in tight times, stretching the imagination is better than stretching the wallet. I’ll also put up some of the scripts I use to gather data on disks and such (ex: easy way to track disk size and growth).

At this point, let’s get SSSU fired up and play around a bit. To launch, log into your CV server and run that fancy icon on the desktop. One quick gripe: no way for me to install this on my own laptop to just run and connect with. To get around that, I copy over from the CV install to my local machine the SSSU.exe file. It runs great and it’s just that less than 2 meg file. Upon launching it, you get to login.

You get three parts to a login:

You can login with a domain account without any issue, so you don’t have to create a whole separate user account list. One thing to note is that although you can fire up multiple SSSU windows to one array, you can only execute commands to it one at a time (serial baby!), so when one command is running in one window, your other windows would hang if you tried to execute a command).

After logging in, you are sitting at a default path, so to speak. That being that you have not selected your array.

Hitting ? and enter will list off all the commands available. This can also be used to find out what options each command has available.

Object names are case sensitive and are organized in a root tree system. Commands and objects with spaces in their names require double quotes. The first thing to do is select an EVA to work with, using the term select system.

You can flip around using the select system command. At this time there isn’t a way to issue group commands (outside of scripting, and even then it’s not a group command, in that sense).

Root Structure of Objects:

\Hosts

“\Disk Groups”

“\Virtual Disks”

\Hardware

Note that you can create objects (like folders) under all but \Hardware. Objects created are purely for human organization. The EVA doesn’t care if you have them or not (though if you do create them you need to be aware of the “path” to them.

A complete listing of the commands can be found in the SSSU reference doc, found here:

http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02493404/c02493404.pdf

This link is for the latest (I believe rolled into Command View 9.3) as of this date (9.23.2010).

My advice would be to look through the command reference to understand what the commands do. Listing them all out here in a blog post would be silly. And a lot of work, and I’m lazy, so….

As promised before, I will follow up this post with a more in-depth guide for where SSSU is handy and probably some more complaints on how it’s irritating. J

About Mike Mills

Mail | More Posts (20)

Overall, and perhaps due to the time available, it felt like the presentation was a bit light in material.  It did have some good insight into certain aspects of best practices for virtualization of each app, and did point us to the white papers / resource materials for further study.  But it really was more like what you could get in a 2-3 page pdf attached to an email.  When I asked a question regarding using two adapters and should they both be pvscsi (if the hosts supported such) or is there a specific use case for such, I was told “oh, yeah, use two adapters”.  I felt like there was no interest in hearing my question, let alone even answering my question.  Overall though the pdfs I pulled down are pretty useful and should be helpful as my company seems to understand that “it’s okay to virtualize when we move to Exchange 2010″.  SQL is another battle entirely, but they’ll come around.  The art of the food bribe is an essential part of my utility belt

After the VMware presentation, Netapp (who was sponsoring this meeting) had an engineer or three onhand to give a general feature overview.  It felt alot like the Compellent talk that was given at the recent Chicago VMUG.  Brian and I were talking about this:  we don’t really need a marketing effort by itself.  Bring along a customer or two, one who will give both good and bad feedback regarding their product.

Bit of a side story:  my company is allowing me to help guide them to purchasing a new dedicated VMware storage platform to get us off the icky EVAs.  I’m eager as it’s basically going to be between Netapp and EMC.  In fact we are being flown down by our VAR PDS to Netapp HQ for a meet and greet, plus executive briefing August 16-18.  Maybe I’ll get lucky and meet Vaughn and get an autograph *laughs*

I’ll also be attending the VMware Support Day August 19th hosted by the Wisconsin VMUG.  Looking forward to good conversation and copious amounts of pasta!

About Mike Mills

Mail | More Posts (20)

A healthy set of modules looks like this:

Now, for the EVA we have problems with, it looks like this:

This problem occurred after we had this particular module fail. We received a replacement from HP and swapped it out. However, after a few days, it was marked as failed again. Again we received a replacement from HP, and swapped it out. A few days later, same result. In contacting HP a third time, I explained what had occurred. In response, I received this notification:

This is just another somewhat oddball error that we deal with on a regular basis. Now, on to the fix! To restart the controller in question, first note as per Command View which controller is in question. In my case, it is Controller A (just follow the bang indicators)

A restart of the controller should be done during your change / maintenance window (all those years of ITIL ingrained in me!). To do so, you have a few choices.

The first is via Command View:

On the controller’s page, hit shutdown, then restart and the controller (A/B).

The second is via the SSSU utility (installs as part of the Command View install):

Restart controller A, but not its peer controller:

RESTART “\Hardware\Rack 1\Enclosure 7\Controller A” NOALL_PEERS

Note that when restarting the controller, if it is the master controller the vdisks will transfer to the other controller without any downtime. In my experience with the EVAs, they are a touchy lot. I prefer using the SSSU utility for a halfway decent command line interface. Pretty powerful too. I’ll be writing up a blog posting discussing good uses for SSSU in the future.

About Mike Mills

Mail | More Posts (20)

So as you can see, we have a total Capacity (which is correct and accurate), and the Occupancy. The information listed is correct, and it’s refreshing. Now, for the problematic Disk Group (and please ignore the name as it was before my time).

Here we see the correctly calculated Capacity, but lo! What’s this? What on earth is going on with that Occupancy? It seemingly continues to grow a bit here and there as we take snapshots of various. HP doesn’t know what’s wrong either. When we upgrade from Command View 9.0 to 9.1, it did not fix the issue either. The big problem here is that we have to figure out how much space is actually used since we’ll never get alerted. It is a pain. I can turn to Replication Solutions Manager to obtain the correct size by simply adding all the luns (easy way to view them, as opposed to Command View), so that’s the workaround. Not very satisfying if you consider how much money was spent on these beasts.

About Mike Mills

Mail | More Posts (20)

Launched from the shortcut on the Windows host, or is accessible via a web browser at https://servername:2372

You are presented with the login screen:

It is here that you will also see the version number (down below). We have not yet upgraded this server to version 9.2 as we are building a VM to run Command View from and retire this physical box.

After login, you are greeted by the overview page. Here you will see all the EVAs listed, as well as the stats for your overall environment. The first thing of note is that two of my EVAs have bang lights on them, indicating something is amiss. I’ll investigate both as part of my next posting.

On the top right, there are some hyperlinks, your login id, and the ip of the Command View server. Most are self explanatory. Server Options provides for a place to enter license codes, setup RSM relationships, and a few other features. I seldom visit this page, so like once a year?

Moving right along, let’s take a look at a healthy EVA, in this case DS-SAN-2:

As you can see from the above, a healthy EVA has a number of folders beneath it. It breaks out into many subfolders. On the right hand side are the numbers. It would be here that you can get the logs for HP support (I’ll cover that in a separate blog post). You can see the current capacity level, view the Version level (this is the XCS code release running on the EVA. 6220 is the latest for the 8100 series). The left column is broken down like such:

Virtual Disks – this is where the luns (vdisks in EVA-speak) are listed. The folder structure is entirely man-made. That is to say, it’s for human organizational purposes (and plays an important role for setting up RSM jobs. More on that will be covered on a separate posting).

Hosts – here is where hosts are setup in Command View. You will provide the host’s OS, and it’s WWN’s for fiber cards. Hosts MUST be setup on every single EVA that you want to present disks from. Annoying, I know.

Disk Groups – these are comprised of physical disks. Best practice says to build these in multiples of 8, and of all the same speed and size. You can choose to not follow these and your performance will suck majorly. I’ve worked on rebuilding two of the 4 EVAs that had improperly constructed Disk Groups. It is PAINFUL to correct, but I’m glad I did. I will cover that also as a separate blog post. FYI: The ungrouped disks folder is for disks that have failed or been ungrouped on purpose. Ungrouping takes time as the EVA moves data from the drive to free it up to be removed or replaced.

Data Replication – it is here that you can create DR groups. This allows you to replicate (synchronous or asynchronously) between EVA arrays. A replication group is comprised of 1 or more vdisks. Sounding like a broken record, I will have a separate posting on replication.

Hardware – it is here that you can check out the status of the hardware. Both controllers are listed, as are all the disks. If there are hardware issues (per a bang light) then you can come here to find out why. The status of failed items is usually fairly straightforward and understandable as to what happened and what should be done.

About Mike Mills

Mail | More Posts (20)