0 - en to ja translation catalogue (320 entries)

en: Preseeding
ja: Preseed

en: Monitoring
ja: 監視

en: Virtualization
ja: 仮想化

en: Advanced Administration
ja: 高度な管理

en: This chapter revisits some aspects we already described, with a different perspective: instead of installing one single computer, we will study mass-deployment systems; instead of creating RAID or LVM volumes at install time, we'll learn to do it by hand so we can later revise our initial choices. Finally, we will discuss monitoring tools and virtualization techniques. As a consequence, this chapter is more particularly targeting professional administrators, and focuses somewhat less on individuals responsible for their home network.
ja: この章では、前章までに説明した一部の側面を異なる視点からもう一度取り上げます。すなわち、1 台のコンピュータにインストールするのではなく、大規模な配備システムについて学びます。さらに、初回インストール時に RAID や LVM ボリュームを作成するのではなく、手作業でこれを行う方法について学びます。こうすることで初回インストール時の選択を訂正することが可能です。最後に、監視ツールと仮想化技術について議論します。その結果として、この章はより熟練した管理者を対象にしており、ホームネットワークに責任を負う個人を対象にしていません。

en: RAID and LVM
ja: RAID と LVM

en: <emphasis>PERSPECTIVE</emphasis> Btrfs combines LVM and RAID
ja: <emphasis>PERSPECTIVE</emphasis> Btrfs が LVM と RAID を結び付ける

en: Among the noteworthy features are the ability to take a snapshot of a filesystem tree at any point in time. This snapshot copy doesn't initially use any disk space, the data only being duplicated when one of the copies is modified. The filesystem also handles transparent compression of files, and checksums ensure the integrity of all stored data.
ja: <emphasis>btrfs</emphasis> の特筆すべき機能に、任意の時点におけるファイルシステムツリーのスナップショットを取る機能があります。このスナップショットコピーは初期状態ではいかなるディスク領域も使いません、コピー内容の 1 つが修正された際にデータが複製されます。また、このファイルシステムはファイルを透過的に圧縮することが可能で、さらにチェックサムを用いて保存されているデータの完全性を保証します。

en: In both the RAID and LVM cases, the kernel provides a block device file, similar to the ones corresponding to a hard disk drive or a partition. When an application, or another part of the kernel, requires access to a block of such a device, the appropriate subsystem routes the block to the relevant physical layer. Depending on the configuration, this block can be stored on one or several physical disks, and its physical location may not be directly correlated to the location of the block in the logical device.
ja: RAID と LVM のどちらの場合も、カーネルはハードディスクドライブやパーティションに対応するブロックデバイスファイルとよく似たブロックデバイスファイルを提供します。アプリケーションやカーネルの別の部分がそのようなデバイスのあるブロックにアクセスを要求する場合、適切なサブシステムが要求されたブロックを物理層のブロックに対応付けます。設定に依存して、アプリケーション側から見たブロックは単独か複数の物理ディスクに保存されます。このブロックの物理的場所は論理デバイス内のブロックの位置と直接的に対応するものではないかもしれません。

en: Software RAID
ja: ソフトウェア RAID

en: <emphasis>CULTURE</emphasis> <foreignphrase>Independent</foreignphrase> or <foreignphrase>inexpensive</foreignphrase>?
ja: <emphasis>CULTURE</emphasis> <foreignphrase>independent</foreignphrase> それとも <foreignphrase>inexpensive</foreignphrase>?

en: RAID can be implemented either by dedicated hardware (RAID modules integrated into SCSI or SATA controller cards) or by software abstraction (the kernel). Whether hardware or software, a RAID system with enough redundancy can transparently stay operational when a disk fails; the upper layers of the stack (applications) can even keep accessing the data in spite of the failure. Of course, this “degraded mode” can have an impact on performance, and redundancy is reduced, so a further disk failure can lead to data loss. In practice, therefore, one will strive to only stay in this degraded mode for as long as it takes to replace the failed disk. Once the new disk is in place, the RAID system can reconstruct the required data so as to return to a safe mode. The applications won't notice anything, apart from potentially reduced access speed, while the array is in degraded mode or during the reconstruction phase.
ja: RAID は専用ハードウェア (SCSI や SATA コントローラカードに統合された RAID モジュール) またはソフトウェア抽象化 (カーネル) を使って実装することが可能です。ハードウェアかソフトウェアかに関わらず、十分な冗長性を備えた RAID システムはディスク障害があっても利用できる状態を透過的に継続することが可能です。従って、スタックの上層 (アプリケーション) はディスク障害にも関わらず、引き続きデータにアクセスできます。もちろん「信頼性低下状態」は性能に影響をおよぼし、冗長性を低下させます。このため、もう一つ別のディスク障害が起きるとデータを失うことになります。このため実践的には、管理者は信頼性低下状態を障害の起きたディスクが交換されるまでの間だけに留めるように努力します。新しいディスクが配備されると、RAID システムは要求されたデータを再構成することが可能です。こうすることで信頼性の高い状態に戻ります。信頼性低下状態か再構成状態にある RAID アレイのアクセス速度は低下する可能性がありますが、この点を除けばアプリケーションがディスク障害に気が付くことはないでしょう。

en: When RAID is implemented by hardware, its configuration generally happens within the BIOS setup tool, and the kernel will consider a RAID array as a single disk, which will work as a standard physical disk, although the device name may be different (depending on the driver).
ja: RAID がハードウェアで実装された場合、その設定は通常 BIOS セットアップツールによってなされます。カーネルは RAID アレイを標準的な物理ディスクとして機能する単一のディスクとみなします。RAID アレイのデバイス名は (ドライバに依存して) 違うかもしれません。

en: We only focus on software RAID in this book.
ja: 本書ではソフトウェア RAID だけに注目します。

en: Different RAID Levels
ja: さまざまな RAID レベル

en: RAID is actually not a single system, but a range of systems identified by their levels; the levels differ by their layout and the amount of redundancy they provide. The more redundant, the more failure-proof, since the system will be able to keep working with more failed disks. The counterpart is that the usable space shrinks for a given set of disks; seen the other way, more disks will be needed to store a given amount of data.
ja: 実際のところ RAID の種類は 1 種類だけではなく、そのレベルによって識別される複数の種類があります。すなわち、設計と提供される冗長性の度合いが異なる複数の RAID レベルが存在します。より冗長性を高くすれば、より障害に強くなります。なぜなら、より多くのディスクで障害が起きても、システムを動かし続けることができるからです。これに応じて、与えられた一連のディスクに対して利用できる領域が小さくなります。すなわち、あるサイズのデータを保存するために必要なディスク領域のサイズが多くなります。

en: Linear RAID
ja: リニア RAID

en: This level doesn't provide any redundancy either, but disks aren't simply stuck on end one after another: they are divided in <emphasis>stripes</emphasis>, and the blocks on the virtual device are stored on stripes on alternating physical disks. In a two-disk RAID-0 setup, for instance, even-numbered blocks of the virtual device will be stored on the first physical disk, while odd-numbered blocks will end up on the second physical disk.
ja: 同様に RAID-0 にも冗長性がありません。しかしながら、RAID-0 は順番通り単純に物理ディスクを連結する構成ではありません。すなわち、物理ディスクは<emphasis>ストライプ状</emphasis>に分割され、仮想デバイスのブロックは互い違いになった物理ディスクのストライプに保存されます。たとえば 2 台のディスクから構成されている RAID-0 セットアップでは、偶数を付番されたブロックは最初の物理ディスクに保存され、奇数を付番されたブロックは 2 番目の物理ディスクに保存されます。

en: This level, also known as “RAID mirroring”, is both the simplest and the most widely used setup. In its standard form, it uses two physical disks of the same size, and provides a logical volume of the same size again. Data are stored identically on both disks, hence the “mirror” nickname. When one disk fails, the data is still available on the other. For really critical data, RAID-1 can of course be set up on more than two disks, with a direct impact on the ratio of hardware cost versus available payload space.
ja: RAID-1 は「RAID ミラーリング」としても知られ、最も簡単で最も広く使われています。RAID-1 の標準的な構成では、同じサイズの 2 台の物理ディスクを使い、物理ディスクと同じサイズの論理ボリュームが利用できるようになります。データを両方のディスクに保存するため、「ミラー」と呼ばれています。一方のディスクに障害があっても、他方のディスクからデータを利用することが可能です。もちろん、非常に重要なデータ用に RAID-1 を 2 台以上の構成にすることも可能ですが、これはハードウェア費用と利用できる保存領域の比率に直接的な影響をおよぼします。

en: <emphasis>NOTE</emphasis> Disks and cluster sizes
ja: <emphasis>NOTE</emphasis> ディスクとクラスタサイズ

en: If two disks of different sizes are set up in a mirror, the bigger one will not be fully used, since it will contain the same data as the smallest one and nothing more. The useful available space provided by a RAID-1 volume therefore matches the size of the smallest disk in the array. This still holds for RAID volumes with a higher RAID level, even though redundancy is stored differently.
ja: 異なるサイズの 2 台のディスクをミラーでセットアップする場合、サイズの大きい側のディスクは完全に利用されません。なぜなら、大きい側のディスクに含まれるデータは最も小さいディスクに含まれるデータと同じデータだからです。このため RAID-1 ボリュームで提供される利用できる領域のサイズは RAID アレイの最も小さなディスクのサイズと同じになります。冗長性を異なる方法で確保しているより高い RAID レベルの RAID ボリュームに対しても同じことが言えます。

en: It is therefore important, when setting up RAID arrays (except for RAID-0 and “linear RAID”), to only assemble disks of identical, or very close, sizes, to avoid wasting resources.
ja: それ故、(RAID-0 と「リニア RAID」以外の) RAID アレイをセットアップする場合、資源の無駄を防ぐためにアレイを構成するディスクはそのサイズが完全に同じか近いものを使うことが重要です。

en: <emphasis>NOTE</emphasis> Spare disks
ja: <emphasis>NOTE</emphasis> 予備ディスク

en: RAID levels that include redundancy allow assigning more disks than required to an array. The extra disks are used as spares when one of the main disks fails. For instance, in a mirror of two disks plus one spare, if one of the first two disks fails, the kernel will automatically (and immediately) reconstruct the mirror using the spare disk, so that redundancy stays assured after the reconstruction time. This can be used as another kind of safeguard for critical data.
ja: 冗長性を持たせた RAID レベルでは、必要なディスク数よりも多くのディスクで RAID アレイを構成させることが可能です。追加的ディスクは主要ディスクに障害が起きた場合に予備として使われます。たとえば、2 台のディスクと 1 台の予備ディスクのミラー構成では、最初の 2 台のうちの 1 台に障害が起きた場合、カーネルは自動的に (そして素早く) 予備ディスクを使ってミラーを再構成し、再構成の完了後に冗長性が再確保されます。すなわち、重要なデータに対するもう一つの安全装置として予備ディスクを使うことが可能ということです。

en: One would be forgiven for wondering how this is better than simply mirroring on three disks to start with. The advantage of the “spare disk” configuration is that the spare disk can be shared across several RAID volumes. For instance, one can have three mirrored volumes, with redundancy assured even in the event of one disk failure, with only seven disks (three pairs, plus one shared spare), instead of the nine disks that would be required by three triplets.
ja: この方式が単純に 3 台のディスクに対して最初からミラーリングを行うよりも優れているとされることに疑問を持つかもしれません。「予備ディスク」を設定する利点は複数の RAID ボリュームで予備ディスクを共有することが可能という点です。たとえば、1 台のディスク障害に対する冗長性を確保した 3 つのミラーされたボリュームを構成するには、ディスクを 7 台 (3 つのペアと 1 台の共有された予備) 用意するだけですみます。これに対して各ボリュームに 3 台のディスクを用意する場合には 9 台のディスクが必要です。

en: This RAID level, although expensive (since only half of the physical storage space, at best, is useful), is widely used in practice. It is simple to understand, and it allows very simple backups: since both disks have identical contents, one of them can be temporarily extracted with no impact on the working system. Read performance is often increased since the kernel can read half of the data on each disk in parallel, while write performance isn't too severely degraded. In case of a RAID-1 array of N disks, the data stays available even with N-1 disk failures.
ja: RAID-1 は高価であるにも関わらず (良くても物理ストレージ領域のたった半分しか使えないにも関わらず)、広く実運用されています。RAID-1 は簡単に理解でき、簡単にバックアップできます。なぜなら両方のディスクが全く同じ内容を持っているため、片方を一時的に取り外しても運用システムに影響をおよぼさないからです。通常 RAID-1 を使うことで、読み込み性能は好転します。なぜなら、カーネルはデータの半分をそれぞれのディスクから並行して読むことができるからです。これに対して、書き込み性能はそれほど悪化しません。N 台のディスクからなる RAID-1 アレイの場合、データは N-1 台のディスク障害に対して保護されます。

en: This RAID level, not widely used, uses N disks to store useful data, and an extra disk to store redundancy information. If that disk fails, the system can reconstruct its contents from the other N. If one of the N data disks fails, the remaining N-1 combined with the “parity” disk contain enough information to reconstruct the required data.
ja: RAID-4 は広く使われていません。RAID-4 は実データを保存するために N 台のディスクを使い、冗長性情報を保存するために 1 台の「パリティ」ディスクを使います。「パリティ」ディスクに障害が起きた場合、システムは他の N 台からデータを再構成することが可能です。N 台のデータディスクのうち、最大で 1 台に障害が起きた場合、残りの N-1 台と「パリティ」ディスクには、要求されたデータを再構成するために十分な情報が含まれます。

en: RAID-4 isn't too expensive since it only involves a one-in-N increase in costs and has no noticeable impact on read performance, but writes are slowed down. Furthermore, since a write to any of the N disks also involves a write to the parity disk, the latter sees many more writes than the former, and its lifespan can shorten dramatically as a consequence. Data on a RAID-4 array is safe only up to one failed disk (of the N+1).
ja: RAID-4 は高価過ぎるというわけではありません。なぜならディスク 1 台につきたった N 分の 1 台分の追加費用で済むからです。また RAID-4 を使うと読み込み性能が大きく低下するというわけでもありません。しかしながら、RAID-4 は書き込み性能に深刻な影響をおよぼします。加えて、N 台の実データ用ディスクのどのディスクに書き込んでもパリティディスクに対する書き込みが発生するので、パリティディスクは実データ用ディスクに比べて書き込み回数が増えます。その結果、パリティディスクは極めて寿命が短くなります。RAID-4 アレイのデータは (N+1 台のディスクのうち) 1 台の障害に対して保護されます。

en: RAID-5 addresses the asymmetry issue of RAID-4: parity blocks are spread over all of the N+1 disks, with no single disk having a particular role.
ja: RAID-5 は RAID-4 の非対称性問題を対処したものです。すなわち、パリティブロックは N+1 台のディスクに分散して保存され、特定のディスクが特定の役割を果たすことはありません。

en: Read and write performance are identical to RAID-4. Here again, the system stays functional with up to one failed disk (of the N+1), but no more.
ja: 読み込みと書き込み性能は RAID-4 と同様です。繰り返しになりますが、RAID-5 システムは (N+1 台のディスクのうち) 最大で 1 台までに障害が起きても動作します。

en: RAID-6 can be considered an extension of RAID-5, where each series of N blocks involves two redundancy blocks, and each such series of N+2 blocks is spread over N+2 disks.
ja: RAID-6 は RAID-5 の拡張と考えられます。RAID-6 では、N 個の連続するブロックに対して 2 個の冗長性ブロックを使います。この N+2 個のブロックは N+2 台のディスクに分散して保存されます。

en: This RAID level is slightly more expensive than the previous two, but it brings some extra safety since up to two drives (of the N+2) can fail without compromising data availability. The counterpart is that write operations now involve writing one data block and two redundancy blocks, which makes them even slower.
ja: RAID-6 は RAID-4 と RAID-5 に比べて少し高価ですが、RAID-6 を使うことで安全性はさらに高まります。なぜなら、(N+2 台中の) 最大で 2 台までの障害に対してデータを守ることが可能だからです。書き込み操作は 1 つのデータブロックと 2 つの冗長性ブロックを書き込むことに対応しますから、RAID-6 の書き込み性能は RAID-4 と RAID-5 に比べてさらに悪化します。

en: RAID-1+0 can survive multiple disk failures: up to N in the 2×N array described above, provided that at least one disk keeps working in each of the RAID-1 pairs.
ja: RAID-1+0 は複数のディスク障害を乗り切ることが可能です。具体的に言えば、上に挙げた 2×N アレイの場合、最大で N 台までの障害に耐えます。ただし、各 RAID-1 ペアを構成するディスクの両方に障害が発生してはいけません。

