はじめに
ArcGIS Enterprise のアーキテクチャでは、共有構成ファイル、コンテンツ、またはバックアップの保存のためにファイル共有を使用する要件があることがよくあります（https://enterprise.arcgis.com/en/server/latest/install/windows/choosing-a-nas-device.htm）。これは特に、複数マシンサイト（高可用性構成など）を含む展開パターンの場合に当てはまります。Portal for ArcGIS、ArcGIS Server、および ArcGIS Data Store の各主要な ArcGIS Enterprise コンポーネントでファイル共有が使用されています。
以下の図では、「Shared Content」と「Shared Config-store and Directories」がファイル共有上にあります：
ファイル共有には物理的なハードウェアデバイスから仮想ファイルシステムやその他のプロバイダーまで、多くの種類とバリエーションがあります。共有ファイルシステムは複数のコンポーネント間でコンテンツを効率的に共有する方法を提供しますが、パフォーマンス、権限、またはファイルレベルの一貫性に関連する課題も引き起こす可能性があります。
ArcGIS Enterprise の展開で問題が発生し、それが共有ストレージに関連していると疑われる場合、アーキテクチャをどのように評価し潜在的な課題を把握し対処すべきか判断するのは難しいことがあります。実際には、ファイル共有の問題を解決することは困難ですが、特定の指標や測定基準を設定して問題を定義し、ベースラインを作成し、疑わしい問題をテストすることで成功の可能性は大幅に高まります。本記事は、ArcGIS Enterprise 展開でファイル共有の問題があるかどうか、その症状や指標（署名）が何か、そして根本原因を調査する方法について判断する手助けを目的としています。
Linux/NFS および Windows/SMB システムにも類似した原則が適用されますが、本記事では Windows/SMB システムに焦点を当てています。
ArcGIS Enterprise はどのようにファイル共有を使用するか？
ArcGIS Enterprise がファイル共有を使用する方法はいくつかあり、以下が含まれます：
- ArcGIS Server サイト内の登録済みデータリポジトリ
- ArcGIS Data Store バックアップ用の共有バックアップ場所
- 災害復旧ワークフロー用 WebGISDR バックアップの保存および抽出場所
- 複数マシン ArcGIS Server サイトの「config-store」および「server directories」を保存する場所
- 高可用性 ArcGIS Enterprise portal サイトの「content directory」を保存する場所
後者2つが本記事の焦点です。これらの場合、ファイル共有は複数マシンサイト内の各マシンが何が起こっているかを知る役割を果たします。比喩的に言えば、ファイル共有は「config-store」、「server directories」、または「content directory」をサポートしているときの ArcGIS Enterprise portal または ArcGIS Server サイトの「神経系」の一部として機能します。したがって、ファイル共有に問題がある場合、ArcGIS Server または Portal for ArcGIS サイトはサービス公開の問題やサーバーの「不安定さ」など、多様な断続的症状を示すことがあります。
ファイル共有に関連した問題の認識と調査
潜在的なファイル共有問題の分析は単独で始めることもあります。各 ArcGIS ソフトウェアコンポーネントのログを調べます。しかし、そこにファイルアクセスに関連した問題を示す証拠が見つかった場合は、他の情報源やソフトウェアコンポーネントと連携する必要があります。これは通常、一人で完結せず必要なアクセス権限や知識が一人に集中していないため他者と協力することになります。
本記事では異なる権限や知識セットで追求できる内容について説明します。まず ArcGIS Enterprise のログから始める理由は二つあります。一つ目はそれら権限を持っていると仮定していること。二つ目はここでファイル共有問題があるかどうか、その理由を初期判断できるからです。
基礎
開始前に、生産性を最大化するため適切な環境選択、複雑さの制御、および適切なチーム編成を行いたいところです。
環境
可能ならば「低環境」（つまり本番環境以外）で問題を観察してください。本番環境で見られる問題について ArcGIS Server ログでその署名（特徴）を理解します。その署名検出については後述します。その後、ステージング、テストまたは UAT 環境で同じ署名が見つかるか確認してください。その環境で問題を見るためには何らかの操作活動を生成しなければならない場合があります（多くの問題はシステムがアイドル状態だと現れません）。
低環境で問題が確認できれば、その環境で調査すべきです。その環境では活動レベルをより制御できるため無関係な要因による妨害が少なくなります。また何が起こっているか把握しやすいため潜在的原因についてより良い考えを形成できます。最後にトラブルシューティング目的で変更するときも可能ならまず低環境で行いユーザーへの不要な影響を避けてください。
複雑さ
基本構成を変えずにできるだけ複雑さを減らしたいところです。低環境で作業すると複雑さ軽減につながります。しかし複数マシンサイトの場合、多数マシンがあるため任意の問題について調査すべき箇所も増えます。
効果的な方法としてサイト内冗長マシンを停止することがあります。例えば ArcGIS Server サイトに3台マシンがあれば、そのうち2台（OS 停止またはサイト内停止）をオフにします。残った1台も同じ目的でファイル共有を使い、多くの場合問題も継続して現れます。冗長マシン停止によって問題が消える場合、それは重要な手掛かりです。具体的にはその問題が同時クライアントアクセスによるものでネットワーク自体ではない可能性があります。
他者参加
複数環境にまたがる問題解決では、自身の権限や経験不足による壁に遭遇することがあります。権限は一時付与可能ですが、その分野での経験も同様に価値があります。専任チーム編成しておくことで質問発生時にも即座に対応資源確保できます。
この種仮想チーム活動で機能不全になりやすい原因として全員が意味ある貢献方法理解できていないことがあります。ネットワーク管理者やファイル共有管理者は通常 Esri ソフトウェアについてあまり知らずインフラ上アプリケーション学習意欲も低い傾向ですが好奇心旺盛で問題解決好きです。「ネットワークに問題がありますか？」という漠然質問や「ネットワークが原因です」という早計な非難では興味深い回答得られません。一方、証拠ベースで具体的質問すると有益回答得られる可能性高まります。例えば「特定時間 X, Y, Z にアプリケーションログで『connection time out』メッセージ見られます。約2～3時間ごと発生しています。その期間中トラフィックキャプチャして接続状況解析いただけますか？」などです。
証拠ベース仮説と調査
単独でも仮想チームでも効果的になるには証拠ベースアプローチが最良です。その基本要素はいくつかあります：
- システム変更前に初期観察し、それら観察結果が一貫していること確認する。
- 特定ワークフローやリクエスト・操作について具体的観察から始める。
- 繰り返し性・再現性確認。不規則事象や誤警報追わない。
- 進行中記録保持し詳細確認・他者共有可能とする。
- 各問題について複数仮説立て最初案だけに固執せず順次検証。
- 仮説否定（または支持）できる証拠特定し追求。
- 他者専門知識活用。専門家へ特定観察結果意味説明依頼すると理解進み協力得やすくなる。
ArcGIS Enterprise 管理者として学べること：署名
ArcGIS Enterprise のログ（ArcGIS Enterprise portal ログおよび ArcGIS Server ログ）は問題署名特定場所です。それはファイル共有問題有無判定および変更効果測定に使う指標となります。 解決しました。<\/P>
ArcGIS Enterprise コンポーネントがファイル共有と「通信」する場合、それはしばしば入力／出力（I／O）と呼ばれるファイルオブジェクトの読み書きを行っています。そして、それは特定のアカウント（service account<\/A>）として行われるため、権限の問題やファイルシステムの問題が発生する可能性があります。 <\/P>権限の問題は通常、ログメッセージでかなり認識しやすく、比較的簡単に対処できます。例えば、ログメッセージ「ディレクトリパス''{0}''に書き込めません。場所が有効であり、ArcGIS Server アカウントにその場所への権限があることを確認してください。」（コード6697）は原因を説明し、解決策のアイデアを提供します。実効権限は共有自体のものと、共有を通じて公開されるファイルおよびディレクトリの両方に関わることに注意してください。<\/P>
共有権限<\/P><\/TD> | ファイルおよびディレクトリ権限<\/P><\/TD><\/TR> |
 <\/span> <\/P><\/TD> <\/span> <\/P><\/TD><\/TR><\/TBODY><\/TABLE> <\/P>ファイル共有、I/O、または IOException に関連するパスを言及するログメッセージは、おそらく権限が問題ではないことを意味します。この記事の最後には、ファイル共有の問題と相関するログコードおよびメッセージタイプの部分的なリストが付録としてあります。相関は因果関係を確立する基礎です。これらのようなメッセージが見られた場合、それはファイル共有および／またはそのネットワーク経路をより詳しく調査する必要がある良い指標ですが、ファイル共有が原因であるという決定的な証拠ではありません。 <\/P>ログメッセージタイプの詳細は、探している高レベルのパターンを曖昧にするかもしれません。ファイル共有はネットワークの向こう側にあるファイルシステムなので、問題があれば少なくとも2種類の原因があります：ファイル共有ソリューション自体かネットワークです。以下はファイル共有からファイルにアクセスする際の問題を示すメッセージの例です（一部情報は明確化またはプライバシー保護のため削除されています）：<\/P>Enterprise Component<\/P><\/TD>Level<\/P><\/TD>Code<\/P><\/TD>Message<\/P><\/TD>Notes<\/P><\/TD><\/TR>Server<\/P><\/TD>WARNING<\/P><\/TD>7721<\/P><\/TD>22failed to write heartbeat22<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>WARNING<\/P><\/TD>7712<\/P><\/TD>22An error was encountered while synchronizing with the config store22<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>SEVERE<\/P><\/TD>6561<\/P><\/TD>22Failed to return all folder configurations22<\/P><\/TD> <\/P><\/TD><\/TR>Server<\/P><\/TD>SEVERE<\/P><\/TD>9000<\/P><\/TD>22Internal Server Error: 22Service <name> not found22<\/P><\/TD>現在存在しないサービスへのリクエストもこのようなメッセージを生成します。これがファイル共有の問題を示すには、そのサービスが実際にサイト内に存在している必要があります。<\/P><\/TD><\/TR>Server<\/P><\/TD>SEVERE<\/P><\/TD>6605<\/P>22Failed to return all services configurations in the folder 685 (The system cannot find the file specified)22<\td\r\n<td\r\nwidth=275\r\n<p> <\p\r\n</td\r\n</tr\r\n<tr\r\n<td\r\nwidth=86\r\n<p>ServerSEVERE665222Unable to read the service 685 from the configuration store 685 (The system cannot find the file specified)22 |
