Dépannage des partages de fichiers et d'ArcGIS Enterprise

DannyKrouk_ps

Introduction

Les architectures ArcGIS Enterprise ont souvent des exigences concernant l'utilisation de partages de fichiers pour le stockage de fichiers de configuration partagés, de contenu ou de sauvegardes (https://enterprise.arcgis.com/en/server/latest/install/windows/choosing-a-nas-device.htm). Cela est particulièrement vrai lorsque le modèle de déploiement implique des sites multi-machines (comme les configurations à haute disponibilité). Il existe des utilisations des partages de fichiers dans chacun des principaux composants d'ArcGIS Enterprise (Portal for ArcGIS, ArcGIS Server et ArcGIS Data Store).

Dans le schéma ci-dessous, le « Shared Content » et le « Shared Config-store and Directories » sont situés sur un partage de fichiers :

 

Les partages de fichiers existent en plusieurs types et variétés, allant des dispositifs matériels physiques aux systèmes de fichiers virtuels ou autres fournisseurs. Les systèmes de fichiers partagés offrent un moyen efficace de partager du contenu entre plusieurs composants, mais ils peuvent aussi introduire des défis liés à la performance, aux permissions ou à la cohérence au niveau des fichiers.

Lorsqu'il y a des problèmes dans un déploiement ArcGIS Enterprise, et que vous suspectez qu'ils peuvent être liés au stockage partagé, il peut être difficile de savoir comment évaluer votre architecture pour détecter d'éventuels défis et quoi faire à ce sujet. En pratique, résoudre un problème de partage de fichiers peut être complexe, mais vos chances de succès sont bien meilleures si vous établissez une métrique ou une mesure spécifique à utiliser pour définir, créer une base de référence et tester le problème suspecté. Cet article est conçu pour vous aider à déterminer s'il existe un problème de partage de fichiers dans votre déploiement ArcGIS Enterprise, quels symptômes et indicateurs pourraient pointer vers ce type de problème (sa signature), et comment enquêter sur la cause racine.

Bien que des principes similaires s'appliquent aux systèmes Linux/NFS et Windows/SMB, les détails de cet article se concentrent sur les systèmes Windows/SMB.

Comment ArcGIS Enterprise utilise-t-il un partage de fichiers ?

Il existe plusieurs façons dont ArcGIS Enterprise utilise un partage de fichiers, notamment :

1. Un référentiel de données enregistré dans un site ArcGIS Server
2. Un emplacement partagé pour les sauvegardes d'ArcGIS Data Store
3. Un emplacement pour le stockage et l'extraction des sauvegardes WebGISDR pour les workflows de reprise après sinistre
4. Un emplacement pour stocker le « config-store » et les « server directories » d'un site ArcGIS Server multi-machines
5. Un emplacement pour stocker le « content directory » d'un site portail ArcGIS Enterprise à haute disponibilité

Les deux derniers sont le focus de cet article ; dans ces cas, le partage de fichiers joue un rôle dans la façon dont chaque machine du site multi-machines sait ce qui se passe. Métaphoriquement, le partage de fichiers agit comme une partie du « système nerveux » du portail ArcGIS Enterprise ou du site ArcGIS Server lorsqu'il supporte le « config-store », les « server directories » ou le « content directory ». Donc, s'il y a un problème avec le partage de fichiers, le site ArcGIS Server ou Portal for ArcGIS peut afficher une grande variété de symptômes intermittents, tels que des difficultés à publier des services ou une « instabilité » du serveur.

Reconnaître et enquêter sur un problème lié à un partage de fichiers

L'analyse d'un potentiel problème de partage de fichiers peut commencer en solo, en examinant les journaux logiciels pour chaque composant logiciel ArcGIS. Cependant, si vous trouvez des preuves indiquant des problèmes liés à l'accès aux fichiers, vous devrez travailler avec d'autres sources d'information ou composants logiciels. Cela impliquera probablement de collaborer avec d'autres personnes, car les privilèges d'accès requis et les connaissances sont rarement concentrés chez une seule personne.

Cet article décrit ce que vous pouvez poursuivre avec différents ensembles de privilèges et connaissances. Nous commençons par les journaux dans ArcGIS Enterprise pour deux raisons : premièrement, nous supposons que vous avez ces privilèges — et deuxièmement, c'est là que vous faites la détermination initiale s'il y a lieu de croire qu'il y a un problème avec le partage de fichiers et quelle en est la raison.

Fondations