en: RAID-10 is generally considered a synonym of RAID-1+0, but a Linux specificity makes it actually a generalization. This setup allows a system where each block is stored on two different disks, even with an odd number of disks, the copies being spread out along a configurable model.
ja: 通常 RAID-10 は RAID-1+0 の同意語と考えられますが、Linux では特別に RAID-10 をより一般的な構成を可能にするものとして定めています。RAID-10 では、システムが各ブロックを 2 種類の異なるディスクに保存することが可能です。奇数台のディスク構成の場合でも、ブロックのコピーは設定可能なモデルに従って分散して保存されます。

en: Performances will vary depending on the chosen repartition model and redundancy level, and of the workload of the logical volume.
ja: RAID-10 の性能は選択した再分割モデルと冗長性の度合い、そして論理ボリュームの作業負荷に依存して変化します。

en: Obviously, the RAID level will be chosen according to the constraints and requirements of each application. Note that a single computer can have several distinct RAID arrays with different configurations.
ja: RAID レベルを選ぶ際には、各用途からの制限および要求を考慮する必要があるのは明らかです。1 台のコンピュータに異なる設定を持つ複数の RAID アレイを配置することが可能である点に注意してください。

en: Setting up RAID
ja: RAID の設定

en: Setting up RAID volumes requires the <emphasis role="pkg">mdadm</emphasis> package; it provides the <command>mdadm</command> command, which allows creating and manipulating RAID arrays, as well as scripts and tools integrating it to the rest of the system, including the monitoring system.
ja: RAID ボリュームを設定するには <emphasis role="pkg">mdadm</emphasis> パッケージが必要です。<emphasis role="pkg">mdadm</emphasis> パッケージには RAID アレイを作成したり操作するための <command>mdadm</command> コマンド、システムの他の部分に RAID アレイを統合するためのスクリプトやツール、監視システムが含まれます。

en: Our example will be a server with a number of disks, some of which are already used, the rest being available to setup RAID. We initially have the following disks and partitions:
ja: 以下の例では、多数のディスクを持つサーバをセットアップします。ディスクの一部は既に利用されており、残りは RAID をセットアップするために利用できるようになっています。最初の状態で、以下のディスクとパーティションが存在します。

en: the <filename>sdb</filename> disk, 4 GB, is entirely available;
ja: <filename>sdb</filename> ディスク (4 GB) は全領域を利用できます。

en: the <filename>sdc</filename> disk, 4 GB, is also entirely available;
ja: <filename>sdc</filename> ディスク (4 GB) は全領域を利用できます。

en: on the <filename>sdd</filename> disk, only partition <filename>sdd2</filename> (about 4 GB) is available;
ja: <filename>sdd</filename> ディスクは <filename>sdd2</filename> パーティション (約 4 GB) だけを利用できます。

en: finally, a <filename>sde</filename> disk, still 4 GB, entirely available.
ja: <filename>sde</filename> ディスク (4 GB) は全領域を利用できます。

en: <emphasis>NOTE</emphasis> Identifying existing RAID volumes
ja: <emphasis>NOTE</emphasis> 既存の RAID ボリュームの識別

en: The <filename>/proc/mdstat</filename> file lists existing volumes and their states. When creating a new RAID volume, care should be taken not to name it the same as an existing volume.
ja: <filename>/proc/mdstat</filename> ファイルには既存のボリュームとその状態が書かれています。新しい RAID ボリュームを作成する場合、既存のボリュームと同じ名前を付けないように注意してください。

en: We're going to use these physical elements to build two volumes, one RAID-0 and one mirror (RAID-1). Let's start with the RAID-0 volume:
ja: RAID-0 とミラー (RAID-1) の 2 つのボリュームを作るために上記の物理ディスクを使います。それでは RAID-0 ボリュームから作っていきましょう。

en: Creation of a RAID-1 follows a similar fashion, the differences only being noticeable after the creation:
ja: 同様のやり方で RAID-1 を作成します。注意するべき違いは作成後に説明します。

en: <emphasis>TIP</emphasis> RAID, disks and partitions
ja: <emphasis>TIP</emphasis> RAID、ディスク、パーティション

en: A few remarks are in order. First, <command>mdadm</command> notices that the physical elements have different sizes; since this implies that some space will be lost on the bigger element, a confirmation is required.
ja: いくつかの注意点があります。最初に、<command>mdadm</command> は物理デバイス同士のサイズが異なる点を指摘しています。さらに、このことによりサイズが大きい側のデバイスの一部の領域が使えなくなるため、確認が求められています。

en: More importantly, note the state of the mirror. The normal state of a RAID mirror is that both disks have exactly the same contents. However, nothing guarantees this is the case when the volume is first created. The RAID subsystem will therefore provide that guarantee itself, and there will be a synchronization phase as soon as the RAID device is created. After some time (the exact amount will depend on the actual size of the disks…), the RAID array switches to the “active” or “clean” state. Note that during this reconstruction phase, the mirror is in a degraded mode, and redundancy isn't assured. A disk failing during that risk window could lead to losing all the data. Large amounts of critical data, however, are rarely stored on a freshly created RAID array before its initial synchronization. Note that even in degraded mode, the <filename>/dev/md1</filename> is usable, and a filesystem can be created on it, as well as some data copied on it.
ja: さらに重要なことは、ミラーの状態に注意することです。RAID ミラーの正常な状態とは、両方のディスクが全く同じ内容を持っている状態です。しかしながら、ボリュームを最初に作成した直後の RAID ミラーは正常な状態であることを保証されません。このため、RAID サブシステムは RAID ミラーの正常な状態を保証するために、RAID デバイスが作成されたらすぐに同期化作業を始めます。しばらくの後 (必要な時間はディスクの実サイズに依存します)、RAID アレイは「active」または「clean」状態に移行します。同期化作業中、ミラーは信頼性低下状態で、冗長性は保証されない点に注意してください。同期化作業中にディスク障害が起きると、すべてのデータを失うことにつながる恐れがあります。しかしながら、最近作成された RAID アレイの最初の同期化作業の前に大量の重要なデータがこの RAID アレイに保存されていることはほとんどないでしょう。信頼性低下状態であっても <filename>/dev/md1</filename> を利用することが可能で、ファイルシステムを作成したり、データのコピーを取ったりすることが可能という点に注意してください。

en: <emphasis>TIP</emphasis> Starting a mirror in degraded mode
ja: <emphasis>TIP</emphasis> 信頼性低下状態でミラーを開始する

en: Sometimes two disks are not immediately available when one wants to start a RAID-1 mirror, for instance because one of the disks one plans to include is already used to store the data one wants to move to the array. In such circumstances, it is possible to deliberately create a degraded RAID-1 array by passing <filename>missing</filename> instead of a device file as one of the arguments to <command>mdadm</command>. Once the data have been copied to the “mirror”, the old disk can be added to the array. A synchronization will then take place, giving us the redundancy that was wanted in the first place.
ja: RAID-1 ミラーを構成する 2 台のディスクの両方をすぐに使えないことが時々あります。たとえば、ミラーを構成するディスクの片方にミラーに移動したいデータが既に保存されている場合です。このような場合、<command>mdadm</command> に渡すデバイスファイル引数の片方をデバイスファイルの代わりに <filename>missing</filename> にすることで、意図的に信頼性低下状態の RAID-1 アレイを作成することも可能です。ミラーに移動したいデータを含むディスクからデータを「ミラー」にコピーした後、そのディスクをアレイに追加することが可能です。追加作業が終われば、同期化作業が行われ、ミラーに移動したかったデータの冗長性が確保されます。

en: <emphasis>TIP</emphasis> Setting up a mirror without synchronization
ja: <emphasis>TIP</emphasis> 同期化作業を行わずにミラーをセットアップする

en: RAID-1 volumes are often created to be used as a new disk, often considered blank. The actual initial contents of the disk is therefore not very relevant, since one only needs to know that the data written after the creation of the volume, in particular the filesystem, can be accessed later.
ja: 通常 RAID-1 ボリュームは新しいディスクとして使うために作成され、RAID-1 ボリュームの作成直後にはデータが保存されていないと考えられます。すなわち、RAID-1 ボリュームの初期内容に価値はなく、RAID-1 で保護したい重要なデータは RAID-1 ボリュームの作成後に書き込まれるデータというわけです。

en: One might therefore wonder about the point of synchronizing both disks at creation time. Why care whether the contents are identical on zones of the volume that we know will only be read after we have written to them?
ja: そう考えると、RAID-1 ボリュームにデータが書き込まれる前に RAID-1 ボリュームを構成するディスクの内容が同期されるという点について疑問に思うかもしれません。RAID-1 ボリュームに書き込んでいないデータは後から読み込まれることもないのにも関わらず、なぜ RAID-1 ボリュームの作成時に RAID-1 ボリュームを構成するディスクの内容の同期化作業が必要なのでしょうか?

en: Fortunately, this synchronization phase can be avoided by passing the <literal>--assume-clean</literal> option to <command>mdadm</command>. However, this option can lead to surprises in cases where the initial data will be read (for instance if a filesystem is already present on the physical disks), which is why it isn't enabled by default.
ja: 幸いなことに、RAID-1 を構成するディスクの内容の同期化作業は <literal>--assume-clean</literal> オプションを <command>mdadm</command> に渡せば避けることが可能です。しかしながら、初期データが読まれる場合、<literal>--assume-clean</literal> オプションを使うと問題があります (たとえば、物理ディスク上にファイルシステムが既に存在している場合、問題があります)。このため、デフォルトでこのオプションは有効化されません。

en: Now let's see what happens when one of the elements of the RAID-1 array fails. <command>mdadm</command>, in particular its <literal>--fail</literal> option, allows simulating such a disk failure:
ja: RAID-1 アレイを構成するディスクの 1 台に障害が発生した場合、何が起きるかを見て行きましょう。<command>mdadm</command> に <literal>--fail</literal> オプションを付けることで、ディスク障害を模倣することが可能です。

