6 votes

Diagnostic de la résolution dns d'AWS EC2

J'utilise des instances EC2 avec amazon linux installé (avec les paramètres du serveur dns d'amazon, qui provient de DHCP), ainsi qu'une base de données RDS. Les instances EC2 sont derrière ELB et reçoivent un trafic élevé. L'application que j'utilise est codée en PHP.

Le problème est que lorsque PHP essaie de se connecter à la base de données RDS, il renvoie parfois l'erreur suivante :

PHP Warning:  mysqli_connect(): (HY000/2005): Unknown MySQL server host ...

Cela ne se produit pas souvent, mais cela s'aggrave parfois ; je reçois des milliers d'événements d'erreur avec ce message.

Y a-t-il une suggestion pour diagnostiquer le problème ? J'ai pensé à vider tout le trafic DNS dans un fichier et à le vérifier, mais les serveurs ont un trafic très élevé et il sera difficile de le suivre à partir de ce fichier.

Ip:
197171459 total packets received
1 with invalid addresses
0 forwarded
0 incoming packets discarded
197171458 incoming packets delivered
175015443 requests sent out
Icmp:
12528 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
    destination unreachable: 188
    echo requests: 12340
12559 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
    destination unreachable: 219
    echo replies: 12340
IcmpMsg:
    InType3: 188
    InType8: 12340
    OutType0: 12340
    OutType3: 219
Tcp:
5231380 active connections openings
3978862 passive connection openings
881 failed connection attempts
6420 connection resets received
17 connections established
191630575 segments received
200105352 segments send out
2797151 segments retransmited
0 bad segments received.
6910 resets sent
Udp:
5577451 packets received
219 packets to unknown port received.
0 packet receive errors
5577700 packets sent
UdpLite:
TcpExt:
172 invalid SYN cookies received
808 resets received for embryonic SYN_RECV sockets
7176788 TCP sockets finished time wait in fast timer
507 packets rejects in established connections because of timestamp
448055 delayed acks sent
2927 delayed acks further delayed because of locked socket
Quick ack mode was activated 2433 times
94865861 packets directly queued to recvmsg prequeue.
16611185 packets directly received from backlog
54150864749 packets directly received from prequeue
2158966 packets header predicted
79141174 packets header predicted and directly queued to user
40780030 acknowledgments not containing data received
56946553 predicted acknowledgments
84 times recovered from packet loss due to SACK data
Detected reordering 4 times using FACK
Detected reordering 11 times using SACK
Detected reordering 69 times using time stamp
70 congestion windows fully recovered
1241 congestion windows partially recovered using Hoe heuristic
TCPDSACKUndo: 13
2491 congestion windows recovered after partial ack
0 TCP data loss events
220 timeouts after SACK recovery
104 fast retransmits
99 forward retransmits
7 retransmits in slow start
2792531 other TCP timeouts
22 times receiver scheduled too late for direct processing
2423 DSACKs sent for old packets
2785871 DSACKs received
5162 connections reset due to unexpected data
921 connections reset due to early user close
135 connections aborted due to timeout
TCPDSACKIgnoredOld: 533
TCPDSACKIgnoredNoUndo: 393
TCPSackShifted: 477
TCPSackMerged: 536
TCPSackShiftFallback: 2709
TCPBacklogDrop: 46
TCPDeferAcceptDrop: 3906058
IpExt:
InOctets: 69400712361
OutOctets: 94841399143

4voto

Chris Adams Points 290

Il existe un bogue AWS connu qui provoque l'échec sporadique de la résolution DNS :

https://forums.aws.amazon.com/thread.jspa?messageID=330465#330465

Vous pourriez vouloir tester avec des connexions persistantes, car cela réduirait la fréquence à laquelle la résolution DNS est effectuée.

Un cache DNS local (par ex. pdns-recursor o dnscache ) réduira la fréquence, mais les enregistrements de noms d'hôtes RDS ont des TTL très courts (60 secondes), ce qui signifie que le problème se produira beaucoup moins fréquemment, mais toujours plusieurs fois par jour.

0voto

polynomial Points 3908

Vous parlez de trafic élevé. Je me demande si vous ne rencontrez pas des problèmes de réseau. Surveillez-vous déjà les statistiques SNMP de votre serveur ? Vous devriez envisager d'établir des tendances pour certaines des valeurs de IF-MIB :

IF-MIB::ifInOctets.1 = Counter32: 117194642
IF-MIB::ifInOctets.2 = Counter32: 3406296104
IF-MIB::ifInOctets.3 = Counter32: 754235769
IF-MIB::ifInOctets.4 = Counter32: 0
IF-MIB::ifInUcastPkts.1 = Counter32: 112415844
IF-MIB::ifInUcastPkts.2 = Counter32: 352495427
IF-MIB::ifInUcastPkts.3 = Counter32: 588414566
IF-MIB::ifInUcastPkts.4 = Counter32: 0
IF-MIB::ifInNUcastPkts.1 = Counter32: 0
IF-MIB::ifInNUcastPkts.2 = Counter32: 5038722
IF-MIB::ifInNUcastPkts.3 = Counter32: 4835908
IF-MIB::ifInNUcastPkts.4 = Counter32: 0
IF-MIB::ifInDiscards.1 = Counter32: 0
IF-MIB::ifInDiscards.2 = Counter32: 0
IF-MIB::ifInDiscards.3 = Counter32: 0
IF-MIB::ifInDiscards.4 = Counter32: 0
IF-MIB::ifInErrors.1 = Counter32: 0
IF-MIB::ifInErrors.2 = Counter32: 0
IF-MIB::ifInErrors.3 = Counter32: 0
IF-MIB::ifInErrors.4 = Counter32: 0

Plus d'informations à ce sujet :

http://www.oidview.com/mibs/0/IF-MIB.html

Vous pouvez également vérifier certaines des statistiques du réseau avec :

# netstat -s

En général, je pense qu'il est préférable d'utiliser les adresses IP dans les fichiers de configuration lorsqu'il s'agit de se référer à d'autres serveurs en production.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X