Récemment, nous avons constaté une série d'échecs intéressants sur notre cluster, où les travaux des utilisateurs échouent par intermittence en raison d'erreurs de connexion, d'erreurs de verrouillage de compte ou d'erreurs de permission de fichier.
Notre cluster est faiblement couplé et à gros grains, construit autour de 40 machines Windows 2003 à 16 voies. Elles participent à un domaine d'entreprise, avec des contrôleurs de domaine locaux et sur le WAN. La soumission des tâches est gérée par une application tierce (ActiveBatch) et le stockage des fichiers est réparti entre un SAN exporté par un serveur Windows 2003 et un partage CIFS plus récent sur un cluster Isilon.
Les tâches sont des graphes acycliques dirigés, composés de 1 à 5 000 processus, programmés sur un nœud principal par ActiveBatch. La plupart des travaux sont de minuscules fichiers batch ou des scripts Perl qui effectuent la configuration de l'environnement pour des codes de calcul écrits en FORTRAN. Les fichiers d'entrée et de sortie de ces travaux sont stockés soit sur le SAN, soit sur l'Isilon.
Nous avons constaté des échecs intermittents de l'authentification, que nous pensions à l'origine être isolés sur l'Isilon. Le mode d'échec général est le suivant : 100 à 200 tâches commencent à s'exécuter, chacune faisant référence à des données de configuration communes dans un fichier. La majorité d'entre eux réussissent, mais plusieurs travaux sur plusieurs machines échouent du côté client avec une erreur de permissions de fichiers (soit 0x775 Le compte référencé est actuellement bloqué... ou 0x52E Nom d'utilisateur inconnu ou mauvais mot de passe ).
La vérification des journaux d'événements pour ces périodes rapporte 0 échec d'audit de sécurité, mais plusieurs succès d'audit de sécurité pour le même utilisateur ! La seule entrée du journal des événements à proximité est un événement 6013 qui nous informe que "le temps de disponibilité du système est de 2199088 secondes".
Récemment, nous avons également constaté la même erreur lorsque le logiciel de planification des tâches tente de créer les tâches sur les machines distantes. ActiveBatch envoie les détails de la tâche à un service fonctionnant sur la machine qui tente ensuite de se faire passer pour l'utilisateur lorsqu'il crée la tâche. Comme pour les échecs d'autorisation de fichiers, nous voyons à la fois des verrouillages de comptes et des utilisateurs/mots de passe inconnus alors que le compte de l'utilisateur n'est ni verrouillé ni inconnu (et en fait, les processus sur la même machine ont réussi peu après ces tentatives ratées).
Je ne suis pas assez familier avec les contrôleurs de domaine, ni n'ai un accès suffisant pour les explorer, pour savoir s'il s'agit ou non d'un problème côté client ou côté serveur. L'absence d'entrées d'échec dans le journal des événements côté client m'amène à penser que l'échec est peut-être dû à un dépassement de délai du DC ou à un problème de réseau. Cependant, une interrogation Wireshark du trafic entre un serveur aléatoire et le DC n'a pas révélé d'incohérences flagrantes en dehors des messages Kerberos Response Too Big occasionnels.
S'agit-il d'un problème courant avec les configurations de contrôleur de domaine où une forte charge d'authentification/impersonnalisation provoque des défaillances transitoires ?
