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
[email protected]
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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
