en to ja translation catalogue (53 entries)

note: type: Title ==
en: Troubleshooting and error recovery
ja: トラブルシューティングとエラーからの回復

note: type: Plain text
en: This chapter describes tasks to be performed in the event of hardware or system failures.
ja: この章では、ハードウェアやシステムに障害が発生した場合に必要な手順について説明します。

note: type: Title ===
en: Dealing with hard drive failure
ja: ハードドライブの障害の場合

note: type: Plain text
en: indexterm:[drive failure]indexterm:[disk failure]How to deal with hard drive failure depends on the way DRBD is configured to handle disk I/O errors (see <<s-handling-disk-errors>>), and on the type of meta data configured (see <<s-metadata>>).
ja: indexterm:[drive failure]indexterm:[disk failure]ハードドライブの障害への対処方法は、DRBDがディスクI/Oエラーを処理する方法(<<s-handling-disk-errors>>参照)、また設定されているメタデータの種類(<<s-metadata>>参照)によって異なります。

note: type: delimited block =
en: For the most part, the steps described here apply only if you run DRBD directly on top of physical hard drives. They generally do not apply in case you are running DRBD layered on top of
ja: ほとんどの場合、ここで取り上げる手順はDRBDを直接物理ハードドライブ上で実行している場合にのみ適用されます。次に示す層の上でDRBDを実行している場合には通常は適用されません。

note: type: delimited block =
en: an MD software RAID set (in this case, use `mdadm` to manage drive replacement),
ja: MDソフトウェアRAIDセット( `mdadm` を使用してドライブ交換を管理)

note: type: delimited block =
en: device-mapper RAID (use `dmraid`),
ja: デバイスマッパRAID( `dmraid` 使用)

