Deployment Solution

 View Only

Rule Based RAID In Depth - Part 2: Controller Matching Modes 

Aug 28, 2007 12:11 PM

In this article we will take a look at how rules, modes, and controllers play in the new Rule-based RAID feature of Deployment Solution for Dell Servers 3.0. Rule based RAID is a very powerful tool that simplifies the process of deploying servers. When properly understood it can be used to deploy many different server configurations in a very customized way.

Modes: How the Rules are Evaluated

In part 1 of this article I went over the process of creating RAID rules and creating controller definitions within those rules. If you haven't yet read part 1 I highly recommend you stop reading right now (well not really right now, cuz you have you read the rest of this sentence so I can tell you what I want you to read) and go read part 1.

Ok, so now that those people who haven't read part 1 yet are gone, we'll continue with the good stuff.

Controller Matching Modes in Depth

So now we've arrived at the moment you've been waiting for. I'm finally going to break down and explain how the modes work. The mode selected with a rule can have a significant impact on how and if a particular rule will be applied to a system.

Physical Mode in Depth

Physical mode is the more straightforward of the two modes. Basically the controller definitions represent the order in which the physical controllers must be arranged. This can get a little sticky, because how do you determine the order of the controllers? Is it the order they appear in the PCI bus? Is it the order they are enumerated by raidcfg (the DTK utility used to configure the RAID controllers) which, by the way, is different between WinPE and Linux. The way the order is determined is the controller ID number, from lowest to highest. Each controller has an ID (0, 1, 2, 3) assigned to it. The DTK utility raidcfg reports the ID number which, I must point out, isn't consecutive, so a particular system might have controllers with IDs of 0, 3, and 5. So while the physical ordering of the controllers may not be what you'd expect, they are at least consistent. A simple way to discover the controller ID numbers is to run the sample job "Get RAID Information File".

So now that we know how the order is determined we can continue. At run-time each rule is evaluated, from top to bottom. First the number of controller definitions in the rule is compared to the number of physical controllers in the system. If there are more controller definitions than physical controllers the rule is automatically eliminated and processing continues with the next rule. It's ok to have too many physical controllers, but not ok to have too many controller definitions because we can have that "catch all" rule to apply to any remaining controllers. I must also point out that the "catch all" definition itself is not included in a rule's controller definition count. Once this first test is past the controller definitions are compared to the physical controllers on a one-to-one basis. So the first controller definition will be compared to the first physical controller (the one with the lowest controller ID). The comparison process for controller definitions and physical controllers only compares the number of disks in the definition vs the number of physical disks attached to the controller. If they are the same (or if the "or more" checkbox was checked then the physical controller only has to have at least the number of disks defined in the definition) then the controller definition matches. If a match is found processing continues with the next controller definition and physical controller. If all the controller definitions match the physical controllers then the rule is applied. If there was a "catch all" controller definition then it is applied to any remaining physical controllers.

Priority Mode in Depth

Priority mode can be a bit more complicated because of the different options that are available. Basically, in priority mode the controller definitions represent a priority list. They are evaluated from left to right. The physical controllers are enumerated in numerical order by controller ID (see physical mode above for more info about controller IDs). If each physical controller on the system has a controller definition that matches it, then the entire rule matches. If even one physical controller on the system doesn't have a matching definition, then the entire rule is eliminated. This is when not checking the box to delete the current RAID configuration may be helpful. You may have a server you want to configure, but it has a controller you don't want touched. If you don't define a controller definition for the controller, the rule won't match.

By default each controller definition is used only once, except the "catch all" definition which will cover any physical controllers that didn't have a match. There is also the option to check the allow controller definitions to be used more than once box. This can open up a lot of subtleties, and some controller definitions may never be considered. For example, if you create two controller definitions, the first one with 3+ disks and the second with exactly three disks, and you specified that the definitions can be used more than once, then the second controller definition will never be used since and controller that has exactly three disks meets the requirements for the 3+ definition. It would, however, be effective to reorder them so controllers with exactly three disks are configured differently than controllers with three or more disks.

There's another subtly I haven't mentioned yet. I said earlier that it is possible to create the "catch all" definition for priority mode rules. If you defined several rules and one of them is a priority mode rule with a "catch all" in it, then rules following this priority rule will never be evaluated. This is because the "catch all" rule will apply to any and all controllers on the system not covered by the other definitions (even if none of them match) and thus the rule will be valid and will match.

I hope you can appreciate the power of the priority based rules. With enough careful planning it is possible to create a rule that will apply to any system, and configure them all in a different and unique way. You could potentially create 100 controller definitions in one rule and, as long as enough of the definitions cover the physical controllers, the rule is valid and will be applied.

Modes Compared

So if we return to the example we had in part 1, we can see how the mode would affect how the rule is applied. Remember we had three controllers: one with three or more disks, one with exactly two disks, and a third "catch all" definition. In physical mode a system would have to have three or more disks on its first physical controller, exactly two disks on its second physical controller, and then any number of other controllers, in order for the rule to be applied. In priority mode the system could have any number of controllers (would need at least one), with any number of disks on them, and the rule would be applied. If one of those controllers happened to have three or more disks, or exactly two disks, then the corresponding controller definition would be matched, otherwise the "catch all" definition would be applied.