ServerSEVERE6566
22Failed to retrieve the status of the service 685 (The system cannot find the file specified)22
Server
SEVERE
9015
22Error getting list of services. 685 (The system cannot find the file specified)22
Server
td
rtthhhtdwdthdthdthdthdthdthdthdthdthdthdthdthdthdthdthdthdthdthdthdthdthdthdthdthdtwdrtwdwdwdwdwdwdwdwdwdwdwdwdwdwdwdwdwdwdwdwdwdrtwtwtwtwtwtwtwtwtwtwtwtwtwtwtwtwtwtwtwtwtwtwtwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwttwwtwttwwtwttwwtwttwwtwttwwtwttwwtwttwwtwttwwtwttwwtwttwwtwttwwtwttpptppptppptppptppptppptppptppptppptppptppptppptppptppptppptppptppptppptppptppptppptppptppptppptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptpptppttppttppttppttppttppttppttppttppttppttppttppttppttppttppttppttppttpptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptsptspspspspspspspspspspspspspspspspspspspspspspspspspspspspspspspspspspspsspstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstsstststststststststststststststststststststststststststststststststststt またはエラー。これらのイベントレベルと時間に基づいてフィルタリングする必要があります。<\/P>
これらのログから何がわかりますか？ <\/P>
- ローカルマシンは問題を検出していますか？
- Esriサーバーログのタイムスタンプに対応するメインのWindowsログでテーマ的に関連するエラーが見つからない場合、その問題はクライアントマシン固有の問題によるものではないという証拠があります。これは可能性を完全に排除するには十分な証拠ではないかもしれませんが、その目的に向けて重要なステップを踏んでおり、他の場所で優先的に対応できます。<\/LI>
- ローカルマシンで興味深いエラーが見つかった場合、それらを理解し解決しようとすることに優先順位を置きます。 <\/LI><\/OL><\/LI>
- SMBプロトコルは問題を検出していますか？
- タイムスタンプに一致するSMBClientログにエラーが見つからない場合、SMBプロトコルに関しては問題はエラーではないと推測できます。例えば、ファイルが見つからないことを示すメッセージを調査している場合、SMBプロトコルはそれをエラーとして分類しません—そのファイルが存在しない可能性もあるためです。その場合、プロトコルは正しく機能し、正しい情報を返しました。 <\/LI>
- 一方で、上記のようなエラーが見られる場合は、調査をSMBプロトコル自体に集中させるのが理にかなっています。<\/LI><\/OL><\/LI><\/OL>
これらのログでテーマ的に関連するエラーを見つけることは、Esriのログに不慣れだがオペレーティングシステムのログを理解または信頼しやすい他の専門家にとって非常に意味があります。<\/P>
他の専門家と学べること<\/H2>多くのファイル共有の問題はクライアントOSのイベントビューアーログには現れません。他の情報源のほとんどは昇格された権限（Esriサーバー管理やローカルマシン管理以上）や専門知識、またはその両方を必要とします。したがって、この分野で進展するには、(a) あなたの魅力的な人柄 と (b) 証拠に基づく調査へのコミットメント の2つの重要な属性を活用しなければなりません。<\/P>ネットワーク担当者<\/H3>ネットワーク関連の問題や障害を示唆するEsriアプリケーションログ署名がある場合、この分野で調査したいでしょう。<\/P>ファイル共有に関連するほとんどのネットワーク問題は、従来のネットワーク監視やログソリューションでは明確には表れません。ネットワーク監視は通常、容量、スループット、およびサービス品質に焦点を当てています。これは全体的なネットワーク計画や管理には有用ですが、特定接続のトラブルシューティングには必ずしも役立ちません。ファイアウォールの拒否ログは参照価値がありますが、ファイル共有問題の原因が一般的に見つかる場所ではありません。<\/P>答えは通常、問題が発生しているか手動でトリガーされた短期間中にネットワークトラフィックをキャプチャすることで見つかります。断続的な問題をキャプチャすることは思ったほど難しくありません。リングバッファキャプチャを設定して安定したファイル在庫へのキャプチャを継続し、時間経過とともに上書きします。組織のネットワークチームはツールと権限だけでなく、その方法も知っているでしょう。したがって、次回いつ問題が発生するか正確に知る必要はありません。 <\/P>多くの場合、リングバッファは数時間分のネットワークキャプチャデータをローリングベースで保持できます。問題が再度発生したらネットワークチームにトレース停止を依頼します。そしてEsriサーバーログのタイムスタンプを使ってネットワークキャプチャ情報を調査します。堅実なネットワーク基礎知識（ネットワークチームまたはあなた自身）と献身があれば、多くを学べます。チームにあまりネットワーク分析知識がなくても異常を探せます。そのタイムスタンプで異常なネットワーク特性があるかどうかです。不審な点や異常があれば必要に応じて追加専門家を招くことができます。具体性はこれら専門家には魅力的でしょう。<\/P>ファイル共有担当者<\/H3>Esriサーバーログ署名がネットワーク問題を示唆しない場合、この分野で調査したいでしょう。ファイル共有ソリューションもほとんどのITシステム同様ログがあります。該当時間帯のこれらログレビューは適切です。そのタイムスタンプでテーマ的に関連するエラーがあれば、更なる調査対象となる可能性があります。そしてファイル共有管理チーム（およびそのベンダーサポート組織）が主導します。<\/P>ファイル共有ログに関連エラーがない可能性もあります。他の可能性ある原因が排除されていてファイル共有ログにも問題が示されていない場合、残る可能性があります。それはファイル共有とEsriソフトウェアで問題分類方法が異なることです。例えば、ファイル共有が最終的一貫性（eventual consistency）を提供するよう設計・構成されている場合、それについてエラー記録しません。しかしArcGIS Serverは即時一貫性（immediate consistency）を期待しています。そのためファイル共有側にはエラーなしでもArcGIS Server側では必要な状態になっていません。<\/P>この考え方についてもう少し掘り下げましょう。例として構成ストアとサーバーディレクトリがファイル共有上にある2台構成ArcGIS Serverサイトの場合です。マシンAがファイルを書き込むとArcGIS Serverサイト内マシンBはすぐその新情報を読み取れるべきです。それが即時一貫性：任意クライアントによる書き込み後すぐ読み取り可能ということです。もしArcGIS Server側で「そのファイルが見つからない」や「そのファイル内容が予想と違う」と言い、ファイル共有側では「問題なし」と言うならどう仮説立てますか？他原因排除後、この仮説になります：ファイル共有側は「書き込み後読み取り」一貫性を提供していない。他の仮説よりこのデータには合致します。<\/P>それでどうしますか？これはまた別途ファイル共有管理チームとの調査です。しかしログ内エラー注目ではなく複数クライアントが同じ時刻同じファイル状態を見る方法理解へ向けた調査です。一方クライアントによる変更後も他クライアントから変更前状態を見ることなく、一方クライアントによる排他ロック中別クライアントによる変更不可という状態維持です。あっ、「L語」（ロック）が出ましたね。それで過去話題になったかもしれない用語・概念：オポチュニスティックロッキング（Oplocks）について触れます。<\/P>問題はOplocksですか？<\/H4>Oplocksがあなたのシステム問題原因となっている可能性もあります。しかしここで話している問題では可能性低いです。ただ証拠ベース意思決定こそ進展手段なので、それが原因かどうか証拠で証明できます。<\/P>Oplocksおよび代替策について考えてみましょう。Oplocksとはオポチュニスティックロックです。クライアント（Esriシステム）は楽観的に、ファイル共有上で知っているファイルは変更されていない／安全だと仮定します。ただしサーバー（ファイル共有）から通知あれば例外です。一方オポチュニスティックロックとは逆なのはペシミスティックロック（ロックなしは選択肢外）です。この場合クライアントは悲観的に他クライアントも同じファイル使用中かもしれないので操作前チェックします。オポチュニスティックロック戦略は大半のファイルアクセス時単一クライアントの場合優秀です。一方ペシミスティックロック戦略は複数クライアント頻繁アクセス時優秀です。複数マシンArcGIS ServerやPortal for ArcGISサイトについて何かわかりますか？少なくとも2つ以上クライアント同時アクセスしていますね。<\/P>つまりOplocksはEsriサーバー利用ケースには最適とは言えません。しかしそれがあなたの問題原因でしょうか？わかりませんね。Esriログから得た問題署名がありますのでOplocks設定変更して同じ負荷条件下でメッセージ出現頻度など署名変化を見ることができます。このパラメータ変更はクライアントOS（Esriソフトウェア稼働マシン）または構成によってファイル共有ソリューション側でも可能です。<\/P>クライアントOSローカルマシン管理者なら以下手順です。「管理者として実行」でPowerShellコマンドウィンドウ開き現在設定確認：<\/P>Get-SmbClientConfiguration<\/FONT><\/P>次に設定変更可能です。以下コマンド群でクライアント側キャッシュ（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>これら設定確認はこちら：<\/P>Get-SmbClientConfiguration<\/FONT><\/P>変更内容は次回クライアントから新規接続時反映されます。Esriサーバーソフト再起動すれば即反映されます。<\/P>設定変更後、Esriログへ戻り同じ負荷条件下で署名・エラーメッセージ情報および頻度変化確認してください。それで改善あれば祝福しましょう。不改善ならどうしますか？<\/P>問題とは何でしょう 他に？はい—もしこの段階にいるなら、問題は他の何かです。これまでのすべての合理的な仮説を否定しました。残されたのは除外診断です。その診断は、ファイル共有ソリューション（設計によるものかどうかにかかわらず）が即時整合性を提供していないということです。 この状況では、裏付けとなる証拠を持つことが有用です。それを行う非常に良い方法は、別のファイル共有ソリューションと比較することです。Windows仮想マシンからのファイル共有は、あなたやあなたの組織が永久に採用したい解決策ではないかもしれませんが、調査には非常に役立ちます。Esriは単一のWindowsマシンからのファイル共有が即時整合性の問題を引き起こすという経験的証拠を持っていません。そのための強力な理論的根拠もありません。そして、上記のようにOplocksをオフにすると、その弱い理論的根拠も無効化されます。Windowsマシンのファイル共有は、元のファイル共有と同じSMBパラメーターで構成する必要があります。PowerShellのSet-SmbServerConfigurationコマンドを使用して、ファイル共有管理チームがそのソリューションから示すほとんどのパラメーターを一致させることができます。いずれにせよ、EsriサーバーをWindowsマシンのファイル共有に向けて問題の特徴が消えた場合、除外診断が裏付けられたことになります。そこから、ファイル共有ソリューションチームは即時整合性特性を再現しようとするか、そのようなサービスを提供したくないと示すかを決定できます。つまり、解決策か答えのどちらかが得られます。 結論疑わしいファイル共有問題の調査は、ArcGIS Enterprise管理領域で最も困難なトラブルシューティング作業の一つです。本記事は、個々の読者であるあなたをこの領域で成功する単独実践者にすることを目指していません。むしろ目的は、基礎的な情報とプロセスを提供することです。このプロセスを慎重に実行すれば、多くの異なる専門家を招いて解決策に到達する手助けができます。自組織内の関連ドメイン専門家だけでなく、Esriテクニカルサポートやプロフェッショナルサービスも参加させることが可能です。時間とともに、慎重な実行と質の高いチーム参加によって、この領域で問題を正しく診断できるようになります。付録：ファイル共有問題と関連するログメッセージ以下はArcGIS Enterpriseシステムでファイル共有問題を示す可能性があるエラーコードおよびメッセージの部分的なリストです。警告および重大なログメッセージ
デフォルトログレベルでは、以下のコードおよびメッセージは通常、（複数マシンサイトで）ファイル共有に問題があることを示します。直前および直後のメッセージを見ることがしばしば有用です。その際にはマシン、プロセス、およびスレッドフィールドを使って関連メッセージを認識します。多くのマシン・プロセス・スレッドがあるため、時間的に隣接するメッセージは別プロセスからの場合があります。
Enterprise Component | レベル | コード | メッセージ | 備考 |
Server | WARNING | 7721 | “heartbeat の書き込みに失敗しました” | |
Server | WARNING | 7712 | “config store との同期中にエラーが発生しました” | |
Server | SEVERE | 6561 | “すべてのフォルダー構成の返却に失敗しました” | |
Server | SEVERE | 9000 | “内部サーバーエラー: “Service <name> が見つかりません”” | 現在存在しないサービスへのリクエストでもこのようなメッセージが生成されます。これがファイル共有問題を示すには、そのサービスがサイト内に実際に存在している必要があります。 |
Server | SEVERE | 6605 | “フォルダー内のすべてのサービス構成の返却に失敗しました…（指定されたファイルが見つかりません）” | |
Server | SEVERE | 6652 | “構成ストアからサービス… を読み取れません（指定されたファイルが見つかりません）” | |
Server | SEVERE </td<tdwidth= |
