Rolling Reload of NonStop Kernel Processors

Rolling Reload of NonStop Kernel Processors 2/18/04
Hewlett-Packard Development Company L.P. 5 of 7 CSSI Website
4 Rolling reload implementation
Before starting the rolling reload, complete the procedures described in Sections 2 and 3.
Verify the fault-tolerance of the system, paying particular attention to the ServerNet
Fabrics and processor-to-ServerNet addressable controller (SAC) relationships.
To implement a rolling reload, perform the pre-checks in Section 4.1, halt and reload
each processor one at a time using the procedures in Sections 4.2-4.4, and perform the
checks described in Section 4.5 after all processors are reloaded. The processors should
be halted and reloaded in the order selected in Section 2.2, Choose the processor reload
sequence.
If a processor upgrade is the reason for the rolling reload, use the guided processor
replacement procedure instead of Sections 4.2-4.4, but be sure to verify that there are no
new OSM/TSM alarms before each halt and before each reload. If necessary, the
application checks described in Sections 4.2-4.4 should still be performed.
4.1 Pre-checks before halting the first processor
• Verify that SCF STATUS SERVERNET $ZSNET shows no problems.
• Verify that SCF STATUS SAC $ZZLAN.*, DETAIL shows no problems.
• Verify that all SLSA SACs are in the STARTED state, not STARTING.
Check the access from both fabrics and all processors configured for each SAC.
• Verify that there are no new OSM/TSM alarms.
• Perform similar checks for applications and other subsystems such as
ServerNet/FX and Telco-specific SACs.
4.2 Halt a processor
Use the OSM/TSM Low Level Link (LLL) or Service Connection to halt the processor.
In general, do not perform a hard reset unless you require a very low-level re-
initialization.
• Wait a minimum of one minute before proceeding with the next step.
• Verify that processor utilization (measured by ViewSys or other up system
management application) stabilizes.
• Verify that the event flood triggered by halting a processor has receded by
checking events in the two event logs ($0 and $ZLOG) using the “real-time”
setting.
Caution: Some subsystems might continue to generate events indicating
that they have no backup, and these events should be ignored until after
the reload.
• Verify that SCF STATUS SERVERNET $ZSNET shows no problems.
• Verify that SCF STATUS SAC $ZZLAN.*,DETAIL shows no problems
• Verify that all SLSA SACs are in the STARTED state, not STARTING.
Check the access from both fabrics and all processors configured for each SAC.
• Verify that there are no new OSM/TSM alarms (other than the expected halted
processor indication).