Prev: Debian pkg mgmt database/system irreparably broken
Next: Fedora 13, how do I get OpenGL support?
From: Doug Freyburger on 14 Jun 2010 12:15
Nico Kadel-Garcia wrote:
> Doug Freyburger <dfrey...(a)yahoo.com> wrote:
>
>> The source host is old:
>>
>> Red Hat Enterprise Linux ES release 3 (Taroon Update 8)
>
> Stop *RIGHT* there. RHEL 3? E-w-w-w-w-w-w-w!

The source host is the source for the migration effort because of that.
Check. No way am I going to abandon the source of the data without
migrating just because it's old. Yes way am I going to ask for the old
host to be trashed after it's all over. The entire source is actually
two ASM/CRS Oracle clusters of two hosts each.

The other cluster has already been migrated using NFS over the NetApp.
That followed the standard NetApp experience with NFS, works first time
every time. Unfortunately trying to use the NetApp as a block service
also has followed the standard NetApp experience with SAN, no faster
than NFS but a lot more frustrating.

>> Red Hat Enterprise Linux Server release 5.3 (Tikanga)
>
> There are a number of useful and important fixes from the default RHEL
> 5.3 kernels available in RHEL 5.4 and 5.5. I'd definitely make the
> leap.

Thanks! Since there was frustration with the block service I started
the backup over again using the NFS service. Time was of the essence
and it was worth pursuing both avenues in parallel.

At this time the 2+ TB backup over NFS completed. We swung the NFS
mount to the new system which of course worked first time every time
(not counting a bad EtherNet cable thrown in by Murphy just for fun).
The restore over NFS completed and production has been migrated to the
new machines.

I have added OS upgrades to the recommended maintainence list for all of
the new hosts at that client. It will proceed on the usual scheduled
maintenance window pattern.

Thanks for the advice. I now have a plan going forward.
From: Doug Freyburger on 15 Jun 2010 11:43
Nico Kadel-Garcia wrote:
> Doug Freyburger <dfrey...(a)yahoo.com> wrote:
>
>> I have added OS upgrades to the recommended maintainence list for all of
>> the new hosts at that client. �It will proceed on the usual scheduled
>> maintenance window pattern.
>>
>> Thanks for the advice. �I now have a plan going forward.
>
> Good. And you've my sympathies: I worked very hard on a migration of
> 12 year old SCO OpenServer, proprietary software to RHEL 5 a few years
> ago, and definitely feel your discomfort. (I also asked Richard
> Stallman for brownie points for doing it, and he said "well, it's a
> start"....)

The ancient source host accessed 2+ TB LUNs and it is inevitable that
the destintion host will at some point need to access 2+ TB LUNs.
Moore's Law marches on and the current 256 GB raw devices used for
Oracle ASM will one day be replaced by bigger ones.

Thanks for pointing me in the right direction.

This is my week for dealing with clients who have ancient hardware.
Over the weekend a different client added drives to an ancient HP VA
array and the new drives didn't level. Yeah, not just an old EVA but
an ancient VA. Sigh. "I am attempting to make the world's first
memonic circuit using only stone knives and bear skins." ;^)

That client doesn't even have HP's CommandView installed on their jump
box so all I have is the command line looking thingie that came with the
old VA array. 9600 8N1, whew. I'll look for how to install CommandView
for them ...
 | 
Pages: 1
Prev: Debian pkg mgmt database/system irreparably broken
Next: Fedora 13, how do I get OpenGL support?