Locality, and latency to the server still matters. Let's imagine we are 5 years from now, and there are at least 3 branded AFS derivatives, and vendors touting 'AFS appliance' capability, and 'the cloud' has been replaced by 'the filesystem'. As in, some derivative of the Andrew filesystem.
When the meteorology department is approaches deadlines for climate conference papers, and everyone there is throwing terabytes of datafiles into and out of 'the filesystem', everyone else on campus is going to be very happy they have isolated servers, and the only complaints about performance will be from the poor students taking a weather course for graduation requirements. Dropbox would melt down and explode in bankruptcy from bandwidth charges if 10Gb networking was actually *everywhere*. Their model works, for the moment, because Dropbox has 10Gb firehoses, and all their users drink from teensy consumer class straws. They can take their time filling buckets with the firehose and let the users drain it out slow. AFS might have a chance of handling this, because of the design. On Mon, Oct 01, 2012 at 07:28:43PM +0000, Dyer, Rodney wrote: > NetApp's strength is actually its problem, and that is it doesn't actually > exist to the client, it is completely invisible. Windows sees it as a normal > Windows CIFS share. 'nix sees it as NFS. The problem is that this is > point-to-point file sharing. AFS allows global namespace, and the client > does the volume lookup to find the server for the "path" required. This is > true "distribution", not point-to-point. > > If you setup Microsoft's AD "dfs" with NetApp filers, you might come close to > "emulating" what AFS does, but it won't be pretty, and as far as I know 'nix > is out of the question in that setup. > > I would personally rather be allowed to distribute my server load, than to > point thousands of clients at single filer heads. Of course networking is > much better now than it was 10 years ago, but single point of failure is > still an important consideration. We have server rooms in each of our major > campus buildings. If networking goes down in one building, the others don't > completely lose access to AFS. This is mainly read-only data, but users are > also distributed where possible. The rule of thumb should be always to keep > network traffic local where possible, and only expand where necessary. This > is actually the opposite model of the internet cloudy file repositories like > DropBox. > > Maybe I'm just too old, and in a world where 10 Gb networking is everywhere > locality no longer matters. > > Rodney > > Rodney Dyer > Operations and Systems (Specialist) > Mosaic Computing Group > William States Lee College of Engineering > University of North Carolina at Charlotte > > > From: [email protected] [mailto:[email protected]] > On Behalf Of Hoskins, Matthew E. > Sent: Monday, October 01, 2012 12:37 PM > To: Booker Bense > Cc: Glenn Bjorcken; [email protected] > Subject: Re: [OpenAFS] the future > > NetApp's "vol move" and "vfiler migrate". We primarily use AFS vos move for > FS balancing and evacuation in prep for maintenance. Since netapps can be > maintained non-disruptively, keeping them scaled small so they can be > evacuated easily is not a design constraint. Therefore, our netapps have > 200+ TB of storage which eliminates most of the data movement we would > typically do with AFS to avoid maint downtime. > Its a different world/different philosophy. Netapp can also serves a volume > to NFS and CIFS simultaneously, supports Krb5 and AD...Snapshots, dedupe, > compression, But i digress. > > On Mon, Oct 1, 2012 at 11:57 AM, Booker Bense > <[email protected]<mailto:[email protected]>> wrote: > On Mon, Oct 1, 2012 at 8:44 AM, Glenn Bjorcken > <[email protected]<mailto:[email protected]>> wrote: > > > > > I want vos move, does NFSv4 do that ? :) > > > > > I think if you spend $$$$$$ on a NetAPP box, you might get that. > However, I am aware of > no open source/freeware solution that does vos move, ( or at least > none that does it as > seamlessly as OpenAFS). > > - Booker C. Bense > _______________________________________________ > OpenAFS-info mailing list > [email protected]<mailto:[email protected]> > https://lists.openafs.org/mailman/listinfo/openafs-info > _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
