1 / 82

Advanced Administration And Problem Determination

Advanced Administration And Problem Determination. 2011 년 6 월 20 일 시스템 기술 지원팀. Advanced Administration And Problem Determination. 목차. 1. The Object Data Manager. 2. Error monitoring. 3. System initializing. 4. Disk management. 1. The Object Data Manager. 1. The Object Data Manager.

bond
Download Presentation

Advanced Administration And Problem Determination

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Advanced Administration And Problem Determination 2011년 6월 20일 시스템 기술 지원팀

  2. Advanced Administration AndProblem Determination 목차 1. The Object Data Manager 2. Error monitoring 3. System initializing 4. Disk management

  3. 1. The Object Data Manager

  4. 1. The Object Data Manager • What is the ODM? • The Object Data Manager (ODM) is a database • intended for storing system information. • Physical and logical device information is stored and • maintained through the use of object with associated • characteristics.

  5. 1. The Object Data Manager Data managed by the ODM Devices Software ODM SMIT menus System Resource controller TCP/IP configuration Error Log, Dump NIM

  6. 1. The Object Data Manager • System data managed by ODM • The ODM manages the following system data: • Device configuration data • Software Vital Product Data (SWVPD) • System Resource Controller (SRC) data • TCP/IP configuration data • Error log and dump information • NIM (Network Installation Manager) information • SMIT menus and commands

  7. 1. The Object Data Manager ODM database files PdDv - predefined device PdAt - predefined Attribute PdCn - predefined connection CuDv - Customized device CuAt - Customized Attribute CuVPD - Customized vital Product data CuDvDr -Customized Device Driver CuDep - Customized dependency Config_rules - 디바이스 잡는 순서

  8. 1. The Object Data Manager Device configuration summary Predefined database PdAt PdCn PdDv Configuration Manager (cfgmgr) Config_Rules Customized database CuDv CuAt CuDep CuDvDr CuVPD

  9. 1. The Object Data Manager Roles of cfgmgr and Config_Rules When an AIX system boots, the Configuration Manager (cfgmgr) is responsible for configuring devices. There is one ODM object class which the cfgmgr uses to determine the correct sequence when configuring devices: Config_Rules. This ODM object class also contains information about various methods files used for device management.

  10. 1. The Object Data Manager • Data not managed by ODM • Filesystem information : /etc/filesystems • User/security information : /etc/security/user • Queues and queue devices : /etc/qconfig

  11. 1. The Object Data Manager Changing attribute values #odmget –q”uniquetype=tape/scsi/scsd and attribute=block_size” PdAt > file #vi file PdAt : uniquetype = “tape/scsi/scsd” attribute = “block_size” deflt = “512” values = “0-2147483648,1” width = “ “ type = “R” #odmdelete –o PdAt –q”uniquetype=tape/scsi/scsd and attribute=block_size” #odmadd file Modify deflt to 512

  12. 1. The Object Data Manager Using odmchange to change attribute values #odmget –q”uniquetype=tape/scsi/scsd and attribute=block_size” PdAt > file #vi file PdAt : uniquetype = “tape/scsi/scsd” attribute = “block_size” deflt = “512” values = “0-2147483648,1” width = “ “ type = “R” #odmchange –o PdAt –q”uniquetype=tape/scsi/scsd and attribute=block_size” file Modify deflt to 512

  13. 1. The Object Data Manager Predefined devices (PdDv) PdDv : type = “scsd” class = “tape” subclass = “scsi” prefix = “rmt” … base = 0 detectable = 1 … led = 2418 setno = 54 msgno = 0 catalog = “devices.cat” … uniquetype = “tape/scsi/scsd”

  14. 1. The Object Data Manager Predefined devices (PdDv) base = This descriptor specifies whether a device is a base device or not. A base device is any device that forms part of a minimal base system. During system boot, a minimal base system is configured to permit access to the root volume group and hence to the root file system. detectable = This specifies whether the device instance is detectable of undetectable. A device whose presence and type can be determined by the cfgmgr, once it is actually powered on and attached to the system, is said to be detectable

  15. 1. The Object Data Manager Predefined attributes (PdAt) PdAt : uniquetype = “tape/scsi/scsd” attribute = “block_size” deflt = “ “ values = “0-2147483648,1” … PdAt : uniquetype = “disk/scsi/osdisk” attribute = “pvid” deflt = “none” values = “ “ … PdAt : uniquetype = “tty/rs232/tty” attribute = “term” deflt = “dumb” values = “ “ …

  16. 1. The Object Data Manager Predefined attributes (PdAt) attribute = This identifies the name of the attribute. This is the name that can be passed to the mkdev or chdev command. For example, to change the default name of dump to ibm3151 for tty0, you can issue the following command: # chdev –l tty0 –a term=ibm3151 values = This identifies the possible values that can be associated with the attribute name. For example, allowed values for the block_size attribute range from 0 to 2147483648, with an increment of 1

  17. 1. The Object Data Manager Customized devices (CuDv) CuDv : name = “ent1” status = 1 chgstatus = 2 ddins = “pci/goentdd” location = “02-08” parent = “pci2” connwhere = “8” PdDvLn = “adapter/pci/14106902” CuDv : name = “hdisk2” status = 1 chgstatus = 2 ddins = “scdisk” location = “01-08-01-8,0” parent = “scsi1” connwhere = “8,0” PdDvLn = “disk/scsi/scsd”

  18. 1. The Object Data Manager Customized devices (CuDv) Status This identifies the current status of the device instance. Possible values are : - status = 0 (Defined) - status = 1 (Available) - status = 2 (Stopped) Chgstatus This flag tells whether the device instance has been altered since the last system boot. The diagnostics facility uses this flag to validate system configuration. The flag can take these values : - chgstatus = 0 (New device) - chgstatus = 1 (Don’t care) - chgstatus = 2 (Same) - chgstatus = 3 (Device is missing)

  19. 1. The Object Data Manager Customized attributes (CuAt) CuAt : name = “ent1” attribute = “humbo_frames” value = “yes” … CuAt : name = “hdisk2” attribute = “pvid” value = “00c35ba0816eafe50000000000000000” …

  20. 2. Error monitoring

  21. 2. Error mornitoring #errpt

  22. 2. Error mornitoring #errpt -A

  23. 2. Error mornitoring A summary report Error types Valid error types include the following : - PEND – The loss of availability of a device or component is imminent. - PERF – The performance of the device or component has degraded to below an acceptable level. - TEMP – Recovered from condition after several attempts. - PERM – Unable to recover from error condition. Error types with this value are usually the most severe errors and imply that you have a hardware or software defect. Error types other than PERM usually do not indicate a defect, but they are recorded so that they can be analyzed by the diagnostic programs. - UNKN – Severity of the error cannot be determined. - INFO – The error type is used to record informational entries. Error Classes H (hardware), S (software), O (operator), U (Undetermined).

  24. 2. Error mornitoring The errpt command - Summary report : #errpt - Detailed report : #errpt –a -Summary report of all hardware errors : #errpt –d H -Detailed report of all software errors : #errpt –a –d S -Concurrent error logging(“Real-time” error logging) : #errpt –c > /dev/console

  25. 2. Error mornitoring Types of Disk Errors * error types : P=permanent T=temporary

  26. 2. Error mornitoring LVM Error Log Entries * error class : H=hardware Error Classes : H = hardware Error Types : P = permanent S= software T = Temporary

  27. 2. Error mornitoring Maintaining the error log #smit errdemon #smit errclear

  28. 2. Error mornitoring Self-made error notification #! /usr/bin/ksh errpt > /tmp/errlog.1 while true do sleep 60 errpt > /tmp/errlog.2 #compare the two files. #If no difference, let’s sleep again cmp –s /tmp/errlog.1 /tmp/errlog.2 && continue #files are different : Let’s inform the operator : print “Operator : check error log” > /dev/console errpt > /tmp/errlog.1 done

  29. 2. Error mornitoring syslogd configuration examples /etc/syslogd.conf : auth.debug /dev/console mail.debug /tmp/mail.debug daemon.debug /tmp/daemon.debug *.debug; mail.none @server All security messages to the system console collect all mail messages in /tmp/mail.debug collect all daemon messages in /tmp/daemon.debug Send all messages, except mail messages, to host server After changing /etc/syslog.conf : # refresh –s syslogd

  30. 2. Error mornitoring Redirecting syslog messages to error log /etc/syslogd.conf : *.debug errorlog Redirect all syslog messages to error log # errpt IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION ... C6ACA566 0505071399 U S syslog MESSAGE REDIRECTED FROM SYSLOG ...

  31. 3. System initialization

  32. 3. System initialization How does a System p server or LPAR boot? Possible failures Check and initialize the hardware POST. Hardware error. Locate boot image using the boot list. Unable to find any boot image. Load and pass control to boot image. Boot image corrupted. Start AIX software initialization.

  33. 3. System initialization Loading of a boot image hdisk0 • Firmware • boot deivces : • diskette • CD-Rom • Internal disk • Network Bootstrap code RAM Boot Logical Volume(hd5) Boot controller Bootstrap code : System p and pSeries systems can manage several different operation systems. The hardware is not bound to the software. The first block of the boot disk contains bootstrap code that is loaded into RAM during the boot process. This part is sometimes referred to as System Read Only Storage(ROS). The bootstrap code gets control. The task of this code is to locate the boot logical volume on the disk, and load the boot image. In some technical manuals, this second part is called the Software ROS.

  34. 3. System initialization Contents of the boot logical volume (hd5) AIX Kernel RAMFS Reduced ODM AIX Kernel : The AIX kernel is the core of the operating system and provides basic services like process, memory, and device management. The AIX kernel is always loaded from the boot logical volume. There is a copy of the AIX kernel in the hd4 file system (under the name /unix), but this program has no role in system initialization. Never remove /unix, because it is used for rebuilding the kernel in the boot logical volume. RAMFS : This RAMFS is a reduced or miniature root file system which is loaded into memory and used as if it were a disk-based file system. The contents of the RAMFS are slightly different depending on the type of system boot. Reduced ODM : The boot logical volume contains a reduced copy of the ODM. During the boot process, many devices are configured before hd4 is available. For these devices, the corresponding ODM files must be stored in the boot logical volume.

  35. 3. System initialization Unable to find boot image (Working with bootlists) Normal bootlist : # bootlist –m normal hdisk0 hdisk1 # bootlist –m normal –o hdisk0 blv=hd5 hdisk1 blv=hd5 Customization service bootlist : # bootlist –m service –o cd0 hdisk0 blv=hd5 ent0 Service bootlist – over network : # bootlist –m service ent0 gateway=192.168.1.1 \ bserver=192.168.1.3 client=192.168.1.57

  36. 3. System initialization Starting System Management Services (SMS mode) Reboot or power on the system Press F1 and enter the SMS mode Select Boot Options Configure Boot Device Order Select 1st Boot Device List All Devices

  37. 3. System initialization Accessing a system that will not boot Boot the system from the BOS CD-ROM, tape or network device(NIM) Select maintenance mode Maintenance 1. Access a Root Volume Group 2. Copy a System Dump to Media 3. Access Advanced Maintenance 4. Install from a System Backup Perform corrective actions Recover data

  38. 3. System initialization How to fix a corrupted BLV (Boot Logical Volume) Maintenance Mode Access a Root Volume Group # bosboot –ad /dev/hdisk0 # shutdown -Fr Rebuild BLV Maintenance mode If the boot logical volume is corrupted (for example, bad blocks on a disk might cause a corrupted BLV), the machine will not boot. To fix this situation, you must boot your machine in maintenance mode, from a CD or tape. If NIM has been set up for a machine, you can also boot the machine from a NIM master in maintenance mode. NIM is actually a common way to do special boots in a logical partition environment.

  39. 3. System initialization How to fix a corrupted BLV (Boot Logical Volume) • Recreating the boot logical volume • Boot your machine in maintenance mode (from CD or tape) to access the Systems • Management Services (SMS) to select the boot device. • 2. Remove the old hd5 logical volume. • # rmlv hd5 • 3. Clear the boot record at the beginning of the disk. • # chpv –c hdisk0 • 4. Create a new hd5 logical volume : one physical partition in size, it must be in rootvg • and outer edge as intrapolicy. Specify boot as the logical volume type. • # mklv –y hd5 –t boot –a e rootvg 1 • 5. Run the bosboot command as described on the visual. • # bosboot –ad /dev/hdisk0 • 6. Check the actual bootlist and reboot the system • # bootlist –m normal –o • # sync;sync;shutdown -Fr

  40. 3. System initialization System software initialization overview Load kernel and pass control / etc,dev,mnt,usr Restore RAM file system from boot image rc.boot 1 Start init process (from RAMFS) Configure base devices rc.boot 2 Active rootvg Configure remaining devices rc.boot 3 Start “real” init process (from rootvg) /etc/inittab

  41. 3. System initialization • Boot sequence • The visual shows the boot sequence after loading the AIX kernel from the boot image • The kernel restores a RAM file system into memory by using information provided in • the boot image. At this stage the rootvg is not available, so the kernel needs to work with commands provided in the RAM file system. You can consider this RAM file system as a small AIX operating system. • The kernel starts the init process which was provided in the RAM file system (not from the root file system). This init process executes a boot script rc.boot. • rc.boot controls the boot process. In the first phase (it is called by init with rc.boot 1), the base devices are configured. In the second phase (rc.boot 2), the rootvg is activated (or varied on). • After activating the rootvg at the end of rc.boot 2, the kernel overmounts the RAM file system with the file systems from rootvg. The init from the boot image is replaced by the init from the root file system, hd4. • 5. This init processes the /etc/inittab file. Out of this file, rc.boot is called a third time(rc.boot 3) and all remaining devices are configured.

  42. 3. System initialization rc.boot 1 rootvg is not active. Failure LED Process 1 init F05 c06 rc.boot 1 Boot image ODM restbase 548 510 RAM file syetem ODM cfgmgr –f Confie_Rules phase=1 Devices to activate rootvg are configured!! bootinfo -b 511

  43. 3. System initialization • rc.boot phase 1 actions • rc.boot phase 1 actions • The init process started from the RAM file system, executes the boot script rc.boot 1. If init fails for some reason(for example, a bad boot logical volume), c06 is shown on the LED display. The following steps are executed when rc.boot 1 is called: • The restbase command is called which copies the ODM from the boot image into the RAM file system. After this step, an ODM is available in the RAM file system. The LED shows 510 if restbase completes successfully, otherwise LED 548 is shown. • When the restbase has completed successfully, the configuration manager(cfgmgr) is run with the option –f (first). cfgmgr reads the Config_Rules class and executes all methods that stored under phase=1. Phase 1 configuration methods result in the configuration of base devices into the system, so that the rootvg can be activated in the next rc.boot phase.

  44. 3. System initialization • rc.boot phase 1 actions • 3. Base devices are all devices that are necessary to access the rootvg. If the rootvg is stored on hdisk0, all devices from the mother board to the disk itself must be configured in order to be able to access the rootvg. • At the end of rc.boot 1, the system determines the last boot device by calling bootinfo –b. The LED shows 511.

  45. 3. System initialization rc.boot 2 (part 1) Failure LED rc.boot2 551 rootvg c06 511 ipl_varyon 556 hd4: / hd2: /usr hd9var: /var hd6 517 555 fsck –f /dev/hd4 mount /dev/hd4 557 copycore: if dump, copy fsck –f /dev/hd2 mount /usr 518 dev etc mnt usr var fsck –f /dev/hd9var mount /var copycore umount /var 518 / RAM file system swapon /dev/hd6

  46. 3. System initialization • rc.boot phase 2 actions (part 1) • rc.boot is run for the second time and is passed the parameter 2. The LED shows 551. • The following steps take part in this boot phase : • The rootvg is varied on with a special version of the varyonvg command designed to handle rootvg. If ipl_varyon completes successfully, 517 is shown on the LED, otherwise 552,552 or 556 are shown and the boot process stops. • The root file system, hd4, is checked by fsck. The option –f means that the file system is checked only if it was not unmounted cleanly during the last shutdown. This improves the boot performance. If the check fails, LED 555 is shown. • Afterwards, /dev/hd4 is mounted directly onto the root in the RAM file system. If the mount fails, for example due to a corrupted JFS log, the LED 557 is shown and the boot process stops.

  47. 3. System initialization • rc.boot phase 2 actions (part 1) • 4. Next, /dev/hd2 is checked and mounted (again with option –f, it is checked only if the file system wasn’t unmounted cleanly). If the mount fails, LED 518 is displayed and the boot stops. • Next, the /var file system is checked and mounted. This is necessary at this stage, because the copycore command checks if a dump occurred. If a dump exits in a paging space device, it will be copied from the dump device, /dev/hd6, to the copy directory which is by default the directory /var/adm/ras. /var is unmounted afterwards. • The primary paging space /dev/hd6 is made available.

  48. 3. System initialization rc.boot 2 (part 2) swapon /dev/hd6 rootvg hd4: / hd2: /usr hd9var: /var hd6 Copy RAM /dev files to disk : mergydev Copy RAM ODM files to disk : cp /../etc/objrepos/Cu* /etc/objrepos dev etc ODM mount /var dev etc ODM mnt usr var Copy boot messages to alog / RAM file system Kernel removes RAMFS

  49. 3. System initialization • rc.boot phase 2 actions (part 2) • After the paging space /dev/hd6 has been made available, the following tasks are executed in rc.boot 2 : • To understand this steps, remember two things : • - /dev/hd4 is mounted onto root in the RAM file system. • - In rc.boot 1, the cfgmgr has been called and all base devices are configured. This configuration data has been written into the ODM of the RAM file system. • Now, mergedev is called and all /dev files from the RAM file system are copied to disk. • All customized ODM files from the RAM file system ODM are copied to disk as well. At this stage, both ODMs (in hd5 and hd4) are in sync now.

  50. 3. System initialization • rc.boot phase 2 actions (part 2) • 3. The /var/file system (hd9var) is mounted • 4. All messages during the boot process are copied into a special file. You must use the alog command to view this file : • # alog –t boot –o • As no console is available at this stage all boot information is collected in this file. • When rc.boot 2 is finished, the /, usr, and /var file system in rootvg are active. • Final stage • At this stage, the AIX kernel removes the RAM file system (returns the memory to the free memory pool) and starts the init process from the / file system in rootvg.

More Related