Řešení problémů se sdílenými soubory a ArcGIS Enterprise

DannyKrouk_ps

Úvod

Architektury ArcGIS Enterprise často vyžadují použití sdílených složek pro ukládání sdílených konfiguračních souborů, obsahu nebo záloh (https://enterprise.arcgis.com/en/server/latest/install/windows/choosing-a-nas-device.htm). To platí zejména tehdy, když nasazení zahrnuje více strojů (například konfigurace s vysokou dostupností). Sdílené složky se používají napříč hlavními komponentami ArcGIS Enterprise (Portal for ArcGIS, ArcGIS Server a ArcGIS Data Store).

Na diagramu níže jsou „Shared Content“ a „Shared Config-store and Directories“ umístěny na sdílené složce:

 

Sdílené složky existují v mnoha typech a variantách, od fyzických hardwarových zařízení po virtuální souborové systémy nebo jiné poskytovatele. Sdílené souborové systémy poskytují efektivní způsob sdílení obsahu mezi více komponentami, ale mohou také přinášet výzvy týkající se výkonu, oprávnění nebo konzistence na úrovni souborů.

Když se v nasazení ArcGIS Enterprise vyskytnou problémy a máte podezření, že by mohly souviset se sdíleným úložištěm, může být obtížné vědět, jak zhodnotit vaši architekturu z hlediska možných problémů a co s tím dělat. V praxi může být řešení problému se sdílenou složkou náročné, ale vaše šance na úspěch jsou mnohem lepší, pokud stanovíte konkrétní metriku nebo měření k definování, vytvoření základní linie a testování podezřelého problému. Tento článek je navržen tak, aby vám pomohl určit, zda ve vašem nasazení ArcGIS Enterprise existuje problém se sdílenou složkou, jaké příznaky a indikátory by mohly na tento typ problému ukazovat (jeho podpis) a jak vyšetřit jeho příčinu.

I když podobné principy platí pro Linux/NFS a Windows/SMB systémy, detaily tohoto článku se zaměřují na Windows/SMB systémy.

Jak ArcGIS Enterprise používá sdílenou složku?

Existuje několik způsobů, jak ArcGIS Enterprise využívá sdílenou složku, včetně následujících:

1. Zaregistrovaný datový repozitář v lokalitě ArcGIS Server
2. Sdílené záložní místo pro zálohy ArcGIS Data Store
3. Místo pro ukládání a extrakci záloh WebGISDR pro pracovní postupy obnovy po havárii
4. Místo pro uložení „config-store“ a „server directories“ vícestrojové lokality ArcGIS Server
5. Místo pro uložení „content directory“ vysoce dostupné portálové lokality ArcGIS Enterprise

Dva poslední body jsou předmětem tohoto článku; v těchto případech hraje sdílená složka roli v tom, jak každý stroj ve vícestrojové lokalitě ví, co se děje. Metaforicky funguje sdílená složka jako část „nervového systému“ portálu ArcGIS Enterprise nebo lokality ArcGIS Server při podpoře „config-store“, „server directories“ nebo „content directory“. Pokud tedy dojde k problému se sdílenou složkou, lokalita ArcGIS Server nebo Portal for ArcGIS může vykazovat širokou škálu přerušovaných příznaků, jako jsou potíže s publikováním služeb nebo „nestabilita“ serveru.

Rozpoznání a vyšetřování problému souvisejícího se sdílenou složkou

Analýza potenciálního problému se sdílenou složkou může začít jako samostatná činnost zkoumáním softwarových logů každé komponenty ArcGIS. Pokud však najdete důkazy ukazující na problémy s přístupem k souborům, budete muset spolupracovat s dalšími zdroji informací nebo softwarovými komponentami. To pravděpodobně znamená spolupráci s dalšími lidmi, protože požadovaná přístupová práva a znalosti jsou zřídka soustředěny v jedné osobě.

Tento článek popisuje, co můžete dělat s různými sadami oprávnění a znalostí. Začínáme logy v ArcGIS Enterprise ze dvou důvodů: za prvé předpokládáme, že tato oprávnění máte – a za druhé zde provedete počáteční určení toho, zda existuje důvod věřit tomu, že je problém se sdílenou složkou a jaký tento důvod je.

Základy

Před začátkem si chcete zajistit co největší produktivitu výběrem vhodného prostředí, kontrolou komplexity a sestavením správného týmu.

Prostředí

Měli byste se snažit využít „nižší prostředí“ (jinými slovy ne produkční prostředí), pokud můžete pozorovat problémy i v těchto systémech. Jakýkoli problém vidíte v produkci, použijte logy ArcGIS Server k pochopení jeho podpisu. Nalezení tohoto podpisu je popsáno níže. Poté hledejte stejný podpis ve vašem stagingovém, testovacím nebo UAT prostředí. Všimněte si, že možná budete muset v tomto prostředí vyvolat nějakou aktivitu, abyste problém viděli (mnoho problémů se neprojevuje při nečinnosti systému).

Pokud problém vidíte v nižším prostředí, měli byste tam provádět vyšetřování. Protože máte větší kontrolu nad úrovní aktivity v tomto prostředí, budete méně rušeni nesouvisejícími faktory. A protože je praktičtější vědět, co se děje, můžete lépe formulovat možné příčiny. Nakonec byste měli změny pro řešení problémů vždy provádět nejprve v nižších prostředích, pokud je to možné, abyste předešli zbytečným narušením uživatelů.

Komplexita

Chcete omezit komplexitu co nejvíce bez změny základní konfigurace. Práce v nižším prostředí pomáhá snížit komplexitu. Ale když pracujete s vícestrojovými lokalitami, více strojů znamená více míst k hledání jakéhokoli problému. 

Často účinnou praxí je vypnout redundantní stroje v lokalitě. Například pokud jsou ve vaší lokalitě ArcGIS Server tři stroje, vypněte (operační systém) nebo zastavte (v lokalitě) dva stroje. Zbývající stroj stále používá sdílenou složku ke stejným účelům a mnoho problémů se bude nadále projevovat. Pokud vypnutí redundantních strojů způsobí zmizení problému, je to důležitý náznak o povaze problému. Konkrétně to znamená, že problém souvisí s současným přístupem klientů a možná ne sítě.

Zapojte ostatní

Při řešení problémů napříč více prostředími můžete narazit na problémy přesahující vaše přístupová práva nebo zkušenosti. Zatímco oprávnění lze dočasně udělit, zkušenosti v těchto oblastech jsou stejně cenné. Sestavení specializovaného týmu pro řešení problémů zajistí, že budete mít zdroje připravené předem při vzniku otázek.

Častým zdrojem dysfunkce v takovém virtuálním týmovém úsilí je nedostatečné pochopení toho, jak může každý smysluplně přispět. Správci sítí a správci sdílených složek obvykle vědí málo o Esri softwaru a nejsou motivováni učit se hodně o aplikacích na jejich infrastruktuře. Nicméně obvykle mají zvědavou mysl a rádi řeší problémy. Pokud jim položíte otevřenou otázku („Má síť nějaké problémy?“) nebo předčasně široké obvinění („Síť nám způsobuje problémy“), pravděpodobně nedostanete zajímavé odpovědi. Naopak pokud položíte otázky založené na důkazech a konkrétní dotazy, vaše šance na produktivní odpověď vzrostou. Například: „Vidíme zprávy ‚connection time out‘ v našich aplikačních logech v časech X, Y a Z. Zdá se to probíhat každé 2 až 3 hodiny. Mohli byste zachytit provoz za toto období a pomoci nám pochopit co se děje s připojením?“

Hypotézy založené na důkazech a vyšetřování

Ať už se snažíte být efektivní sami nebo jako součást virtuálního týmu, přístup založený na důkazech je zlatým standardem pro dosažení pokroku. Některé základní kameny přístupu založeného na důkazech jsou následující:

1. Proveďte své počáteční pozorování před provedením jakýchkoli změn systému a ujistěte se, že tato pozorování jsou konzistentní.
2. Začněte s konkrétními pozorováními týkajícími se určitého pracovního postupu, požadavku nebo operace.
3. Najděte opakování nebo opakovatelnost. Nechcete honit výjimky nebo falešné poplachy.
4. Dokumentujte průběh práce. Chcete mít možnost vrátit se zpět a potvrdit detaily svých pozorování a sdílet je s ostatními.
5. Vytvořte více než jednu hypotetickou příčinu každého problému. Vaše první myšlenka zřídka bývá odpovědí; vytvořte několik hypotéz a postupně je prověřujte.
6. Identifikujte důkazy které by mohly hypotézu vyvrátit (nebo podpořit) a pak tyto důkazy sledujte.
7. Využijte odbornosti ostatních. Jedním z nejlepších způsobů jak získat účast experta je požádat ho aby předvedl svou odbornost vysvětlením možných významů konkrétního pozorování. Je to dvojité vítězství: posunete své porozumění vpřed a zároveň zvýšíte pravděpodobnost jejich ochoty vám dále pomoci.

Co můžete zjistit jako administrátor ArcGIS Enterprise: Podpis

Logy v ArcGIS Enterprise (logy portálu ArcGIS Enterprise i logy ArcGIS Server) jsou místem kde identifikujete podpis svého problému. Je to měření které použijete k určení zda máte problém se sdílenou složkou a zda změna kterou provedete skutečně vyřešeno.<\/P>

Když komponenta ArcGIS Enterprise „komunikuje“ se sdílením souborů, čte a zapisuje objekty souborů, často označované jako vstup\/výstup nebo I\/O. A dělá to jako konkrétní účet (service account<\/A>), takže můžete mít problémy s oprávněními a problémy se souborovým systémem. <\/P>

Problémy s oprávněními jsou obvykle v logovacích zprávách dobře rozpoznatelné a relativně snadno řešitelné. Například logovací zpráva „Nelze zapisovat do cesty adresáře ''{0}''. Zkontrolujte, zda je umístění platné a zda má účet ArcGIS Server oprávnění k tomuto umístění.“ (kód 6697) popisuje příčinu a poskytuje nápad na řešení. Vezměte na vědomí, že efektivní oprávnění zahrnují jak oprávnění ke sdílení samotnému, tak k souborům a adresářům zpřístupněným prostřednictvím sdílení.<\/P>

Oprávnění ke sdílení<\/P><\/TD>

Oprávnění k souborům a adresářům<\/P><\/TD><\/TR>

<\/span> <\/P><\/TD><\/span> <\/P><\/TD><\/TR><\/TBODY><\/TABLE> <\/P>Logovací zprávy, které zmiňují cestu související se sdílením souborů, I\/O nebo IOException, pravděpodobně znamenají, že problém není v oprávněních. Na konci tohoto článku je příloha s částečným seznamem kódů logů a typů zpráv, které korelují s problémy se sdílením souborů. Korelace je základem pro stanovení příčinné souvislosti. Pokud vidíte takovéto zprávy, je to dobrý indikátor, že byste měli podrobněji prozkoumat sdílení souborů a/nebo síťovou cestu k němu, i když to není nevyvratitelný důkaz, že chyba je na straně sdílení souborů.  <\/P>Detaily typů logovacích zpráv mohou zakrýt vysokou úroveň vzorců, které hledáte. Sdílení souborů je souborový systém na druhé straně sítě, takže pokud je problém, mohou být alespoň dva typy zdrojů: samotné řešení sdílení souborů nebo síť. Následují příklady zpráv indikujících problém s přístupem k souborům ze sdílení souborů (některé informace byly odstraněny pro přehlednost nebo ochranu soukromí):<\/P>Enterprise Component<\/P><\/TD>Úroveň<\/P><\/TD>Kód<\/P><\/TD>Zpráva<\/P><\/TD>Poznámky<\/P><\/TD><\/TR>Server<\/P><\/TD>VAROVÁNÍ<\/P><\/TD>7721<\/P><\/TD>„selhalo zápis heartbeat“<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>VAROVÁNÍ<\/P><\/TD>7712<\/P><\/TD>„Během synchronizace s config store došlo k chybě“<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>ZÁVAŽNÉ<\/P><\/TD>6561<\/P><\/TD>„Nepodařilo se vrátit všechny konfigurace složek“<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>ZÁVAŽNÉ<\/P><\/TD>9000<\/P><\/TD>„Interní chyba serveru: ‚Service <name> nenalezen‘“<\/P> Poznámka: Žádost o službu, která momentálně neexistuje, také vygeneruje podobnou zprávu. Aby tato zpráva indikovala problém se sdílením souborů, musí služba skutečně existovat na lokalitě.<\p> nebo Chyba. Měli byste filtrovat na základě těchto úrovní událostí a času.<\/P> Co vám tyto záznamy mohou říci? <\/P> Zjišťuje místní počítač problém? Pokud v hlavních Windows záznamech pro časová razítka z vašich Esri serverových záznamů nenajdete tematicky související chyby, máte nějaký důkaz, že problém není způsoben problémem specifickým pro klientský počítač. I když to nemusí být dostatečný důkaz k úplnému vyloučení této možnosti, podnikli jste důležité kroky k tomuto cíli a můžete své úsilí upřednostnit jinde.<\/LI> Pokud na místním počítači najdete zajímavé chyby, upřednostníte své úsilí na jejich pochopení a pokus o jejich vyřešení. <\/LI><\/OL><\/LI> Zjišťuje protokol SMB problém? Pokud v SMBClient záznamech nenajdete chyby odpovídající časovým razítkům, můžete usoudit, že problém není chybou z hlediska protokolu SMB. Například pokud vyšetřujete zprávy naznačující, že soubor nelze najít, protokol SMB to nebude klasifikovat jako chybu — podle všeho ten soubor neexistuje. V takovém případě protokol fungoval správně a vrátil správnou informaci. <\/LI> Na druhou stranu, pokud vidíte chybu jako je ta výše uvedená, dává smysl zaměřit vyšetřování přímo na protokol SMB.<\/LI><\/OL><\/LI><\/OL> Nalezení tematicky souvisejících chyb v těchto záznamech je často velmi významné pro jiné specialisty, kteří nejsou obeznámeni s Esri logováním, ale pravděpodobně lépe rozumějí nebo důvěřují logování operačního systému.<\/P>

Co se můžete naučit s jinými specialisty<\/H2>Mnoho problémů se sdílením souborů se neprojeví v Event Viewer záznamech klientského OS. Většina ostatních zdrojů informací vyžaduje zvýšená oprávnění (nad rámec správy Esri serveru nebo místního počítače), specializované znalosti nebo obojí. Takže abyste v této oblasti pokročili, musíte využít dvě důležité vlastnosti: (a) vaši vítěznou osobnost a (b) váš závazek k vyšetřování založenému na důkazech.<\/P>Lidé z oblasti sítí<\/H3>Pokud máte podpisy aplikace Esri naznačující síťový problém nebo selhání, budete chtít tuto oblast prozkoumat.<\/P>Většina síťových problémů souvisejících se sdílením souborů se neprojeví jasně v klasických řešeních monitorování nebo logování sítě. Monitorování sítě se často zaměřuje na kapacitu, propustnost a kvalitu služby. To je užitečné pro plánování a správu sítě obecně, ale nemusí být nutně užitečné při řešení konkrétních připojení. Záznamy firewallu o zamítnutích stojí za konzultaci, ale obvykle tam nejsou příčiny problémů se sdílením souborů.<\/P>Odpovědi jsou typicky nalezeny zachycením síťového provozu během krátkého období, kdy problém nastane nebo je manuálně vyvolán. Zachytit přerušovaný problém není tak těžké, jak by se mohlo zdát. Lze nastavit zachytávání do kruhového bufferu, který uchovává stabilní inventář souborů a přepisuje je postupem času. Síťový tým vaší organizace má kromě nástrojů a oprávnění pravděpodobně i znalosti, jak to udělat. Takže nemusíte přesně vědět, kdy problém nastane příště. <\/P>V mnoha případech může kruhový buffer uchovávat data zachycení sítě po mnoho hodin na průběžném základě. Když problém opět nastane, požádejte síťový tým o zastavení sledování. Poté použijte časová razítka z Esri serverových záznamů k prozkoumání informací ze zachycení sítě. S pevnými základy znalostí sítí (od síťového týmu nebo vás) a odhodláním lze mnoho zjistit. I když váš tým nemá mnoho znalostí o analýze sítí, můžete hledat anomálie. Buď existují nebo neexistují abnormální síťové charakteristiky v daných časových razítcích. Pokud je něco abnormálního nebo podezřelého, mohou být podle potřeby přizváni další odborníci. Specifičnost bude pro tyto odborníky pravděpodobně atraktivní.<\/P>Lidé ze sdílení souborů<\/H3>Pokud vaše Esri serverové podpisy nenasvědčují síťovému problému, budete chtít tuto oblast prozkoumat. Řešení sdílení souborů mají jako většina IT systémů obvykle záznamy. Přezkoumání těchto záznamů v daných časech je vhodné. Pokud existují tematicky související chyby pro daná časová razítka, máte pravděpodobnou příčinu k dalšímu vyšetřování. A máte svůj tým správy sdílení souborů (a podporu jejich dodavatele), který vás povede.<\/P>Je také možné, že záznamy sdílení souborů nemají související chyby. Pokud nasbírané důkazy vyloučily jiné pravděpodobné zdroje a záznamy sdílení souborů neukazují problém, zbývá ještě jedna možnost. Je možné, že sdílení souborů a software Esri klasifikují problémy odlišně. Například pokud je sdílení souborů navrženo nebo nakonfigurováno tak, aby poskytovalo konečnou konzistenci, nebude o tom zaznamenávat chyby. Ale víme, že ArcGIS Server očekává okamžitou konzistenci. Takže sdílení souborů nevidí žádnou chybu, ale ArcGIS Server nedostává to, co potřebuje.<\/P>Pojďme tuto myšlenku trochu více prozkoumat, protože se skutečně objevuje, na příkladu dvoupočítačového ArcGIS Server webu s konfiguračním úložištěm a serverovými adresáři uloženými na sdílení souborů. Pokud počítač A zapíše do souboru, měl by počítač B webu ArcGIS Server být schopen ihned přečíst tyto nové informace. To je okamžitá konzistence: čtení po zápisu pro jakéhokoli klienta ke sdílení souborů. Takže pokud ArcGIS Server říká: „Hej, nemohu ten soubor najít,“ nebo „Ten soubor vypadá jinak než jsem si myslel,“ a sdílení souborů říká: „Nevím o žádných problémech,“ jaká je vaše výsledná hypotéza? Po vyloučení jiných pravděpodobných příčin je vaše výsledná hypotéza taková, že sdílení souborů neposkytuje konzistenci „čtení po zápisu“. Žádný jiný nápad tak dobře nesedí na data.<\/P>Co s tím uděláte? Toto je další vyšetřování se správcem sdílení souborů. Ale místo zaměření na chybu v jeho záznamech jde o snahu pochopit, jak více klientů současně vidí stejný soubor ve stejném stavu vždycky stejně. Žádný klient nemůže vidět předchozí stav jako platný poté, co byl soubor změněn jiným klientem. A žádný klient nemůže změnit soubor, když má jiný klient exkluzivní zámek na něj. Uf-uf. Řekli jsme „L-slovo“ (lock). To přináší jeden další termín nebo koncept, který jste možná slyšeli diskutovat dříve: oportunistické zamykání souborů, také označované jako Oplocks.<\/P>Je problém Oplocks?<\/H4>I když je určitě možné, že Oplocks způsobují problém ve vašem systému, u problémů o kterých zde mluvíme jsou šance proti tomu. Ale protože rozhodování založené na důkazech je cestou k pokroku, můžete použít důkazy k ověření zda je to příčina.<\/P>Stojí za to přemýšlet o tom co jsou Oplocks a jejich alternativy. Oplocks jsou oportunistické zámky. Klient (systém Esri) optimisticky předpokládá, že soubory které zná na sdílení souborů jsou nezměněné a/nebo bezpečné ke změně pokud nedostane zprávu od serveru (sdílení souborů). Opakem oportunistického zamykání je pesimistické zamykání (bez zamykání není možnost). V tomto případě klient pesimisticky předpokládá, že jiné klienti mohou používat známé soubory na sdílení souborů a proto před jakoukoli akcí kontroluje stav. Oportunistické zámky jsou skvělá strategie když většina souborů není současně přístupná více než jedním klientem. Pesimistické zámky jsou lepší strategie když jsou soubory často přístupné více než jedním klientem současně. Co víme o vícepočítačovém ArcGIS Server nebo Portal for ArcGIS webu? Jsou tam alespoň dva klienti přistupující ke stejným souborům současně.<\/P>Takže Oplocks jsou suboptimální pro použití Esri serveru. Ale je to příčina vašeho problému? To nevíte. Protože máte svůj podpis problému ze svých Esri logů můžete změnit nastavení Oplocks a zjistit zda to změní podpis problému (přítomnost zprávy a její frekvenci při stejné pracovní zátěži). Tyto parametry lze měnit v klientském OS (počítače na kterých běží software Esri) nebo v řešení sdílení souborů podle vaší konfigurace.<\/P>Zde je návod jak to udělat pokud jste místní správce počítače pro klientský OS. Otevřete PowerShell okno příkazové řádky jako „Administrátor“ a poznamenejte si aktuální nastavení:<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Poté je můžete změnit. Následující příkazy zakážou veškeré klientské ukládání do mezipaměti<\/A> (včetně 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>Můžete pak tato nastavení zkontrolovat tímto:<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Všimněte si prosím že změny vstoupí v platnost při dalším navázání nového připojení klienta ke sdílení souborů. Restartování Esri serverového softwaru by způsobilo okamžité provedení změn.<\/P>Až změníte svá nastavení vraťte se k Esri logům abyste zjistili zda byl podpis problému – informace o chybové zprávě a její frekvence při stejné pracovní zátěži – vyřešený. Pokud ano můžete slavit. Pokud ne co pak?<\/P>

Je problém něco jinak? <\/H4>Ano0404 pokud jste v tomto bod1b, proble9m je n1bco jine9ho.<\/P>Dosud jste vyvre1tili v61echny rozumne9 hypote9zy. Z6fste1ve1 ve1m diagnf3za vylou0denedm. Tato diagnf3za je, 7ee 59e61ened sd2blene9ho souboru (a0d u7e z d6bznu nebo ne) neposkytuje okam7eitou konzistenci. <\/P>V t1bchto p59
epadech m6f

ze bdt u
ite
n
o m
o m
o m

m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
m
o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o m o mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo mo ťit potvrzujícím dokažem. Velmi dobrým způsobe, jak toho dosáhnout, je porovnání s jiným řešením sdíleného souboru. I když sdílení souborů z Windows virtuálního stroje nemusí být řešením, které vy nebo vaše organizace chcete trvale přijmout, může být velmi užitečné při vyšetřování. Esri nemá empirické důkazy, že sdílení souborů z jednoho Windows stroje způsobuje problémy s okamžitou konzistencí. Neexistuje pro to silný teoretický základ. A pokud vypnete Oplocks, jak je popsáno výše, neutralizujete i slabé teoretické základy. Sdílení souborů na Windows stroji by mělo být nakonfigurováno se stejnými SMB parametry jako původní sdílení souborů.  Příkaz PowerShell Set-SmbServerConfiguration lze použít k nastavení většiny parametrů, které by tým správy sdílení souborů uvedl ze svého řešení.<\/P>V každém případě, pokud nasměrujete svůj server(y) Esri na sdílení souborů Windows stroje a problémová charakteristika zmizí, vaše diagnóza vyloučením byla potvrzena. Odtud může tým řešení sdílení souborů rozhodnout, zda chtějí zkusit dosáhnout charakteristiky okamžité konzistence nebo naznačit, že takovou službu poskytovat nechtějí. Takže buď máte řešení, nebo odpověď. <\/P>Závěr<\/H1>Vyšetřování podezření na problém se sdílením souborů je jedním z nejnáročnějších úkolů při odstraňování problémů v oblasti správy ArcGIS Enterprise. Tento článek si neklade za cíl učinit vás, jednotlivého čtenáře, úspěšným samostatným praktikem v této oblasti; spíše je cílem poskytnout vám základní informace a proces. Pokud tento proces pečlivě provedete, můžete přizvat mnoho různých specialistů, kteří vám pomohou dosáhnout řešení. Kromě zapojení příslušných odborníků z vaší vlastní organizace můžete přizvat technickou podporu Esri a/nebo profesionální služby k účasti. Časem může vaše pečlivé provedení a kvalitní týmová spolupráce správně diagnostikovat problémy v této oblasti.<\/P>Příloha: Protokolové zprávy spojené s problémy se sdílením souborů<\/H1>Následující informace jsou částečným seznamem chybových kódů a zpráv, které mohou naznačovat problém se sdílením souborů ve vašem systému ArcGIS Enterprise.<\/P>Varovné a závažné protokolové zprávy<\/H2>Při výchozí úrovni protokolování obvykle následující kódy a zprávy indikují problém se sdílením souborů (v prostředí s více stroji). Často je užitečné podívat se na zprávy bezprostředně před a po nich. Při tom chcete použít pole stroj, proces a vlákno k rozpoznání souvisejících zpráv. Protože existuje mnoho strojů, procesů a vláken, bezprostředně sousední zprávy podle času mohou pocházet z jiného procesu.<\/P>Enterprise komponenta<\/P><\/TD>Úroveň<\/P><\/TD>Kód<\/P><\/TD>Zpráva<\/P><\/TD>Poznámky<\/P><\/TD><\/TR>Server<\/P><\/TD>VAROVÁNÍ<\/P><\/TD>7721<\/P><\/TD>1ezařilo se nepodařilo zapsat heartbeat<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>VAROVÁNÍ<\/P><\/TD>7712<\/P><\/TD>Došlo k chybě při synchronizaci s config store<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>ZÁVAŽNÉ<\/P><\/TD>6561<\/P><\/TD>Nepodařilo se vrátit všechny konfigurace složek<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>ZÁVAŽNÉ<\/P><\/TD>9000<\/P><\/TD>Interní chyba serveru: Služba <name> nenalezena<\/

MikeSchiewe

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