On Wed, Dec 23, 2009 at 2:01 PM, Ben Rockwood <benr at cuddletech.com> wrote: > Nicolas Williams wrote: >> On Wed, Dec 23, 2009 at 11:25:01AM -0800, Ben Rockwood wrote: >> >>> I'm very interested in finding someone who has experience deploying >>> LDAP in multiple sites for operating system IDM and how they handle >>> the home directory problem. ?I want to federate LDAP across multiple >>> global sites, but I'm nervous about a user logging into a system in >>> Europe who has a home directory in the Bay Area and the latency >>> associated. ?I suppose an option is to have separate homedirs in each >>> site, but that adds an additional step when >>> provisioning/deprovisioning users which isn't good. >>> >>> Is there anyone that can shed some light on the topic? ?There seems to >>> be very little information on doing AAA (LDAP, Kerberos, BSM, etc) >>> deployments for OS authentication on a large scale. >>> >> >> I'm not entirely sure what you mean by federate. ?I think you mean that >> you have a single namespace of users/groups but want to override some >> things locally, such as home directory locations. >> >> Assuming I understood correctly, you have some choices: >> >> ?- Setup distinct directories, one per-site, and keep them in synch via >> ? ?tools that you write and which provide for the override functionality >> ? ?that you want. >> >> ? ?This is clearly painful. >> >> ?- Use the automounter and/or NFSv4 referrals (recently added to >> ? ?OpenSolaris in /dev) and/or symlinks to add a level of indirection? >> >> ? ?I.e., make the override something that doesn't live in the directory, >> ? ?but in local NFS servers. >> >> ? ?For example, you could have user's homedirs be /home/<user> and then >> ? ?use auto_home to map that to a local homedir path in every site. ?Add >> ? ?in symlinks and/or NFSv4 referrals pointing to the user's true or >> ? ?local home, and you have a decent solution. >> > > > Maybe I should step back slightly. ?I'm particularly interested in > best-practice with regard to multi-site identity, auth, and > accounting. ? When I consider creating a configuration its fairly > straight forward to have a single replicated directory (LDAP) which has > a local presence in each site across the globe; but each user is going > to need a home directory for login.
What will people be doing with the home directories? That is, do they just need to have their .profile and maybe a handful of shell scripts? Or are they software developers that are checking out code and building it in their home directories? The type of environment I am most familiar with tends to have one site where people do latency sensitive work at one site and may need their home directories at various globally dispersed sites. I've found that around the globe mounts are not that big of a deal. Sure, it's a bit slower to log in (+ < 5 sec), but it is not enough to warrant a more complicated architecture. > Now, I can use several methods to override or redirect, such as you > point out. ?But what is the best practice way to handle this size > deployment? ?Home directories are one such problem, but there are plenty > of others. > > > This really starts to become an issue as you look toward IDM in cloud > deployments, where some of your servers are here and some there, perhaps > on different continents. ?I feel like I'm inventing an architecture for > the first time, but others have done this many times before. When I think about it in an IDM context, I would be looking at an HR record to see where a person's office is and provision the home directory based on that. I am not sure I see it as an IDM task to handle continuous optimization of this. In a cloud environment, I would think (without having actually managed a cloud environment but with managing a smallish HPC environment) that each workload deployed to the cloud would have a well-defined set of dependencies. Much like memory placement optimization, thread migration, etc. algorithms in an OS, it would make sense to locate the workload close to the storage. At such a time as there is not enough compute power to handle the workload (or other constraints, such as availability) are not being met, the workload should move to someplace that has more capacity. Presumably this means replicating or moving at least the active data set with the workload. This sounds like resource management, not identity management. Most likely the cloud isn't made up of interactive shell users. Interactive users are much less inclined to "put things where they belong". Where you do need to support interactive shell users, it would seem to make sense to isolate each to a site that will give them great performance. The workload that they distribute will presumably have well-defined data stores. As the data stores are defined, I would think that they would consist of a menu of characteristics. The menu is limited and you can't pick all. For example, "shared rw access", "globally distributed", and "less than 10 ms service time" don't go together. However, "replicated rw access" is compatible with global distribution and good service times. Without such rules in place and applications designed to play within such rules, I have a really hard time seeing how a cloud can use global distribution while providing predictable levels of performance. But I suspect that you've already figured this out or I am missing some fundamental information about how your environment works. -- Mike Gerdts http://mgerdts.blogspot.com/
