On Jan 28, 2011, at 3:24 PM, Gary Gatling wrote: > I am in charge of several afs servers in our college. Right now there are 5 > afs servers running on 5 SPARC based servers. We are ditching Solaris since > it sucks so bad and are going to move to Linux VM's running inside of VMware. > > I was asked how much disk and memory we would need for the VMs. I was then > critized for suggesting that each VM needs 4GB just like the real servers. I > did not suggest the 4GB in each server. That was decided by a guy who quit a > few years ago. > > So.... > > Is there some rule of thumb for how one calculates the amout of RAM a AFS > file server should have. The 5 servers serve out about 2 TB of data. So each > fileserver has like about 500 GB of afs volumes on. Also how to go about > calculating will be good when the justifications for RAM are asked? > > Thanks for any ideas anyone will have.
YMMV, depending on the activity level of your users, volume and file sizes, etc, etc. For our system, 4GB is barely acceptable once load ramps up. We run 8GB, and as of right now a typical memory footprint is: afs-a-52-root# more /proc/meminfo MemTotal: 8236068 kB MemFree: 39188 kB Buffers: 547196 kB Cached: 7218020 kB SwapCached: 748 kB Active: 2031164 kB Inactive: 5900212 kB Active(anon): 145508 kB Inactive(anon): 20752 kB Active(file): 1885656 kB Inactive(file): 5879460 kB . . . But it's lunchtime. Things will ramp up this afternoon. I also strongly second the comments made about VM vs large quantities of IOPs. We're debating virtualization of servers here (umich) and the jury is still out. Thomas Kula has more to say on that topic in his note, but in general I have strong doubts about any file server that runs in anything except a one-server-per-phyisical-host model. I can envision a few benefits to having a vhost running AFS on top of virtualized storage; for example, one could migrate an AFS server to a different physical host and then do physical maintenance on the vacated box. On the other hand, in a non-virutal env one could also vos move the volumes to another unit and take it down for physical maintenance. The latter has the side benefit of letting you occasionally reboot the server and afs service. Of course, if you update your afs binaries more than say, once a year, you've gotta be restarting afs anyway. Most of our machines haven't been updated since June 8, 2010, and I'm getting antsy. But that's another topic. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
