[OpenAFS] the future
Dyer, Rodney
rmdyer@uncc.edu
Mon, 1 Oct 2012 19:28:43 +0000
--_000_18B8F39B03C7B445B4C3B97D55D4555B0E7020RPITSEXMS2itsuncc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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 norm=
al Windows CIFS share. 'nix sees it as NFS. The problem is that this is p=
oint-to-point file sharing. AFS allows global namespace, and the client do=
es the volume lookup to find the server for the "path" required. This is t=
rue "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 st=
ill 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 reposito=
ries 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: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org=
] On Behalf Of Hoskins, Matthew E.
Sent: Monday, October 01, 2012 12:37 PM
To: Booker Bense
Cc: Glenn Bjorcken; openafs-info@openafs.org
Subject: Re: [OpenAFS] the future
NetApp's "vol move" and "vfiler migrate". We primarily use AFS vos move fo=
r FS balancing and evacuation in prep for maintenance. Since netapps can =
be maintained non-disruptively, keeping them scaled small so they can be ev=
acuated easily is not a design constraint. Therefore, our netapps have 200=
+ TB of storage which eliminates most of the data movement we would typical=
ly do with AFS to avoid maint downtime.
Its a different world/different philosophy. Netapp can also serves a volum=
e 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 <bbense@gmail.com<mailto:bben=
se@gmail.com>> wrote:
On Mon, Oct 1, 2012 at 8:44 AM, Glenn Bjorcken <glenn@kth.se<mailto:glenn@k=
th.se>> 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
OpenAFS-info@openafs.org<mailto:OpenAFS-info@openafs.org>
https://lists.openafs.org/mailman/listinfo/openafs-info
--_000_18B8F39B03C7B445B4C3B97D55D4555B0E7020RPITSEXMS2itsuncc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Arial","sans-serif";
color:#1F497D;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D">NetApp’s strength is =
actually its problem, and that is it doesn’t actually exist to the cl=
ient, it is completely invisible. Windows sees it as a normal Windows
CIFS share. ‘nix sees it as NFS. The problem is that thi=
s is point-to-point file sharing. AFS allows global namespace, and th=
e client does the volume lookup to find the server for the “path̶=
1; required. This is true “distribution”, not point-to-po=
int.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D"><o:p> </o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D">If you setup Microsoft̵=
7;s AD “dfs” with NetApp filers, you might come close to “=
;emulating” what AFS does, but it won’t be pretty, and as far a=
s I know ‘nix is
out of the question in that setup.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D"><o:p> </o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D">I would personally rather b=
e 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 impo=
rtant consideration. We have server rooms in each of our major campus=
buildings. If networking goes down in one building, the others don&#=
8217;t completely lose access to AFS. This is mainly
read-only data, but users are also distributed where possible. The r=
ule 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.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D"><o:p> </o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D">Maybe I’m just too ol=
d, and in a world where 10 Gb networking is everywhere locality no longer m=
atters.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D"><o:p> </o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D">Rodney<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D"><o:p> </o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Rodney Dyer<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Operations and Systems (S=
pecialist)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Mosaic Computing Group<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">William States Lee Colleg=
e of Engineering<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">University of North Carol=
ina at Charlotte<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D"><o:p> </o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D"><o:p> </o:p></span></p=
>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"=
;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:"Tahoma","sans-serif""> openafs-=
info-admin@openafs.org [mailto:openafs-info-admin@openafs.org]
<b>On Behalf Of </b>Hoskins, Matthew E.<br>
<b>Sent:</b> Monday, October 01, 2012 12:37 PM<br>
<b>To:</b> Booker Bense<br>
<b>Cc:</b> Glenn Bjorcken; openafs-info@openafs.org<br>
<b>Subject:</b> Re: [OpenAFS] the future<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">NetApp's "vol move" and "vfiler migra=
te". We primarily use AFS vos move for FS balancing and evacuati=
on in prep for maintenance. Since netapps can be maintained non-disr=
uptively, 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 wou=
ld typically do with AFS to avoid maint downtime. <o:p></o:p></p>
<div>
<p class=3D"MsoNormal">Its a different world/different philosophy. Ne=
tapp can also serves a volume to NFS and CIFS simultaneously, sup=
ports Krb5 and AD...Snapshots, dedupe, compression, But i digress.&nb=
sp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class=3D"MsoNormal">On Mon, Oct 1, 2012 at 11:57 AM, Booker Bense <<a=
href=3D"mailto:bbense@gmail.com" target=3D"_blank">bbense@gmail.com</a>>=
; wrote:<o:p></o:p></p>
<p class=3D"MsoNormal">On Mon, Oct 1, 2012 at 8:44 AM, Glenn Bjorcken <<=
a href=3D"mailto:glenn@kth.se">glenn@kth.se</a>> wrote:<br>
<br>
><br>
> I want vos move, does NFSv4 do that ? :)<br>
><br>
<br>
<br>
I think if you spend $$$$$$ on a NetAPP box, you might get that.<br>
However, I am aware of<br>
no open source/freeware solution that does vos move, ( or at least<br>
none that does it as<br>
seamlessly as OpenAFS).<br>
<br>
- Booker C. Bense<br>
_______________________________________________<br>
OpenAFS-info mailing list<br>
<a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</a><br=
>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info" target=
=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-info</a><o:p=
></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>
--_000_18B8F39B03C7B445B4C3B97D55D4555B0E7020RPITSEXMS2itsuncc_--