DPF failure to connect

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • chmmr

    DPF failure to connect

    Hi,

    I have a problem with a cluster of two nodes (A - instance-owner node
    and B - partition node).

    Everything (db2start, db2stop, db2 get dbm cfg...) works perfectly until
    I add the second node B in the db2nodes.cfg.

    So, my db2nodes.cfg looks like this - "0 <node A hostname0", and when
    I try to add the node B with "1 <node B hostname0", db2start reports a
    communication problem, and db2_all date reports connection refused on
    node A and node B.

    ..rhosts file is setup with "+ db2inst" to make it 'unsafe' and foolproof
    as possible.

    /etc/services file on both nodes is identical and is as follows:
    db2c_db2inst1 50000/tcp
    DB2_db2inst1 60000/tcp
    DB2_db2inst1_1 60001/tcp
    DB2_db2inst1_2 60002/tcp
    DB2_db2inst1_EN D 60003/tcp

    Maximum number of logical nodes is 4 (I presume there is nothing wrong
    in having a lower-than-max-number of nodes in the cluster?).

    Both nodes are on the same domain and can ping and tracerout perfectly
    each other in the first hop (I presume that means there is no
    "high-speed interconnection device" in between?).

    What have I done wrong?

    Thank you for your reply
  • Raj

    #2
    Re: DPF failure to connect

    Did you verify if the db2 home is mounted correctly on server B?
    Also Add the following two lines to .rhosts and save (with chmod 600):
    ServerA db2inst1
    ServerB db2inst1

    chmmr wrote:
    Hi,
    >
    I have a problem with a cluster of two nodes (A - instance-owner node
    and B - partition node).
    >
    Everything (db2start, db2stop, db2 get dbm cfg...) works perfectly until
    I add the second node B in the db2nodes.cfg.
    >
    So, my db2nodes.cfg looks like this - "0 <node A hostname0", and when
    I try to add the node B with "1 <node B hostname0", db2start reports a
    communication problem, and db2_all date reports connection refused on
    node A and node B.
    >
    .rhosts file is setup with "+ db2inst" to make it 'unsafe' and foolproof
    as possible.
    >
    /etc/services file on both nodes is identical and is as follows:
    db2c_db2inst1 50000/tcp
    DB2_db2inst1 60000/tcp
    DB2_db2inst1_1 60001/tcp
    DB2_db2inst1_2 60002/tcp
    DB2_db2inst1_EN D 60003/tcp
    >
    Maximum number of logical nodes is 4 (I presume there is nothing wrong
    in having a lower-than-max-number of nodes in the cluster?).
    >
    Both nodes are on the same domain and can ping and tracerout perfectly
    each other in the first hop (I presume that means there is no
    "high-speed interconnection device" in between?).
    >
    What have I done wrong?
    >
    Thank you for your reply

    Comment

    • Ian

      #3
      Re: DPF failure to connect

      chmmr wrote:
      >
      Both nodes are on the same domain and can ping and tracerout perfectly
      each other in the first hop (I presume that means there is no
      "high-speed interconnection device" in between?).
      >
      What have I done wrong?

      You need to have your sysadmin enable the 'login' service in
      /etc/inetd.conf (or equivalent if you're not on AIX).

      Comment

      • chmmr

        #4
        Re: DPF failure to connect

        Ian wrote:
        chmmr wrote:
        >
        >>
        >Both nodes are on the same domain and can ping and tracerout perfectly
        >each other in the first hop (I presume that means there is no
        >"high-speed interconnection device" in between?).
        >>
        >What have I done wrong?
        >
        >
        You need to have your sysadmin enable the 'login' service in
        /etc/inetd.conf (or equivalent if you're not on AIX).
        >
        Yes, we figured that one too, but then again only the primary node will
        start and secondary would say - Communication Error. In the logs we've
        found out that we have no license and db2lic reported DPF license
        "Violated".

        Now, does that mean that the secondary node wouldn't start due to
        license problem, or are we still screwing something up?

        Thank you in advance

        Comment

        Working...