4. DNS Advantage Business Rules Web Services - GoogleCode

outstandingmaskΔιαχείριση Δεδομένων

29 Νοε 2012 (πριν από 4 χρόνια και 11 μήνες)

282 εμφανίσεις








DNS Adv
Appliance Replication

Engineering Document





Creation Date:
Oct
, 200
9

Last Updated:
March 16, 2013








DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=
2
=
c楬i湡浥m=
=
=

Table of Contents

1.

Document Overview

4

2.

Overview

6

3.

Core database changes

10

4.

DNS Advantage Business Rules Web Services

11

5.

DNS Advantage

Business Rules Downloader

14

6.

Leaf Database Specifications

15

7.

Proxy Cache Loader change specifications

16

8.

Web Service Content Format

16

9.

Release Documentation Requirements

17

10.

Requirements Traceability

18





Document Control



Revision History


Date

Version

Revision Description

Author

22
/1
0
/0
9

1.0

Draft for Commen
t

Rajesh Nair





DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=
3
=
c楬i湡浥m=
=
=

Document Approvals


Department

Representative

Approval
Date

Engineering (Impetus)

Alok Agarwal


QA(Impetus)

Bhushan Joshi


Engineering (NeuStar)

Aydin Kaya


Product Management (NeuStar)

John Crotty


Operation Support (NeuStar)

Gaur
ang Mehta


Databases(Impetus)

Pranabesh Sarkar


Databases (NeuStar)

Malini Saxena



DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=
4
=
c楬i湡浥m=
=
=


1.

Document Overview


1.1

Introduction

This document is the
Engineering

Specification for the
replication of DNS advantage Business rules from
core to appliance leaf database
.




1.2

Assumptions

The assumptions made in preparation for this document are listed below.


#

Assumption

1.


All the data required for leaf database is captured in audit tables. If not, we will need to add an audit
table

or corresponding columns in audit table
s
.

2.


The failure scenario of leaf database on the appliance getting corrupted has not been considered in the
design. The base assumption here is it will be better to replace the appliance in this scenario.

3.


It is assumed that appliances boxes shall have
sendmail
/postfix

configured and the syslog on
appliances box shall be configured to send all CRIT logs to a
n

operation support email alias.

4.


It is assumed that monitoring of appliances boxes and its component shall be handled by operation

support. Enginee
ring shall provide a cheatsheet for common problem along with the ability in the
product to notify operation support for replication problem.



1.3

Issues

Unresolved issues are noted in the table below. Decisions that close issues appear in the Resolution
c
olumn, noting what resolution was reached that closes the issue, and identifying any meeting minutes or
other document(s) that support the decision. Individual issues specific to individual work request are
document in the individual enhancement sections.


#

Issue

Resolution

Status

(Owner)

1.


Need to have canned requirements
for appliance replication


John Crotty

2.



Will the customers have access to
the appliance filesystem? If yes, to
what extent?


Joel Sciandra

3.


Need to have a dev appliance box
and need
to evaluate the libpg C
library for PostgreSQL access from
PCL.


Joel Sciandra

4.


What is the plan for updating the
database schema in future releases?

Is it required to bring this in scope
of this release?


Joel Sciandra

5.


What shall be the sub

domain

Joel Sciandra

DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=
R
=
c楬i湡浥m=
=
=

#

Issue

Resolution

Status

(Owner)

wh
ere web

services shall be hosted?

6.


What shall be the order of tables to
be replicated? The dependency
hierarchy of tables need to be
analyzed


Pranabesh Sarkar




1.4

Documents Referenced

#

Document and Location


TBD


Get the Appliance repl
ication added in MRD and refer the MRD here




DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=
6
=
c楬i湡浥m=
=
=


2.

Overview

This document describes a
web services
solution
for
replicating
DNS Advantage
business rules data from
core database to appliance leaf database
.

The solution proposes to replace Oracle materialize
d view based
replication with web services which provide updates to appliances for appliances.





Features of the proposed design include:


Firewall issue
:

Appliances fetch the business rules update over HTTPS (port 443) which is
commonly allowed throug
h firewall
.

Reduced Exposure to System Outages:

The solution does not require continuous connection between
appliance and core database infrastructure. The appliances can fetch the updates after
network connection is resumed without any intervention

(unli
ke present Materialized view
solution)
.

