External Power Controllers: Qualifying Nodes and Other Best Practices
Intended for use with Cassatt Active Response Standard Edition, Premium Edition and Data Center Edition V5.1.
For application nodes to use external power controllers, you must ensure that nodes have the required power behaviors. This article describes:
- How to qualify application nodes for use with external power controllers
- Supported external power controller configurations
- Best practices
- Configuration tips
Qualifying application nodes for use with external power controllers
For Cassatt Active Response to power manage nodes plugged into external power controllers, the nodes must have power behaviors on the application node such as "Wake on LAN" and "node boots when power is restored." Therefore, it is critical that you qualify these behaviors on all application nodes that will be plugged into external power controllers.
You also need to assess your goals for active power management in Cassatt Active Response. For example, if you are using Cassatt Active Response in a development/test environment, you may have older and more diverse equipment that may not have one of the recommended power behaviors (or the behaviors are simply non-functional). In a development/test environment, this might be acceptable if you can tolerate occasionally powering on nodes when they do not boot. On the other hand, if you are implementing Cassatt Active Response in a production environment, you may have more stringent requirements and goals for node power management. In either case, you must validate the power functionality on each application node you're going to use with external power controllers—so you understand how the node behaves under Cassatt Active Response power management.
top
Recommended power behaviors and settings
This following table describes node power behaviors/settings that work with Cassatt Active Response active power management, which ones do not, and important considerations.
Cassatt has observed that 1) not all nodes have BIOS settings for power behaviors—sometimes the behavior is just how the node works and is not configurable 2) some settings just don't work, even after you've configured them properly. That's why it's critical to validate application node power behaviors before deciding if a node can be used with external power controllers.
Node behavior or BIOS setting |
Description |
Recommended? |
Suited For...
|
| Wake on LAN |
Wake on LAN is an Ethernet networking computer standard that allows a machine that has been shut down to be booted remotely.
Also called: Remote Wake Up |
Yes |
Production and non-production environments |
Node boots when power is restored
|
If a node has this behavior, when power is taken away from the node, and then power is restored, the node boots, regardless of its previous state. Unfortunately, the name for this behavior/setting is not consistent across application nodes; similarly, although you may find this setting under Power Management in the BIOS, that's not always the case.
Also called: AC Power Recovery |
Yes |
Production and non-production environments |
Node returns to last power state |
This is the default behavior for many nodes. In this case, the node remembers its previous state. If the node is off when the power is removed, the node remains off and doesn't boot when the power is restored. However, if the node is on at the time the power is removed, and then power is restored, the node boots. This can appear to be random power behavior if you are not aware of this possibility.
This power behavior may be acceptable, but both of the following are required to make it work:
- You must be willing to tolerate inconsistent node power states, and be willing to manually manage those nodes when they don't automatically power on. (This is not recommended in a production environment because it depends on the node always remaining on in the event power is cut at the external power controller outlet.)
- The OS on the node must not have the ability to power off the node after it is shut down; if the OS powers down the node after shutdown, there is nothing Cassatt Active Response can do to monitor and counteract the OS behavior.
|
Yes,
but with caveats |
Non-production environments only
|
| Node does not boot when power is restored |
This is another common default behavior for many nodes. In this case, if the power is taken away from the node, and then power is restored, the node does not boot, regardless of its previous state. Cassatt Active Response can never power on the node without manual intervention. Although not recommended, there may be particular nodes for which manual power intervention is acceptable. You just need to make sure the behavior is known to whoever is managing the node so time is not wasted on troubleshooting. |
No |
Non-production environments only |
Nodes with IPv6 addresses must either:
- Support Wake on LAN and be on the same VLAN as the Cassatt Active Response control node.
OR
- Support power up on AC restoration.
top
Follow these steps to verify the power behavior/settings for all application nodes that you wish to use with external power controllers; this avoids unpredictable behavior during operation.
- If available, enable the Wake on LAN or "Boot when power is restored" setting.
- Test that the setting is functioning using the table below.
- If the setting is not functional, or there isn't a setting, use the table below to determine the node's power behavior.
Node behavior or BIOS Setting |
How to verify behavior or BIOS setting... |
| Wake on LAN (WOL) or "Remote Wake Up" |
- Power off the node.
- From the control node, execute the following command:
ccwol -m <mac_of_the_node> -b <broadcast_address_of_subnet_NIC_is_on>
NOTE: If the control node on which you are running the ccwol command is on the same subnet as the NIC you are trying to wake up, skip the -b parameter; ccwol will use the local 255.255.255.255 broadcast address.
The ccwol command sends a WOL packet at one-second intervals for 30 seconds. If the node is properly configured and the setting is functional, the node boots.
|
Node boots when power is restored or "AC Power Recovery"
|
- Power off the node.
- Unplug the node.
- Plug the node into an outlet with power.
If properly configured and the setting is functional, the node boots.
|
| Node returns to last power state |
- Power off the node.
- Unplug the node.
- Plug the node into an outlet with power.
The node should remain off.
- Power on the node.
- Unplug the node.
- Plug the node into an outlet with power.
The node boots.
|
| Node does not boot when power is restored |
- Power on the node.
- Unplug the node.
- Plug the node into an outlet with power.
The node does not boot.
|
Supported external power controller configurations
The following table lists configurations and limitations when using external power controllers.
Question |
Answer |
Can external power controllers have any number of outlets? |
Yes |
Can external power controllers be partially-owned by Cassatt Active Response?
Cassatt Active Response requires that external power controllers be totally owned by Cassatt Active Response. This avoids issues of configuration changes that could be made that would conflict with Cassatt Active Response. For example, necessary privileges might be removed from the userid used by Cassatt Active Response. |
No |
Can I connect one external power controller into the outlet of another external power controller (daisy-chaining)? |
No |
Can I connect a node with an enabled integrated power controller with multiple power supplies to an external power controller?
|
No |
| Is there a limit to the number of different external power controllers/outlets I can plug into a single node? |
No |
Can I use a external power controller on Cassatt Active Response control nodes? |
No |
top
Best practices
The following table describes best practices when using external power controllers.
Best practice |
Description |
| Plan ahead if power controllers need firmware upgrades |
Upgrading firmware on some external
power controllers is not as simple as getting a download from a vendor site. Some
vendors introduce significant delays by requiring you to contact their
support organization to get an update. |
Balance out nodes across multiple power controllers |
It is best not to put a high percentage of nodes on a single external power controller. For example, if you had an external power controller with 24 outlets, and you configured your domain with 24 nodes on that single external power controller and it fails, tiers would go critical with no chance of recovery. |
Know who else may be using the power controller |
If you are re commissioning an existing external power controller for use by Cassatt Active Response, make sure you know if it is being used; you don't want to overwrite an existing user authentication. |
Make sure physical hardware settings match UI settings |
It is imperative that the settings you configure on the external power controllers and nodes (for example, IP address, authentication, network), match what you enter in the Cassatt Active Response Controller—or the power controller may not be discovered. Also, make sure the IP address for the external power controller matches the IP address of the network you are specifying. |
top
Configuration tips
The following table lists things you should know when configuring external power controllers.
What you should know |
Description |
Changes to configuration settings do not always happen immediately |
Cassatt has observed delays when changing configuration settings in some external power controller interfaces. Although the interfaces display that changes were successful, updates may not go into effect immediately. In one case, changing an authentication phrase took 3 minutes to go into effect. If you are certain you have correctly set up an authentication phrase, and Cassatt Active Response is not discovering the external power controller, you may need to verify that the updates were successful. |
Valid characters for authentication phrases are not standard |
The valid number of characters for authentication phrases varies from device to device. When you are creating authentication phrases, make sure you are not getting errors. If you do get an error, sometimes the errors are not intuitive; check and recheck the number of characters until you determine a valid string. |
top
Was this article useful? Tell us what you think.
Email infocentral@cassatt.com. |