en: The contents of the volume are still accessible (and, if it is mounted, the applications don't notice a thing), but the data safety isn't assured anymore: should the <filename>sdd</filename> disk fail in turn, the data would be lost. We want to avoid that risk, so we'll replace the failed disk with a new one, <filename>sdf</filename>:
ja: RAID-1 ボリュームの内容はまだアクセスすることが可能ですが (そして、RAID-1 ボリュームがマウントされていた場合、アプリケーションはディスク障害に気が付きませんが)、データの安全性はもはや保証されません。つまり <filename>sdd</filename> ディスクにも障害が発生した場合、データは失われます。この危険性を避けるために、障害の発生したディスクを新しいディスク <filename>sdf</filename> に交換します。

en: Here again, the kernel automatically triggers a reconstruction phase during which the volume, although still accessible, is in a degraded mode. Once the reconstruction is over, the RAID array is back to a normal state. One can then tell the system that the <filename>sde</filename> disk is about to be removed from the array, so as to end up with a classical RAID mirror on two disks:
ja: 繰り返しになりますが、ボリュームはまだアクセスすることが可能とは言うもののボリュームが信頼性低下状態ならば、カーネルは自動的に再構成作業を実行します。再構成作業が終了したら、RAID アレイは正常状態に戻ります。ここで、システムに <filename>sde</filename> ディスクをアレイから削除することを伝えることが可能です。削除することで、2 台のディスクからなる古典的な RAID ミラーになります。

en: From then on, the drive can be physically removed when the server is next switched off, or even hot-removed when the hardware configuration allows hot-swap. Such configurations include some SCSI controllers, most SATA disks, and external drives operating on USB or Firewire.
ja: この後、今後サーバの電源を切った際にドライブを物理的に取り外したり、ハードウェア設定がホットスワップに対応しているならばドライブをホットリムーブすることが可能です。一部の SCSI コントローラ、多くの SATA ディスク、USB や Firewire で接続された外部ドライブなどはホットスワップに対応しています。

en: Backing up the Configuration
ja: 設定のバックアップ

en: Backing up the configuration is therefore important, if only for reference. The standard way to do it is by editing the <filename>/etc/mdadm/mdadm.conf</filename> file, an example of which is listed here:
ja: このため、参考情報に過ぎないとは言うものの、設定を保存することは重要です。設定を保存する標準的な方法は <filename>/etc/mdadm/mdadm.conf</filename> ファイルを編集することです。以下に例を示します。

en: <command>mdadm</command> configuration file
ja: <command>mdadm</command> 設定ファイル

en: One of the most useful details is the <literal>DEVICE</literal> option, which lists the devices where the system will automatically look for components of RAID volumes at start-up time. In our example, we replaced the default value, <literal>partitions containers</literal>, with an explicit list of device files, since we chose to use entire disks and not only partitions, for some volumes.
ja: 最も役に立つ設定項目の 1 つに <literal>DEVICE</literal> オプションがあります。これは起動時にシステムが RAID ボリュームの構成情報を自動的に探すデバイスをリストします。上の例では、値をデフォルト値 <literal>partitions containers</literal> からデバイスファイルを明示したリストに置き換えました。なぜなら、パーティションだけでなくすべてのディスクをボリュームとして使うように決めたからです。

en: The last two lines in our example are those allowing the kernel to safely pick which volume number to assign to which array. The metadata stored on the disks themselves are enough to re-assemble the volumes, but not to determine the volume number (and the matching <filename>/dev/md*</filename> device name).
ja: 上の例における最後の 2 行を使うことで、カーネルはアレイに割り当てるボリューム番号を安全に選ぶことが可能です。ディスク本体に保存されたメタ情報はボリュームをもう一度組み上げるのに十分ですが、ボリューム番号を定義する (そして <filename>/dev/md*</filename> デバイス名にマッチすることを確認する) には不十分です。

en: Fortunately, these lines can be generated automatically:
ja: 幸いなことに、以下のコマンドを実行すればこの行を自動的に生成することが可能です。

en: The contents of these last two lines doesn't depend on the list of disks included in the volume. It is therefore not necessary to regenerate these lines when replacing a failed disk with a new one. On the other hand, care must be taken to update the file when creating or deleting a RAID array.
ja: 最後の 2 行の内容はボリュームを構成するディスクのリストに依存しません。このため、障害の発生したディスクを新しいディスクに交換した際に、これをもう一度生成する必要はありません。逆に、RAID アレイを作成および削除した際に、必ずこの設定ファイルを注意深く更新する必要があります。

en: LVM, the <emphasis>Logical Volume Manager</emphasis>, is another approach to abstracting logical volumes from their physical supports, which focuses on increasing flexibility rather than increasing reliability. LVM allows changing a logical volume transparently as far as the applications are concerned; for instance, it is possible to add new disks, migrate the data to them, and remove the old disks, without unmounting the volume.
ja: LVM (<emphasis>論理ボリュームマネージャ</emphasis>) は物理ディスクから論理ボリュームを抽象化するもう一つの方法で、信頼性を増加させるのではなく柔軟性を増加させることに注目しています。LVM を使うことで、アプリケーションから見る限り透過的に論理ボリュームを変更することが可能です。LVM を使うことで、たとえば新しいディスクを追加し、データを新しいディスクに移行し、古いディスクを削除することがボリュームをアンマウントせずに可能です。

en: LVM Concepts
ja: LVM の概念

en: This flexibility is attained by a level of abstraction involving three concepts.
ja: LVM の柔軟性は 3 つの概念から構成された抽象化レベルによって達成されます。

en: First, the PV (<emphasis>Physical Volume</emphasis>) is the entity closest to the hardware: it can be partitions on a disk, or a full disk, or even any other block device (including, for instance, a RAID array). Note that when a physical element is set up to be a PV for LVM, it should only be accessed via LVM, otherwise the system will get confused.
ja: 1 番目の概念は PV (<emphasis>物理ボリューム</emphasis>) です。PV はハードウェアに最も近い要素です。具体的に言えば、PV はディスクのパーティション、ディスク全体、その他の任意のブロックデバイス (たとえば、RAID アレイ) などの物理的要素を指します。物理的要素を LVM の PV に設定した場合、物理的要素へのアクセスは必ず LVM を介すべきという点に注意してください。そうでなければ、システムが混乱します。

en: The third kind of object is the LV (<emphasis>Logical Volume</emphasis>), which is a chunk of a VG; if we keep the VG-as-disk analogy, the LV compares to a partition. The LV appears as a block device with an entry in <filename>/dev</filename>, and it can be used as any other physical partition can be (most commonly, to host a filesystem or swap space).
ja: 3 番目の概念は LV (<emphasis>論理ボリューム</emphasis>) です。LV は VG の中の 1 つの塊です。さらに VG をディスクに例えたのと同様の考え方を使うと、LV はパーティションに例えられます。LV はブロックデバイスとして <filename>/dev</filename> に現れ、他の物理パーティションと同様に取り扱うことが可能です (一般的に言えば、LV にファイルシステムやスワップ領域を作成することが可能です)。

en: The important thing is that the splitting of a VG into LVs is entirely independent of its physical components (the PVs). A VG with only a single physical component (a disk for instance) can be split into a dozen logical volumes; similarly, a VG can use several physical disks and appear as a single large logical volume. The only constraint, obviously, is that the total size allocated to LVs can't be bigger than the total capacity of the PVs in the volume group.
ja: ここで重要な事柄は VG を LV に分割する場合に物理的要素 (PV) はいかなる制約も要求しないという点です。1 つの PV (たとえばディスク) から構成される VG を複数の LV に分割できます。同様に、複数の PV から構成される VG を 1 つの大きな LV として提供することも可能です。制約事項がたった 1 つしかないのは明らかです。それはある VG から分割された LV のサイズの合計はその VG を構成する PV のサイズの合計を超えることができないという点です。

en: It often makes sense, however, to have some kind of homogeneity among the physical components of a VG, and to split the VG into logical volumes that will have similar usage patterns. For instance, if the available hardware includes fast disks and slower disks, the fast ones could be clustered into one VG and the slower ones into another; chunks of the first one can then be assigned to applications requiring fast data access, while the second one will be kept for less demanding tasks.
ja: しかしながら、ある VG を構成する PV 同士の性能を同様のものにしたり、その VG から分割された LV 同士に求められる性能を同様のものにしたりすることは通常理に適った方針です。たとえば、利用できるハードウェアに高速な PV と低速な PV がある場合、高速な PV から構成される VG と低速な PV から構成される VG に分けると良いでしょう。こうすることで、高速な PV から構成される VG から分割された LV を高速なデータアクセスを必要とするアプリケーションに割り当て、低速な PV から構成される VG から分割された LV を負荷の少ない作業用に割り当てることが可能です。

en: In any case, keep in mind that an LV isn't particularly attached to any one PV. It is possible to influence where the data from an LV are physically stored, but this possibility isn't required for day-to-day use. On the contrary: when the set of physical components of a VG evolves, the physical storage locations corresponding to a particular LV can be migrated across disks (while staying within the PVs assigned to the VG, of course).
ja: いかなる場合でも、LV は特定の PV を使用するわけではないという点を覚えておいてください。ある LV に含まれるデータの物理的な保存場所を操作することも可能ですが、普通に使っている限りその必要はありません。逆に、VG を構成する PV 群の構成要素が変化した場合、ある LV に含まれるデータの物理的な保存場所は対象の LV の分割元である VG の中ひいてはその VG を構成する PV 群の構成要素の中を移動することがあります (もちろん、データの移動先は対象の LV の分割元の VG を構成する PV 群の構成要素の中に限られます)。

en: Setting up LVM
ja: LVM の設定

en: Let us now follow, step by step, the process of setting up LVM for a typical use case: we want to simplify a complex storage situation. Such a situation usually happens after some long and convoluted history of accumulated temporary measures. For the purposes of illustration, we'll consider a server where the storage needs have changed over time, ending up in a maze of available partitions split over several partially used disks. In more concrete terms, the following partitions are available:
ja: 典型的な用途に対する LVM の設定過程を、段階的に見て行きましょう。具体的に言えば、複雑なストレージの状況を単純化したい場合を見ていきます。通常、長く複雑な一時的措置を繰り返した挙句の果てに、この状況に陥ることがあります。説明目的で、徐々にストレージを変更する必要のあったサーバを考えます。このサーバでは、PV として利用できるパーティションが複数の一部使用済みディスクに分散しています。より具体的に言えば、以下のパーティションを PV として利用できます。

en: on the <filename>sdb</filename> disk, a <filename>sdb2</filename> partition, 4 GB;
ja: <filename>sdb</filename> ディスク上の <filename>sdb2</filename> パーティション (4 GB)。

en: on the <filename>sdc</filename> disk, a <filename>sdc3</filename> partition, 3 GB;
ja: <filename>sdc</filename> ディスク上の <filename>sdc3</filename> パーティション (3 GB)。

en: the <filename>sdd</filename> disk, 4 GB, is fully available;
ja: <filename>sdd</filename> ディスク (4 GB) は全領域を利用できます。

en: on the <filename>sdf</filename> disk, a <filename>sdf1</filename> partition, 4 GB; and a <filename>sdf2</filename> partition, 5 GB.
ja: <filename>sdf</filename> ディスク上の <filename>sdf1</filename> パーティション (4 GB) および <filename>sdf2</filename> パーティション (5 GB)。

en: In addition, let's assume that disks <filename>sdb</filename> and <filename>sdf</filename> are faster than the other two.
ja: 加えて、<filename>sdb</filename> と <filename>sdf</filename> が他の 2 台に比べて高速であると仮定しましょう。

en: Our goal is to set up three logical volumes for three different applications: a file server requiring 5 GB of storage space, a database (1 GB) and some space for back-ups (12 GB). The first two need good performance, but back-ups are less critical in terms of access speed. All these constraints prevent the use of partitions on their own; using LVM can abstract the physical size of the devices, so the only limit is the total available space.
ja: 今回の目標は、3 種類の異なるアプリケーション用に 3 つの LV を設定することです。具体的に言えば、5 GB のストレージ領域が必要なファイルサーバ、データベース (1 GB)、バックアップ用の領域 (12 GB) 用の LV を設定することです。ファイルサーバとデータベースは高い性能を必要とします。しかし、バックアップはアクセス速度をそれほど重要視しません。これらの要件により、各アプリケーションに設定する LV の使用する PV が決定されます。さらに LVM を使いますので、PV の物理的サイズからくる制限はありません。このため、PV 群として利用できる領域のサイズの合計だけが制限となります。

en: The required tools are in the <emphasis role="pkg">lvm2</emphasis> package and its dependencies. When they're installed, setting up LVM takes three steps, matching the three levels of concepts.
ja: LVM の設定に必要なツールは <emphasis role="pkg">lvm2</emphasis> パッケージとその依存パッケージに含まれています。これらのパッケージをインストールしたら、3 つの手順を踏んで LVM を設定します。各手順は LVM の概念の 3 つの抽象化レベルに対応します。

en: First, we prepare the physical volumes using <command>pvcreate</command>:
ja: 最初に、<command>pvcreate</command> を使って PV を作成します。

en: So far, so good; note that a PV can be set up on a full disk as well as on individual partitions of it. As shown above, the <command>pvdisplay</command> command lists the existing PVs, with two possible output formats.
ja: ここまでは順調です。PV はディスク全体およびディスク上の各パーティションに対して設定することが可能という点に注意してください。上に示した通り、<command>pvdisplay</command> コマンドは既存の PV をリストします。出力フォーマットは 2 種類あります。

en: Now let's assemble these physical elements into VGs using <command>vgcreate</command>. We'll gather only PVs from the fast disks into a <filename>vg_critical</filename> VG; the other VG, <filename>vg_normal</filename>, will also include slower elements.
ja: <command>vgcreate</command> を使って、これらの PV から VG を構成しましょう。高速なディスクの PV から <filename>vg_critical</filename> VG を構成します。さらに、これ以外の低速なディスクの PV から <filename>vg_normal</filename> VG を構成します。

en: Here again, commands are rather straightforward (and <command>vgdisplay</command> proposes two output formats). Note that it is quite possible to use two partitions of the same physical disk into two different VGs. Note also that we used a <filename>vg_</filename> prefix to name our VGs, but it is nothing more than a convention.
ja: 繰り返しになりますが、<command>vgdisplay</command> コマンドはかなり簡潔です (そして <command>vgdisplay</command> には 2 種類の出力フォーマットがあります)。同じ物理ディスク上にある 2 つの PV から 2 つの異なる VG を構成することが可能である点に注意してください。また、<filename>vg_</filename> 接頭辞を VG の名前に使っていますが、これは慣例に過ぎない点に注意してください。

en: Two parameters are required when creating logical volumes; they must be passed to the <command>lvcreate</command> as options. The name of the LV to be created is specified with the <literal>-n</literal> option, and its size is generally given using the <literal>-L</literal> option. We also need to tell the command what VG to operate on, of course, hence the last parameter on the command line.
ja: LV を作成する場合、2 種類のパラメータが必要です。このため、必ず 2 種類のパラメータをオプションとして <command>lvcreate</command> に渡します。作成する LV の名前を <literal>-n</literal> オプションで指定し、サイズを <literal>-L</literal> オプションで指定します。また、操作対象の VG をコマンドに伝えることが必要です。これはもちろん最後のコマンドラインパラメータです。

en: <emphasis>GOING FURTHER</emphasis> <command>lvcreate</command> options
ja: <emphasis>GOING FURTHER</emphasis> <command>lvcreate</command> のオプション

en: The <command>lvcreate</command> command has several options to allow tweaking how the LV is created.
ja: <command>lvcreate</command> コマンドは複数のオプションを取り、作成する LV を微調整することが可能です。

en: Let's first describe the <literal>-l</literal> option, with which the LV's size can be given as a number of blocks (as opposed to the “human” units we used above). These blocks (called PEs, <emphasis>physical extents</emphasis>, in LVM terms) are contiguous units of storage space in PVs, and they can't be split across LVs. When one wants to define storage space for an LV with some precision, for instance to use the full available space, the <literal>-l</literal> option will probably be preferred over <literal>-L</literal>.
ja: 最初に <literal>-l</literal> オプションについて説明しましょう。<literal>-l</literal> オプションを使った場合 LV のサイズをブロック数 (上の例で用いた「人間にとって分かりやすい」単位ではありません) で指定することが可能です。ブロックとは (LVM の用語で PE すなわち<emphasis>物理エクステント</emphasis>と呼ばれています) PV 中のストレージ領域の連続した単位です。ブロックは LV 中に分散されています。ある LV 用のストレージ領域を正確に定義したい場合、たとえば利用できる領域のすべてを使いたい場合、<literal>-l</literal> オプションのほうが <literal>-L</literal> オプションよりも使いやすいでしょう。

en: Logical volumes, once created, end up as block device files in <filename>/dev/mapper/</filename>:
ja: LV が作成され、ブロックデバイスファイルとして <filename>/dev/mapper/</filename> に現れます。

en: When the computer boots, the <filename>lvm2-activation</filename> systemd service unit executes <command>vgchange -aay</command> to “activate” the volume groups: it scans the available devices; those that have been initialized as physical volumes for LVM are registered into the LVM subsystem, those that belong to volume groups are assembled, and the relevant logical volumes are started and made available. There is therefore no need to edit configuration files when creating or modifying LVM volumes.
ja: コンピュータの起動時に、<filename>lvm2-activation</filename> systemd サービスユニットは <command>vgchange -aay</command> を実行して VG を「始動」します。具体的に言えば、<filename>lvm2-activation</filename> systemd サービスユニットは利用できるデバイスを探します。そして LVM サブシステムに LVM 用の PV として初期化されたデバイスが登録され、PV から構成される VG が開始され、VG から分割された LV が開始され、LV が利用できるようになります。このため、LVM ボリュームを作成したり変更する際に設定ファイルを編集する必要はありません。

en: Note, however, that the layout of the LVM elements (physical and logical volumes, and volume groups) is backed up in <filename>/etc/lvm/backup</filename>, which can be useful in case of a problem (or just to sneak a peek under the hood).
ja: しかしながら、LVM 要素 (PV、LV、GV) の配置図は <filename>/etc/lvm/backup</filename> にバックアップされ、問題が起きた時 (見えないところで何が行われているかを確認したい時) に有益です。

en: To make things easier, convenience symbolic links are also created in directories matching the VGs:
ja: ブロックデバイスファイルを分かり易くするために、VG に対応するディレクトリの中に便利なシンボリックリンクが作成されます。

en: The LVs can then be used exactly like standard partitions:
ja: LV は標準的なパーティションと全く同様に取り扱われます。

en: From the applications' point of view, the myriad small partitions have now been abstracted into one large 12 GB volume, with a friendlier name.
ja: アプリケーションにしてみれば、無数の小さなパーティションがわかり易い名前を持つ 1 つの大きな 12 GB のボリュームにまとめられたことになります。

en: LVM Over Time
ja: 経時変化に伴う LVM の利便性

en: Even though the ability to aggregate partitions or physical disks is convenient, this is not the main advantage brought by LVM. The flexibility it brings is especially noticed as time passes, when needs evolve. In our example, let's assume that new large files must be stored, and that the LV dedicated to the file server is too small to contain them. Since we haven't used the whole space available in <filename>vg_critical</filename>, we can grow <filename>lv_files</filename>. For that purpose, we'll use the <command>lvresize</command> command, then <command>resize2fs</command> to adapt the filesystem accordingly:
ja: LVM のパーティションや物理ディスクを統合する機能は便利ですが、これは LVM のもたらす主たる利点ではありません。時間経過に伴い LVM のもたらす柔軟性が特に重要になる時とは LV のサイズを増加させる必要が生じた時でしょう。ここまでの例を使い、LV に新たに巨大なファイルを保存したいけれども、ファイルサーバ用の LV はこの巨大なファイルを保存するには狭すぎると仮定しましょう。<filename>vg_critical</filename> から分割できる全領域はまだ使い切られていないので、<filename>lv_files</filename> のサイズを増やすことが可能です。LV のサイズを増やすために <command>lvresize</command> コマンドを使い、LV のサイズの変化にファイルシステムを対応させるために <command>resize2fs</command> を使います。

en: <emphasis>CAUTION</emphasis> Resizing filesystems
ja: <emphasis>CAUTION</emphasis> ファイルシステムのサイズ変更

en: The ext3, ext4 and xfs filesystems can be grown online, without unmounting; shrinking requires an unmount. The reiserfs filesystem allows online resizing in both directions. The venerable ext2 allows neither, and always requires unmounting.
ja: ext3、ext4、xfs ファイルシステムはオンラインでサイズを増加させることすなわちアンマウントすることなくサイズを増加させることが可能です。しかし、サイズを減少させる場合はアンマウントを必要とします。reiserfs はオンラインでサイズを増加および減少することが可能です。ext2 は増加も減少も可能ですが、アンマウントを必要とします。

en: We could proceed in a similar fashion to extend the volume hosting the database, only we've reached the VG's available space limit:
ja: 同様の方法でデータベースをホストしている <filename>lv_base</filename> のサイズを増加させます。以下の通り <filename>lv_base</filename> の分割元である <filename>vg_critical</filename> から分割できる領域は既にほぼ使い切った状態になっています。

en: <emphasis>GOING FURTHER</emphasis> Advanced LVM
ja: <emphasis>GOING FURTHER</emphasis> LVM の上級活用

en: RAID or LVM?
ja: RAID それとも LVM?

en: RAID and LVM both bring indisputable advantages as soon as one leaves the simple case of a desktop computer with a single hard disk where the usage pattern doesn't change over time. However, RAID and LVM go in two different directions, with diverging goals, and it is legitimate to wonder which one should be adopted. The most appropriate answer will of course depend on current and foreseeable requirements.
ja: 1 番目の利用形態は用途が時間的に変化しない 1 台のハードディスクを備えたデスクトップコンピュータのような単純な利用形態です。この場合 RAID と LVM はどちらも疑う余地のない利点をもたらします。しかしながら、RAID と LVM は目標を分岐させて別々の道を歩んでいます。どちらを使うべきか悩むのは間違っていることではありません。最も適切な答えはもちろん現在の要求と将来に予測される要求に依存します。

en: There are a few simple cases where the question doesn't really arise. If the requirement is to safeguard data against hardware failures, then obviously RAID will be set up on a redundant array of disks, since LVM doesn't really address this problem. If, on the other hand, the need is for a flexible storage scheme where the volumes are made independent of the physical layout of the disks, RAID doesn't help much and LVM will be the natural choice.
ja: いくつかの状況では、疑問の余地がないくらい簡単に答えを出すことが可能です。2 番目の利用形態はハードウェア障害からデータを保護することが求められる利用形態です。この場合、ディスクの冗長性アレイ上に RAID をセットアップするのは明らかです。なぜなら LVM はこの種の問題への対応策を全く用意していないからです。逆に、柔軟なストレージ計画が必要でディスクの物理的な配置に依存せずにボリュームを構成したい場合、RAID はあまり役に立たず LVM を選ぶのが自然です。

en: <emphasis>NOTE</emphasis> If performance matters…
ja: <emphasis>NOTE</emphasis> 性能が重要な場合

en: The third notable use case is when one just wants to aggregate two disks into one volume, either for performance reasons or to have a single filesystem that is larger than any of the available disks. This case can be addressed both by a RAID-0 (or even linear-RAID) and by an LVM volume. When in this situation, and barring extra constraints (for instance, keeping in line with the rest of the computers if they only use RAID), the configuration of choice will often be LVM. The initial set up is barely more complex, and that slight increase in complexity more than makes up for the extra flexibility that LVM brings if the requirements change or if new disks need to be added.
ja: 3 番目に注目すべき利用形態は単に 2 つのディスクを 1 つのボリュームにまとめるような利用形態です。性能が欲しかったり、利用できるディスクのどれよりも大きな単一のファイルシステムにしたい場合にこの利用形態が採用されます。この場合、RAID-0 (またはリニア RAID) か LVM ボリュームを使って対処できます。この状況では、追加的な制約事項 (たとえば、他のコンピュータが RAID だけを使っている場合に RAID を使わなければいけないなどの制約事項) がなければ、通常 LVM を選択すると良いでしょう。LVM の最初のセットアップは RAID に比べて複雑ですが、LVM は複雑度を少し増加させるだけで要求が変った場合や新しいディスクを追加する必要ができた場合に対処可能な追加的な柔軟性を大きく上昇させます。

en: Then of course, there is the really interesting use case, where the storage system needs to be made both resistant to hardware failure and flexible when it comes to volume allocation. Neither RAID nor LVM can address both requirements on their own; no matter, this is where we use both at the same time — or rather, one on top of the other. The scheme that has all but become a standard since RAID and LVM have reached maturity is to ensure data redundancy first by grouping disks in a small number of large RAID arrays, and to use these RAID arrays as LVM physical volumes; logical partitions will then be carved from these LVs for filesystems. The selling point of this setup is that when a disk fails, only a small number of RAID arrays will need to be reconstructed, thereby limiting the time spent by the administrator for recovery.
ja: そしてもちろん、最後の本当に興味深い利用形態はストレージシステムにハードウェア障害に対する耐性を持たせさらにボリューム分割に対する柔軟性を持たせる必要がある場合の利用形態です。RAID と LVM のどちらも片方だけで両方の要求を満足させることは不可能です。しかし心配ありません。この要求を満足させるには RAID と LVM の両方を同時に使用する方針、正確に言えば一方の上に他方を構成する方針を採用すれば良いでのです。RAID と LVM の高い成熟度のおかげでほぼ標準になりつつある方針に従うならば、最初にディスクを少数の大きな RAID アレイにグループ分けすることでデータの冗長性を確保します。さらにそれらの RAID アレイを LVM の PV として使います。そして、ファイルシステム用の VG から分割された LV を論理パーティションとして使います。この標準的な方針の優れた点は、ディスク障害が起きた場合に再構築しなければいけない RAID アレイの数が少ない点です。このため、管理者は復旧に必要な時間を減らすことが可能です。

en: RAID-1 and LVM are combined to satisfy these constraints. The disks are attached to two different SATA controllers to optimize parallel access and reduce the risk of a simultaneous failure, and they therefore appear as <filename>sda</filename> and <filename>sdc</filename>. They are partitioned identically along the following scheme:
ja: 前述の条件を満足させるために RAID-1 と LVM を組み合わせます。ディスクの並行アクセスを最適化し、そして障害が同時に発生する危険性を減らすために、各ディスクは 2 つの異なる SATA コントローラに接続されています。このため、各ディスクは <filename>sda</filename> と <filename>sdc</filename> として現れます。どちらのディスクも以下に示したパーティショニング方針に従ってパーティショニングされます。

en: Once the VGs are created, they can be partitioned in a very flexible way. One must keep in mind that LVs created in <filename>vg_raid</filename> will be preserved even if one of the disks fails, which will not be the case for LVs created in <filename>vg_bulk</filename>; on the other hand, the latter will be allocated in parallel on both disks, which allows higher read or write speeds for large files.
ja: VG を作成したら、VG をとても柔軟な方法で LV に分割することが可能です。<filename>vg_raid</filename> から分割された LV は 1 台のディスク障害に対して耐性を持ちますが、<filename>vg_bulk</filename> から分割された LV はディスク障害に対する耐性を持たない点を忘れないでください。逆に、<filename>vg_bulk</filename> は両方のディスクにわたって割り当てられるので、<filename>vg_bulk</filename> から分割された LV に保存された巨大なファイルの読み書き速度は高速化されるでしょう。

en: <emphasis>NOTE</emphasis> Why three RAID-1 volumes?
ja: <emphasis>NOTE</emphasis> なぜ 3 種類の RAID-1 ボリュームが必要なのでしょうか?

en: We could have set up one RAID-1 volume only, to serve as a physical volume for <filename>vg_raid</filename>. Why create three of them, then?
ja: RAID-1 ボリュームを 1 つだけ作成し、作成した PV から <filename>vg_raid</filename> を構成し、<filename>vg_raid</filename> から保護したい内容用の LV を分割することも可能でした。それにも関わらず、なぜ 3 種類の RAID-1 ボリュームを作成したのでしょうか?

en: The rationale for the first split (<filename>md0</filename> vs. the others) is about data safety: data written to both elements of a RAID-1 mirror are exactly the same, and it is therefore possible to bypass the RAID layer and mount one of the disks directly. In case of a kernel bug, for instance, or if the LVM metadata become corrupted, it is still possible to boot a minimal system to access critical data such as the layout of disks in the RAID and LVM volumes; the metadata can then be reconstructed and the files can be accessed again, so that the system can be brought back to its nominal state.
ja: 最初の分割 (<filename>md0</filename> とその他) の根本的理由はデータの安全性を考慮したためです。つまり RAID-1 ミラーを構成する要素に書き込まれるデータは要素同士で全く同じだからです。そのため RAID 層を迂回し、RAID-1 ミラーを構成する 1 台のディスクだけを直接マウントすることが可能です。すなわち、カーネルにバグがあったり LVM メタ情報が破壊されたりした場合でも、RAID と LVM ボリュームに含まれるディスクの配置などの重要なデータにアクセスするために最小限のシステムを起動することが可能ということです。そして、このメタ情報を再構成したりファイルにアクセスしたりすることが可能です。こうすることで、システムを正常状態に戻すことが可能です。

en: <primary>virtualization</primary>
ja: <primary sortas="カソウカ">仮想化</primary>

en: Virtualization is one of the most major advances in the recent years of computing. The term covers various abstractions and techniques simulating virtual computers with a variable degree of independence on the actual hardware. One physical server can then host several systems working at the same time and in isolation. Applications are many, and often derive from this isolation: test environments with varying configurations for instance, or separation of hosted services across different virtual machines for security.
ja: 仮想化は最近のコンピューティングにおける最も大きな進歩の 1 つです。仮想化という用語は、実際のハードウェアに対するさまざまな独立性の度合いを持つ仮想コンピュータを模倣するさまざまな抽象化と技術を指します。1 台の物理的なサーバが同時かつ隔離された状態で動く複数のシステムをホストすることが可能です。仮想化アプリケーションは数多く存在し、隔離された仮想システムを使うことができます。たとえば、さまざまに設定されたテスト環境を作ったり、安全性を確保する目的で異なる仮想マシン間でホストされたサービスを分離したりすることが可能です。

en: There are multiple virtualization solutions, each with its own pros and cons. This book will focus on Xen, LXC, and KVM, but other noteworthy implementations include the following:
ja: 複数の仮想化ソリューションが存在し、それぞれが利点と欠点を持っています。本書では Xen、LXC、KVM に注目しますが、他にも以下のような注目すべき実装が存在します。

en: Bochs is another free virtual machine, but it only emulates the x86 architectures (i386 and amd64).
ja: Bochs は自由な仮想マシンですが、x86 アーキテクチャ (i386 と amd64) だけをエミュレートすることが可能です。

en: Xen <indexterm><primary>Xen</primary></indexterm> is a “paravirtualization” solution. It introduces a thin abstraction layer, called a “hypervisor”, between the hardware and the upper systems; this acts as a referee that controls access to hardware from the virtual machines. However, it only handles a few of the instructions, the rest is directly executed by the hardware on behalf of the systems. The main advantage is that performances are not degraded, and systems run close to native speed; the drawback is that the kernels of the operating systems one wishes to use on a Xen hypervisor need to be adapted to run on Xen.
ja: Xen<indexterm><primary>Xen</primary></indexterm> は「準仮想化」ソリューションです。Xen には薄い抽象化層が含まれ、この抽象化層は「ハイパーバイザ」と呼ばれ、ハードウェアとその上にあるシステムの間に位置します。さらにハイパーバイザは審判員として振る舞い、仮想マシンからハードウェアへのアクセスを制御します。しかしながら、Xen ハイパーバイザは命令のほんの一部だけを取り扱い、残りは Xen ハイパーバイザではなくハードウェアによって直接的に実行されます。こうすることによる主な有効性は性能が低下せず、システムがネイティブ速度に迫る性能を発揮するという点です。一方で欠点は Xen ハイパーバイザ上でオペレーティングシステムを実行するには実行されるオペレーティングシステムのカーネルを修正しなければいけないという点です。

en: <emphasis>CULTURE</emphasis> Xen and the various versions of Linux
ja: <emphasis>CULTURE</emphasis> Xen と Linux のさまざまなバージョン

en: Xen was initially developed as a set of patches that lived out of the official tree, and not integrated to the Linux kernel. At the same time, several upcoming virtualization systems (including KVM) required some generic virtualization-related functions to facilitate their integration, and the Linux kernel gained this set of functions (known as the <emphasis>paravirt_ops</emphasis> or <emphasis>pv_ops</emphasis> interface). Since the Xen patches were duplicating some of the functionality of this interface, they couldn't be accepted officially.
ja: 当初 Xen は Linux 公式ツリーの外部パッチとして開発され、Linux カーネルに組み込まれていませんでした。これと同時期に、複数の次世代仮想化システム (KVM など) は Linux カーネルへの組み込みを簡単にするためにいくつかの包括的な仮想化関連関数を必要としており、さらに Linux カーネルが (<emphasis>paravirt_ops</emphasis> または <emphasis>pv_ops</emphasis> インターフェースとして知られる) 一連の仮想化関連関数を獲得しました。Xen のパッチはこのインターフェースのいくつかの機能を複製していたため、Xen のパッチは公式に受け入れられませんでした。

en: <emphasis>CULTURE</emphasis> Xen and non-Linux kernels
ja: <emphasis>CULTURE</emphasis> Xen と非 Linux カーネル

en: However, if Xen can rely on the hardware functions dedicated to virtualization (which are only present in more recent processors), even non-modified operating systems can run as domU (including Windows).
ja: しかしながら、Xen で仮想化専用のハードウェア機能 (最近のプロセッサだけが搭載した機能) に依存するオペレーティングシステムを動作させる場合や、修正されていないオペレーティングシステム (Windows など) を動作させる場合、そのオペレーティングシステムは domU としてのみ動作します。

en: <emphasis>NOTE</emphasis> Architectures compatible with Xen
ja: <emphasis>NOTE</emphasis> Xen 互換のアーキテクチャ

en: Xen is currently only available for the i386, amd64, arm64 and armhf architectures.
ja: 現在のところ、Xen を利用できるのは i386、amd64、arm64、armhf アーキテクチャだけです。

en: Using Xen under Debian requires three components:
ja: Debian の下で Xen を使うには 3 つの要素が必要です。

en: The i386 architecture also requires a standard library with the appropriate patches taking advantage of Xen; this is in the <emphasis role="pkg">libc6-xen</emphasis> package.
ja: さらに i386 アーキテクチャでは、Xen を活用するための適切なパッチを組み込んだ標準的なライブラリが必要です。このライブラリは <emphasis role="pkg">libc6-xen</emphasis> パッケージに含まれます。

en: Once these prerequisites are installed, the next step is to test the behavior of the dom0 by itself; this involves a reboot to the hypervisor and the Xen kernel. The system should boot in its standard fashion, with a few extra messages on the console during the early initialization steps.
ja: これらの前提要件をインストールしたら、次に dom0 の挙動をテストします。テストを行うには、Xen ハイパーバイザと Xen カーネルの再起動が必要です。システムは標準的な方法で起動するべきです。初期化の早い段階でコンソールにいくつかの追加的メッセージが表示されます。

en: Now is the time to actually install useful systems on the domU systems, using the tools from <emphasis role="pkg">xen-tools</emphasis>. This package provides the <command>xen-create-image</command> command, which largely automates the task. The only mandatory parameter is <literal>--hostname</literal>, giving a name to the domU; other options are important, but they can be stored in the <filename>/etc/xen-tools/xen-tools.conf</filename> configuration file, and their absence from the command line doesn't trigger an error. It is therefore important to either check the contents of this file before creating images, or to use extra parameters in the <command>xen-create-image</command> invocation. Important parameters of note include the following:
ja: これで、実用システムを domU システムに実際にインストールできるようになりました。これを行うには <emphasis role="pkg">xen-tools</emphasis> に含まれるツールを使います。<emphasis role="pkg">xen-tools</emphasis> パッケージには <command>xen-create-image</command> コマンドが含まれます。<command>xen-create-image</command> コマンドはインストール作業の大部分を自動化します。必須のパラメータは <literal>--hostname</literal> だけで、このパラメータは domU の名前を設定します。他のオプションは重要ですが、オプションを <filename>/etc/xen-tools/xen-tools.conf</filename> 設定ファイルに保存することが可能です。そして、コマンドラインでオプションを指定しなくてもエラーは起きません。このため、イメージを作る前にこのファイルの内容を確認するか、<command>xen-create-image</command> の実行時に追加的パラメータを使うことが重要です。以下に注目すべき重要なパラメータを示します。

en: <literal>--memory</literal>, to specify the amount of RAM dedicated to the newly created system;
ja: <literal>--memory</literal>。新たに作成する domU システム専用の RAM のサイズを指定します。

en: <literal>--size</literal> and <literal>--swap</literal>, to define the size of the “virtual disks” available to the domU;
ja: <literal>--size</literal> と <literal>--swap</literal>。domU で利用できる「仮想ディスク」のサイズを定義します。

en: <emphasis>GOING FURTHER</emphasis> Installing a non-Debian system in a domU
ja: <emphasis>GOING FURTHER</emphasis> 非 Debian システムを domU にインストール

en: In case of a non-Linux system, care should be taken to define the kernel the domU must use, using the <literal>--kernel</literal> option.
ja: 非 Linux システムを domU にインストールする場合、<literal>--kernel</literal> オプションを使って、domU で使うカーネルを定義しなければいけない点に注意してください。

en: <literal>--dhcp</literal> states that the domU's network configuration should be obtained by DHCP while <literal>--ip</literal> allows defining a static IP address.
ja: <literal>--dhcp</literal>。domU のネットワーク設定を DHCP で取得することを宣言します。対して、<literal>--ip</literal> は静的 IP アドレスを定義します。

en: Lastly, a storage method must be chosen for the images to be created (those that will be seen as hard disk drives from the domU). The simplest method, corresponding to the <literal>--dir</literal> option, is to create one file on the dom0 for each device the domU should be provided. For systems using LVM, the alternative is to use the <literal>--lvm</literal> option, followed by the name of a volume group; <command>xen-create-image</command> will then create a new logical volume inside that group, and this logical volume will be made available to the domU as a hard disk drive.
ja: 最後に、作成されるイメージ (domU からはハードディスクドライブに見えるイメージ) の保存方法を選択します。最も簡単な方法は、<literal>--dir</literal> オプションを使い、各 domU を格納するデバイス用のファイルを dom0 上に作成する方法です。LVM を使っているシステムでは、<literal>--lvm</literal> オプションを使い、VG の名前を指定しても良いでしょう。この場合 <command>xen-create-image</command> は指定された VG から新しい LV を分割し、この LV をハードディスクドライブとして domU から利用できるようにします。

en: <emphasis>NOTE</emphasis> Storage in the domU
ja: <emphasis>NOTE</emphasis> domU 内のストレージ

en: Entire hard disks can also be exported to the domU, as well as partitions, RAID arrays or pre-existing LVM logical volumes. These operations are not automated by <command>xen-create-image</command>, however, so editing the Xen image's configuration file is in order after its initial creation with <command>xen-create-image</command>.
ja: ハードディスク全体、パーティション、RAID アレイ、既存の LVM の LV を domU に書き出すことも可能です。<command>xen-create-image</command> を使ってもこれらの操作を自動化することは不可能ですが、<command>xen-create-image</command> を使って Xen イメージの設定ファイルを作成した後にその設定ファイルを編集することで対応する操作が可能です。

en: Once these choices are made, we can create the image for our future Xen domU:
ja: これらを選んだ後、将来の Xen domU 用のイメージを作成することが可能です。

en: We now have a virtual machine, but it is currently not running (and therefore only using space on the dom0's hard disk). Of course, we can create more images, possibly with different parameters.
ja: これで仮想マシンが作成されましたが、仮想マシンはまだ実行されていません (このため dom0 のハードディスク上の領域が使われているだけです)。もちろん、異なるパラメータを使ってより多くのイメージを作成することが可能です。

en: The simplest model is the <emphasis>bridge</emphasis> model; all the eth0 network cards (both in the dom0 and the domU systems) behave as if they were directly plugged into an Ethernet switch.
ja: 最も単純なモデルは <emphasis>bridge</emphasis> モデルです。この場合、すべての eth0 ネットワークカードが (dom0 と domU システムに含まれるものも含めて) 直接的にイーサネットスイッチに接続されているかのように振る舞います。

en: Then comes the <emphasis>routing</emphasis> model, where the dom0 behaves as a router that stands between the domU systems and the (physical) external network.
ja: 2 番目に単純なモデルは <emphasis>routing</emphasis> モデルです。これは dom0 が domU システムと (物理) 外部ネットワークの間に位置するルータとして振る舞うモデルです。

en: Finally, in the <emphasis>NAT</emphasis> model, the dom0 is again between the domU systems and the rest of the network, but the domU systems are not directly accessible from outside, and traffic goes through some network address translation on the dom0.
ja: 最後が <emphasis>NAT</emphasis> モデルです。これは dom0 が domU システムとその他のネットワークの間に位置するモデルですが、domU システムに外部から直接アクセスすることは不可能です。dom0 の行ういくつかのネットワークアドレス変換がトラフィックを仲介します。

en: These three networking nodes involve a number of interfaces with unusual names, such as <filename>vif*</filename>, <filename>veth*</filename>, <filename>peth*</filename> and <filename>xenbr0</filename>. The Xen hypervisor arranges them in whichever layout has been defined, under the control of the user-space tools. Since the NAT and routing models are only adapted to particular cases, we will only address the bridging model.
ja: これら 3 種類のネットワークノードは <filename>vif*</filename>、<filename>veth*</filename>、<filename>peth*</filename>、<filename>xenbr0</filename> などの独特な名前を付けられた数多くのインターフェースと関係を持ちます。Xen ハイパーバイザは定義された配置に従いユーザ空間ツールの制御の下でインターフェースを準備します。NAT と routing モデルは特定の場合にのみ適合します。このためわれわれは bridge モデルを使います。

en: <emphasis>TOOL</emphasis> Choice of toolstacks to manage Xen VM
ja: <emphasis>TOOL</emphasis> Xen VM を管理するツールスタックの選択

en: <emphasis>CAUTION</emphasis> Only one domU per image!
ja: <emphasis>CAUTION</emphasis> 1 つのイメージに 1 台以上の domU を割り当てないでください!

en: Note that the <filename>testxen</filename> domU uses real memory taken from the RAM that would otherwise be available to the dom0, not simulated memory. Care should therefore be taken, when building a server meant to host Xen instances, to provision the physical RAM accordingly.
ja: <filename>testxen</filename> domU は仮想メモリではなく RAM から取った物理メモリを使います。このメモリ領域は <filename>testxen</filename> domU が起動していなければ dom0 が使えるメモリ領域だったという点に注意してください。このため、サーバを作ることが Xen インスタンスをホストすることを意味する場合、それに応じて十分なサイズの物理 RAM が必要になるという点に注意が必要です。

en: Voilà! Our virtual machine is starting up. We can access it in one of two modes. The usual way is to connect to it “remotely” through the network, as we would connect to a real machine; this will usually require setting up either a DHCP server or some DNS configuration. The other way, which may be the only way if the network configuration was incorrect, is to use the <filename>hvc0</filename> console, with the <command>xl console</command> command:
ja: おめでとうございます! 仮想マシンが開始されました。仮想マシンにアクセスするには 2 種類の方法があります。通常の方法は、真のマシンに接続するのと同様に、ネットワークを介して「リモートで」仮想マシンに接続することです。そしてこれを行うには、通常別の DHCP サーバや DNS 設定をセットアップすることが必要です。別の方法は <command>xl console</command> コマンドから <filename>hvc0</filename> コンソールを使う方法です。ネットワーク設定が正しくない場合にはこれが唯一の方法です。

en: One can then open a session, just like one would do if sitting at the virtual machine's keyboard. Detaching from this console is achieved through the <keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo> key combination.
ja: 仮想マシンのキーボードの前に座っているかのごとくセッションを開くことが可能です。このコンソールからデタッチするには、<keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo> キーの組み合わせを使用します。

en: <emphasis>TIP</emphasis> Getting the console straight away
ja: <emphasis>TIP</emphasis> すぐにコンソールを開始する

en: Sometimes one wishes to start a domU system and get to its console straight away; this is why the <command>xl create</command> command takes a <literal>-c</literal> switch. Starting a domU with this switch will display all the messages as the system boots.
ja: domU システムの開始直後にコンソールを始めたい場合があります。そしてこの希望に応えるために <command>xl create</command> コマンドは <literal>-c</literal> オプションを備えています。<literal>-c</literal> オプションを付けて domU を開始すれば、システム起動時に表示されるすべてのメッセージを見ることが可能です。

en: Once the domU is up, it can be used just like any other server (since it is a GNU/Linux system after all). However, its virtual machine status allows some extra features. For instance, a domU can be temporarily paused then resumed, with the <command>xl pause</command> and <command>xl unpause</command> commands. Note that even though a paused domU does not use any processor power, its allocated memory is still in use. It may be interesting to consider the <command>xl save</command> and <command>xl restore</command> commands: saving a domU frees the resources that were previously used by this domU, including RAM. When restored (or unpaused, for that matter), a domU doesn't even notice anything beyond the passage of time. If a domU was running when the dom0 is shut down, the packaged scripts automatically save the domU, and restore it on the next boot. This will of course involve the standard inconvenience incurred when hibernating a laptop computer, for instance; in particular, if the domU is suspended for too long, network connections may expire. Note also that Xen is so far incompatible with a large part of ACPI power management, which precludes suspending the host (dom0) system.
ja: domU の起動完了後、domU は他のサーバと同様に使うことが可能です (domU は結局 GNU/Linux システムに過ぎません)。しかしながら、domU の仮想マシンの状態はいくつかの追加的機能を備えています。たとえば、<command>xl pause</command> と <command>xl unpause</command> コマンドを使って domU を一時的に停止したり再開することが可能です。一時的に停止された domU は全くプロセッサを使いませんが、割り当てられたメモリを解放しません。<command>xl save</command> と <command>xl restore</command> コマンドを考慮することは興味深いかもしれません。なぜなら <command>xl save</command> で domU を保存すれば domU の使っていた RAM などの資源が解放されるからです。また、<command>xl restore</command> で domU を元に戻す時 (ついでに言えば <command>xl unpause</command> で再開する時)、domU は時間が経過したことに全く気が付きません。dom0 を停止した時に domU が動いていた場合、パッケージに含まれるスクリプトが自動的に <command>xl save</command> で domU を保存し、dom0 の次回起動時に自動的に <command>xl restore</command> で domU を再開します。もちろんこれにはラップトップコンピュータをハイバネートする場合と同様の標準的な不便さがあります。特に、domU が長い間一時停止されていた場合、ネットワーク接続が切断される可能性があります。今現在 Xen は ACPI 電源管理のほとんどに互換性がない点にも注意してください。このため、ホスト (dom0) システムを一時停止することは不可能です。

en: Halting or rebooting a domU can be done either from within the domU (with the <command>shutdown</command> command) or from the dom0, with <command>xl shutdown</command> or <command>xl reboot</command>.
ja: domU を停止したり再起動するには、domU の内部から (<command>shutdown</command> コマンドを使って) 行ったり、dom0 から <command>xl shutdown</command> または <command>xl reboot</command> を使って行うことも可能です。

en: Most of the <command>xl</command> subcommands expect one or more arguments, often a domU name. These arguments are well described in the <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page.
ja: <command>xl</command> サブコマンドのほとんどは domU の名前などの 1 つか複数個の引数を取ります。これらの引数は <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry> マニュアルページは詳しく説明されています。

en: <emphasis>GOING FURTHER</emphasis> Advanced Xen
ja: <emphasis>GOING FURTHER</emphasis> Xen の上級活用

en: Even though it is used to build “virtual machines”, LXC is not, strictly speaking, a virtualization system, but a system to isolate groups of processes from each other even though they all run on the same host. It takes advantage of a set of recent evolutions in the Linux kernel, collectively known as <emphasis>control groups</emphasis>, by which different sets of processes called “groups” have different views of certain aspects of the overall system. Most notable among these aspects are the process identifiers, the network configuration, and the mount points. Such a group of isolated processes will not have any access to the other processes in the system, and its accesses to the filesystem can be restricted to a specific subset. It can also have its own network interface and routing table, and it may be configured to only see a subset of the available devices present on the system.
ja: LXC は「仮想マシン」を作るために使われるにも関わらず、厳密に言うと仮想システムではなく、同じホスト上で実行されるプロセスのグループを隔離するためのシステムです。LXC は近年 Linux カーネルに対して行われた数々の機能の利点を活用しています。これらの機能はまとめて <emphasis>control groups</emphasis> として知られています。<emphasis>control groups</emphasis> を使うことにより、「グループ」と呼ばれるさまざまなプロセス群に対してシステム全体の特定の側面の状態を強制することが可能です。中でも最も注目すべき側面はプロセス ID、ネットワーク接続、マウントポイントです。隔離されたプロセスのグループはシステムの他のプロセスにアクセスできませんし、グループによるファイルシステムへのアクセスを特定の一部に限定することが可能です。さらにグループにネットワークインターフェースとルーティングテーブルを設定することにより、グループがシステム上の利用できるデバイスの一部だけを見えるように設定することが可能です。

en: <emphasis>NOTE</emphasis> LXC isolation limits
ja: <emphasis>NOTE</emphasis> LXC の隔離制限

en: LXC containers do not provide the level of isolation achieved by heavier emulators or virtualizers. In particular:
ja: LXC コンテナは負荷の大きなエミュレータやバーチャライザが備える隔離機能を備えていません。たとえば以下のような機能を備えていません。

en: since the kernel is shared among the host system and the containers, processes constrained to containers can still access the kernel messages, which can lead to information leaks if messages are emitted by a container;
ja: カーネルはホストシステムとコンテナによって共有されているため、コンテナ内に隔離されているプロセスはカーネルメッセージにアクセスできます。このことにより、メッセージがコンテナによって発せられた場合、情報が漏洩する可能性があります。

en: for similar reasons, if a container is compromised and a kernel vulnerability is exploited, the other containers may be affected too;
ja: 同様の理由で、コンテナが不正アクセスされカーネルの脆弱性が悪用された場合、他のコンテナが影響を受ける可能性があります。

en: on the filesystem, the kernel checks permissions according to the numerical identifiers for users and groups; these identifiers may designate different users and groups depending on the container, which should be kept in mind if writable parts of the filesystem are shared among containers.
ja: ファイルシステムについて、カーネルはユーザとグループの数値的な識別子に従ってパーミッションを確認します。これらの識別子の意味するユーザとグループはコンテナごとに異なります。ファイルシステムの書き込み可能な部分がコンテナ同士で共有されている場合、この点を覚えておくべきです。

en: Since we are dealing with isolation and not plain virtualization, setting up LXC containers is more complex than just running debian-installer on a virtual machine. We will describe a few prerequisites, then go on to the network configuration; we will then be able to actually create the system to be run in the container.
ja: LXC による隔離は単純な仮想化と異なるため、LXC コンテナを設定することは仮想マシン上で単純に debian-installer を実行するよりも複雑な作業です。このため、いくつかの必要条件を説明した後、ネットワーク設定を行います。こうすることで、コンテナの中で実行するシステムを実際に作成することが可能です。

en: Preliminary Steps
ja: 準備段階

en: The <emphasis role="pkg">lxc</emphasis> package contains the tools required to run LXC, and must therefore be installed.
ja: <emphasis role="pkg">lxc</emphasis> パッケージには LXC を実行するために必要なツールが含まれるため、必ずこのパッケージをインストールしなければいけません。

en: LXC also requires the <emphasis>control groups</emphasis> configuration system, which is a virtual filesystem to be mounted on <filename>/sys/fs/cgroup</filename>. Since Debian 8 switched to systemd, which also relies on control groups, this is now done automatically at boot time without further configuration.
ja: LXC を使うには <emphasis>control groups</emphasis> 設定システムが必要で、<filename>/sys/fs/cgroup</filename> に仮想ファイルシステムをマウントする必要があります。Debian 8 からは init システムとして systemd が採用されており、systemd は <emphasis>control groups</emphasis> に依存しているため、設定せずとも <filename>/sys/fs/cgroup</filename> は起動時に自動でマウントされます。

en: Network Configuration
ja: ネットワークの設定

en: They should be disabled and replaced with the following:
ja: このエントリを無効化し、以下の通り書き換えます。

en: The effect of this configuration will be similar to what would be obtained if the containers were machines plugged into the same physical network as the host. The “bridge” configuration manages the transit of Ethernet frames between all the bridged interfaces, which includes the physical <literal>eth0</literal> as well as the interfaces defined for the containers.
ja: この設定により、コンテナをホストと同じ物理ネットワークに接続されたマシンとして考えた場合と、同様の効果が得られます。この「ブリッジ」設定はすべてのブリッジされたインターフェース間のイーサネットフレームの通過を管理します。これには物理的な <literal>eth0</literal> およびコンテナ用に定義されたインターフェースが含まれます。

en: In addition to <emphasis role="pkg">bridge-utils</emphasis>, this “rich” configuration requires the <emphasis role="pkg">vde2</emphasis> package; the <filename>/etc/network/interfaces</filename> file then becomes:
ja: この「ぜいたくな」設定を行うには <emphasis role="pkg">bridge-utils</emphasis> と <emphasis role="pkg">vde2</emphasis> パッケージが必要です。<filename>/etc/network/interfaces</filename> ファイルは以下のようになります。

en: The network can then be set up either statically in the containers, or dynamically with DHCP server running on the host. Such a DHCP server will need to be configured to answer queries on the <literal>br0</literal> interface.
ja: コンテナのネットワークは静的またはコンテナのホスト上で動く DHCP サーバを使って動的に設定されます。また、DHCP サーバを <literal>br0</literal> インターフェースを介した問い合わせに応答するように設定する必要があります。

en: Setting Up the System
ja: システムのセットアップ

en: Note that the filesystem is initially created in <filename>/var/cache/lxc</filename>, then moved to its destination directory. This allows creating identical containers much more quickly, since only copying is then required.
ja: ファイルシステムは最初に <filename>/var/cache/lxc</filename> の中に作成され、その後目的のディレクトリに移動されます。こうすることで、同一のコンテナが極めて素早く作成されます。なぜなら、単純にコピーするだけだからです。

en: Another useful entry in that file is the setting of the hostname:
ja: 以下のようにすることで、設定ファイル内でホスト名を設定することも可能です。

en: Starting the Container
ja: コンテナの開始

en: We are now in the container; our access to the processes is restricted to only those started from the container itself, and our access to the filesystem is similarly restricted to the dedicated subset of the full filesystem (<filename>/var/lib/lxc/testlxc/rootfs</filename>). We can exit the console with <keycombo action="simul"><keycap>Control</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo>.
ja: これでコンテナの中に入りました。プロセスへのアクセスはコンテナ自身によって開始されたものだけに制限されていることがわかります。同様に、ファイルシステムへのアクセスも testlxc コンテナ専用に割り当てられた完全なファイルシステムの一部分 (<filename>/var/lib/lxc/testlxc/rootfs</filename>) に制限されています。コンソールを終了するには <keycombo action="simul"><keycap>Control</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo> を使います。

en: The <emphasis role="pkg">lxc</emphasis> package contains an initialization script that can automatically start one or several containers when the host boots (it relies on <command>lxc-autostart</command> which starts containers whose <literal>lxc.start.auto</literal> option is set to 1). Finer-grained control of the startup order is possible with <literal>lxc.start.order</literal> and <literal>lxc.group</literal>: by default, the initialization script first starts containers which are part of the <literal>onboot</literal> group and then the containers which are not part of any group. In both cases, the order within a group is defined by the <literal>lxc.start.order</literal> option.
ja: <emphasis role="pkg">lxc</emphasis> パッケージには、ホストの起動時に自動的に 1 つまたは複数のコンテナを開始するための初期化スクリプトが含まれます (この初期化スクリプトは <literal>lxc.start.auto</literal> オプションが 1 に設定されているコンテナを起動する <command>lxc-autostart</command> に依存しています)。起動順序を非常に細かく制御するには <literal>lxc.start.order</literal> と <literal>lxc.group</literal> を使います。デフォルトの場合、初期化スクリプトは <literal>onboot</literal> グループに所属するコンテナを起動し、その後いかなるグループにも所属しないコンテナを起動します。どちらの場合も、グループ内の起動順序を制御するには <literal>lxc.start.order</literal> オプションを使います。

en: <emphasis>GOING FURTHER</emphasis> Mass virtualization
ja: <emphasis>GOING FURTHER</emphasis> 大量の仮想化

en: Since LXC is a very lightweight isolation system, it can be particularly adapted to massive hosting of virtual servers. The network configuration will probably be a bit more advanced than what we described above, but the “rich” configuration using <literal>tap</literal> and <literal>veth</literal> interfaces should be enough in many cases.
ja: LXC は非常に軽量の隔離システムですから、LXC を使って仮想サーバを大量にホストすることが可能です。この場合のネットワーク設定は上に述べた物よりも少し高度なものになるかもしれませんが、多くの場合 <literal>tap</literal> と <literal>veth</literal> インターフェースを用いた「ぜいたくな」設定を使えば事足ります。

en: It may also make sense to share part of the filesystem, such as the <filename>/usr</filename> and <filename>/lib</filename> subtrees, so as to avoid duplicating the software that may need to be common to several containers. This will usually be achieved with <literal>lxc.mount.entry</literal> entries in the containers configuration file. An interesting side-effect is that the processes will then use less physical memory, since the kernel is able to detect that the programs are shared. The marginal cost of one extra container can then be reduced to the disk space dedicated to its specific data, and a few extra processes that the kernel must schedule and manage.
ja: ファイルシステムの一部 (たとえば <filename>/usr</filename> と <filename>/lib</filename> などのサブツリー) を共有することは合理的です。こうすることで、複数のコンテナで共通に必要なソフトウェアを複製することを避けることが可能です。通常これを設定するには、コンテナ設定ファイルに含まれる <literal>lxc.mount.entry</literal> エントリを使います。さらに興味深い副作用として、より少ない物理メモリでプロセスを動かすことが可能になります。なぜなら、カーネルはプログラムが共有されていることを検出できるからです。このことにより 1 つのコンテナを追加するためのコストをコンテナに特有のデータに割り当てられたディスク領域と、カーネルがスケジュールと管理に使ういくつかの追加的プロセスだけに減らすことが可能です。

en: We haven't described all the available options, of course; more comprehensive information can be obtained from the <citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry> and <citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual pages and the ones they reference.
ja: もちろん、ここではすべての利用できるオプションを説明していません。このため、より広範囲におよぶ情報を入手するには、<citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry> と <citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> マニュアルページおよびこれらのマニュアルページから参照されている文書を参照してください。

en: Virtualization with KVM
ja: KVM を使った仮想化

en: KVM, which stands for <emphasis>Kernel-based Virtual Machine</emphasis>, is first and foremost a kernel module providing most of the infrastructure that can be used by a virtualizer, but it is not a virtualizer by itself. Actual control for the virtualization is handled by a QEMU-based application. Don't worry if this section mentions <command>qemu-*</command> commands: it is still about KVM.
ja: KVM は <emphasis>Kernel-based Virtual Machine</emphasis> を意味しており、仮想化システムの使うほとんどの基礎構造を提供する最初で最高のカーネルモジュールです。しかしながら、LVM 自身は仮想化システムではありません。仮想化の実際の制御を行うには QEMU に基づくアプリケーションを使います。この節で <command>qemu-*</command> コマンドがあっても心配しないでください。なぜならこのコマンドは KVM に関連するものだからです。

en: Unlike other virtualization systems, KVM was merged into the Linux kernel right from the start. Its developers chose to take advantage of the processor instruction sets dedicated to virtualization (Intel-VT and AMD-V), which keeps KVM lightweight, elegant and not resource-hungry. The counterpart, of course, is that KVM doesn't work on any computer but only on those with appropriate processors. For x86-based computers, you can verify that you have such a processor by looking for “vmx” or “svm” in the CPU flags listed in <filename>/proc/cpuinfo</filename>.
ja: 他の仮想化システムと異なり、KVM は最初から Linux カーネルにマージされていました。KVM の開発者はプロセッサが備える仮想化専用命令セット (Intel-VT と AMD-V) を有効活用することを選びました。仮想化専用命令セットを活用することで、KVM は軽量で簡潔でリソースを大量に消費しないものになっています。もちろんその代償として KVM にも欠点があります。それはすべてのコンピュータが KVM を動かせるわけではなく、適切なプロセッサを備えたコンピュータでなければ KVM を動かせないという点です。x86 ベースのコンピュータで <filename>/proc/cpuinfo</filename> 内の CPU フラグに「vmx」または「svm」が含まれている場合、そのプロセッサは KVM を動かすことができることを意味します。

en: With Red Hat actively supporting its development, KVM has more or less become the reference for Linux virtualization.
ja: Red Hat が KVM の開発を活発に支援したことで、KVM は事実上 Linux 仮想化の基準点になりました。

en: The <emphasis role="pkg">virtinst</emphasis> package provides <command>virt-install</command>, which allows creating virtual machines from the command line. Finally, <emphasis role="pkg">virt-viewer</emphasis> allows accessing a VM's graphical console.
ja: <emphasis role="pkg">virtinst</emphasis> パッケージには <command>virt-install</command> コマンドが含まれます。<command>virt-install</command> を使うことで、コマンドラインから仮想マシンを作成することが可能になります。最後に、<emphasis role="pkg">virt-viewer</emphasis> を使うことで、仮想マシンのグラフィカルコンソールにアクセスすることが可能になります。

en: Just as in Xen and LXC, the most frequent network configuration involves a bridge grouping the network interfaces of the virtual machines (see <xref linkend="sect.lxc.network" />).
ja: Xen や LXC と同様に、最もよく使われるネットワーク設定は仮想マシンのネットワークインターフェースをグループ化するブリッジです (<xref linkend="sect.lxc.network" />を参照してください)。

en: Alternatively, and in the default configuration provided by KVM, the virtual machine is assigned a private address (in the 192.168.122.0/24 range), and NAT is set up so that the VM can access the outside network.
ja: ネットワーク設定には別の方法もあります。KVM の提供するデフォルト設定の中では、仮想マシンに (192.168.122.0/24 の範囲内に) プライベートアドレスが割り当てられており、さらに NAT が設定されています。この設定により仮想マシンは外部ネットワークにアクセスすることが可能です。

en: The rest of this section assumes that the host has an <literal>eth0</literal> physical interface and a <literal>br0</literal> bridge, and that the former is connected to the latter.
ja: この節の残りでは、ホストが <literal>eth0</literal> 物理インターフェースと <literal>br0</literal> ブリッジを備え、<literal>eth0</literal> が <literal>br0</literal> に接続されていることを仮定します。

en: Installation with <command>virt-install</command>
ja: <command>virt-install</command> を使ったインストール

en: Creating a virtual machine is very similar to installing a normal system, except that the virtual machine's characteristics are described in a seemingly endless command line.
ja: 仮想マシンの作成は普通のシステムをインストールするのとよく似ています。違いは、仮想マシンの性質をコマンドラインから非常に長々と指定する点です。

en: Practically speaking, this means we will use the Debian installer, by booting the virtual machine on a virtual DVD-ROM drive that maps to a Debian DVD image stored on the host system. The VM will export its graphical console over the VNC protocol (see <xref linkend="sect.remote-desktops" /> for details), which will allow us to control the installation process.
ja: 具体的に言えば、これはホストシステムに保存された Debian DVD イメージを挿入された仮想 DVD-ROM ドライブから仮想マシンを起動することにより Debian インストーラを使うことを意味します。仮想マシンは VNC プロトコル (詳しくは<xref linkend="sect.remote-desktops" />を参照してください) を介してグラフィカルコンソールに表示されます。これによりインストール作業を操作することが可能になります。

en: <emphasis>TIP</emphasis> Add your user to the libvirt group
ja: <emphasis>TIP</emphasis> libvirt グループに対するユーザの追加

en: Let us now start the installation process for the virtual machine, and have a closer look at <command>virt-install</command>'s most important options. This command registers the virtual machine and its parameters in libvirtd, then starts it so that its installation can proceed.
ja: それでは仮想マシンのインストール作業を開始し、<command>virt-install</command> の最も重要なオプションを詳細に見て行きましょう。<command>virt-install</command> は仮想マシンとそのパラメータを libvirtd に登録し、インストールを進めるために仮想マシンを開始します。

en: The <literal>--connect</literal> option specifies the “hypervisor” to use. Its form is that of an URL containing a virtualization system (<literal>xen://</literal>, <literal>qemu://</literal>, <literal>lxc://</literal>, <literal>openvz://</literal>, <literal>vbox://</literal>, and so on) and the machine that should host the VM (this can be left empty in the case of the local host). In addition to that, and in the QEMU/KVM case, each user can manage virtual machines working with restricted permissions, and the URL path allows differentiating “system” machines (<literal>/system</literal>) from others (<literal>/session</literal>).
ja: <literal>--connect</literal> オプションは使用する「ハイパーバイザ」を指定します。これは仮想システムを表す URL (<literal>xen://</literal>、<literal>qemu://</literal>、<literal>lxc://</literal>、<literal>openvz://</literal>、<literal>vbox://</literal> など) と VM をホストするマシン (ローカルホストの場合、空でも構いません) の形をしています。QEMU/KVM の場合、これに加えて各ユーザは制限されたパーミッションで稼働する仮想マシンを管理できます。この場合 URL パスは「システム」マシン (<literal>/system</literal>) かその他 (<literal>/session</literal>) かで識別されます。

en: Since KVM is managed the same way as QEMU, the <literal>--virt-type kvm</literal> allows specifying the use of KVM even though the URL looks like QEMU.
ja: <literal>--virt-type kvm</literal> を指定することで KVM を使うことが可能です。<literal>--connect</literal> で指定した URL を一見すると QEMU が使われるように見えますが、これは KVM は QEMU と同じ方法で管理されているためです。

en: The <literal>--name</literal> option defines a (unique) name for the virtual machine.
ja: <literal>--name</literal> オプションは仮想マシンの (一意的な) 名前を定義します。

en: The <literal>--cdrom</literal> option is used to indicate where to find the optical disk to use for installation. The path can be either a local path for an ISO file, an URL where the file can be obtained, or the device file of a physical CD-ROM drive (i.e. <literal>/dev/cdrom</literal>).
ja: <literal>--cdrom</literal> オプションはインストール時に利用する光学ディスクの場所を指定するために使われます。場所には ISO ファイルのローカルパス、ファイル取得先の URL、物理 CD-ROM ドライブのデバイスファイル (例 <literal>/dev/cdrom</literal>) のどれか 1 つを使うことが可能です。

en: The <literal>--network</literal> specifies how the virtual network card integrates in the host's network configuration. The default behavior (which we explicitly forced in our example) is to integrate it into any pre-existing network bridge. If no such bridge exists, the virtual machine will only reach the physical network through NAT, so it gets an address in a private subnet range (192.168.122.0/24).
ja: <literal>--network</literal> オプションはホストネットワーク設定の中に仮想ネットワークを統合する方法を指定します。デフォルトは既存のネットワークブリッジに仮想ネットワークを統合する方法です (例では明示的にこの挙動を指定しています)。指定したブリッジが存在しない場合、仮想マシンが到達できるネットワークは NAT を介した物理ネットワークだけに限定されるので、仮想マシンはプライベートサブネット範囲 (192.168.122.0/24) に含まれるアドレスを割り当てられます。

en: The <literal>--os-type</literal> and <literal>--os-variant</literal> options allow optimizing a few parameters of the virtual machine, based on some of the known features of the operating system mentioned there.
ja: <literal>--os-type</literal> と <literal>--os-variant</literal> オプションは、指定されたオペレーティングシステムの備える既知の機能に基づいて、仮想マシンのいくつかのパラメータを最適化するためのものです。

en: At this point, the virtual machine is running, and we need to connect to the graphical console to proceed with the installation process. If the previous operation was run from a graphical desktop environment, this connection should be automatically started. If not, or if we operate remotely, <command>virt-viewer</command> can be run from any graphical environment to open the graphical console (note that the root password of the remote host is asked twice because the operation requires 2 SSH connections):
ja: <command>virt-install</command> を実行した時点で仮想マシンが実行されます。インストール作業に進むためには、グラフィカルコンソールに接続する必要があります。上の操作をグラフィカルデスクトップ環境から行った場合、自動的に接続が開始されます。そうでない場合、グラフィカルコンソールを開くために <command>virt-viewer</command> を任意のグラフィカル環境から実行します (この時にリモートホストの root パスワードが 2 回尋ねられる点に注意してください。なぜなら、この操作には 2 つの SSH 接続を必要とするからです)。

en: When the installation process ends, the virtual machine is restarted, now ready for use.
ja: インストール作業が終了したら、仮想マシンが再起動されます。これで仮想マシンを利用する準備が整いました。

en: Managing Machines with <command>virsh</command>
ja: <command>virsh</command> を使ったマシンの管理

en: Now that the installation is done, let us see how to handle the available virtual machines. The first thing to try is to ask <command>libvirtd</command> for the list of the virtual machines it manages:
ja: これでインストールが終了しました。利用できる仮想マシンを取り扱う方法に移りましょう。最初に <command>virsh</command> を使って <command>libvirtd</command> が管理している仮想マシンのリストを確認します。

en: Let's start our test virtual machine:
ja: それではテスト用仮想マシンを起動しましょう。

en: We can now get the connection instructions for the graphical console (the returned VNC display can be given as parameter to <command>vncviewer</command>):
ja: そして、グラフィカルコンソールへの接続命令を出します (接続する VNC 画面を <command>vncviewer</command> へのパラメータの形で指定することが可能です)。

en: Other available <command>virsh</command> subcommands include:
ja: その他の利用できる <command>virsh</command> サブコマンドには以下のものがあります。

en: <literal>reboot</literal> to restart a virtual machine;
ja: <literal>reboot</literal>。仮想マシンを再起動します。

en: <literal>shutdown</literal> to trigger a clean shutdown;
ja: <literal>shutdown</literal>。仮想マシンを正常にシャットダウンします。

en: <literal>destroy</literal>, to stop it brutally;
ja: <literal>destroy</literal>。仮想マシンを無理やり停止します。

en: <literal>suspend</literal> to pause it;
ja: <literal>suspend</literal>。仮想マシンを一時停止します。

en: <literal>resume</literal> to unpause it;
ja: <literal>resume</literal>。一時停止された仮想マシンを再開します。

en: <literal>autostart</literal> to enable (or disable, with the <literal>--disable</literal> option) starting the virtual machine automatically when the host starts;
ja: <literal>autostart</literal>。ホスト起動時にこの仮想マシンを自動的に起動することを有効化します (または <literal>--disable</literal> オプションを付けて無効化します)。

en: <literal>undefine</literal> to remove all traces of the virtual machine from <command>libvirtd</command>.
ja: <literal>undefine</literal>。仮想マシンのすべての痕跡を <command>libvirtd</command> から削除します。

en: All these subcommands take a virtual machine identifier as a parameter.
ja: ここに挙げたすべてのサブコマンドは仮想マシン識別子をパラメータとして受け取ります。

en: Automated Installation
ja: 自動インストール

en: <primary>deployment</primary>
ja: <primary sortas="ハイビ">配備</primary>

en: <primary>installation</primary><secondary>automated installation</secondary>
ja: <primary>インストール</primary><secondary sortas="ジドウインストール">自動インストール</secondary>

en: The Falcot Corp administrators, like many administrators of large IT services, need tools to install (or reinstall) quickly, and automatically if possible, their new machines.
ja: 巨大な IT サービスの管理者と同様に Falcot Corp の管理者もまた、新しいマシンへシステムを素早く (可能であれば自動的に) インストール (または再インストール) するツールを必要としています。

en: These requirements can be met by a wide range of solutions. On the one hand, generic tools such as SystemImager handle this by creating an image based on a template machine, then deploy that image to the target systems; at the other end of the spectrum, the standard Debian installer can be preseeded with a configuration file giving the answers to the questions asked during the installation process. As a sort of middle ground, a hybrid tool such as FAI (<emphasis>Fully Automatic Installer</emphasis>) installs machines using the packaging system, but it also uses its own infrastructure for tasks that are more specific to massive deployments (such as starting, partitioning, configuration and so on).
ja: 自動インストールの要求に応えるためのさまざまな解決策が存在します。一方では、SystemImager などの一般的なツールが存在します。こちらの解決策ではテンプレートマシンに基づくイメージを事前に準備し、そのイメージを目標のシステムで展開します。他方では、標準的な Debian インストーラが存在します。こちらの解決策ではインストール作業中に尋ねられる質問の回答を含めた設定ファイルを事前に準備し、この設定ファイルに基づいて目標のシステムを設定します。両者の折衷案として、FAI (<emphasis>Fully Automatic Installer</emphasis>) などのハイブリッドツールが存在します。こちらの解決策ではパッケージングシステムでシステムをインストールし、自分自身の機能を使って大規模な配備に特有のタスク (起動、パーティショニング、設定など) をこなします。

en: <foreignphrase>Fully Automatic Installer</foreignphrase> is probably the oldest automated deployment system for Debian, which explains its status as a reference; but its very flexible nature only just compensates for the complexity it involves.
ja: <foreignphrase>Fully Automatic Installer</foreignphrase> はおそらく最も古い Debian 用の自動配備システムで、基準としての地位を確立しています。しかしその一方で FAI の高い柔軟性は FAI の複雑性によって成し遂げられています。

en: FAI requires a server system to store deployment information and allow target machines to boot from the network. This server requires the <emphasis role="pkg">fai-server</emphasis> package (or <emphasis role="pkg">fai-quickstart</emphasis>, which also brings the required elements for a standard configuration).
ja: FAI には、配備情報を保存してネットワークから目標のマシンを起動することを可能にするために、サーバシステムが必要です。サーバシステムには、<emphasis role="pkg">fai-server</emphasis> パッケージ (または <emphasis role="pkg">fai-quickstart</emphasis>、これには、標準的な設定に必要な要素が含まれています) が必要です。

en: Creating all these configuration files requires some understanding of the way FAI works. A typical installation process is made of the following steps:
ja: これらすべての設定ファイルを作成するには、FAI の動作方法を理解する必要があります。典型的なインストール作業は以下の順番で進みます。

en: fetching a kernel from the network, and booting it;
ja: ネットワークからカーネルを取得して起動します。

en: mounting the root filesystem from NFS;
ja: NFS でルートファイルシステムをマウントします。

en: executing <command>/usr/sbin/fai</command>, which controls the rest of the process (the next steps are therefore initiated by this script);
ja: インストール作業を制御する <command>/usr/sbin/fai</command> を実行します (<command>/usr/sbin/fai</command> が以降の各段階を初期化します)。

en: copying the configuration space from the server into <filename>/fai/</filename>;
ja: サーバから <filename>/fai/</filename> に設定領域をコピーします。

en: running <command>fai-class</command>. The <filename>/fai/class/[0-9][0-9]*</filename> scripts are executed in turn, and return names of “classes” that apply to the machine being installed; this information will serve as a base for the following steps. This allows for some flexibility in defining the services to be installed and configured.
ja: <command>fai-class</command> を実行します。<filename>/fai/class/[0-9][0-9]*</filename> スクリプトが順番に実行され、インストールされるマシンに適用する「クラス」の名前が返されます。この情報は以降の各段階の基礎としての機能を果たします。これを使うことで、インストールおよび設定されるサービスを定義する際に幾らかの柔軟性を持たせることが可能です。

en: fetching a number of configuration variables, depending on the relevant classes;
ja: 対応するクラスに基づき、設定変数を取得します。

en: partitioning the disks and formatting the partitions, based on information provided in <filename>/fai/disk_config/<replaceable>class</replaceable></filename>;
ja: <filename>/fai/disk_config/<replaceable>class</replaceable></filename> で定義された情報に基づいて、ディスクのパーティショニングとパーティションのフォーマットを行います。

en: mounting said partitions;
ja: 指定されたパーティションをマウントします。

en: installing the base system;
ja: 基本システムをインストールします。

en: preseeding the Debconf database with <command>fai-debconf</command>;
ja: <command>fai-debconf</command> を使って Debconf データベースを事前配布します。

en: fetching the list of available packages for APT;
ja: APT で利用できるパッケージのリストを取得します。

en: installing the packages listed in <filename>/fai/package_config/<replaceable>class</replaceable></filename>;
ja: <filename>/fai/package_config/<replaceable>class</replaceable></filename> にリストされたパッケージをインストールします。

en: executing the post-configuration scripts, <filename>/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename>;
ja: 設定後にスクリプト <filename>/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename> を実行します。

en: recording the installation logs, unmounting the partitions, and rebooting.
ja: インストールログを記録し、パーティションをアンマウントし、再起動します。

en: Preseeding Debian-Installer
ja: Debian-Installer の事前設定

en: <primary>preconfiguration</primary>
ja: <primary sortas="ジゼンセッテイ">事前設定</primary>

en: <emphasis>GOING FURTHER</emphasis> Debconf with a centralized database
ja: <emphasis>GOING FURTHER</emphasis> 中央集権型データベースを用いる Debconf

en: Preseeding allows to provide a set of answers to Debconf questions at installation time, but these answers are static and do not evolve as time passes. Since already-installed machines may need upgrading, and new answers may become required, the <filename>/etc/debconf.conf</filename> configuration file can be set up so that Debconf uses external data sources (such as an LDAP directory server, or a remote file accessed via NFS or Samba). Several external data sources can be defined at the same time, and they complement one another. The local database is still used (for read-write access), but the remote databases are usually restricted to reading. The <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page describes all the possibilities in detail (you need the <emphasis role="pkg">debconf-doc</emphasis> package).
ja: preseed を使うことで、インストール時に尋ねられる Debconf 質問に対する回答を事前に提供することが可能です。しかし、これらの回答は静的なもので、時間経過に従い変化しません。既にインストールされたマシンは更新が必要かもしれませんし、新しい回答が必要かもしれません。このため <filename>/etc/debconf.conf</filename> 設定ファイルから、Debconf が外部のデータソース (LDAP ディレクトリサーバ、NFS や Samba 経由でアクセスされるリモートファイル) を使うようにセットアップして、お互いに補完し合う複数の外部データソースを同時に定義することが可能です。とは言うものの、ローカルデータベースも使えます (読み書きアクセスできます)。これに対してリモートデータベースは読み込みのみに制限されていることが多いです。<citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> マニュアルページではすべての可能性が詳細に説明されています (このマニュアルは <emphasis role="pkg">debconf-doc</emphasis> パッケージに含まれます)。

en: Using a Preseed File
ja: preseed ファイルの利用

en: There are several places where the installer can get a preseeding file:
ja: インストーラが preseed ファイルを取得することが可能な場所にはいくつかあります。

en: in the initrd used to start the machine; in this case, preseeding happens at the very beginning of the installation, and all questions can be avoided. The file just needs to be called <filename>preseed.cfg</filename> and stored in the initrd root.
ja: マシンを開始するために使われる initrd の中。この場合、インストールの最初から preseed を行い、すべての質問を回避することが可能です。preseed ファイルの名前は必ず <filename>preseed.cfg</filename> にして initrd のルートに保存しなければいけません。

en: on the boot media (CD or USB key); preseeding then happens as soon as the media is mounted, which means right after the questions about language and keyboard layout. The <literal>preseed/file</literal> boot parameter can be used to indicate the location of the preseeding file (for instance, <filename>/cdrom/preseed.cfg</filename> when the installation is done off a CD-ROM, or <filename>/hd-media/preseed.cfg</filename> in the USB-key case).
ja: 起動メディア (CD や USB メモリ) の中。メディアがマウントされた直後から preseed が始まります。これは言語とキーボードレイアウトに関する質問の直後を意味します。<literal>preseed/file</literal> 起動パラメータを使って preseed ファイルの場所を指定することが可能です (たとえば、インストールが CD-ROM から開始された場合は <filename>/cdrom/preseed.cfg</filename>、USB メモリから開始された場合は <filename>/hd-media/preseed.cfg</filename> などです)。

en: At a glance, including the preseeding file in the initrd looks like the most interesting solution; however, it is rarely used in practice, because generating an installer initrd is rather complex. The other two solutions are much more common, especially since boot parameters provide another way to preseed the answers to the first questions of the installation process. The usual way to save the bother of typing these boot parameters by hand at each installation is to save them into the configuration for <command>isolinux</command> (in the CD-ROM case) or <command>syslinux</command> (USB key).
ja: 一見すると、preseed ファイルを initrd の中に含めることが最もうまい解決策のように見えます。しかし、実際のところこれはほとんど行われません。なぜなら、インストーラの initrd を生成することはかなり複雑だからです。その他の 2 種類の解決策はよく使われます。なぜなら起動パラメータを使うことで、インストール作業の最初の質問の回答を他のやり方で事前指定することが可能だからです。インストールごとに起動パラメータを手作業で打ち込む手間を省くためによく使われる方法は <command>isolinux</command> (CD-ROM の場合) や <command>syslinux</command> (USB メモリの場合) の設定ファイルに起動パラメータを保存することです。

en: Creating a Preseed File
ja: preseed ファイルの作成

en: A preseed file is a plain text file, where each line contains the answer to one Debconf question. A line is split across four fields separated by whitespace (spaces or tabs), as in, for instance, <literal>d-i mirror/suite string stable</literal>:
ja: preseed ファイルはプレーンテキストファイルで、各行に 1 つの Debconf 質問に対する回答が含まれます。行は空白 (スペースかタブ) で区切られた 4 種類のフィールドに分割されます。たとえば <literal>d-i mirror/suite string stable</literal> のようになります。

en: the first field is the “owner” of the question; “d-i” is used for questions relevant to the installer, but it can also be a package name for questions coming from Debian packages;
ja: 最初のフィールドはこの質問の「所有者」です。インストーラに関する質問の場合「d-i」を使い、Debian パッケージからの質問の場合パッケージ名を使います。

en: third, the type of question;
ja: 3 番目のフィールドは質問の種類です。

en: the fourth and last field contains the value for the answer. Note that it must be separated from the third field with a single space; if there are more than one, the following space characters are considered part of the value.
ja: 4 番目以降のフィールドは質問に対する回答です。3 番目のフィールドの後ろに必ず 1 つの空白を含めなければいけない点に注意してください。さらに 1 つ以上の回答がある場合、続く空白文字は回答の一部として取り扱われます。

en: The simplest way to write a preseed file is to install a system by hand. Then <command>debconf-get-selections --installer</command> will provide the answers concerning the installer. Answers about other packages can be obtained with <command>debconf-get-selections</command>. However, a cleaner solution is to write the preseed file by hand, starting from an example and the reference documentation: with such an approach, only questions where the default answer needs to be overridden can be preseeded; using the <literal>priority=critical</literal> boot parameter will instruct Debconf to only ask critical questions, and use the default answer for others.
ja: preseed ファイルを書く最も簡単な方法はシステムを手作業でインストールする方法です。インストール完了後に <command>debconf-get-selections --installer</command> を実行してインストーラに関連する回答を取得します。<command>debconf-get-selections</command> を使えば、他のパッケージに関連する回答を取得することが可能です。しかしながら、最も明確な解決策は記載例と基準文書を参考にしながら手作業で preseed ファイルを書くことです。なぜなら、このような取り扱い方をすることで、デフォルト回答に対して上書きが必要な質問だけに回答を事前指定することが可能だからです。さらに <literal>priority=critical</literal> 起動パラメータ使うことで、Debconf が重要な質問だけを尋ね、他の質問にはデフォルトの回答を使うようにすることが可能です。

en: <emphasis>DOCUMENTATION</emphasis> Installation guide appendix
ja: <emphasis>DOCUMENTATION</emphasis> インストールガイドの付録

en: Creating a Customized Boot Media
ja: カスタマイズされた起動メディアの作成

en: Knowing where to store the preseed file is all very well, but the location isn't everything: one must, one way or another, alter the installation boot media to change the boot parameters and add the preseed file.
ja: preseed ファイルを保存する場所を知ることは誠に結構なことですが、場所がすべてではありません。なぜなら、起動パラメータを変更し preseed ファイルを追加するためには、いずれにせよインストール用の起動メディアを改造しなければいけないからです。

en: Booting From the Network
ja: ネットワークからの起動

en: Preparing a Bootable USB Key
ja: 起動可能な USB メモリの準備

en: syslinux.cfg file and preseeding parameters
ja: syslinux.cfg ファイルと preseed パラメータ

en: Creating a CD-ROM Image
ja: CD-ROM イメージの作成

en: A USB key is a read-write media, so it was easy for us to add a file there and change a few parameters. In the CD-ROM case, the operation is more complex, since we need to regenerate a full ISO image. This task is handled by <emphasis role="pkg">debian-cd</emphasis>, but this tool is rather awkward to use: it needs a local mirror, and it requires an understanding of all the options provided by <filename>/usr/share/debian-cd/CONF.sh</filename>; even then, <command>make</command> must be invoked several times. <filename>/usr/share/debian-cd/README</filename> is therefore a very recommended read.
ja: USB メモリは読み書きメディアなので、ファイルを追加したりいくつかのパラメータを変更することが簡単に可能です。CD-ROM の場合、この操作はさらに複雑になります。なぜなら、完全な ISO イメージを再生成する必要があるからです。<emphasis role="pkg">debian-cd</emphasis> がこの作業を担当しますが、<emphasis role="pkg">debian-cd</emphasis> ツールは少し使いにくいです。すなわち、<emphasis role="pkg">debian-cd</emphasis> ツールを使うには、ローカルミラーと <filename>/usr/share/debian-cd/CONF.sh</filename> によって提供されるすべてのオプションについて理解する必要があります。そしてさらに、<command>make</command> を複数回実行する必要があります。このため、<filename>/usr/share/debian-cd/README</filename> を一読することを強く推奨します。

en: Simple-CDD: The All-In-One Solution
ja: Simple-CDD、一体型の解決策

en: Simply using a preseed file is not enough to fulfill all the requirements that may appear for large deployments. Even though it is possible to execute a few scripts at the end of the normal installation process, the selection of the set of packages to install is still not quite flexible (basically, only “tasks” can be selected); more important, this only allows installing official Debian packages, and precludes locally-generated ones.
ja: 単純に preseed ファイルを使うだけでは、大規模な配備に要求されるすべてを満足させることはできません。preseed ファイルを使うことで、通常のインストール作業の最後にいくつかのスクリプトを実行することが可能とは言うものの、インストールするパッケージ群の選択にはまだ大きな制限があります (基本的に「tasks」を選択できるだけです)。それどころかより重要なこととして、preseed ファイルを使えば公式の Debian パッケージをインストールすることが可能ですが、自前で作成したパッケージをインストールすることは不可能です。

en: Creating Profiles
ja: プロファイルの作成

en: Simple-CDD defines “profiles” that match the FAI “classes” concept, and a machine can have several profiles (determined at installation time). A profile is defined by a set of <filename>profiles/<replaceable>profile</replaceable>.*</filename> files:
ja: Simple-CDD は FAI における「クラス」の概念に対応する「プロファイル」を定義し、マシンは (インストール時に定義される) 複数のプロファイルを持つことが可能です。プロファイルは以下に挙げる <filename>profiles/<replaceable>profile</replaceable>.*</filename> ファイルを使って定義されます。

en: the <filename>.description</filename> file contains a one-line description for the profile;
ja: <filename>.description</filename> ファイル。プロファイルに関する 1 行の説明が含まれます。

en: the <filename>.packages</filename> file lists packages that will automatically be installed if the profile is selected;
ja: <filename>.packages</filename> ファイル。プロファイルが選択された場合に自動的にインストールするパッケージがリストされています。

en: the <filename>.downloads</filename> file lists packages that will be stored onto the installation media, but not necessarily installed;
ja: <filename>.downloads</filename> ファイル。インストールメディアに保存するがシステムにインストールしないパッケージがリストされています。

en: the <filename>.preseed</filename> file contains preseeding information for Debconf questions (for the installer and/or for packages);
ja: <filename>.preseed</filename> ファイル。(インストーラおよびパッケージの) Debconf 質問に関する preseed 情報が含まれます。

en: the <filename>.postinst</filename> file contains a script that will be run at the end of the installation process;
ja: <filename>.postinst</filename> ファイル。インストール作業の最後に実行されるスクリプトが含まれます。

en: The <literal>default</literal> profile has a particular role, since it is always selected; it contains the bare minimum required for Simple-CDD to work. The only thing that is usually customized in this profile is the <literal>simple-cdd/profiles</literal> preseed parameter: this allows avoiding the question, introduced by Simple-CDD, about what profiles to install.
ja: <literal>default</literal> プロファイルは特別な役割を担います。なぜなら <literal>default</literal> プロファイルは常に選択されるからです。そして <literal>default</literal> プロファイルには、Simple-CDD を動作させるために最低限必要な要素が含まれています。通常 <literal>default</literal> プロファイルの中でカスタマイズが必要なのは <literal>simple-cdd/profiles</literal> preseed パラメータだけです。なぜなら、これを使うことで Simple-CDD によって追加されたインストールするプロファイルの選択に関する質問を避けることが可能だからです。

en: Note also that the commands will need to be invoked from the parent directory of the <filename>profiles</filename> directory.
ja: コマンドは <filename>profiles</filename> ディレクトリの親ディレクトリから実行する必要がある点に注意してください。

en: Configuring and Using <command>build-simple-cdd</command>
ja: <command>build-simple-cdd</command> の設定と利用

en: <emphasis>QUICK LOOK</emphasis> Detailed configuration file
ja: <emphasis>QUICK LOOK</emphasis> 詳細説明を含む設定ファイル

en: Simple-CDD requires many parameters to operate fully. They will most often be gathered in a configuration file, which <command>build-simple-cdd</command> can be pointed at with the <literal>--conf</literal> option, but they can also be specified via dedicated parameters given to <command>build-simple-cdd</command>. Here is an overview of how this command behaves, and how its parameters are used:
ja: Simple-CDD を完全に動作させるには多くのパラメータが必要です。通常、パラメータは設定ファイルの中にまとめられ、この設定ファイルを <command>build-simple-cdd</command> の <literal>--conf</literal> オプションに指定します。しかし、パラメータは専用パラメータを <command>build-simple-cdd</command> に渡すことでも指定することも可能です。以下では、パラメータの使い方と <command>build-simple-cdd</command> の挙動を大ざっぱに説明しています。

en: the <literal>profiles</literal> parameter lists the profiles that will be included on the generated CD-ROM image;
ja: <literal>profiles</literal> パラメータは生成する CD-ROM イメージに含めるプロファイルをリストします。

en: based on the list of required packages, Simple-CDD downloads the appropriate files from the server mentioned in <literal>server</literal>, and gathers them into a partial mirror (which will later be given to debian-cd);
ja: Simple-CDD は要求されるパッケージのリストに基づいて、<literal>server</literal> で指定されているサーバから適切なファイルをダウンロードし、(後に debian-cd に渡される) ローカルミラーにまとめます。

en: the custom packages mentioned in <literal>local_packages</literal> are also integrated into this local mirror;
ja: また <literal>local_packages</literal> で指定されたカスタムパッケージがこのローカルミラーの中に統合されます。

en: debian-cd is then executed (within a default location that can be configured with the <literal>debian_cd_dir</literal> variable), with the list of packages to integrate;
ja: この後、組み込むパッケージのリストを使って debian-cd が実行されます (実行場所は <literal>debian_cd_dir</literal> 変数を使って設定されたデフォルト位置です)。

en: once debian-cd has prepared its directory, Simple-CDD applies some changes to this directory:
ja: debian-cd が <literal>debian_cd_dir</literal> で指定したディレクトリを用意した後、Simple-CDD はいくつかの変更をこのディレクトリに加えます。

en: files containing the profiles are added in a <filename>simple-cdd</filename> subdirectory (that will end up on the CD-ROM);
ja: プロファイルを含むファイルが <filename>simple-cdd</filename> サブディレクトリに追加されます (CD-ROM に追加されます)。

en: other files listed in the <literal>all_extras</literal> parameter are also added;
ja: <literal>all_extras</literal> パラメータで指定された他のファイルがディレクトリに追加されます。

en: the boot parameters are adjusted so as to enable the preseeding. Questions concerning language and country can be avoided if the required information is stored in the <literal>language</literal> and <literal>country</literal> variables.
ja: 起動パラメータが調整され、preseed が有効化されます。言語と国に関する質問を避けるには、これらの情報を <literal>language</literal> と <literal>country</literal> 変数に保存します。

en: debian-cd then generates the final ISO image.
ja: この後、debian-cd が最終的な ISO イメージを生成します。

en: Generating an ISO Image
ja: ISO イメージの生成

en: Monitoring is a generic term, and the various involved activities have several goals: on the one hand, following usage of the resources provided by a machine allows anticipating saturation and the subsequent required upgrades; on the other hand, alerting the administrator as soon as a service is unavailable or not working properly means that the problems that do happen can be fixed sooner.
ja: 監視は一般的な用語で、さまざまな目的で行われるさまざまな活動を意味します。すなわち一方では、マシンの提供するリソースが使い切られ、更新が必要になることを予測することが可能です。さらに他方では、サービスが利用できなくなったり適切に動作していないことを可能な限り早く管理者に警告することにより、発生した問題の早急な修正を可能にすることを意味します。

en: <emphasis>Munin</emphasis> covers the first area, by displaying graphical charts for historical values of a number of parameters (used RAM, occupied disk space, processor load, network traffic, Apache/MySQL load, and so on). <emphasis>Nagios</emphasis> covers the second area, by regularly checking that the services are working and available, and sending alerts through the appropriate channels (e-mails, text messages, and so on). Both have a modular design, which makes it easy to create new plug-ins to monitor specific parameters or services.
ja: <emphasis>Munin</emphasis> は最初の範囲をカバーします。すなわち <emphasis>Munin</emphasis> はいくつかのパラメータの経時変化をグラフィカルに図示します (使用された RAM、専有されたディスク領域、プロセッサの負荷、ネットワークトラフィック、Apache/MySQL の負荷などを図示します)。<emphasis>Nagios</emphasis> は 2 番目の範囲をカバーします。すなわち <emphasis>Nagios</emphasis> はサービスの稼働状態と利用可能状態を定期的に確認し、適切な経路 (電子メール、テキストメッセージなど) を通じて警告を送信します。<emphasis>Munin</emphasis> と <emphasis>Nagios</emphasis> はモジュール式に設計されているので、特定のパラメータやサービスを監視する新しいプラグインを簡単に作成できます。

en: <emphasis>ALTERNATIVE</emphasis> Zabbix, an integrated monitoring tool
ja: <emphasis>ALTERNATIVE</emphasis> Zabbix、統合監視ツール

en: <emphasis>ALTERNATIVE</emphasis> Icinga, a Nagios fork
ja: <emphasis>ALTERNATIVE</emphasis> Icinga、Nagios のフォーク

en: Setting Up Munin
ja: Munin のセットアップ

en: The purpose of Munin is to monitor many machines; therefore, it quite naturally uses a client/server architecture. The central host — the grapher — collects data from all the monitored hosts, and generates historical graphs.
ja: Munin の目的は多くのマシンを監視することです。そしてこのため、Munin は当然クライアント/サーバアーキテクチャを採用しています。グラフ化を担当している中央ホストがすべての監視されているホストからデータを収集し、データの履歴グラフを生成します。

en: Configuring Hosts To Monitor
ja: 監視対象ホストの設定

en: The first step is to install the <emphasis role="pkg">munin-node</emphasis> package. The daemon installed by this package listens on port 4949 and sends back the data collected by all the active plugins. Each plugin is a simple program returning a description of the collected data as well as the latest measured value. Plugins are stored in <filename>/usr/share/munin/plugins/</filename>, but only those with a symbolic link in <filename>/etc/munin/plugins/</filename> are really used.
ja: 最初に <emphasis role="pkg">munin-node</emphasis> パッケージをインストールします。<emphasis role="pkg">munin-node</emphasis> パッケージによってインストールされるデーモンはポート 4949 番をリッスンし、すべての動作しているプラグインによって収集されたデータを送り返します。それぞれのプラグインは収集されたデータの説明および最新の計測値を返す簡単なプログラムです。プラグインは <filename>/usr/share/munin/plugins/</filename> に保存されますが、実際に使われるのは <filename>/etc/munin/plugins/</filename> 内からシンボリックリンクを張られたプラグインだけです。

en: <emphasis>GOING FURTHER</emphasis> Creating local plugins
ja: <emphasis>GOING FURTHER</emphasis> ローカルプラグインの作成

en: A plugin is best tested when run in the same conditions as it would be when triggered by munin-node; this can be simulated by running <command>munin-run <replaceable>plugin</replaceable></command> as root. A potential second parameter given to this command (such as <literal>config</literal>) is passed to the plugin as a parameter.
ja: プラグインを検査するには、プラグインが munin-node から実行されたのと同じ状況下で実行するのが最良の方法です。この状況を模倣するには root で <command>munin-run <replaceable>plugin</replaceable></command> を実行します。このコマンドに与えられた 2 番目のパラメータ (<literal>config</literal> など) はパラメータとしてプラグインに渡されます。

en: When a plugin is invoked with the <literal>config</literal> parameter, it must describe itself by returning a set of fields:
ja: プラグインに <literal>config</literal> パラメータを付けて実行した場合、プラグイン自身を説明する一連のフィールドが返されます。

en: When invoked without a parameter, the plugin simply returns the last measured values; for instance, executing <command>sudo munin-run load</command> could return <literal>load.value 0.12</literal>.
ja: パラメータを付けずにプラグインを実行した場合、プラグインは最新の計測値を返却します。従って、たとえば <command>sudo munin-run load</command> を実行すると <literal>load.value 0.12</literal> が返されます。

en: Finally, when a plugin is invoked with the <literal>autoconf</literal> parameter, it should return “yes” (and a 0 exit status) or “no” (with a 1 exit status) according to whether the plugin should be enabled on this host.
ja: 最後に、プラグインに <literal>autoconf</literal> パラメータを付けて実行した場合、プラグインは自分が対象のホストで有効化されているか否かに基づいて「yes」(終了ステータス 0) または「no」(終了ステータス 1) を返すべきです。

en: Configuring the Grapher
ja: グラフ化担当マシンの設定

en: The “grapher” is simply the computer that aggregates the data and generates the corresponding graphs. The required software is in the <emphasis role="pkg">munin</emphasis> package. The standard configuration runs <command>munin-cron</command> (once every 5 minutes), which gathers data from all the hosts listed in <filename>/etc/munin/munin.conf</filename> (only the local host is listed by default), saves the historical data in RRD files (<emphasis>Round Robin Database</emphasis>, a file format designed to store data varying in time) stored under <filename>/var/lib/munin/</filename> and generates an HTML page with the graphs in <filename>/var/cache/munin/www/</filename>.
ja: 「グラフ化担当マシン」はデータを集計し対応するグラフを生成するだけのコンピュータです。「グラフ化担当マシン」に必要なソフトウェアは <emphasis role="pkg">munin</emphasis> パッケージに含まれます。標準的な設定は <command>munin-cron</command> を (5 分ごとに) 実行します。このコマンドは <filename>/etc/munin/munin.conf</filename> にリストされているすべてのホスト (デフォルトではローカルホストのみがリストされています) からデータを収集し、時系列データを <filename>/var/lib/munin/</filename> にある RRD ファイル (<emphasis>Round Robin Database</emphasis>、経時変化するデータを保存するために設計されたファイルフォーマット) に保存し、<filename>/var/cache/munin/www/</filename> に含まれるグラフを使って HTML ページを生成します。

en: All monitored machines must therefore be listed in the <filename>/etc/munin/munin.conf</filename> configuration file. Each machine is listed as a full section with a name matching the machine and at least an <literal>address</literal> entry giving the corresponding IP address.
ja: すべての監視対象のマシンは <filename>/etc/munin/munin.conf</filename> 設定ファイルにリストされていなければいけません。各マシンは完全なセクションの形でリストされています。セクションはマシンと同じ名前で、少なくとも対応する IP アドレスを指定する <literal>address</literal> エントリを持っていなければいけません。

en: Sections can be more complex, and describe extra graphs that could be created by combining data coming from several machines. The samples provided in the configuration file are good starting points for customization.
ja: セクションをさらに複雑にして、複数のマシンからのデータをまとめて作成されるグラフを追加することも可能です。設定ファイルの中で提供されている見本がカスタマイズの良い足掛かりとなります。

en: The last step is to publish the generated pages; this involves configuring a web server so that the contents of <filename>/var/cache/munin/www/</filename> are made available on a website. Access to this website will often be restricted, using either an authentication mechanism or IP-based access control. See <xref linkend="sect.http-web-server" /> for the relevant details.
ja: 最後の段階は生成されたページを公開することです。そしてこれは、ウェブサイトから <filename>/var/cache/munin/www/</filename> の内容を利用できるようにするようウェブサーバを設定することを意味しています。通常このウェブサイトへのアクセスは認証メカニズムか IP に基づくアクセス制御を使って制限されています。アクセス制御の詳細は<xref linkend="sect.http-web-server" />をご覧ください。

en: Setting Up Nagios
ja: Nagios のセットアップ

en: Unlike Munin, Nagios does not necessarily require installing anything on the monitored hosts; most of the time, Nagios is used to check the availability of network services. For instance, Nagios can connect to a web server and check that a given web page can be obtained within a given time.
ja: Munin と異なり、Nagios の場合、必ずしも監視対象のホストに何かをインストールする必要はありません。そしてほとんどの場合、Nagios はネットワークサービスの可用性を確認するために使われます。たとえば Nagios を使うことで、ウェブサーバに接続して特定のウェブページがある時間内に取得できるかを確認することが可能です。

en: Installing
ja: インストール

en: Configuring
ja: 設定

en: These files should not be dived into without some understanding of the Nagios concepts. The configuration lists objects of the following types:
ja: Nagios の概念を理解していない場合、オブジェクト設定ファイルの内容に立ち入るべきではありません。オブジェクト設定ファイルから設定するオブジェクトには以下の種類があります。

en: a <emphasis>host</emphasis> is a machine to be monitored;
ja: <emphasis>host</emphasis> は監視対象のマシンです。

en: a <emphasis>hostgroup</emphasis> is a set of hosts that should be grouped together for display, or to factor some common configuration elements;
ja: <emphasis>hostgroup</emphasis> はグループ化して表示されたり、同じ設定要素を持つホスト群です。

en: a <emphasis>service</emphasis> is a testable element related to a host or a host group. It will most often be a check for a network service, but it can also involve checking that some parameters are within an acceptable range (for instance, free disk space or processor load);
ja: <emphasis>service</emphasis> はホストやホストグループへの検査項目を定義します。これは多くの場合、あるネットワークサービスに対する検査を定義するものですが、いくつかのパラメータ (たとえば空きディスク領域やプロセッサ負荷) が条件を満たす範囲内にあるかに対する検査を定義することも可能です。

en: a <emphasis>servicegroup</emphasis> is a set of services that should be grouped together for display;
ja: <emphasis>servicegroup</emphasis> はグループ化して表示されるサービス群です。

en: a <emphasis>contact</emphasis> is a person who can receive alerts;
ja: <emphasis>contact</emphasis> は警告を受け取る人です。

en: a <emphasis>contactgroup</emphasis> is a set of such contacts;
ja: <emphasis>contactgroup</emphasis> は警告を受け取る人のグループです。

en: a <emphasis>timeperiod</emphasis> is a range of time during which some services have to be checked;
ja: <emphasis>timeperiod</emphasis> は時間範囲で、この範囲内にいくつかのサービスを確認します。

en: a <emphasis>command</emphasis> is the command line invoked to check a given service.
ja: <emphasis>command</emphasis> はサービスを確認するために実行するコマンドラインです。

en: According to its type, each object has a number of properties that can be customized. A full list would be too long to include, but the most important properties are the relations between the objects.
ja: オブジェクトの種類に応じて、各オブジェクトにはカスタマイズが可能な複数の属性が含まれます。完全なリストはここに挙げるには長すぎますが、最重要の属性はオブジェクト間の関係性を示す属性です。

en: A <emphasis>service</emphasis> uses a <emphasis>command</emphasis> to check the state of a feature on a <emphasis>host</emphasis> (or a <emphasis>hostgroup</emphasis>) within a <emphasis>timeperiod</emphasis>. In case of a problem, Nagios sends an alert to all members of the <emphasis>contactgroup</emphasis> linked to the service. Each member is sent the alert according to the channel described in the matching <emphasis>contact</emphasis> object.
ja: <emphasis>service</emphasis> は <emphasis>command</emphasis> を使い、<emphasis>timeperiod</emphasis> で定めた時間内に <emphasis>host</emphasis> (または <emphasis>hostgroup</emphasis>) で稼働する特定の機能を確認します。問題が起きた場合、Nagios はそのサービスに関連付けられた <emphasis>contactgroup</emphasis> のメンバーに警告を送信します。各メンバーは対応する <emphasis>contact</emphasis> オブジェクトに書かれたチャンネルを介して警告を受け取ります。

en: The Falcot Corp administrators use the following configuration:
ja: Falcot Corp の管理者は以下の設定を使います。

en: Note the use of inheritance: an object is made to inherit from another object with the “use <replaceable>parent-name</replaceable>”. The parent object must be identifiable, which requires giving it a “name <replaceable>identifier</replaceable>” property. If the parent object is not meant to be a real object, but only to serve as a parent, giving it a “register 0” property tells Nagios not to consider it, and therefore to ignore the lack of some parameters that would otherwise be required.
ja: 継承の使い方に注意してください。具体的に言えば、オブジェクトを継承するには「use <replaceable>parent-name</replaceable>」の形で親オブジェクトの名前を指定します。親オブジェクトは識別可能でなければいけません。つまり、親オブジェクトに「name <replaceable>identifier</replaceable>」属性を与える必要があります。親オブジェクトが真のオブジェクトでなく、属性継承の機能を担うだけの場合、このオブジェクトに「register 0」属性を与えます。こうすることで Nagios はこのオブジェクトを考慮しなくなり、真のオブジェクトならば必須とされるいくつかのパラメータが欠けていてもその問題を無視するようになります。

en: <emphasis>DOCUMENTATION</emphasis> List of object properties
ja: <emphasis>DOCUMENTATION</emphasis> オブジェクト属性のリスト

en: <emphasis>GOING FURTHER</emphasis> Remote tests with NRPE
ja: <emphasis>GOING FURTHER</emphasis> NRPE を使ったリモートマシンの状態検査
