- 17.9K All Categories
- 3.4K Industry Applications
- 3.4K Intelligent Advisor
- 73 Insurance
- 537.3K On-Premises Infrastructure
- 138.6K Analytics Software
- 38.6K Application Development Software
- 6K Cloud Platform
- 109.6K Database Software
- 17.6K Enterprise Manager
- 8.8K Hardware
- 71.2K Infrastructure Software
- 105.3K Integration
- 41.6K Security Software
Make CRS cman-"aware"
This idea is an example how the situation described in
Integrating Connection Manager (CMAN) into a RAC+SCAN Environment (Doc ID 1556300.1)
could be solved:
The goal is to avoid cman configurations with source based routing (source_route=yes), instead make the instance register the service(s) at cman directly.
As this approach is more centralized and hides complexity from the client it's my preferred configuration.
The current problem is the lack of awareness of CRS stack about the possible existance of cman(s). So crs agent will not register the cman in REMOTE_LISTENER - and if REMOTE_LISTENER is set manually by a DBA, the configuration is not flexible anymore.
To implement a proper configuration, several resources must be defined. Most of these can be done nowadays with customized resources, but there are some changes required on existing agent activity.
One obvious requirement is a "cman" resource. To be precise, it can be divided into 3 parts:
first a cman-ip
this can be any ordinary vip you can create already. If desired even an existing vip can be used, but this will make dependencies more complex.
It should be part of a network, as all vips are.
quite similar to the current lsnr resource - with it's obvious dependency to a vip.
whereas these 2 resources are optional in a cluster configuration (if the listener is started somewhere else, there is no reason to configure them)
a cman-check (maybe there are better names)
is required for the configuration. It's purpose is to connect to an existing cman (IP:PORT) and check if it's healthy.
cman-check resources should belong to a cman-pool.
all cmans in this pool are used to serve the same set of client connections - several cmans for availability reasons.
It needs to be assigned to a "network" as a proper registration of the correct local_listener is required in environments with multiple networks and multiple listeners.
Until now we do have some resources for cman, but no link to any instance.
I'd like to add cman-pools as possible configuration options for a service:
srvctl add service -db <db_unique_name> -service <service_name> -crs-pools "crs_pool_east:crs_pool_west"
This requires the crs agent to update the remote_listener config for every instance where the service goes up/down.
(this particular step I do not know how to implement in current crs stack).
Even it seems over-complicated at first sign, those resources and changes should bring peace in a complex configuration with cman and crs.