Examples

Alright, perhaps it would be beneficial to go over a few examples. I'm not sure how good I am at cooking up some scenarios, but I'll do my best. If you can think of a good example I don't cover let me know and I can add it.

Example 1

Let's say we have a few different kinds of systems. We have one group of systems with one controller and two disks, another group with one controller and six disks, and a third group with two controllers, the first has two disks and the second is connected to a PowerVault with 14 disks. Of course we want a different configuration for each. We want the first group to have a RAID-1 virtual disk created on them. The second group we want the first two disks to be RAID-1, then the remaining four disks to be RAID-10. The final group we want the two disks on the first controller in RAID-1, and the 14 disks on the second controller in RAID-50. I'll explain how to do this in both modes.

Physical Mode

In physical mode I need three rules, one for each group. I need one rule with one controller that has exactly two disks, and I need it set to RAID-1. Then I need a second rule with one controller that has six disks. On this controller I define two disk groups, one with two disks set to RAID-1 and the other with four disks set to RAID-10. Then I need a final rule with two controllers, the first with two disks and the second with 14 disks. I set the two disks on the first controller to RAID-1 and the 14 disks on the second controller to RAID-50. The resulting rule list would look like this:

Figure 1

Click to view.

Priority Mode

In priority mode I need only one rule, and it will cover all the groups. I just need three controller definitions, one with two disks, another with six disks, and a third with 14 disks. The order doesn't matter, but I put them from lowest to highest. I set the controller with two disks to RAID-1, I create two disk groups on the controller with six disks, one with two disks in RAID-1, the other with four disks in RAID-10. Then I set the final controller with 14 disks to RAID-50. Here's the rule list:

Figure 2

Click to view.

Example 2

Ok, we'll do one more example, this one is a bit harder. We'll have three groups again. The first group has two controllers, one with 2 disks that we want in RAID-0, the second with 3 or more disks, we want three of the disks in RAID-5 and any others as hotspares. The second group we have three controllers, the first two controllers both have six disks, and we want them in RAID-50, and the third controller has ten disks, but it has important data on it and we don't want it touched. The final group is a collection of servers with a variable number of controllers and disks which we want configured dynamically.

Physical Mode

Once again, in physical mode I need three rules. I'll create two controllers, the first with two disks set to RAID-0, and the second with three or more disks, with three disks set to RAID-5 and the "or more" disk group set to hotspare. Next I'll make a rule with three controllers, the first two with six disks each, and all six disks in RAID-50, then the third controller with ten disks, but I won't configure it so it won't be touched. Then I'll make a final rule with just a "catch all" controller definition. I'll assign dynamic RAID to it. This one has to be last in the order so it will apply to any systems that the first two rules weren't valid for. Here's a screen shot of the resulting rules:

Figure 3

Click to view.

Priority Mode

I can do this in one rule in priority mode with the controller definitions being used more than once, but there are some cases where I may not get the behavior I want, I'll explain in a minute. I can make five controller definitions; the first has two disks set to RAID-0. The second controller definition has 6 disks, set to RAID-50, the third has ten disks with no configuration. Then I have a fourth controller definition with three or more disks, with three disks set to RAID-5 and the "or more" disk group set to hotspare. Then I have a final "catch all" definition set to dynamic. The rule list is below:

Figure 4

Click to view.

This can have undesired behavior however. I have the definition for 3+ disks, which comes after the six and ten disks definitions so those apply first. But what if I have a system with two controllers, the first with two disks, and the second with six disks? I want it to do RAID-0 on the first controller, and RAID-5 with three disks and then three hotspares on the second controller. But what I get is RAID-50 with all six disks. Also if this rule is applied to any systems from our third group, and they happen to have controllers that are valid for any of the first four rules, they won't have the dynamic RAID type applied to them and will be configured some other way (ex: controller with 12 disks matches the 3+ definition, so I'd get RAID-5 with three disks and nine disks as hotspares).

To fix this I need to mix the modes a bit. I don't have to have the same mode on all the rules I define. So if I make a rule with physical mode that is the same as the first rule in my physical mode example above, then create a priority mode rule with three definitions, one with six disks, the second with ten disks, and the third the "catch all" definition. The rule list is below:

Figure 5

Click to view.

I'm sure even this has some unexpected behavior. The point I'm trying to make is that a rule may not behave the way you initially think it will. Just make sure you run through the different possibilities as you create your rules.

Well that's all I have. I hope this article has been enlightening and has armed you with the knowledge you need to use the RAID rules feature. It can be a powerful tool in your arsenal to help you configure and deploy your servers quickly.

Statistics
0 Favorited
0 Views
1 Files
0 Shares
0 Downloads
Attachment(s)
zip file
Rule based RAID in depth part 2.zip   333 KB   1 version
Uploaded - Feb 25, 2020

Tags and Keywords

Comments

May 01, 2008 04:37 PM

I don't believe there is a pdf version, but with DS for Dell 3.1, they have improved the documentation for rule based RAID a lot, complete with examples and that is available in PDF format. Just go to Tools->Dell Help for the documentation.

Nov 14, 2007 12:15 AM

Love the article, is there a pdf version as i have been asked a few times by Dell people so that they can play with RAID rules in their Labs
a

Related Entries and Links

No Related Resource entered.