Compressed Data Transfer:

Wherever required, gzip encoding would be used to compress the web
service response

Configurability of each
appliance
:

Each appliance can be configured to retrieve data at its own schedule
a
nd can also be triggered to forcefully retrieve updates.

Cache
coherency

on core database:
Since appliances would be hitting the core db for updates, most of
the updates would be cached
on

the core database resulting in improved performance.

Tracking faile
d updates:

The business rules downloader component would insert the data into an
intermediary table and the data
would be moved to actual tables
after downloading the data.
This process would record any failed updates and alert the system if an appliance
f
ails

to
update a particular record.

Security:

All network transfer takes places over SSL to secure the replicated data. Also it is proposed
to keep the credentials of the database in encoded files to prevent customers to gain access
to leaf database

Time z
one

independent
:

There is no dependency on appliances to have synchronized clock with
NeuS
tar cloud for it to function correctly. Also appliances can reside in any
time zone
.

Appliance monitoring:
With the proposed design it would be easy to monitor any ap
pliance which has
not connected to NeuStar cloud for an elongated period of time without requiring
connecting to the appliance box itself, The Core database shall record the last connected
timestamp of each appliance



A weakness of the solution is that th
e
increased hit on core database with the increase in number of
appliances.

This can however be mitigated by deploying a load balancer which load balances web service
request to the 4 core databases. Looking at the number of appliances and data size presen
tly however, this
is not required for the initial release.



2.1

Requirements

The requirements for this capability are documented
ISSUE: where
?



DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=
T
=
c楬i湡浥m=
=
=

2.2

Deviations from the Requirements

This section documents areas where the proposed implementation intentionally devi
ates from the
requirements.


#

Deviation





2.3

Limitations

This section lists the limitations that have been identified in the proposed implementation.


#

Limitation

1

The replication time proposed here can be huge in case where appliance is disconnected
from NeuStar
cloud for an elongated period of time. In any case, the replication window will be slightly higher than
current materialized view based replication.

2

The proposed design can increase the hit on the core database as the number of appliances
increase.
The proposed design should work fine for 100 appliances configured to poll every 10 minutes with
around 1000 record updates per day.
This limitation can be mitigated further to an extent by deploying
web services

on each of the 4 core database a
nd using HTTP
load balancer
. But any further increase in
data load would require design reconsideration.


DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=
U
=
c楬i湡浥m=
=
=


2.4

Risks

This section lists the risks that have been identified.


#

Risk

1

The performance tuning of PostgreSQL has not been evaluated and assumed to

be not of major impact.

2

PostgreSQL being a new addition to the whole system can be a potential risk element. Although we do
not anticipate any major problems in replicating data from oracle to postgreSQl, but late discoveries in
data incompatibility mi
ght cause some additional work. This is identified as a low
-
risk and should affect
the timeline only and not the feasibility.


DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=
9
=
c楬i湡浥m=
=
=




2.5

Affected Components

The purpose of this section is to give an overall indication as to the changes that are being proposed i
n this
document.



Core Database Site
Appliance Node
DNS
Advantage
core DB
Business Rules Web Services
Proxy
Server
Business
Rules
Downloader
DNS
Advantage
app leaf DB
(
postgreSQL
)
Proxy
Cache
Loader
Memcache
JDBC Oracle
HTTP
/
SSL
JDBC PostgreSQL
libpq
libmemcached


Figure
1



High Level
Components

of the Solution



The
DNS Advantage
Core DB

is a component of the DNS Advantage v2.5 solution.
It
stores the business
rules for mo
e
ntizing
DNS queries along with reporting and statistical data
.


The
Business Rules Web

Services
is a
new
component of the DNS Advantage v
3.0

solution.
It
is a

RESTful
web

services hosted on a

JBoss application server. It will serve request from appliance by provi
ding
updates for each of the
existing materialized view
.


The
Business Rules Downloader

is
a
new component
on the appliance node
that runs via cron to periodically

(default 10 min) call each of the web services and insert the updates(if any) into the leaf
database
.

The
initial data would be replicated at the time of provisioning of appliance using flat files(csv).


The
DNS Advantage app leaf DB

is the database residing on appliance node with similar schema as that of
core database. The leaf database shall b
e a PostgreSQL instance.


