As you can see I've setup a breakpoint for connect(). Then I "continue" the execution and I try the connection. gdb stops the program at the breakpoint and I get the stack trace (read bottom up).
So, it shows we call getnameinfo() which in turn calls gethostbyaddr_r() etc. All this belongs to the system libraries, not to Informix code.
There are two additional considerations we need to be aware. First, the Informix MSC VP processes it's requests in a serial manner. For each connection it asks what it needs from the DNS servers and/or files and makes the authentication. By default we only have one MSC VP... so if one request gets stuck.... yes... the following connections will suffer delays. This delays can be a fraction of second, or a few seconds, but on some systems I've seen tens (heard about hundreds) of connections per second, so even a few seconds will have large impact.
The second consideration relates to the differences between the first call and the subsequent ones. As we've seen above, on the first call the process checks the configuration (the /etc/nsswitch.conf and /etc/resolv.conf files). After that first check it does not do that anymore. And this causes a problem. Again this is the behavior of the system functions (but not necessarily the end of the story....)
So, hopefully I was able to explain how Informix interacts with the DNS system. The important technical deep dive should be over. We'll proceed to the implications. It's important you understand all the above before proceeding to the next paragraphs.
Above I've tried to show you how things work when everything is ok. But what happens when something is wrong? Let's see what can go wrong first and then the implications. I'll also try to explain who to blame (and again the disclaimer...). The purpose of course is not to finger point, but knowing where the problem lies is the first step to solve it.
From the above problems it's easy to understand that the three first are not Informix's fault. When a customer decides (presumably because it needs) to use a DNS infra-structure people have to understand that it automatically becomes a critical component of the system. Any problems in it will cause problems in the layers above, specifically in the Informix system.
And that leaves us with the forth problem. I wrote before and it's true that this is how the functions work (and I'll show this in action), so why do I write that this is Informix's fault? Well, because there is a way to handle this. There is another system call named res_init() that does precisely what we need. From the Linux manual, I quote:
Knowing if you have the problem
How do we know that we have a problem in DNS and that Informix is being impacted? Typically you'll get some sort of complain from the Informix clients. Usually something like "the database is terribly slow", or "it takes a long time to connect", or eventually you'll have connections refused with server side error -956 (not trusted). In extreme situations you can have weird errors in the online.log (-25xxx ). In all these situations you'll notice that the already existing sessions are working smoothly.
But in order to be sure you may follow two paths:
- The most simple is to run a "netstat -a" command on the database server. This shows all the TCP/UDP connections to and from the machine. By default it will go through all the socket connections and will try to reverse lookup the respective IP addresses. If you're having problems you'll see that the netstat output will be very slow or at least with some "bumps". But for this simple tests to provide meaningful conclusions, you must be sure that the system is still configured to use the same configuration (/etc/nsswitch.conf and /etc/resolv.conf) that was in place when the Informix engine was started. Otherwise you'll not be comparing apples to apples
- The most complex is to run a truss or strace command against the MSC VP with timings. This can show slow response from the calls to the DNS hosts. Be aware that running truss/strace requires root privileges and that even if everything is running fine, it will cause delays on systems with a large number of connects per second
I wrote earlier that I could demonstrate the facts presented here without using Informix. For that I created a simple program (line numbers included):
1 #include <sys/time.h>
2 #include <netdb.h>
3 #include <resolv.h>
4 #include <stdlib.h>
5 #include <string.h>
6
7 int main(int argc, char **argv)
8 {
9 struct hostent *hp;
10 in_addr_t data;
11 char buff[100];
12 struct timeval ts_initial, ts_final;
13
14 if (argc == 2) {
15 strcpy(buff,argv[1]);
16 }
17 else {
18 printf("Introduce an IP address: ");
19 if (fscanf(stdin,"%s", buff) == EOF)
20 exit(0);
21 }
22
23 while (1 == 1) {
24 data = inet_addr(buff);
25 gettimeofday(&ts_initial, NULL);
26 hp = gethostbyaddr(&data, 4, AF_INET);
27 gettimeofday(&ts_final, NULL);
28
29 if (hp == NULL) {
30 printf("Unknown host (%s). Took %f seconds\n", buff, (double)((ts_final.tv_sec * 1000000 + ts_final.tv_usec) - (ts_initial.tv_sec * 1000000 + ts_initial.tv_usec))/1000000);
31 }
32 else {
33 printf("Name (%s): %s Took %f seconds\n", buff, hp->h_name, (double)((ts_final.tv_sec * 1000000 + ts_final.tv_usec) - (ts_initial.tv_sec * 1000000 + ts_initial.tv_usec))/1000000);
34 }
35 printf("Next: ");
36 if (fscanf(stdin,"%s", buff) == EOF)
37 exit(0);
38 if ( strncmp("refresh", buff, 7) == 0 )
39 {
40 res_init();
41 printf("Called res_init()\n");
42 printf("Next: ");
43 if (fscanf(stdin,"%s", buff) == EOF)
44 exit(0);
45 }
46 }
47 }
This is basically a loop that reads an IP address (which are not validated, so it's easily breakable), and runs gethostbyaddr() on it. If the "ip" provided is "refresh" then it calls res_init(). It reports the information returned by the resolver subsystem and the time it took. You can use it interactively or redirect a file with one IP address per line.
I'll run it interactively with tracing in order to show the effect of calling res_init(). I have "hosts: dns,files" in /etc/nsswitch.conf and 192.168.112.2 on /etc/resolv.conf. This file also contains options do define the timeout to 2 seconds. So I call this with:
cheetah@pacman1.onlinedomus.net:fnunes-> strace -r -o test_resolv.trace ./test_resolv
Introduce an IP address: 1.1.1.1
Unknown host (1.1.1.1). Took 2.010235 seconds
Next: 1.1.1.2
Unknown host (1.1.1.2). Took 2.003324 seconds
Next: refresh
Called res_init()
Next: 1.1.1.3
Unknown host (1.1.1.3). Took 2.004002 seconds
Next: ^C
Before I introduce "refresh" I change the DNS nameserver in /etc/resolv.conf from 192.168.112.2 to 192.168.112.5.
The trace is this (line numbers and timmings added):
1 [...]
2 0.000000 write(1, "Introduce an IP address: ", 25) = 25
3 0.000000 read(0, "1.1.1.1\n", 1024) = 8
4 3.055699 gettimeofday({1325865284, 104186}, NULL) = 0
5 [...]
6 0.000160 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
7 0.000099 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
8 0.000128 close(3) = 0
9 0.000053 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
10 0.000123 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
11 0.000122 close(3) = 0
12 0.000095 open("/etc/nsswitch.conf", O_RDONLY) = 3
13 0.000108 fstat64(3, {st_mode=S_IFREG|0644, st_size=1803, ...}) = 0
14 0.000101 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
15 0.000057 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1803
16 0.000001 read(3, "", 4096) = 0
17 0.000000 close(3) = 0
18 [...]
19 0.000055 open("/etc/resolv.conf", O_RDONLY) = 3
20 0.000072 fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
21 0.000095 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
22 0.000050 read(3, "# Generated by NetworkManager\nna"..., 4096) = 118
23 0.000086 read(3, "", 4096) = 0
24 0.000046 close(3) = 0
25 [...]
26 0.000173 open("/etc/host.conf", O_RDONLY) = 3
27 0.000068 fstat64(3, {st_mode=S_IFREG|0644, st_size=26, ...}) = 0
28 0.000081 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
29 0.000179 read(3, "multi on\norder hosts,bind\n", 4096) = 26
30 0.000083 read(3, "", 4096) = 0
31 0.000048 close(3) = 0
32 0.000049 munmap(0xb7843000, 4096) = 0
33 0.000160 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
34 0.000075 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
35 0.000640 gettimeofday({1325865284, 108850}, NULL) = 0
36 0.000062 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
37 0.000094 send(3, "r\363\1\0\0\1\0\0\0\0\0\0\0011\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
38 0.000889 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
39 2.003373 close(3) = 0
40 0.000109 open("/etc/ld.so.cache", O_RDONLY) = 3
41 0.000078 fstat64(3, {st_mode=S_IFREG|0644, st_size=72238, ...}) = 0
42 0.000093 mmap2(NULL, 72238, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7821000
43 0.000054 close(3) = 0
44 [...]
45 0.000105 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
46 0.000097 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
47 0.000065 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
48 0.000053 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
49 0.000035 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
50 0.000137 read(3, "", 4096) = 0
51 0.000130 close(3) = 0
52 [...]
53 0.000101 write(1, "Unknown host (1.1.1.1). Took 2.0"..., 46) = 46
54 0.000071 write(1, "Next: ", 6) = 6
55 0.000267 read(0, "1.1.1.2\n", 1024) = 8
56 0.000071 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
57 0.000077 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
58 0.000049 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
59 0.000063 send(3, ":\243\1\0\0\1\0\0\0\0\0\0\0012\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
60 0.000152 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
61 2.002550 close(3) = 0
62 0.000088 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
63 0.000077 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
64 0.000092 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
65 0.000057 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
66 0.000110 read(3, "", 4096) = 0
67 0.000049 close(3) = 0
68 [...]
69 0.000060 write(1, "Unknown host (1.1.1.2). Took 2.0"..., 46) = 46
70 0.000076 write(1, "Next: ", 6) = 6
71 0.000253 read(0, "refresh\n", 1024) = 8
72 17.639011 open("/etc/resolv.conf", O_RDONLY) = 3
73 0.000088 fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
74 0.000087 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
75 0.000052 read(3, "# Generated by NetworkManager\n#n"..., 4096) = 118
76 0.000108 read(3, "", 4096) = 0
77 0.000047 close(3) = 0
78 0.000048 munmap(0xb7843000, 4096) = 0
79 0.000065 write(1, "Called res_init()\n", 18) = 18
80 0.000060 write(1, "Next: ", 6) = 6
81 0.000051 read(0, "1.1.1.3\n", 1024) = 8
82 3.595382 gettimeofday({1325865312, 174933}, NULL) = 0
83 0.000075 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
84 0.000078 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.5")}, 16) = 0
85 0.000266 gettimeofday({1325865312, 175350}, NULL) = 0
86 0.000052 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
87 0.000069 send(3, "\321\234\1\0\0\1\0\0\0\0\0\0\0013\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
88 0.000085 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
89 2.002271 close(3) = 0
90 0.000081 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
91 0.000076 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
92 0.000087 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
93 0.000054 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
94 0.000091 read(3, "", 4096) = 0
95 0.000047 close(3) = 0
96 0.000048 munmap(0xb7843000, 4096) = 0
97 0.000062 gettimeofday({1325865314, 178373}, NULL) = 0
98 0.000058 write(1, "Unknown host (1.1.1.3). Took 2.0"..., 46) = 46
99 0.000072 write(1, "Next: ", 6) = 6
100 0.000053 read(0, 0xb7844000, 1024) = ? ERESTARTSYS (To be restarted)
101 0.918564 --- SIGINT (Interrupt) @ 0 (0) ---
102 0.000931 +++ killed by SIGINT +++
And the explanation:
Hacking it just for fun!
Please don't try this at home!.. Really, the following is something risky, not supported, and for learning purposes only. I argued above that calling res_init() would allow you to change the DNS servers without restarting Informix. Let's prove it!
Again I traced a connection, looking at MSC VP. I get this:
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
gettimeofday({1326038028, 174740}, NULL) = 0
poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
send(3, "+\316\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
close(3) = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x12f000
read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
close3)
It is connecting to 192.168.112.2, which is what I have on /etc/resolv.conf. If I change that on the file to 192.168.112.5 and try to connect again, the same thing happens (it's not aware of the change). But now, without further changes in the file I run a debugger against the MSC VP process:
[root@pacman tmp]# gdb -p 4649
GNU gdb (GDB) Fedora (7.1-18.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http: bugs="" gdb="" software="" www.gnu.org="">.
Attaching to process 4649
Reading symbols from /usr/informix/srvr1170uc4/bin/oninit...(no debugging symbols found)...done.
[...]
(gdb) call __res_init()
$1 = 0
(gdb) detach
Detaching from program: /usr/informix/srvr1170uc4/bin/oninit, process 4649
(gdb) quit
[root@pacman tmp]#
And I "call" the __res_init() function which I checked to be defined in the libc.so code. Let's trace another connection now:
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.5")}, 16) = 0
gettimeofday({1326038409, 784712}, NULL) = 0
poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
send(3, "\364K\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
close(3) = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x12f000
read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
close(3)
Ups! Hacked!... Of course this is not supported. Don't try this on real servers. It just serves the purpose of proving a point.
Conclusions
What I tried to demonstrate in this article is how Informix interacts with the DNS system, if you configure DNS in your environment. I hope that I made clear that once DNS is in place it takes a very important role in the connection process. So much that a bad function in DNS will have major impact in the database system. There are a few points that are Informix responsibility that can contribute to the impact. In particular:
- The fact that the reverse DNS requests are made by the MSC VP(s) can generate delays in requests that would work ok, just because a previous one has a problem. Having more than one MSC VP can greatly alleviate this, but may not solve it
- The fact that Informix doesn't establish timeouts to the gethostbyname() calls - or equivalent - can also lead to unnecessary delays. But note that the functions signatures don't have any way to ask for this, so an alarm would have to be setup, so that the process would receive a signal and then check if it was still waiting on the function. This would cause additional overhead, that would not make sense specially because the timeouts are possible to configure in the generic DNS configuration
- The fact that the functions called, cache the configuration details, allied to the fact that Informix has no way to clear the cache, means that a change in the DNS addresses will require a stop in the database system. There is a feature request to allow this. I'd love to see this implemented.
On the other hand, Informix 11.7 introduced a great feature to ease all this. With the NS_CACHE parameter we can configure the cache times for several systems (DNS, users/passwords, services...). This can reduce to a minimum the number of requests. Of course, as with any other caching mechanism the risk is to have stalled entries. But we can clear any of the caches by using "onmode -wm NS_CACHE=..." and using a timeout of zero. This would be a great place to call res_init() by the way...
To roundup the article I'd like to mention a few best practices:
- Use Informix 11.7 if you can, so that you can take advantage of the caching. Your DNS servers and DNS admins will appreciate it if you have high connection rates
- Consider including "files" in the /etc/nsswitch.conf configuration. Some people consider this a bad idea, because it keeps the /etc/hosts file very busy. But if you keep it short and use the cache of Informix 11.7 it shouldn't be too bad. And it can save you if your DNS blows away (you could then add entries to the /etc/hosts file even temporarily). Note that at least in my test system (Linux) not even res_init makes the process re-read /etc/nsswitch.conf
- Make sure your DNS admins and DBA get along... They must work together and should be aware that their systems are tightly connected
- Use Informix 11.7 if you can, so that you can use REMOTE_SERVER_CFG. Many companies don't allow the DBA to manage the /etc/hosts.equiv files (system files). If you have a problem in DNS, and your reverse DNS queries start to fail, your trusted connections will fail if they use the names and not the IP addresses. So, in critical situations it may be useful that the DBAs can act immediately and add the IP addresses in the trusted lists. With REMOTE_SERVER_CFG they'll be able to do it.
- Use very small timeouts configured in /etc/resolvs.conf (1-2s) to minimize the waisted wait time (a successful query to a DNS is pretty quick
Versão Portuguesa:
Nota (13 Fev 2014): Um novo artigo apresenta uma forma de contornar o problema aqui descrito (http://informix-technology.blogspot.pt/2014/02/dns-changes-ok-mudancas-no-dns-ok.html)
Você decidiu...
Este artigo é o primeiro publicado após opinião dos leitores. Tinha algumas opções para assuntos a abordar e iniciei um inquérito numa
página do Facebook. O impacto do
DNS no Informix foi o mais votado. E a vontade expressa foi cumprida. Provavelmente continuarei a fazer isto de ora em diante.
Pessoalmente o assunto agrada-me porque já enfrentei problemas relacionados com o DNS em mais que um cliente É um assunto algo frequente em ambientes complexos.
O
blog tem um termo de desresponsabilização público e genérico, mas neste caso gostaria de o enfatizar um pouco... Para além do normal, gostaria de deixar claro que a informação que se segue foge um pouco às minhas competências "regulares". É o resultado de bastante investigação ao longo fo tempo (e não só minha) e pode conter alguns (espero que poucos e pouco importantes) erros. Não se acanhe de comentar, corrigir, sugerir alterações por aqui ou por
email etc.
Pequena introdução ao DNS
DNS é um acrónimo de Domain Name System, que é o protocolo/serviço capaz de converter um nome (ex: onlinedomus.com) num endereço TCP/IP (ex: 89.1.2.3) e vice-versa. Pode ainda fazer uma série de outras coisas, como indicar qual o servidor de
email responsável por um determinado domínio etc., mas isso já sai do âmbito deste artigo.
Sem DNS não haveria Internet como a conhecemos. É um componente crítico da infra-estrutura da Internet, e a sua eficiência e segurança é crucial para nós, os utilizadores
Numa pequena rede podemos passar sem DNS para as funções básicas de resolução de nomes, usando ficheiros. Mas em redes mais complexas e maiores, pode ser muito complicado e penoso gerir isso usando apenas ficheiros.
O sistema de DNS tem uma arquitectura hierárquica e usa o
protocolo UDP (U não significa
unreliable mas podia...) por questões de
performance. Configurar devidamente um sistema DNS pode ser uma tarefa complexa e a minha experiência diz-me que não é muito fácil encontrar quem o saiba fazer correctamente. Ainda mais, na maioria dos casos as pessoas não têm a correcta noção do terrível impacto que uma má configuração no DNS pode ter nos sistemas.
Não vou explicar (não o saberia fazer) todos os aspectos de configuração de DNS, mas quero referir alguns pontos:
- /etc/nsswitch.conf
Este ficheiro (em sistemas Unix/Linux, mas o nome pode mudar) define como a resolução de nomes (e outros serviços) é efectuada. Mais especificamente define se o sistema usa ficheiros, NIS, servidores de DNS ou outros mecanismos e a ordem porque o faz. Como exemplo, uma linha como:
hosts: dns files
indica que as pesquisas de nomes e IPs são feitas primeiro usando os servidores de DNS e depois ficheiros
- /etc/hosts
Este ficheiro mapeia os endereços IPs em nomes (e vice-versa). Por exemplo:
89.1.2.3 www.onlinedomus.com onlinedomus.com
Isto indica ao sistema que o endereço IP 89.1.2.3 mapeia para "www.onlinedomus.com" (e vice-versa). Uma pesquisa por "onlinedomus.com" irá mapear para o mesmo endereço IP.
- /etc/resolv.conf
Este ficheiro contém a lista de servidores de DNS que serão usados para fazer pesquisas e eventualmente mais algumas opções (como timeouts para os pedidos, domínios que serão adicionados aos nomes pedidos caso o nome simples não obtenha resultados etc.). Um exemplo:
nameserver 192.168.112.2
nameserver 9.64.162.21
Como é que o Informix usa o DNS?
Da perspectiva do DNS, o Informix é apenas mais uma aplicação. O ficheiro /etc/nsswitch.conf contém configurações que definem se o Informix irá usar ficheiros (/etc/hosts) ou servidores de DNS (configurados em /etc/resolv.conf). A primeira coisa a notar é que toda a interacção do Informix com o DNS é feito através de funções de sistema. Em particular, o Informix usa duas funções ou as suas equivalente e/ou substitutas:
- gethostbyname()
Resumidamente recebe um nome de máquina e retorna uma estrutura contendo um endereço IP
- gethostbyaddr()
Esta faz o contrário, ou seja recebe uma estrutura com o endereço IP e retorna os campos relativos ao nome (ou nomes) preenchidos
Assim, se alguma coisa não estiver a funcionar, temos de entender quando e onde é que o Informix chama estas funções e como é que elas funcionam. É típico ver clientes a culpar o Informix quando tal não é justo (não completamente pelo menos, mas mais sobre isto adiante). A maioria (senão todos) dos problemas de DNS que afectam o Informix que presenciei, afectam também outras aplicações. E estes problemas são facilmente reproduzíveis com um pequeno programa em linguagem C. Quer isto dizer que não poderíamos fazer algumas coisas de forma diferente (melhor?) Não... Mas isto será abordado mais adiante (chamo a atenção para o termo de desresponsabilização :) )
Este artigo é escrito essencialmente da perspectiva do servidor de base de dados. Mas o DNS tem implicações óbvias no lado do cliente... Vamos começar por aqui e depois saltamos para o servidor.
Quando um cliente tenta conectar-se a um servidor Informix, começa por procurar o $INFORMIXSERVER (ou equivalente dado na
string de conexão) no ficheiro $INFORMIXSQLHOSTS (em Java a informação pode ser obtida via LDAP ou HTTP, mas vamos assumir só ficheiros por simplificação). O ficheiro contém linhas com o seguinte formato:
INFORMIXSERVER PROTOCOLO NOME_MAQUINA/ENDERECO_IP NUMERO_PORTO/NOME_SERVICO OPCOES
Quando as funções das bibliotecas cliente encontram a linha que define o INFORMIXSERVER pretendido, obtêm o nome da máquina (ou endereço IP) e o número do porto (ou nome de serviço).
Se o nome de serviço é usado, procuramos o número do porto no ficheiro /etc/services (isto também pode ser configurado no /etc/nsswitch.conf). Pessoalmente habitualmente uso o número do porto directamente para evitar mais esta consulta..
Depois, se o nome de uma máquina foi usado, o cliente terá de o converter para um endereço IP. Para isso chama a função gethostbyname(). Esta função irá comportar-se como especificado no ficheiro /etc/nsswitch.conf e tentará mapear o nome recebido num endereço IP. Uma falha ao fazer isto irá resultar num erro -930. Isto pode ser provocado:
cheetah@pacman.onlinedomus.com:fnunes-> echo $INFORMIXSERVER; grep $INFORMIXSERVER $INFORMIXSQLHOSTS; dbaccess sysmaster -
blogtest
blogtest onsoctcp nowhere.onlinedomus.com 1500
930: Cannot connect to database server (nowhere.onlinedomus.com).
cheetah@pacman.onlinedomus.com:fnunes->
e se precisar de evidências do que se está a passar pode usar o strace (ou truss conforme a plataforma):
strace -o /tmp/strace.out dbaccess sysmaster -
O seguinte é um extracto editado do /tmp/strace.out gerado pelo comando acima. Se tiver paciência, pode vê-lo a fazer:
- Abrir o ficheiro etc/nsswitch.conf
- Abrir o ficheiro $INFORMIXSQLHOSTS (/home/informix/etc/sqlhosts)
- Abrir o ficheiro /etc/services (excepcionalmente usei um nome em vez de um porto)
- Abrir o /etc/resolv.conf para descobrir os servidores de DNS configurados
- Abrir um socket para 192.168.112.2 (o servidor de DNS que tenho configurado)
- Perguntar por nowhere.onlinedomus.com
- Abrir o ficheir /etc/hosts (no /etc/nsswtich.conf eu configurei a pesquisa nos ficheiros após a pesquisa nos servidores de DNS)
- Ler a mensagem de erro nos ficheiros de mensagens do Informix
- Escrever a mensagem de erro no stderr
- Sair com o erro -1
cheetah@pacman.onlinedomus.com:fnunes-> cat /tmp/strace.out
[...]
open("/etc/nsswitch.conf", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1803, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7862000
read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1803
read(3, "", 4096) = 0
close(3) = 0
[...]
open("/home/informix/etc/sqlhosts", O_RDONLY|O_LARGEFILE) = 4
_llseek(4, 0, [0], SEEK_SET) = 0
read(4, "blogtest onsoctcp nowher"..., 4096) = 1389
[...]
open("/etc/services", O_RDONLY|O_CLOEXEC) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=644327, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7862000
read(4, "# /etc/services:\n# $Id: services"..., 4096) = 4096
close(4) = 0
[...]
open("/etc/resolv.conf", O_RDONLY) = 4
[...]
read(4, "", 4096) = 0
close(4) = 0
[...]
open("/lib/libresolv.so.2", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0Pf\256\0004\0\0\0"..., 512) = 512
[...]
close(4) = 0
[...]
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
gettimeofday({1325590403, 502576}, NULL) = 0
poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}])
send(4, "tl\1\0\0\1\0\0\0\0\0\0\7nowhere\vonlinedomus"..., 41, MSG_NOSIGNAL) = 41
poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}])
ioctl(4, FIONREAD, [101]) = 0
recvfrom(4, "tl\201\203\0\1\0\0\0\1\0\0\7nowhere\vonlinedomus"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, [16]) = 101
close(4) = 0
[...]
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 4
[...]
read(4, "127.0.0.1\tpacman1.onlinedomus.ne"..., 4096) = 439
[...]
close(4) = 0
[...]
read(3, "Cannot connect to database serve"..., 40) = 40
write(2, "\n", 1) = 1
write(2, " 930: Cannot connect to databas"..., 68) = 68
exit_group(-1) = ?
cheetah@pacman.onlinedomus.com:fnunes->
Agora devemos passar para o lado do servidor. Mas isso requer um pouco mais de trabalho e explicações preliminares. Para começar temos de entender o que o motor necessita para estabelecer uma ligação ou sessão. Uma dessas coisas é fazer o chamado "reverse DNS" ou DNS inverso que não é mais que converter um endereço IP no nome de uma máquina. Isto pode não ser absolutamente essencial, mas é sempre tentado. O Informix pode precisar do nome da máquina para validar as relações de confiança (ligações sem utilizador/password). O nome servirá também para informação do DBA de forma a mais facimente identificar a origem do cliente.
Como saberá, o motor de base de dados Informix é composto por vários processos de sistema operativo. Do ponto de vista do SO, todos estes processos parecem iguais (chamam-se oninit), mas cada um tem um trabalho específico e corre threads específicas do motor.
Podemos listar as
threads com:
panther@pacman.onlinedomus.com:fnunes-> onstat -g ath
IBM Informix Dynamic Server Version 11.70.UC4 -- On-Line -- Up 00:17:01 -- 411500 Kbytes
Threads:
tid tcb rstcb prty status vp-class name
2 5583fa38 0 1 IO Idle 3lio* lio vp 0
3 558551f8 0 1 IO Idle 4pio* pio vp 0
4 5586b1f8 0 1 IO Idle 5aio* aio vp 0
5 558811f8 8f59dc0 1 IO Idle 6msc* msc vp 0
6 558af1f8 0 1 IO Idle 7fifo* fifo vp 0
7 558c9590 0 1 IO Idle 9aio* aio vp 1
8 558df3b8 54267018 3 sleeping secs: 1 8cpu main_loop()
9 559276f8 0 1 running 10soc* soctcppoll
10 5593ed18 0 2 sleeping forever 1cpu* soctcplst
11 55927d20 542675fc 1 sleeping secs: 1 8cpu flush_sub(0)
12 55988018 54267be0 1 sleeping secs: 1 8cpu flush_sub(1)
13 559881f0 542681c4 1 sleeping secs: 1 8cpu flush_sub(2)
14 559883c8 542687a8 1 sleeping secs: 1 8cpu flush_sub(3)
15 559885a0 54268d8c 1 sleeping secs: 1 8cpu flush_sub(4)
16 55988778 54269370 1 sleeping secs: 1 8cpu flush_sub(5)
17 55988bf0 54269954 1 sleeping secs: 1 8cpu flush_sub(6)
18 559fb468 54269f38 1 sleeping secs: 1 8cpu flush_sub(7)
19 559fb640 0 3 IO Idle 8cpu* kaio
20 55ab6018 5426a51c 2 sleeping secs: 1 8cpu aslogflush
21 55ab6960 5426ab00 1 sleeping secs: 92 1cpu btscanner_0
22 55b6a408 5426b0e4 3 cond wait ReadAhead 1cpu readahead_0
39 55bcd5c8 0 3 IO Idle 1cpu* kaio
40 55bcd7a0 5426bcac 3 sleeping secs: 1 1cpu* onmode_mon
41 55d3e148 5426c874 3 sleeping secs: 1 8cpu periodic
49 55e80a78 5426da20 1 sleeping secs: 177 1cpu dbScheduler
51 55f340f8 5426d43c 1 sleeping forever 1cpu dbWorker1
52 55f34d80 5426ce58 1 sleeping forever 8cpu dbWorker2
59 562ee228 5426e5e8 1 cond wait bp_cond 1cpu bf_priosweep()
E os processos de sistema operativo com:
panther@pacman.onlinedomus.com:fnunes-> onstat -g glo
IBM Informix Dynamic Server Version 11.70.UC4 -- On-Line -- Up 00:18:48 -- 411500 Kbytes
MT global info:
sessions threads vps lngspins
0 29 10 3
sched calls thread switches yield 0 yield n yield forever
total: 9589515 8992470 597961 14485 4457836
per sec: 0 0 0 0 0
Virtual processor summary:
class vps usercpu syscpu total
cpu 2 11.51 94.06 105.57
aio 2 3.57 75.44 79.01
lio 1 0.01 0.01 0.02
pio 1 0.00 0.01 0.01
adm 1 0.01 0.15 0.16
soc 1 0.04 0.15 0.19
msc 1 0.00 0.01 0.01
fifo 1 0.00 0.01 0.01
total 10 15.14 169.84 184.98
Individual virtual processors:
vp pid class usercpu syscpu total Thread Eff
1 29395 cpu 5.63 46.80 52.43 66.41 78%
2 29398 adm 0.01 0.15 0.16 0.00 0%
3 29399 lio 0.01 0.01 0.02 0.02 100%
4 29400 pio 0.00 0.01 0.01 0.01 100%
5 29401 aio 3.29 74.30 77.59 77.59 100%
6 29402 msc 0.00 0.01 0.01 0.03 31%
7 29403 fifo 0.00 0.01 0.01 0.01 100%
8 29404 cpu 5.88 47.26 53.14 64.45 82%
9 29405 aio 0.28 1.14 1.42 1.42 100%
10 29406 soc 0.04 0.15 0.19 NA NA
tot 15.14 169.84 184.98
As
threads que estão à escuta nos portos TCP do motor são as
poll threads (soctcppoll) que correm nos VPs (
virtual processors) de classe SOC (isto depende da configuração do parâmetro NETTYPE). Quando um novo pedido de ligação é recebido por elas, chama as
listener threads (soctcplst) que correm na classe CPU, para iniciar o processo de autenticação. Partes deste processo são executadas pelo VP MSC. Como podemos ver na lista acima este tem o PID 29402. Portanto, para perceber o que se passa irei fazer o
trace a este processo. Por razões que ficarão claras mais abaixo, vou desligar a funcionalidade NS_CACHE (11.7) e vou fazer uma paragem/arranque do motor. Após isto, para a primeira tentativa de conexão obtemos (algumas partes não relevantes foram cortadas):
1 0.000000 semop(753664, {{5, -1, 0}}, 1) = 0
2 7.009868 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
3 0.000107 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
4 0.000242 close(3) = 0
5 0.000060 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
6 0.000063 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
7 0.000095 close(3) = 0
8 [...]
9 0.000000 open("/etc/resolv.conf", O_RDONLY) = 3
10 0.000000 fstat64(3, {st_mode=S_IFREG|0644, st_size=55, ...}) = 0
11 0.000000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xab4000
12 0.000000 read(3, "# Generated by NetworkManager\nna"..., 4096) = 55
13 0.000926 read(3, "", 4096) = 0
14 0.000050 close(3) = 0
15 [...]
16 0.000057 futex(0x29ab44, FUTEX_WAKE_PRIVATE, 2147483647) = 0
17 0.000256 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
18 0.000089 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
19 0.000107 gettimeofday({1325605320, 167025}, NULL) = 0
20 0.000072 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
21 0.000083 send(3, "\363\337\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
22 0.000322 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
23 2.061369 ioctl(3, FIONREAD, [121]) = 0
24 0.000111 recvfrom(3, "\363\337\201\203\0\1\0\0\0\1\0\0\0011\003112\003168\003192\7in-ad"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, [16]) = 121
25 0.000155 close(3) = 0
26 0.000090 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
27 0.000377 fstat64(3, {st_mode=S_IFREG|0644, st_size=439, ...}) = 0
28 0.000089 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf22000
29 0.000057 read(3, "127.0.0.1\tpacman1.onlinedomus.ne"..., 4096) = 439
30 0.000130 close(3) = 0
31 [...]
32 0.000072 semop(753664, {{7, 1, 0}}, 1) = 0
33 0.000069 semop(753664, {{7, 1, 0}}, 1) = 0
34 0.007558 semop(753664, {{5, -1, 0}}, 1
Note-se que para facilitar a análise, adicionei números de linhas e diferenças de tempos entre cada uma das chamadas a funções de sistema (isto será importante adiante). Vamos explicar o que vemos:
- Na linha 1) tempos um semop() que é a forma de o VP MSC ficar inactivo, à espera de ser solicitado. Isto foi antes da tentativa de conexão
- 7 segundos depois, acorda e tenta "falar" com o serviço nscd (linhas 2-8). Este serviço é algo específico do Linux e eu não o tenho a correr. Depois acede a /etc/nsswitch.conf. Fixe que isto foi feito na primeira tentativa de conexão.
- Depois acede ao ficheiro /etc/resolv.conf (linhas 9-15) e descobre os endereços IP dos servidores de DNS
- Nas linhas 16-25 fala com o servidor de DNS (192.168.112.2) e pede o nome do endereço IP que se está a tentar ligar (obtido pela estrutura do socket)
- Como a resposta é inconclusiva, vai ao ficheiro /etc/hosts (linhas 26-31)
- Cortei a parte restante, relativa à autenticação (abertura do /etc/passwd, /etc/group e /etc/shadow etc.)
- Finalmente retorna ao normal estado de espera
Alguns pontos importantes sobre isto:
Tudo aconteceu bastante depressa (valores em segundos)
- Não vemos a chamada à função gethostbyaddr() que eu garanti que era chamada pelo Informix. Na perspectiva do strace esta não é uma "system call". Só vemos chamadas de mais baixo nível, mas não a gethostbyaddr(). Podemos apanhá-la se ligar-mos um debugger (dbx, gdb, adb) ao processo. Isto é importante, pois é habitual ser difícil discutir este tema com os administradores de rede e sistema operativo, pois pensam que todas estas chamadas são feitas pelo Informix. Não são! O Informix apenas chama a gethostbyaddr() ou equivalente
Agora vamos ver o mesmo processo, mas para a segunda tentativa de conexão. Seria de esperar que o resultado fosse o mesmo, mas não é. Cortei exactamente as mesmas zonas:
1 0.000000 semop(753664, {{5, -1, 0}}, 1) = 0
2 6.452154 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
3 0.000099 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
4 0.008816 gettimeofday({1325605445, 534040}, NULL) = 0
5 0.000089 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
6 0.000100 send(3, "\233\t\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
7 0.000417 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
8 2.089726 ioctl(3, FIONREAD, [121]) = 0
9 0.000118 recvfrom(3, "\233\t\201\203\0\1\0\0\0\1\0\0\0011\003112\003168\003192\7in-ad"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, [16]) = 121
10 0.000132 close(3) = 0
11 0.000069 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
12 0.000102 fstat64(3, {st_mode=S_IFREG|0644, st_size=439, ...}) = 0
13 0.000092 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xe1f000
14 0.000064 read(3, "127.0.0.1\tpacman1.onlinedomus.ne"..., 4096) = 439
15 0.000099 close(3) = 0
16 [...]
17 0.000068 semop(753664, {{0, 1, 0}}, 1) = 0
18 0.000096 semop(753664, {{0, 1, 0}}, 1) = 0
19 0.000076 semop(753664, {{5, -1, 0}}, 1
Novamente a análise:
- A primeira parte de acesso ao servilo nscd, a abertura do /etc/nsswitch.conf e do /etc/resolv.conf não aparece. Como se pode ver começa logo com a consulta ao DNS
- Depois lê o ficheiro /etc/hosts
- Voltei a cortar a parte da autenticação como anteriormente
- Finalmente regressa ao estado de espera, tal como anteriormente
O ponto importante a reter é que a primeira tentativa é diferente das subsequentes. E reforço novamente que o Informix apenas chama a gethostbyaddr()... exactamente a mesma chamada de cada vez. Bom... para ser exacto a função que chamamos pode depender da plataforma, mas é sempre a mesma em cada conexão. Como referi acima, apenas com a utilização de um debugger podemos capturar a chamada à gethostbyaddr(). Eu fi-lo e aqui está o resultado:
(gdb) break connect
Breakpoint 1 at 0x95f640
(gdb) continue
Continuing.
Breakpoint 1, 0x0095f640 in connect () from /lib/libpthread.so.0
(gdb) where
#0 0x0095f640 in connect () from /lib/libpthread.so.0
#1 0x00aec9ab in reopen () from /lib/libresolv.so.2
#2 0x00aee542 in __libc_res_nsend () from /lib/libresolv.so.2
#3 0x00aeb24e in __libc_res_nquery () from /lib/libresolv.so.2
#4 0x002b6dc7 in _nss_dns_gethostbyaddr2_r () from /lib/libnss_dns.so.2
#5 0x002b6f1a in _nss_dns_gethostbyaddr_r () from /lib/libnss_dns.so.2
#6 0x0020890b in gethostbyaddr_r@@GLIBC_2.1.2 () from /lib/libc.so.6
#7 0x00211f77 in getnameinfo () from /lib/libc.so.6
#8 0x08c0e664 in ifx_getipnodebyaddr ()
#9 0x08c0f79c in ifx_gethostbyaddr ()
#10 0x08c0f8a2 in __osgethostbyaddr ()
#11 0x08b0c055 in aio_workon ()
#12 0x08b0c9c3 in aiothread ()
#13 0x08b0dbcb in iothread ()
#14 0x08b00762 in startup ()
#15 0x558749e8 in ?? ()
#16 0x00000000 in ?? ()
(gdb)
Como pode ver, estabeleci um
breakpoint na função
connect(). Depois executei o
continue para que o processo prosseguisse e tentei a conexão. O
debugger interrompeu a execução quando chegou ao
connect() e isso permitiu-me retirar um
stack trace (ler de baixo para cima)
Portanto, mostra-nos que chamamos a função getnameinfo() que por sua vez chama a gethostbyaddr_r() etc. Tudo isto está contido em bibliotecas de sistema, não no código Informix.
Há mais dois pontos a salientar. Primeiro, o processador virtual do Informix da classe MSC processa os pedidos de forma sequencial. Para cada conexão é-lhe pedido que efectue o DNS inverso (pedindo aos servidores DNS ou lendo o ficheiro /etc/hosts) e faça a autenticação. Por omissão apenas temos um MSC... portanto se um pedido ficar "preso"... sim... os que vierem a seguir irão sofrer atrasos. Estes atrasos podem ser uma fracção de segundo ou alguns segundos, mas em alguns sistemas já observei dezenas de conexões por segundo (já vi referências a centenas/segundo). Portanto mesmo um atraso de alguns segundos pode ter um impacto muito notório.
O segundo ponto refere-se à diferença entre a primeira chamada e as seguintes. Como vimos acima, na primeira chamada é verificada a configuração (ficheiros /etc/nsswitch.conf e /etc/resolv.conf). Nas seguintes tal não acontece por razões de
performance. E isto causa um problema. Novamente, este comportamento é das funções de sistema, não do Informix (mas não será necessariamente o fim da história)
Portanto, espero que tenha conseguido explicar como é que o Informix interage com o sistema de DNS. O mergulho nos bits e bytes já terminou. Vamos prosseguir para as implicações, mas é importante que tenha ficado claro o que foi explicado acima antes de prosseguir para os próximos parágrafos.
Que problemas podemos enfrentar?
Acima tentei demonstrar como as coisas funcionam quando está tudo ok. Mas o que acontece quando algo está mal? Vamos ver o que pode correr mal e quais as implicações. Tentarei também tentar indicar de quem será a responsabilidade (mais uma vez relembro o termo de desresponsabilização...). O objectivo não é propriamente apontar o dedo a ninguém, mas saber onde é que o problema reside é meio caminho andado para o resolver.
- Problemas de rede impedem a conexão aos servidores de DNS
Se isto acontecer, os pedidos enviados pelo VP MSC terão de dar timeout (tipicamente alguns segundos) antes que as chamadas às funções de sistema operativo retornem. Este atraso irá causar que todos os pedidos de conexão seguintes fiquem em espera (assumindo que só temos um MSC VP). Se os problemas de rede persistirem, não irá importar muito quantos processadores de classe MSC temos, pois à partida todos eles irão ficar presos e todos os pedidos de conexão sofrerão atrasos.
- O(s) servidor(es) de DNS caem, são parados ou ficam muito lentos
O efeito disto é em tudo semelhante ao anterior. Qualquer coisa que cause atrasos nos pedidos aos DNS irá potenciar atrasos nas conexões ao motor. Note-se que isto pode ser um problema que afecte todos os pedidos, ou apenas alguns. Devido à natureza hierárquica e distribuída da estrutura de DNS, pode ser possível responder a alguns pedidos e não a outros por estes levarem a contactos com determinados servidores que possam não estar disponíveis. Escusado referir que isto torna a investigação destes problemas ainda mais difícil.
- Algo afecta o sistema de DNS. Os pedidos de DNS inverso falham e isto afecta as conexões trusted
Neste caso começam a aparecer erros -956 no online.log da instância e os clientes começam a receber o erro -951. Naturalmente isto acontece se as relações de confiança estiverem definidas com nomes em vez de endereços IP (o uso de nomes é o mais normal e recomendado, dado que é mais frequente mudar um IP que o nome)
- Precisa de mudar os seus servidores de DNS
Então terá de parar e arrancar o Informix. Isto é um problema causado pelo Informix (podía-mos fazer melhor). Como referido acima, as funções de sistema operativo fazem cache da configuração (seria muito ineficiente re-verificar a configuração em cada pedido). E esta situação leva a que o Informix não se "aperceba" que os servidores de DNS foram mudados. Portanto o problema é que se mudarmos a politica de resolução (/etc/nsswitch.conf) ou os servidores (/etc/resolv.conf) os processos de Informix não terão isso em conta
Dos problemas acima é fácil de entender que os três primeiros não são "culpa" do Informix. Quando um cliente decide usar uma infra-estrutura de DNS (supostamente porque necessita) terá de entender que isso passa automaticamente a ser um componente critico dos seus sistemas. Qualquer problema que essa infra-estrutura tenha vai afectar as camadas acima como os servidores de base de dados e outros.
E assim ficamos com o quarto problema. Escrevi atrás e é verdade que o comportamento é das funções de sistema operativo (e vou demonstrá-lo), portanto porque é que digo que a responsabilidade é do Informix? Bom, porque existe uma forma de lidar com isto. Há uma outra função de sistema chamada res_init() que faz aquilo que necessitamos. Do manual de Linux, cito (sem tradução):
The res_init() function reads the configuration files (see resolv.conf(5)) to get the default domain name, search order and name server address(es).
If no server is given, the local host is tried. If no domain is given, that associated with the local host is used. It can be overridden with the environment variable LOCALDOMAIN. res_init() is normally executed by the first call to one of the other functions.
A minha opinião é que o Informix deveria providenciar uma forma pela qual o DBA poderia forçar que cada processador virtual da classe MSC chamasse esta função. Isto refrescaria a informação obtida na primeira chamada à gethostbyaddr() que é mantida em cache no espaço do processo.
Na verdade a IBM tem um pedido de funcioalidade pendente que refer isto explicitamente. Gostaria bastante de o ver implementado numa versão futura. Isto é algo sem o qual podemos viver durante anos, mas se a situação se coloca pode realmente fazer a diferença entre ter de parar o servidor de base de dados ou não.
Detectar se temos um problema
Como podemos saber se temos um problema de DNS e isso está a ter impacto no Informix? Habitualmente iremos receber algum tipo de queixa dos clientes/aplicações Informix. Tipicamente algo como "a base de dados está muito lenta", ou algo mais correcto como "leva muito tempo a estabelecer uma conexão", ou eventualmente algumas sessões serão recusadas com o erro -956 (do lado do servidor) que corresponde a um erro -951 retornado ao cliente. Nos casos mais extremos podem aparecer erros menos comuns no
online.log (-25xxx). Em todos estes casos notará que depois de estabelecidas as ligações estas trabalham sem problemas.
Mas para ter a certeza absoluta pode seguir dois caminhos:
- O mais simples é correr um simples "netstat -a" na máquina onde reside o servidor de base de dados. Isto mostra todas as ligações TCP/UDP de e para a máquina. Por omissão, vai percorrer todas as ligações socket e tentará fazer o pedido de DNS inverso sobre o respectivo endereço IP para obter os nomes das máquinas. Se estiver a ter problemas de DNS o netstat irá correr muito lento ou pelo menos verificará alguns "soluços" no output do mesmo. Mas para que este teste seja conclusivo, tem de garantir que as configurações de DNS que o netstat vai usar são as mesmas que o motor Informix está a usar (que serão as que tinha quando o motor foi levantado)
- O mais complexo passa por executar um comando "truss" ou "strace" contra o(s) processo do processador virtual de classe MSC, com apresentação de tempos. Isto permitirá mostrar tempos de resposta lentos das funções que trocam informação com os servidores de DNS. Tenha em atenção que correr o truss/strace requer privilégios de root e que mesmo quando tudo está a correr bem, isto causará algum impacto em sistemas com uma taxa de novas ligações por segundo elevada.
Escrevia atrás que posso demonstrar os factos apresentados aqui sem usar o Informix. Para tal criei um pequeno programa em C (números de linha adicionados):
1 #include <sys/time.h>
2 #include <netdb.h>
3 #include <resolv.h>
4 #include <stdlib.h>
5 #include <string.h>
6
7 int main(int argc, char **argv)
8 {
9 struct hostent *hp;
10 in_addr_t data;
11 char buff[100];
12 struct timeval ts_initial, ts_final;
13
14 if (argc == 2) {
15 strcpy(buff,argv[1]);
16 }
17 else {
18 printf("Introduce an IP address: ");
19 if (fscanf(stdin,"%s", buff) == EOF)
20 exit(0);
21 }
22
23 while (1 == 1) {
24 data = inet_addr(buff);
25 gettimeofday(&ts_initial, NULL);
26 hp = gethostbyaddr(&data, 4, AF_INET);
27 gettimeofday(&ts_final, NULL);
28
29 if (hp == NULL) {
30 printf("Unknown host (%s). Took %f seconds\n", buff, (double)((ts_final.tv_sec * 1000000 + ts_final.tv_usec) - (ts_initial.tv_sec * 1000000 + ts_initial.tv_usec))/1000000);
31 }
32 else {
33 printf("Name (%s): %s Took %f seconds\n", buff, hp->h_name, (double)((ts_final.tv_sec * 1000000 + ts_final.tv_usec) - (ts_initial.tv_sec * 1000000 + ts_initial.tv_usec))/1000000);
34 }
35 printf("Next: ");
36 if (fscanf(stdin,"%s", buff) == EOF)
37 exit(0);
38 if ( strncmp("refresh", buff, 7) == 0 )
39 {
40 res_init();
41 printf("Called res_init()\n");
42 printf("Next: ");
43 if (fscanf(stdin,"%s", buff) == EOF)
44 exit(0);
45 }
46 }
47 }
Isto é basicamente um ciclo que lê um endereço IP (que não é validado, portanto é fácil de causar erros no programa) e corre a gethostbyaddr() sobre o mesmo. Se o "IP" dado fôr "refresh" então chama a função res_init(). Informa das respostas obtidas pelo sistema de resolução de nomes e o tempo que demorou. Pode ser usado interactivamente ou podemos chamá-lo redireccionando o
input de um ficheiro que contenha um endereço IP em cada linha.
Vou executá-lo interactivamente com tracing para mostrar o efeito de chamar a função res_init(). Tenho "hosts: dns, files" no ficheiro /etc/nsswitch.conf e 192.168.112.2 no /etc/resolv.conf. Este último contém também opções para definir um
timeout de 2 segundos. Portanto chamo-o com:
cheetah@pacman1.onlinedomus.net:fnunes-> strace -r -o test_resolv.trace ./test_resolv
Introduce an IP address: 1.1.1.1
Unknown host (1.1.1.1). Took 2.010235 seconds
Next: 1.1.1.2
Unknown host (1.1.1.2). Took 2.003324 seconds
Next: refresh
Called res_init()
Next: 1.1.1.3
Unknown host (1.1.1.3). Took 2.004002 seconds
Next: ^C
Antes de introduzir "refresh" mudo o servidor de DNS no ficheiro /etc/resolv.conf de 192.168.112.2 para 192.168.112.5.
O resultado do
trace é este (números de linha e tempos adicionados):
1 [...]
2 0.000000 write(1, "Introduce an IP address: ", 25) = 25
3 0.000000 read(0, "1.1.1.1\n", 1024) = 8
4 3.055699 gettimeofday({1325865284, 104186}, NULL) = 0
5 [...]
6 0.000160 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
7 0.000099 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
8 0.000128 close(3) = 0
9 0.000053 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
10 0.000123 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ECONNREFUSED (Connection refused)
11 0.000122 close(3) = 0
12 0.000095 open("/etc/nsswitch.conf", O_RDONLY) = 3
13 0.000108 fstat64(3, {st_mode=S_IFREG|0644, st_size=1803, ...}) = 0
14 0.000101 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
15 0.000057 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1803
16 0.000001 read(3, "", 4096) = 0
17 0.000000 close(3) = 0
18 [...]
19 0.000055 open("/etc/resolv.conf", O_RDONLY) = 3
20 0.000072 fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
21 0.000095 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
22 0.000050 read(3, "# Generated by NetworkManager\nna"..., 4096) = 118
23 0.000086 read(3, "", 4096) = 0
24 0.000046 close(3) = 0
25 [...]
26 0.000173 open("/etc/host.conf", O_RDONLY) = 3
27 0.000068 fstat64(3, {st_mode=S_IFREG|0644, st_size=26, ...}) = 0
28 0.000081 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
29 0.000179 read(3, "multi on\norder hosts,bind\n", 4096) = 26
30 0.000083 read(3, "", 4096) = 0
31 0.000048 close(3) = 0
32 0.000049 munmap(0xb7843000, 4096) = 0
33 0.000160 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
34 0.000075 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
35 0.000640 gettimeofday({1325865284, 108850}, NULL) = 0
36 0.000062 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
37 0.000094 send(3, "r\363\1\0\0\1\0\0\0\0\0\0\0011\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
38 0.000889 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
39 2.003373 close(3) = 0
40 0.000109 open("/etc/ld.so.cache", O_RDONLY) = 3
41 0.000078 fstat64(3, {st_mode=S_IFREG|0644, st_size=72238, ...}) = 0
42 0.000093 mmap2(NULL, 72238, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7821000
43 0.000054 close(3) = 0
44 [...]
45 0.000105 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
46 0.000097 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
47 0.000065 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
48 0.000053 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
49 0.000035 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
50 0.000137 read(3, "", 4096) = 0
51 0.000130 close(3) = 0
52 [...]
53 0.000101 write(1, "Unknown host (1.1.1.1). Took 2.0"..., 46) = 46
54 0.000071 write(1, "Next: ", 6) = 6
55 0.000267 read(0, "1.1.1.2\n", 1024) = 8
56 0.000071 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
57 0.000077 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
58 0.000049 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
59 0.000063 send(3, ":\243\1\0\0\1\0\0\0\0\0\0\0012\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
60 0.000152 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
61 2.002550 close(3) = 0
62 0.000088 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
63 0.000077 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
64 0.000092 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
65 0.000057 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
66 0.000110 read(3, "", 4096) = 0
67 0.000049 close(3) = 0
68 [...]
69 0.000060 write(1, "Unknown host (1.1.1.2). Took 2.0"..., 46) = 46
70 0.000076 write(1, "Next: ", 6) = 6
71 0.000253 read(0, "refresh\n", 1024) = 8
72 17.639011 open("/etc/resolv.conf", O_RDONLY) = 3
73 0.000088 fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
74 0.000087 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
75 0.000052 read(3, "# Generated by NetworkManager\n#n"..., 4096) = 118
76 0.000108 read(3, "", 4096) = 0
77 0.000047 close(3) = 0
78 0.000048 munmap(0xb7843000, 4096) = 0
79 0.000065 write(1, "Called res_init()\n", 18) = 18
80 0.000060 write(1, "Next: ", 6) = 6
81 0.000051 read(0, "1.1.1.3\n", 1024) = 8
82 3.595382 gettimeofday({1325865312, 174933}, NULL) = 0
83 0.000075 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
84 0.000078 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.5")}, 16) = 0
85 0.000266 gettimeofday({1325865312, 175350}, NULL) = 0
86 0.000052 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
87 0.000069 send(3, "\321\234\1\0\0\1\0\0\0\0\0\0\0013\0011\0011\0011\7in-addr\4arp"..., 38, MSG_NOSIGNAL) = 38
88 0.000085 poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
89 2.002271 close(3) = 0
90 0.000081 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
91 0.000076 fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
92 0.000087 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7843000
93 0.000054 read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
94 0.000091 read(3, "", 4096) = 0
95 0.000047 close(3) = 0
96 0.000048 munmap(0xb7843000, 4096) = 0
97 0.000062 gettimeofday({1325865314, 178373}, NULL) = 0
98 0.000058 write(1, "Unknown host (1.1.1.3). Took 2.0"..., 46) = 46
99 0.000072 write(1, "Next: ", 6) = 6
100 0.000053 read(0, 0xb7844000, 1024) = ? ERESTARTSYS (To be restarted)
101 0.918564 --- SIGINT (Interrupt) @ 0 (0) ---
102 0.000931 +++ killed by SIGINT +++
E a explicação:
Hacking só por brincadeira!
Por favor não tente isto em casa! Atenção, o que vem a seguir é arriscado, não suportado e apresentado apenas para provar um ponto de vista. Argumentei acima que chamar a função res_init() permitiria que se mudasse os endereços dos servidores DNS sem parar e arrancar o Informix. Vamos prová-lo!
Fiz novamente
trace a uma conexão, olhando para o processo do processador virtual da classe MSC. Obtive isto:
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.2")}, 16) = 0
gettimeofday({1326038028, 174740}, NULL) = 0
poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
send(3, "+\316\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
close(3) = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x12f000
read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
close3)
Está a ligar-se ao 192.168.112.2, que é o servidor DNS definido no /etc/resolv.conf. Se eu mudar isso no ficheiro para 192.168.112.5 e tentar novamente, acontece o mesmo (não se apercebe da mudança). Mas agora, sem mais alterações no ficheiro, se correr um
debugger contra o processo do MSC:
[root@pacman tmp]# gdb -p 4649
GNU gdb (GDB) Fedora (7.1-18.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http: bugs="" gdb="" software="" www.gnu.org="">.
Attaching to process 4649
Reading symbols from /usr/informix/srvr1170uc4/bin/oninit...(no debugging symbols found)...done.
[...]
(gdb) call __res_init()
$1 = 0
(gdb) detach
Detaching from program: /usr/informix/srvr1170uc4/bin/oninit, process 4649
(gdb) quit
[root@pacman tmp]#
Se fizer um "call", ou seja chamar a função, a __res_init() que verifiquei ser o nome interno da função definida na libc.so e fizer um novo
trace a uma conexão obtenho:
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.112.5")}, 16) = 0
gettimeofday({1326038409, 784712}, NULL) = 0
poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
send(3, "\364K\1\0\0\1\0\0\0\0\0\0\0011\003112\003168\003192\7in-ad"..., 44, MSG_NOSIGNAL) = 44
poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
close(3) = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=438, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x12f000
read(3, "127.0.0.1\tpacman.onlinedomus.net"..., 4096) = 438
close(3)
Ups!
Hacked!... Claro que isto não é suportado. Não tente isto numa instância "real". Apenas serve para provar uma teoria.
Conclusões
O que tentei demonstrar neste artigo é como o Informix interage com os serviços de DNS, se os mesmos estiverem configurados no seu ambiente. Espero ter deixado claro que uma vez activo, o DNS toma um papel muito importante no estabelecimento de ligações. Tanto que um mau funcionamento do DNS terá um impacto muito significativo no sistema de gestão de base de dados. Há alguns pontos em que se pode atribuir responsabilidade ao Informix. Em particular:
- O facto de os pedidos de DNS inverso serem feitos pelo processador virtual da class MSC pode gerar atrasos em pedidos que poderiam correr bem, apenas porque um pedido anterior teve um problema. Ter mais de um processador virtual MSC pode aliviar isto significativamente, mas poderá não resolver por completo
- O facto de o Informix não estabelecer timeouts na chamada à gethostbyaddr() - ou equivalente -pode também causar atrasos desnecessários. Mas note-se que a assinatura das funções não tem nada que o permita, e portanto seria necessário criar um alarme que enviasse um sinal ao processo, e que este verificasse se ainda estava à espera da chamada. Isto traria um peso adicional que não faz muito sentido, especialmente quando os timeouts podem ser configurados na configuração geral dos servidores de DNS
- O facto de as funções chamadas fazerem cache das configurações, aliado ao facto de o Informix não proporcionar uma forma de limpar essa cache (havendo funcionalidades de baixo nível que o permitem), significa que uma mudança nos endereços de DNS requerem uma paragem e arranque do motor Informix. Existe um pedido de funcionalidade registado para isto e muito me agradaria que fosse implementado
Por outro lado, o Informix 11.7 introduziu uma excelente funcionalidade que permite aliviar quase todos os problemas.Com o parâmetro NS_CACHE podemos configurar tempos de
caching para vários sistemas (DNS, utilizadores/passwords, serviços...). Isto pode reduzir ao mímino o número de pedidos que são feitos. Naturalmente sempre que lidamos com
caches temos o risco de lidar com informação desactualizada, mas neste caso limpar as
caches é tão simples quanto correr o comando "onmode -wm NS_CACHE=..." e indicar um
timeout de zero segundos. Já agora, este seria um bom sitio/momento para forçar a chamada da função res_init()...
Para fechar o artigo gostaria de mencionar algumas boas práticas:
- Usar o Informix 11.7 se possível, para que possa tirar proveito do sistema de caching. Os administradores de sistema e/ou de DNS irão apreciar isto se tiver uma taxa de novas ligações muito alta
- Considerar incluir "files" no ficheiro de configuração /etc/nsswitch.conf. Algumas pessoas podem considerar isto uma má ideia, pois pode causar muita actividade sobre o ficheiro /etc/hosts. Mas se as consultas ao ficheiro só forem feitas se os DNS não responderem, e o ficheiro fôr mantido com poucas entradas, e idealmente se usar o sistema de cache do Informix 11.7 o impacto adicional será negligenciável. E isto pode salvá-lo, caso tenha problemas nos DNS, pois temporariamente poderia adicionar entradas a este ficheiro, permitindo assim que a resolução de nomes fosse feita. Note que pelo menos no meu sistema de testes (Linux), mesmo a chamada à função res_init() não força a leitura novamente do ficheiro /etc/nsswitch.conf
- Faça com que os seus administradores de DNS e os DBAs se entendam... Terão de trabalhar em conjunto e têm de entender que os seus serviços estão intimamente ligados
- Use o Informix 11.7 se puder, para que possa usar o parâmetro REMOTE_SERVER_CFG. Em muitas empresas os DBAs não têm permissões para gerir o /etc/hosts.equiv (ficheiro de sistema). Se tiver um problema de DNS que impossibilite as conversões de endereços IP em nomes, as suas relações de confiança irão ser afetadas se estiverem definidas com nomes.e não endereços (o normal). Numa situação de emergência poderá ser útil que o DBA possa agir imediatamente e temporariamente adicionar os endereços IP ao ficheiro que estabelece as reações de confiança. Com o REMOTE_SERVER_CFG isso será possível sem privilégios de administrador de sistema
- Use timeouts configurados no /etc/resolv.conf baixos de forma a que o tempo inútil de espera seja menor (uma consulta a um DNS é algo muito rápido)
Posts
