DB2 Clustering

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Daniel G. Cantua

    DB2 Clustering

    We are thinking of starting to use clustering with our DB2 V8. I
    understand that with clustering when a node goes down that the other
    nodes will keep the database up for the users. What I would like to
    know is does this include if the node has a hard drive crash and the
    disks are not salvagable or just if the machine looses connection?
    And if a new machine is used to replace the damaged one how does it
    sync together? Any information on the subject will be appreciated.

    Daniel G. Cantua
    Los Angeles County - ISD
  • Serge Rielau

    #2
    Re: DB2 Clustering

    Daniel,

    Have you downloaded DB2 Stinger? Given that you are just "starting to
    look" you want to add HADR to your choices. Take peek :-)

    Cheers
    Serge
    --
    Serge Rielau
    DB2 SQL Compiler Development
    IBM Toronto Lab

    Comment

    • Steve Pearson

      #3
      Re: DB2 Clustering

      Cluster-based high availability tends to work by combining multi-ported disk
      devices,
      spare processing power, and a cluster manager (such as HACMP, MSCS, etc.).
      When
      a processor fails, the services that were running there (which could include
      a DB2 "node"
      aka processing "partition" ) are restarted in the spare processing facilities
      (which may have
      previously been idle, or may be already loaded processors that are set up to
      absorb
      additional workload in a failover). The disk resources associated with the
      failed node
      need to be accessible from the new node as well.

      Disk (media) recovery is not usually part of this picture. Other approaches
      are used
      for that, including RAID/mirroring and database recovery (restore and
      rollforward).

      HADR (high availability disaster recovery), mentioned by Serge, is a log
      shipping
      database replication feature. Such products are typically deployed to
      provide
      failover to both different processors and different disks. This can be used
      within
      a cluster, with *separate* disk resources, which is different from the usual
      configuration
      meant when someone refers to cluster-based HA. More typically, log shipping
      based HA is deployed between independent (not clustered) systems, either
      within
      one data center for "local" failover, or between geographically separated
      ("remote")
      systems for protection against whole site failures.

      Regards,
      -steve p.
      -------------------
      Steve Pearson
      DB2 UDB Development
      Portland, OR, USA


      "Daniel G. Cantua" <dcantua@co.la. ca.us> wrote in message
      news:6cca870b.0 405140838.582de 62d@posting.goo gle.com...[color=blue]
      > We are thinking of starting to use clustering with our DB2 V8. I
      > understand that with clustering when a node goes down that the other
      > nodes will keep the database up for the users. What I would like to
      > know is does this include if the node has a hard drive crash and the
      > disks are not salvagable or just if the machine looses connection?
      > And if a new machine is used to replace the damaged one how does it
      > sync together? Any information on the subject will be appreciated.
      >
      > Daniel G. Cantua
      > Los Angeles County - ISD[/color]


      Comment

      • Daniel G. Cantua

        #4
        Re: DB2 Clustering

        Steve,

        If we use HADR on two machines and one the machines is physical
        damaged or turned off, will the user be able to continue to work as if
        nothing happen. Or will they have to do some type of reconfiguration
        the the workstation. What we have are six sites in LA county that
        will need to connect to this DB. We were thing that clustering will
        take care of a disaster occurs. But it sounds like if we have two
        machines using HADR that both machines will mirror each other. Can
        this be used also for load balancing. Like I said I am new to this.

        Thank You For Your Help,
        Daniel G. Cantua
        Los Angeles County - ISD

        Comment

        • Blair Adamache

          #5
          Re: DB2 Clustering

          When the primary crashes and DB2 fails over to the secondary, the user
          will have to reconnect. The secondary will assume the IP address of the
          primary, so the user will just reconnect to the same database on the
          same instance (it will seem the same to the application).

          When DB2 Stinger ships, the reconnection will not be necessary.

          Daniel G. Cantua wrote:
          [color=blue]
          > Steve,
          >
          > If we use HADR on two machines and one the machines is physical
          > damaged or turned off, will the user be able to continue to work as if
          > nothing happen. Or will they have to do some type of reconfiguration
          > the the workstation. What we have are six sites in LA county that
          > will need to connect to this DB. We were thing that clustering will
          > take care of a disaster occurs. But it sounds like if we have two
          > machines using HADR that both machines will mirror each other. Can
          > this be used also for load balancing. Like I said I am new to this.
          >
          > Thank You For Your Help,
          > Daniel G. Cantua
          > Los Angeles County - ISD[/color]

          Comment

          • Steve Pearson

            #6
            Re: DB2 Clustering

            > If we use HADR on two machines and one the machines is physical[color=blue]
            > damaged or turned off, will the user be able to continue to work as if
            > nothing happen. Or will they have to do some type of reconfiguration
            > the the workstation. What we have are six sites in LA county that
            > will need to connect to this DB. We were thing that clustering will
            > take care of a disaster occurs. But it sounds like if we have two
            > machines using HADR that both machines will mirror each other.[/color]

            The results from the user's perspective would depend on specifics of the
            configuration and application. First, something or somebody (cluster
            manager software, a system administrator, etc.) must recognize that a
            failure has occurred and invoke the TAKEOVER HADR command.
            Once the standby takes over as new primary, the applications will need
            to reconnect. How exactly this happens depends somewhat on the
            application's own behavior. As Blair mentioned, in Stinger there
            will also be an ability to configure an automatic connection rerouting.
            In-flight transactions must roll back, but the client can be reconnected
            to the alternative server automatically. Other possible elements of
            the failover, such as moving IP addresses around and so on are out of
            HADR's control but may come into play with how the application
            behaves. HADR only makes the standby database available at the
            standby site after issuance of a Takeover command.

            Traditional in-cluster failover (not involving HADR) is another
            alternative, as I discussed before.

            [color=blue]
            > Can this be used also for load balancing.[/color]

            In the Stinger release, HADR does not provide for anything like this.
            What is most common with log-shipping database replication products
            (in which category HADR falls) is to provide for periodic consistent
            read access and/or periodic or continuous dirty read access to data
            at the standby site. We recognize the value of this kind of access, and
            it is high on our list of possible future enhancements to HADR.

            Other kinds of replication technologies, such as DB2 SQL Replication
            or, coming with Stinger, MQ Series based "Q" Replication, provide
            logical (vs. HADR's physical) replication, at object rather than database
            level, and the possibility of load balancing through either multi way
            replication (update anywhere) or consistent read on non-updated sites.
            Such features can also be employed in support of high availability, but
            with somewhat different failover characteristics .

            So you have plenty of choices! :-)

            Regards,
            -steve p.
            -------------------
            Steve Pearson
            DB2 UDB Development
            Portland, OR, USA


            Comment

            Working...