Hi Peter
Thanks for posting your question. I have attempted to answer your
questions below to the extent I can remember.
On 1/3/11 10:02 AM, peter.gratzer_at_spanningtree-solutions.com wrote:
> I am looking for some insight into HADB ...
>
> Configuration:
> - Solaris 10 u8 on 2 SPARC systems
> - GF v.2.1 running in each system within a Local Zone
> - no shared memory area specified
> - Cluster configured with HADB 4.4.3.6
>
> it seems the HA database is working without having a shared memory area
> being specified. Any help available regarding the following questions:
>
> - What is the purpose of the shared memory ?
This allows you to have multiple HADB nodes in a host machine and helps
with performance.
> - Why is there no error showing up ?
If you are running HADB on a separate machine or one per machine, that
may still work without any errors IIRC - I am not very familiar with
the inner workings of HADB to comment about errors.
> - What are the ramifications if shared memory is not configured ?
On a single host with multiple HADB nodes, performance would probably be
slower - should be no impact if a single HADB node is running on a host.
> - What are the ramifications not being able to set the real time
> priority for NSUP
> due to be running in a local zone ?
I unfortunately do not have an answer but have forwarded your question
to a contact from the HADB team who may be able to answer the question.
> - Are all of these performance related ? Would it just impact the
> availability rate ?
I believe these are mostly performance related. The NSUP process's
realtime priority setting enables this process to have priority in CPU
allocations to that non-availability of HADB instances is detected
quickly even when the host CPU is busy with other tasks. Not having that
setting marginally affects the ability to detect failures of HADB nodes
quickly.
I dont know if you have already read through the High Availability
Administration Guide but if you have not, this particular page has
details of the above configurations
http://docs.sun.com/app/docs/doc/820-4341/abdcw?l=en&a=view
Aside from the above, I have a couple of suggestions:
1. I'd suggest you move to at least GlassFish v2.1.1 as that release has
many bug fixes (not specifically to HADB but is generally more stable) -
or move to the latest 2.1 patch level if you are a support customer
2. If it is not critical for your application use case to have the level
of reliability of HADB (and the accompanying 5 nines availability), and
you can afford to tolerate some risk of session loss (such as losing
sessions when both primary and replica GlassFish instances fail in a
cluster of more than two instances), then you may want to look at the
in-memory replication option that is available as the "replicated"
session persistence type option with GlassFish v2.x and in the upcoming
3.1 release, as the in-memory replication option has significantly
better performance.
Please let us know if you have further questions.
Shreedhar
> Thanks in advance,
>
> Peter