Assumptions I am making:
- You are running custom applications (not sla, itsm, cs, crm, etc.)
- You do not have any external api's (plugins, external binaries
compiled for Solaris) on the ar servers
-
I would go with something along these lines:
1. Build the new 7.5 servers:
1. Install the prerequisite software (db client, java, etc.)
2. Install ARS 7.5, point it at an empty database that uses the
AL32UTF8 character set
1. Install subsystems in use (email, approval, etc.)
3. [1] Manually apply your form/field/permission changes to the core
forms and grab a def
4. [2] You will need a load balancer, get it set up properly, get
the server group set up properly
2. Migration preparation
1. Install the 64-bit 10g oracle client on the old arserver(s)
2. Empty the contents of the new db instance
3. Migration:
1. Upgrade the existing 6.3 server to 7.5
1. Perform a minimal installation (ARServer only)
2. Stop AR on the new and old servers
3. Convert the db character set/transport the data
1. Empty the temp new database with AL32UTF8 character set
2. Exported (exp utility) the data from original database (source)
with the source character set
3. Copy the dump to the new server
4. Import (imp utility) the data into the new
database(destination) with character set AL32UTF8
4. Perform the upgrade installer for other core ar components
(email, fb, approval, etc.)
4. Post-migration
1. Set up oracle data guard
Footnotes:
1. A better option would be to update your applications so they do not
rely on (any) changes to the core forms prior to the migration.
2. Load Balancer: You will require a hardware load balancer (BigIP,
etc.) in front of the ARServers:
- Enable session persistence based on the source ip address
Special Notes:
1. Do perform this operation in a non-production environment prior to
upgrading production and verify it works. Also, during this time, if
you run into workflow problems, generate the defs necessary to apply
to an upgraded system so that you can use them during your upgrade.
Server Groups: Server groups will make the following operations
easier, but is not required to run an HA arrangement with AR:
- Object cache synchronization across all nodes
- Subsystem failover between nodes (e.g., escalations)
DR Failover: There are many approaches to this; the choice usually
depends on the size of your wallet and the practices currently
implemented for dr:
- Using Oracle DG, the db should be available at the time you need to fail over
- You should be able to image the AR VM's in the DR with a near mirror
image of the production hosts (hostname can/may vary)
- This can be done on the fly during a dr or maintained separately
- You will need to create a runbook of the operations required to
perform a failover in the event you do not have any type of automated
failover in place. Tasks would include things like:
- dns changes
- fail over db to standby server
- bring up ar servers
Axton Grams
The opinions, statements, and/or suggested courses of action expressed
in this E-mail do not necessarily reflect those of BMC Software, Inc.
My voluntary participation in this forum is not intended to convey a
role as a spokesperson, liaison or public relations representative for
BMC Software, Inc.
On Thu, Sep 17, 2009 at 7:05 PM, Paul Blasquez <pblasq...@equinix.com> wrote:
> **
> Hello,
>
> I have been tasked from moving our current production installation to a more
> robust/modern installation. Any and all help would be appreciated!
>
> Currently:
>
> -AR System 6.3 custom server (with modifications to forms User and AR System
> Email Messages)
> -Oracle 9iR2 non-unicode
> -Solaris 9
> -Application and Database reside on the same machine
>
> Goal:
>
> -AR System 7.1 or 7.5 (With form modifications intact)
> -Oracle 11g unicode
> -Linux Redhat 5
> -Application and Database on different machines
> -Disaster Recovery (DR) backup site (Using Oracle log-shipping)
> -Local High Availibility (HA) backup server (server groups?)
>
> I have at my disposal 4 Virtual Machines (VMs) to do development and
> testing, with an additional 2 VMs and 2 dedicated servers (for the DBs)
> reserved for the final production installation. (Please note that there
> will be Midtier servers involved in all of this, but their deployment is
> trivial so I'm not including them here.)
>
> From my point of view I see that multiple operations must occur for this
> migration to be successful (in no particular order):
>
> 1) The Oracle 9iR2 DB
> -Must be upgraded to 11g
> -Must be translated into Unicode
> -Must be moved from the Solaris 9 machine to the Linux RH5 machine
>
> 2) The current 6.3 installation
> -Must be upgraded to 7.1 or 7.5
> -Must be configured for server groups
> -Must be moved from the Solaris 9 machine to the Linux RH5 machine
> -Must begin connecting to the DB remotely instead of locally
>
> 3) The finished AR System 7.x installation and Oracle 11g DB
> -Must begin log shipping (Data Guard) to the second DB
> -Must have a method for failing over to the second site
> -Must have a method for local server group failover (load balancer/quick
> TTL DNS)
>
> If you have completed any one of these tasks before, *please* share with me
> your experience and what you would recommend for my situation! I would
> save me hours of researching dead-ends!
>
>
> Finally, I would like input on what would be the correct order to complete
> all of these tasks, so that the cutover would be as smooth as possible with
> the least downtime possible. So far, I have tested the following scenario
> in Dev/Test:
>
> Fresh installation of 7.1/7.5
> -DEF import of workflow
> -ARX import of data
>
> This method seems stable but tedious, as there are many import errors I
> would need to repair. This would be the method I would fall back on if
> there were no more clever/sophisticated way to upgrade.
>
>
> Again, ANY input at all would be GREAT, as of course this project is on a
> tight timeline. THANK YOU to anyone who responds!
>
> ____________
> Paul Blasquez
> Senior Network Engineer/Remedy Developer
>
>
> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers
> Are"_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