The
Proxy Cache Loader( PCL)
is component that
updates the memcache by retrieving the updates from leaf
database. For appliance, PCL shall be modified to support fetching from PostgreSQL database.


Memcache and Proxy Server are ex
isting components and shall not be affected with this replication design.

DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=

=
c楬i湡浥m=
=
=


2.6

Data replication flow

In general
,

data replication flow would be in the following order with the proposed design



Base table of Core database



Audit table of Core database



Load table
of Leaf database



Audit table of Leaf database



Base table of leaf database

TBD: Replace the above with a flow diagram



Triggers are already in place to move data from base table to audit tables of core database.

Web services are new components which will m
ove data from Audit table of core database to load table of
leaf database.

A stored procedure in leaf database shall move the records from load table to audit table and then finally
to base table.


Following are the tables identified which needs to be repl
icated

through webservices




BI_AUDIT_BL_GDATA



BI_AUDIT_BL_GSETTINGS



BI_AUDIT_BLOCK_LIST_DATA



BI_AUDIT_BLOCK_LIST_GDATA



BI_AUDIT_BLOCK_LIST



BI_AUDIT_CATEGORIES



BI_AUDIT_CATEGORY_DATA



BI_AUDIT_CG_SETTINGS



BI_AUDIT_NETWORK_CATEGORIES



BI_AUDIT_NETWORK




BI_AUDIT_NXDOMAIN



BI_AUDIT_SHORTCUTS_DATA



BI_AUDIT_SHORTCUTS



BI_AUDIT_TYPC_GSETTINGS



BI_AUDIT_TYPO_CORR_GDATA



BI_AUDIT_TYPO_CORRECTIONS



BI_AUDIT_WHITE_LIST_DATA



BI_AUDIT_WHITE_LIST


3.

Core database changes

3.1

Request Logging changes

Proxy Nodes shall b
e modified to add following columns

Last_updated_datetime : timestamp when this updates were sent to this node

Last_requested_datetime : timestamp when a request was received for updates from this node.



DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=

=
c楬i湡浥m=
=
=

4.

DNS Advantage
Business Rules Web

Services

This sect
ion deals with the
webservices required to replicate core database changes to leaf database


4.1

Web service

d
eployment
s
pecifications

This section deals with the
deployment

specifications for
t
he
web services
.


Specification
Number

Requirement
Number(s)

Desc
ription

BRWS
DEP
-
1


Web Services shall be deployed in JBoss 4.2.2

and need to have read
-
only
access to the core database.

BRWS
DEP
-
2


JBoss shall be configured to serve only to trusted clients. It is required to
generate client certificate for each applia
nce at the time of provisioning and
add the same to application server’s trusted certificate store.

The server should send a 403 status code to any client which is not using a
trusted certificate

BRWS
DEP
-
3


Web

service shall be deployed on a subdomain of
dnsadvantage.com
domain.
TODO: Finalize the subdomain to be used.Meanwhile use
brws.dnsadvantage.com as a placeholder for now

BRWS
DEP
-
4


JBoss shall be configured to serve over HTTP/SSL(HTTPS) only.

BRWS
DEP
-
5


Appliances should be able to connect to
JBo
ss
on port 443

BRWSDEP
-
6


Another instance of JBoss shall be deployed as a failover and the brws
subdomain shall be configured to resolve to failover system if the primary
instance is down



DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=

=
c楬i湡浥m=
=
=

4.2

Web s
ervice

functional specification

This section deals with
the
functionality of the replication webservice.

Specification
Number

Requirement
Number(s)

Description

BRWSFUNC
-
1


Each
audit
table
,

as defined
here
,
shall be modeled as a

RESTful
resource with the URI
.



https
://brws.dnsadvantage.com/businessrules/updates/
<audit_table
>


BRWSFUNC
-
2


The replication webservice shall support only GET operation

BRWSFUNC
-
3


The service shall accept a mandatory request HTTP header
User
-
Agent.

The client is expected to send the node
name in the User
-
Agent
field in the following format

dnsadvantage
-
<appliance nodename>


Eg. dnsadvantage
-
rdns1geapp1


BRWSFUNC
-
4


The service shall accept an optional request HTTP header
If
-
Modified
-
Since
.
The client should send the timestamp of the last
received update in
the following format


Eg. Sat, 29 Oct 1994 19:43:31 GMT


