Experience with FIM 2010 on VMWare vSphere 4
Dear experts,
we are in the process of upgrading from MIIS 2003 to FIM 2010. As the new software requires a 64 bit architecture, we need new hardware. Following MS recommendations (given in the capacity planning guide), we are aiming for a scenario with two boxes. One
box for FIM Portal, FIM Services and FIM Service Database and another one for FIM Synchronisation and FIM Synchronisation DB.
Now our hosting partner would like to know whether we can use VMWare machines instead of physical boxes. I checked on MS website (http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpwizard.htm)
and found out that the proposed virtualization software (VMWare vSphere 4) is supported.
Now I would like to know whether anyone of you had already have the chance to run FIM 2010 under VMWare vSphere 4 and what experience he made with this. Are there any unforeseen pitfalls that
we should be aware of?
We are still a bit unsure whether we really need 4 x 4 Quadcore CPUs for the box that runs the FIM Sync services (recommended by MS in capacity planning guide). We will use Intel CPUs
~3 GHz Hexacores on the physical level. This means we would have to assign 16 cores to the VMWare image for FIM Sync Services. From our gut feeling this seems to be a bit too much.
We have about 4 data sources from where we pull data (120.000 user objects, 25 attributes per user). These data are merged based on unique idenitifier. Later these user objects are assigned
to user groups based on their attributes (about 10 groups, 2 bigger groups with up to 50.000 user objects).
Any advice on the use of VMWare in such a scenario or on the general sizing is very much appreciated.
Best regards,
Martin
September 23rd, 2011 12:14pm
Unfortunately, what I've read in Microsoft's documentation basically indicates there are too many variables with FIM (especially with the addition of the portal) to accurately predict broadly how much hardware is required.
My environment isn't that different from yours, although I'm going to be managing more groups (still planning to break up the larger groups into subgroups no larger than 5,000 based on previous Microsoft best-practice and a bad experience I had early with
ILM and groups over ~25k). I'm starting my development work on 2 64-bit PCs just to get an idea of how much drive space will be required and where all the processing seems to be. I don't have a lot of workflows and special things in the portal
yet, but so far all of the capacity-gobbling seems to be with the SQL databases that support both halves of FIM. When I took a FIM training class the instructor indicated to me that I should look for a hit on the CPU for the FIM Service, and maybe with
more workflows and such I may start to see that.
My thought at this point for my environment is to go physical on the SQL Server(s) (adding a node or two to our SQL Server 2008 cluster) and perhaps virtualize the FIM Service/Portal and the FIM Sync Service that interact with them. That way if portal
activity grows to the point where users are waiting too long for pages to load while the sync engine is exporting, we can spin up another VM and install the portal/service on it just for the end-users and have point it to the same database.
The overriding question is how patient are you with how long it takes things to process, and how much are users going to have to wait for the portal to respond. If you expect a lot of traffic to the portal (like if you were to implement the self-service
password reset portion), you'd probably want to look at having multiple portal/service servers running. It doesn't sound like there would be a lot of traffic there just to manage 10 or so groups, but you know your environment better than anyone.
Free Windows Admin Tool Kit Click here and download it now
September 23rd, 2011 5:11pm
I'll second some of Chris' comments - especially around SQL server.
Her's an example that might help.
I had two environments with the same FIM config, both using the same offboard SQL server (physical box)
The first setup was with a fairly low end VM server (4gb / single core) running sync service and portal
The second setup was with a much beafier physical box (32gb /12 core) running the same software and configs
The second setup was faster, but only by about 10-15% (not at all what we hoped for..) and neither was close to being limited in CPU or memory.
We came back later after the DBA team made various performance tuning adjustments and we retested both hardware configs and we noted almost a doubling of sync and portal export performance for both servers
The takeaway here is that database performance = FIM performance, and if you're going to invest time in tuning, start with SQL.
Hope that helps..
Frank C. Drewes III - Consultant: Certified Security Solutions - My blog: http://www.css-security.com/author/fdrewes
September 25th, 2011 7:58am
Dear Chris,
thank you very much for your detailed answer. As you said it depends pretty much on the scenario that we are planning to implement. In fact we do not want to use the FIM portal for self-services. We only would need it for the definition of automatic
user group assignments. Therefore, I am fine with the setup of a small server for that part.
One more thing how do you break up larger groups. One of our biggest group is automatically assigne to users based on the value of one user attribute. In a nutshell, if the user attribute is empty, user is not assigned. In case the attribute contains a non-null
value, the group is assigned. How would I split up that group in a proper way? I thouhgt about the following approach. As the attribute in question is a number I could assign all users with a number below 10.000 to the first group and all users with a number
between 10.000 and 20.000 to the next group and so on and so forth. How did you split your groups?
Best regards,
Martin
Free Windows Admin Tool Kit Click here and download it now
October 6th, 2011 4:22am
Hi Frank,
thank you very much for your answer. It helped me a lot to understand where to look for performance optimisation. I'll keep that in mind when talking to our DB team next time. Any general advice in tuning the SQL server for FIM? As I am no DB expert myself,
I appreaciate any advice on that.
Best regards,
Martin
October 6th, 2011 4:23am
Note that what I have in production is with ILM, and I am probably going to mimic the behavior with FIM. Exports to AD are always deltas, but whenever ILM imports from AD it imports the entire member list of a changed group (which is why I do not
archive the import log files). I have not yet done any tests to see if FIM retains that full-attribute import behavior on a delta import. If it were able to import only group membership changes, the size of the group would be of much less concern
as long as AD was happy.
I'll be away from my test environment for several days, but I'll try to check on the FIM behavior next week if no one else posts a response about the delta imports. I didn't even think to question that until we started talking about this topic.
I have two large student groups, for current and former students, and I subdivide each of those groups by first initial (technically, the first letter of the email address). The groups are not equal in size, but the solution seems to work for us.
I built the solution over a year ago using some
custom SQL tables and stored procedures called outside of ILM, and I plan to replace this with rules in the FIM portal when we upgrade. The largest groups (A, C, and J, typically) stay under 5k except in the overlap periods when current student groups contain
both students for a future semester and some for a semester that is just ending. Since the groups were created in AD when at 2003 functional level, the 5k limit is not really a hard limit but still a good recommendation. If the groups had been
migrated from our late NT domain, replication of group changes would involve the entire member list rather than just the changes in members and having a large list might cause replication delays or worse.
Several months ago I toyed with the idea of using the last two digits of a unique key value from our ERP system to break them into 100 groups instead of 26 as that would be more random and uniform. (Using the last digit would not have made them
small enough to make changing the design worth the bother.) What I found, though, is that in the course of the day as ILM is cycling and importing changes from our ERP system, each group that was changed would have fewer members but more groups would
be updated in each sync cycle and the processing time was about the same. It certainly wasn't worth having about four times the number of groups, though at least with the SQL solution it was easy to create and populate them all.
Back to your original question, in our environment I believe there is a reluctance to host SQL on virtual servers, but I cannot say if that is because of fear, experience, best practices, a recognition of the fact that by the time you assign enough resources
to SQL to make it perform well, you've gobbled up most of the host, or because our virtual infrastructure isn't what you would call "mature". But if you are hosting SQL on actual hardware separate from FIM, the CPU/RAM resources needed for the FIM services
become much less demanding.
I wish I had actual virtualization experience to share, but hopefully what Frank and I have provided will help you.
Chris
Free Windows Admin Tool Kit Click here and download it now
October 6th, 2011 9:20am
Hi Chris,
thanks, for sharing your experience and ideas regarding management of larger groups. It definitely helped me to go on.
Best regards,
Martin
October 11th, 2011 3:51am