Issues setting up a DR instance for QC/ALM?
| ♥ 0 |
We are attempting Disaster Recovery (DR) testing in a temporary isolated environment. We duplicated our QC VM’s (DB-server and QC-server) with different IP addresses. QC Service strats up and we can get into Site Admin and into projects wtih the QC IE Clients, and within ALM/QC, the functionality to edit tests and other functions still directs activity to the original/production installation IP addresses/servers (changing data in the ORIGINAL Databases) – which is not valid in the DR environment. Is there a config file or some other areas that can be used to redirect ALM/QC activity to the new temporary DR Servers/ IPs? I see the original/production Server’s IP in the Site Admin (qcsiteadmin_db) tables, but not sure where to begin. Again, this is a copied environment for temporary use and any changes will not affect the existing QC/ALM Production environment we use regularly.
Marked as spam
|
Posted by |
Private answer
You cannot just DUPLICATE all components (App, DB, repository etc) and expect ALM/QC to work. I (and HP) recommend Fresh INSTALL of ALM/QC on the NEW/other DR/TEST environment, stand up a SEPARATE Database instance, then do a project migration of copies of projects and corresponding repositories. When duplicating (HDD copy including all files OR VM image copy) this sets you up with a potentially DISASTROUS situation where even if you get it up and running, it will dangerously be reading/writing to DB's in the OLD db server. It is not trivial to swap DB servers (which is basically what you are doing with the copying). Migrate your qcsiteadmin_db (and project DB's) to the NEW DB instance, and choose ''use and existing'' qcsiteadmin_Db schema/database when installing QC/ALM. Once your NEW QC/PC is up and running, then, EACH project must be REMOVE'ed, it's DBID.xml edited to point to the NEW DB server (the one you just added to Site Admin), then RESTORED from it's DBID file. a trick here would be to create a NEW project and look at it's DBID.XML for DB_CONNSTR, DBSERVER_NAME, and DB_USER_PASS. Once this is all working with the NEW server and COPIES of projects, the DR process on the PROJECT level would be to de-activate the DR-project copy, then REPLACE the DB and REPOSITORY from the BACKUP of PROD. This all works best if PROD and DR/TEST are on the SAME DB and QC/ALM version and Patch level. Marked as spam
 Posted by pt-barnum (Questions: 4, Answers: 509) Answered on February 20, 2015 2:12 pm
|