Problemen oplossen met Bestandsdeling en ArcGIS Enterprise

DannyKrouk_ps

Inleiding

ArcGIS Enterprise-architecturen hebben vaak vereisten voor het gebruik van bestandsdelen voor opslag van gedeelde configuratiebestanden, inhoud of back-ups (https://enterprise.arcgis.com/en/server/latest/install/windows/choosing-a-nas-device.htm). Dit geldt met name wanneer het implementatiepatroon meerdere-machinesites omvat (zoals de high-availability configuraties). Er zijn toepassingen van bestandsdelen binnen elk van de hoofdcomponenten van ArcGIS Enterprise (Portal for ArcGIS, ArcGIS Server en ArcGIS Data Store).

In het onderstaande diagram bevinden de Shared Content en Shared Config-store and Directories zich op een bestandsdeel:

 

Bestandsdelen komen in vele typen en varianten, variërend van fysieke hardwareapparaten tot virtuele bestandssystemen of andere providers. Gedeelde bestandssystemen bieden een efficibare manier om inhoud te delen tussen meerdere componenten, maar ze kunnen ook uitdagingen met zich meebrengen die verband houden met prestaties, machtigingen of bestandsniveau consistentie.

Wanneer er problemen zijn in een ArcGIS Enterprise-implementatie en u vermoedt dat deze gerelateerd zijn aan gedeelde opslag, kan het moeilijk zijn om te beoordelen hoe uw architectuur mogelijke uitdagingen heeft en wat u eraan kunt doen. In de praktijk kan het oplossen van een probleem met een bestandsdeel uitdagend zijn, maar uw kansen op succes zijn veel beter als u een specifieke metriek of meting vaststelt om te definibren, een basislijn te creëren en het vermoedelijke probleem te testen. Dit artikel is ontworpen om u te helpen bepalen of er een probleem is met een bestandsdeel in uw ArcGIS Enterprise-implementatie, welke symptomen en indicatoren kunnen wijzen op dit type probleem (de handtekening), en hoe u de hoofdoorzaak kunt onderzoeken.

Hoewel vergelijkbare principes gelden voor Linux/NFS en Windows/SMB-systemen, richten de details van dit artikel zich op Windows/SMB-systemen.

Hoe gebruikt ArcGIS Enterprise een bestandsdeel?

Er zijn verschillende manieren waarop ArcGIS Enterprise een bestandsdeel gebruikt, waaronder de volgende:

1. Een geregistreerde data repository in een ArcGIS Server-site
2. Een gedeelde back-uplocatie voor ArcGIS Data Store-back-ups
3. Een locatie voor opslag en extractie van WebGISDR-back-ups voor disaster recovery-workflows
4. Een locatie om de config-store en server directories van een meerdere-machine ArcGIS Server-site op te slaan
5. Een locatie om de content directory van een hoog beschikbare ArcGIS Enterprise portal-site op te slaan

De laatste twee staan centraal in dit artikel; in deze gevallen speelt het bestandsdeel een rol in hoe elke machine in de meerdere-machine site weet wat er gaande is. Figuurlijk gezien fungeert het bestandsdeel als onderdeel van het nervous system van het ArcGIS Enterprise portal of ArcGIS Server-site wanneer het de config-store, server directories of content directory ondersteunt. Dus als er een probleem is met het bestandsdeel, kan de ArcGIS Server of Portal for ArcGIS-site een breed scala aan intermitterende symptomen vertonen, zoals problemen bij het publiceren van services of server onstabiliteit.

Herkennen en onderzoeken van een probleem gerelateerd aan een bestandsdeel

Het analyseren van een potentieel probleem met een bestandsdeel kan beginnen als een solistische inspanning waarbij u de softwarelogboeken voor elke ArcGIS-softwarecomponent onderzoekt. Als u daar echter bewijs vindt dat wijst op problemen met bestandstoegang, moet u samenwerken met andere informatiebronnen of softwarecomponenten. Dit betekent waarschijnlijk dat u met andere mensen moet samenwerken, aangezien de vereiste toegangsrechten en kennis zelden bij één persoon geconcentreerd zijn.

Dit artikel beschrijft wat u kunt nastreven met verschillende sets privileges en kennis. We beginnen met de logs in ArcGIS Enterprise om twee redenen: ten eerste gaan we ervan uit dat u die privileges hebt - en ten tweede is dit waar u de eerste bepaling maakt of er reden is om te geloven dat er een probleem is met het bestandsdeel en wat die reden is.

Fundamenten

Voordat u begint, wilt u uzelf zo productief mogelijk maken door een geschikte omgeving te kiezen, complexiteit onder controle te houden en het juiste team samen te stellen.

Omgevingen

U moet proberen gebruik te maken van lagere omgevingen (met andere woorden, niet uw productieomgeving) als u de problemen in die systemen kunt waarnemen. Welk probleem u ook ziet in productie, gebruik de ArcGIS Server-logs om de handtekening ervan te begrijpen. Het vinden van die handtekening wordt hieronder besproken. Kijk vervolgens in uw staging-, test- of UAT-omgeving om te zien of u dezelfde handtekening kunt vinden. Houd er rekening mee dat u mogelijk enige activiteit in die omgeving moet genereren om het probleem te zien (veel problemen treden niet op wanneer het systeem inactief is).

Als u het probleem in de lagere omgeving kunt zien, is dat de omgeving waarin u onderzoek moet doen. Omdat u meer controle hebt over het activiteitsniveau in die omgeving, wordt u minder afgeleid door niet-gerelateerde factoren. En omdat het praktischer is om te weten wat er gebeurt, kunt u betere ideeën vormen over mogelijke oorzaken. Ten slotte moet u bij het aanbrengen van wijzigingen voor probleemoplossing deze altijd eerst in lagere omgevingen aanbrengen indien mogelijk, om onnodige verstoringen voor gebruikers te voorkomen.

Complexiteit

U wilt zoveel mogelijk complexiteit verminderen zonder uw basisconfiguratie te wijzigen. Werken in een lagere omgeving helpt om complexiteit te verminderen. Maar wanneer u werkt met meerdere-machine sites betekent dit dat er meerdere machines zijn waarnaar u moet kijken voor elk gegeven probleem. 

Een vaak effectieve praktijk is om de redundante machines in de site uit te schakelen. Bijvoorbeeld, als er drie machines zijn in een ArcGIS Server-site, zet dan twee machines uit (het OS) of stop ze (in de site). De overgebleven machine gebruikt nog steeds het bestandsdeel voor dezelfde doeleinden en veel problemen zullen zich blijven uiten. Als het uitschakelen van de redundante machines ervoor zorgt dat het probleem verdwijnt, is dit een belangrijke aanwijzing over de aard van het probleem. Het vertelt specifiek dat het probleem te maken heeft met gelijktijdige clienttoegang en misschien niet met het netwerk.

Betrek anderen

Bij het oplossen van problemen die meerdere omgevingen overspannen, kunt u problemen tegenkomen die uw toegangsrechten of ervaring overstijgen. Hoewel privileges tijdelijk kunnen worden verleend, is ervaring in die domeinen net zo waardevol. Door uzelf op te zetten met een toegewijd probleemoplossingsteam zorgt u ervoor dat u proactief middelen beschikbaar hebt wanneer vragen zich voordoen.

Een veelvoorkomende bron van disfunctie bij dit soort virtuele teaminspanningen is ervoor zorgen dat iedereen begrijpt hoe zij zinvol kunnen bijdragen. Netwerkbeheerders en beheerders van bestandsdelen weten meestal weinig over Esri-software en worden waarschijnlijk niet gestimuleerd om veel over de applicaties op hun infrastructuur te leren. Ze hebben echter meestal nieuwsgierige geesten en lossen graag problemen op. Als u hen een open vraag stelt (Heeft het netwerk problemen?) of een voortijdig brede beschuldiging (Het netwerk veroorzaakt ons problemen), zult u waarschijnlijk geen interessante reacties krijgen. Aan de andere kant verhogen bewijsgestuurde, specifieke vragen uw kansen op een productieve reactie. Bijvoorbeeld: We zien 'connection time out'-berichten in onze applicatielogs op tijden X, Y en Z. Het lijkt elke 2 tot 3 uur voor te komen. Zou u verkeer kunnen vastleggen voor die periode en ons kunnen helpen begrijpen wat er gebeurt met de verbindingen?

Hypothesen gebaseerd op bewijs en onderzoek

Of u nu effectief probeert te zijn op eigen kracht of als onderdeel van een virtueel team, een bewijsgestuurde aanpak is de gouden standaard voor vooruitgang boeken. Enkele hoekstenen van een bewijsgestuurde aanpak zijn als volgt:

1. Maak uw eerste observaties voordat u wijzigingen aanbrengt aan het systeem en zorg ervoor dat deze observaties consistent zijn.
2. Begin met specifieke observaties over een bepaalde workflow, verzoek of operatie.
3. Zoek herhaling of reproduceerbaarheid. U wilt geen buitenbeentjes of valse alarmen najagen.
4. Documenteer terwijl u bezig bent. U wilt later details kunnen bevestigen en uw observaties kunnen delen met anderen.
5. Creëer meer dan één veronderstelde oorzaak voor elk probleem. Uw eerste idee is zelden het antwoord; creëer er meerdere en volg ze één voor één na.
6. Identificeer bewijs dat een hypothese kan weerleggen (of ondersteunen) en volg dat bewijs na.
7. Bruik expertise van anderen aan. Een van de beste manieren om deelname van een expert te krijgen is hen hun expertise te laten tonen door mogelijke betekenissen van een specifieke observatie uit te leggen. Het is dubbel winst: u vergroot uw begrip en maakt hen meer geneigd om u verder te helpen.

Wat kunt u leren als ArcGIS Enterprise-beheerder: De handtekening

De logs in ArcGIS Enterprise (ArcGIS Enterprise portal logs en ArcGIS Server logs) zijn waar u uw probleemhandtekening identificeert. Het is de meting die u zult gebruiken om vast te stellen of u een probleem heeft met het bestandsdeel en of een wijziging die u aanbrengt daadwerkelijk opgelost.<\/P>

Wanneer een ArcGIS Enterprise-component talks met een bestandsdeling, leest en schrijft deze bestandobjecten, vaak aangeduid als Input\/Output of I\/O. En dit gebeurt onder een specifiek account (het service account<\/A>), dus je kunt problemen met machtigingen en het bestandssysteem tegenkomen. <\/P>

Machtigingsproblemen zijn meestal goed herkenbaar in de logberichten en relatief eenvoudig op te lossen. Bijvoorbeeld, het logbericht Cannot write to directory path ''{0}''. Please check that the location is valid and that the ArcGIS Server account has permissions to the location. (code 6697) beschrijft de oorzaak en geeft een idee voor de oplossing. Houd er rekening mee dat effectieve machtigingen zowel die voor de share zelf als voor de bestanden en mappen die via de share worden blootgesteld, omvatten.<\/P>

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

Bestands- en mapmachtigingen<\/P><\/TD><\/TR>

<\/span> <\/P><\/TD><\/span> <\/P><\/TD><\/TR><\/TBODY><\/TABLE> <\/P>Logberichten die een pad vermelden gerelateerd aan de bestandsdeling, I\/O, of een IOException betekenen waarschijnlijk dat machtigingen niet het probleem zijn. Aan het einde van dit artikel is een bijlage met een gedeeltelijke lijst van logcodes en berichttypen die gecorreleerd zijn met bestandsdeelproblemen. Correlatie is fundamenteel om causaliteit vast te stellen. Als je berichten zoals deze ziet, is dat een goede indicatie dat je nauwkeuriger naar de bestandsdeling en\of het netwerkpad ernaartoe moet kijken, hoewel het geen onweerlegbaar bewijs is dat de bestandsdeling de schuldige is.  <\/P>De details van de logberichttypen kunnen de hoog-niveau patronen die je zoekt verbergen. Een bestandsdeling is een bestandssysteem aan de andere kant van een netwerk, dus als er een probleem is, kunnen er ten minste twee soorten bronnen zijn: de bestandsdelingsoplossing zelf of het netwerk. Hieronder volgen voorbeelden van berichten die wijzen op een probleem bij het openen van bestanden vanaf een bestandsdeling (sommige informatie verwijderd voor duidelijkheid of privacy):<\/P>Enterprise-component<\/P><\/TD>Niveau<\/P><\/TD>Code<\/P><\/TD>Bericht<\/P><\/TD>Aantekeningen<\/P><\/TD><\/TR>Server<\/P><\/TD>WAARSCHUWING<\/P><\/TD>7721<\/P><\/TD>failed to write heartbeat<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>WAARSCHUWING<\/P><\/TD>7712<\/P><\/TD>An error was encountered while synchronizing with the config store<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>ERNSTIG<\/P><\/TD>6561<\/P><\/TD>Failed to return all folder configurations<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>ERNSTIG<\/P><\/TD>9000<\/P><\/TD>Internal Server Error: Service <name> not found<\/P><\/TD>Let op dat een verzoek voor een service die momenteel niet bestaat ook zo'n bericht genereert. Om dit als een probleem met een bestandsdeling te zien, moet de service daadwerkelijk bestaan in de site.

of Fout. U moet filteren op basis van deze gebeurtenisniveaus en tijd.<\/P>

Wat kunnen deze logs u vertellen? <\/P>

1. Detecteert de lokale machine een probleem?
   1. Als u thematisch gerelateerde fouten niet vindt in de hoofd-Windows-logs voor de tijdstempels uit uw Esri-serverlogs, dan heeft u enig bewijs dat het probleem niet te wijten is aan een probleem dat specifiek is voor de client-machine. Hoewel dit misschien niet genoeg bewijs is om de mogelijkheid volledig uit te sluiten, hebt u belangrijke stappen gezet in die richting en kunt u uw inspanningen elders prioriteren.<\/LI>
   2. Als u interessante fouten op de lokale machine vindt, richt u uw inspanningen op het begrijpen en proberen op te lossen daarvan. <\/LI><\/OL><\/LI>
   3. Detecteert het SMB-protocol een probleem?
      1. Als u geen fouten vindt in de SMBClient-logs die overeenkomen met de tijdstempels, kunt u afleiden dat het probleem geen fout is wat betreft het SMB-protocol. Bijvoorbeeld, als u berichten onderzoekt die aangeven dat een bestand niet kan worden gevonden, zal het SMB-protocol dat niet classificeren als een fout— Voor zover het weet bestaat dat bestand niet. In dat geval functioneerde het protocol correct en gaf het correcte informatie terug. <\/LI>
      2. Aan de andere kant, als u een fout ziet zoals hierboven getoond, is het logisch om het onderzoek te richten op het SMB-protocol zelf.<\/LI><\/OL><\/LI><\/OL>

         Het vinden van thematisch gerelateerde fouten in deze logs is vaak zeer betekenisvol voor andere specialisten die niet vertrouwd zijn met Esri-logging maar waarschijnlijker zijn om besturingssysteemlogging te begrijpen of vertrouwen.<\/P>

         Wat u kunt leren met andere specialisten<\/H2>Veel problemen met bestandsdeling zullen zich niet uiten in de Event Viewer-logs van het client-besturingssysteem. De meeste andere informatiebronnen vereisen verhoogde privileges (boven Esri-serverbeheer of lokaal machinebeheer), gespecialiseerde kennis, of beide. Dus om vooruitgang te boeken in dit gebied moet u twee belangrijke eigenschappen inzetten: (a) uw winnende persoonlijkheid en (b) uw toewijding aan op bewijs gebaseerde onderzoek.<\/P>Netwerk mensen<\/H3>Als u de Esri-toepassingsloghandtekeningen hebt die wijzen op een netwerkgerelateerd probleem of storing, wilt u in dit gebied onderzoek doen.<\/P>De meeste netwerkproblemen die betrekking hebben op bestandsdeling zullen zich niet duidelijk uiten in klassieke netwerkbewakings- of loggingsoplossingen. Netwerkbewaking richt zich vaak op capaciteit, doorvoer en kwaliteit van service. Dat is nuttig voor netwerkplanning en algemeen beheer maar niet noodzakelijk behulpzaam bij het oplossen van specifieke verbindingen. Een firewall-logboek van weigeringen is het raadplegen waard, maar daar worden oorzaken van bestandsdeelproblemen meestal niet gevonden.<\/P>De antwoorden worden doorgaans gevonden door netwerkverkeer vast te leggen gedurende een korte periode wanneer het probleem zich voordoet of handmatig wordt geactiveerd. Het vastleggen van een intermitterend probleem is niet zo moeilijk als het lijkt. Men kan een ringbuffer-captatie instellen om continu vast te leggen naar een stabiele inventaris van bestanden, waarbij oudere gegevens worden overschreven na verloop van tijd. Het netwerkteam van uw organisatie heeft naast de tools en privileges waarschijnlijk ook kennis over hoe dit te doen. U hoeft dus niet precies te weten wanneer het probleem zich opnieuw zal voordoen. <\/P>In veel gevallen kan een ringbuffer vele uren aan netwerkcaptatiegegevens op een rollende basis bewaren. Wanneer het probleem zich opnieuw voordoet, vraagt u het netwerkteam om de trace te stoppen. Gebruik dan de tijdstempels uit de Esri-serverlogs om de netwerkcaptatie-informatie te onderzoeken. Met enige degelijke netwerkinfundamentele kennis (van het netwerkteam of uzelf) en wat toewijding kan er veel geleerd worden. Zelfs als uw team weinig netwerk-analysekennis heeft, kunt u zoeken naar anomalieën. Ofwel zijn er abnormale netwerkkenmerken bij de betreffende tijdstempels, ofwel niet. Als er iets abnormaals of verdachts is, kunnen extra experts indien nodig worden ingeschakeld. Specificiteit zal waarschijnlijk aantrekkelijk zijn voor deze experts.<\/P>Bestandsdeel mensen<\/H3>Als uw Esri-serverloghandtekeningen geen netwerkprobleem suggereren, wilt u dit gebied onderzoeken. Bestandsdeeloplossingen hebben, net als de meeste IT-systemen, doorgaans logs. Een beoordeling van deze logs op de betreffende tijden is gepast. Als er thematisch gerelateerde fouten zijn voor de betreffende tijdstempels, hebt u een waarschijnlijke oorzaak om verder te onderzoeken. En u hebt uw bestandsdeelbeheerteam (en hun leveranciersondersteuningsorganisatie) om de leiding te nemen.<\/P>Het is ook mogelijk dat de bestandsdeellogs geen gerelateerde fouten bevatten. Als het verzamelde bewijs andere waarschijnlijke bronnen heeft uitgesloten en de bestandsdeellogs geen probleem aangeven, blijft er nog een mogelijkheid over. Het is mogelijk dat de bestandsdeling en de Esri-software problemen anders classificeren. Bijvoorbeeld, als een bestandsdeling is ontworpen of geconfigureerd om uiteindelijke consistentie te bieden, zal deze daar geen fouten over registreren. Maar we weten dat ArcGIS Server onmiddellijke consistentie verwacht. Dus ziet de bestandsdeling geen fout, maar krijgt ArcGIS Server niet wat het nodig heeft.<\/P>Laten we dit idee wat verder verkennen, want het komt wel eens voor, met behulp van het voorbeeld van een ArcGIS Server-site met twee machines waarbij de configuratiewinkel en servermappen op een bestandsdeling zijn opgeslagen. Als machine A naar een bestand schrijft, zou ArcGIS Server-site machine B die nieuwe informatie direct moeten kunnen lezen. Dat is onmiddellijke consistentie: lezen na schrijven voor elke client naar de bestandsdeling. Dus als ArcGIS Server zegt: Hé, ik kan dat bestand niet vinden, of Dat bestand ziet er anders uit dan ik dacht, en de bestandsdeling zegt: Ik weet van geen problemen, wat is dan uw resulterende hypothese? Nadat andere waarschijnlijke oorzaken zijn uitgesloten, is uw resulterende hypothese dat de bestandsdeling geen lezen na schrijven consistentie biedt. Geen ander idee past zo goed bij de gegevens.<\/P>Wat doet u daarmee? Dit is weer een onderzoek met het bestandsdeelbeheerteam. Maar in plaats van zich te richten op een fout in hun logs gaat het erom te begrijpen hoe meerdere clients die hetzelfde bestand bekijken op hetzelfde moment dit altijd in exact dezelfde staat zien. Geen enkele client kan de vorige staat als geldig zien nadat het bestand door een andere client is gewijzigd. En geen enkele client kan een bestand wijzigen wanneer een andere client er een exclusieve lock op heeft. Oei. We zeiden het L-woord (lock). Dat brengt nog één extra term of concept naar voren die u misschien eerder hebt gehoord: opportunistische locking van bestanden, ook wel Oplocks genoemd.<\/P>Is het probleem Oplocks? <\/H4>Hoewel het zeker mogelijk is dat Oplocks problemen veroorzaken voor uw systeem, zijn bij de problemen waar we hier over praten de kansen tegen die mogelijkheid. Maar omdat besluitvorming gebaseerd op bewijs vooruitgang brengt, kunt u bewijs gebruiken om aan te tonen of het wel of niet een oorzaak is.<\/P>Het is zinvol na te denken over wat Oplocks en alternatieven zijn. Oplocks zijn opportunistische locks. De client (het Esri-systeem) gaat optimistisch ervan uit dat bestanden waarvan hij weet op de bestandsdeling ongewijzigd en/of veilig te wijzigen zijn tenzij hij iets hoort van de server (de bestandsdeling). Het tegenovergestelde van opportunistische locking is pessimistische locking (geen locking is geen optie). In dat geval gaat de client pessimistisch ervan uit dat andere clients mogelijk gebruik maken van bestanden waarvan hij weet op de bestandsdeling, dus controleert hij voordat hij iets doet. Opportunistische locks zijn een goede strategie wanneer de meeste bestanden niet door meer dan één client tegelijk worden benaderd. Pessimistische locks zijn beter wanneer bestanden vaak door meer dan één client tegelijk worden benaderd. Wat weten we over een ArcGIS Server- of Portal for ArcGIS-site met meerdere machines? Er zijn minstens twee clients die dezelfde bestanden tegelijk benaderen.<\/P>Dus Oplocks zijn suboptimaal voor Esri-servergebruiksscenario's. Maar is het oorzaak van uw probleem? Dat weet u niet zeker. Omdat u uw probleemhandtekening uit uw Esri-logs hebt, kunt u de Oplocks-instellingen wijzigen en kijken of dit verandert aan de probleemhandtekening (de aanwezigheid van het bericht en hoe vaak dit voorkomt bij dezelfde werklast). Deze parameters kunnen worden gewijzigd in het client-besturingssysteem (de machines waarop Esri-software draait) of in de bestandsdeeloplossing, afhankelijk van uw configuratie.<\/P>Hier leest u hoe dit te doen als u lokaal machinebeheerder bent voor het client-besturingssysteem. Open een PowerShell-opdrachtvenster als als Administrator en noteer de huidige instellingen:<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Vervolgens kunt u ze wijzigen. De volgende opdrachten schakelen alle client-side caching<\/A> uit (inclusief 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>U kunt deze instellingen vervolgens inspecteren met dit commando:<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Let op: De wijzigingen treden pas in werking wanneer de client opnieuw verbinding maakt met de bestandsdeling. Het herstarten van Esri-serversoftware zorgt ervoor dat dit meteen gebeurt.<\/P>Zodra u uw instellingen hebt gewijzigd, keert u terug naar de Esri-logs om te zien of handtekening, foutmeldinginformatie en frequentie voor dezelfde werklast zijn aangepakt. Als dat zo is, kunt u feestvieren. Zo niet, wat dan?<\/P>

         Is het probleem iets anders? <\/H4>Jaals je op dit punt bent, is het probleem iets anders.<\/P>Je hebt tot nu toe alle redelijke hypothesen weerlegd. Je blijft over met een diagnose door uitsluiting. Die diagnose is dat de file share-oplossing (of dit nu door ontwerp is of niet) geen onmiddellijke consistentie biedt. <\/P>In deze situatie kan het nuttig zijn om ondersteunend bewijs te hebben. Een zeer goede manier om dat te doen is door te vergelijken met een andere file share-oplossing. Hoewel een file share van een Windows virtuele machine misschien geen oplossing is die jij of jouw organisatie permanent willen adopteren, kan het zeer nuttig zijn voor een onderzoek. Esri heeft geen empirisch bewijs dat file shares van een enkele Windows-machine onmiddellijke consistentieproblemen veroorzaken. Er is geen sterke theoretische basis voor. En als je Oplocks uitschakelt zoals hierboven beschreven, neutraliseer je ook de zwakke theoretische basis. De Windows-machine file share moet worden geconfigureerd met dezelfde SMB-parameters als de oorspronkelijke file share.  PowerShell's Set-SmbServerConfiguration-commando kan worden gebruikt om de meeste parameters af te stemmen die het file share-beheerteam zou aangeven vanuit hun oplossing.<\/P>In ieder geval, als je jouw Esri-server(s) richt op de Windows-machine file share en het probleemkenmerk verdwijnt, is jouw diagnose door uitsluiting bevestigd. Vanaf daar kan het file share-oplossingsteam beslissen of ze willen proberen de onmiddellijke consistentiekenmerk te evenaren of aangeven dat ze zo'n dienst niet willen leveren. Dus, je hebt ofwel een oplossing of een antwoord. <\/P>Ter conclusie<\/H1>Het onderzoeken van een vermoedelijk file share-probleem is een van de meer uitdagende probleemoplossingsinspanningen in de ArcGIS Enterprise-beheeromgeving. Dit artikel heeft niet tot doel jou, de individuele lezer, een succesvolle solo beoefenaar in dit domein te maken; eerder is het doel om je wat fundamentele informatie en een proces te geven. Als je dit proces zorgvuldig uitvoert, kun je veel verschillende specialisten inschakelen om je te helpen de oplossing te bereiken. Naast het betrekken van de gerelateerde domeinexperts uit jouw eigen organisatie, kun je Esri Technical Support en/of Professional Services laten deelnemen. Met tijd kunnen jouw zorgvuldige uitvoering en kwalitatieve teamdeelname problemen in dit domein correct diagnosticeren.<\/P>Bijlage: Logberichten die gecorreleerd zijn met file share-problemen<\/H1>De onderstaande informatie is een gedeeltelijke lijst van foutcodes en berichten die kunnen wijzen op een file share-probleem in jouw ArcGIS Enterprise-systeem.<\/P>Waarschuwing en ernstige logberichten<\/H2>Op het standaard logniveau duiden de volgende codes en berichten meestal op een probleem met een file share (in een site met meerdere machines). Het is vaak nuttig om naar de berichten direct ervoor en erna te kijken. Wanneer je dat doet, wil je de machine-, proces- en threadvelden gebruiken om gerelateerde berichten te herkennen. Omdat er veel machines, processen en threads zijn, kunnen de direct aangrenzende berichten, qua tijd, van een ander proces zijn.<\/P>Enterprise Component<\/P><\/TD>Niveau<\/P><\/TD>Code<\/P><\/TD>Bericht<\/P><\/TD>Aantekeningen<\/P><\/TD><\/TR>Server<\/P><\/TD>WAARSCHUWING<\/P><\/TD>7721<\/P><\/TD>1 schrijven heartbeat mislukt7<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>WAARSCHUWING<\/P><\/TD>7712<\/P><\/TD>Er trad een fout op tijdens synchronisatie met de config store<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>ERNSTIG<\/P><\/TD>6561<\/P><\/TD>1 kon niet alle mapconfiguraties retourneren7<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>ERNSTIG<\/P><\/TD>9000<\/P><\/TD>Interne serverfout: Service <naam> niet gevonden<\/P><\/TD>Let op dat een verzoek voor een service die momenteel niet bestaat ook zo'n bericht genereert. Om dit als een probleem met een file share aan te duiden, moet de service daadwerkelijk bestaan in de site.<\/P><\/TD><\/TR>Server<\/P><\/TD>ERNSTIG<\/P><\/TD>6605<\/P><\/TD>1 kon niet alle serviceconfiguraties in de map f... (Het systeem kan het opgegeven bestand niet vinden)f7<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>ERNSTIG<\/P><\/TD>6652<\/P>

MikeSchiewe

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