|
Jim,
I've finished the checklist for the 177 SSD to 775 SSD, including load
source.
Raid 5 parity will never be stopped in this scenario, so should be safer
then my older plan which included stopping or Raid.
I'm looking at a 2 hour down window, in addition to save window, maybe
less, all depends on option 9. Copy disk unit data
2 Power downs.
Identify current load source
SST, 1. Start a service tool, 7. Hardware service manager, 2. Logical
hardware resources (buses, IOPs, controllers,...) 1. System bus resources
9=Resources associated with IOP beside IOP with *,
Disk Unit * 58B4-109 Operational DMP001
Load source is resource DMP01
SST 2. Work with disk configuration, 1. Display disk configuration, 5.
Display device parity status
Print this screen,
Confirm Load Source is DMP001, unit 1, parity set 2
Display Device Parity Status
Parity Resource Hot Spare
Set ASP Unit Type Model Name Status Protection
1 57B5 001 DC11 RAID 5 N
1 15 58B4 109 DMP029 Active
1 14 58B4 109 DMP027 Active
1 16 58B4 109 DMP031 Active
1 12 58B4 109 DMP023 Active
1 11 58B4 109 DMP019 Active
1 18 58B4 109 DMP033 Active
1 10 58B4 109 DMP021 Active
1 13 58B4 109 DMP025 Active
1 17 58B4 109 DMP035 Active
2 57B5 001 DC11 RAID 5 N
1 1 58B4 109 DMP001 Active
1 4 58B4 109 DMP007 Active
1 2 58B4 109 DMP003 Active
1 3 58B4 109 DMP005 Active
1 6 58B4 109 DMP009 Active
1 8 58B4 109 DMP017 Active
1 7 58B4 109 DMP013 Active
1 9 58B4 109 DMP015 Active
1 5 58B4 109 DMP011 Active
GO SAVE 21.
SST 1. Start a service tool, 7. Hardware service manager 8. Device
Concurrent Maintenance 2=Install device
Attach six new 775 Gb SSD drives in the EXP24 drawer, units 19 thru 24
SST 3. Start device parity protection - RAID 5 six new 775 Gb drives,
record time.
SST 2. Add units to ASPs record time - six new 775, record time
STRASPBAL TYPE(*ENDALC) UNIT(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18)
on 18 of the 177 Gb drives, (This will stop any new data from going to
units 1-18)
CHKASPBAL
STRASPBAL TYPE(*MOVDTA) TIMLMT(*NOMAX) PRIORITY(*MEDIUM) on the 18 177 Gb
drives that are *ENDALC.(This will move data from Unit 1-18 current 177 to
Units 19 thru 24 new 775., record time
12. Work with removing units from configuration, units 2 thru 18.
Logical remove at SST of 17 *ENDALC / *MOVDTA drives,
so that their data goes to the five new 775 Gb drives.
If necessary, we can run the logical remove at DST on a
manual IPL. The option to remove at SST is available.
Power down the partition, restart *NO
Physically remove 9 177 Gb non-cfg drives from non-load source parity set
1, units 10 thru 18
Physically add seven new 775 Gb SSD drives in the EXP24 drawer, units 10
thru 16
From HMC, manual IPL to DST
I'm not sure if this IPL will force us to do something with the disks
added. Hope we can defer this till IPL completed.
Please confirm this, very important.
2. Work with disk unit recovery 9. Copy disk unit data
From the original load source, unit 1, to the one remaining non-cfg 775
Gb drive, unit 24., record time
Power down, physically remove the 9 177 Gb non-cfg drives, units 1 thru 9
including old load source.
Tag the new load source, if on a different IOA.
B IPL on the new load source
I'm not sure if this IPL will force us to do something with the final
disks added. Hope we can defer this till IPL completed.
Please confirm this, very important.
SST 8. Work with device parity protection 5. Start device parity
protection - RAID 5 with hot spare, record time
six new 775 Gb drives, record time.
SST 3. Work with disk units 2. Work with disk configuration 2. Add units
to ASPs, record time
STRASPBAL TYPE(*CAPACITY) TIMLMT(*NOMAX) PRIORITY(*MEDIUM) , record time.
1. Capacity balancing - The data on all the units within the ASP
will be balanced so each unit has an equal percentage of used
and unused space. This is useful when new units are added to
an ASP. Instead of having several units with the majority of
the data and several new ones with no data, the user can
spread the data evenly across all the units.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Jim Oberholtzer
Sent: Wednesday, January 07, 2015 12:59 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Removing disk units that have device parity protection from a
disk pool without mirrored protection
Paul,
At V7Rx that hasn't been true for some time. It might have been
introduced in a TR but that would have been very early, certainly by TR3.
I'm not in a position to find a document now but I've done it as recently
as last week.
The physical removal is a bit more complex since you have to follow the
remove FRU procedure, but still very doable.
I have a test system I could remove a drive from live if you want to do a
GoToMeeting to watch the procedure.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Wednesday, January 07, 2015 11:23 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Removing disk units that have device parity protection from a
disk pool without mirrored protection
Jim,
Can you point me to the doc or link for this process.
The current V7R1 doc that I listed below still states that you must IPL to
DST to remove a drive or drives.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Jim Oberholtzer
Sent: Wednesday, January 07, 2015 11:27 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Removing disk units that have device parity protection from a
disk pool without mirrored protection
Paul,
If you are at V7R1 you don't need to power down to remove the drives from
the configuration. You can do it while the system is running. As to
physically removing them, if you are taking the entire RAID set anyway,
don't bother with stopping it. Let whoever gets those drives on the used
market deal with it. They have to anyway to prepare them for resale.
Remember there's no data on them at this point. You could use the SST
function to physically remove them while the system is running if downtime
is a scarce commodity.
Also, unless you have very heavy I/O most of the time, don't be afraid to
end allocation and then drain the drives during the day. The process runs
in the background and is very rarely disruptive.
Otherwise your procedure looks good to me.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Wednesday, January 07, 2015 9:59 AM
To: 'Midrange Systems Technical Discussion'
Subject: Removing disk units that have device parity protection from a
disk pool without mirrored protection
I'm looking for the latest doc - Removing disk units that have device
parity protection from a disk pool without mirrored protection From the IBM
Knowledge Center, IBM i: Systems management Disk management, I found this
table/checklist.
I want to confirm that this is current, and this process STILL cannot be
done concurrently (Requires IPL to DST) My additional notes below is to
minimize the down window (4 - Remove unit from configuration) after IPL to
DST.
Task What to do Where to learn more
1.___ Display your current disk configuration. "Evaluating the current
configuration" on page 6 2.___ Calculate the space requirements for the
disk pools that are involved in disk removal.
"Calculating disk space requirements" on page 8 3.___ Use option 21 from
the Save menu to save your entire system.
Save your system with the GO SAVE command 4.___ Restart your system and
select the option to use dedicated service tools (DST).
"How to Start Dedicated Service Tools (DST)" in Backup and Recovery. From
the taskpad in System i Navigator, select OpenSystem i Navigator Service
Tools.
5.___ Remove disk units that you plan to remove from the system.
"Removing a disk unit from a disk pool" on page
101
6.___ Exclude the disk units from device parity protection. If you were
successful in excluding the disk units, skip to task 8. Otherwise, continue
to task 7.
"Excluding disk units from a parity set" on page
25
7.___ Stop device parity protection for all the disk units in the
Input/Output Processor (IOP).
"Stopping device parity protection" on page 24 8.___ Physically remove
disk units. If you stopped device parity protection in task 7, continue
with task 9. If you did not stop device parity protection, skip to task 10.
"Removing a disk unit from a disk pool" on page
101
9.___ Start device parity protection again. "Starting device parity
protection" on page 22 10.___ Verify that your disk unit configuration is
correct. "Evaluating the current configuration" on page 6 11.___ Print your
disk configuration to have available in case a recovery situation occurs.
"Printing your disk configuration" on page 7 12.___ Restart your system.
Disk removal
Removing disks require shutting down system, steps 1 thru 3 can be done
ahead to minimize down time, steps 4 on require down time. (Checklist 9 -
Backup and Recovery)
1) STRASPBAL TYPE(*ENDALC) UNIT(10 11 12 13 14 15 16 17 18) - This marks
the disks for those you want to remove
2) CHKASPBAL
Unit 10 is selected for end allocation.
Unit 11 is selected for end allocation.
Unit 12 is selected for end allocation.
Unit 13 is selected for end allocation.
Unit 14 is selected for end allocation.
Unit 15 is selected for end allocation.
Unit 16 is selected for end allocation.
Unit 17 is selected for end allocation.
Unit 18 is selected for end allocation.
3) STRASPBAL TYPE(*MOVDTA) TIMLMT(*NOMAX) - This will run for 3 to 6 hours
- suggest running at night.
4) PWRDWNSYS with restart (*NO) 5 - minutes
5) IPL using manual mode to DST 5 - minutes
6) Signon to DST
7) Logically remove from the ASP -
option 4 - (work with disk units)
option 1 - (work with disk configuration) option 3 - (work with ASP
configuration)
4 - Remove unit from configuration - If step 3 above already moved
majority of data, time should be minimal, 10 minutes for all disks.
8) Stop device parity protection for IOA - 3 minutes
9) Power down system
10) From HMC, power off frame that includes the disks
11) Physically remove disks from the system
Thank You
_____
Paul Steinmetz
IBM i Systems Administrator
Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071
610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home
psteinmetz@xxxxxxxxxx
http://www.pencor.com/
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
