Highlighted
Respected Contributor.
Respected Contributor.
268 views

Horizontal Scalability for NA DR Environment

I'd like to set up NA for Disaster Recovery. I have the following environment:

Primary Location:
NA1 - NA 10.40 Linux RHEL 7.5 VM  - Standalone install of NA.
Primary DB Server running Oracle 12.c with "na" instance in Dataguard ( to Remote DB server in DR location )

DR Location ( about 200 miles away): 
NA2 NA 10.40 Linux RHEL 7.5 VM   -  Standalone install of NA. 
DB Server running Oracle 12.c  with "na" instance in  Dataguard replication 

I have read the post:

https://community.microfocus.com/t5/Network-Automation-User/NA-Multimaster-vs-Horizontal-Scalability-for-HA-Environment/m-p/560153

The setup I"m interested in is,  as Chris Powers said:

In a nutshell, DR works as this:

NA1 Core & DB at location 1 are active    - Currently have this

NA2 Core & DB at location 2 are inactive / down - DB replication is happening in background.   - WANT TO HAVE THIS  , only have DB replication part.

Say location 1 has an issue, you bring Core 1 and DB 1 down, bring Core 2 and DB 2 up.  So, you'd need some DB help (or scripting / automation).  The NA side of things - it's really easy to do as long as you have server / proxy access.  

Even if you had two cores up, you'd have some work to do if say Core 1 dies as you'd want to make sure that Core2 knows Core 1 isn't able to participate.  

I've checked the online documents but it's not clear what I need to do for the NA side of things.  Could someone tell me the details to complete the setup for NA1 and NA2 ?

Thanks,

wbrunc 

0 Likes
7 Replies
Highlighted
Respected Contributor.
Respected Contributor.

Re: Horizontal Scalability for NA DR Environment

I've found the  NA-Node-HS-MM-10.40-Eng.zip that contains the OracleInitialSetup.sql script to enable HS between 2 NA cores. I've set  my variables as per the script :

-- BEGIN VARIABLE REPLACEMENT SECTION
--
database_name := 'NA';
database_server_name_or_ip := 'mtdbpa1';
core_server_name_or_ip_1 := 'napa1';
core_server_name_or_ip_2 := 'nasa1';
--
-- END VARIABLE REPLACEMENT SECTION

 

However, when I run the script I get:

SQL> @/tmp/OracleInitialSetup.sql
UPDATE RN_CORE SET
*
ERROR at line 19:
ORA-06550: line 19, column 8:
PL/SQL: ORA-00942: table or view does not exist
ORA-06550: line 19, column 1:
PL/SQL: SQL Statement ignored
ORA-06550: line 32, column 13:
PL/SQL: ORA-00942: table or view does not exist
ORA-06550: line 32, column 1:
PL/SQL: SQL Statement ignored
ORA-06550: line 56, column 57:
PL/SQL: ORA-00942: table or view does not exist
ORA-06550: line 56, column 1:
PL/SQL: SQL Statement ignored

Can someone tell me what I may be missing ?

0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

Re: Horizontal Scalability for NA DR Environment

I've been told that since my initial NA installations were Standalone, I don't have RN_CORE table. How can I fix this so the sql script runs ?

Thanks

0 Likes
Acclaimed Contributor.
Acclaimed Contributor.

Re: Horizontal Scalability for NA DR Environment

Hi, 

The RN_Core issue, do you have NA running currently? The NA instance you're trying to connect to with the script? Is that up, is the DB up? I get the impression you have more than one NA instance? So, did you install two single core NA instances or am I not following you?

If you have one core and that core and db are up, you should be able to run the scripts and connect to it.  Let's focus on that first, then go from there.  Perhaps the port is different, credentials not as you expected, or not up, etc. If NA is up / running, you can see the ID and port and db info - look here:

your_NA_URL/monitordetails.htm?diag=com.rendition.monitor.DatabaseMonitor

lines
lines
Database type: Oracle
Database catalog:
Database URL: jdbc:oracle:thin:@//key_DB_Info:port#/key_DB_Info
Database user name: NA_ID_IS_HERE
lines
...

Perhaps try to connect to the DB using SQL Developer or your tool of choice first - can you log in?  If you can log in, then ok, cool - that's good.  Take a look at the script, maybe there's a typo (missing ';') or similar?  Maybe try the IP as DNS isn't resolving as expected?  

But let's get this first handled...

I've attached a screen snip of a single core db that a friend of mine provided (ours are multi-core and wanted it to be same as yours). You "could" also  see this in the same screen as you get the credentials, just scroll down a bit.  🙂  

As for the documentation,

have you looked at this for architecture info:

https://docs.microfocus.com/itom/Network_Automation:10.40/Install/Deployment_Arch

and here for installing in HS / multi-core environment:

https://docs.microfocus.com/itom/Network_Automation:10.40/Install/NA_HS/Configuring_Horizontal_Scalability/Configure

and for DR, here:

https://docs.microfocus.com/itom/Network_Automation:10.40/Administer/Appendix/App_HS_WAN

