Db2 (On Premises and Cloud)

Expand all | Collapse all

DB2 HADR

  • 1.  DB2 HADR

    Posted Fri June 04, 2021 04:50 PM
    Hi,
    When implementing HADR with VIP is it necessary to have two NIC's? If we can configure using one NIC, are there any other drawback other than failure of the one adapter such as DB performance?

    ------------------------------
    Steven Drogoszewski
    ------------------------------


  • 2.  RE: DB2 HADR

    Posted Wed June 09, 2021 03:47 AM
    Hi Steven,
    In my experience sharing the one pair of NICs is usually sufficient. An exception to this would be when you are managing HADR using TSA where the second pair of NICs can help maintain quorum in the cluster especially if the NICs are communicating across different network routes. 
    Cheers

    ------------------------------
    Colin Chapman
    ------------------------------



  • 3.  RE: DB2 HADR

    Posted Fri June 11, 2021 01:04 PM
    Hi

    Use two NICs can be also useful to isolate the workload, e.g. in the 1st pair (public) you work with the application workload and in the 2nd pair (private) you work with HADR workload. The VIP will be part of the public pair naturally. And remember that HADR is a solution by database and not by instance. This is the default behavior when you use the db2haicu to configure the cluster.

    Hope this helped.

    Cheers,
    Skeff

    ------------------------------
    Daniel Skeff
    ------------------------------



  • 4.  RE: DB2 HADR

    Posted Fri June 11, 2021 01:17 PM
    We  will be implementing with two NIC's.
    We are following recommendations provided in this document:
    Db2 (On Premises and Cloud)



    Thank you for the response.




    ------------------------------
    Steven Drogoszewski
    ------------------------------



  • 5.  RE: DB2 HADR

    Posted Mon June 14, 2021 01:53 AM

    Hi Steven,
    I know this question very well! The IT guy, configuring your database server asks, why you really need a second card.

    Well, in times when we had physical machines, not only a machine could fail, but also a NIC. If you just have one and the NIC of the Primary fails, your Secondary has to become primary (but the former primary will not change state and hence you could get a so called split-brain situation as soon as the old primary machine becomes online again).
    If they have a second NIC to communicate over, such situations are much simpler to avoid.

    Also, as mentioned in your referenced best practices paper on page 7/8, one of the important things in a high performant HADR system is to reduce the latency of commit processing. E.g. if you run HADR in SYNC, an application commiting it's changes has to wait until the primary has written its transaction logs, the primary sends over the logbuffer to the standby, the standby has to write them to disk (and apply in parallel) before the standby acknowledges the logbuffer to the primary, which in turn can now return from the commit call back to the application.
    If you have a separate network for this communication, commit latency will be smaller than if you have to compete with all the data packages sent to the clients. Neglecting any backups and other traffic right now.

    Now today a lot of machines are virtualized and the VM host might have a twin channel NIC with bonding to the network to prevent outages and increase transfer. So assigning a second virtual NIC to your VM would send all the traffic over the same adapter. It neither helps you for preventing split brain, nor helping in bandwidth.

    So for a simple data base in an HADR cluster this might be sufficient. But if you have e.g. a high performance SAP database for thousands of users, you might want to have this extra x% in performance option.

    It depends. Your mileage will vary.



    ------------------------------
    Roland Schock
    Distinguished Engineer
    ARS Computer und Consulting GmbH
    Muenchen
    ------------------------------



  • 6.  RE: DB2 HADR

    Posted Sat July 03, 2021 06:27 AM
    In my view the issue described on this support page is under-advertised: https://www.ibm.com/support/pages/how-tsamp-cluster-gets-db2-split-brain

    One of my customers is currently investigation a situation where a short outage to the network backbone between two geographically separate HADR nodes caused a split brain, with TSA also assigning the VIP to the second node so that it was in fact present on both nodes simultaneously. With application servers local to both nodes this could be extremely dangerous.

    I don't think dual NICs would suffice in above scenario - with the network tiebreaker architecture, what is needed is a completely independent second network for HADR log shipping.

    Regards,

    Jeremy Rickard

    ------------------------------
    Jeremy Rickard
    ------------------------------



  • 7.  RE: DB2 HADR

    Posted Sat July 03, 2021 06:55 AM
    Excellent catch!

    ------------------------------
    Roland Schock
    Distinguished Engineer
    ARS Computer und Consulting GmbH
    Muenchen
    ------------------------------



  • 8.  RE: DB2 HADR

    Posted Wed July 07, 2021 01:03 PM
    Thank you Jeremy!

    ------------------------------
    Steven Drogoszewski
    ------------------------------