Anonymous_User Absent Member.
Absent Member.
1192 views

Clustering NDPS without shared storage

Is is possible to cluster NDPS without using shared storage?

The NDPS\resdir seems pretty static and could easily be kept in sync with
another server.
I'm not sure about the database however. I think the command line options
can specify a local volume for it, but not sure what it holds and whether it
would need to be kept in sync. Lost print jobs during a fail-over are not
an issue.


- Jim


0 Likes
4 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Clustering NDPS without shared storage

The Broker (responsible for the resdir directory) would be easy to
cluster. In fact, you would not make the broker fail over, but simply
create a separate broker for each node, but make sure they have the same
resdir.
The NDPS Manager however needs a shared volume for clustering. Most of the
information the Manager needs to work is in the database and the Manager
object contains the information to locate volume and directory for the
Manager database. If you load a Manager on a different server, the Manager
tries to move the database from the old server to the new server.

--
Marcel Cox (using XanaNews 1.17.6.6)
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Clustering NDPS without shared storage

If I load the manager on another server and answer the prompts (or use
command line options) to move the database when the original server is
unavailable, what happens? Does the manager create a new database? What
would be lost? I thought the printer agent configuration was in eDir.

- Jim


"Marcel Cox" <cimetmc@myrealbox.com> wrote in message
news:bMxyf.245$En3.223@prv-forum2.provo.novell.com...
> The Broker (responsible for the resdir directory) would be easy to
> cluster. In fact, you would not make the broker fail over, but simply
> create a separate broker for each node, but make sure they have the same
> resdir.
> The NDPS Manager however needs a shared volume for clustering. Most of the
> information the Manager needs to work is in the database and the Manager
> object contains the information to locate volume and directory for the
> Manager database. If you load a Manager on a different server, the Manager
> tries to move the database from the old server to the new server.
>
> --
> Marcel Cox (using XanaNews 1.17.6.6)



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Clustering NDPS without shared storage

Jim Lawson wrote:

>
>If I load the manager on another server and answer the prompts (or use
>command line options) to move the database when the original server is
>unavailable, what happens? Does the manager create a new database? What
>would be lost? I thought the printer agent configuration was in eDir.


A lot of NDPS information is only stored int he database, and not in the
pritner objects. This for example includes the gateway load strings and
other printer configuration information. Without this information, NDPS
will simply not work at all.
However for security reasons, the NDPS Manager makes backup copies of its
database to the NDS. By default, this is done once every night.
In theory, the NDPS Manager could restore the database from NDS instead of
copying it from another server. I don't know however if this procedure
could be automated.
Also, if you would have make configuration changes to a printer or create
a new printer during the day and the restore the database from NDS the
same day, the changes would be lost.

--
Marcel Cox (using XanaNews 1.17.6.6)
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Clustering NDPS without shared storage

I tried is on a test server. Using the /DBVolume=.srv_volume.ou.o. If the
database does not exist on the volume specified, the manager quietly created
a new database and loaded. It looks like it restored the database from the
NDS backup. I would probably need to remove any existing database files
before loading the manager. A couple of "toolbox" commands in the cluster
scripts should work.

Restoring the database from backup, it appears I only lose recent
configuration changes and pending print jobs. This is not a concern as I'm
looking at this for disaster recovery purposes. The cluster resouce would
be configured for manual fail-over.

- Jim


"Marcel Cox" <cimetmc@myrealbox.com> wrote in message
news:Kyxzf.1129$MB5.139@prv-forum2.provo.novell.com...
> Jim Lawson wrote:
>
>>
>>If I load the manager on another server and answer the prompts (or use
>>command line options) to move the database when the original server is
>>unavailable, what happens? Does the manager create a new database? What
>>would be lost? I thought the printer agent configuration was in eDir.

>
> A lot of NDPS information is only stored int he database, and not in the
> pritner objects. This for example includes the gateway load strings and
> other printer configuration information. Without this information, NDPS
> will simply not work at all.
> However for security reasons, the NDPS Manager makes backup copies of its
> database to the NDS. By default, this is done once every night.
> In theory, the NDPS Manager could restore the database from NDS instead of
> copying it from another server. I don't know however if this procedure
> could be automated.
> Also, if you would have make configuration changes to a printer or create
> a new printer during the day and the restore the database from NDS the
> same day, the changes would be lost.
>
> --
> Marcel Cox (using XanaNews 1.17.6.6)



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.