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.
Thanks,
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.
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.
Thanks
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.
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.
bakunin