BTW, why10.40?  Is this an old installation or new?  If new, really recommend moving to 2019.05 - it's in your best interests as an admin...  If it is old / existing, then OK, gotcha - you have what you have and that's that.  Been there, done that.  Though you might want to look into seeing if you can upgrade straight to 2019.05.  Can't recall if that jump is doable with one straight upgrade or not (2019.05 was "special" release that let folks make multiple version hops in one jump but 10.40 might have been too new).  

I'm wondering if you just installed two separate one core NA instances and expect to "join" them.  Best to follow the steps above, as you'll see (read), even the DR core is connected and so it's not really separate.  Once you get connected, and script OK (connect to core #1) then think it'll make more sense.  

-Chris

 

 

0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

Re: Horizontal Scalability for NA DR Environment

Chris,
Thanks for responding.

Answers  to your questions.


1. The RN_Core issue, do you have NA running currently? The NA instance you're trying to connect to with the script?
Is that up, is the DB up?

Primary Location:
NA1 - NA 10.40 Linux RHEL 7.5 VM - Standalone install of NA. - Currently Up.
Primary DB Server running Oracle 12.c with "na" instance in Dataguard ( to Remote DB server in DR location ) - Currently Up.

DR Location ( about 200 miles away):
NA2 NA 10.40 Linux RHEL 7.5 VM - Standalone install of NA. NOT Running.
DB Server running Oracle 12.c with "na" instance in Dataguard replication - Currently Up.

I'm running the OracleInitialSetup.sql from the Primary DB Server .

2. I get the impression you have more than one NA instance? - Yes.

So, did you install two single core NA instances or am I not following you? Yes 2 single core instances. 

When the environment was initially built, we had completely separate Prod and Prod DR setups.
Each had their own NA core and DB server with an "na" instance.

We want to change the environment for DR purposes. So we've instituted ORacle Dataguard for the "na"
instance between the Prod and DR DB Servers. Now we'd like to "connect" the two NA Cores.

3.
https://na1/monitordetails.htm?diag=com.rendition.monitor.DatabaseMonitor
.
.
Database type: Oracle
Database catalog:
Database URL: jdbc:oracle:thin:@na1.xxx.xx.xx.xx:1521:na
Database user name: NAUSER
Database vendor: Oracle
Database version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
JDBC driver: Oracle JDBC driver
JDBC driver version: 12.1.0.2.0
.

4. This is an existing installation. We had to go with 10.40 because our other software was tested against this version. It would be a major undertaking to upgrade at this time.

The bottom line is I'm hoping this existing environment can be "converted" to a DR one.

Thanks,

wbrunc

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Horizontal Scalability for NA DR Environment

OK, well, I'll start with your last line and move from there...

I don't know of a safe way to convert your 2nd 1 core NA instance and DB over to DR.  There may be a way it can be done, but honestly, not sure it'd be easy, quick or solid.  In all honesty, it'd be quicker to just uninstall NA on that 2nd core and follow the HS process and have DR in mind.  

Someone else may have done this and have options / answers or maybe support / CPE could help, but for prod, I'd not recommend it.  I'd hate to have some lingering thing that you don't find until you switch over and need it and BAM! problems.  

All that said, you should be able to use the DB(s) you have as long as that 2nd single core hasn't updated it - just follow the HS steps and get that 2nd core talking with the first and (for now) both talking to the same DB.  Once that's done, you can follow the DR steps and should be all set.  

So, the the two databases are handled by Oracle replication and the two NA cores are covered by NA's replication.  

Does this help?  Granted, not sure of a way to just move your 2nd single core over but do you understand why and what needs to happen and how it'd work when complete?  

Hope this helps,

Chris

0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

Re: Horizontal Scalability for NA DR Environment

Chris,

Thanks this does help.

As you suggested,  I'd be better off reinstalling the second NA with the HS option as per:

https://docs.microfocus.com/itom/Network_Automation:10.40/Install/NA_HS/Configuring_Horizontal_Scalability/Configuring_a_Two_Core

.

Step 8 .

.

Enter 4 for secondary installations of NA without a database, for example, the second NA core server in a horizontal scalability environment. 

 

I'll givei it a try and keep you posted.

Thanks again,

wbrunc 

0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: Horizontal Scalability for NA DR Environment

What you were missing is the horizontal scalability bundle.  It contains the sql statements that will create the rn_core table and populate it.  The rn_core table is critical as it contains the resources that the scheduler references when assigning tasks to a server. In your explanation of what you want to do there are a few things that you will have to do when you want to failover since its not automatic at all:

1. You'll need to stop your Dataguard replication and change your redundant DB from RO to RW.

2. You have to set your core 1 and core two to inactive (either by the proxy or directly in the DB)

3. You have to set your core 3 and core 4 to active (either by proxy or directly in the DB)

4. You have to set any scheduled job to use the new resources (ie cores) manually, there is no automatic reallocation.

 

Have a nice day 🙂

Andy Kemp
I've lasted longer in the technology industry than most certifications.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.