Re: [OpenAFS] Questions about OpenAFS reality
In message [EMAIL PROTECTED],Jan Johansson writes: All of the above have one common problem. When the disk run out you have big problem. Ladies and gentlemen can we please have your attention. Please stop working, close your files and hold you hands up while we move your data to a new disk. Thank you. I am sure that this can be solved with NAS, SAN or some other hype technique of the week. But with AFS this is not a problem, you move user data under the feet of the user and they will not even know it. That is pure power. to be fair, nfs never was intended to really solve this problem. nfs just exports your existing storage. solutions to this my disk is too small problem have been around a while. ibm's jfs and lv are a good example (and dates back to around 1991). you can simply add new physical storage to an existing logical volume and grow the filesystem to use this new space. since then quite a few others have added these features. veritas has been around a little longer, but it has always been an extra you had to buy. irix, solaris and linux all now have similar features to ibm's lvm/jfs. there are some limits with this though--typically a 16T barrier somewhere. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Questions about OpenAFS reality
You received many good answers and I would just like to add some small details. Leroy Tennison [EMAIL PROTECTED] wrote: How does AFS compare in administrative burden compared to the common PC NOSes (NetWare and AD)? It has been quite long since I saw NetWare but keeping file history so users could restore there own files helped the tape monkey. AFS has .backup volumes that solves a part of this. SMB, CIFS in NT4 was/is a pain. When you ran out of disk you hade to forcibly move users to another server with a new name. If the users learned the name of the server you lost. There was once a great phone company that had a branch office i Kista. They had a server which they named server.kista... a number of years later it lives in Älvsjö some 40km away because the users was used to it and the scripts where written, horribly I think. DFS (Microsoft Distributed File System) a good attempt at solving the above problem. I believe the fell short as there are a number of limitations. NFS never runned it in any larger scale but people keep telling me Watch out for the symlinks I wounder what they mean. But I am sure this will be solved with NFSv4 because that will solve world hunger. But wait didn't they say that NFSv3 would solve world hunger? All of the above have one common problem. When the disk run out you have big problem. Ladies and gentlemen can we please have your attention. Please stop working, close your files and hold you hands up while we move your data to a new disk. Thank you. I am sure that this can be solved with NAS, SAN or some other hype technique of the week. But with AFS this is not a problem, you move user data under the feet of the user and they will not even know it. That is pure power. So planning your disk space is not a problem, but you need to think a little of how you plan you volumes (and of course how you organise your tree). Is it more intensive, less or about the same for a given type of user population? A related question is how sensitive is it, do you have to be overly careful in order for things to work correctly? I would say AFS is very forgiving an mostly run by itself very low maintenance or zero effort if you wish. But this is unix so it will sometimes tell you I do not wish to play today (-18232323223) and if you can't find the magic number at you Internat oracle you come here and people will tell you need to insert a coin while clapping your hands to get a new token. And if you do it correctly you will teach department heads to manage ACLs on their part of the tree while you catch some zzz's. How stable and trouble free is the Windows client? I often hear people bitching about how broken it is. They can never say any specific and it always ends with Atleast it was two years ago when I last tried. It has come a long way since then. Might I add a thank you here. Is there a Linux GUI for day-to-day administration? As your questions evovle around Windows I read this as a GUI to manage the Linux servers. There is GUI parts connected to the Windows client. Thease can change ACLs and do some other stuff. There is no need to be logged on to a AFS server to administrate it. What are people doing for printing, particularly Windows printing? The computers in our Active Directory use LPR to print to our unix print server getting settings and drivers from the AD. Loose client use Samba, this is to be user friendly with drivers and settings (point and print). What about workstation customization (consistent look and feel from workstation to workstation, workstation restrictions, etc.)? What are the alternatives there? If you run Windows, you should have an Active Directory. You might also find use for a Windows file server to put certain stuff on like roaming profiles. So Pick your fights and follow the stream as it suits you. Enjoy. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Questions about OpenAFS reality
Leroy Tennison wrote: ---snip--- Is there a Linux GUI for day-to-day administration? No, I'm afraid. What is the status of server-side byte-range locking? If this isn't a near-term reality what alternatives do people use (SQL server is obviously a possibility, are there other alternatives for MS Access style databases and other byte-range locking needs)? I don't understand this. Do you want to put the database files into AFS? If yes, why ? What are people doing for printing, particularly Windows printing? OpenAFS is nothing like Samba where you share printers and files alike over the network. It's a filesystem. Printing has to be done separately. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Questions about OpenAFS reality
Christof Hanke wrote: Leroy Tennison wrote: ---snip--- What are people doing for printing, particularly Windows printing? OpenAFS is nothing like Samba where you share printers and files alike over the network. It's a filesystem. Printing has to be done separately. Still it's a valid question, if you are migrating from samba to AFS you have to replace samba with something else for printing (or continue to run samba just for printing) Here we use lprng for printing, it works fine in both *ix (linux+solaris) and windows (2000/xp), windows supports this out of the box, even if you have to manually add LPR printing as a windows component. -- ___ / __\ __ | UNIX System administrator at| __ / /__ / /__ __| IT-university / KTH Kista | (__/ /_ // / -_) _ ) _ )__) | Email «» [EMAIL PROTECTED] | \___//_/\__/_//_/_//_/ | Phone «» +46 8 790 4228 | Where the russian heart is strong, like the beating of a drum, Where the magic lingers on and the fight for truth is won.. Deep in the European soul.. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Questions about OpenAFS reality
On Dec 13, 2005, at 1:20 PM, Leroy Tennison wrote: I am just learning OpenAFS and am very impressed with what I see so far. As a result I'm now interested in getting a broad overall picture of it and have several questions. A recent post stated that they had about 7000 users in a single cell, I'm wondering what a realistic maximum is (assume 'average' end user file activity - nothing extraordinary). I saw in the archives a refernce to 45k and a statement that UMich had 100,000. Are these (especially the 100,000 for UMich) confirmed numbers? If anyone out there has a larger cell or knows of someone who does could you provide specifics? Right now I'm not so concerned with how many file servers I would have to have or other particulars as I am about what a realistic limit is with a proper configuration. The increasing number of users isn't primarily related to the number of the fileservers (these are very easily addable to a cell) but to the database servers. If you have a very heavy 'loaded' cell the calls to the protection service (ptserver) are worse than teh quantity of any other call in the cell. You can design your volume location so well, that it scales almost optimal for file access, but you still have those calls for permissions from the fileservers ending up at a smaller number of protection servers. (... just some thoughts about what you have to consider in the design of such a large cell) If I'm not terribly mistaken there were cells with more than 130,000 users around some years ago, but I don't know how 'active' those users really were. How does AFS compare in administrative burden compared to the common PC NOSes (NetWare and AD)? Is it more intensive, less or about the same for a given type of user population? A related question is how sensitive is it, do you have to be overly careful in order for things to work correctly? If you're looking for a fancy graphical administration tool like a Windows server will provide. I don't know of any. AFS administration is completely scriptable, so after some time in administering your cell, you'll end up with some nifty scripts or small programs doing almost everything of your daily work. Maybe some automatic work done at night as well :-) How stable and trouble free is the Windows client? (I saw a statement that the Windows server was considered experimental and not being maintained). The later statement unfortunately is true, but the client is used by many people and is well maintained. ;-) I never had any major problems with the client, but I'm not using it that heavily. Is there a Linux GUI for day-to-day administration? Not that I know of. After some time you don't need it. Believe me ... ;-) What is the status of server-side byte-range locking? If this isn't a near-term reality what alternatives do people use (SQL server is obviously a possibility, are there other alternatives for MS Access style databases and other byte-range locking needs)? If you want to use that for databases put into AFS. Don't ... And besides, what do you gain from a database where you share the files? Maybe for Access it's useful, but if we're talking about big databases, you shouldn't do that. What are people doing for printing, particularly Windows printing? They use Samba, if you want to print from windows boxes and your servers are UNIX. Or use CUPS, which is also very portable. But that's a completely different story. What about workstation customization (consistent look and feel from workstation to workstation, workstation restrictions, etc.)? What are the alternatives there? That depends completely on the workstation, doesn't it? This is not really related to AFS. AFS just provides a nice way of having the same files on all the workstations in the same place (nice feature the global namespace, isn't it?) I'm not looking for detailed responses just reasonable approximations of OpenAAFS reality, thank you for any replies. AFS is very well suited for large hetrogeneous environments with a lot of servers lots of users and where scalability is really a 'must have'. Horst ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Questions about OpenAFS reality
On Tue, Dec 13, 2005 at 06:20:48AM -0600, Leroy Tennison wrote: A recent post stated that they had about 7000 users in a single cell, I'm wondering what a realistic maximum is (assume 'average' end user file activity - nothing extraordinary). I saw in the archives a refernce to 45k and a statement that UMich had 100,000. Are these (especially the 100,000 for UMich) confirmed numbers? If anyone out I'd be shocked if umich didn't have 100,000 user ids in their AFS cell. they have I think 35,000 active students, all of whom get an AFS identity home directory, something like 10k or 15k staff faculty, and god knows how many years of crufty users who haven't been deleted. How many are actually *active* users is another question. I'm sure it's a fraction of these people. Maybe as many as 20,000 although that could be way off. I'd be shocked if it were fewer than 5,000. How stable and trouble free is the Windows client? (I saw a statement that the Windows server was considered experimental and not being maintained). The windows client has been under active development for the last year and a half or so and has vastly improved. What about workstation customization (consistent look and feel from workstation to workstation, workstation restrictions, etc.)? What are the alternatives there? This is just a vague recollection, but I think you can do windows roaming profiles with AFS as the file store. You still need an AD or samba to manage the windows information, though. You can have AD backend to the same kerberos 5 database as afs uses. I think you can even use AD as AFS's kerberos 5 database. danno -- dan pritts - systems administrator - internet2 734/352-4953 office734/834-7224 mobile ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Questions about OpenAFS reality
Leroy Tennison [EMAIL PROTECTED] writes: A recent post stated that they had about 7000 users in a single cell, I'm wondering what a realistic maximum is (assume 'average' end user file activity - nothing extraordinary). I don't see any reason why there would ever be any maximum. I suppose at some point you have as many VLDB servers as you can add, or you maximize the number of replicas for root.cell, but I expect OpenAFS could easily handle hundreds of thousands of users. And you can always just split the cell into multiple cells. I saw in the archives a refernce to 45k and a statement that UMich had 100,000. Stanford's statistics as of December 1st: Number of users using more than 1MB space 22,764 (53.7%) 10MB space17,203 (40.6%) 100MB space6,729 (15.9%) Number of users modifying files more recently than One week ago 5,905 (13.9%) One month ago 12,120 (28.6%) Six months ago23,631 (55.7%) One year ago 27,905 (65.8%) Ever 32,663 (77.0%) Since everyone gets an AFS home directory, we have some set of people who have them and never use them, for a total of about 45,000 registered users. How does AFS compare in administrative burden compared to the common PC NOSes (NetWare and AD)? Is it more intensive, less or about the same for a given type of user population? A related question is how sensitive is it, do you have to be overly careful in order for things to work correctly? My personal experience is that AFS is extremely robust and generally less work for any other file system of comparable size provided that you're dealing with a user population large enough to have AFS's location independence and administrative tools become truly useful. If you've outgrown a few large NFS servers, AFS is probably going to be as inexpensive or more so than any other network file system you'd end up running. The one caveat to that is that ACLs require a bit of user training and some help desk activity that a more native file system for a particular platform may not require. How stable and trouble free is the Windows client? (I saw a statement that the Windows server was considered experimental and not being maintained). The current Windows client is great. Is there a Linux GUI for day-to-day administration? No. Personally, I admit to not understanding what people see in GUIs for this sort of thing; AFS has an even more valuable feature in that it's scriptable, and for large sites you don't want anyone sitting in front of any sort of UI and doing things manually. But I do understand that not everyone thinks at a level of scalability that I tend to. What is the status of server-side byte-range locking? If this isn't a near-term reality what alternatives do people use (SQL server is obviously a possibility, are there other alternatives for MS Access style databases and other byte-range locking needs)? We generally recommend against putting databases in AFS and have for some time. Byte-range locking for Windows is available and is sufficient to have Word and similar applications do the right thing, but I'm not sure I'd want to trust an active database to the AFS locking model. What are people doing for printing, particularly Windows printing? As others have mentioned, AFS is only a file system and doesn't attempt to solve these sorts of needs. At Stanford, we also have an AD forest that we use to provide other Windows services. What about workstation customization (consistent look and feel from workstation to workstation, workstation restrictions, etc.)? What are the alternatives there? AFS is just a file system. What you do with the file system is up to you. You can distribute or automate the distribution of such things via AFS, or you can just use AFS as a file system, but AFS does not, itself, control things like this. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Questions about OpenAFS reality
Leroy Tennison wrote: How stable and trouble free is the Windows client? (I saw a statement that the Windows server was considered experimental and not being maintained). Hosting AFS file, volume database, and protection servers on Microsoft Windows platforms is not recommended. There are no resources available at the current time to maintain this code base. If this is something you are interested in, please contact me privately. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Questions about OpenAFS reality
On Tue, 13 Dec 2005, Leroy Tennison wrote: Is there a Linux GUI for day-to-day administration? I've never seen an administration GUI that didn't fail to scale long before the scaling limits of the underlying technology were reached. Invariably, my day-to-day reality far exceeds the imagination of any GUI designer. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Questions about OpenAFS reality
Am Dienstag, 13. Dezember 2005 13:20 schrieb ext Leroy Tennison: Is there a Linux GUI for day-to-day administration? AFAIK not. What is the status of server-side byte-range locking? If this isn't a near-term reality what alternatives do people use (SQL server is obviously a possibility, are there other alternatives for MS Access style databases and other byte-range locking needs)? Could you clarify this? Do you mean SQL Server as alternative to AFS or to MS Access stored in AFS? What are people doing for printing, particularly Windows printing? I don't get the point. How is printing related to AFS? Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: [EMAIL PROTECTED] Hambornerstraße 55 | Web: http://www.capgemini.com D-40472 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net pgpEGVVBamQEu.pgp Description: PGP signature
