Configuring ArcSDE HA

2975
17
05-27-2011 02:29 AM
by Anonymous User
Not applicable
Original User: tariqchpk75

I want to configure/manage ArcSDE failover.  I have read an article found at

www.lincoln.ne.gov/city/pworks/gis/pdf/arcsde.pdf

As per this there should be two separate oracle server sharing common data stores.

My question is if we will have the replica of entire geodatabase or it will be the same single geodatabase for both oracle servers.

Any kind of assistance n help is appreciated in advance.
0 Kudos
17 Replies
by Anonymous User
Not applicable
Original User: tariqchpk75

Thanks for reply.

You have raised performance issue regarding virtualized environment. I need to clarify one thing what were RAM and processors specifications of the hosing servers. As I think low performance should be attributed to the hardware resources employed but not to the virtualiztion itself. What do you say?
0 Kudos
VinceAngelo
Esri Esteemed Contributor
It's difficult to blame RAM or CPU when two identical hosts are provided for testing.  We
spent three weeks in the test lab and, based on the results that we had to present before
an engineering review board, threw out the load-balanced 8 virtual server architecture
in favor of a single physical server with a virtual failover host, and eventually threw out
the failover host because it was unreliable with the needed fibrechannel drivers.

By definition, virtualization has a cost associated with it (I call it the "virtualization tax").
One of the prime benefits of virtualization is that it lets you steal CPU cycles from unbusy
systems in order to reduce the physical host footprint.  Yet when the systems are NOT unbusy,
and especially when the busyness is I/O related, there is a greater cost.  GIS applications
easily have the highest I/O demand in the business marketplace.   Virtualizing production
GIS servers causes them to have the highest taxes.  You won't notice when the systems
aren't under heavy load, but when they are, you can't help but notice it.

I had VM administrators pleading with me to speed up physical deployment of an ArcSDE
server because the four virtual servers it was replacing were increasing the data center's
demand numbers to the point where it was endangering their contract performance metrics
(when deployed, the ArcSDE connect time [with scores of concurrent users and thousands
of feature classes] dropped from 40-120 minutes to 5 minutes).  There was nothing wrong
with the RAM or CPUs involved, and only two of the servers were really busy.  That same
physical server now services 3-4 times the client load of the four virtual hosts, and still has
a similar connection time (with 30% more tables).

- V
0 Kudos
by Anonymous User
Not applicable
Original User: tariqchpk75

Can you please elaborate it with the help of diagram that what was your architecture for both the tests (virtual and physical). what arcgis server configuration you used (single som, multiple socs, arcsde failover etc).

Moreover arcgis server is 32 bit. if it is installed on a physical server having 32gb ram, will it be able to use all the ram? virtual architectures are io intensive. did you use the same number of ethernet interfaces for both configurations.Plz post the diagrams.

Regards
0 Kudos
VinceAngelo
Esri Esteemed Contributor
As stated previously, the project was done under non-disclosure.  The three-member test team
had a combined fifty years of GIS/IT experience, twenty years of rigorous test experience, and
more than ten years with the VM application in use.  We were fully aware of the issues and did
our best to optimize VM performance with the hardware previously selected for the project.  We
had to present our results to an engineering review board that *really* wanted us to select VMs
for all components.  In the end, our results were consistent with Esri support policy on virtual
architecture -- Works okay in test environments, but not recommended for production use.

- V
0 Kudos
by Anonymous User
Not applicable
Original User: mishfaq

Thanks Vangelo for the very informative reply. However, I would like to mention here that when we talk about Failover Manager implementation so it is not true virtualization rather you are working with actual system physical resources. As per my understanding and after my discussion with our system administrator, the virtual host on top of your cluster nodes manages control from one node to another. To simply say, it is not similar to virtualization offered by Microsoft Hyper V or VMWare. Please correct me if you have better information as I am not master of this subject.

Your comment stay true regarding the hardware architecture as mentioned by Tariq. Though, I also got a comment saying that virtualization environment/tools are improved with time. So, can you share vintage of this experiment about which shared statistics.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
Esri and VMware have a Deployment Guide which contains performance statistics from 2009.  Our
disk options were not as performant, and the result was reflected in our evaluation.  The ArcGIS
Server Blog has guidelines for ArcGIS Server virtualization.

The way to get higher availablility out of ArcSDE is to use Direct Connect (the MTBF for an unused
component is infinity).  A failover configuration for the application server should only be considered
as a short term solution to get all your clients to the same release (or at least to those for which
DC is an option) [and, IMHO, probably isn't worth the bother -- our failover provisions caused more
downtime than any other cause].

- V
0 Kudos
by Anonymous User
Not applicable
Original User: mishfaq

Can you kindly explain how can we achieve High Availability using direct connect? Please share if you have any literature or reference URL in this regard.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
Mean time between failures (MTBF) is a key component in availability calculation.  If you remove
an unnecessary component, you remove any possibility of its failure, which increases reliability. 

Using Direct Connect to Oracle will not provide high availability without RAC, but it will provide
higher availability than a redundant ArcSDE application server could, and it does it without
the complexity of a redundant system for a component that isn't designed to support it.

- V
0 Kudos