symbolic links in site

Hi,

 During some discussions concerning site architecture, we decided that we may want to try to split a new environment into multiple sites.  To increase the manageability of these seperate sites, we wanted to use symbolic links in the second site to refer to directories in the first site. Specificially, we wanted to perform the following linkages:

site2/tclprocs -> site1/tclprocs

site2/Xlate -> site1/Xlate

site2/formats -> site1/formats

site2/Tables – > site2/Tables

Does anyone have comments, suggestion, positive or negative feedback on trying this etc. Please note Jim’s mentioning of the breaking of symbolic links by the engine toolset.

I found this artical in the archives

Anther approach is to use a ‘global’ site. That is a Cloverleaf site which

will ONLY be a repository for the objects (Tables, Variants, Tcl procs,

etc.) which are needed in multiple sites. One would never expect to see any

integrations actually defined here.

Utilize the same symbolic linking technique.

An advantage of the site technique is that when upgrading, the entire site

can be upgraded taking advantage of the vendor supplied scripts and tools.

Also the existing engine toolsets can be used for managing/maintaining the

objects.

A serious caveat when utilizing symbolic links. The engine configuration

toolsets create a .bak file of the objects being edited. Because of the

method being used to create the .bak file (probably a mv instead of a cp),

the symbolic link actually stays with the .bak file rather than the source

file. This effectively breaks the symbolic link. It is therefore imperative

to use the configuration tools in the ‘global’ repository and to develop

audit tools to assure links have not been broken. Otherwise despite your

best intentions, you could end up with many ‘local’ copies and the ‘global’

copy may become not only obsolete, but worthless.

I have formally asked Quovadx to develop an understanding within the engine

of the concept of ‘global’ objects and to support their existence natively

within the engine environment.

Additionally, the symbolic links in the HCIROOT tclprocs directory will

disappear with a new release (the install rebuilds the directory without

regard for what you might have placed there). I have written a Tcl proc

which saves off the link information and restores the links under argument

control. The proc is run prior to upgrade to save off the link info, then

after to restore the links.

There are many ways to architect your multi-site environment. Rarely have I

seen such re-architecting introduce any performance issues (normally quite

the opposite happens as most people have eventually gotten themselves into

a performance issue trying to stay with one site). It is worth the effort

to have an intensive brainstorming session to decide what your goals for

restructuring are and how to best achieve those goals.

My personal belief is a new environment should consider the use of a multi

site architecture from the start and lay the groundwork up front thereby

reducing the necessity to split a site.

Please understand, architecting into multiple sites does NOT guarantee you

will never have to do a site split. As time goes by and your integration

architecture becomes more complex, you may find a need to revisit the

issue. A good idea is to have a periodic review (every six months?) of your

architecture and evaluate it’s effectiveness.

One of the really good benefits of a multi site environment, is the ability

to control the integration operational environment with greater

granularity. Thus the need to take down a site (which happens from time to

time) only affects the threads which reside in that site. Other

administration activities (such as reporting) can also become improved.

But there is no free lunch – some activities such as HACMP may become more

complicated or complex.

I have also asked Quovadx (through group conversations aimed at requesting

enhancements) to make the engine toolset multi site sensitive such that the

defining of and connecting together multiple sites is a non event. when

deciding what thread(s) to route as destinations for example, the GUI

should present a hierarchy of defined sites and their threads. The Engineer

then selects the appropriate destination (no matter what site it is in) and

all of the necessary configuration is constructed ‘under the covers’ to

make that happen (such as defining localhost ports to connect the various

sites). Tools should be deveolped to assist in the management of multiple

site environments. As is obvious from the response to this question now and

in the past, multiple site production environments are here to stay and are

growing. The engine should do a better job of facilitating that

architecture.

When I was at Oakwood Hospital, we were among the first to deploy multiple

site architecture in a production environment (nearly eight years age – can

that be correct). At that time I noticed the underpinnings in the engine to

support what has been referred to as virtual hubs (domains).

I have been predicting for a while now that the need for such cross

platform (as well as multi site) is coming fast. In my opinion, Quovadx

would be well served getting ahead of that particular curve.

Whew!

Jim Kosloskey

---

Original Message

---

From: Montoya, Francisco [SMTP:Francisco.Montoya@bannerhealth.com]

Sent: Friday, October 10, 2003 4:21 PM

To: Technical Issues

Subject: [clovertech] RE: Looking for information about splitting up sites

AIX 4.3.3

QDXi 3.8.1

When we split our environment into three sites, we had several tcl

procs, tables, variants and xlates that were needed in all three new

sites. Instead of having three verisons of these files (one in each

site), we created a shared directory under the hci root directory and

then created a link to this directory.

Our directory sturcture:

/hci/root3.8.1P/prod_formats

/hci/root3.8.1P/prod_xlate

/hci/root3.8.1P/prod_tables

/hci/root3.8.1P/prod_tclprocs

Then within each site there is a link pointing back to the directory

created above the site level for each of these directories.

formats -> /hci/root3.8.1P/procd_formats

Xlate -> /hci/root3.8.1P/prod_xlate

Tables -> /hci/root3.8.1P/prod_tables

tclprocs -> /hci/root3.8.1P/prod_tclrocs

This has been a great time saver for us and we have avoided a management

nightmare by not having to manage three versions of the same file.

Francisco Montoya

Senior Programmer Analyst

Banner Health

1441 N 12th Street

Phoenix AZ 85006

Phone: 602-495-4971

francisco.montoya@bannerhealth.com

---

Original Message

---

From: Jason Alexander [mailto:jalex@u.washington.edu]

Sent: Thursday, October 09, 2003 3:38 PM

To: Technical Issues

Subject: [clovertech] Looking for information about splitting up sites

We currently run one site on our production machine and we’re

seeing some performance problems/degradation. (We’ve got lots of

development sites on a different machine, but the prod machine only runs

the prod site.)

Our primary is a cluster of 2 IMB RS6000 M80s with 4 CPUs each,

6 Gig of real RAM and 4 Gig of virtual RAM. Our production site is 20

processes with roughly 100 (user defined) threads. When we run HCI

commands today (hciconnstatus, hciprocstatus, etc.) it is not unusual to

have the command time-out. We’ve also seen general performance

degradation as the number of threads has grown.

I’m looking for folks who have split one functional site into

two or more sites for any information you might have on

1) How to do so with minimal disruption to the user community

2) Information about system performance that might affect the choice of

configuration (how many threads can a site handle, aside from disk usage

is there any other penalty to running many sites that might dissuade me

from splitting into 10 sites instead of 2)

3) Experience regarding sending messages from one site to another (we

already use localhost threads to minimize interprocess communication

which has in the past caused us severe state 7 latency so I suspect that

this will be a similar process)

I’d be just as happy to take this discussion to private e-mails

as well so that we don’t subject the whole list to follow-up questions.

Jason Alexander

Systems Programmer

UW Medicine ITS

(206)685-8129

Privileged, confidential or patient identifiable information may be

contained in this message. This information is meant only for the use of

the intended recipients. If you are not the intended recipient, or if

the message has been addressed to you in error, do not read, disclose,

reproduce, distribute, disseminate or otherwise use this transmission.

Instead, please notify the sender by reply e-mail, and then destroy all

copies of the message and any attachments.

—

You are currently subscribed to clovertech as:

Francisco.Montoya@bannerhealth.com

To unsubscribe send a blank email to unsub-clovertech@ajax.quovadx.com

—

You are currently subscribed to clovertech as: chiliman@todaylink.com

To unsubscribe send a blank email to unsub-clovertech@ajax.quovadx.com