Solución de problemas de File Shares y ArcGIS Enterprise

DannyKrouk_ps

Introducción

Las arquitecturas de ArcGIS Enterprise a menudo requieren el uso de recursos compartidos de archivos para el almacenamiento de archivos de configuración compartidos, contenido o copias de seguridad (https://enterprise.arcgis.com/en/server/latest/install/windows/choosing-a-nas-device.htm). Esto es particularmente cierto cuando el patrón de implementación involucra sitios con múltiples máquinas (como las configuraciones de alta disponibilidad). Hay usos de recursos compartidos de archivos en cada uno de los principales componentes de ArcGIS Enterprise (Portal for ArcGIS, ArcGIS Server y ArcGIS Data Store).

En el diagrama a continuación, el "Shared Content" y "Shared Config-store and Directories" están ubicados en un recurso compartido de archivos:

 

Los recursos compartidos de archivos vienen en muchos tipos y variedades, que van desde dispositivos físicos de hardware hasta sistemas de archivos virtuales u otros proveedores. Los sistemas de archivos compartidos proporcionan una forma eficiente de compartir contenido entre múltiples componentes, pero también pueden introducir desafíos relacionados con el rendimiento, permisos o consistencia a nivel de archivo.

Cuando hay problemas en una implementación de ArcGIS Enterprise, y sospecha que pueden estar relacionados con el almacenamiento compartido, puede ser difícil saber cómo evaluar su arquitectura para posibles desafíos y qué hacer al respecto. En la práctica, resolver un problema con un recurso compartido de archivos puede ser desafiante, pero sus posibilidades de éxito son mucho mejores si establece una métrica o medida específica para definir, crear una línea base y probar el problema sospechado. Este artículo está diseñado para ayudarle a determinar si hay un problema con un recurso compartido de archivos en su implementación de ArcGIS Enterprise, qué síntomas e indicadores podrían señalar este tipo de problema (su firma) y cómo investigar la causa raíz.

Si bien principios similares se aplican a sistemas Linux/NFS y Windows/SMB, los detalles de este artículo se centran en sistemas Windows/SMB.

¿Cómo usa ArcGIS Enterprise un recurso compartido de archivos?

Hay varias formas en que ArcGIS Enterprise usa un recurso compartido de archivos, incluyendo las siguientes:

1. Un repositorio de datos registrado en un sitio ArcGIS Server
2. Una ubicación compartida para copias de seguridad de ArcGIS Data Store
3. Una ubicación para almacenamiento y extracción de copias WebGISDR para flujos de trabajo de recuperación ante desastres
4. Una ubicación para almacenar el "config-store" y los "server directories" de un sitio ArcGIS Server con múltiples máquinas
5. Una ubicación para almacenar el "content directory" de un sitio portal altamente disponible de ArcGIS Enterprise

Los dos últimos son el foco de este artículo; en estos casos, el recurso compartido de archivos juega un papel en cómo cada máquina en el sitio múltiple sabe lo que está sucediendo. Metafóricamente, el recurso compartido actúa como parte del "sistema nervioso" del portal ArcGIS Enterprise o del sitio ArcGIS Server cuando está soportando el "config-store", los "server directories" o el "content directory". Por lo tanto, si hay un problema con el recurso compartido, el sitio ArcGIS Server o Portal for ArcGIS puede mostrar una amplia variedad de síntomas intermitentes, como problemas al publicar servicios o "instabilidad" del servidor.

Reconocer e investigar un problema relacionado con un recurso compartido

Analizar un posible problema con un recurso compartido puede comenzar como un esfuerzo individual, examinando los registros del software para cada componente del software ArcGIS. Sin embargo, si encuentra evidencia allí que apunta a problemas relacionados con el acceso a archivos, necesitará trabajar con otras fuentes de información o componentes del software. Esto probablemente significará trabajar con otras personas, ya que los privilegios y conocimientos requeridos rara vez están concentrados en una sola persona.

Este artículo describe lo que puede perseguir con diferentes conjuntos de privilegios y conocimientos. Comenzamos con los registros en ArcGIS Enterprise por dos razones: primero, asumimos que tiene esos privilegios—y segundo, aquí es donde hace la determinación inicial sobre si hay razón para creer que hay un problema con un recurso compartido y cuál es esa razón.

Fundamentos

Antes de comenzar, desea prepararse para ser lo más productivo posible eligiendo un entorno apropiado, controlando la complejidad y reuniendo al equipo adecuado.

Entornos

Debe intentar hacer uso de "entornos inferiores" (en otras palabras, no su entorno productivo) si puede observar los problemas en esos sistemas. Cualquier problema que vea en producción, use los registros del ArcGIS Server para entender su firma. Encontrar esa firma se discute a continuación. Luego, busque en su entorno staging, testing o UAT para ver si puede encontrar la misma firma. Tenga en cuenta que puede tener que generar alguna actividad en ese entorno para ver el problema (muchos problemas no se presentan cuando el sistema está inactivo).

Si puede ver el problema en el entorno inferior, ese es el entorno en el que debe investigar. Dado que tiene más control sobre el nivel de actividad en ese entorno, estará menos distraído por factores no relacionados. Y porque es más práctico saber qué está sucediendo, puede formar mejores ideas sobre causas potenciales. Finalmente, cuando se trata de hacer cambios para la solución de problemas, siempre debe hacerlos primero en entornos inferiores cuando sea posible para evitar interrupciones innecesarias a los usuarios.

Complejidad

Desea reducir tanta complejidad como sea posible sin cambiar su configuración básica. Trabajar en un entorno inferior ayuda a reducir la complejidad. Pero cuando trabaja con sitios múltiples máquinas, las múltiples máquinas significan que tiene múltiples lugares para buscar cualquier problema dado. 

Una práctica frecuentemente efectiva es apagar las máquinas redundantes en el sitio. Por ejemplo, si hay tres máquinas en un sitio ArcGIS Server, apague (el SO) o detenga (en el sitio) dos máquinas. La máquina restante sigue usando el recurso compartido para los mismos propósitos y muchos problemas continuarán manifestándose. Si apagar las máquinas redundantes hace que desaparezca el problema, esta es una pista importante sobre la naturaleza del problema. Específicamente, le dice que el problema tiene que ver con acceso concurrente del cliente y quizás no con la red.

Involucrar a otros

Cuando soluciona problemas que abarcan múltiples entornos, puede encontrarse con problemas que exceden sus privilegios o experiencia. Mientras los privilegios pueden otorgarse temporalmente, la experiencia en esos dominios es igual de valiosa. Prepararse con un equipo dedicado a resolver problemas asegurará que tenga recursos disponibles preventivamente cuando surjan preguntas.

Una fuente frecuente de disfunción en este tipo de esfuerzo virtual en equipo es lograr que todos entiendan cómo pueden hacer una contribución significativa. Los administradores de red y administradores del recurso compartido típicamente saben poco sobre software Esri y probablemente no estén incentivados a aprender mucho sobre las aplicaciones en su infraestructura. Sin embargo, típicamente tienen mentes curiosas y les gusta resolver problemas. Si les presenta una pregunta abierta (“¿La red está teniendo problemas?”) o una acusación prematuramente amplia (“La red nos está causando problemas”), es poco probable obtener respuestas interesantes. Por otro lado, si hace preguntas específicas basadas en evidencia, sus probabilidades de una respuesta productiva aumentan. Por ejemplo: “Vemos mensajes ‘connection time out’ en nuestros registros de aplicación en los tiempos X, Y y Z. Parece estar ocurriendo cada 2 a 3 horas. ¿Podría capturar tráfico durante ese período y ayudarnos a entender qué está pasando con las conexiones?”

Hipótesis e investigación basadas en evidencia

Tanto si intenta ser efectivo por su cuenta como parte de un equipo virtual, un enfoque basado en evidencia es el estándar oro para avanzar. Algunas piedras angulares del enfoque basado en evidencia son las siguientes:

1. Realice sus observaciones iniciales antes de hacer cualquier cambio al sistema y establezca que estas observaciones son consistentes.
2. Comience con observaciones específicas sobre cierto flujo de trabajo, solicitud u operación.
3. Encuentre repetición o repetibilidad. No quiere perseguir valores atípicos o falsas alarmas.
4. Documente mientras avanza. Querrá poder regresar y confirmar detalles de sus observaciones y compartirlas con otros.
5. Cree más de una causa hipotetizada para cada problema. Su primera idea rara vez es la respuesta; cree varias y persíguelas una a la vez.
6. Identifique la evidencia que podría invalidar (o apoyar) una hipótesis y luego persiga esa evidencia.
7. Aproveche la experiencia ajena. Una de las mejores maneras para obtener participación experta es pedirles mostrar su experiencia explicando posibles significados de una observación específica. Es una doble ganancia: avanza su comprensión y hace más probable que quieran ayudarle adelante.

Lo que puede aprender como administrador de ArcGIS Enterprise: La firma

Los registros en ArcGIS Enterprise (registros del portal ArcGIS Enterprise y registros del ArcGIS Server) son donde identifica la firma del problema. Es la medida que usará para determinar si tiene un problema con un recurso compartido y si un cambio que haga realmente resuelto.<\/P>

Cuando un componente de ArcGIS Enterprise talks a un recurso compartido de archivos, este1 leyendo y escribiendo objetos de archivo, a menudo denominados Entrada\/Salida o I\/O. Y lo hace como una cuenta especedfica (la cuenta de servicio<\/A>), por lo que pueden surgir problemas de permisos y problemas del sistema de archivos. <\/P>

Los problemas de permisos suelen ser bastante reconocibles en los mensajes del registro y relativamente fe1ciles de abordar. Por ejemplo, el mensaje del registro No se puede escribir en la ruta del directorio ''{0}''. Por favor, verifique que la ubicacif3n sea ve1lida y que la cuenta de ArcGIS Server tenga permisos para la ubicacif3n. (cf3digo 6697) describe la causa y proporciona una idea para la solucif3n. Tenga en cuenta que los permisos efectivos involucrare1n tanto los del recurso compartido en sed como los archivos y directorios expuestos a trave9s del recurso compartido.<\/P>

Permisos del recurso compartido<\/P><\/TD>

Permisos de archivos y directorios<\/P><\/TD><\/TR>

<\/span> <\/P><\/TD><\/span> <\/P><\/TD><\/TR><\/TBODY><\/TABLE> <\/P>Los mensajes del registro que mencionan una ruta relacionada con el recurso compartido de archivos, I\/O o una IOException probablemente signifiquen que los permisos no son el problema. Al final de este artedculo, hay un ape9ndice con una lista parcial de cf3digos de registro y tipos de mensajes que este1n correlacionados con problemas del recurso compartido de archivos. La correlacif3n es fundamental para establecer la causalidad. Si ve mensajes como estos, es una buena indicacif3n de que debe examinar me1s detenidamente el recurso compartido de archivos y\u002For la veda de red hacia 9l, aunque no es una prueba irrefutable de que el recurso compartido sea el culpable.  <\/P>Los detalles de los tipos de mensajes del registro pueden oscurecer los patrones generales que este1 buscando. Un recurso compartido es un sistema de archivos al otro lado de una red, por lo que si hay un problema, puede haber al menos dos tipos de fuentes: la solucif3n del recurso compartido en sed o la red. Los siguientes son ejemplos de mensajes que indican un problema al acceder a archivos desde un recurso compartido (se ha eliminado alguna informacif3n para mayor claridad o privacidad):<\/P>Componente Enterprise<\/P><\/TD>Nivel<\/P><\/TD>C3digo<\/P><\/TD>Mensaje<\/P><\/TD>Notas<\/P><\/TD><\/TR>Servidor<\/P><\/TD>ADVERTENCIA<\/P><\/TD>7721<\/P><\/TD>fallo al escribir latido<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>ADVERTENCIA<\/P><\/TD>7712<\/P><\/TD>Se encontr un error mientras se sincronizaba con el almacn de configuracin<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>GRAVE<\/P><\/TD>6561<\/P><\/TD>No se pudo devolver todas las configuraciones de carpetas<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>GRAVE<\/P><\/TD>9000<\/P><\/TD>Error interno del servidor: Servicio <name> no encontrado<\/P><\/TD>Tenga en cuenta que una solicitud para un servicio que actualmente no existe tambin generar un mensaje como este. Para que esto indique un problema con un recurso compartido, el servicio debe existir realmente en el sitio.

Servidor

GRAVE

6605

No se pudo devolver todas las configuraciones de servicios en la carpeta (El sistema no puede encontrar el archivo especificado)

 

Servidor

GRAVE

6652

No se puede leer el servicio desde el almacén de configuración (El sistema no puede encontrar el archivo especificado)

 

Servidor

GRAVE

6566

No se pudo recuperar el estado del servicio (El sistema no puede encontrar el archivo especificado)

 

Servidor

GRAVE

9015

Error al obtener la lista de servicios. (El sistema no puede encontrar el archivo especificado)

 

Servidor

GRAVE

6615

No se puede recuperar la información del recurso 'Permisos'. ...

Este mensaje no es exclusivo para problemas con recursos compartidos, pero puede estar asociado con ellos.

Portal Enterprise

GRAVE

218037

Sitio Portal inicializado y configurado pero actualmente inaccesible porque el directorio de contenido no está disponible...

o Error. Debe filtrar según estos niveles de evento y tiempo.<\/P>

¿Qué pueden decirle estos registros? <\/P>

1. ¿Detecta la máquina local un problema?
   1. Si no encuentra errores temáticamente relacionados en los registros principales de Windows para las marcas de tiempo de sus registros del servidor Esri, entonces tiene alguna evidencia de que el problema no se debe a un problema específico de la máquina cliente. Aunque esto puede no ser suficiente evidencia para descartar completamente la posibilidad, ha tomado pasos importantes hacia ese objetivo y puede priorizar sus esfuerzos en otro lugar.<\/LI>
   2. Si encuentra errores interesantes en la máquina local, prioriza sus esfuerzos en comprender y tratar de resolver esos. <\/LI><\/OL><\/LI>
   3. ¿Detecta el protocolo SMB un problema?
      1. Si no encuentra errores en los registros SMBClient que coincidan con las marcas de tiempo, puede inferir que el problema no es un error en lo que respecta al protocolo SMB. Por ejemplo, si está investigando mensajes que indican que no se puede encontrar un archivo, el protocolo SMB no clasificará eso como un error— Para todo lo que sabe, ese archivo no existe. En ese caso, el protocolo funcionó correctamente y devolvió una información correcta. <\/LI>
      2. Por otro lado, si ve un error como el mostrado arriba, tiene sentido enfocar la investigación en el propio protocolo SMB.<\/LI><\/OL><\/LI><\/OL>

         Encontrar errores temáticamente relacionados en estos registros suele ser muy significativo para otros especialistas que no están familiarizados con el registro Esri pero que probablemente entienden o confían más en el registro del sistema operativo.<\/P>

         Lo que puede aprender con otros especialistas<\/H2>Muchos problemas con compartición de archivos no se presentan en los registros del Visor de Eventos del sistema operativo cliente. La mayoría de las otras fuentes de información requieren privilegios elevados (más allá de la administración del servidor Esri o la administración local de la máquina), conocimientos especializados o ambos. Por lo tanto, para avanzar en este ámbito, debe emplear dos atributos importantes: (a) su personalidad ganadora y (b) su compromiso con la investigación basada en evidencia.<\/P>Personas de redes<\/H3>Si tiene las firmas del registro de aplicaciones Esri que sugieren un problema o fallo relacionado con la red, querrá investigar en este ámbito.<\/P>La mayoría de los problemas de red relacionados con compartición de archivos no se expresan claramente en soluciones clásicas de monitoreo o registro de red. El monitoreo de red a menudo se centra en capacidad, rendimiento y calidad del servicio. Eso es útil para la planificación y administración general de la red pero no necesariamente ayuda a solucionar conexiones específicas. El registro de denegaciones de un firewall vale la pena consultarlo, pero comúnmente no es donde se encuentran las causas de problemas con compartición de archivos.<\/P>Las respuestas típicamente se encuentran capturando tráfico de red durante un corto período cuando ocurre el problema o se activa manualmente. Capturar un problema intermitente no es tan difícil como parece. Se puede configurar una captura con búfer circular para mantener una reserva estable de archivos, sobrescribiéndolos conforme pasa el tiempo. El equipo de red de su organización, además de tener las herramientas y privilegios, probablemente sabrá cómo hacerlo. Así que no necesita saber exactamente cuándo ocurrirá el problema nuevamente. <\/P>En muchos casos, un búfer circular puede persistir datos capturados durante muchas horas sobre una base continua. Cuando el problema ocurra otra vez, pida al equipo de red que detenga la traza. Luego, use las marcas de tiempo de los registros del servidor Esri para investigar la información capturada en la red. Con algunos conocimientos sólidos básicos sobre redes (del equipo o suyos) y dedicación, se puede aprender mucho. Incluso si su equipo no tiene mucho conocimiento en análisis de redes, puede buscar anomalías. O hay características anormales en la red en las marcas temporales cuestionadas o no las hay. Si hay algo anormal o sospechoso, se pueden traer expertos adicionales según sea necesario. La especificidad probablemente atraerá a estos expertos.<\/P>Personas encargadas del compartimiento de archivos<\/H3>Si las firmas del registro del servidor Esri no sugieren un problema de red, querrá investigar este ámbito. Las soluciones para compartición de archivos, como la mayoría de los sistemas TI, típicamente tienen registros. Una revisión de estos registros en los momentos cuestionados es apropiada. Si hay errores temáticamente relacionados para esas marcas temporales, tiene una causa probable para investigar más a fondo. Y cuenta con su equipo administrativo del compartimiento (y la organización soporte del proveedor) para liderar el camino.<\/P>También es posible que los registros del compartimiento no tengan errores relacionados. Si la evidencia acumulada ha descartado otras fuentes probables y los registros del compartimiento no indican un problema, queda una posibilidad restante. Es posible que el compartimiento y el software Esri clasifiquen los problemas diferente. Por ejemplo, si un compartimiento está diseñado o configurado para proporcionar consistencia eventual, no registrará errores al respecto. Pero sabemos que ArcGIS Server espera consistencia inmediata. Entonces, el compartimiento no ve error pero ArcGIS Server no recibe lo que necesita.<\/P>Exploremos esta idea un poco más, ya que surge usando el ejemplo de un sitio ArcGIS Server con dos máquinas con la tienda de configuración y directorios del servidor almacenados en un compartimiento. Si la máquina A escribe a un archivo, la máquina B del sitio ArcGIS Server debería poder leer esa nueva información inmediatamente. Eso es consistencia inmediata: lectura después escritura para cualquier cliente al compartimiento. Entonces, si ArcGIS Server dice: "Oye, no puedo encontrar ese archivo," o "Ese archivo parece diferente a lo esperado," y el compartimiento dice: "No sé de ningún problema," ¿cuál es su hipótesis resultante? Habiendo descartado otras causas probables, su hipótesis resultante es que el compartimiento no está proporcionando consistencia "lectura después escritura". Ninguna otra idea encaja tan bien con los datos.<\/P>¿Qué hace con eso? Esta es otra investigación con el equipo administrativo del compartimiento. Pero en lugar de enfocarse en un error en sus registros, busca entender cómo múltiples clientes viendo el mismo archivo al mismo tiempo lo ven siempre en exactamente el mismo estado. Ningún cliente puede ver el estado anterior como válido después que otro cliente cambió el archivo. Y ningún cliente puede cambiar un archivo cuando otro cliente tiene bloqueo exclusivo sobre él. Uy-uy-uy. Dijimos la "palabra con L" (lock). Eso trae a colación otro término o concepto que quizás haya escuchado antes: bloqueo oportunista (opportunistic locking) también referido como Oplocks.<\/P>¿El problema son los Oplocks?<\/H4>Aunque ciertamente es posible que los Oplocks estén causando un problema para su sistema, para los problemas aquí discutidos las probabilidades están en contra. Pero como tomar decisiones basadas en evidencia es la forma correcta para avanzar, puede usar evidencia para probar si es una causa.<\/P>Vale la pena pensar qué son los Oplocks y sus alternativas. Los Oplocks son bloqueos oportunistas. El cliente (el sistema Esri) asume optimistamente que los archivos conocidos en el compartimiento están sin cambios y/o son seguros para cambiar salvo que reciba aviso del servidor (el compartimiento). Lo opuesto al bloqueo oportunista es bloqueo pesimista (no bloquear no es opción). En ese caso, el cliente asume pesimistamente que otros clientes podrían estar usando esos archivos conocidos en el compartimiento por lo que verifica antes de hacer algo. Los bloqueos oportunistas son una gran estrategia cuando la mayoría archivos no son accedidos por más de un cliente a la vez. Los bloqueos pesimistas son mejor estrategia cuando archivos son frecuentemente accedidos por más de un cliente simultáneamente. ¿Qué sabemos sobre sitios ArcGIS Server o Portal for ArcGIS con múltiples máquinas? Hay al menos dos clientes accediendo a los mismos archivos simultáneamente.<\/P>Así que Oplocks es subóptimo para casos uso servidor Esri. Pero ¿es causa del problema? No lo sabe aún. Dado que tiene su firma problemática desde sus registros Esri, puede cambiar configuraciones Oplocks y ver si cambia esa firma (presencia y frecuencia del mensaje dado misma carga). Estos parámetros pueden cambiarse en OS cliente (máquinas donde corre software Esri) o solución compartición según configuración.<\/P>Aquí cómo hacerlo si usted es administrador local OS cliente: Abra ventana PowerShell como "Administrador" y anote configuraciones actuales:<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Luego puede cambiarlas. Los siguientes comandos deshabilitan todo caché lado cliente<\/A> (incluyendo 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>Luego puede inspeccionar estas configuraciones con:<\/P>Get-SmbClientConfiguration<\/FONT><\/P>Tenga presente que cambios aplicarán cuando cliente establezca nueva conexión al compartimiento; reiniciar software servidor Esri causaría efecto inmediato.<\/P>Una vez cambie configuraciones vuelva a revisar registros Esri para ver si firma problemática — mensaje error e información frecuencia bajo misma carga — ha sido resuelta. Si sí, celebre. Si no ¿qué sigue?<\/P>

         ¿Es algo ¿algo más? <\/H4>Sísi has llegado a este punto, el problema es otra cosa.<\/P>Has refutado todas las hipf3tesis razonables hasta ahora. Te queda un diagnf3stico por exclusif3n. Ese diagnf3stico es que la solucif3n de file share (ya sea por disef1o o no) no este1 proporcionando consistencia inmediata. <\/P>En esta circunstancia, puede ser fatil tener evidencia corroborativa. Una muy buena manera de hacerlo es comparar con una solucif3n diferente de file share. Aunque un file share desde una me1quina virtual Windows puede no ser una solucif3n que tfa o tu organizacif3n quieran adoptar permanentemente, puede ser muy fatil para una investigacif3n. Esri no tiene evidencia empedrica de que los file shares desde una sola me1quina Windows produzcan problemas de consistencia inmediata. No hay una base tef3rica fuerte para ello. Y, si desactivas Oplocks como se describif3 arriba, tambie9n neutralizas las bases tef3ricas de9biles. El file share de la me1quina Windows debereda configurarse con los mismos pare1metros SMB que el file share original.  El comando Set-SmbServerConfiguration de PowerShell se puede usar para igualar la mayoreda de los pare1metros que el equipo de administracif3n del file share indicareda desde su solucif3n.<\/P>En cualquier caso, si apuntas tu(s) servidor(es) Esri al file share de la me1quina Windows y la firma del problema desaparece, tu diagnf3stico por exclusif3n ha sido corroborado. A partir de ahd, el equipo de la soluci3n de file share puede decidir si quieren intentar igualar la caracterdstica de consistencia inmediata o indicar que no desean proporcionar tal servicio. Asd que tienes una soluci3n o una respuesta. <\/P>En conclusi3n<\/H1>Investigar un problema sospechoso de file share es uno de los esfuerzos de resoluci3n de problemas mas desafiantes en el espacio de administraci3n de ArcGIS Enterprise. Este art4culo no ha pretendido convertirte a ti, lector individual, en un practicante exitoso en solitario en este espacio; mas bien, el objetivo es darte informaci3n fundamental y un proceso. Si ejecutas cuidadosamente este proceso, puedes involucrar a muchos especialistas diferentes para ayudarte a alcanzar la soluci3n. Ademas de involucrar a los expertos en dominio relacionados de tu propia organizacin, puedes traer Soporte Tcnico Esri y/o Servicios Profesionales para participar. Con el tiempo, tu ejecucin cuidadosa y la participacin de un equipo de calidad pueden diagnosticar correctamente problemas en este espacio.<\/P>Apndice: Mensajes de registro correlacionados con problemas de file share<\/H1>La informacin a continuacin es una lista parcial de c
         igos y mensajes de error que pueden indicar un problema con file share en tu sistema ArcGIS Enterprise.<\/P>Mensajes de advertencia y severos<\/H2>En el nivel predeterminado del registro, los siguientes c
         igos y mensajes usualmente indican un problema con un file share (en un sitio con maltiples m1quinas). A menudo es atil observar los mensajes inmediatamente antes y despu s. Cuando haces eso, quieres usar los campos m
         quina, proceso e hilo para reconocer mensajes relacionados. Dado que hay muchas m
         quinas, procesos e hilos, los mensajes vecinos inmediatos, por tiempo, pueden ser de otro proceso.<\/P>Componente Enterprise<\/P><\/TD>Nivel<\/P><\/TD>Código<\/P><\/TD>Mensaje<\/P><\/TD>Notas<\/P><\/TD><\/TR>Servidor<\/P><\/TD>ADVERTENCIA<\/P><\/TD>7721<\/P><\/TD>fallo al escribir latido del corazn<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>ADVERTENCIA<\/P><\/TD>7712<\/P><\/TD>Se encontrf un error mientras se sincronizaba con la tienda config<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>SEVERO<\/P><\/TD>6561<\/P><\/TD>Fallo al devolver todas las configuraciones de carpeta<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>SEVERO<\/P><\/TD>9000<\/P><\/TD>Error interno del servidor: Servicio <name> no encontrado<\/P><\/TD>Tenga en cuenta que una solicitud para un servicio que actualmente no existe tambin generara un mensaje como este. Para que esto indique un problema con un file share, el servicio debe existir realmente en el sitio.<\/P><\/TD><\/TR>Servidor<\/P><\/TD>SEVERO<\/P><\/TD>6605<\/P><\/TD>Fallo al devolver todas las configuraciones del servicio en la carpeta (El sistema no puede encontrar el archivo especificado)<\/P><\/TD> <\/P><\/TD><\/TR>Servidor<\/P><\/TD>SEVERO<\/p>

MikeSchiewe

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