Avant de commencer, vous voulez vous préparer pour être aussi productif que possible en choisissant un environnement approprié, en contrôlant la complexité et en constituant la bonne équipe.

Environnements

Vous devriez essayer d'utiliser des « environnements inférieurs » (autrement dit, pas votre environnement production) si vous pouvez observer les problèmes dans ces systèmes. Quel que soit le problème que vous voyez en production, utilisez les journaux d'ArcGIS Server pour comprendre sa signature. Trouver cette signature est discuté ci-dessous. Ensuite, regardez dans votre environnement staging, test ou UAT pour voir si vous pouvez trouver la même signature. Notez que vous devrez peut-être générer une certaine activité dans cet environnement pour voir le problème (beaucoup de problèmes ne se manifestent pas lorsque le système est inactif).

Si vous pouvez voir le problème dans l'environnement inférieur, c'est dans cet environnement que vous devriez enquêter. Puisque vous avez plus de contrôle sur le niveau d'activité dans cet environnement, vous serez moins distrait par des facteurs non liés. Et parce qu'il est plus pratique de savoir ce qui se passe, vous pouvez formuler de meilleures idées sur les causes potentielles. Enfin, lorsqu'il s'agit d'apporter des modifications pour le dépannage, vous devriez toujours les faire d'abord dans les environnements inférieurs quand c'est possible afin d'éviter des perturbations inutiles aux utilisateurs.

Complexité

Vous voulez réduire autant que possible la complexité sans changer votre configuration basique. Travailler dans un environnement inférieur aide à réduire la complexité. Mais lorsque vous travaillez avec des sites multi-machines, les machines multiples signifient que vous avez plusieurs endroits où chercher pour tout problème donné. 