note: type: delimited block =
en: a hardware RAID appliance (follow the vendor's instructions on how to deal with failed drives),
ja: ハードウェアRAID機器 (障害が発生したドライブの扱いについてはベンダーの指示に従ってください)

note: type: delimited block =
en: some non-standard device-mapper virtual block devices (see the device mapper documentation).
ja: 一部の非標準デバイスマッパ仮想ブロックデバイス(デバイスマッパのマニュアルを参照してください)

note: type: Title ====
en: Manually detaching DRBD from your hard drive
ja: 手動でDRBDをハードドライブから切り離す

note: type: Plain text
en: indexterm:[drbdadm, detach]If DRBD is <<fp-io-error-pass-on,configured to pass on I/O errors>> (not recommended), you must first detach the DRBD resource, that is, disassociate it from its backing storage:
ja: indexterm:[drbdadm]DRBDが<<fp-io-error-pass-on,I/Oエラーを伝えるように設定>>(非推奨)している場合、まずDRBDリソースを切り離すとよいでしょう。つまり、下位デバイスからの切り離しです。

note: type: Plain text
en: By running the `drbdadm status` or the `drbdadm dstate` command, you will now be able to verify that the resource is now in indexterm:[diskless mode]indexterm:[diskless (disk state)]indexterm:[disk state, Diskless]_diskless mode_:
ja: `drbdadm status` footnote:[以前は `drbdadm dstate` コマンドを推奨していました]コマンドを実行することで、現在の状態を確認することができます。

note: type: Plain text
en: If the disk failure has occurred on your primary node, you may combine this step with a switch-over operation.
ja: ディスク障害がプライマリノードで発生した場合、スイッチオーバーと、この手順を組み合わせることもできます。

note: type: Title ====
en: Automatic detach on I/O error
ja: I/Oエラー時の自動切り離し

note: type: Plain text
en: If DRBD is <<fp-io-error-detach,configured to automatically detach upon I/O error>> (the recommended option), DRBD should have automatically detached the resource from its backing storage already, without manual intervention. You may still use the `drbdadm status` command to verify that the resource is in fact running in diskless mode.
ja: DRBDが<<fp-io-error-detach,I/Oエラー時に自動的に切り離しを行うように設定>>(推奨オプション)されている場合、 手動での操作なしで、DRBDはすでにリソースを下位ストレージから自動的に切り離しているはずです。その場合でも `drbdadm status` コマンドを使用して、リソースが実際にディスクレスモードで実行されているか確認します。

note: type: Title ====
en: Replacing a failed disk when using internal meta data
ja: 障害が発生したディスクの交換(内部メタデータを使用している場合)

note: type: Plain text
en: If using <<s-internal-meta-data,internal meta data>>, it is sufficient to bind the DRBD device to the new hard disk. If the new hard disk has to be addressed by another Linux device name than the defective disk, the DRBD configuration file has to be modified accordingly.
ja: <<s-internal-meta-data,内部メタデータ>>を使用している場合、新しいハードディスクでDRBDデバイスを再構成するだけで十分です。交換したハードディスクのデバイス名が交換前と異なる場合は、DRBD設定ファイルを適切に変更してください。

note: type: Plain text
en: This process involves creating a new meta data set, then re-attaching the resource: indexterm:[drbdadm, create-md]
ja: 新しいメタデータを作成してから、リソースを再接続します。 indexterm:[drbdadm]

note: type: Plain text
en: Full synchronization of the new hard disk starts instantaneously and automatically. You will be able to monitor the synchronization's progress via `drbdadm status --verbose`, as with any background synchronization.
ja: 新しいハードディスクの完全同期がただちに自動的に始まります。通常のバックグラウンド同期と同様、同期の進行状況を `drbdadm status --verbose` で監視することができます。

note: type: Title ====
en: Replacing a failed disk when using external meta data
ja: 障害の発生したディスクの交換(外部メタデータを使用している場合)

note: type: Plain text
en: When using <<s-external-meta-data,external meta data>>, the procedure is basically the same. However, DRBD is not able to recognize independently that the hard drive was swapped, thus an additional step is required.
ja: <<s-external-meta-data,外部メタデータ>>を使用している場合でも、手順は基本的に同じです。ただし、DRBDだけではハードドライブが交換されたことを認識できないため、追加の手順が必要です。

note: type: Plain text
en: Make sure to run `drbdadm invalidate` on the node __*without*__ good data; this command will cause the local contents to be overwritten with data from the peers, so running this command on the wrong node might lose data!
ja: `drbdadm invalidate` は、必ず破棄するデータのある側のノードでを実行してください。 このコマンドはローカルのデータを対向ノードからのデータで上書きさせます。つまり、このコマンドを実行すると破棄する側のノードのデータが失われます。

note: type: Plain text
en: Here, the `drbdadm invalidate` command triggers synchronization. Again, sync progress may be observed via `drbdadm status --verbose`.
ja: 上記の `drbdadm invalidate` コマンドが同期をトリガーします。この場合でも、同期の進行状況は `drbdadm status --verbose` で確認できます。

note: type: Title ===
en: Dealing with node failure
ja: ノード障害に対処する

note: type: Plain text
en: indexterm:[node failure]When DRBD detects that its peer node is down (either by true hardware failure or manual intervention), DRBD changes its connection state from _Connected_ to _Connecting_ and waits for the peer node to re-appear. The DRBD resource is then said to operate in _disconnected mode_. In disconnected mode, the resource and its associated block device are fully usable, and may be promoted and demoted as necessary, but no block modifications are being replicated to the peer node. Instead, DRBD stores which blocks are being modified while disconnected, on a per-peer basis.
ja: indexterm:[node failure]DRBDが(実際のハードウェア障害であれ手動による介入であれ)対向ノードがダウンしていることを検出すると、DRBDは自身のコネクションステータスを `Connected` から `WFConnection` に変更し、対向ノードが再び現れるのを待ちます。その後、DRBDリソースは _disconnected mode(切断モード)_ で動作します。切断モードでは、リソースおよびリソースに関連付けられたブロックデバイスが完全に利用可能で、必要に応じて昇格したり降格したりします。ただし、ブロックの変更は対向ノードにレプリケートされません。切断中に変更されたブロックについての内部情報は対向ノードごとにDRBDが格納します。

note: type: Title ====
en: Dealing with temporary secondary node failure
ja: 一時的なセカンダリノードの障害に対処する

note: type: Plain text
en: indexterm:[node failure]If a node that currently has a resource in the secondary role fails temporarily (due to, for example, a memory problem that is subsequently rectified by replacing RAM), no further intervention is necessary — besides the obvious necessity to repair the failed node and bring it back online. When that happens, the two nodes will simply re-establish connectivity upon system start-up. After this, DRBD synchronizes all modifications made on the primary node in the meantime to the secondary node.
ja: indexterm:[node failure]セカンダリロールでリソースを持っているノードに一時的に障害が生じた場合(たとえばメモリ交換で直るようなメモリの問題)には、障害が発生したノードを修復してオンラインに戻すだけで十分です。修正したノードを起動すると、ノード間の接続が再確立され、停止中にプライマリノードに加えられた変更内容すべてがセカンダリノードに同期されます。

note: type: Plain text
en: At this point, due to the nature of DRBD's re-synchronization algorithm, the resource is briefly inconsistent on the secondary node. During that short time window, the secondary node can not switch to the Primary role if the peer is unavailable. Thus, the period in which your cluster is not redundant consists of the actual secondary node down time, plus the subsequent re-synchronization.
ja: この時点で、DRBDの再同期アルゴリズムの性質により、セカンダリノードのリソースの一貫性が一時的に失われます。この短時間の再同期の間は、対向ホストが使用できない場合でも、セカンダリノードをプライマリロールに切り替えることができません。したがって、セカンダリノードの実際のダウンタイムとその後の再同期の間は、クラスタが冗長性を持たない期間になります。

note: type: Plain text
en: Please note that with DRBD 9 more than two nodes can be connected for each resource, so for e.g. 4 nodes a single failing secondary still leaves two other secondaries available for failover.
ja: DRBD9では各リソースに3ノード以上が接続することができます。そのため、例えば4ノードでは一度フェイルオーバーしてもまだ2回フェイルオーバーすることができます。

note: type: Title ====
en: Dealing with temporary primary node failure
ja: 一時的なプライマリノードの障害に対処する

note: type: Plain text
en: indexterm:[node failure]From DRBD's standpoint, failure of the primary node is almost identical to a failure of the secondary node. The surviving node detects the peer node's failure, and switches to disconnected mode. DRBD does _not_ promote the surviving node to the primary role; it is the cluster management application's responsibility to do so.
ja: indexterm:[node failure]DRBDからみると、プライマリノードの障害とセカンダリノードの障害はほぼ同じです。生き残ったノードが対向ノードの障害を検出し、切断モードに切り替わります。DRBDは生き残ったノードをプライマリロールに _昇格しません_ 。これはクラスタ管理システムが管理します。

note: type: Plain text
en: When the failed node is repaired and returns to the cluster, it does so in the secondary role, thus, as outlined in the previous section, no further manual intervention is necessary. Again, DRBD does not change the resource role back, it is up to the cluster manager to do so (if so configured).
ja: 障害が発生したノードが修復されてクラスタに戻る際に、セカンダリロールになります。すでに述べたように、それ以上の手動による介入は必要ありません。このときもDRBDはリソースのロールを元に戻しません。変更を行うように設定されている場合は、クラス管理システムがこの変更を行います。

note: type: Plain text
en: DRBD ensures block device consistency in case of a primary node failure by way of a special mechanism. For a detailed discussion, refer to <<s-activity-log>>.
ja: プライマリノードに障害が発生すると、DRBDはアクティビティログというメカニズムによってブロックデバイスの整合性を確保します。詳細は<<s-activity-log>>を参照ください。

note: type: Title ====
en: Dealing with permanent node failure
ja: 永続的なノード障害に対処する

note: type: Plain text
en: indexterm:[node failure]If a node suffers an unrecoverable problem or permanent destruction, you must follow the following steps:
ja: indexterm:[node failure]ノードに回復不能な問題が発生した場合やノードが永久的に破損した場合は、次の手順を行う必要があります。

note: type: Plain text
en: Replace the failed hardware with one with similar performance and disk capacity.
ja: 障害が発生したハードウェアを同様のパフォーマンスと ディスク容量を持つハードウェアと交換します。

note: type: Plain text
en: Replacing a failed node with one with worse performance characteristics is possible, but not recommended. Replacing a failed node with one with less disk capacity is not supported, and will cause DRBD to refuse to connect to the replaced nodefootnote:[It couldn't replicate the data, anyway!].
ja: 障害が発生したノードを、それよりパフォーマンスが低いものと置き換えることも可能ですが、お勧めはできません。障害が発生したノードを、それよりディスク容量が小さいものと置き換えることはできません。このような場合には、DRBDを置き換えたノードへの接続は拒否されます。footnote:[結局はレプリケーションできません]

note: type: Plain text
en: Install the base system and applications.
ja: OSとアプリケーションをインストールします。

note: type: Plain text
en: Install DRBD and copy `/etc/drbd.conf` and all of `/etc/drbd.d/` from one of the surviving nodes.
ja: DRBDをインストールし、生き残ったノードから `/etc/drbd.conf` と、全ての `/etc/drbd.d/` を コピーします。

note: type: Plain text
en: Follow the steps outlined in <<ch-configure>>, but stop short
ja: <<ch-configure>>に記載された手順を、

note: type: Plain text
en: of <<s-initial-full-sync>>.
ja: <<s-initial-full-sync>>の前まで実行します。

note: type: Plain text
en: Manually starting a full device synchronization is not necessary at this point, it will commence automatically upon connection to the surviving primary and/or secondary node(s).
ja: この時点で、デバイスの完全同期を手動で開始する必要はありません。生き残ったプライマリノードへの接続時に、同期が自動的に開始します。

note: type: Title ===
en: Manual split brain recovery
ja: スプリットブレインからの手動回復

note: type: Plain text
en: indexterm:[split brain]DRBD detects split brain at the time connectivity becomes available again and the peer nodes exchange the initial DRBD protocol handshake. If DRBD detects that both nodes are (or were at some point, while disconnected) in the primary role, it immediately tears down the replication connection. The tell-tale sign of this is a message like the following appearing in the system log:
ja: indexterm:[split brain]ノード間の接続が可能になると、ノード間で初期ハンドシェイクのプロトコルが交換されます。この時点でDRBDはスプリットブレインが発生したかどうかを判断できます。両方のノードがプライマリロールであるか、もしくは切断中に両方がプライマリロールになったことを検出すると、DRBDは即座にレプリケーション接続を切断します。その場合、システムログにたとえば次のようなメッセージが記録されます。

note: type: Plain text
en: After split brain has been detected, one node will always have the resource in a indexterm:[StandAlone (connection state)]indexterm:[connection state]_StandAlone_ connection state. The other might either also be in the _StandAlone_ state (if both nodes detected the split brain simultaneously), or in indexterm:[Connecting (connection state)] indexterm:[connection state]_Connecting_ (if the peer tore down the connection before the other node had a chance to detect split brain).
ja: スプリットブレインが検出されると、1つのノードは常にindexterm:[StandAlone (connection state)]indexterm:[connection state]_StandAlone_ の状態でリソースを保持します。もう一方のノードもまた _StandAlone_ 状態になる(両方のノードが同時にスプリットブレインを検出した場合)、または indexterm:[WFConnection (connection state)] indexterm:[connection state] _WFConnection_ 状態になります(一方のノードがスプリットブレインを検出する前に対向ノードが切断をした場合)。

note: type: Plain text
en: At this point, unless you configured DRBD to automatically recover from split brain, you must manually intervene by selecting one node whose modifications will be discarded (this node is referred to as the indexterm:[split brain]_split brain victim_). This intervention is made with the following commands:
ja: DRBDがスプリットブレインから自動的に回復するように設定されていない場合は、この時点で手動で介入して、変更内容を破棄するほうのノードを選択する必要があります(このノードは _スプリットブレインの犠牲ノード_ と呼ばれる)。indexterm:[split brain]この介入は次のコマンドで行います。

note: type: delimited block =
en: This is still _work in progress_.
ja: ここは現在 _作業中_ です。

note: type: delimited block =
en: Expect rough edges and changes.
ja: 構成の変更が行われる予定です。

note: type: Plain text
en: On the other node (the indexterm:[split brain]_split brain survivor_), if its connection state is also _StandAlone_, you would enter:
ja: 他方のノード(スプリットブレインのindexterm:[split brain]生存ノード)のコネクションステータスも `StandAlone` の場合には、次のコマンド実行します。

note: type: Plain text
en: You may omit this step if the node is already in the _Connecting_ state; it will then reconnect automatically.
ja: ノードがすでに _Connecting_ の状態の場合は自動的に再接続するので、この手順は省略できます。

note: type: Plain text
en: Upon connection, your split brain victim immediately changes its connection state to _SyncTarget_, and gets its modifications overwritten by the other node(s).
ja: 接続すると、スプリットブレインの犠牲ノードのコネクションステータスがすぐに _SyncTarget_ に変化し、他のノードによって変更内容が上書きされます。

note: type: Plain text
en: The split brain victim is not subjected to a full device synchronization. Instead, it has its local modifications rolled back, and any modifications made on the split brain survivor(s) propagate to the victim.
ja: スプリットブレインの犠牲ノードは、デバイスのフル同期の対象にはなりません。代わりに、ローカル側での変更がロールバックされ、スプリットブレインの生存ノードに対して加えられた変更が犠牲ノードに伝播されます。

note: type: Plain text
en: After re-synchronization has completed, the split brain is considered resolved and the nodes form a fully consistent, redundant replicated storage system again.
ja: 再同期が完了すると、スプリットブレインが解決したとみなされ、2つのノードが再び完全に一致した冗長レプリケーションストレージシステムとして機能します。
