Fehlerbehebung bei File Shares und ArcGIS Enterprise

DannyKrouk_ps

Einführung

ArcGIS Enterprise-Architekturen haben oft Anforderungen an die Verwendung von Dateifreigaben zur Speicherung gemeinsamer Konfigurationsdateien, Inhalte oder Backups (https://enterprise.arcgis.com/en/server/latest/install/windows/choosing-a-nas-device.htm). Dies gilt insbesondere, wenn das Bereitstellungsmuster mehrere Maschinenstandorte umfasst (wie bei Hochverfügbarkeitskonfigurationen). Es gibt Verwendungen von Dateifreigaben in jedem der Hauptkomponenten von ArcGIS Enterprise (Portal for ArcGIS, ArcGIS Server und ArcGIS Data Store).

Im untenstehenden Diagramm befinden sich der „Shared Content“ und der „Shared Config-store and Directories“ auf einer Dateifreigabe:

 

Dateifreigaben gibt es in vielen Typen und Varianten, von physischen Hardwaregeräten bis hin zu virtuellen Dateisystemen oder anderen Anbietern. Gemeinsame Dateisysteme bieten eine effiziente Möglichkeit, Inhalte zwischen mehreren Komponenten zu teilen, können aber auch Herausforderungen in Bezug auf Leistung, Berechtigungen oder Konsistenz auf Datei-Ebene mit sich bringen.

Wenn es Probleme in einer ArcGIS Enterprise-Bereitstellung gibt und Sie vermuten, dass diese mit gemeinsam genutztem Speicher zusammenhängen, kann es schwierig sein zu beurteilen, wie Sie Ihre Architektur auf potenzielle Herausforderungen überprüfen und was Sie dagegen tun können. In der Praxis kann die Lösung eines Problems mit einer Dateifreigabe herausfordernd sein, aber Ihre Erfolgschancen sind viel besser, wenn Sie eine spezifische Metrik oder Messung festlegen, um das vermutete Problem zu definieren, eine Basislinie zu erstellen und zu testen. Dieser Artikel soll Ihnen helfen festzustellen, ob es ein Problem mit der Dateifreigabe in Ihrer ArcGIS Enterprise-Bereitstellung gibt, welche Symptome und Indikatoren auf diese Art von Problem hinweisen könnten (seine Signatur) und wie Sie die Ursache untersuchen können.

Obwohl ähnliche Prinzipien für Linux/NFS- und Windows/SMB-Systeme gelten, konzentrieren sich die Details dieses Artikels auf Windows/SMB-Systeme.

Wie verwendet ArcGIS Enterprise eine Dateifreigabe?

Es gibt mehrere Möglichkeiten, wie ArcGIS Enterprise eine Dateifreigabe nutzt, darunter folgende:

1. Ein registriertes Datenrepository in einem ArcGIS Server-Standort
2. Ein gemeinsamer Sicherungsort für ArcGIS Data Store-Backups
3. Ein Ort zur Speicherung und Extraktion von WebGISDR-Backups für Disaster-Recovery-Workflows
4. Ein Ort zur Speicherung des „config-store“ und der „server directories“ eines Mehrmaschinen-ArcGIS Server-Standorts
5. Ein Ort zur Speicherung des „content directory“ eines hochverfügbaren ArcGIS Enterprise Portal-Standorts

Die letzten beiden stehen im Fokus dieses Artikels; in diesen Fällen spielt die Dateifreigabe eine Rolle dabei, wie jede Maschine im Mehrmaschinenstandort weiß, was vor sich geht. Metaphorisch wirkt die Dateifreigabe wie ein Teil des „Nervensystems“ des ArcGIS Enterprise-Portals oder des ArcGIS Server-Standorts, wenn sie den „config-store“, die „server directories“ oder das „content directory“ unterstützt. Wenn also ein Problem mit der Dateifreigabe besteht, kann der ArcGIS Server oder Portal for ArcGIS-Standort eine Vielzahl intermittierender Symptome zeigen, wie Schwierigkeiten beim Veröffentlichen von Diensten oder Server-„Instabilität“.

Erkennen und Untersuchen eines Problems im Zusammenhang mit einer Dateifreigabe

Die Analyse eines potenziellen Problems mit einer Dateifreigabe kann als Einzelarbeit beginnen, indem die Softwareprotokolle jeder ArcGIS-Komponente untersucht werden. Wenn Sie dort jedoch Hinweise finden, die auf Probleme im Zusammenhang mit dem Datei-Zugriff hindeuten, müssen Sie mit anderen Informationsquellen oder Softwarekomponenten zusammenarbeiten. Dies bedeutet wahrscheinlich die Zusammenarbeit mit anderen Personen, da die erforderlichen Zugriffsrechte und Kenntnisse selten bei einer einzigen Person konzentriert sind.

Dieser Artikel beschreibt, was Sie mit unterschiedlichen Privilegien und Kenntnissen verfolgen können. Wir beginnen aus zwei Gründen mit den Protokollen in ArcGIS Enterprise: Erstens gehen wir davon aus, dass Sie diese Privilegien haben – und zweitens treffen Sie hier die erste Entscheidung darüber, ob es Grund zu der Annahme gibt, dass ein Problem mit der Dateifreigabe vorliegt und was dieser Grund ist.

Grundlagen

Bevor Sie beginnen, sollten Sie sich so produktiv wie möglich aufstellen, indem Sie eine geeignete Umgebung wählen, Komplexität kontrollieren und das richtige Team zusammenstellen.

Umgebungen

Sie sollten versuchen, „untergeordnete Umgebungen“ (mit anderen Worten nicht Ihre Produktionsumgebung) zu nutzen, wenn Sie die Probleme in diesen Systemen beobachten können. Welches Problem Sie auch immer in der Produktion sehen – verwenden Sie die ArcGIS Server-Protokolle, um seine Signatur zu verstehen. Das Auffinden dieser Signatur wird unten erläutert. Suchen Sie dann in Ihrer Staging-, Test- oder UAT-Umgebung nach derselben Signatur. Beachten Sie dabei, dass Sie möglicherweise etwas Aktivität in dieser Umgebung erzeugen müssen, um das Problem zu sehen (viele Probleme treten nicht auf, wenn das System im Leerlauf ist).

Wenn Sie das Problem in der unteren Umgebung sehen können, ist dies die Umgebung, in der Sie untersuchen sollten. Da Sie dort mehr Kontrolle über das Aktivitätsniveau haben, werden Sie weniger durch nicht zusammenhängende Faktoren abgelenkt. Und weil es praktischer ist zu wissen, was passiert, können Sie bessere Ideen über mögliche Ursachen entwickeln. Schließlich sollten Änderungen zur Fehlerbehebung immer zuerst in unteren Umgebungen vorgenommen werden – wenn möglich –, um unnötige Störungen für Benutzer zu vermeiden.

Komplexität

Sie sollten so viel Komplexität wie möglich reduzieren ohne Ihre Grundkonfiguration zu ändern. Die Arbeit in einer unteren Umgebung hilft dabei Komplexität zu verringern. Aber bei Mehrmaschinenstandorten bedeuten mehrere Maschinen auch mehrere Orte zur Fehlersuche für ein gegebenes Problem. 

Eine häufig wirksame Praxis ist es daher, die redundanten Maschinen im Standort herunterzufahren. Zum Beispiel: Wenn es drei Maschinen in einem ArcGIS Server-Standort gibt, schalten Sie zwei Maschinen aus (das Betriebssystem) oder stoppen sie (im Standort). Die verbleibende Maschine verwendet weiterhin die Dateifreigabe für dieselben Zwecke und viele Probleme werden weiterhin auftreten. Wenn durch das Herunterfahren der redundanten Maschinen das Problem verschwindet, ist dies ein wichtiger Hinweis auf die Natur des Problems. Konkret sagt es Ihnen, dass das Problem mit gleichzeitigen Clientzugriffen zusammenhängt und vielleicht nicht am Netzwerk liegt.

Andere einbeziehen

Bei der Fehlerbehebung über mehrere Umgebungen hinweg stoßen Sie möglicherweise auf Probleme außerhalb Ihrer Zugriffsrechte oder Erfahrung. Während Rechte temporär vergeben werden können, ist Erfahrung in diesen Bereichen ebenso wertvoll. Ein dediziertes Problemlösungsteam stellt sicher, dass Ressourcen proaktiv verfügbar sind, wenn Fragen auftauchen.

Eine häufige Ursache für Dysfunktion bei solchen virtuellen Teamarbeiten ist es sicherzustellen, dass alle verstehen, wie sie sinnvoll beitragen können. Netzwerkadministratoren und Administratoren von Dateifreigaben wissen typischerweise wenig über Esri-Software und sind meist nicht motiviert viel über Anwendungen ihrer Infrastruktur zu lernen. Allerdings sind sie meist neugierig und lösen gerne Probleme. Wenn Sie ihnen eine offene Frage stellen („Hat das Netzwerk Probleme?“) oder eine vorschnelle breite Anschuldigung („Das Netzwerk verursacht uns Probleme“), erhalten Sie wahrscheinlich keine interessanten Antworten. Stellen Sie hingegen evidenzbasierte spezifische Fragen steigt die Wahrscheinlichkeit produktiver Antworten. Zum Beispiel: „Wir sehen ‚connection time out‘ Meldungen in unseren Anwendungsprotokollen zu den Zeiten X,Y,Z. Es scheint alle 2 bis 3 Stunden aufzutreten. Können Sie den Verkehr für diesen Zeitraum erfassen und uns helfen zu verstehen was bei den Verbindungen passiert?“

Evidenzbasierte Hypothesen und Untersuchung

Egal ob Sie alleine effektiv sein wollen oder als Teil eines virtuellen Teams – ein evidenzbasierter Ansatz ist der Goldstandard für Fortschritte. Einige Eckpfeiler eines evidenzbasierten Ansatzes sind:

1. Machen Sie Ihre ersten Beobachtungen bevor Sie Änderungen am System vornehmen und stellen Sie sicher dass diese Beobachtungen konsistent sind.
2. Beginnen Sie mit spezifischen Beobachtungen bezüglich eines bestimmten Workflows, einer Anfrage oder Operation.
3. Suchen Sie Wiederholungen oder Reproduzierbarkeit. Verfolgen Sie keine Ausreißer oder Fehlalarme.
4. Dokumentieren Sie währenddessen. So können Sie Details Ihrer Beobachtungen später bestätigen und mit anderen teilen.
5. Erstellen Sie mehr als eine hypothetische Ursache für jedes Problem. Ihre erste Idee ist selten die Antwort; entwickeln Sie mehrere Hypothesen und verfolgen diese nacheinander.
6. Identifizieren Sie Beweise die eine Hypothese widerlegen (oder unterstützen) könnten und verfolgen diese Beweise dann.
7. Ziehen Sie Expertise anderer hinzu. Eine der besten Methoden Expertenbeteiligung zu erhalten ist sie einzuladen ihre Expertise zu zeigen indem sie mögliche Bedeutungen einer spezifischen Beobachtung erklären. Das ist ein doppelter Gewinn: Ihr Verständnis wächst und sie sind eher bereit Ihnen zukünftig weiterzuhelfen.

Was ein ArcGIS Enterprise Administrator lernen kann: Die Signatur

Die Protokolle in ArcGIS Enterprise (ArcGIS Enterprise portal logs und ArcGIS Server logs) sind der Ort an dem man seine Problemsignatur identifiziert. Es ist die Messgröße die verwendet wird um festzustellen ob ein Problem mit der Dateifreigabe vorliegt und ob eine Änderung tatsächlich gelöst.<\/P>

Wenn eine ArcGIS Enterprise-Komponente mit einem File Share 1te4uscht7, liest und schreibt sie Dateiobjekte, die oft als Input\/Output oder I\/O bezeichnet werden. Und sie tut dies als ein bestimmtes Konto (das Servicekonto<\/A>), sodass Berechtigungsprobleme und Dateisystemprobleme auftreten kf6nnen. <\/P>

Berechtigungsprobleme sind in den Protokollmeldungen in der Regel recht gut erkennbar und relativ einfach zu beheben. Zum Beispiel beschreibt die Protokollmeldung Kann nicht in das Verzeichnis ''{0}'' schreiben. Bitte prfcfen Sie, ob der Speicherort gfcltig ist und ob das ArcGIS Server-Konto Berechtigungen ffcr den Speicherort hat. (Code 6697) die Ursache und gibt einen Hinweis auf die Lf6sung. Beachten Sie, dass effektive Berechtigungen sowohl die ffcr den Share selbst als auch ffcr die durch den Share freigegebenen Dateien und Verzeichnisse umfassen.<\/P>

Share-Berechtigungen<\/P><\/TD>

Datei- und Verzeichnisberechtigungen<\/P><\/TD><\/TR>

<\/span> <\/P><\/TD><\/span> <\/P><\/TD><\/TR><\/TBODY><\/TABLE> <\/P>Protokollmeldungen, die einen Pfad im Zusammenhang mit dem File Share, I\/O oder einer IOException erwe4hnen, bedeuten wahrscheinlich, dass Berechtigungen nicht das Problem sind. Am Ende dieses Artikels befindet sich ein Anhang mit einer Teilliste von Protokollcodes und Meldungstypen, die mit File Share-Problemen korreliert sind. Korrelation ist grundlegend ffcr die Feststellung von Ursache und Wirkung. Wenn Sie solche Meldungen sehen, ist dies ein guter Hinweis darauf, dass Sie sich das File Share und\oder den Netzwerkpfad genauer ansehen sollten, obwohl es kein unwiderlegbarer Beweis daffcr ist, dass das File Share schuld ist.  <\/P>Die Details der Protokollmeldungen kf6nnen die hochrangigen Muster, nach denen Sie suchen, verschleiern. Ein File Share ist ein Dateisystem auf der anderen Seite eines Netzwerks. Wenn es ein Problem gibt, kann es mindestens zwei Arten von Quellen geben: die File Share-Lf6sung selbst oder das Netzwerk. Im Folgenden finden Sie Beispiele ffcr Meldungen, die auf ein Problem beim Zugriff auf Dateien von einem File Share hinweisen (einige Informationen wurden zur Klarheit oder zum Schutz der Privatsphe4re entfernt):<\/P>Enterprise-Komponente<\/P><\/TD>Ebene<\/P><\/TD>Code<\/P><\/TD>Meldung<\/P><\/TD>Hinweise<\/P><\/TD><\/TR>Server<\/P><\/TD>WARNUNG<\/P><\/TD>7721<\/P><\/TD>Heartbeat konnte nicht geschrieben werden<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>WARNUNG<\/P><\/TD>7712<\/P><\/TD>Beim Synchronisieren mit dem Config Store ist ein Fehler aufgetreten<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>SCHWERWIEGEND<\/P><\/TD>6561<\/P><\/TD>Alle Ordnerkonfigurationen konnten nicht zurfcckgegeben werden<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>SCHWERWIEGEND<\/P><\/TD>9000<\/P><\/TD>Interner Serverfehler: Service <name> nicht gefunden<\/P><\/TD>Beachten Sie, dass eine Anfrage ffcr einen Dienst, der derzeit nicht existiert, ebenfalls eine solche Meldung erzeugt. Damit dies auf ein Problem mit einem File Share hinweist, muss der Dienst tatse4chlich in der Site existieren.

oder Fehler. Sie sollten basierend auf diesen Ereignisebenen und der Zeit filtern.<\/P>

Was können Ihnen diese Protokolle sagen? <\/P>

1. Erkennt der lokale Computer ein Problem?
   1. Wenn Sie in den Haupt-Windows-Protokollen für die Zeitstempel aus Ihren Esri-Serverprotokollen keine thematisch verwandten Fehler finden, haben Sie einige Hinweise darauf, dass das Problem nicht auf einen client-spezifischen Computer zurückzuführen ist. Obwohl dies möglicherweise nicht ausreicht, um die Möglichkeit vollständig auszuschließen, haben Sie wichtige Schritte in diese Richtung unternommen und können Ihre Bemühungen anderswo priorisieren.<\/LI>
   2. Wenn Sie auf dem lokalen Computer interessante Fehler finden, priorisieren Sie Ihre Bemühungen darauf, diese zu verstehen und zu beheben. <\/LI><\/OL><\/LI>
   3. Erkennt das SMB-Protokoll ein Problem?
      1. Wenn Sie in den SMBClient-Protokollen keine Fehler finden, die mit den Zeitstempeln übereinstimmen, können Sie daraus schließen, dass das Problem aus Sicht des SMB-Protokolls kein Fehler ist. Zum Beispiel, wenn Sie Nachrichten untersuchen, die anzeigen, dass eine Datei nicht gefunden werden kann, wird das SMB-Protokoll dies nicht als Fehler klassifizieren – soweit bekannt existiert diese Datei nicht. In diesem Fall hat das Protokoll korrekt funktioniert und eine korrekte Information zurückgegeben. <\/LI>
      2. Andererseits macht es Sinn, die Untersuchung auf das SMB-Protokoll selbst zu konzentrieren, wenn Sie einen Fehler wie oben gezeigt sehen.<\/LI><\/OL><\/LI><\/OL>

         Das Finden thematisch verwandter Fehler in diesen Protokollen ist oft sehr aussagekräftig für andere Spezialisten, die mit Esri-Logging nicht vertraut sind, aber eher Betriebssystemprotokolle verstehen oder ihnen vertrauen.<\/P>

         Was Sie mit anderen Spezialisten lernen können<\/H2>Viele Probleme mit Dateifreigaben zeigen sich nicht in den Ereignisanzeigeprotokollen des Client-Betriebssystems. Die meisten anderen Informationsquellen erfordern erhöhte Berechtigungen (über die Esri-Serververwaltung oder lokale Maschinenverwaltung hinaus), spezielles Wissen oder beides. Um in diesem Bereich Fortschritte zu machen, müssen Sie zwei wichtige Eigenschaften einsetzen: (a) Ihre gewinnende Persönlichkeit und (b) Ihr Engagement für evidenzbasierte Untersuchungen.<\/P>Netzwerkexperten<\/H3>Wenn Ihre Esri-Anwendungsprotokoll-Signaturen auf ein netzwerkbezogenes Problem oder einen Ausfall hindeuten, sollten Sie in diesem Bereich untersuchen.<\/P>Die meisten Netzwerkprobleme im Zusammenhang mit Dateifreigaben zeigen sich nicht klar in klassischen Netzwerküberwachungs- oder Protokollierungslösungen. Die Netzwerküberwachung konzentriert sich oft auf Kapazität, Durchsatz und Dienstgüte. Das ist nützlich für die Netzwerkplanung und -verwaltung insgesamt, aber nicht unbedingt hilfreich bei der Fehlersuche bei spezifischen Verbindungen. Das Protokoll von Firewall-Verweigerungen ist eine wertvolle Quelle, aber dort werden Ursachen von Dateifreigabeproblemen selten gefunden.<\/P>Die Antworten findet man typischerweise durch Erfassen des Netzwerkverkehrs während eines kurzen Zeitraums, wenn das Problem auftritt oder manuell ausgelöst wird. Ein intermittierendes Problem zu erfassen ist nicht so schwer wie es scheint. Man kann eine Ringpuffer-Erfassung einrichten, um kontinuierlich Daten zu erfassen und ältere Dateien nach einer Weile zu überschreiben. Das Netzwerkteam Ihrer Organisation verfügt neben den Werkzeugen und Berechtigungen wahrscheinlich auch über das Wissen dazu. Daher müssen Sie nicht genau wissen, wann das Problem als nächstes auftritt. <\/P>In vielen Fällen kann ein Ringpuffer viele Stunden an Netzwerkdaten fortlaufend speichern. Wenn das Problem erneut auftritt, bitten Sie das Netzwerkteam, die Erfassung zu stoppen. Dann verwenden Sie die Zeitstempel aus den Esri-Serverprotokollen zur Untersuchung der Netzwerkdaten. Mit soliden Netzwerkgrundkenntnissen (vom Netzwerkteam oder Ihnen) und Engagement kann viel gelernt werden. Selbst wenn Ihr Team wenig Netzwerk-Analysewissen hat, können Sie nach Anomalien suchen. Entweder gibt es ungewöhnliche Netzwerkeigenschaften zu den betreffenden Zeitstempeln oder nicht. Wenn etwas Ungewöhnliches oder Verdächtiges vorliegt, können bei Bedarf weitere Experten hinzugezogen werden. Spezifität wird für diese Experten wahrscheinlich attraktiv sein.<\/P>Dateifreigabe-Experten<\/H3>Wenn Ihre Esri-Serverprotokoll-Signaturen kein Netzwerkproblem vermuten lassen, sollten Sie diesen Bereich untersuchen. Dateifreigabelösungen haben wie die meisten IT-Systeme typischerweise Protokolle. Eine Überprüfung dieser Protokolle zu den betreffenden Zeiten ist angebracht. Wenn es thematisch verwandte Fehler für die betreffenden Zeitstempel gibt, haben Sie eine wahrscheinliche Ursache zur weiteren Untersuchung. Und Ihr Dateifreigabe-Verwaltungsteam (und deren Supportorganisation des Anbieters) führt dann die Untersuchung an.<\/P>Es ist auch möglich, dass die Dateifreigabeprotokolle keine verwandten Fehler enthalten. Wenn die gesammelten Beweise andere wahrscheinliche Quellen ausschließen und die Dateifreigabeprotokolle kein Problem anzeigen, bleibt eine Möglichkeit: Es ist möglich, dass die Dateifreigabe und die Esri-Software Probleme unterschiedlich klassifizieren. Zum Beispiel zeichnet eine Dateifreigabe mit eventual consistency keine Fehler darüber auf. Aber wir wissen, dass ArcGIS Server sofortige Konsistenz erwartet. Also sieht die Dateifreigabe keinen Fehler, aber ArcGIS Server erhält nicht was es braucht.<\/P>Lassen Sie uns diese Idee etwas näher betrachten – sie kommt tatsächlich vor – anhand eines Beispiels einer ArcGIS Server-Site mit zwei Maschinen und dem Konfigurationsspeicher sowie Serververzeichnissen auf einer Dateifreigabe gespeichert. Wenn Maschine A in eine Datei schreibt, sollte Maschine B der ArcGIS Server-Site diese neue Information sofort lesen können. Das ist sofortige Konsistenz: Lesen nach Schreiben für jeden Client der Dateifreigabe. Wenn also ArcGIS Server sagt: „Hey, ich kann diese Datei nicht finden“ oder „Diese Datei sieht anders aus als erwartet“ und die Dateifreigabe sagt: „Ich kenne keine Probleme“, was ist Ihre Hypothese? Nachdem andere wahrscheinliche Ursachen ausgeschlossen wurden, lautet Ihre Hypothese: Die Dateifreigabe bietet keine „read after write“-Konsistenz. Keine andere Idee passt so gut zu den Daten.<\/P>Was tun Sie damit? Dies ist eine weitere Untersuchung mit dem Dateifreigabe-Verwaltungsteam. Aber statt sich auf einen Fehler im Protokoll zu konzentrieren, geht es darum zu verstehen, wie mehrere Clients dieselbe Datei zur gleichen Zeit immer im exakt gleichen Zustand sehen können. Kein Client darf den vorherigen Zustand als gültig sehen nachdem ein anderer Client die Datei geändert hat. Und kein Client darf eine Datei ändern wenn ein anderer Client einen exklusiven Lock darauf hat. Oh-oh. Wir haben das „L-Wort“ gesagt (Lock). Das bringt einen weiteren Begriff ins Spiel, den Sie vielleicht schon gehört haben: opportunistisches Sperren von Dateien, auch Oplocks genannt.<\/P>Ist das Problem Oplocks?<\/H4>Obwohl es durchaus möglich ist, dass Oplocks ein Problem für Ihr System verursachen, stehen die Chancen bei den hier besprochenen Problemen dagegen. Da evidenzbasierte Entscheidungsfindung der Weg zum Fortschritt ist, können Sie Beweise nutzen um festzustellen ob es eine Ursache ist.<\/P>Es lohnt sich darüber nachzudenken was Oplocks und Alternativen sind. Oplocks sind opportunistische Sperren. Der Client (das Esri-System) geht optimistisch davon aus, dass die ihm bekannten Dateien auf der Dateifreigabe unverändert und/oder sicher zu ändern sind solange er nichts vom Server (der Dateifreigabe) hört. Das Gegenteil von opportunistischem Sperren ist pessimistisches Sperren (kein Sperren ist keine Option). Dabei geht der Client pessimistisch davon aus, dass andere Clients die ihm bekannten Dateien nutzen könnten und prüft vor jeder Aktion nach. Opportunistische Sperren sind eine gute Strategie wenn die meisten Dateien nicht gleichzeitig von mehr als einem Client genutzt werden. Pessimistische Sperren sind besser wenn Dateien häufig gleichzeitig von mehreren Clients genutzt werden. Was wissen wir über eine ArcGIS Server- oder Portal for ArcGIS-Site mit mehreren Maschinen? Mindestens zwei Clients greifen gleichzeitig auf dieselben Dateien zu.<\/P>Daher sind Oplocks suboptimal für Esri-Server-Anwendungsfälle. Aber sind sie Ursache Ihres Problems? Das wissen Sie nicht. Da Sie Ihre Problemsignatur aus Ihren Esri-Protokollen haben, können Sie die Oplocks-Einstellungen ändern und prüfen ob sich die Problemsignatur ändert (das Vorhandensein der Meldung und ihre Häufigkeit bei gleicher Arbeitslast). Diese Parameter können im Client-Betriebssystem (den Maschinen auf denen Esri-Software läuft) oder in der Dateifreigabelösung geändert werden – je nach Konfiguration.<\/P>So machen Sie es als lokaler Administrator des Client-Betriebssystems: Öffnen Sie ein PowerShell-Kommando-Fenster als „Administrator“ und notieren Sie die aktuellen Einstellungen:<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Dann können Sie sie ändern. Die folgenden Befehle deaktivieren alle clientseitigen Caches<\/A> (einschließlich 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>Sie können diese Einstellungen dann mit folgendem Befehl überprüfen:<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Beachten Sie bitte: Die Änderungen treten erst in Kraft wenn der Client eine neue Verbindung zur Dateifreigabe herstellt. Ein Neustart der Esri-Server-Software bewirkt dies sofort.<\/P>Sobald Sie Ihre Einstellungen geändert haben, kehren Sie zu den Esri-Protokollen zurück um zu sehen ob sich Signatur sowie Fehlermeldungsinformationen und Häufigkeit bei gleicher Arbeitslast verbessert haben. Falls ja – herzlichen Glückwunsch! Falls nein – was dann?<\/P>

         Ist das Problem etwas sonst? <\/H4>Ja94wenn Sie an diesem Punkt sind, liegt das Problem woanders.<\/P>Sie haben bisher alle vernfcnftigen Hypothesen widerlegt. Ihnen bleibt eine Diagnose durch Ausschluss. Diese Diagnose besagt, dass die File Share-Lf6sung (ob absichtlich oder nicht) keine sofortige Konsistenz bietet. <\/P>In diesem Fall kann es hilfreich sein, beste4tigende Beweise zu haben. Eine sehr gute Mf6glichkeit daffcr ist der Vergleich mit einer anderen File Share-Lf6sung. Obwohl ein File Share von einer Windows-VM vielleicht keine Lf6sung ist, die Sie oder Ihre Organisation dauerhaft einsetzen mf6chten, kann es ffcr eine Untersuchung sehr nfctzlich sein. Esri hat keine empirischen Belege daffcr, dass File Shares von einer einzelnen Windows-Maschine sofortige Konsistenzprobleme verursachen. Es gibt keine starke theoretische Grundlage daffcr. Und wenn Sie Oplocks wie oben beschrieben deaktivieren, neutralisieren Sie auch die schwachen theoretischen Grundlagen. Das Windows-Maschinen-File Share mfcsste ffcr dieselben SMB-Parameter konfiguriert werden wie das ursprfcngliche File Share.  PowerShells Set-SmbServerConfiguration-Befehl kann verwendet werden, um die meisten Parameter abzugleichen, die das File Share-Administrationsteam von ihrer Lf6sung angibt.<\/P>Jedenfalls, wenn Sie Ihren Esri-Server(n) das Windows-Maschinen-File Share zuweisen und das Problemsignal verschwindet, wurde Ihre Diagnose durch Ausschluss beste4tigt. Von dort aus kann das File Share-Lf6sungsteam entscheiden, ob es versucht, die Eigenschaft der sofortigen Konsistenz nachzubilden oder angibt, dass es einen solchen Service nicht bereitstellen mf6chte. Sie haben also entweder eine Lf6sung oder eine Antwort. <\/P>Zusammenfassung<\/H1>Die Untersuchung eines vermuteten File Share-Problems ist eine der herausfordernderen Fehlersuche-Aufgaben im ArcGIS Enterprise-Verwaltungsbereich. Dieser Artikel beabsichtigt nicht, Sie als einzelnen Leser zu einem erfolgreichen Einzelpraktiker in diesem Bereich zu machen; vielmehr ist das Ziel, Ihnen einige grundlegende Informationen und einen Prozess zu vermitteln. Wenn Sie diesen Prozess sorgfe4ltig ausffchren, kf6nnen Sie viele verschiedene Spezialisten hinzuziehen, um Ihnen bei der Lf6sung zu helfen. Neben der Einbindung der entsprechenden Fachexperten aus Ihrer eigenen Organisation kf6nnen Sie Esri Technical Support und\/oder Professional Services zur Teilnahme hinzuziehen. Mit der Zeit kf6nnen Ihre sorgfe4ltige Ausffchrung und qualifizierte Teamteilnahme Probleme in diesem Bereich korrekt diagnostizieren.<\/P>Anhang: Protokollmeldungen, die mit File Share-Problemen korrelieren<\/H1>Die nachfolgenden Informationen sind eine Teilliste von Fehlercodes und Meldungen, die auf ein File Share-Problem in Ihrem ArcGIS Enterprise-System hinweisen kf6nnen.<\/P>Warn- und schwere Protokollmeldungen<\/H2>Auf dem Standardprotokollierungslevel deuten die folgenden Codes und Meldungen normalerweise auf ein Problem mit einem File Share (in einer Mehrmaschinenumgebung) hin. Es ist oft hilfreich, die Meldungen unmittelbar davor und danach anzusehen. Dabei sollten Sie die Felder Maschine, Prozess und Thread verwenden, um zusammenh40ngende Meldungen zu erkennen. Da es viele Maschinen, Prozesse und Threads gibt, k64nnen die zeitlich unmittelbar benachbarten Meldungen von einem anderen Prozess stammen.<\/P>Enterprise-Komponente<\/P><\/TD>Level<\/P><\/TD>Code<\/P><\/TD>Meldung<\/P><\/TD>Hinweise<\/P><\/TD><\/TR>Server<\/P><\/TD>WARNUNG<\/P><\/TD>7721<\/P><\/TD>22Fehler beim Schreiben des Heartbeats22<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>WARNUNG<\/P><\/TD>7712<\/P><\/TD>22Beim Synchronisieren mit dem Config Store wurde ein Fehler festgestellt22<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>SCHWERWIEGEND<\/P><\/TD>6561<\/P><\/TD>22Fehler beim Zurcckgeben aller Ordnerkonfigurationen22<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>SCHWERWIEGEND<\/P><\/TD>9000<\/P><\/TD>22Interner Serverfehler: ullstiger Dienst <name> nicht gefundendienst</name>dienst</name>dienst</name>dienst</name>dienst</name>dienst</name>dienst</name>dienst</name>dienst</name>dienst</name>dienst</name>dienst</name>dienst</name> nicht gefunden"<\/p>
         Beachten Sie, dass eine Anfrage f\u\u\"ur einen Dienst, der derzeit nicht existiert, ebenfalls eine solche Meldung erzeugt. Damit dies auf ein Problem mit einem File Share hinweist, muss der Dienst tats\u\"achlich im Standort vorhanden sein.<\p>
         
         Server
         SCHWERWIEGEND
         6605
         "Fehler beim Zurückgeben aller Dienstkonfigurationen im Ordner ... (Die Datei wurde nicht gefunden)"
          
         
         
         Server
         SCHWERWIEGEND
         6652
         "Dienst ... konnte nicht aus dem Konfigurationsspeicher gelesen werden ... (Die Datei wurde nicht gefunden)"
          
         
         
         Server
         SCHWERWIEGEND
         6566
         "Status des Dienstes ... konnte nicht abgerufen werden ... (Die Datei wurde nicht gefunden)"
          
         
         
         Server
         SCHWERWIEGEND
         9015
         "Fehler beim Abrufen der Dienstliste ... (Die Datei wurde nicht gefunden)"
          
         
         
         Server
         SCHWERWIEGEND
         6615
         "'Permissions'-Ressourceninformationen konnten nicht abgerufen werden ... "
         Diese Meldung ist nicht exklusiv für File Share-Probleme, kann aber damit assoziiert sein.
         
         Enterprise portal
         SCHWERWIEGEND
         218037
         „Der Portal-Standort wurde initialisiert und konfiguriert, ist aber derzeit nicht zugänglich, da das Inhaltsverzeichnis nicht verfügbar ist ...“
           Wie aus dieser Tabelle ersichtlich sein sollte, beziehen sich die meisten Meldungen auf eine Datei oder ein Verzeichnis, das nicht gefunden werden kann.Debug-LevelAuf dem DEBUG-Protokollierungslevel stehen weitere Meldungen zur Verfügung, die mehr Hinweise liefern können. Wenn Sie also nach einem potenziellen File Share-Problem suchen, kann es nützlich sein, für eine gewisse Zeit den DEBUG-Protokollierungslevel einzuschalten. Diese Debug-Level-Meldungen wären meist dazu geeignet, Hypothesen aus anderen Protokollebenen oder Quellen zu unterstützen (oder zu widerlegen) und eventuell relevante Details hinzuzufügen. Allein genommen wären sie kein handlungsrelevanter Hinweis auf ein File Share-Problem; es gibt andere plausible Interpretationen.- SITE_IN_USE = ArcGIS Server-Site wird derzeit von einer anderen Verwaltungsoperation konfiguriert. Bitte versuchen Sie es später erneut. - (6850)MACHINE_BEING_CONFIGURED = Servermaschine ''{0}'' wird derzeit von einer anderen Verwaltungsoperation konfiguriert. Bitte versuchen Sie es später erneut. - (6851)CONFIG_STORE_BEING_ACCESSED = Eine andere Verwaltungsoperation greift derzeit auf den Speicher zu. Bitte versuchen Sie es später erneut. - (6852)CLUSTER_BEING_CONFIGURED = Cluster ''{0}'' wird derzeit von einer anderen Verwaltungsoperation konfiguriert. Bitte versuchen Sie es später erneut. - (6853)CLUSTER_MACHINE_BEING_CONFIGURED = Cluster ''{0}'' - Maschine ''{1}'' wird derzeit von einer anderen Verwaltungsoperation konfiguriert. Bitte versuchen Sie es später erneut. - (7506)CLUSTER_RESOURCE_BEING_CONFIGURED = Cluster ''{0}'' Ressource wird derzeit von einer anderen Verwaltungsoperation konfiguriert. Bitte versuchen Sie es später erneut. - (7507)METRIC_BEING_CONFIGURED = Metrik ''{0}'' wird derzeit von einer anderen Verwaltungsoperation konfiguriert. Bitte versuchen Sie es später erneut. - (6614)SERVICE_BEING_CONFIGURED = Dienst ''{0}''.''{1}'' im Ordner ''{2}'' wird derzeit von einer anderen Verwaltungsoperation konfiguriert. Bitte versuchen Sie es später erneut. - (6854)SERVICE_CONFIG_BEING_WRITTEN = Eine andere Verwaltungsoperation schreibt gerade die Dienstkonfiguration. Bitte versuchen Sie es später erneut. - (6859)FOLDER_IN_USE = Ordner ''{0}'' wird derzeit von einer anderen Verwaltungsoperation verwendet. Bitte versuchen Sie es später erneut.- (6877)Einige dieser Meldungen können auch bei DEBUG-Code 9999 erscheinen. 

MikeSchiewe

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