Une pratique souvent efficace est d'arrêter les machines redondantes du site. Par exemple, s'il y a trois machines dans un site ArcGIS Server, éteignez (le système d'exploitation) ou arrêtez (dans le site) deux machines. La machine restante utilise toujours le partage de fichiers aux mêmes fins, et beaucoup de problèmes continueront à se manifester. Si arrêter les machines redondantes fait disparaître le problème, c'est un indice important sur la nature du problème. Plus précisément, cela indique que le problème concerne l'accès client concurrentiel, et peut-être pas le réseau.

Impliquer d'autres personnes

Lorsque vous dépannez des problèmes qui couvrent plusieurs environnements, vous pouvez rencontrer des problèmes qui dépassent vos privilèges d'accès ou votre expérience. Bien que les privilèges puissent être accordés temporairement, l'expérience dans ces domaines est tout aussi précieuse. Se constituer une équipe dédiée à la résolution des problèmes garantira que vous disposez préventivement des ressources nécessaires lorsque des questions surgissent.

Une source fréquente de dysfonctionnement dans ce type d'effort en équipe virtuelle est d'amener tout le monde à comprendre comment ils peuvent apporter une contribution significative. Les administrateurs réseau et administrateurs du partage de fichiers connaissent généralement peu les logiciels Esri et ne sont pas incités à apprendre beaucoup sur les applications sur leur infrastructure. Cependant, ils ont généralement un esprit curieux et aiment résoudre des problèmes. Si vous leur présentez une question ouverte (« Le réseau a-t-il des problèmes ? ») ou une accusation prématurément large (« Le réseau nous cause des problèmes »), il est peu probable que vous obteniez des réponses intéressantes. En revanche, si vous posez des questions spécifiques basées sur des preuves, vos chances d'une réponse productive augmentent. Par exemple : « Nous voyons des messages 'connection time out' dans nos journaux applicatifs aux moments X, Y et Z. Cela semble se produire toutes les 2 à 3 heures. Seriez-vous capable de capturer le trafic pendant cette période et nous aider à comprendre ce qui se passe avec les connexions ? »

Hypothèses basées sur les preuves et investigation

Que vous essayiez d'être efficace seul ou en tant que partie d'une équipe virtuelle, une approche basée sur les preuves est la norme absolue pour progresser. Quelques pierres angulaires d'une approche basée sur les preuves sont :

1. Faites vos observations initiales avant toute modification du système et établissez que ces observations sont cohérentes.
2. Commencez par des observations spécifiques concernant un certain workflow, requête ou opération.
3. Trouvez la répétition ou la reproductibilité. Vous ne voulez pas courir après des cas isolés ou fausses alertes.
4. Documentez au fur et à mesure. Vous voulez pouvoir revenir confirmer les détails de vos observations et partager vos observations avec d'autres.
5. Créez plus d'une cause hypothétique pour chaque problème. Votre première idée n'est rarement la réponse ; créez-en plusieurs en poursuivant chacune à son tour.
6. Identifiez les preuves qui pourraient invalider (ou soutenir) une hypothèse puis poursuivez ces preuves.
7. Tirez parti de l'expertise des autres. Une des meilleures façons d'obtenir la participation d'un expert est de lui demander de montrer son expertise en expliquant les significations possibles d'une observation spécifique. C'est un double gain : vous avancez votre compréhension et cela rend l'expert plus susceptible vouloir continuer à vous aider par la suite.

Ce que vous pouvez apprendre en tant qu'administrateur ArcGIS Enterprise : La signature

Les journaux dans ArcGIS Enterprise (journaux du portail ArcGIS Enterprise et journaux ArcGIS Server) sont l'endroit où identifier votre signature problématique. C'est la mesure que vous utiliserez pour déterminer si vous avez un problème avec un partage de fichiers et si un changement effectué réellement résolu.<\/P>

Lorsqu'un composant ArcGIS Enterprise « communique » avec un partage de fichiers, il lit et écrit des objets fichiers, souvent appelés Entrée\/Sortie ou E\/S. Et, il le fait en tant que compte spécifique (le compte de service<\/A>), donc vous pouvez rencontrer des problèmes d'autorisations et des problèmes de système de fichiers. <\/P>

Les problèmes d'autorisations sont généralement assez reconnaissables dans les messages du journal et relativement simples à résoudre. Par exemple, le message du journal « Impossible d'écrire dans le chemin du répertoire ''{0}''. Veuillez vérifier que l'emplacement est valide et que le compte ArcGIS Server a les autorisations nécessaires pour cet emplacement. » (code 6697) décrit la cause et donne une idée pour la solution. Notez que les autorisations effectives impliqueront à la fois celles pour le partage lui-même et les fichiers et répertoires exposés via le partage.<\/P>

Autorisations du partage<\/P><\/TD>

Autorisations des fichiers et répertoires<\/P><\/TD><\/TR>

<\/span> <\/P><\/TD><\/span> <\/P><\/TD><\/TR><\/TBODY><\/TABLE> <\/P>Les messages du journal qui mentionnent un chemin lié au partage de fichiers, à l'E\/S ou à une IOException signifient probablement que les autorisations ne sont pas en cause. À la fin de cet article, il y a une annexe avec une liste partielle des codes de journal et types de messages corrélés aux problèmes de partage de fichiers. La corrélation est fondamentale pour établir la causalité. Si vous voyez des messages comme ceux-ci, c'est un bon indicateur que vous devez examiner de plus près le partage de fichiers et\ou le chemin réseau vers celui-ci, bien que ce ne soit pas une preuve irréfutable que le partage de fichiers est en faute.  <\/P>Les détails des types de messages du journal peuvent obscurcir les schémas généraux que vous recherchez. Un partage de fichiers est un système de fichiers situé de l'autre côté d'un réseau, donc s'il y a un problème, il peut y avoir au moins deux types de sources : la solution de partage de fichiers elle-même ou le réseau. Voici des exemples de messages indiquant un problème d'accès aux fichiers depuis un partage de fichiers (certaines informations ont été supprimées pour plus de clarté ou confidentialité) :<\/P>Composant Enterprise<\/P><\/TD>Niveau<\/P><\/TD>Code<\/P><\/TD>Message<\/P><\/TD>Notes<\/P><\/TD><\/TR>Serveur<\/P><\/TD>AVERTISSEMENT<\/P><\/TD>7721<\/P><\/TD>« échec d'écriture du heartbeat »<\/P><\/TD> <\/P><\/TD><\/TR>Serveur<\/P><\/TD>AVERTISSEMENT<\/P><\/TD>7712<\/P><\/TD>« Une erreur est survenue lors de la synchronisation avec le magasin de configuration »<\/P><\/TD> <\/P><\/TD><\/TR>Serveur<\/P><\/TD>SÉVÈRE<\/P><\/TD>6561<\/P><\/TD>« Échec du retour de toutes les configurations de dossier »<\/P><\/TD> <\/P><\/TD><\/TR>Serveur<\/P><\/TD>SÉVÈRE<\/P><\/TD>9000<\/P><\/TD>« Erreur interne du serveur : « Service <name> non trouvé » < \/ P > < T D w i d t h = " 2 7 5 " > < P > Notez qu'une requête pour un service qui n'existe pas actuellement générera également un message comme celui-ci. Pour que cela indique un problème avec un partage de fichiers, le service doit réellement exister dans le site.< \/ P > < \/ T D > < \/ T R > < T R > < T D w i d t h = " 8 6 " > < P > Serveur < \/ P > < \/ T D > < T D w i d t h = " 9 0 " > < P > SÉVÈRE < \/ P > < \/ T D > < T D w i d t h = " 7 7 " > < P > 6605 < \/ P > < \/ T D > < T D w i d t h = " 1 8 6 " > < P > « Échec du retour de toutes les configurations des services dans le dossier … (Le système ne trouve pas le fichier spécifié) » < \/ P > < T D w i d t h = " 2 7 5 " > < P > < \/ P > < \/ T D > < \/ T R > < T R > < T D w i d t h = " 8 6 " > < P > Serveur < \/ P > < \/ T D > < T D w i d t h = " 9 0 " > < P > SÉVÈRE < \/ P > < \/ T D > < T D w i d t h = " 7 7 " > < P > 6652 < \/ P > < \/ T D > < T D w i d t h = " 1 8 6 " > < P > « Impossible de lire le service … depuis le magasin de configuration … (Le système ne trouve pas le fichier spécifié) » < \/ P > < T D w i d t h = " 2 7 5 " > < P > < \/ P > < \/ T D > < \/ T R > < T R > < T D w i d t h = " 8 6 " > < P > Serveur < \/ P > < \/ T D > < T D w i d t h = " 9 0 " > < P > SÉVÈRE < \/ P > < \/ T D > < T D w i d t h = " 7 7 " > < P > 6566 < \/ P > < \/ T D > < T D w i d t h = " 1 8 6 " > < P > « Échec de récupération du statut du service … (Le système ne trouve pas le fichier spécifié) »< \/ P >< P > <\ / P ><\ / TD ><\ / TR >< TR >< TD w i d t h = "86" >< P > Serveur<\ / P ><\ / TD >< TD w i d t h = "90" >< P>SÉVÈRE<\ / P ><\ / TD >< TD w i d t h = "77" >< P>9015<\ / P ><\ / TD >< TD w i d t h = "186" >< P>« Erreur lors de l'obtention de la liste des services. … (Le système ne trouve pas le fichier spécifié) »<\ / P >< TD w i d t h = "275" >< P > <\ / P ><\ / TD ><\ / TR >< TR >< TD w i d t h = "86" >< P>Serveur<\ / P ><\ / TD >< TD w i d t h = "90" >< P>SÉVÈRE<\ / P ><\ / TD >< TD w i d t h = "77" >< P>6615<\ / P ><\ / TD >< TD w i d t h = "186" >< P>« Impossible de récupérer les informations sur la ressource 'Permissions'. … »<\ / P >< TD w i d t h = "275" >< P>Ce message n'est pas exclusif aux problèmes liés aux partages de fichiers, mais il peut être associé à ces problèmes.<\ / P ><\ / TD ><\ / TR >< TR >< TD w i d t h = "86" >< P>Portail Enterprise<\ / P ><\ / TD >< TD w i d t h = "90" >< P>SÉVÈRE<\ / P ><\ / TD >< TD w i d t h = "77" >< P>218037<\ / P ><\ / TD >< TD w i d t h = "186" >< P>« Le site Portal a été initialisé et configuré mais n'est actuellement pas accessible car le répertoire contenu n'est pas disponible … »<\ / P >< TD w i d t h = "275" >< P > <\ / P ><\ / TD ><\ / TR ><\ / TBODY ><\ / TABLE >< P > <\ / P >< P>Lequel de ces messages pourrait vous amener à vous concentrer sur le réseau et lequel pourrait vous amener à vous concentrer sur le partage de fichiers ? Aucun de ces messages n'inclut des phrases comme « connexion expirée », « connexion forcée fermée », ou « délai dépassé ».  Cette absence suggère qu'il n'y avait pas un problème pour se connecter au partage de fichiers ; il y avait un problème après ce point. Cela vous oriente vers le partage de fichiers comme prochain point sur lequel concentrer votre attention.<\ / P >< p inversement, si vous voyez une phrase comme « délai expiré lors de la connexion », c'est une indication que vous devriez enquêter sur votre réseau — parce que se connecter est ce que font les réseaux.<\ / p >< p votre enquête sur les journaux du serveur Esri devrait pouvoir établir trois points et demi :<\ / p >< ol >< li il y a ou non des messages spécifiques aux emplacements du partage supportant config-store, répertoires serveur ou répertoire contenu.<\ / li >< li fréquence d'apparition de ces messages : idéalement, s'ils sont corrélés à une activité particulière (modèle des requêtes \ utilisation du logiciel)<\ li ></ ol ></ li ></ ol ></ p ></ p>Ceci est votre signature. Lorsque vous avez une signature, vous pouvez commencer à examiner d'autres sources d'information pour des événements coïncidents dans le temps.<

Nous consultons d'autres sources journaux pour chercher la cause première ou le « pourquoi ». Dans le cas d'un problème lié à un partage de fichiers, le système Esri est la victime. Les journaux Esri n'offriront probablement pas une vision claire sur la cause première. La machine locale est celle (ou celles) sur laquelle tourne le logiciel Esri. C'est le client du serveur du partage de fichiers. Les journaux provenant de la machine locale permettent de savoir s'il y a un problème spécifique à cette machine ou détectable par elle. Un administrateur local a accès aux journaux Event Viewer. Ces journaux contiennent une mine d'informations provenant des différents sous-systèmes du système Windows OS. Vous voulez prendre les horodatages observés dans vos journaux serveur Esri et voir s'il y a des enregistrements intéressants dans quelques catégories des journaux Event Viewer. Dans la plupart des cas, vous voulez regarder les catégories Windows System, Security et Application. La capture écran ci-dessous illustre les capacités filtrage qui permettent de se concentrer sur certains types messages pour périodes temporelles intéressantes dans ces principaux journaux Windows : Parce que vous êtes concentré sur les partages fichiers, il existe une source supplémentaire potentielle enfouie plus profondément dans l'arborescence des journaux Event Viewer. Si vous naviguez dans l'arborescence à gauche vers Applications and Services Logs > Microsoft > Windows > SMBClient, il y a trois autres journaux (Connectivity, Operational et Security) qui concernent spécifiquement SMB (SMB est le protocole utilisé pour communiquer avec le partage). La capture écran ci-dessous illustre certains contenus avec une erreur qui, bien que rare, causerait certainement un problème pour un serveur Esri :
 
Que vous regardiez les principaux journaux Windows ou ceux du client SMB, votre attention principale doit porter sur les messages classés comme Critique, Avertissement, ou Erreur. Vous devriez filtrer en fonction de ces niveaux d'événements et du temps.<\/P>Que peuvent vous dire ces journaux ? <\/P>La machine locale détecte-t-elle un problème ?Si vous ne trouvez pas d'erreurs thématiquement liées dans les journaux Windows principaux pour les horodatages de vos journaux serveur Esri, alors vous avez une preuve que le problème n'est pas dû à un problème spécifique à la machine cliente. Bien que cela ne soit peut-être pas une preuve suffisante pour exclure complètement la possibilité, vous avez pris des mesures importantes vers cet objectif, et vous pouvez prioriser vos efforts ailleurs.<\/LI>Si vous trouvez des erreurs intéressantes sur la machine locale, vous priorisez vos efforts pour comprendre et essayer de résoudre celles-ci. <\/LI><\/OL><\/LI>Le protocole SMB détecte-t-il un problème ?Si vous ne trouvez pas d'erreurs dans les journaux SMBClient correspondant aux horodatages, vous pouvez en déduire que le problème n'est pas une erreur en ce qui concerne le protocole SMB. Par exemple, si vous enquêtez sur des messages indiquant qu'un fichier est introuvable, le protocole SMB ne va pas classer cela comme une erreur — Pour autant qu'il sache, ce fichier n'existe pas. Dans ce cas, le protocole a fonctionné correctement et a renvoyé une information correcte. <\/LI>D'autre part, si vous voyez une erreur comme celle montrée ci-dessus, il est logique de concentrer l'enquête sur le protocole SMB lui-même.<\/LI><\/OL><\/LI><\/OL>Trouver des erreurs thématiquement liées dans ces journaux est souvent très significatif pour d'autres spécialistes qui ne sont pas familiers avec la journalisation Esri mais sont plus susceptibles de comprendre ou de faire confiance à la journalisation du système d'exploitation.<\/P>Ce que vous pouvez apprendre avec d'autres spécialistes<\/H2>De nombreux problèmes de partage de fichiers ne se manifestent pas dans les journaux Event Viewer du système d'exploitation client. La plupart des autres sources d'information nécessitent des privilèges élevés (au-delà de l'administration du serveur Esri ou de la machine locale), des connaissances spécialisées, ou les deux. Donc, pour progresser dans ce domaine, vous devez employer deux attributs importants : (a) votre personnalité gagnante et (b) votre engagement envers une enquête basée sur des preuves.<\/P>Personnes en réseau<\/H3>Si vous avez les signatures du journal d'application Esri qui suggèrent un problème ou une défaillance liée au réseau, vous voudrez enquêter dans ce domaine.<\/P>La plupart des problèmes réseau liés aux partages de fichiers ne s'expriment pas très clairement dans les solutions classiques de surveillance ou de journalisation réseau. La surveillance réseau se concentre souvent sur la capacité, le débit et la qualité de service. Cela est utile pour la planification et l'administration réseau globale mais pas nécessairement utile pour dépanner des connexions spécifiques. Le journal des refus d'un pare-feu vaut la peine d'être consulté, mais ce n'est généralement pas là que se trouvent les causes des problèmes de partage de fichiers.<\/P>Les réponses se trouvent généralement en capturant le trafic réseau pendant une courte période lorsque le problème survient ou est déclenché manuellement. Capturer un problème intermittent n'est pas aussi difficile qu'il n'y paraît. On peut configurer une capture en tampon circulaire pour conserver un inventaire stable de fichiers, en les écrasant au fil du temps. L'équipe réseau de votre organisation, en plus d'avoir les outils et privilèges, saura probablement comment faire cela. Donc, vous n'avez pas besoin de savoir exactement quand le problème se produira à nouveau. <\/P>Dans de nombreux cas, un tampon circulaire peut conserver plusieurs heures de données de capture réseau sur une base roulante. Lorsque le problème se reproduit, demandez à l'équipe réseau d'arrêter la trace. Ensuite, utilisez les horodatages des journaux serveur Esri pour examiner les informations de capture réseau. Avec quelques solides connaissances fondamentales en réseau (de l'équipe réseau ou vous-même) et un peu de dévouement, beaucoup peut être appris. Même si votre équipe n'a pas beaucoup de connaissances en analyse réseau, vous pouvez rechercher des anomalies. Soit il y a des caractéristiques réseau anormales aux horodatages concernés, soit il n'y en a pas. S'il y a quelque chose d'anormal ou suspect, des experts supplémentaires peuvent être appelés selon les besoins. La spécificité sera probablement attrayante pour ces experts.<\/P>Personnes responsables du partage de fichiers<\/H3>Si vos signatures du journal serveur Esri ne suggèrent pas un problème réseau, vous voudrez enquêter dans ce domaine. Les solutions de partage de fichiers, comme la plupart des systèmes informatiques, ont généralement des journaux. Un examen de ces journaux aux moments concernés est approprié. S'il y a des erreurs thématiquement liées aux horodatages concernés, vous avez une cause probable à approfondir. Et vous avez votre équipe administrative du partage de fichiers (et l'organisation support du fournisseur) pour mener la voie.<\/P>Il est également possible que les journaux du partage de fichiers ne contiennent pas d'erreurs liées. Si les preuves accumulées ont exclu les autres sources probables et que les journaux du partage de fichiers n'indiquent aucun problème, il reste une possibilité. Il est possible que le partage de fichiers et le logiciel Esri classifient différemment les problèmes. Par exemple, si un partage de fichiers est conçu ou configuré pour fournir une cohérence éventuelle, il n'enregistrera pas d'erreurs à ce sujet. Mais nous savons qu'ArcGIS Server attend une cohérence immédiate. Ainsi, le partage de fichiers ne voit aucune erreur, mais ArcGIS Server n'obtient pas ce dont il a besoin.<\/P>Explorons un peu plus cette idée car elle revient souvent, en utilisant l'exemple d'un site ArcGIS Server à deux machines avec le magasin de configuration et les répertoires serveur stockés sur un partage de fichiers. Si la machine A écrit dans un fichier, la machine B du site ArcGIS Server devrait pouvoir lire cette nouvelle information immédiatement. C'est la cohérence immédiate : lecture après écriture pour tout client du partage de fichiers. Donc, si ArcGIS Server dit : « Hé, je ne trouve pas ce fichier », ou « Ce fichier semble différent de ce que je pensais », et que le partage de fichiers dit : « Je ne connais aucun problème », quelle est votre hypothèse résultante ? Ayant exclu d'autres causes probables, votre hypothèse résultante est que le partage de fichiers ne fournit pas la cohérence « lecture après écriture ». Aucune autre idée ne correspond aussi bien aux données.<\/P>Que faites-vous avec cela ? C'est une autre enquête avec l'équipe administrative du partage de fichiers. Mais au lieu de se concentrer sur une erreur dans ses journaux, il s'agit de comprendre comment plusieurs clients regardant le même fichier au même moment le voient toujours dans exactement le même état. Aucun client ne peut voir l'état avant comme valide après que le fichier ait été modifié par un autre client. Et aucun client ne peut modifier un fichier lorsqu'un autre client a un verrou exclusif dessus. Oups. Nous avons dit le mot commençant par "L" (lock). Cela soulève un terme ou concept supplémentaire dont vous avez peut-être entendu parler auparavant : verrouillage opportuniste des fichiers, également appelé Oplocks.<\/P>Le problème vient-il des Oplocks ?<\/H4>Bien qu'il soit certainement possible que les Oplocks causent un problème pour votre système, pour les problèmes dont nous parlons ici les chances sont contre cela. Mais comme la prise de décision basée sur des preuves est la manière d'avancer, vous pouvez utiliser des preuves pour démontrer si c'est une cause.<\/P>Il vaut la peine de réfléchir à ce que sont les Oplocks et leurs alternatives. Les Oplocks sont des verrous opportunistes. Le client (le système Esri) suppose optimistement que les fichiers qu'il connaît sur le partage sont inchangés et/ou sûrs à modifier sauf s'il reçoit une notification du serveur (le partage). L'opposé du verrouillage opportuniste est le verrouillage pessimiste (l'absence totale de verrouillage n'est pas une option). Dans ce cas, le client suppose pessimistement que d'autres clients pourraient utiliser les fichiers qu'il connaît sur le partage et vérifie avant toute action. Les verrous opportunistes sont une excellente stratégie lorsque la plupart des fichiers ne sont pas accédés par plus d'un client à la fois. Les verrous pessimistes sont une meilleure stratégie lorsque les fichiers sont fréquemment accédés par plusieurs clients simultanément. Que savons-nous d'un site ArcGIS Server ou Portal for ArcGIS multi-machines ? Il y a au moins deux clients accédant aux mêmes fichiers simultanément.<\/P>Ainsi, les Oplocks sont sous-optimaux pour les cas d'utilisation serveur Esri. Mais est-ce la cause de votre problème ? Vous ne savez pas encore. Puisque vous avez votre signature problématique issue des journaux Esri, vous pouvez changer les paramètres Oplocks et voir si cela modifie la signature du problème (la présence du message et sa fréquence avec la même charge). Ces paramètres peuvent être modifiés dans le système d'exploitation client (les machines où tourne le logiciel Esri) ou dans la solution de partage selon votre configuration.<\/P>Voici comment faire si vous êtes administrateur local pour le système client OS. Ouvrez une fenêtre PowerShell en tant qu'« Administrateur » et notez les paramètres actuels :<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Puis vous pouvez les modifier. Les commandes suivantes désactiveront tout cache côté client<\/A> (y compris Oplocks) :<\/P>

Set-SmbClientConfiguration -OplocksDisabled 1<\/FONT><\/P>Set-SmbClientConfiguration -UseOpportunisticLocking 0<\/FONT><\/P>Set-SmbClientConfiguration -DirectoryCacheLifetime 0<\/FONT><\/P>Set-SmbClientConfiguration -FileNotFoundCacheLifetime 0<\/FONT><\/P>Set-SmbClientConfiguration -FileInfoCacheLifetime 0<\/FONT><\/P> <\/P>Vous pouvez ensuite inspecter ces paramètres avec ceci :<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Notez que ces changements prendront effet lors du prochain établissement par le client d'une nouvelle connexion au partage. Redémarrer le logiciel serveur Esri provoquerait cela immédiatement.<\/P>Une fois vos paramètres modifiés, retournez aux journaux Esri pour voir si la signature — informations sur l'erreur et fréquence avec la même charge — a été corrigée. Si oui, félicitations ! Sinon ?<\/P>

Le problème est-il autre chose autre chose ?

Oui—si vous en êtes à ce stade, le problème est autre chose.

Vous avez réfuté toutes les hypothèses raisonnables jusqu'à présent. Il ne vous reste qu'un diagnostic d'exclusion. Ce diagnostic est que la solution de partage de fichiers (qu'elle soit conçue ainsi ou non) ne fournit pas une cohérence immédiate. 

Dans ce cas, il peut être utile d'avoir des preuves corroborantes. Une très bonne façon de le faire est de comparer avec une solution de partage de fichiers différente. Bien qu'un partage de fichiers depuis une machine virtuelle Windows ne soit pas une solution que vous ou votre organisation souhaitez adopter définitivement, cela peut être très utile pour une enquête. Esri ne dispose pas de preuves empiriques que les partages de fichiers depuis une seule machine Windows produisent des problèmes de cohérence immédiate. Il n'y a pas de base théorique solide pour cela. Et, si vous désactivez les Oplocks comme décrit ci-dessus, vous neutralisez également les bases théoriques faibles. Le partage de fichiers sur la machine Windows devrait être configuré avec les mêmes paramètres SMB que le partage de fichiers original.  La commande PowerShell Set-SmbServerConfiguration peut être utilisée pour correspondre à la plupart des paramètres que l'équipe d'administration du partage de fichiers indiquerait pour leur solution.

En tout cas, si vous pointez votre(vos) serveur(s) Esri vers le partage de fichiers sur la machine Windows et que la signature du problème disparaît, votre diagnostic d'exclusion est corroboré. À partir de là, l'équipe responsable de la solution de partage de fichiers peut décider si elle souhaite essayer d'égaler la caractéristique de cohérence immédiate ou indiquer qu'elle ne veut pas fournir un tel service. Ainsi, vous avez soit une solution, soit une réponse. 

En conclusion

Enquêter sur un problème suspecté de partage de fichiers est l'une des tâches de dépannage les plus difficiles dans l'administration ArcGIS Enterprise. Cet article n'a pas eu pour but de faire de vous, lecteur individuel, un praticien solo réussi dans ce domaine ; l'objectif est plutôt de vous fournir des informations fondamentales et un processus. Si vous exécutez soigneusement ce processus, vous pouvez faire appel à plusieurs spécialistes différents pour vous aider à trouver la solution. En plus d'impliquer les experts du domaine concernés dans votre propre organisation, vous pouvez faire participer le Support Technique Esri et/ou les Services Professionnels. Avec le temps, votre exécution attentive et la participation qualitative de l'équipe peuvent diagnostiquer correctement les problèmes dans ce domaine.

Annexe : Messages journaux corrélés aux problèmes de partage de fichiers

Les informations ci-dessous sont une liste partielle des codes d'erreur et messages pouvant indiquer un problème de partage de fichiers dans votre système ArcGIS Enterprise.

Messages journaux d'avertissement et graves

Au niveau journal par défaut, les codes et messages suivants indiquent généralement un problème avec un partage de fichiers (dans un site multi-machines). Il est souvent utile d'examiner les messages immédiatement avant et après. Lorsque vous faites cela, vous devez utiliser les champs machine, processus et thread pour reconnaître les messages liés. Comme il y a beaucoup de machines, processus et threads, les messages immédiatement voisins dans le temps peuvent provenir d'un autre processus.

Composant Enterprise	Niveau	Code	Message	Notes
Serveur	AVERTISSEMENT	7721	"échec d'écriture du heartbeat"
Serveur	AVERTISSEMENT	7712	"Une erreur a été rencontrée lors de la synchronisation avec le magasin config"
Serveur	GRAVE	6561	"Échec du retour de toutes les configurations des dossiers"
Serveur	GRAVE	9000	"Erreur interne du serveur : "Service <name> non trouvé"	Notez qu'une requête pour un service qui n'existe pas actuellement générera aussi un message comme celui-ci. Pour que cela indique un problème avec un partage de fichiers, le service doit réellement exister dans le site.
Serveur	GRAVE	6605	"Échec du retour de toutes les configurations des services dans le dossier … (Le système ne trouve pas le fichier spécifié)"
Serveur	GRAVE	6652	"Impossible de lire le service … depuis le magasin de configuration … (Le système ne trouve pas le fichier spécifié)"
Serveur	GRAVE	6566	"Échec pour récupérer l'état du service … (Le système ne trouve pas le fichier spécifié)"
Serveur	GRAVE	9015	"Erreur lors de l'obtention de la liste des services. … (Le système ne trouve pas le fichier spécifié)"
Serveur	GRAVE	6615	"Impossible d'obtenir les informations sur la ressource 'Permissions'. …"	Ce message n'est pas exclusif aux problèmes de partage de fichiers, mais il peut y être associé.
Porte Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprise portalalce Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotalle Enterprisepotaleportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportalportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleportaleporta...

MikeSchiewe

This is great information.  Is there a Linux version of this article?