If not sent the
server shall send all the records of the base table.

The timestamp value should be the one sent by the server in the ETag
response header

BRWSFUNC
-
5


The web servi
ce shall load from a configuration file the map of audit table
along with tits SELECT sql. On receiving the request , it will fire the
corresponding SQL to fetch the updates.


BRWSFUNC
-
6


If updates are available
, the resultset would be transformed into
d
nsarep
format

(the format is described
here
)

and send it out to the client with the
status code of
200
. It shall also update th
e last_updates_datetime of
Proxy_nodes table with current timestamp
.


Server shall send the timestamp of the last
update as ETag header.

BRWSFUNC
-
7


If updates are not available, send the status code of
304

with no body

BRWSFUNC
-
8


If
after formatting the response size is greater than
20K

and if the client
accepts gzip encoded data (Accept
-
Encoding : gzip) , then compress the
response body using gzip compression method
along with proper response
header set
Content
-
Encoding : gzip
.

BRSWFUNC
-
9


The server should log the request timestamp of each appliance on the core
database.

BRSWFUNC
-
10


The server shall update the Proxy_Nodes table last request_datetime for
every r
equest from a given appliance with current timestamp.

BRSWFUNC
-
11


The server shall set the Content
-
Type header as
application/x
ml

DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=

=
c楬i湡浥m=
=
=


DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=

=
c楬i湡浥m=
=
=


5.

DNS Advantage Business Rules Downloader


5.1

Functional

Specifications

This section deals with the
business rules downloade
r application on the appliance node
.


Specification
Number

Requirement
Number(s)

Description

BRDFUNC
-
1


The downloader program shall
be started by cron

BRDFUNC
-
2


The downloader program shall load the following configuration parameters
from /etc/DNSA2.5/
conf/dnsaBRdownloader.conf.



Leaf database JDBC URI


Leaf Database username


Leaf Database password

ISSUE:
Do we need to base 64 encode this conf file to
hide the database
credentials from the customer
? Will the appliance customer have access

to
the appliance filesystem?


The downloader program shall read the node name from the following
conf file

/etc/DNSA2.5/conf/dnsaPServer.conf

BRDFUNC
-
3


The downloader shall sequentially fire HTTP request for updates for
each
of the
resources

(as defined

here
)

in the given order
.


The downloader shall set the appliance nodename in the User
-
Agent
request header and set the last timestamp from the dnsaPCLupdates.dat
while firing the requests

BRDFUNC
-
4


No co
nnection to web service shall be logged at CRIT level in syslog
prompting an email to operation support.

BRDFUNC
-
5


On receiving updates (status code = 200) , downloader shall
perform the
following processing

-

check if the content has been compressed (
Content
-
Encoding = gzip)
and uncompress the content.

-

The response shall be stored as separate xml files on the leaf database
under /opt/DNSA2.5/dnsaBRdownloader/downloads directory.


BRDFUNC
-
6


The downloader shall transform the xml file(s) (if any) in
/opt/DNSA2.5/dnsaBRdownloader/downloads into a single file insert
SQL queries and delete the successful xml files.

Failure in transformation shall be be moved to error directory and logged
into syslog at ERR level

BRDFUNC
-
7


Downloader shall then execute
all the insert queries in one database
transaction and on success commit the transaction.

On success of transaction, dnsaPCLupdates shall be updated with the
timestamp as received
from ETag header of the response
.

On error , the error needs to be logged at

CRIT level in syslog

prompting
an email to support team
.


DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=

=
c楬i湡浥m=
=
=

Specification
Number

Requirement
Number(s)

Description

BRDFUNC
-
8


Any error in downloader not able to process data shall be logged at ERR
level



6.

Leaf Database Specifications

This section deals with the
leaf database changes

that runs on the
applianc
e node
.


Specification
Number

Requirement
Number(s)

Description

LEAFDB
-
1


Leaf database on the appliance node shall be a PostgreSQL database
instance

LEAFDB
-
2


PostgreSQL startup and shutdown needs to be included at the time of
appliance box startup and
shutdown.

LEAFDB
-
3


The schema shall be similar to existing leaf database except that all
materialized views shall be tables

with the same name as its synonyms
.

LEAFDB
-
4


In addition to the above, the leaf database shall have load tables for each of
the

audit
tables

with the same schema as audit tables and no primary key on
load tables
.

