Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Session
Bob Foster
Senior Technical Staff Member
and
Turgut Genc 2018 IBM Systems
Senior IT Consultant Technical University
IBM – Power Systems Lab Services October 2018
Rome
Session Objectives
• Outline the Process for migrating your current environment to a Power 9
environment
▪ OS and Application Compatibility
▪ Power9 performance and sizing your workloads
▪ Using new features on Power9
▪ Building new servers
▪ Migrating workloads to new servers
• This website can analyze your desired HMC, VIOS, Server, Server Firmware,
OS levels for your P9 and suggest the appropriate levels you should use for all
these components.
5
IBM FLRT webpage for Hiper APARs
https://www-304.ibm.com/webapp/set2/flrt/doc?page=hiper
6
IBM FLRT webpage for Security and HIPER script
https://www14.software.ibm.com/webapp/set2/flrt/sas?page=flrtvc
7
Application Compatibility
• Contact your Software vendors for compatibility with Power9 and SMT8
– Each customer has their set of applications that they will need to
discuss compatibility with their software vendor.
• General rules
• Energy Scale
• Example of rPerf sizing
• Right-sizing Experiment results and conclusions
• SMT levels play no role with IBM i as CPW always exploits the
maximum number of threads
10
EnergyScale Overview
For example, Maximum Performance mode will allow the system to reach the
maximum frequency under more conditions, thus providing maximum
performance (the maximum frequency is approximately 20% better than
nominal).
• Enable LPM
• Enable SRR
• Using SR-IOV
• Power Enterprise Pools
• Use AIX MPIO and NPIV
Movement to a
different server
with no loss of
service
Virtualized
VirtualizedSAN
SANand
andNetwork
NetworkInfrastructure
Infrastructure
15 © Copyright IBM Corporation 2018
Simplified Remote Restart (SRR) Overview
Power Enterprise Pools (PEP) provides the ability to move processor and memory
resources from one server to another any time, with no physical movement of
hardware, using easy operator commands in HMC.
Customers are using this for workload balancing, LPM, firmware maintenance, and
DR sites.
AIX MPIO
• Many customers no longer use vendor multipathing software in their VIOS partitions
and in their client partitions.
• The default AIX MPIO that is part of VIOS/AIX is being used instead of products like
PowerPath.
• Customers say upgrades of the VIOS/AIX is much simpler with the AIX MPIO vs. a
vendor product.
• When PowerVM first released in 2005, VSCSI was the only technology for disk
virtualization. Early adopters used this.
• NPIV support was released in 2008. Even though NPIV was easier to manage than
VSCSI, along with other benefits, the conversion process was non-trivial.
• There is a tool from lab-services that automates this.
The second session listed below uses features of the IBM PowerVM
Advanced Provisioning toolkit which is used by over 300 customers
worldwide to build VIOS and partitions.
The first session is a follow-on tool that originated from the provisioning
toolkit
A little terminology:
• Disadvantages
▪ Lpar requires downtime when migrating to new server
MES Upgrades - Definition
•What is a MES Upgrade:
•Wikipedia states:
• MES is an acronym used by IBM which stands for Miscellaneous
Equipment Specification. Any server hardware change, which can be an
addition, improvement, removal, or any combination of these. The serial
number of the server does not change. (in some cases)
• Specific types include the following:
▪ Customer-installable feature (CIF) miscellaneous equipment specification
(MES) Install-by-IBM(R) (IBI) MES
▪ Return-Parts MES (RPMES) is a special MES that is an IBI MES and
requires the return of selected parts to IBM on completion of the MES.
▪ [1] Since the MES process involves replacing large parts such as CPU or
feature cards, or even the entire server itself, but without a system serial
number change, it is sometimes referred to as a Machine Equipment
Swap.
MES Upgrade – General Procedure
• This procedure is a “general procedure” for MES’d servers (i.e. P8
to P9)
• Presteps:
− Gather Server properties – you will need these to set them on your P9
− Collect HMC Serial numbers
− Backup HMC Config
− Backup VIOS and Clients configs
− Remove CD/DVD from any managed system. (important to be done before
viosbr)
− Run VIOSBR on each VIOS
− Run Invscsout (perfect time to update the microcode of the devices if need be)
on your new P9 server
− Collect Source CEC serial numbers matching to target CEC serial numbers
(you need these for the viosbr restore).
• CE Installs Hardware
32
MES Upgrade – General Procedure
• Post Steps
• Change the VIO profiles to remove the old CEC devices (the old VIOS profiles will be on the
MES’d server)
• Add the New CEC Devices to the VIOS profile
• Boot the VIO’s, you may have to boot into SMS and choose boot device
• Remove defined devices created by the removal of the CEC and any available devices that
occurred after the Defined Devices so that they will be renumbered
▪ Ex: SAS drives, FC adapters, Network adapters
fcs0 Defined PCIe2 2-Port 16Gb FC Adapter (df1000e21410f103)
fcs1 Defined PCIe2 2-Port 16Gb FC Adapter (df1000e21410f103)
fcs2 Defined PCIe2 2-Port 16Gb FC Adapter (df1000e21410f103)
fcs3 Defined PCIe2 2-Port 16Gb FC Adapter (df1000e21410f103)
fcs4 Available PCIe2 2-Port 16Gb FC Adapter (df1000e21410f103)
fcs5 Available PCIe2 2-Port 16Gb FC Adapter (df1000e21410f103)
fcs6 Available PCIe2 2-Port 16Gb FC Adapter (df1000e21410f103)
fcs7 Available PCIe2 2-Port 16Gb FC Adapter (df1000e21410f103)
33
MES Upgrade – General Procedure
• Post Steps (cont’d)
▪ Run cfgdev
▪ Edit the VIOSBR.xml file and change the Bus id and the CEC Serial
<name>ent0</name> <state>AVAILABLE</state>
<locCode>U78C0.001.DBJF101-P2-C2-T1</locCode>
<unique_type>adapter/pciex/e41457162004000</unique_type>
<locCode>U78C0.001.DBJF101-P2-C2-T2</locCode>
<unique_type>adapter/pciex/e41457162004000</unique_type>
<type>FCP</type> <CuAtcount>3</CuAtcount> <CuAt
name="jumbo_frames" value="yes" action="TRUE" /> <CuAt
name="busmem" value="0xffc70000" action="FALSE" /> <CuAt
name="busintr" value="259585" action="FALSE" />
• :%s/search_string/replacement_string/g
34
MES Upgrade – General Procedure
• Post Steps (cont’d)
− Now that you have edited and fixed the VIOSBR.xml file you can restore it with
Restore VIOSBR
− Boot clients - you may have to boot into SMS and choose boot device
35
“Swing Disks”
•“Swing” Disks is virtually moving the disks to another LPAR.
“Swing”Disks
▪ Description:
− Pre-work before the outage
Verify all of the pre-requisites exist. (Very
important)
Create the new LPAR profile either VSCSI or NPIV
Collect the WWPN’s
Create vscsi or vfc mappings on new P9 VIOS
Zone the disks to the new frame
− Outage:
Shutdown the Source LPAR
Boot the Target System
− Post outage Order will change
based on vscsi or vfc
Clean up old LPAR and VIO mappings
“Swing” Disks – Prerequisites
• Pre-reqs.
▪ Both the CECs are connected to the same the network or subnet.
▪ The slot numbers of the virtual ethernet and virtual SCSI client adapters for the
AIX client partition (on the partition profile) must match on both CECs. The virtual
SCSI client and virtual SCSI server adapter mappings have to be the same on
both CECs.
▪ Virtual I/O server versions on the two CECs have to be the same.
▪ Running all software on Virtual I/O servers at the same levels, for instance,
SDDPCM or Powerpath. All the disks that are visible on the AIX client partition
have to be virtual disks (exported from VIOS using virtual SCSI).
“Swing” Disks- Prerequisites (cont’d)
▪ All the disks that are exported to the AIX client partition from VIOS have to be
SAN disks
▪ The attribute reserve_policy for all the SAN disks on VIOS should be set to
no_reserve for VSCSI. If 'no_reserve' is not set, then VIOS on the original CEC
should be shut down before the switch over is done.
▪ On the Virtual I/O server, a Shared Ethernet Adapter or VNIC has to be created
so that layer-2 bridging is available for the virtual ethernet assigned to the AIX
client partition. Ensure VLAN configuration is done appropriately for VIOS
partitions on both the CECs.
▪ Both Source Server and Target Server must see the same SAN fabric
Mksysb Restore
• Mksysb restore is the “granddaddy” of restoring rootvg. This is
the most trusted and most utilized process for restoring rootvg.
▪ Restore mksysb for rootvg and restore the other VG’s with savevg.
− This can be used if your rootvg isn’t on SAN, and your datavg is not on SAN and you have don’t have
a backup solution. (Can require a great deal of space for the savevg)
▪ Restore mksysb for rootvg and restore the LVM skeleton with savevg, then restore the data with a
backup solution such as TSM.
− This is used if your rootvg isn’t on SAN and your datavg’s are not on SAN. You can create a savevg
without the data so once your rootvg is restore, you can create the filesystem structure for the datavg’s
with the savevg. You would first restore your rootvg , then restore your savevg, then do a TSM restore.
Alt_disk_copy
▪ The -B option tells alt_disk_copy not to change the bootlist to this new copy of
rootvg, the -O option will remove devices from your customized ODM database.
− From the alt_disk_copy man page:-O Performs a device reset on the target
altinst_rootvg. This causes the alternate disk install to not retain any user-defined device
configurations. This flag is useful if the target disk or disks become the rootvg of a
different system (such as in the case of logical partitioning or system disk swap).
• Then that mksysb image is restored to unused disks in the current system
using alt_disk_mksysb, again using the -O option to perform a device reset.
• After this the disks could be removed and placed in a new system, or via
fibre rezoned to a new system, and the rootvg booted up.
Why unsupported methods don’t work
• The reason for this is there are many objects in an AIX system that are
unique to it; Hardware location codes, World-Wide Port Names,
partition identifiers, and Vital Product Data (VPD) to name a few.
• Most of these objects or identifiers are stored in the ODM and used by
AIX commands. If a disk containing the AIX rootvg in one system is
copied bit-for-bit (or removed), then inserted in another system, the
firmware in the second system will describe an entirely different device
tree than the AIX ODM expects to find, because it is operating on
different hardware.
• Devices that were previously seen will show missing or removed, and
usually the system will typically fail to boot with LED 554 (unknown boot
disk).
• Supported methods link:
▪ http://www-01.ibm.com/support/docview.wss?uid=isg3T1012273
43
•Software Upgrades – you may need to update
your OS before moving to P9
44
AIX Upgrade Options
• AIX Live Update
• Alt_disk_copy
• Update/Upgrade Current Version
• Mksysb Migration
• Multibos
• Nim Alt disk Migration
45
AIX Live Update
46
AIX Upgrade Options
Alt_disk_copy:
▪ Make a copy of the rootvg and update or upgrade the
alt_disk_copy. Then do a alt_disk_install to the copy of
rootvg:
− Alt_disk_copy
− Alt_disk_install
− Or smitty alt_disk_install
− Change bootlist when ready to boot to new level
− Reboot
▪ Benefits
− Can boot back and forth between the two rootvg’s. During testing if issues with
the new OS level arise, you can quickly reboot back to the previous working
version.
− Uptime while migrating, only an outage during the reboot.
47
AIX Upgrade Options
• Update/Upgrade current version (In place)
▪ This is the original update or upgrade path. Updating/upgrading the current
rootvg. An outage is needed for an update/ or upgrade.
▪ CONS:
− In order to backout from a failed upgrade, a mksysb restore will need to take
place.
− A longer outage needs to occur.
− Updates can be difficult to back out.
• Mksysb Migration
▪ This type of migration is used when you are trying to go to a new type of server
and aren’t at the correct OS level to get there. This is not intended for an update
from one tech level to another, but a full migration from AIX 6.1 to AIX 7.1
▪ Examples of Use: AIX 5.3 needing to move to Power 8 where the min is AIX
6.1tl8.
▪ More information on this can be found in the Redbook NIM from A to Z in AIX 5L
Chapter 4.5 Nim mksysb migration and nim_move_up Power5 tools.
48
AIX Upgrade Options
• Nim Alt Disk Migration
▪ The nimadm utility offers several advantages over a conventional migration. For
example, a system administrator can use nimadm to create a copy of a NIM
client's rootvg (on a spare disk on the client, similar to a standard alternate disk
install alt_disk_install) and migrate the disk to a newer version or release of AIX.
All of this can be done without disruption to the client (there is no outage required
to perform the migration). After the migration is finished, the only downtime
required will be a scheduled reboot of the system.
▪ Another advantage is that the actual migration process occurs on the NIM master,
taking the load off the client LPAR. This reduces the processing overhead on the
LPAR and minimizes the performance impact to the running applications.
49
Lab-Services Assistance Available for migrations
• Lab-Services has been helping customers with migrations starting back
in 2010. Over the last few years, we have designed engagements for
customer to better plan for these migrations along with multiple tools
that can be used to help build the new Power servers and size the
workloads and move the workloads. These tools make the migration
process easier and faster.
▪ For the overall planning, ask for the Power 9 Migration Planning Workshop
▪ For sizing of workloads, ask for the Capacity Planning Tool
▪ For building new VIOS/infrastructure, ask for the Lab-services IBM Advanced
PowerVM Provisioning Toolkit
▪ For moving from VSCSI to NPIV, ask for the VSCSI to NPIV Tool
▪ For LPMing workloads, ask for the PowerVM LPM/SRR Automation Tool
(ibm.biz/lpm_srr_tool)
N
EW
Power to Cloud Linux
§ IBM Cloud Design Workshop § Linux Installation and Optimization
§ PowerVC Enablement
§ VMware vRealize Integration Security
§ Automation for DevOps Enablement § Security Assessment
§ Power Enterprise Pools Enablement § PowerSC Enablement
§ PowerVM Provisioning and Mobility Automation § AIX Role Based Access Control Workshop
§ Database as a Service § BigFix Patch Management
§ Power Systems
§ Storage and Software Defined Infrastructure
§ IBM Z and LinuxONE
§ Systems Consulting
§ Migration Factory
§ Technical Training and Events
ibmsls@us.ibm.com
www.ibm.com/it-infrastructure/services/lab-services
54
Thank you!
Bob Foster
Senior Technical Staff Member
bobf@us.ibm.com
Turgut Genc
STG Lab Services Consultant - Power Systems
TurgutGenc@uk.ibm.com
• U.S. Government Users Restricted Rights — use, duplication • customers have used IBM products and the results they may
or disclosure restricted by GSA ADP Schedule Contract with have achieved. Actual performance, cost, savings or other
IBM. results in other operating environments may vary.
• Information in these presentations (including information relating to • References in this document to IBM products, programs, or
products that have not yet been announced by IBM) has been services does not imply that IBM intends to make such
reviewed for accuracy as of the date of initial publication and could products, programs or services available in all countries in
include unintentional technical or typographical errors. IBM shall which IBM operates or does business.
have no responsibility to update this information. This document • Workshops, sessions and associated materials may have been
is distributed “as is” without any warranty, either express or prepared by independent session speakers, and do not
implied. In no event, shall IBM be liable for any damage arising necessarily reflect the views of IBM. All materials and
from the use of this information, including but not limited to, discussions are provided for informational purposes only, and
loss of data, business interruption, loss of profit or loss of are neither intended to, nor shall constitute legal or other
opportunity. IBM products and services are warranted per the guidance or advice to any individual participant or their specific
terms and conditions of the agreements under which they are situation.
provided.
• It is the customer’s responsibility to insure its own compliance
• IBM products are manufactured from new parts or new and used with legal requirements and to obtain advice of competent legal
parts. counsel as to the identification and interpretation of any
In some cases, a product may not be new and may have been relevant laws and regulatory requirements that may affect the
previously installed. Regardless, our warranty terms apply.” customer’s business and any actions the customer may need
• Any statements regarding IBM's future direction, intent or to take to comply with such laws. IBM does not provide legal
product plans are subject to change or withdrawal without advice or represent or warrant that its services or products will
notice. ensure that the customer follows any law.