1 / 21

Riccardo.Veraldi@cnaffn.it

DNS HA A multimaster DNS configuration for Disaster Recovery and Business Continuity environment. Riccardo.Veraldi@cnaf.infn.it. HA DNS General Concepts. It is a fundamental component of a Disaster Recovery strategy Objectives:

kanoa
Download Presentation

Riccardo.Veraldi@cnaffn.it

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DNS HAA multimaster DNS configuration for Disaster Recovery and Business Continuity environment Riccardo.Veraldi@cnaf.infn.it

  2. HA DNS General Concepts It is a fundamental component of a Disaster Recovery strategy Objectives: • Build a resilient DNS infrastructure able to guarantee the full functionality in case of “Disaster” in any of the INFN Computing centers. • The system should be able to modify the IP of a service also during the “down time” of a site hosting one of the authoritative DNS servers for the “INFN.IT” Domain. • In general INFN national services addresses are of this type: <ServiceName>.INFN.IT Riccardo Veraldi - Spring HEPiX 2013

  3. Current INFN DNS infrastructure ns1.garr.net ext-dns-2.cern.ch Primary name server for infn.it Domain AXFR AXFR INFN.IT Domain server2.infn.it AXFR dxcnaf.cnaf.infn.it Riccardo Veraldi - Spring HEPiX 2013

  4. DNS HA Architecture (single master) hostIN CNAME host.ha.infn.it. infn.it server2.infn.it AXFR host 60 IN A 193.x.y.z host 60 IN A 131.154.a.b dxcnaf.cnaf.infn.it ha IN NS ns1.ha.infn.it ns1.ha.infn.it 131.154.48.100 AXFR host.cnaf.infn.it ha.infn.it probe ns1.ha.infn.it nagios-srv update host.lnf.infn.it probe Riccardo Veraldi - Spring HEPiX 2013

  5. HA DNS Architecture (Single Master implementation) • National Services (host.infn.it) are geographically replicated in 2 sites for Example: CNAF in Bologna and LNF (Frascati National Laboratories) in Frascati • The ha.infn.it sub domain defined in a name server ns1.ha.infn.it placed in a third site geographically far from the two sites hosting the National Services. • A DNS delegation is set up on server2.infn.it (infn.it primary DNS) defining ns1.ha.infn.it as the primary NS for the ha.infn.it domain. The host names of the HA Services are registered in server2.infn.it as CNAME pointing to the ha.infn.it domain entries. • The host name defined in ns1.ha.infn.it points to the IP address of one of the instances of the service with TTL 60 • A nagios server (Installed for example in the site hosting ns1.ha.infn.it) probes the different servers implementing the service instances. • If the main server doesn’t answer to the probe, nagios triggers the nsupdate procedure on ns1.ha.infn.it in order to point to the active instance of the service. • Using the same CNAME defined in server2.infn.it the service will always be reached in the site where it is Up and Running. Riccardo Veraldi - Spring HEPiX 2013

  6. DNS HA architecture(multimaster) ha IN NS ns1.ha.infn.it ha IN NS ns2.ha.infn.it ns1.ha.infn.it 131.154.48.100 ns2.ha.infn.it 131.154.48.101 host IN CNAME host.ha.infn.it. server2.infn.it infn.it AXFR dxcnaf.cnaf.infn.it host 60 IN A 193.x.y.z host 60 IN A 131.154.a.b ha.infn.it ns1.ha.infn.it Master instance at CNAF host.cnaf.infn.it nsupdate probe ha.infn.it nagios-srv ns2.ha.infn.it nsupdate host.lnf.infn.it probe Master instance at INFN ROMA1 Riccardo Veraldi Riccardo Veraldi - Spring HEPiX 2013

  7. HA DNS multimaster • National Services (host.infn.it) are geographically replicated in 2 sites for Example: CNAF in Bologna and LNF (Frascati National Laboratories) in Frascati • The ha.infn.it sub domain is now implemented with a Multimaster architecture in two different INFN department for example CNAF and INFN ROMA1 • A DNS delegation is set up on server2.infn.it (infn.it primary DNS) defining ns1.ha.infn.it and ns2.ha.infn.it as NS for the ha.infn.it domain. The host names of the HA services are registered in server2.infn.it as CNAME pointing to the hostnames defined in ha.infn.it domain. • The host names defined in ns1.ha.infn.it and ns2.ha.infn.it point to the IP address of one of the instances of the service with TTL 60. • A nagios server (Installed in the site hosting ns2.ha.infn.it) probes the different servers implementing the service instances. • If the main server doesn’t answer to the probe, nagios triggers the update procedure to modify the IP address in ns2.ha.infn.it or in ns1.ha.infn.it if the first is not reachable in order to point to the active instance of the service. • Using the same CNAME defined in server2.infn.it the service will always be reachable in the site where it is Up and Running. Riccardo Veraldi - Spring HEPiX 2013

  8. BIND9 limits • BIND9 • readsDNS data from text files. Itisvery easy to make a mistakewhen editing a file causingit to be mis-read or made un-readable by BIND • storesall DNS data in RAM. Ifyour DNS server isauthoritative for a large number of zones, youmayhave to rebuild the kernel on your machine in order to supportBIND'smemoryneeds • parsesall of itszone filesat startup. For a large number of zonesthis can be time-consuming • Ifyouchangeany information in those zone files, you must reload or restart BIND beforethosechanges take effect. “Do thisoftenenough and BIND couldspend more time reloading data thanansweringqueries!” • doesnotsupport multi-master architecture Riccardo Veraldi - Spring HEPiX 2013

  9. BIND-DLZ • BIND-DLZ is a patch for BIND9 • Itallowsyou to storeyour zone data in a database • PostgreSQL • MySQL • Berkeley DB • ODBC • LDAP or • FS hierarchicalstructure • Changesin your database are immediatelyreflected in BIND'sresponse to DNS queries, no need to restartnamedwhen DNS info changes • Il dynamicallyloadzoneswhenneeded • Veryflexible: you can have standard BIND zones and DLZ zonesconfigured in named.conf Riccardo Veraldi - Spring HEPiX 2013

  10. BIND-DLZ + MySQL ha.infn.it CNAF ha.infn.it ROMA1 ns1.ha.infn.it ns2.ha.infn.it bind-dlz bind-dlz mysql mysql master1/slave2 MySQLcircularreplication master2/slave1 Riccardo Veraldi - Spring HEPiX 2013

  11. CentOS + BIND-DLZ • CentOS 6.4 • bind-sdb-9.8.2-0.17.rc1.el6 (yuminstallbind-sdb) • mysql-server-5.1.67-1.el6 • Centos 5.x • itworksbutbindsrc.rpm from el6 must be re-built on el5 bind from el5 rpmdoesnot include DLZ extensions • Anymysqlversion can be used:tested on 5.0, 5.1, 5.6 Riccardo Veraldi - Spring HEPiX 2013

  12. namedconfiguration • A chrootedversion of namedisalways a suggested best practice: • bind-9.8.2-0.17.rc1.el6_4.4.x86_64 • bind-utils-9.8.2-0.17.rc1.el6_4.4.x86_64 • bind-libs-9.8.2-0.17.rc1.el6_4.4.x86_64 • bind-sdb-9.8.2-0.17.rc1.el6_4.4.x86_64 • bind-chroot-9.8.2-0.17.rc1.el6_4.4.x86_64 • DLZ zone in named.conf Riccardo Veraldi - Spring HEPiX 2013

  13. MySQL Schema • DLZ driver doesnot impose a specificschema, ItacceptsSQL queries with a few special tokensasparameters. Thesequeries are thenparsed and the tokensremoved. When a queryisrun, the tokenisreplaced with the appropriate value. Thisallows a variety of database schemas to be usedwithoutmodification to the driver'scode • Limitations: • The query must return the appropriate data types in the correctorder. • The query must use the correctpre-definedtokens. • Named must not be multi-threaded Riccardo Veraldi - Spring HEPiX 2013

  14. MySQLexample schema INDEXES: zone, host, type Riccardo Veraldi - Spring HEPiX 2013

  15. Step1: on MySQL Master1/Slave2 • Master 1/Slave 2 ip: 131.154.48.100 • Master 2/Slave 1 ip : 131.154.48.101 • Create a replication slave account in mysql • Restartmysql Master1 Riccardo Veraldi - Spring HEPiX 2013

  16. Step2: on MySQL Slave1/Master2 • Restartmysql slave1/master2 then start slave process • Slave_IO_Runningand Slave_SQL_Runningmust be Yes in the output Riccardo Veraldi - Spring HEPiX 2013

  17. Step3: on MySQL Master1/Slave2 Thisis the simple master-slaves scenario Riccardo Veraldi - Spring HEPiX 2013

  18. Step4: on MySQL Slave1/Master2 • Configure Slave1 as a master (Master2) • Create a replication slave account on Slave1/Master2 for Master1 Riccardo Veraldi - Spring HEPiX 2013

  19. Step5: on MySQL Master1/Slave2 • Editmy.cnf on Master1 for information of its master. • Restartboth Master1 and Master2 • On Master1 Riccardo Veraldi - Spring HEPiX 2013

  20. Step6: on MySQL Master1 and Master2 • Checking slave and master status both on Master1 and Master2 • BothMySQLservers are configuredas slave/master to eachotherallowing • a circularreplication • To Avoid auto incementkeyclashing • On Master 1 • On Master2 Riccardo Veraldi - Spring HEPiX 2013

  21. conclusions • With the introduction of a new domain ha.infn.it with two nameservers (multimaster) installed in different sites with the correct CNAME configuration and delegation on the top level domain nameserver is possible to build a DNS architecture for Geographically redundant services. • The Multimaster implementation permits to change the ip addresses even if one of the two sites hosting the DNS service is down. • The technologies used in this implementation of the multimaster DNS is based on Bind9-DLZ + mysqlbackebd Riccardo Veraldi - Spring HEPiX 2013

More Related