LEAFDB
-
5


The leaf database shall have an additional stored procedure
load_core_data

which when called shall move the records from load
tables to the
audit table and corr
esponding base

table
s. All failed records
shall be logged in an error table for further manual analysis. The stored
procedure shall return 0 on success and non
-
zero code on error.


ISSUE: The order of loading of table is yet to be analy
z
ed

LEAFDB
-
6


At th
e time of provisioning of appliance, leaf database shall be populated
with core data using core database flat files.


DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=

=
c楬i湡浥m=
=
=


7.

Proxy Cache Loader change specifications

This section deals with the
PCL component

that runs on the proxy server

node
.


7.1.1

Build Specific
ation


Specification
Number

Requirement
Number(s)

Description

PCLMAKE
-
1


PCL Makefile shall be modified to build two separate instances of the
program
,once by passing in APPLIANCENODE and one without.

PCLMAKE
-
2


Makefile shall be modified to link to lib
pg for appliance node and
libsqlora8 for hosted nodes



7.1.2

Functional Specification


Specification
Number

Requirement
Number(s)

Description

PCLFUNC
-
1


All the SQLs in the codebase shall be surrounded by #ifdef
APPLIANCENODE. If the APPLIANCENODE make param
eter is
defined , PostgreSQL version of sql shall be used else oracle version

PCLFUNC
-
2


The db_connect and db_disconnect functional shall be modified to
conditionally include the oracle and postgreSQL db connection and
disconnection code.





8.

Web Servic
e Content Format

8.1

Format Design Criteria

For the web

service content format , following are the design criteria



The format should be as lightweight as possible and its parsing and formatting should not be heavy



The format needs to model a two dimensional da
taset.



The format should be able to specify the column name also

in order for the downloader to insert
into load tables


8.2

Format Specification


Based on the above criteri
a
, an xml based format is proposed for the content format. Also it is
recommended to us
e a SAX parser (instead of a DOM parser) to reduce the formatting and parsing
overhead.

Also it is required to use a parser which guarantees the order of elements.



DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=

=
c楬i湡浥m=
=
=




Given below is an example of Network service content to explain the format


<?xml encod
ing=”UTF
-
8”?>

<BusinessRules name=”Network”>

<Tuple>

<network_id>
123
</network_id>

<parent_id>0</parent_id>

<iprange_cidr>220.220.0.0/16</iprange_cidr>

<
is_network_queries_enabled
>1</
is_network_queries_enabled
>

<
nqe_ipaddress
>202.203.204.205</nqe_

ipaddress

>

<nd_date>23 Oct 2009 10:31:41 GMT</nd_date>

</Tuple>


<Tuple>

<network_id>124</network_id>

<parent_id>0</parent_id>

<iprange>156.154.70.1</iprange>

<!

iprange_cidr absence signifies the null value
--
>

<
is_network_queries_enabled
>1</
is_network_queries_en
abled
>

<
nqe_ipaddress
>202.203.204.205</nqe_

ipaddress

>

<nd_date>23 Oct 2009 10:31:41 GMT</nd_date>

</Tuple>


</BusinessRule>


8.3

Alternate solution

Json was also considered as a format and although it is a much more terse format, the following factors
went i
n favour of xml.



Availability of mature Json parser: The JSon parsers available at present are not as mature as xml
parsers. At the moment, the parser available are Jackson, Noggit and Json lib.



Transformation ability : Downloader will require the ability
to transform the response into SQL
queries. The transformation ability available
in J
son parser is limited.




9.

Release Documentation Requirements

The release documentation needs to fully describe the configuration for the file transfer.



Specification
Num
ber

Requirement
Number(s)

Description

DNS Advantage Appliance Replication

Version: 1.
0

Engineering Document


Date:
3/16/2013



Confidential

=
䑯⁎潴⁄=s瑲楢畴i
=
ma来=

=
c楬i湡浥m=
=
=

Specification
Num
ber

Requirement
Number(s)

Description

RELDOC
-
1


Deployment document for each component including configuration

RELDOC
-
2


Support c
heat

sheet for operation support to debug common problems



10.

Requirements Traceability

This section maps the requirements to

the specifications.


Requirement
Number

Specification
Number(s)

Description
, Comments, or Limitations





ISSUE:
This
s

will need the requirements to be elicited.