[OpenAFS] Transitioning from IBM Transarc to OpenAFS Help

[Steve Devine]

Andrew Bacchi wrote:

> We migrated from AIX/Transarc to Linux/OpenAFS about 2 years ago.  I 
> chose method 1 to make a gradual transition over the course of a 
> summer.  For a few weeks I had a mixed cell with both platforms in 
> production.  I did not have any problems with database corruption and 
> all DB and file servers talked to each other without incident.
>
> Creating a new cell would have caused more problems for the user 
> base.  The migration went easily to the 1.2 .x version series.  I 
> can't speak about any later release.
>
> John Harris wrote:
>
>> Greetings OpenAFS Community,
>>
>> We are *finally* going to transition our production AFS cells from 
>> IBM Transarc to the OpenAFS code base.
>> I have lots of questions and discussion points and am not sure if 
>> this is the appropriate forum to do it in, so I'd first like pointers 
>> on where to place it.  I also hope to contact other 
>> companies/universities that have made the transition to get some 
>> pointers.
>>
>> Unfortunately, we are running on majorly patched IBM code; meaning 
>> the code that branched to OpenAFS a number of years ago has been 
>> patched several times on proprietary needs of IBM's customers.  We 
>> aren't running anything different than their *latest* release version 
>> and I've gathered enough info to know that the problems they patched 
>> have already been addressed in OpenAFS, but I assume there are major 
>> differences now even in the kernel module...?
>>
>> Here, we are debating about a couple of ways to transition:
>>
>> 1) The communications-type folks, you know, the ones who don't 
>> actually do any of the work, want to keep the same cell name and just 
>> do a one-time massive integration come cut-over day.  They hope to 
>> mix and match IBM servers (database and fileservers) and OpenAFS 
>> servers (ie: just added OpenAFS servers and rotate the IBM ones 
>> out).  To me, this just screams of database corruption and problems; 
>> the technical side of our house is really against this (we have 
>> enough problems with running on one code-base) for various reasons, 
>> but it would be quickest way.  Before I go testing this for weeks on 
>> end, does this community have any opinions on it.
>>
>> 2) The technical-type folks here want to start over with a new cell 
>> name so we can slowly transition our production clients over one at a 
>> time, have the old cell running for easy cut-back, take the time in 
>> the new cell to design the layout and permission scheme the correct 
>> way (like no individuals on ACLs, etc.), etc.
>>
>> This is slower but safer and easier in my opinion.  We have lots to 
>> do, like transitioning from the afs4-krb database and K5, moving to 
>> newer hardware, etc.
>>
>> I'd really like some feedback, either in the appropriate forum or 
>> personally, on experiences or thoughts.  There isn't a lot publicly 
>> out there on a big transition like this.
>>
>> Sincerely,
>>
>> John Harris
>> University of California, Davis
>>
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>
>>
>>
I would strongly advise against a new cell. This could get ugly very 
fast in ways that you might not even realize.
We slowly moved from  Ibm p43s (running the old transarc stuff) to Dell 
boxes running OpenAfs. I just did it one box at a time. We swapped the 
DB over to OpenAfs two years ago (just tar up the dbs and move em)  and 
ran a mixed fileserver cell for over a year.
Its was seamless  and painless. We got the cell swapped over to OpenAfs 
before jumping to k5.


-- 
Steve Devine
Storage Systems
Academic Computing & Network Services
Michigan State University

506 Computer Center
East Lansing, MI 48824-1042
1-517-432-7327

Baseball is ninety percent mental; the other half is physical.
- Yogi Berra