I would like to hear your opinions about virtualization and physical resources
On aix we can create micropartitions with virtual ethernet and scsi resources. We can move partitions on line with partition mobility (here all have to be virtual).
But hear I have a comment. Best practices say that production environment has to be physical, disk, ethernet and with another server exactly like the first one in case the first one fails.
Then I think maybe one option could be that partitions production line be physical and maybe test partitions or maybe develop partitions line could be virtual.
What do you think ?????
What could be the good and bad things about virtualization against physical.
Sometimes we do micropartitioning in our production and failover environments, sometimes the partitions are on seperate hosts.
It's really my preference to have relating DB/App severs on the same host. This way we can create virtual network devices and any app-DB communication can be done via the backplane rather than over the physical network. The real setback for using this strategy is cost. It generally will cost less to buy 2 systems with half the memory than 1 with double the memory. This is slightly less of a problem with Power 6 as IBM has added additional RAM slots per module.
When we get into the VIO type of virtualization, we keep that to our development and QA environments. If we put that into production I'd spend half of every week on conference calls determining who is slowing who else down, or proving that it isn't happening.
Most of the times the IT experts have no say at all in the layout of the environment. Decisions are usually made by beaming sales people showing colourful brochures to ignorant managers while telling them everything is possible. (Which might be even correct for sufficient values of "everything".) I have seen horribly undersized machines choking on applications they were in no way fit to run and i have seen really big irons run applications for which a pocket calculator would have had enough computing power. Usually this is blamed on the IT for good measure and after firing half of the SA staff the manager having decided the issue is promoted for "being cost-effective".
Enough of the lament and back to topic: First off, there is no general rule without exception: every system has to be evaluated in its own right and sometimes this may lead to a wide variation of possible conclusions. So take any advice here cum grano salis. It is offered as a rule of thumb and even if most times fitting your system might as well be different.
Having said this: i would usually not use dynamic LPARs or virtual I/O in a production environment, because it adds a layer of complexity to the system. Reducing in layers of complexity usually enhance stability. Having a VIO-server and a system depending on it means there are also two machines instead of one which could fail to interrupt service. It also means there are two machines which might have to undergo service which also means interruption of the service.
Furthermore, a VIO-server clusters risks: if it serves several machines and it fails then all these machines are affected. If you use dedicated disks and one fails only one system will be affected.
For testing/Q&A/etc. VIO-servers and DLPARs are great: they can easily be recreated (which is a great asset in testing), they can easily be moved around, etc., which adds flexibility to the distribution of computing resources. You can easily shift memory, CPU cycles, etc. around to meet the requirements.
For development i think it is usually better to have a stable environment, quite like production. If you can get the developers to do the testing stuff on the before-mentioned test environments (in this case you should guarantee real quick response times for setting up their specified testing environments, ideally some Click-to-create-test-machine mechanism) you can hold the development environment very stable and can afford to be very conservative about it.
I agree with bakunin on the premis that clever salemen sell non-technical managers some TIN which is unsuitable for the job. However I cannot totally agree with the statement that all cases of production SHOULD NOT be through VIO served LPAR configuration. I have worked for a number of clients where the large grunt machines running very large Oracle databases were by necessity standalone LPARs with their own resources (network disk etc.) However for the low order LPARs these were configured in a dual VIO server configuration with auto failover of all services (network SSA disk etc.) As long as the network and disk connections are proven and stable then the performance of this configuration were more than adequate.