6 votes

Comment puis-je résoudre les problèmes de réseau avec mon SDV ?

Problème : J'ai parfois des problèmes de réseau avec mon VPS Ubuntu. Je ne peux pas me connecter en SSH à la boîte, je ne peux pas faire de ping avec l'adresse IP. Je peux accéder à la boîte via le terminal série de l'hôte. Lorsque j'accède à la boîte via le terminal série, je ne peux faire de ping nulle part (pour autant que je puisse le dire), même lorsque je fais un ping par adresse IP. Après un certain temps, le réseau se rétablit, parfois sans mon intervention. Parfois, il revient lorsque j'interviens. Mais il est difficile de savoir pourquoi. (Edit : Il est très régulièrement hors service depuis 1 heure)

Questions : Comment puis-je procéder pour résoudre ce problème ? Que puis-je faire pour exclure les problèmes de configuration/logiciels que je peux contrôler afin de me sentir plus à l'aise pour soulever le problème auprès de mon hébergeur ?

Les choses que j'ai essayées :

  • Descendre et remonter eth0
  • Désactiver temporairement le pare-feu
  • J'ai vérifié les avis de l'hébergeur VPS concernant les problèmes de réseau - je n'en ai vu aucun.
  • Redémarrer le serveur via la console Web
  • Note : Aucune de ces méthodes n'a fonctionné pour moi.

Détails :

  • Ubuntu 10.04.1 LTS
  • Hébergé avec la virtualisation Xen
  • Avoir un accès root (SSH) pour effectuer mes propres mises à jour, installations, etc.
  • J'ai configuré le VPS en tant que serveur VPN afin de pouvoir m'y connecter à la manière d'un "guerrier de la route" et de faire transiter tout mon trafic par le VPS en premier. Voilà donc le problème avec 10.8.X.X.
  • Tout le trafic, y compris les recherches DNS, est transféré via le VPS.
  • Utiliser un pare-feu simple (ufw) avec quelques règles de base
  • Joue également le rôle de serveur pour certains services, notamment Mumble et le serveur web.
  • J'ai configuré un script sur le VPS en tant que tâche cron pour envoyer un ping à certaines entités Internet courantes par adresse IP toutes les 5 minutes. Si le ping échoue, il le consigne dans un fichier. C'est assez simple. La coupure du réseau dure systématiquement une heure. Il ne se produit pas toujours au même moment de la journée. Dans la quasi-totalité des cas, le réseau est indisponible pendant une heure, puis il revient "comme par magie".
  • L'utilisation de la mémoire sur mon VPS est généralement très élevée. En général, je suis au maximum et j'utilise un peu de swap. Le monstre de la mémoire est java, si cela peut aider.
  • Mon fournisseur d'accès n'a pas été d'une grande aide. Sa réponse va de "nous sommes désolés, nous avons eu un problème malheureux" à "il n'y a plus de problème maintenant". C'est frustrant pour moi car, en général, je fais un ticket lorsqu'il y a un problème, mais le problème a disparu le temps que le ticket soit traité. La communication la plus récente a été qu'ils suggèrent de reformater mon VPS et de recommencer à zéro, ce qui ne m'enchante pas.
  • Les pannes de réseau se produisent régulièrement à l'heure près (dans les 5 à 10 minutes). En d'autres termes, les pannes de réseau ne commencent pas vers XX:30, XX:45, etc.

netstat -rn

    Kernel IP routing table  
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface  
    10.8.0.2        0.0.0.0         255.255.255.255 UH        0 0          0 tun0  
    XX.57.166.0     0.0.0.0         255.255.255.128 U         0 0          0 eth0  
    192.168.50.0    10.8.0.2        255.255.255.0   UG        0 0          0 tun0  
    10.8.0.0        10.8.0.2        255.255.255.0   UG        0 0          0 tun0  
    0.0.0.0         XX.57.166.1     0.0.0.0         UG        0 0          0 eth0  

ip route list

    10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1  
    XX.57.166.0/25 dev eth0  proto kernel  scope link  src XX.57.166.59  
    192.168.50.0/24 via 10.8.0.2 dev tun0  
    10.8.0.0/24 via 10.8.0.2 dev tun0  
    default via XX.57.166.1 dev eth0  metric 100

cat /etc/network/interfaces

    auto eth0  
    iface eth0 inet static  
        address XX.57.166.59  
        gateway XX.57.166.1  
        netmask 255.255.255.128  
    auto lo  
    iface lo inet loopback

2voto

Mufaka Points 54

Tout d'abord, si vous pensez qu'il s'agit d'un problème de fournisseur qu'ils n'abordent pas, j'envisagerais fortement de migrer ailleurs. J'ai accordé à VPS.net le bénéfice du doute lorsque leur SAN ne cessait de tomber en panne (entraînant l'arrêt de tous les VPS dans le processus), mais après quelques mois de "Nous avons résolu ce problème pour de bon" et qu'il continue de tomber en panne, j'ai dû voter avec mon porte-monnaie.

Il est étonnamment facile de créer une société VPS (il suffit d'un peu d'espace dans un centre de données et de quelques serveurs), de sorte qu'ils ne sont pas tous égaux en termes de compétences techniques, même avant le service à la clientèle.

Mais pour aller au fond du problème, je chercherais d'abord à empêcher que les choses ne finissent dans un échange. Laissez le swap activé, mais faites ce qu'il faut pour ne pas pousser les choses aussi loin. Réduisez l'application Java ou ajoutez de la RAM. Et voyez ce qui se passe. Si c'est très régulier, vous ne devriez pas avoir à attendre longtemps (ou à payer beaucoup) pour voir un résultat.

Idem pour l'unité centrale. Si certains éléments fonctionnent à 100 % pendant de longues périodes, vous devez vous assurer qu'ils n'interfèrent pas avec d'autres applications. La façon la plus simple d'y parvenir est de fixer la valeur agréable de toutes les applications qui tournent à plein régime à quelque chose de positif. Une valeur de +10 devrait permettre au système d'avoir une priorité totale sur les ressources avant vos applications. Encadré : Les valeurs "nice" signifient essentiellement qu'elles sont plus polies lorsqu'il s'agit d'ordonnancer le processeur. Une valeur faible (par exemple -20) signifie qu'elle sera prioritaire sur toutes les autres choses dont la valeur est plus élevée.

Si vous le pouvez, étendez vos tests à d'autres éléments du réseau local. S'ils fournissent un résolveur DNS (comme le font de nombreuses sociétés de serveurs), envoyez-lui un ping en permanence (plusieurs fois par minute) et enregistrez les résultats. Si vous pouvez toujours y accéder pendant les périodes d'indisponibilité, il est moins probable que ce soit votre faute.

Et comme je l'ai dit, si ce n'est pas de votre faute, déménagez. Si vous passez plus de temps à essayer d'arranger les choses, vous l'emportez sur tout avantage concevable de rester avec ces personnes. Personnellement, j'ai une très bonne et longue expérience avec Linode, mais il y a beaucoup de bonnes entreprises sur le marché.

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