Is it still recommended to deploy IGL on a physical, rather then virtual, environment?
This recommendation comes down to dedicated resources for performance. A database is intensive when it comes to cpu and I/O. A physical environment is going to ensure that happens. You can definitely do a virtual environment too but you really need to be aware of this and ensure resources arent swapping out from the database. You can lock resources even in virtual environments to ensure this doesnt happen but you need to consciously do this. If you dont, you are going to be competing with other things for those resources.
the tricky part in my experience is that the platform folks give the appserver/database guys resources. CPU, RAM, storage. And they apply their own rules. Overcommitting RAM, virtualizing storage (sometimes stacking virtualization several levels deep) and doing so without informing the resources running on top of the virtualization. At the beginning of the project all is dedicated and then later on, when resources become an issue, the "tuning" starts. It all just adds another step and hassle when debugging performance problems.
Sometimes however it is not a problem, mainly when the virtualization team is on top of things and understands their (internal) customers' needs.
As Sean and Frank both indicate, the decision to go to Physical or Virtual is highly related to the anticipated load and required performance.
The RSA IGL application knows multiple components:
- Web Application
- Worker Application
- Workflow Engine
- Provisioning (AFX)
- Collection (AveksaAgent)
In my experience the RSA IGL component utilization is as followed::
- Database is SMP-CPU/Memory/Disk IO intense
- Worker Application/Workflow Engine/Provisioning is CPU/Memory intense
(*SMP: Symmetric multiprocessing, e.g. effectively using multiple CPU's/Cores)
Virtualization is equal to sharing resources, when your application is requiring high performance the impact of shared resources will manifest in any shape or form. In my experience, all components but the database can cope with virtualization reasonably well.
However I've never seen a high performing environment function correctly when the database server is not installed on dedicated hardware and/or the database is hosted on a virtual database setup which is highly optimized for database loads. Typical database related performance issues you can experience is lengthy unification runs, slow workflow processing, slow reporting. .
Retrieving data ...