Automation of AIX LPARs reboot

Login or Register to Reply

Thread Tools Search this Thread
# 1  
Automation of AIX LPARs reboot

Hello Everyone,

Can you please help me with the following questions regarding recycling LPARs.

1) Is it recommended to automate the reboot of AIX LPARs with a script ?
i mean we've few App LPARs and Database LPARs. we would like to bring down LPARs on last sunday of every month for about 1 hour and bring up after 1 hour automatically.

2) If it is recommended, please give your views or ideas on how to achieve this.

# 2  
The very first question that comes to my mind is why you want to reboot the system everymonth?
In real world, System admin have to wait for months to reboot a box (unless it is NOT production).

You can write a script to bring down LPAR's from HMC CLI,
You can write a script on NIM server (you can use any server) and direct it on HMC, and same you can do to bring the LPAR's up.

But, remember that the server from which you are running the script is not down, if its down it won't bring up the LPARs.

Now coming to the point of doing that, I have personally never did that, or saw people doing it.
Reasons could be many. If there are handful of LPARs then do it manually.
# 3  

thanks for your quick response. Even i never heard about automatic reboot of AIX LPARs.
but we had some kind of request/proposal to automate the maintenance/IPL every 3 months to free up the cache/buffer. so that it will improve performance.

i used to bring down/up LPARs manually by co-coordinating with other folks (middleware/app/Database engineers) in all my previous projects.
we've only a few servers and AIX is new in our environment. If we automate this process, it doesn't need many people work during off hours.......we are not 24/7 business yet.

Please give me some clue regarding script from HMC CLI end, in case if you have something on top of your head.

# 4  
Basic thumb rule, be there for these kind of activities.
in order to achieve that, you need to determine which server you will use as a launching pad for those commands? (I had used NIM a couple of years ago, but for an entirely different purpose).

Once you sort out which server you will use (say NIM server using your own userID), now you have to do exchange the ssh keys between NIM server and HMC (anyone HMC is fine).
Say for example on NIM you want to use your userID to connect to hscroot at HMC, you need to generate a ssh-key pair for your user ID on NIM. (It's a little tricky to set up SSH keys on HMC, search it you will find a procedure from IBM).
Test the connection from you NIM server.

I am not writing the entire script, but giving you the exact commands to stop and start the LPAR.
to stop a LPAR run,
ssh <username>@hmcX "chsysstate -r lpar -m <Manage System Name> -n <LPAR Name> -o shutdown"

Where, username is user on HMC (could be hscroot, you etc..,). Remember to enclose the actual command in quotation ("), same with start command.
If you don't do a ssh-key exchange it will ask for user password on HMC (it is not always required that you have hscroot access, some shops go by individual names and don't disclose hscroot password). This will nullify your automation.

Say you have 2 or 3 systems, I recommend you add 'sleep' of atleast for 3-4 minutes between each shutdown.

To start the LPAR run this
ssh <username>@hmcX "chsysstate -r lpar -m <Manage System Name> -n <LPAR Name> -f <LPAR_profile> -o on"

Here we add the LPAR_profile, because you need to know which profile it has to boot from (generally it will be LPARname_default) but make sure you use the correct profile.

You can write a simple script or a complex script to achieve the above and tune it to death, upto you.

Note: I don't recommend you using the automation process, imagine while adding a cronjob you miss'up with month to week or day or worst minute and it goes down every three minutes.

Also, the worst case scenario, because of some weird reason, the system isn't going down smoothly.

Many factors to ponder upon, and if you use it, use at your sole discretion.
# 5  
Originally Posted by System Admin 77
but we had some kind of request/proposal to automate the maintenance/IPL every 3 months to free up the cache/buffer. so that it will improve performance.
If this is about OS buffers/cache it is absolute nonsense. In fact it will not improve but hurt performance. Whatever is in the OS' buffers (the biggest of them being the file cache) is there because it is needed often. The system "learns" which data is needed more often and which is needed only rarely. Rebooting destroys this (meta-)information and the learning process starts from point zero.

I have a suspicion about how this came: someone noticed that after rebooting the system the "fre" counter in vmstat is higher than in a long-running system. So there must be more free memory, right? No! When a system starts up it loads all the programs and then (i presume the system being well tuned) some memory is left over, which would be dedicated mainly to the disk cache. But as the system doesn't know what to cache it simply makes no sense to fill up this memory with anything. This is why "fre" is so high: the memory is not "free", but "unused". Once the system starts to process data, it dedicates the unused memory to caching these. Things oftenly needed will stay in the cache while things needed only once will get thrown out eventually, as other data are loaded. This way, as a "usage pattern" develops, the cache becomes more and more effective, because it holds the things most oftenly needed. This is what i meant with "the system learning" above. A reboot destroys this and starts this "learning" process anew.

By the way: it is really easy to make the "fre" memory counter go up: (mis-)tune the maxperm and minperm to really idiotic values so that the filecache is very small even if there is lots of memory available. Performance wil suffer greatly, but the "fre" counter will go up.

By and large a reboot is only needed for one purpose in a Unix system: to load a new kernel image! If you didn't change anything on your kernel you DO NOT HAVE TO REBOOT! Sometimes a reboot is used by sysadmins to bring the system back into a defined state ("reboot .... is good", as a proverbial bad rhyme goes). Whatever might have run on the system, now it is either gone or we can watch it as it develops. But to "reboot to improve performance" is absolute nonsense, in fact it will rather hurt performance.

I hope this helps.

Login or Register to Reply

Thread Tools Search this Thread
Search this Thread:
Advanced Search

More UNIX and Linux Forum Topics You Might Find Helpful
Changing VLAN on AIX lpars in the same subnet
Hi Guys, Our lpars is currently running on 2 different vlans (20, 30). Now we have a requirement that vlan 30 needs to be change to vlan 31 at the same subnet. I'm not sure on what is the best approach for this or what change is involve on the AIX side. This is our setup. Network switch -...... AIX
Is it must to enable TCB on AIX LPARs ?
System Admin 77
Hi, I've verified my AIX 7.1 LPAR , and TCB is disabled by default. #odmget -q attribute=TCB_STATE PdAt PdAt: uniquetype = "" attribute = "TCB_STATE" deflt = "tcb_disabled" values = "" width = "" type = "" generic = "" ...... AIX
Creating LPARS in AIX
Hi, I have a p520 with 2 cpus and 10gb of ram.Is it sufficient enough to create 2 lpars.What other things we have to check.... AIX
Finding Root cause of AIX server reboot itself
Hi, please explain that how to find the rootcause of aix servers reboot itself. Which log or commands should be used to analyse the reboot incident? Please explain in detail.... AIX
Is fsck executed during reboot for AIX?
Dear Gurus, I would like to know if fsck is executed automatically during reboot for AIX? Is there any logs which I can refer to? or any documentation reference for this? Thank You.... AIX