HP Integrity BL870c Server-Blade - Manual (Page 23)

a known good blade. Note that the highly preferred solution for a faulted blade is to replace it
with a known good blade.
Placing a faulted blade into its own partition is a method of isolating a fault. For a multi-blade
partition experiencing a fault, isolating the fault will cause a reduction in the number of resources
in the partition. If it is required to maintain a multi-blade partition, and a spare known good blade
is not on hand, the Administrator can consider doing the physical blade swap.
For this case, the System administrator physically swaps blade resources across partitions or within
partition. The objective is to replace a faulted blade with a known good blade. In the event that
a blade fault occurs within the Blade Link domain which requires replacement, and no replacement
blades are readily available, it is suggested that the faulted blade be moved to the farthest right
location (highest numbered bay) in the Blade Link Domain. Further, the faulted blade can be
isolated, using the guidance in Chapter 9 of this document.
If the administrator chooses to swap two blades within the Blade Link Domain, the following
recommendations are suggested if possible:
1. Isolate the known good blade into its own partition, for example, D (highest numbered blade
in the domain).
2. The known good blade should have all old unwanted data removed, e.g. de-configuration
settings or logs.
3. If possible, back up all configuration information for the faulted blade in the domain, which
will be swapped with the known good blade; if this has not already be done. See Chapter 6
for more details.
4. Power down the Blade Link Domain.
5. Carefully remove the Blade Link using the procedures specified in the Service Users Guide.
6. Swap the known good and faulted blades.
7. Carefully re-attach the Blade Link
8. Check that all blades are detected by iLO, using the nPar TUI. Please refer to Chapter 9 for
blade isolation examples.
9. If necessary, use the nPar cmd to isolate the faulted blade, if not done already. Note, it is
always a good policy to force a faulted blade into its own electrically isolated partition, so
that it can't have an impact on other blades within the Blade Link Domain.
10. Restore and or re-configure the know good blade if it has assumed the role of a monarch
elsewhere in the Domain.
Best practices
If a blade swap is performed, check to make sure that correct processor, memory, and I/O loading
rules are followed for the blades.
Replace the faulted blade at your earliest opportunity with a known fully operative blade.
Case H: Scale up via a field upgrade.
This case describes physically growing the size of the Blade Link Domain.
Upon attach of the upgrade Blade Link, the system Administrator will observe that:
•
Existing blades have been moved to the default partition A, e.g. AB -> AA. Note, this is a
unique and special behavior; i.e., state is preserved for later reuse on the Auxiliary blades.
This is not a re-assign process.
•
Newly added physical blades are assigned as part of the default partition; e.g. AB + 2 new
blades -> AAAA, as the final state.
If and when the Blade Link Domain is partitioned to provide the original partitions; e.g., AB, A
will retain its monarch settings. B will need to have its System EFI variable settings restored at EFI,
if this is desired. The newly added blades will need to be configured, if moved into their own
partition(s).
Case H: Scale up via a field upgrade. 23