Solução de Problemas em Compartilhamentos de Arquivos e ArcGIS Enterprise

DannyKrouk_ps

Introdução

As arquiteturas do ArcGIS Enterprise frequentemente exigem o uso de compartilhamentos de arquivos para armazenamento de arquivos de configuração compartilhados, conteúdo ou backups (https://enterprise.arcgis.com/en/server/latest/install/windows/choosing-a-nas-device.htm). Isso é particularmente verdadeiro quando o padrão de implantação envolve sites com múltiplas máquinas (como as configurações de alta disponibilidade). Existem usos de compartilhamentos de arquivos em cada um dos principais componentes do ArcGIS Enterprise (Portal for ArcGIS, ArcGIS Server e ArcGIS Data Store).

No diagrama abaixo, o “Shared Content” e “Shared Config-store and Directories” estão localizados em um compartilhamento de arquivos:

 

Compartilhamentos de arquivos existem em muitos tipos e variedades, variando desde dispositivos físicos de hardware até sistemas de arquivos virtuais ou outros provedores. Sistemas de arquivos compartilhados fornecem uma maneira eficiente de compartilhar conteúdo entre múltiplos componentes, mas também podem introduzir desafios relacionados a desempenho, permissões ou consistência a nível de arquivo.

Quando há problemas em uma implantação do ArcGIS Enterprise, e você suspeita que eles possam estar relacionados ao armazenamento compartilhado, pode ser difícil saber como avaliar sua arquitetura para potenciais desafios e o que fazer a respeito. Na prática, resolver um problema com compartilhamento de arquivos pode ser desafiador, mas suas chances de sucesso são muito melhores se você estabelecer uma métrica ou medição específica para definir, criar uma linha base e testar o problema suspeito. Este artigo foi projetado para ajudá-lo a determinar se há um problema com o compartilhamento de arquivos em sua implantação do ArcGIS Enterprise, quais sintomas e indicadores podem apontar para esse tipo de problema (sua assinatura) e como investigar a causa raiz.

Embora princípios semelhantes se apliquem aos sistemas Linux/NFS e Windows/SMB, os detalhes deste artigo focam nos sistemas Windows/SMB.

Como o ArcGIS Enterprise usa um compartilhamento de arquivos?

Existem várias maneiras pelas quais o ArcGIS Enterprise usa um compartilhamento de arquivos, incluindo as seguintes:

1. Um repositório de dados registrado em um site do ArcGIS Server
2. Um local compartilhado para backups do ArcGIS Data Store
3. Um local para armazenamento e extração dos backups WebGISDR para fluxos de trabalho de recuperação de desastres
4. Um local para armazenar o “config-store” e os “server directories” de um site do ArcGIS Server com múltiplas máquinas
5. Um local para armazenar o “content directory” de um site portal do ArcGIS Enterprise altamente disponível

Os dois últimos são o foco deste artigo; nesses casos, o compartilhamento de arquivos desempenha um papel em como cada máquina no site com múltiplas máquinas sabe o que está acontecendo. Metaforicamente, o compartilhamento de arquivos atua como parte do “sistema nervoso” do portal do ArcGIS Enterprise ou site do ArcGIS Server quando está suportando o “config-store”, “server directories” ou “content directory”. Portanto, se houver um problema com o compartilhamento de arquivos, o site do ArcGIS Server ou Portal for ArcGIS pode exibir uma ampla variedade de sintomas intermitentes, como dificuldades ao publicar serviços ou “instabilidade” do servidor.

Reconhecendo e investigando um problema relacionado a um compartilhamento de arquivos

Analisar um potencial problema com compartilhamento de arquivos pode começar como um esforço solo, examinando os logs dos softwares para cada componente do software ArcGIS. No entanto, se você encontrar evidências que apontem para problemas relacionados ao acesso a arquivos, será necessário trabalhar com outras fontes de informação ou componentes do software. Isso provavelmente significará trabalhar com outras pessoas, pois os privilégios necessários e conhecimento raramente estão concentrados em uma única pessoa.

Este artigo descreve o que você pode buscar com diferentes conjuntos de privilégios e conhecimentos. Começamos pelos logs no ArcGIS Enterprise por duas razões: primeiro, assumimos que você tem esses privilégios — e segundo, é aqui que você faz a determinação inicial se há motivo para acreditar que existe um problema com compartilhamento de arquivos e qual é esse motivo.

Fundamentos

Antes de começar, você quer se preparar para ser o mais produtivo possível escolhendo um ambiente apropriado, controlando a complexidade e reunindo a equipe certa.

Ambientes

Você deve tentar usar “ambientes inferiores” (ou seja, não seu ambiente de produção) se puder observar os problemas nesses sistemas. Qualquer problema que você veja na produção, use os logs do ArcGIS Server para entender sua assinatura. Encontrar essa assinatura é discutido abaixo. Então, procure no seu ambiente staging, teste ou UAT para ver se consegue encontrar a mesma assinatura. Note que talvez seja necessário gerar alguma atividade nesse ambiente para ver o problema (muitos problemas não aparecem quando o sistema está inativo).

Se você conseguir ver o problema no ambiente inferior, esse é o ambiente onde deve investigar. Como você tem mais controle sobre o nível da atividade nesse ambiente, será menos distraído por fatores não relacionados. E porque é mais prático saber o que está acontecendo, você pode formar melhores ideias sobre causas potenciais. Finalmente, quando se trata de fazer mudanças para solução de problemas, você deve sempre fazê-las primeiro em ambientes inferiores quando possível para evitar interrupções desnecessárias aos usuários.

Complexidade

Você quer reduzir ao máximo a complexidade sem alterar sua configuração básica. Trabalhar em um ambiente inferior ajuda a reduzir a complexidade. Mas quando você trabalha com sites com múltiplas máquinas, as múltiplas máquinas significam que você tem vários lugares para procurar qualquer problema dado. 

Uma prática frequentemente eficaz é desligar as máquinas redundantes no site. Por exemplo, se houver três máquinas em um site do ArcGIS Server, desligue (o SO) ou pare (no site) duas máquinas. A máquina restante ainda estará usando o compartilhamento de arquivos para os mesmos propósitos e muitos problemas continuarão a se manifestar. Se desligar as máquinas redundantes fizer o problema desaparecer, isso é uma pista importante sobre a natureza do problema. Especificamente, indica que o problema tem a ver com acesso concorrente dos clientes e talvez não com a rede.

Envolver outros

Ao solucionar problemas que abrangem múltiplos ambientes, você pode encontrar problemas que excedem seus privilégios ou experiência. Embora privilégios possam ser concedidos temporariamente, experiência nessas áreas é igualmente valiosa. Montar uma equipe dedicada à resolução dos problemas garantirá que você tenha recursos disponíveis preventivamente quando surgirem dúvidas.

Uma fonte frequente de disfunção nesse tipo de esforço em equipe virtual é fazer todos entenderem como podem contribuir significativamente. Administradores de rede e administradores do compartilhamento geralmente sabem pouco sobre software Esri e provavelmente não têm incentivo para aprender muito sobre as aplicações na infraestrutura deles. No entanto, eles geralmente têm mentes curiosas e gostam de resolver problemas. Se você apresentar uma pergunta aberta (“A rede está tendo problemas?”) ou uma acusação prematuramente ampla (“A rede está causando nossos problemas”), provavelmente não obterá respostas interessantes. Por outro lado, se fizer perguntas específicas baseadas em evidências suas chances de resposta produtiva aumentam. Por exemplo: “Vemos mensagens ‘connection time out’ nos logs da aplicação nos horários X, Y e Z. Parece acontecer a cada 2 a 3 horas. Você poderia capturar tráfego nesse período e nos ajudar a entender o que está acontecendo com as conexões?”

Hipóteses baseadas em evidências e investigação

Quer esteja tentando ser eficaz sozinho ou como parte da equipe virtual, uma abordagem baseada em evidências é o padrão ouro para avançar. Alguns pilares dessa abordagem baseada em evidências são os seguintes:

1. Faça suas observações iniciais antes de fazer qualquer alteração no sistema e estabeleça que essas observações são consistentes.
2. Comece com observações específicas sobre determinado fluxo de trabalho, requisição ou operação.
3. Encontre repetição ou repetibilidade. Você não quer perseguir casos isolados ou falsos alarmes.
4. Documente conforme avança. Você quer poder voltar e confirmar detalhes das suas observações e compartilhar suas observações com outros.
5. Crie mais de uma hipótese para cada problema. Sua primeira ideia raramente é a resposta; crie várias hipóteses e persiga-as uma por vez.
6. Identifique as evidências que poderiam invalidar (ou apoiar) uma hipótese e então busque essas evidências.
7. Aproveite a expertise dos outros. Uma das melhores formas para obter participação de um especialista é pedir que ele demonstre sua expertise explicando os possíveis significados de uma observação específica. É uma vitória dupla: você avança seu entendimento e torna mais provável que ele queira ajudar futuramente.

O que você pode aprender como administrador do ArcGIS Enterprise: A assinatura

Os logs no ArcGIS Enterprise (logs do portal ArcGIS Enterprise e logs do ArcGIS Server) são onde você identifica sua assinatura do problema. É a medição que usará para determinar se está enfrentando um problema com compartilhamento de arquivos e se uma mudança feita realmente resolvido.<\/P>

Quando um componente do ArcGIS Enterprise talks para um compartilhamento de arquivos, ele est lendo e escrevendo objetos de arquivo, frequentemente referidos como Entrada\/Sada ou I\/O. E, est fazendo isso como uma conta especfica (a conta de servio<\/A>), ento voc pode ter problemas de permisses e problemas no sistema de arquivos. <\/P>

Problemas de permisses so geralmente bastante reconhecveis nas mensagens de log e relativamente fceis de resolver. Por exemplo, a mensagem de log No poss
o escrever no caminho do diretrio ''{0}''. Por favor, verifique se o local vlido e se a conta do ArcGIS Server tem permisses para o local. (cdigo 6697) descreve a causa e fornece uma ideia para a soluo. Observe que as permisses efetivas envolvero tanto aquelas para o prprio compartilhamento quanto para os arquivos e diretrios expostos atravs do compartilhamento.<\/P>

Permisses do Compartilhamento<\/P><\/TD>

Permisses de Arquivo e Diretrio<\/P><\/TD><\/TR>

<\/span> <\/P><\/TD><\/span> <\/P><\/TD><\/TR><\/TBODY><\/TABLE> <\/P>Mensagens de log que mencionam um caminho relacionado ao compartilhamento de arquivos, I\/O ou uma IOException provavelmente significam que permisses no so o problema. No final deste artigo, h um apndice com uma lista parcial de cdigos de log e tipos de mensagens que esto correlacionados com problemas de compartilhamento de arquivos. A correlaao fundamental para estabelecer a causa. Se voce vir mensagens como estas, e uma boa indicaao que voce precisa olhar mais atentamente para o compartilhamento de arquivos e\ou o caminho da rede ate ele, embora no seja uma prova irrefutavel de que o compartilhamento de arquivos seja o culpado.  <\/P>Os detalhes dos tipos de mensagens do log podem obscurecer os padres em alto nvel que voce esta procurando. Um compartilhamento de arquivos e um sistema de arquivos do outro lado da rede, ento se houver um problema, podem haver pelo menos dois tipos de fontes: a prpria soluao do compartilhamento ou a rede. A seguir estao exemplos de mensagens que indicam um problema ao acessar arquivos a partir de um compartilhamento (algumas informaoes removidas para clareza ou privacidade):<\/P>Componente Enterprise<\/P><\/TD>Nivel<\/P><\/TD>Código<\/P><\/TD>Mensagem<\/P><\/TD>Notas<\/P><\/TD><\/TR>Servidor<\/P><\/TD>AVISO<\/P><\/TD>7721<\/P><\/TD>falha ao escrever heartbeat<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>AVISO<\/P><\/TD>7712<\/P><\/TD>Um erro foi encontrado enquanto sincronizava com o config store<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>GRAVE<\/P><\/TD>6561<\/P><\/TD>Falha ao retornar todas as configuraoes da pasta<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>GRAVE<\/P><\/TD>9000<\/P><\/TD>Erro Interno do Servidor: Servio <nome> n ilizado encontrado<\/P><\/TD >< TD width = "275" >< P > Observe que uma solicitaao para um servio que atualmente n ilizado existe tambem gerar uma mensagem como esta. Para isso indicar um problema com um compartilhamento, o servio deve realmente existir no site.< \/ P >< \/ TD >< \/ TR >< TR >< TD width = "86" >< P > Servidor < \/ P >< \/ TD >< TD width = "90" >< P > GRAVE < \/ P >< \/ TD >< TD width = "77" >< P > 6605 < \/ P >< \/ TD >< TD width = "186" >< P > Falha ao retornar todas as configuraoes dos servios na pasta ... (O sistema n ilizado encontra o arquivo especificado) < \/ P >< \/ TD >< TD width = "275" >< P > & nbsp ; < \/ P >< \/ TD >< \/ TR >< TR >< TD width = "86" >< P > Servidor < \/ P >< \/ TD >< TD width = "90" >< P > GRAVE < \/ P >< \/ TD >< TD width = "77" >< P > 6652 < \/ P >< \/ TD >< TD width = "186" >< P > N ilizado poss ilizado ler o servi ilizado ... da loja de configura ilizado ... (O sistema n ilizado encontra o arquivo especificado) < \/ P >< \/ TD >< TD width = "275" >< P > & nbsp ; < \/ P >< \/ TD >< \/ TR >< TR >< TD width = "86" >< P > Servidor < \/ P >< \/ TD >< TD width = "90" >< P > GRAVE < \/ P >< \/ TD >< TD width = "77" >< P > 6566 < \/ P >< \/ TD >< TD width = "186" >< P > Falha ao recuperar o status do servi ilizado ... (O sistema n ilizado encontra o arquivo especificado) < \/ P >< \/ TD >< TD width = "275" >< P > & nbsp ; < \/ P >< \/ TD >< \/ TR >< TR >< TD width = "86" >< P > Servidor < \/ P >< \/ TD >< TD width = "90" >< P > GRAVE < \/ P >< \/ TD >< TD width = "77" >< P > 9015 < \/ P >< \/ TD >< TD width = "186" >< P > Erro ao obter lista de servi ilizados. ... (O sistema n ilizado encontra o arquivo especificado) < \ / p > < \ / td > < td largura = ou Erro. Você deve filtrar com base nesses níveis de evento e tempo.<\/P>O que esses logs podem lhe dizer? <\/P>O computador local detecta um problema?Se você não encontrar erros tematicamente relacionados nos logs principais do Windows para os carimbos de data/hora dos seus logs do servidor Esri, então você tem alguma evidência de que o problema não é devido a um problema específico da máquina cliente. Embora isso possa não ser evidência suficiente para descartar completamente a possibilidade, você deu passos importantes em direção a esse objetivo, e pode priorizar seus esforços em outro lugar.<\/LI>Se você encontrar erros interessantes na máquina local, você prioriza seus esforços em entender e tentar resolver esses. <\/LI><\/OL><\/LI>O protocolo SMB detecta um problema?Se você não encontrar erros nos logs do SMBClient que correspondam aos carimbos de data/hora, pode inferir que o problema não é um erro no que diz respeito ao protocolo SMB. Por exemplo, se você está investigando mensagens que indicam que um arquivo não pode ser encontrado, o protocolo SMB não vai classificar isso como um erro — Para tudo que ele sabe, esse arquivo não existe. Nesse caso, o protocolo funcionou corretamente e retornou uma informação correta. <\/LI>Por outro lado, se você vir um erro como o mostrado acima, faz sentido focar a investigação no próprio protocolo SMB.<\/LI><\/OL><\/LI><\/OL>Encontrar erros tematicamente relacionados nesses logs é frequentemente muito significativo para outros especialistas que não estão familiarizados com o logging Esri mas têm mais probabilidade de entender ou confiar no logging do sistema operacional.<\/P>

O que você pode aprender com outros especialistas<\/H2>Muitos problemas de compartilhamento de arquivos não aparecem nos logs do Visualizador de Eventos do sistema operacional cliente. A maioria das outras fontes de informação requer privilégios elevados (além da administração do servidor Esri ou da máquina local), conhecimento especializado ou ambos. Portanto, para fazer progresso nessa área, você deve empregar dois atributos importantes: (a) sua personalidade vencedora e (b) seu compromisso com a investigação baseada em evidências.<\/P>Pessoas de rede<\/H3>Se você tem as assinaturas do log da aplicação Esri que sugerem um problema ou falha relacionada à rede, você vai querer investigar nessa área.<\/P>A maioria dos problemas de rede relacionados a compartilhamento de arquivos não se expressa claramente em soluções clássicas de monitoramento ou logging de rede. O monitoramento de rede geralmente foca em capacidade, throughput e qualidade de serviço. Isso é útil para planejamento e administração geral da rede, mas nem sempre ajuda na solução de problemas específicos de conexões. O log de negações de um firewall vale a pena consultar, mas normalmente não é onde se encontram as causas dos problemas de compartilhamento de arquivos.<\/P>As respostas são tipicamente encontradas capturando o tráfego da rede durante um curto período quando o problema ocorre ou é acionado manualmente. Capturar um problema intermitente não é tão difícil quanto parece. Pode-se configurar uma captura em buffer circular para manter uma coleção estável de arquivos, sobrescrevendo-os conforme o tempo passa. A equipe de rede da sua organização, além de ter as ferramentas e privilégios, provavelmente sabe como fazer isso. Portanto, você não precisa saber exatamente quando o problema ocorrerá novamente. <\/P>Em muitos casos, um buffer circular pode persistir dados de captura de rede por muitas horas em base contínua. Quando o problema ocorrer novamente, peça à equipe de rede para parar a captura. Então, use os carimbos de data/hora dos logs do servidor Esri para investigar as informações da captura da rede. Com algum conhecimento sólido básico sobre redes (da equipe de rede ou seu) e dedicação, muito pode ser aprendido. Mesmo se sua equipe não tiver muito conhecimento em análise de redes, você pode procurar anomalias. Ou existem características anormais na rede nos carimbos em questão ou não existem. Se houver algo anormal ou suspeito, especialistas adicionais podem ser chamados conforme necessário. A especificidade provavelmente será atraente para esses especialistas.<\/P>Pessoas do compartilhamento de arquivos<\/H3>Se as assinaturas dos logs do servidor Esri não sugerirem um problema na rede, você vai querer investigar essa área. Soluções de compartilhamento de arquivos, como a maioria dos sistemas TI, normalmente têm logs. Uma revisão desses logs nos horários em questão é apropriada. Se houver erros tematicamente relacionados para os carimbos em questão, você tem uma causa provável para investigar mais a fundo. E você tem sua equipe administrativa do compartilhamento de arquivos (e a organização de suporte do fornecedor deles) para liderar o caminho.<\/P>Também é possível que os logs do compartilhamento de arquivos não tenham erros relacionados. Se as evidências acumuladas descartaram outras fontes prováveis e os logs do compartilhamento não indicam problema, há uma possibilidade restante. É possível que o compartilhamento e o software Esri classifiquem problemas diferentemente. Por exemplo, se um compartilhamento for projetado ou configurado para fornecer consistência eventual, ele não registrará erros sobre isso. Mas sabemos que ArcGIS Server espera consistência imediata. Então, o compartilhamento vê nenhum erro, mas ArcGIS Server não está recebendo o que precisa.<\/P>Vamos explorar essa ideia um pouco mais, pois ela aparece usando o exemplo de um site ArcGIS Server com duas máquinas com a loja de configuração e diretórios do servidor armazenados em um compartilhamento. Se a máquina A grava em um arquivo, a máquina B do site ArcGIS Server deveria poder ler essa nova informação imediatamente. Isso é consistência imediata: leitura após gravação para qualquer cliente no compartilhamento. Então, se ArcGIS Server está dizendo: "Ei, eu não consigo encontrar esse arquivo" ou "Esse arquivo parece diferente do que eu pensava", e o compartilhamento está dizendo: "Eu não sei de nenhum problema", qual é sua hipótese resultante? Tendo descartado outras causas prováveis, sua hipótese resultante é que o compartilhamento não está fornecendo consistência "leitura após gravação". Nenhuma outra ideia se encaixa tão bem nos dados.<\/P>O que fazer com isso? Esta é outra investigação com a equipe administrativa do compartilhamento. Mas ao invés de focar em um erro nos seus logs, busca-se entender como múltiplos clientes olhando para o mesmo arquivo ao mesmo tempo veem-no exatamente no mesmo estado sempre. Nenhum cliente pode ver o estado anterior como válido depois que o arquivo foi alterado por outro cliente. E nenhum cliente pode alterar um arquivo quando outro cliente tem bloqueio exclusivo nele. Ih-oh. Dissemos a "palavra com L" (lock). Isso traz à tona mais um termo ou conceito que talvez você tenha ouvido antes: bloqueio oportunista dos arquivos, também chamado Oplocks.<\/P>O problema são os Oplocks?<\/H4>Embora seja certamente possível que Oplocks estejam causando um problema no seu sistema, para os problemas aqui discutidos as chances são contra isso. Mas como tomada de decisão baseada em evidências é a forma correta para avançar, você pode usar evidências para provar se é uma causa.<\/P>Vale pensar no que são Oplocks e suas alternativas. Oplocks são bloqueios oportunistas. O cliente (o sistema Esri) assume otimisticamente que os arquivos conhecidos no compartilhamento estão inalterados e/ou seguros para alteração a menos que receba comunicação do servidor (o compartilhamento). O oposto do bloqueio oportunista é bloqueio pessimista (não bloquear não é opção). Nesse caso, o cliente assume pessimisticamente que outros clientes podem estar usando os arquivos conhecidos no compartilhamento e verifica antes de fazer qualquer coisa. Bloqueios oportunistas são uma ótima estratégia quando a maioria dos arquivos não está sendo acessada por mais de um cliente ao mesmo tempo. Bloqueios pessimistas são melhores quando arquivos são frequentemente acessados por múltiplos clientes simultaneamente. O que sabemos sobre sites ArcGIS Server ou Portal for ArcGIS com múltiplas máquinas? Existem pelo menos dois clientes acessando os mesmos arquivos ao mesmo tempo.<\/P>Portanto, Oplocks são subótimos para casos de uso do servidor Esri. Mas será essa a causa do seu problema? Você não sabe ainda. Como você tem sua assinatura do problema nos logs Esri, pode alterar as configurações dos Oplocks e ver se muda a assinatura do problema (a presença da mensagem e sua frequência dado a mesma carga). Esses parâmetros podem ser alterados no sistema operacional cliente (nas máquinas onde roda o software Esri) ou na solução do compartilhamento dependendo da configuração.<\/P>Aqui está como fazer se você for administrador local da máquina cliente OS. Abra uma janela PowerShell como "Administrador" e observe as configurações atuais:<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Então você pode alterá-las. Os comandos seguintes desabilitarão todo cache no lado cliente<\/A> (incluindo 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>Você pode então inspecionar essas configurações com este comando:<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Note que as mudanças terão efeito na próxima vez que o cliente estabelecer uma nova conexão com o compartilhamento. Reiniciar o software servidor Esri faria isso acontecer imediatamente.<\/P>Depois de alterar suas configurações, volte aos logs Esri para ver se a assinatura — as informações da mensagem de erro e frequência para a mesma carga — foi resolvida. Se sim, comemore! Se não for assim, então o quê?<\/P>

O problema é algo outro? <\/H4>Sim—se você chegou a este ponto, o problema é outro.<\/P>Você refutou todas as hipóteses razoáveis até agora. Você fica com um diagnóstico por exclusão. Esse diagnóstico é que a solução de compartilhamento de arquivos (seja por design ou não) não está fornecendo consistência imediata. <\/P>Nessa circunstância, pode ser útil ter evidências corroborativas. Uma maneira muito boa de fazer isso é comparar com uma solução diferente de compartilhamento de arquivos. Embora um compartilhamento de arquivos de uma máquina virtual Windows possa não ser uma solução que você ou sua organização desejem adotar permanentemente, pode ser muito útil para uma investigação. A Esri não possui evidências empíricas de compartilhamentos de arquivos de uma única máquina Windows produzindo problemas de consistência imediata. Não há uma base teórica forte para isso. E, se você desativar Oplocks conforme descrito acima, você também neutraliza as bases teóricas fracas. O compartilhamento de arquivos da máquina Windows precisaria ser configurado com os mesmos parâmetros SMB do compartilhamento de arquivos original.  O comando Set-SmbServerConfiguration do PowerShell pode ser usado para corresponder à maioria dos parâmetros que a equipe de administração do compartilhamento de arquivos indicaria em sua solução.<\/P>De qualquer forma, se você apontar seu(s) servidor(es) Esri para o compartilhamento de arquivos da máquina Windows e a assinatura do problema desaparecer, seu diagnóstico por exclusão foi corroborado. A partir daí, a equipe da solução de compartilhamento de arquivos pode decidir se deseja tentar corresponder à característica de consistência imediata ou indicar que não deseja fornecer tal serviço. Assim, você tem uma solução ou uma resposta. <\/P>Em conclusão<\/H1>Investigar um problema suspeito de compartilhamento de arquivos é um dos empreendimentos mais desafiadores na resolução de problemas no espaço da administração do ArcGIS Enterprise. Este artigo não pretende torná-lo, leitor individual, um praticante solo bem-sucedido nesse espaço; ao contrário, o objetivo é fornecer algumas informações fundamentais e um processo. Se você executar cuidadosamente esse processo, poderá envolver muitos especialistas diferentes para ajudá-lo a alcançar a solução. Além de envolver os especialistas do domínio relacionado da sua própria organização, você pode trazer o Suporte Técnico da Esri e/ou Serviços Profissionais para participar. Com o tempo, sua execução cuidadosa e a participação qualificada da equipe podem diagnosticar corretamente problemas nesse espaço.<\/P>Apêndice: Mensagens de log correlacionadas com problemas de compartilhamento de arquivos<\/H1>A informação abaixo é uma lista parcial de códigos e mensagens de erro que podem indicar um problema de compartilhamento de arquivos no seu sistema ArcGIS Enterprise.<\/P>Mensagens de aviso e severas<\/H2>No nível padrão de log, os seguintes códigos e mensagens geralmente indicam um problema com um compartilhamento de arquivos (em um site com múltiplas máquinas). Muitas vezes é útil olhar as mensagens imediatamente antes e depois. Quando fizer isso, você deve usar os campos máquina, processo e thread para reconhecer mensagens relacionadas. Como há muitas máquinas, processos e threads, as mensagens vizinhas imediatas, por tempo, podem ser de algum outro processo.<\/P>Componente Enterprise<\/P><\/TD>Nível<\/P><\/TD>Código<\/P><\/TD>Mensagem<\/P><\/TD>Notas<\/P><\/TD><\/TR>Servidor<\/P><\/TD>AVISO<\/P><\/TD>7721<\/P><\/TD>"falha ao escrever heartbeat"<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>AVISO<\/P><\/TD>7712<\/P><\/TD>"Um erro foi encontrado ao sincronizar com o config store"<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>SEVERO<\/P><\/TD>6561<\/P><\/TD>"Falha ao retornar todas as configurações da pasta"<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>SEVERO<\/P><\/TD>9000<\/P><\/TD>"Erro Interno do Servidor: "Serviço <name> não encontrado"<\/P><\/TD>Observe que uma solicitação para um serviço que atualmente não existe também gerará uma mensagem como esta. Para que isso indique um problema com um compartilhamento de arquivos, o serviço deve realmente existir no site.<\/P><\/TD><\/TR>Servidor<\/P><\/TD>SEVERO<\/P><\/TD>6605<\/P><\/TD>"Falha ao retornar todas as configurações dos serviços na pasta (O sistema não pode encontrar o arquivo especificado)"<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>SEVERO<\/P><\/TD>6652<\/P>
\u201cIncapaz de ler o servi\u00e7o \u2026 da loja de configura\u00e7\u00e3o \u2026 (O sistema n\u00e3o pode encontrar o arquivo especificado)\u201d
 


Servidor
SEVERO
6566
\u201cFalha ao recuperar o status do servi\u00e7o \u2026 (O sistema n\u00e3o pode encontrar o arquivo especificado)\u201d
 


Servidor
SEVERO
9015
\u201cErro ao obter lista dos servi\u00e7os. \u2026 (O sistema n\u00e3o pode encontrar o arquivo especificado)\u201d
 


Servidor
SEVERO
6615
\u201cIncapaz de recuperar informações do recurso 'Permissões'. \u2026
Esta mensagem não é exclusiva para problemas com compartilhamento de arquivos, mas pode estar associada a eles.


Pórtal Enterprise
SEVERO
218037
The Portal site has been initialized and configured but is currently not accessible because the content directory is not available




 
Como deve ser evidente nesta tabela, a maioria das mensagens menciona algo sobre um arquivo ou diretório que não pode ser encontrado.
Nível DEBUG
No nível DEBUG do registro, há mais mensagens disponíveis que podem fornecer mais evidência. Portanto, se você estiver procurando por um possível problema no compartilhamento de arquivos, pode ser útil ativar o nível DEBUG por um período. Essas mensagens em nível debug seriam principalmente úteis para apoiar (ou não) hipóteses formadas a partir de outros níveis ou fontes e adicionar detalhes potencialmente relevantes. Por si sós, elas não seriam uma indicação acionável de problema no compartilhamento; existem outras interpretações plausíveis.

SITE_IN_USE=Sito ArcGIS Server est50 sendo configurado por outra opera5750 administrativa. Por favor tente novamente mais tarde. - (6850)
MACHINE_BEING_CONFIGURED=A m51quina servidor ''{0}'' est50 sendo configurada por outra opera5750 administrativa. Por favor tente novamente mais tarde. - (6851)
CONFIG_STORE_BEING_ACCESSED=Outra opera5750 administrativa est50 acessando a loja. Por favor tente novamente mais tarde. - (6852)
CLUSTER_BEING_CONFIGURED=Agrupamento ''{0}'' est50 sendo configurado por outra opera5750 administrativa. Por favor tente novamente mais tarde. - (6853)
CLUSTER_MACHINE_BEING_CONFIGURED=Agrupamento ''{0}'' - M51quina ''{1}'' est50 sendo configurada por outra opera5750 administrativa. Por favor tente novamente mais tarde. - (7506)
CLUSTER_RESOURCE_BEING_CONFIGURED=Recurso do agrupamento ''{0}'' est50 sendo configurado por outra opera5750 administrativa. Por favor tente novamente mais tarde. - (7507)
METRIC_BEING_CONFIGURED=Metrica ''{0}'' est50 sendo configurada por outra opera5750 administrativa. Por favor tente novamente mais tarde. - (6614)
SERVICE_BEING_CONFIGURED=Servi57o ''{0}''.''{1}'' na pasta ''{2}'' est50 sendo configurado por outra opera5750 administrativa. Por favor tente novamente mais tarde. - (6854)
SERVICE_CONFIG_BEING_WRITTEN=Outra opera5750 administrativa est50 escrevendo a configura5750 do servi57o. Por favor tente novamente mais tarde. - (6859)
FOLDER_IN_USE=pasta ''{0}'' est50 sendo usada por outra opera5750 administrativa. Por favor tente novamente mais tarde. - (6877)

Algumas dessas mensagens também podem aparecer no código DEBUG 9999. 

MikeSchiewe

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