Struttura nazionale di Nameserver per i servizi ad alta affidabilità Riccardo Veraldi - CNAF.

Presentazione sul tema: "Struttura nazionale di Nameserver per i servizi ad alta affidabilità Riccardo Veraldi - CNAF."— Transcript della presentazione:

1 Struttura nazionale di Nameserver per i servizi ad alta affidabilità Riccardo Veraldi - CNAF

2 Architettura DNS INFN infn.it Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 2

3 DNS ha.infn.it multimaster Riccardo Veraldi – CNAF – CCRWS11 infn.it ns1.ha.infn.it host IN CNAME host.ha.infn.it. probe Istanza master sez. INFN Istanza master CNAF ns2.ha.infn.it host 60 IN A 193.206.y.z host 60 IN A 131.154.a.b In sede roma1 Db update 3 In sede roma1 18 Maggio 2011 3

4 Come funziona I servizi (host.infn.it) vengono ridondati geograficamente in 2 sedi (ad es: CNAF e altra sede INFN) Il sottodominio ha.infn.it viene implementato con architettura Multi Master in due sedi INFN (ad es. CNAF e ROMA1) Viene impostata la delega per ha.infn.it su server2.infn.it verso ns1.ha.infn.it e ns2.ha.infn.it e gli host name dei servizi HA vengono definiti su server2.infn.it come CNAME che puntano a hostname sul dominio ha.infn.it Gli hostname definiti su ns1.ha.infn.it e ns2.ha.infn.it puntano all’IP di un'istanza del servizio con TTL 60 in una delle due sedi in cui è installato Nella sede di ROMA1 è presente un nagios server che fa probe verso i server su cui è implementato un determinato servizio ridondato geograficamente Se il server principale tra i due non risponde nagios fa partire un'opportuna procedura (db update) che modifica l’IP del servizio su ns1.ha.infn.it oppure su ns2.cnaf.infn.it se il primo non è raggiungibile Lo script di aggiornamento dei record DNS automaticamente contatta il nameserver che risponde per primo Attraverso il CNAME definito su server2.infn.it il servizio sarà sempre raggiungibile nella sede in cui è UP and running Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 4

5 Vantaggi architettura multimaster Tutti i nameserver sono autoritativi e paritetici per la zona ha.infn.it ns1.ha.infn.it ns2.ha.infn.it La modifica su un nameserver viene propagata automaticamente sull’altro Se uno dei due nameserver non e’ raggiungibile si possono continuare a operare modifiche su quello disponibile e quando il secondo tornera’ UP automaticamente si sincronizzera’ con il suo peer Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 5

6 Come si realizza un DNS multimaster Utilizzare un dominio windows2k3 OPPURE Modificare e configurare bind in modo opportuno Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 6

7 Configurazione bind multimaster Bind versione 9.7.0 Supporto per DLZ Supporto per MySQL Configurazione di named-DLZ (named.conf) Creazione schema DB per i record DNS Configurazione del secondo DB sul secondo NS Configurazione dei due DB in modalita’ multimaster Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 7

8 Bind version 9.7.0 Bind versione 9.7.0 di RHEL supporta DLZ rpm RHEL 5.6 bind97 non ha il supporto per DLZ rpm RHEL 6.0 bind-9.7.0-5.P2.1 ha suppoto per DLZ Ricompilazione di bind-9.7.0-5.P2.el6_0.1.src.rpm con supporto DLZ abilitato %{?!SDB: %define SDB 1} Supporto per MySQL %if %{SDB} --with-dlz-ldap=yes \ --with-dlz-postgres=yes \ --with-dlz-mysql=yes \ --with-dlz-filesystem=yes \ %endif Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 8

9 Cos’e’ DLZ ? DLZ (Dynamically Loadable Zones) e’ una patch per bind 9 che consente di caricare le zone in modo dinamico all’occorrenza e permete l’utilizzo di backend altrimenti non supportate nativamente da bind PostgresSQL MySQL ODBC LDAP La patch e’ disponibile di default in bind 9.7.0 di RHEL 6.0 come pachetto bind-sdb-9.7.0-5.P2.1 Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 9

10 Configurazione DLZ in named.conf dlz "Mysql zone" { database "mysql {host=127.0.0.1 dbname=named user=named pass=****} {select zone from dns_records where zone = '%zone%'} {select ttl, type, mx_priority, case when lower(type)='txt' then concat('\"', data, '\"') else data end from dns_records where zone = '%zone%' and host = '%record%' and not (type = 'SOA' or type = 'NS')} {select ttl, type, mx_priority, data, resp_person, serial, refresh, retry, expire, minimum from dns_records where zone = '%zone%' and (type = 'SOA' or type='NS')} {select ttl, type, host, mx_priority, data, resp_person, serial, refresh, retry, expire, minimum from dns_records where zone = '%zone%' and not (type = 'SOA' or type = 'NS')} {select zone from xfr_table where zone = '%zone%' and client = '%client%'}"; }; Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 10

11 Configurazione schema DB | dns_records | CREATE TABLE `dns_records` ( `zone` varchar(255) NOT NULL, `host` varchar(255) NOT NULL, `type` enum('SOA','NS','MX','A','CNAME','PTR') NOT NULL, `data` varchar(255) default NULL, `ttl` int(11) NOT NULL, `mx_priority` varchar(10) default NULL, `refresh` int(11) default NULL, `retry` int(11) default NULL, `expire` int(11) default NULL, `minimum` int(11) default NULL, `serial` bigint(20) default NULL, `resp_person` varchar(255) default NULL, `primary_ns` varchar(255) default NULL, KEY `host_index` (`host`(20)), KEY `zone_index` (`zone`(30)), KEY `type_index` (`type`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 | Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 11

12 Configurazione DB sul secondo NS Dump del DB su ns1 e import su ns2 mysqldump --add-drop-table -u named -p ***** named > named.mysql mysql -u named –p ***** < named.mysql Settare i grant dell’utente named sul nuovo DB Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 12

13 Configurazione MM - my.cnf NS1 # master server-id = 1 # auto_increment_increment = 2 auto_increment_offset = 1 # log-bin=mysql-bin binlog-do-db=named binlog-ignore-db=mysql binlog-ignore-db=test # slave master-host = 141.108.a.b master-user = replication master-password = **** master-port = 3306 # Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 13

14 Configurazione MM - my.cnf NS2 # slave server-id = 2 master-host = 131.154.1.41 master-user = replication master-password = **** master-port = 3306 # master log-bin=mysql-bin binlog-do-db=named # auto_increment_increment = 2 auto_increment_offset = 2 # Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 14

15 Conclusioni Utilizzando un dominio dedicato ha.infn.it e’ possibile a livello TLD infn.it definire dei CNAME predefiniti per i servizi importanti ridondati geograficamente L’architettura MultiMaster di ha.infn.it consente di avere sempre un server DNS disponibile per gli aggiornamenti dei record relativi a servizi nazionali ridonadati geograficamente Tramite nagios si monitora lo stato dei servizi e si lanciano gli aggiornamenti (dbupdate) per i record DNS relativi ai servizi che in un determinato momento non dovessero essere raggiungibili Riccardo Veraldi - CNAF - CCRWS1118 Maggio 2011 15