en to ja translation catalogue (501 entries)

note: type: Title ==
en: Basic administrative tasks / Setup
ja: 基本管理タスク/設定

note: type: Plain text
en: LINSTOR is a configuration management system for storage on Linux systems.  It manages LVM logical volumes and/or ZFS ZVOLs on a cluster of nodes. It leverages DRBD for replication between different nodes and to provide block storage devices to users and applications. It manages snapshots, encryption and caching of HDD backed data in SSDs via bcache.
ja: LINSTORはLinuxシステムのストレージの構成管理システムです。クラスターノードのLVM論理ボリュームとZFS ZVOLを管理します。異なるノード間の複製にDRBDを利用し、ユーザとアプリケーションにブロックストレージデバイスを供給します。LINSTORはスナップショット、暗号化、bcacheを通してSSDのHDDバックアップデータのキャッシュを管理します。

note: Troubleshooting for LINSTOR guide? This chapter outlines typical administrative tasks encountered during day-to-day operations. It does not cover troubleshooting tasks, these are covered in detail in <<ch-troubleshooting>>. type: Title ===
en: Concepts and Terms
ja: 概念と用語

note: type: Plain text
en: This section goes over core concepts and terms that you will need to familiarize yourself with to understand how LINSTOR works and deploys storage. The section is laid out in a "ground up" approach.
ja: このセクションでは、LINSTORがどのように機能し、ストレージを展開するかを理解するために必要である基本的な概念と用語について説明します。このセクションは基礎から築く方法で構成されています。

note: type: Title ====
en: Installable Components
ja: インストール可能コンポーネント

note: type: Plain text
en: A LINSTOR setup requires at least one active controller and one or more satellites.
ja: LINSTOR のセットアップでは、少なくとも1つのアクティブコントローラと1つ以上のサテライトが必要です。

note: Once the chapter on making your controller HA is done we need to link that here type: Plain text
en: The _linstor-controller_ relies on a database that holds all configuration information for the whole cluster. It makes all decisions that need to have a view of the whole cluster. Multiple controllers can be used for LINSTOR but only one can be active.
ja: _linstor-controller_ には、クラスター全体のすべての構成情報を保持するデータベースに依存しています。それはクラスタ全体の情報を持ち必要なすべての決定を下します。LINSTOR には複数のコントローラーを使用できますが、アクティブにできるのは1つだけです。

note: type: Plain text
en: The _linstor-satellite_ runs on each node where LINSTOR consumes local storage or provides storage to services. It is stateless; it receives all the information it needs from the controller. It runs programs like `lvcreate` and `drbdadm`. It acts like a node agent.
ja: _linstor-satellite_ はローカルストレージを供給する、または、ストレージをサービスとして供給するすべてのノードで実行され、必要なすべての情報をコントローラから受け取ります。`lvcreate` や `drbdadm` がそこで実行され、ノードエージェントのように振る舞います。

note: type: Plain text
en: The _linstor-client_ is a command line utility that you use to issue commands to the system and to investigate the status of the system.
ja: _linstor-client_ はコマンドラインのユーティリティで、システムにコマンドを発行したり、ステータスを取得したりします。

note: type: Title ====
en: Objects
ja: オブジェクト

note: type: Plain text
en: Objects are the end result which LINSTOR presents to the end-user or application, such as; Kubernetes/OpenShift, a replicated block device (DRBD), NVMeOF target, etc.
ja: オブジェクトは、Kubernetes/OpenShift、複製ブロックデバイス(DRBD)、NVMeOFターゲットなどLINSTORがエンドユーザーまたはアプリケーションに提示する最終結果です。

note: type: Plain text
en: Node
ja: ノード

note: type: Plain text
en: Node's are a server or container that participate in a LINSTOR cluster. The _Node_ attribute defines:
ja: ノードは、LINSTORクラスタに参加するサーバーまたはコンテナです。ノード属性は、次のものを定義します。

note: type: Plain text
en: Determines which LINSTOR cluster the node participates in
ja: ノードが参加しているLINSTORクラスターを決定します

note: type: Plain text
en: Sets the role of the node: Controller, Satellite, Auxiliary
ja: ノードの役割を設定します：Controller、Satellite、Auxiliary

note: type: Plain text
en: *NetInterface* objects define the node's connectivity
ja: *NetInterface* オブジェクトはノードの接続を定義します

note: type: Plain text
en: As the name implies, this is how you define the interface/address of a node's network interface.
ja: 名前が示すように、これはノードのネットワークインターフェースのインターフェース/アドレスを定義します。

note: type: Plain text
en: Definitions define attributes of an object, they can be thought of as profile or template. Objects created will inherit the configuration defined in the definitions. A definition must be defined prior to creating the associated object.  For example; you must create a _ResourceDefinition_ prior to creating the _Resource_
ja: Definitions はオブジェクトの属性を定義します。それらはプロファイルまたはテンプレートと考えることができます。作成されるオブジェクトは、definition で定義されている設定を継承します。関連オブジェクトを作成する前に definition を定義する必要があります。例えば _Resource_ を作成する前に _ResourceDefinition_ を作成する必要があります。

note: type: Plain text
en: Defines the name of a storage pool
ja: ストレージプールの名前を定義します

note: type: Plain text
en: Resource definitions define the following attributes of a resource:
ja: ResourceDefinition は、リソースの以下の属性を定義します。

note: type: Plain text
en: The name of a DRBD resource
ja: DRBDリソースの名前

note: type: Plain text
en: The TCP port for DRBD to use for the resource's connection
ja: リソースの接続に使用するDRBDのTCPポート

note: type: Plain text
en: Volume definitions define the following:
ja: VolumeDefinition は以下を定義します。

note: type: Plain text
en: A volume of a DRBD resource
ja: DRBDリソースのボリューム

note: type: Plain text
en: The size of the volume
ja: ボリュームのサイズ

note: type: Plain text
en: The volume number of the DRBD resource's volume
ja: DRBDリソースのボリュームのボリューム番号

note: type: Plain text
en: The meta data properties of the volume
ja: ボリュームのメタデータプロパティ

note: type: Plain text
en: The minor number to use for the DRBD device associated with the DRBD volume
ja: DRBDボリュームに関連付けられているDRBDデバイスで使用するマイナー番号

note: type: Plain text
en: The _StoragePool_ identifies storage in the context of LINSTOR. It defines:
ja: _StoragePool_ は、LINSTORのコンテキストでストレージを識別し、以下を定義します：

note: type: Plain text
en: The configuration of a storage pool on a specific node
ja: 特定のノード上のストレージプールの構成

note: type: Plain text
en: The storage back-end driver to use for the storage pool on the cluster node (LVM, ZFS, etc)
ja: クラスタノード上のストレージプールで使用するストレージバックエンドドライバ(LVM, ZFSなど)

note: type: Plain text
en: The parameters and configuration to pass to the storage backed driver
ja: ストレージバックアップドライバに渡すパラメータとその設定

note: type: Plain text
en: Resource
ja: リソース

note: type: Plain text
en: LINSTOR has now has expanded its capabilities to manage a broader set of storage technologies outside of just DRBD. A _Resource_:
ja: LINSTORは、DRBDだけでなく、より幅広いストレージテクノロジを管理するように機能拡張されました。 リソースは

note: type: Plain text
en: Represents the placement of a DRBD resource, as defined within the _ResourceDefinition_
ja: _ResourceDefinition_ 内で定義される DRBDリソースの配備を表します。

note: type: Plain text
en: Places a resource on a node in the cluster
ja: クラスタ内のノードにリソースを配備します

note: type: Plain text
en: Defines the placement of a _ResourceDefinition_ on a node
ja: ノード上の _ResourceDefinition_ の配備を定義します

note: type: Title =====
en: Volume
ja: ボリューム

note: type: Plain text
en: Volumes are a subset of a _Resource_. A _Resource_ could have multiple volumes, for example you may wish to have your database stored on slower storage than your logs in your MySQL cluster.  By keeping the _volumes_ under a single _resource_ you are essentially creating a consistency group.  The _Volume_ attribute can define also define attributes on a more granular level.
ja: ボリュームはリソースのサブセットです。リソースには複数のボリュームを含めることができます。たとえば、データベースをMySQLクラスタ内のログよりも低速のストレージに格納したい場合があります。ボリュームを単一のリソースの下に置くことで、本質的にコンシステンシグループを作成します。ボリューム属性は、より詳細なレベルで属性を定義することもできます。

note: type: Title ===
en: Broader Context
ja: よりハイレベルな適用

note: type: Plain text
en: While LINSTOR might be used to make the management of DRBD more convenient, it is often integrated with software stacks higher up.  Such integration exist already for Kubernetes, OpenStack, OpenNebula and Proxmox. Chapters specific to deploying LINSTOR in these environments are included in this guide.
ja: LINSTORはDRBD管理をより便利にするものとして使われる一方で、よりハイレベルなソフトウェアスタックとしても使われます。例えば、Kubernetes、OpenStack、OpenNebula、Proxmoxなどが該当します。これらの環境でLINSTORを使用するには専用の各章を参照ください。

note: type: Plain text
en: The southbound drivers used by LINSTOR are LVM, thinLVM and ZFS.
ja: LINSTORのサウスバウンドドライバには、LVM、thinLVM、ZFSがあり、Swordfishのサポートも現在開発中です。

note: type: Title ===
en: Packages
ja: パッケージ

note: type: Plain text
en: LINSTOR is packaged in both the .rpm and the .deb variants:
ja: LINSTORはRPMとDEB形式でパッケージングされています。

note: type: Plain text
en: _linstor-client_ contains the command line client program. It depends on python which is usually already installed. In RHEL 8 systems you will need to symlink python
ja: _linstor-client_ にはコマンドラインのクライアントプログラムが含まれていて、通常すでにインストールされているpythonのみに依存しています。RHEL8 システムでは python をシンボリックリンクする必要があります。

note: type: Plain text
en: _linstor-controller_ and _linstor-satellite_ Both contain systemd unit files for the services. They depend on Java runtime environment (JRE) version 1.8 (headless) or higher.
ja: _linstor-controller_ と _linstor-satellite_ の両方に、サービス用のsystemdユニットファイルが含まれています。それらは Java Runtime Environment (JRE) version 1.8 (headless) 以上に依存します。

note: type: Plain text
en: For further detail about these packages see the <<Installable Components,Installable Components>> section above.
ja: これらのパッケージについての詳細は <<Installable Components,Installable Components>> を参照ください。

note: type: Plain text
en: If you have a support subscription to LINBIT, you will have access to our certified binaries via our repositories.
ja: LINBITのサポートサブスクリプションをお持ちの場合は、私たちのリポジトリを通して認定バイナリにアクセスしてください。

note: type: Title ===
en: Installation
ja: インストール

note: type: Plain text
en: If you want to use LINSTOR in containers skip this Topic and use the "Containers" section below for the installation.
ja: コンテナでLINSTORを使用する場合は、このトピックを飛ばして、下記の「コンテナ」セクションを参照ください。

note: type: Plain text
en: If you want to have the option of creating replicated storage using DRBD, you will need to install _drbd-dkms_ and _drbd-utils_. These packages will need to be installed on all nodes. You will also need to choose a volume manager, either ZFS or LVM, in this instance we're using LVM.
ja: DRBDを使用して複製ストレージを作成したい場合は、 _drbd-dkms_ と _drbd-utils_ をインストールする必要があります。これらのパッケージはすべてのノードにインストールする必要があります。また、ZFSかLVMのどちらかのボリュームマネージャを選択する必要があります。この例では、LVMを使用しています。

note: type: Plain text
en: Depending on whether your node is a LINSTOR controller, satellite, or both (Combined) will determine what packages are required on that node. For combined type nodes, we'll need both the controller and satellite LINSTOR package.
ja: ノードがLINSTORコントローラ、サテライト、またはその両方(Combined)のどれであるかに応じて、そのノードに必要なパッケージが決まります。Combinedノードの場合、コントローラとサテライトの両方のLINSTORパッケージが必要になります。

note: type: Plain text
en: Combined node:
ja: Combinedノード

note: type: Plain text
en: That will make our remaining nodes our Satellites, so we'll need to install the following packages on them:
ja: 残りのノードをサテライトにする場合、以下のパッケージをインストールします。

note: type: Plain text
en: SLES High Availability Extension (HAE) includes DRBD.
ja: SLES High Availability Extension (HAE) にDRBDが含まれています。

note: type: Plain text
en: On SLES, DRBD is normally installed via the software installation component of YaST2. It comes bundled with the High Availability package selection.
ja: SLESでは、DRBDは通常YaST2のソフトウェアインストールコンポーネントを介してインストールされます。 High Availabiltyパッケージにバンドルされています。

note: type: Plain text
en: As we download DRBD's newest module we can check if the LVM-tools are up to date as well. User who prefer a command line install may simply issue the following command to get the newest DRBD and LVM version:
ja: DRBDの最新モジュールをダウンロードすると、LVMツールも最新のものであるかどうかを確認できます。コマンドラインでインストールする場合、次のコマンドで最新のDRBDおよびLVMバージョンを入手できます。

note: type: Plain text
en: CentOS has had DRBD 8 since release 5. For DRBD 9 you'll need to look at EPEL and similar sources.  Alternatively, if you have an active support contract with LINBIT you can utilize our RHEL 8 repositories.  DRBD can be installed using `yum`. We can also check for the newest version of the LVM-tools as well.
ja: CentOS はリリース5以降、DRBD 8を含んでいます。DRBD 9に関しては、EPELと同様のソースを調べる必要があります。あるいは、LINBITとサポート契約をお持ちの場合は、RHEL 8リポジトリを利用できます。また、最新バージョンのLVMツールも確認できます。

note: type: Plain text
en: LINSTOR *requires* DRBD 9 if you wish to have replicated storage. This requires an external repository to be configured, either LINBIT's or a 3rd parties.
ja: LINSTOR で複製ストレージを使用する場合は、 *DRBD 9* が必要です。これには、LINBITまたはサードパーティのいずれかの外部リポジトリを設定する必要があります。

note: type: Plain text
en: On RHEL 8 systems you will need to install python2 for the linstor-client to work.
ja: RHEL 8システムでは、linstor-clientが機能するためにpython2をインストールする必要があります。

note: type: Title ===
en: Upgrading
ja: アップグレード

note: type: Plain text
en: LINSTOR doesn't support rolling upgrade, controller and satellites must have the same version, otherwise the controller with discard the satellite with a `VERSION_MISMATCH`.  But this isn't a problem, as the satellite won't do any actions as long it isn't connected to a controller and DRBD will not be disrupted by any means.
ja: LINSTORはローリングアップグレードをサポートしておらず、コントローラとサテライトは同じバージョンでなければなりません。そうでない場合、コントローラはサテライトを `VERSION_MISMATCH` と認識して接続ができません。しかしこの場合はデータの同期には問題はありません。サテライトがコントローラに接続しなければ何もアクションを起こさず、DRBDの動作が中断することもありません。

note: type: Plain text
en: If you are using the embedded default H2 database and the linstor-controller package is upgraded an automatic backup file of the database will be created in the default `/var/lib/linstor` directory.  This file is a good restore point if for any reason a linstor-controller database migration should fail, than it is recommended to report the error to LINBIT and restore the old database file and downgrade to your previous controller version.
ja: 組み込みのデフォルトH2データベースを使用していて、linstor-controllerパッケージがアップグレードされている場合は、デ ータベースの自動バックアップファイルがデフォルトの `/var/lib/linstor` ディレクトリに作成されます。このファイルは、何らかの理由でlinstor-controllerデータベースの移行が失敗した場合の適切な復元ポイントです。エラーをLINBITに 報告し、古いデータベースファイルを使って、以前のコントローラバージョンにダウングレードすることをお勧めします。

note: type: Plain text
en: If you use any external database or etcd, it is recommended to do a manually backup of your current database to have a restore point.
ja: 外部データベースまたはetcdを使用する場合は、現在のデータベースを手動でバックアップして復元ポイントを作成することをお勧めします。

note: type: Plain text
en: So first upgrade the `linstor-controller`, `linstor-client` package on you controller host and restart the `linstor-controller`, the controller should start and all of it's client should show `OFFLINE(VERSION_MISMATCH)`.  After that you can continue upgrading `linstor-satellite` on all satellite nodes and restart them, after a short reconnection time they should all show `ONLINE` again and your upgrade is finished.
ja: したがって、最初にコントローラホストの `linstor-controller` 、`linstor-client` パッケージをアップグレードし、 `linstor-controller` を再起動することで、すべてのクライアントが `OFFLINE（VERSION_MISMATCH）` を表示します。その後すべてのサテライトノードで `linstor-satellite` のアップグレードを続行して再起動することで、すべてのノードで再び `ONLINE` が表示され、アップグレードが完了します。

note: type: Title ===
en: Containers
ja: コンテナ

note: type: Plain text
en: LINSTOR is also available as containers. The base images are available in LINBIT's container registry, `drbd.io`.
ja: LINSTORはコンテナとしても利用可能です。ベースイメージはLINBITのコンテナレジストリ `drbd.io` にあります。

note: type: Plain text
en: In order to access the images, you first have to login to the registry (reach out to sales@linbit.com for credentials):
ja: イメージにアクセスするには、まずレジストリにログインする必要があります（アカウントについては sales@linbit.com にお問い合わせください）。

note: type: Plain text
en: The containers available in this repository are:
ja: このリポジトリで利用可能なコンテナは以下です。

note: type: Plain text
en: An up to date list of available images with versions can be retrieved by opening http://drbd.io in your browser. Make sure to access the host via "http", as the registry's images themselves are served via "https".
ja: ブラウザで http://drbd.io にアクセスすると、バージョン番号付きの利用可能なイメージの最新のリストを取得できます。レジストリのイメージ自体は "https" で提供されてますが、 "http" でホストにアクセスしてください。

note: type: Plain text
en: To load the kernel module, needed only for LINSTOR satellites, you'll need to run a `drbd9-$dist` container in privileged mode. The kernel module containers either retrieve an official LINBIT package from a customer repository, use shipped packages, or they try to build the kernel modules from source. If you intend to build from source, you need to have the according kernel headers (e.g., `kernel-devel`) installed on the host. There are 4 ways to execute such a module load container:
ja: LINSTOR サテライトにのみ必要なカーネルモジュールをロードするには、特権モードで `drbd9-$dist` コンテナを実行する必要があります。カーネルモジュールのコンテナは、モジュールをカスタマーリポジトリの LINBIT 公式パッケージから取得するか、出荷済みパッケージを使用するか、コンテナ内でソースからビルドします。ソースからビルドする場合、カーネルのヘッダ（`kernel-devel` ）をホストにインストールする必要があります。カーネルモジュールのコンテナを実行する方法は4つあります。

note: type: Plain text
en: Building from shipped source
ja: 出荷済みソースからビルドする。

note: type: Plain text
en: Using a shipped/pre-built kernel module
ja: 出荷済み/ビルド済みのカーネルモジュールの使用する。

note: type: Plain text
en: Specifying a LINBIT node hash and a distribution.
ja: LINBITノードのハッシュとディストリビューションを指定する。

note: type: Plain text
en: Bind-mounting an existing repository configuration.
ja: 既存のリポジトリ設定をバインドマウントする。

note: type: Plain text
en: Example building from shipped source (RHEL based):
ja: ソースからビルドする場合(RHEL ベース):

note: type: Plain text
en: Example using a module shipped with the container, which is enabled by *not* bind-mounting `/usr/src`:
ja: コンテナに同梱されているモジュールを使用した例、 `/usr/src` は *バインドマウントしません* :

note: type: Plain text
en: Example using a hash and a distribution (rarely used):
ja: ハッシュとディストリビューションを指定する場合: (あまり使わない):

note: type: Plain text
en: Example using an existing repo config (rarely used):
ja: 既存のリポジトリ設定を使う場合 (あまり使わない):

note: type: Plain text
en: In both cases (hash + distribution, as well as bind-mounting a repo)  the hash or config has to be from a node that has a special property set. Feel free to contact our support, and we set this property.
ja: どちらの場合でも（ハッシュ＋ディストリビューションまたは既存のリポジトリ設定をバインドマウント）、これらが設定されたノードから使用する必要があります。これらの設定に関してはサポートにお問い合わせください。

note: type: Plain text
en: For now (i.e., pre DRBD 9 version "9.0.17"), you must use the containerized DRBD kernel module, as opposed to loading a kernel module onto the host system. If you intend to use the containers you should not install the DRBD kernel module on your host systems. For DRBD version 9.0.17 or greater, you can install the kernel module as usual on the host system, but you need to make sure to load the module with the `usermode_helper=disabled` parameter (e.g., `modprobe drbd usermode_helper=disabled`).
ja: 今のところ（DRBD9 バージョン 9.0.17 より前では）、ホストシステムにカーネルモジュールをロードするのではなく、コンテナ化された DRBD カーネルモジュールを使用する必要があります。コンテナを使用する場合は、DRBD カーネルモジュールをホストシステムにインストールしないでください。バージョン 9.0.17 リリース以降はホストシステムにいつも通りカーネルモジュールをインストールできますが、 `usermode_helper = disabled` パラメータ（例えば `modprobe drbd usermode_helper=disabled` ）を使ってモジュールをロードする必要があります。

note: type: Plain text
en: Then run the LINSTOR satellite container, also privileged, as a daemon:
ja: 次に、デーモンとして特権モードで LINSTOR サテライトコンテナを実行します。

note: type: Plain text
en: `net=host` is required for the containerized `drbd-utils` to be able to communicate with the host-kernel via netlink.
ja: コンテナ化された `drbd-utils` がネットワークを通してホストカーネルと通信できるようにするには `net=host` が必要です。

note: type: Plain text
en: To run the LINSTOR controller container as a daemon, mapping ports `3370`, `3376` and `3377` on the host to the container:
ja: LINSTOR コントローラコンテナをデーモンとして実行するには、ホスト上のポート `3370`, `3376`, `3377` をコンテナにマッピングします。

note: type: Plain text
en: To interact with the containerized LINSTOR cluster, you can either use a LINSTOR client installed on a system via packages, or via the containerized LINSTOR client. To use the LINSTOR client container:
ja: コンテナ化された LINSTOR クラスタと対話するには、パッケージを介してシステムにインストールされた LINSTOR クライアント、またはコンテナ化された LINSTOR クライアントを使用することができます。 LINSTOR クライアントコンテナを使用するには

note: type: Plain text
en: From this point you would use the LINSTOR client to initialize your cluster and begin creating resources using the typical LINSTOR patterns.
ja: これ以降は、LINSTOR クライアントを使用してクラスタを初期化し、一般的な LINSTOR パターンを使用してリソースの作成を開始します。

note: type: Plain text
en: To stop and remove a daemonized container and image:
ja: デーモン化されたコンテナとイメージを停止して削除します。

note: type: Title ===
en: Initializing your cluster
ja: クラスタの初期化

note: type: Plain text
en: We assume that the following steps are accomplished on *all* cluster nodes:
ja: 以下の手順がすべてのクラスタノードですでに実行されていると仮定します。

note: type: Plain text
en: The DRBD9 kernel module is installed and loaded
ja: DRBD9カーネルモジュールがインストール、ロードされている。

note: type: Plain text
en: `drbd-utils` are installed
ja: `drbd-utils` がインストールされている。

note: type: Plain text
en: `LVM` tools are installed
ja: `LVM` ツールがインストールされている。

note: type: Plain text
en: `linstor-controller` and/or `linstor-satellite` its dependencies are installed
ja: `linstor-controller` , `linstor-satellite` とその依存パッケージがインストールされている。

note: type: Plain text
en: The `linstor-client` is installed on the `linstor-controller` node
ja: `linstor-client` は `linstor-controller` ノードにインストールされてている。

note: type: Plain text
en: Start and enable the linstor-controller service on the host where it has been installed:
ja: コントローラがインストールされているホストで linstor-controller サービスを起動して有効にします。

note: type: Plain text
en: If you are sure the linstor-controller service gets automatically enabled on installation you can use the following command as well:
ja: linstor-controllerサービスがインストール時に自動的に有効になる場合は、次のコマンドも使用できます。

note: type: Title ===
en: Using the LINSTOR client
ja: LINSTORクライアントの使用

note: type: Plain text
en: Whenever you run the LINSTOR command line client, it needs to know where your linstor-controller runs. If you do not specify it, it will try to reach a locally running linstor-controller listening on IP `127.0.0.1` port `3376`. Therefore we will use the `linstor-client` on the same host as the `linstor-controller`.
ja: LINSTORコマンドラインクライアントを実行するときは、常にlinstor-controllerがどこで実行されているか知る必要があります。何も指定してないときは、IP `127.0.0.1` port `3376` のローカルのlinstor-controllerを探しにいきます。そのため `linstor-controller` と同じホスト上で `linstor-client` を使います。

note: type: Plain text
en: The `linstor-satellite` requires ports 3366 and 3367. The `linstor-controller` requires ports 3376 and 3377. Make sure you have these ports allowed on your firewall.
ja: `linstor-satellite` はポート3366と3367を必要とします。 `linstor-controller` はポート3376と3377を必要とします。ファイアウォールでこれらのポートが許可されていることを確認してください。

note: type: Plain text
en: should give you an empty list and not an error message.
ja: これは空のノードリストをエラーメッセージなしで表示します。

note: type: Plain text
en: You can use the `linstor` command on any other machine, but then you need to tell the client how to find the linstor-controller. As shown, this can be specified as a command line option, an environment variable, or in a global file:
ja: `linstor` コマンドはどのマシンでも実行できます。ただし、クライアントにどのようにlinstor-controllerを探すか指定する必要があります。これはコマンドラインのオプションか、環境変数、またはグローバルファイルで指定できます。

note: type: Plain text
en: Alternatively you can create the `/etc/linstor/linstor-client.conf` file and populate it like below.
ja: あるいは、 `/etc/linstor/linstor-client.conf` ファイルを作成して、以下のように追加することもできます。

note: type: Plain text
en: If you have multiple linstor-controllers configured you can simply specify them all in a comma separated list. The linstor-client will simply try them in the order listed.
ja: 複数のlinstorコントローラが設定されている場合は、それらをカンマ区切りで指定します。linstor-clientはそれらをリストされた順番で試します。

note: type: Plain text
en: The linstor-client commands can also be used in a much faster and convenient way by only writing the starting letters of the parameters e.g.: `linstor node list` -> `linstor n l`
ja: linstor-clientコマンドは、パラメータの開始文字を書くだけで使える便利な方法があります。例えば: `linstor node list` -> `linstor n l`

note: type: Title ===
en: Adding nodes to your cluster
ja: ノードをクラスタに追加する

note: type: Plain text
en: The next step is to add nodes to your LINSTOR cluster.
ja: 次の手順ではノードを LINSTOR クラスタに追加します。

note: type: Plain text
en: If the IP is omitted, the client will try to resolve the given node-name as host-name by itself.
ja: IP が省略された場合、クライアントは指定されたノード名をホスト名として自分で解決しようとします。

note: type: Plain text
en: Linstor will automatically detect the node's local `uname -n` which is later used for the DRBD-resource.
ja: LINSTOR は、後で DRBD リソースに使用されるノードのローカル `uname -n` を自動的に検出します。

note: type: Plain text
en: When you use `linstor node list` you will see that the new node is marked as offline. Now start and enable the linstor-satellite on that node so that the service comes up on reboot as well:
ja: `linstor node list` を実行したとき、新しいノードはofflineとマークされています。ここで、以下のコマンドでlinstor-satelliteを起動し、有効にするとこで、再起動時も起動するようになります。

note: type: Plain text
en: You can also use `systemctl start linstor-satellite` if you are sure that the service is already enabled as default and comes up on reboot.
ja: サービスがすでにデフォルトで有効になっていて再起動時に起動する場合は、 `systemctl start linstor-satellite` を使うこともできます。

note: type: Plain text
en: About 10 seconds later you will see the status in `linstor node list` becoming online. Of course the satellite process may be started before the controller knows about the existence of the satellite node.
ja: 10秒後に `linstor node list` がonlineになるのを見るでしょう。もちろんコントローラが認識する前にlinstor-satelliteがすでに起動されているときもあります。

note: type: Plain text
en: In case the node which hosts your controller should also contribute storage to the LINSTOR cluster, you have to add it as a node and start the linstor-satellite as well.
ja: ノードがコントローラでかつクラスタにストレージも供給する場合は、同様にlinstor-satelliteを起動します。

note: type: Plain text
en: If you want to have other services wait until the linstor-satellite had a chance to create the necessary devices (i.e. after a boot), you can update the corresponding .service file and change `Type=simple` to `Type=notify`.
ja: linstor-satellite が必要なデバイスを作成する機会が得られるまで（ブート後など）他のサービスを待機させたい場合は、対応する .service ファイルを更新し、`Type=simple` を `Type=notify` に変更します。

note: type: Plain text
en: This will cause the satellite to delay sending the `READY=1` message to systemd until the controller connects, sends all required data to the satellite and the satellite at least tried once to get the devices up and running.
ja: これにより、サテライトはコントローラーが接続し、必要なすべてのデータをサテライトに送信し、サテライトがデバイスの起動と実行を少なくとも1回試行するまで、systemd への `READY=1` メッセージの送信を遅らせます。

note: type: Title ===
en: Storage pools
ja: ストレージプール

note: type: Plain text
en: <<StoragePool,StoragePools>> identify storage in the context of LINSTOR.  To group storage pools from multiple nodes, simply use the same name on each node.  For example, one valid approach is to give all SSDs one name and all HDDs another.
ja: <<StoragePool,StoragePools>> はLINSTORでストレージを識別します。複数のノードからのストレージプールをグループ化するために単純に各ノードで同じ名前を使います。例えば１つの有効な方法としてすべてのSSDに１つの名前をつけ、すべてのHDDに別の名前をつけます。

note: type: Plain text
en: On each host contributing storage, you need to create either an LVM VG or a ZFS zPool. The VGs and zPools identified with one LINSTOR storage pool name may have different VG or zPool names on the hosts, but do yourself a favor and use the same VG or zPool name on all nodes.
ja: ストレージを作成するために、LVM VGまたはZFS zPoolのどちらかを作成する必要があります。LINSTORストレージプール名とともに識別されるVGsやzPools名は、各ホストで別の名前にすることも可能ですが、すべてのノードで同じにすることを推奨します。

note: type: Plain text
en: These then need to be registered with LINSTOR:
ja: 次にこれらは以下のコマンドでLINSTORに登録します。

note: type: Plain text
en: The storage pool name and common metadata is referred to as a _storage pool definition_.  The listed commands create a storage pool definition implicitly.  You can see that by using `linstor storage-pool-definition list`.  Creating storage pool definitions explicitly is possible but not necessary.
ja: ストレージプール名は _ストレージプール定義_ として参照されます。上記コマンドはストレージプール定義を暗黙的に作成します。 `linstor storage-pool-definition list` を使って確認できます。明示的にストレージプール定義を作成することも可能ですが、必須ではありません。

note: type: Plain text
en: To list your storage-pools you can use:
ja: ストレージプールを表示するには、次のようにします。

note: type: Plain text
en: or using the short version
ja: またはショートバージョンを使います。

note: In case anything goes wrong with the storage pool's VG/zPool, e.g. the VG having been renamed or somehow became invalid you can delete the storage pool in LINSTOR with the following command, given that only resources with all their volumes in the so-called 'lost' storage pool are attached. This feat
en: Should the deletion of the storage pool be prevented due to attached resources or snapshots with some of its volumes in another still functional storage pool, hints will be given in the 'status' column of the corresponding list-command (e.g. `linstor resource list`). After deleting the LINSTOR-objects in the lost storage pool manually, the lost-command can be executed again to ensure a complete deletion of the storage pool and its remaining objects.
ja: まだ動作中のリソースまたはスナップショットがアタッチされていて、ストレージプールの削除ができない場合は、対応方法のヒントが関連する list コマンドの status 項に表示されます（例: `linstor resource list` ）。削除されたストレージプールの LINSTOR オブジェクトを手動で削除した後、再度 lost コマンドを実行することで、ストレージプールとその残りのオブジェクトを確実に削除することができます。

note: type: Title ====
en: A storage pool per backend device
ja: 下位デバイスごとのストレージプール

note: type: Plain text
en: In clusters where you have only one kind of storage and the capability to hot-repair storage devices, you may choose a model where you create one storage pool per physical backing device. The advantage of this model is to confine failure domains to a single storage device.
ja: クラスタ内にホット修復機能を備えたストレージしか持たないクラスタでは、物理的な下位デバイスごとに1つのストレージプールを作成するモデルを選択のもよいかもしれません。このモデルの利点は、障害ドメインを単一のストレージデバイスに限定することです。

note: type: Title ====
en: Physical storage command
ja: 物理ストレージコマンド

note: type: Plain text
en: Since linstor-server 1.5.2 and a recent linstor-client, LINSTOR can create LVM/ZFS pools on a satellite for you.  The linstor-client has the following commands to list possible disks and create storage pools, but such LVM/ZFS pools are not managed by LINSTOR and there is no delete command, so such action must be done manually on the nodes.
ja: linstor-server 1.5.2 以降および最新の linstor-client では、LINSTOR はサテライト上に LVM/ZFS プールを作成できます。 linstor-client には、次のように可能なディスクをリストしてストレージプールを作成するためのコマンドがあります。ただし、LVM/ZFS プールは LINSTOR によって管理されないので、削除コマンドはありません。そのため削除はノードで手動で実行する必要があります。

note: type: Plain text
en: Will give you a list of available disks grouped by size and rotational(SSD/Magnetic Disk).
ja: これはサイズと回転方式 (SSD/磁気ディスク) でグループ化された使用可能なディスクのリストを表示します。

note: type: Plain text
en: It will only show disks that pass the following filters:
ja: 次のフィルターを通過するディスクのみが表示されます。

note: type: Plain text
en: The device size must be greater than 1GiB
ja: デバイスサイズは 1GiB より大きい

note: type: Plain text
en: The device is a root device (not having children) e.g.: /dev/vda, /dev/sda
ja: デバイスはルートデバイス（子はなし）例： /dev/vda, /dev/sda

note: type: Plain text
en: The device does not have any file-system or other `blkid` marker (`wipefs -a` might be needed)
ja: デバイスにはファイルシステムやその他の `blkid` マーカー（ `wipefs -a` が必要な場合があります）がない

note: type: Plain text
en: The device is no DRBD device
ja: デバイスは DRBD デバイスでない

note: type: Plain text
en: With the `create-device-pool` command you can create a LVM pool on a disk and also directly add it as a storage-pool in LINSTOR.
ja: `create-device-pool` コマンドを使用して、ディスク上に LVM プールを作成し、LINSTOR のストレージプールとして直接追加することもできます。

note: type: Plain text
en: If the `--storage-pool` option was provided, LINSTOR will create a storage-pool with the given name.
ja: `--storage-pool` オプションを指定した場合、LINSTOR は指定した名前で storage-pool を作成します。

note: type: Plain text
en: For more options and exact command usage please check the linstor-client help.
ja: その他のオプションとコマンドの使用法については、linstor-client のヘルプを参照ください。

note: type: Title ===
en: Resource groups
ja: リソースグループ

note: type: Plain text
en: A resource group is a parent object of a resource definition where all property changes made on a resource group will be inherited by it's resource definition children. The resource group also stores settings for automatic placement rules and can spawn a resource definition depending on the stored rules.
ja: リソースグループはリソース定義の親オブジェクトであり、リソースグループで行われたすべてのプロパティ変更はそのリソース定義の子によって継承されます。リソースグループは自動配置ルールの設定も可能で、このルールに依存するリソース定義を生成できます。

note: type: Plain text
en: In simpler terms, resource groups are like templates that define characteristics of resources created from them. Changes to these pseudo templates will be applied to all resources that were created from the resource group, retroactively.
ja: 言いかえると、リソースグループは、それらから作成されるリソースの特性を定義するテンプレートのようなものです。これらの擬似テンプレートへの変更は、リソースグループから作成されたすべてのリソースにさかのぼって適用されます。

note: type: Plain text
en: Using resource groups to define how you'd like your resources provisioned should be considered the de facto method for deploying volumes provisioned by LINSTOR. Chapters that follow which describe creating each _resource_ from a _resource-definition_ and _volume-definition_ should only be used in special scenarios.
ja: リソースグループを使用して、リソースのプロビジョニング方法を定義することは、 LINSTOR によってプロビジョニングするボリュームをデプロイするための事実上標準の方法と見なされます。_resource-definition_ と _volume-definition_ から各 _resource_ を作成する方法は、特別なシナリオでのみで使用してください。

note: type: Plain text
en: Even if you choose not to create and use _resource-groups_ in your LINSTOR cluster, all resources created from _resource-definitions_ and _volume-definitions_ will exist in the 'DfltRscGrp' _resource-group_.
ja: LINSTOR で _resource-groups_ を使用しないことにした場合でも、 _resource-definitions_ と _volume-definitions_ から作成されたすべてのリソースは 'DfltRscGrp' _resource-group_ に作成されます。

note: type: Plain text
en: A simple pattern for deploying resources using resource groups would look like this:
ja: リソースグループを使用してリソースをデプロイする簡単なパターンは次のようになります。

note: type: Plain text
en: The commands above would result in a resource named 'my_ssd_res' with a 20GB volume replicated twice being automatically provisioned from nodes who participate in the storage pool named 'pool_ssd'.
ja: 上記のコマンドを実行すると 'pool_ssd' という名前のストレージプールに参加するノードから、２つに複製された 20GB ボリュームを持つ 'my_ssd_res' という名前のリソースが自動的にプロビジョニングされます。

note: type: Plain text
en: A more useful pattern could be to create a resource group with settings you've determined are optimal for your use case. Perhaps you have to run nightly online verifications of your volumes' consistency, in that case, you could create a resource group with the 'verify-alg' of your choice already set so that resources spawned from the group are pre-configured with 'verify-alg' set:
ja: より有効なパターンは、ユースケースが最適であると判断した設定でリソースグループを作成することです。もし一貫性のためボリュームの夜間オンライン検証を実行する必要があるというケースの場合、'verify-alg' がすでに設定されたリソースグループを作成することで、グループから生成されるリソースは 'verify-alg' が事前設定されます。

note: type: Plain text
en: The commands above result in twenty 10GiB resources being created each with the 'crc32c' 'verify-alg' pre-configured.
ja: 上記のコマンドを実行すると、20 個の 10GiB リソースが作成され、それぞれに 'crc32c', 'verify-alg' が事前設定されます。

note: type: Plain text
en: You can tune the settings of individual resources or volumes spawned from resource groups by setting options on the respective _resource-definition_ or _volume-definition_. For example, if 'res11' from the example above is used by a very active database receiving lots of small random writes, you might want to increase the 'al-extents' for that specific resource:
ja: _resource-definition_ または _volume-definition_ のオプションを設定することにより、リソースグループから生成される個々のリソースまたはボリュームの設定を調整できます。たとえば、上記の例の 'res11' が多数の小さなランダム書き込みを受信する非常にアクティブなデータベースで使用されている場合、その特定のリソースの 'al-extents' を増やすことができます。

note: type: Plain text
en: If you configure a setting in a _resource-definition_ that is already configured on the _resource-group_ it was spawned from, the value set in the _resource-definition_ will override the value set on the parent _resource-group_. For example, if the same 'res11' was required to use the slower but more secure 'sha256' hash algorithm in its verifications, setting the 'verify-alg' on the _resource-definition_ for 'res11' would override the value set on the _resource-group_:
ja: 生成された _resource-group_ で既に構成されている _resource-definition_ の設定を構成すると、_resource-definition_ で設定された値は親 _resource-group_ で設定された値を上書きします。たとえば、遅くなるがより安全な 'sha256' ハッシュアルゴリズム検証を使用することが 'res11' で必要な場合、'res11' の _resource-definition_ で 'verify-alg' を設定すると、_resource-group_ の値が上書きされます。

note: type: Plain text
en: A rule of thumb for the hierarchy in which settings are inherited is the value "closer" to the resource or volume wins: _volume-definition_ settings take precedence over _volume-group_ settings, and _resource-definition_ settings take precedence over _resource-group_ settings.
ja: どの設定が階層で継承されるかのおおざっぱな目安は、リソースまたはボリュームにより近い設定が使われるというです。volume-definition_ 設定は _volume-group_ 設定より優先され、 _resource-definition_ 設定は _resource-group_ より優先されます。

note: type: Title ===
en: Cluster configuration
ja: クラスタ構成

note: type: Title ====
en: Available storage plugins
ja: 利用可能なストレージプラグイン

note: type: Plain text
en: LINSTOR has the following supported storage plugins as of writing:
ja: LINSTORは以下のストレージプラグインをサポートしています。

note: type: Plain text
en: Thin LVM with a single thin pool
ja: 単一の thin プールの Thin LVM

note: type: Title ===
en: Creating and deploying resources/volumes
ja: リソース、ボリュームの作成と配備

note: type: Plain text
en: In the following scenario we assume that the goal is to create a resource 'backups' with a size of '500 GB' that is replicated among three cluster nodes.
ja: 以下の例では、500 GBのサイズをもつリソースを作成し、３つのクラスタノード間で複製されるというシナリオを紹介します。

note: type: Plain text
en: First, we create a new resource definition:
ja: 最初に新しいリソースの定義を作成します。

note: type: Plain text
en: Second, we create a new volume definition within that resource definition:
ja: 次にこのリソースをもつ新しいボリュームの定義を作成します。

note: type: Plain text
en: If you want to change the size of the volume-definition you can simply do that by:
ja: volume-definition のサイズを変更したい場合は、次のようにして簡単に行うことができます。

note: type: Plain text
en: The parameter `0` is the number of the volume in the resource `backups`. You have to provide this parameter , because resources can have multiple volumes and they are identified by a so called volume-number. This number can be found by listing the volume-definitions.
ja: パラメータ `0` は、リソース `backups` 内のボリュームの番号である。リソースは複数のボリュームを持つことができ、それらはボリューム番号で識別されるため、このパラメーターを指定する必要があります。この番号は、volume-definition をリストすることによって見つけることができます。

note: type: Plain text
en: The size of a volume-definition can only be decreased if it has no resource. Despite of that the size can be increased even with an deployed resource.
ja: volume-definition のサイズは、リソースがない場合にのみ減らすことができます。増やす場合はデプロイされたリソースに対しても可能です。

note: type: Plain text
en: So far we have only created objects in LINSTOR's database, not a single LV was created on the storage nodes. Now you have the choice of delegating the task of placement to LINSTOR or doing it yourself.
ja: ここまではLINSTORのデータベースにオブジェクトが作成されただけで、ストレージノードのLVには作成されていません。この後はLINSTORに配備作業を委任するか自分でやるか選択できます。

note: type: Title ====
en: Manual placement
ja: 手動配備

note: type: Plain text
en: With the `resource create` command you may assign a resource definition to named nodes explicitly.
ja: `resource create` コマンドでリソース定義を指定したノードに明示的に割り当てることができます。

note: type: Title ====
en: Autoplace
ja: 自動配備

note: type: Plain text
en: The value after autoplace tells LINSTOR how many replicas you want to have.  The storage-pool option should be obvious.
ja: オプション--auto-placeに続く数値は複製の数を指定します。--storage-poolはストレージプール名を指定します。

note: type: Plain text
en: Maybe not so obvious is that you may omit the `--storage-pool` option, then LINSTOR may select a storage pool on its own. The selection follows these rules:
ja: ストレージプール名がはっきりしない場合、`--storage-pool` を省略できます。この場合、LINSTORが以下のルールに基づいてストレージプールを選択します。

note: type: Plain text
en: Ignore all nodes and storage pools the current user has no access to
ja: 現在のユーザがアクセスできないすべてのノードとストレージプールは無視する。

note: type: Plain text
en: Ignore all diskless storage pools
ja: すべてのディスクレスストレージプールは無視する

note: type: Plain text
en: Ignore all storage pools not having enough free space
ja: 十分な空き領域がないストレージプールは無視する

note: type: Plain text
en: The remaining storage pools will be rated by different strategies.  LINSTOR has currently three strategies:
ja: 残りのストレージプールは、さまざまな方針によって評価されます。 LINSTORには現在4つの方針があります。

note: type: Plain text
en: `MaxFreeSpace`: This strategy maps the rating 1:1 to the remaining free space of the storage pool. However, this strategy only considers the actually allocated space (in case of thinly provisioned storage pool this might grow with time without creating new resources)
ja: `MaxFreeSpace` : この方針は、ストレージプールの残りの空き領域に 1:1 のレートでマップしますが、実際に割り当てられたスペースのみを考慮します（シンプロビジョニングされたストレージプールの場合、新しいリソースを作成しなくても時間とともに増加する可能性があります）。

note: type: Plain text
en: `MinReservedSpace`: Unlike the "MaxFreeSpace", this strategy considers the reserved spaced. That is the space that a thin volume can grow to before reaching its limit. The sum of reserved spaces might exceed the storage pools capacity, which is as overprovisioning.
ja: `MinReservedSpace` : "MaxFreeSpace" と異なり、この方針では、予約済みのスペースが考慮されます。これは、シンボリュームが限界に達する前の拡張できるスペースです。予約済みスペースの合計がオーバープロビジョニングになって、ストレージプールの容量を超える可能性があります。

note: type: Plain text
en: `MinRscCount`: Simply the count of resources already deployed in a given storage pool
ja: `MinRscCount` : 指定されたストレージプールで、単純にすでにデプロイされているリソース数をカウントします。

note: type: Plain text
en: `MaxThroughput`: For this strategy, the storage pool's `Autoplacer/MaxThroughput` property is the base of the score, or 0 if the property is not present. Every Volume deployed in the given storage pool will subtract its defined `sys/fs/blkio_throttle_read` and `sys/fs/blkio_throttle_write` property- value from the storage pool's max throughput. The resulting score might be negative.
ja: `MaxThroughput` : この方針では、ストレージプールの `Autoplacer/MaxThroughput` プロパティがスコアのベースになります（プロパティが存在しない場合は 0 ）。特定のストレージプールにデプロイされたすべてのボリュームは、ストレージプールの最大スループットから定義された `sys/fs/blkio_throttle_read` および `sys/fs/blkio_throttle_write` の値が差し引かれます。結果のスコアはマイナスになる可能性があります。

note: type: Plain text
en: The scores of the strategies will be normalized, weighted and summed up, where the scores of minimizing strategies will be converted first to allow an overall maximization of the resulting score.
ja: 各方針のスコアは正規化され、重み付けされ、合計されます。この場合、最小化方針のスコアが最初に変換され、結果として得られるスコアの全体的な最大化が可能になります。

note: type: Plain text
en: The weights of the strategies can be configured with
ja: 方針のウェイトは以下で変更できます。

note: type: Plain text
en: whereas the strategy-names are listed above and the weight can be an arbitrary decimal.
ja: ここで方針名とウェイトとして任意の10進数を指定します。

note: type: Plain text
en: To keep the behaviour of the autoplacer similar to the old one (due to compatibility), all strategies have a default-weight of 0, except the `MaxFreeSpace` which has a weight of 1.
ja: 互換性のため以前の autoplacer の動作と同じにするには `MaxFreeSpace` の重みを 1 にし、残りの方針の重みを 0 にします。

note: type: Plain text
en: Neither 0 nor a negative score will prevent a storage pool from getting selected, just making them to be considered later.
ja: 0 でも負のスコアでも、ストレージプールが選択されるのを防ぐことはできず、後ほど考慮されるようになります。

note: type: Plain text
en: Finally LINSTOR tries to find the best matching group of storage pools meeting all requirements. This step also considers other autoplacement restrictions as `--replicas-on-same`, `--replicas-on-different` and others.
ja: 最後に LINSTOR はすべての要件を満たすストレージプールの最適なグループを見つけようとします。このステップでは、他の自動配置の制限 `--replicas-on-same`, `--replicas-on-different` なども考慮されます。

note: type: Plain text
en: These two arguments, `--replicas-on-same` and `--replicas-on-different` expect the name of a property within the `Aux/` namespace. The following example shows that the client automatically prefixes the `testProperty` with the `Aux/` namespace.
ja: これらの2つの引数 `--replicas-on-same` と `--replicas-on-different` は `Aux/` 名前空間内のプロパティの名前を想定しています。次の例は、クライアントが自動的に `testProperty` の前に `Aux/` 名前空間を付けることを示しています。

note: type: Plain text
en: If everything went right the DRBD-resource has now been created by LINSTOR.  This can be checked by looking for the DRBD block device with the `lsblk` command which should look like `drbd0000` or similar.
ja: すべてがうまくいくと、DRBDリソースがLINSTORによって作成されます。 `lsblk` コマンドでDRBDブロックデバイスを探すことで確認でき、 `drbd0000` のように見えるはずです。

note: type: Plain text
en: Now we should be able to mount the block device of our resource and start using LINSTOR.
ja: これでリソースのブロックデバイスをマウントしてLINSTORを使い始めることができるはずです。

note: type: Title ==
en: Further LINSTOR tasks
ja: LINSTOR 応用タスク

note: type: Title ===
en: LINSTOR high availability
ja: LINSTOR 高可用性

note: type: Plain text
en: By default a LINSTOR cluster consists of exactly one LINSTOR controller. Making LINSTOR highly-available involves providing replicated storage for the controller database, multiple LINSTOR controllers where only one is active at a time, and a service manager that takes care of mounting/unmounting the highly-available storage and starting/stopping LINSTOR controllers.
ja: デフォルトでは、LINSTOR クラスターは 1 つの LINSTOR コントローラーで構成されます。LINSTOR の高可用性を実現するには、コントローラーデータベースの複製されたストレージ、一度に 1 つだけがアクティブになる複数の LINSTOR コントローラー、および高可用性ストレージのマウント/アンマウントと LINSTOR コントローラーの開始/停止を処理するサービスマネージャーを提供する必要があります。

note: type: Title ====
en: Highly-available Storage
ja: 高可用性ストレージ

note: type: Plain text
en: For configuring the highly-available storage we use LINSTOR itself. This has the advantage that the storage is under LINSTOR control and can for example be easily extended to new cluster nodes. Just create a new resource with 200MB in size. This could look like this, you certainly need to adapt the storage pool name:
ja: 高可用性ストレージを構成するには、LINSTOR 自体を使用します。これには、ストレージが LINSTOR の制御下にあり、たとえば新しいクラスターノードに簡単に拡張できるという利点があります。サイズが 200MB の新しいリソースを作成するだけです。これは次のようになります。ストレージプール名は環境に合わせて変更してください。

note: type: Plain text
en: From now on we assume the resource's name is "linstor_db". It is crucial that your cluster qualifies for auto-quorum and uses the `io-error` policy (see Section <<s-linstor-auto-quorum>>), and that `auto-promote` is disabled.
ja: これ以降、リソース名は "linstor_db" であると仮定します。クラスターが自動クォーラム (<<s-linstor-auto-quorum>> を参照) の対象になっていて `io-error` ポリシーを使用していることが重要です。また `auto-promote` を無効にします。

note: type: Plain text
en: After the resource is created, it is time to move the LINSTOR DB to the new storage and to create a `systemd` mount service. First we stop the current controller and disable it, as it will be managed by `drbd-reactor` later.
ja: リソースが作成されたら、LINSTOR DB を新しいストレージに移動し `systemd` マウントサービスを作成します。後ほど `drbd-reactor` によって管理されるため、最初に現在のコントローラーを停止して無効にします。

note: type: Plain text
en: copy the `/etc/systemd/system/var-lib-linstor.mount` mount file to all the standby nodes for the linstor controller.  Again, do not `systemctl enable` any of these services, they get managed by `drbd-reactor`.
ja: `/etc/systemd/system/var-lib-linstor.mount` マウントファイルを linstor コントローラーのすべてのスタンバイノードにコピーします。繰り返しますが、これらのサービスを `systemctl enable` しないでください。これらは `drbd-reactor` によって管理されます。

note: type: Title ====
en: Multiple LINSTOR controllers
ja: 複数のLINSTORコントローラー

note: type: Plain text
en: The next step is to install LINSTOR controllers on all nodes that have access to the `linstor_db` DRBD resource (as they need to mount the DRBD volume) and which you want to become a possible LINSTOR controller. It is important that the controllers are manged by `drbd-reactor`, so make sure the `linstor-controller.service` is disabled on all nodes! To be sure, execute `systemctl disable linstor-controller` on all cluster nodes and `systemctl stop linstor-controller` on all nodes except the one it is currently running from the previous step. Also make sure to set `chattr +i /var/lib/linstor` on all potential controller nodes if you use LINSTOR version equal or greater to 1.14.0.
ja: 次のステップは、"linstor_db" DRBD リソースにアクセスでき（DRBD ボリュームをマウントする必要があるため）、LINSTOR コントローラーになる可能性のあるすべてのノードに LINSTOR コントローラーをインストールすることです。コントローラが `drbd-reactor` によって管理されていることが重要なので、すべてのノードで `linstor-controller.service` が無効になっていることを確認してください。すべてのクラスターノードで `systemctl disable linstor-controller` を実行し、前の手順で現在実行しているノードを除くすべてのノードで `systemctl stop linstor-controller` を実行します。また、LINSTOR バージョン 1.14.0 以上を使用している場合、すべての潜在的なコントローラーノードで `chattr +i /var/lib/linstor` を設定してください。

note: type: Title ====
en: Managing the services
ja: サービスの管理

note: type: Plain text
en: For starting and stopping the mount service and the linstor-controller service we use `drbd-reactor`. Install this component on all nodes that could become a LINSTOR controller and edit their `/etc/drbd-reactor.d/linstor_db.toml` configuration file. It should contain an enabled promoter plugin section like this:
ja: マウントサービスと linstor-controller サービスの開始と停止には `drbd-reactor` を使用します。LINSTOR コントローラーになる可能性のあるすべてのノードにこのコンポーネントをインストールし、それらの `/etc/drbd-reactor.d/linstor_db.toml` 構成ファイルを編集します。次のような有効な promoter プラグインセクションが含まれている必要があります。

note: type: Plain text
en: Depending on your requirements you might also want to set an `on-stop-failure` action and set `stop-services-on-exit`.
ja: 要件によっては `on-stop-failure` と `stop-services-on-exit` アクションを設定します。

note: type: Plain text
en: After that restart `drbd-reactor` and enable it on all the nodes you configured it.
ja: その後 `drbd-reactor` を再起動し、構成したすべてのノードで有効にします。

note: type: Plain text
en: Check that there are no warnings from drbd-reactor in the logs by running `systemctl status drbd-reactor`.  As there is already an active LINSTOR controller things will just stay the way they are.  Run `drbd-reactorctl status linstor_db` to check the health of the linstor_db target unit.
ja: `systemctl status drbd-reactor` を実行して、ログに drbd-reactor からの警告がないことを確認します。すでにアクティブな LINSTOR コントローラーが存在するため、状況に変化はあらわれません。 `drbd-reactorctl status linstor_db` を実行して、linstor_db ターゲットユニットの状態を確認します。

note: type: Plain text
en: The last but never the less important step is to configure the LINSTOR satellite services to not delete (and then regenerate) the resource file for the LINSTOR controller DB at its startup. Do not edit the service files directly, but use `systemctl edit`. Edit the service file on all nodes that could become a LINSTOR controller and that are also LINSTOR satellites.
ja: 最後のステップは、起動時に LINSTOR コントローラー DB のリソースファイルを削除（および再生成）しないように LINSTOR サテライトサービスを構成することです。サービスファイルを直接編集するのではなく、 `systemctl edit` を使用してください。LINSTOR コントローラーとサテライトになるすべてのノードでサービスファイルを編集します。

note: type: Plain text
en: After this change you should execute `systemctl restart linstor-satellite` on all satellite nodes.
ja: この変更後、すべてのサテライトノードで `systemctl restart linstor-satellite` を実行する必要があります。

note: type: Plain text
en: Be sure to configure your LINSTOR client for use with multiple controllers as described in the section titled, <<s-using_the_linstor_client>> and make sure you also configured your integration plugins (e.g., the Proxmox plugin) to be ready for multiple LINSTOR controllers.
ja: <<s-using_the_linstor_client>> というタイトルのセクションで説明されているように、複数のコントローラーで使用するように LINSTOR クライアントを構成してください。また、統合プラグイン（ Proxmox プラグインなど）も複数の LINSTOR コントローラーに対応できるように構成したことを確認してください。

note: type: Title ===
en: DRBD clients
ja: DRBDクライアント

note: type: Plain text
en: By using the `--drbd-diskless` option instead of `--storage-pool` you can have a permanently diskless DRBD device on a node. This means that the resource will appear as block device and can be mounted to the filesystem without an existing storage-device. The data of the resource is accessed over the network on another nodes with the same resource.
ja: `--storage-pool` の代わりに `--drbd-diskless` オプションを使うことで、ノード上に永続的なディスクレスのDRBDデバイスを持つことができます。これは、リソースがブロックデバイスとして表示され、既存のストレージデバイスなしでファイルシステムとしてマウントできることを意味します。リソースのデータは、同じリソースを持つ別のノード上にネットワークを介してアクセスされます。

note: type: Plain text
en: The option `--diskless` was deprecated. Please use `--drbd-diskless` or `--nvme-initiator` instead.
ja: オプション `--diskless` は廃止されました。代わりに、 `--drbd-diskless` または `--nvme-initiator` を使用してください 。

note: type: Title ===
en: LINSTOR - DRBD consistency group/multiple volumes
ja: LINSTOR - DRBDコンシステンシグループ/マルチボリューム

note: type: Plain text
en: The so called consistency group is a feature from DRBD. It is mentioned in this user-guide, due to the fact that one of LINSTOR's main functions is to manage storage-clusters with DRBD. Multiple volumes in one resource are a consistency group.
ja: コンシステンシグループはDRBDの機能の1つです。LINSTORの主な機能の1つがDRBDを使用してストレージクラスタを管理することです。1つのリソース内の複数のボリュームがコンシステンシグループになります。

note: type: Plain text
en: This means that changes on different volumes from one resource are getting replicated in the same chronological order on the other Satellites.
ja: これは、1つのリソースで異なるボリュームに対する変更が他のサテライトでも同じ順番で複製されることを意味します。

note: type: Plain text
en: Therefore you don't have to worry about the timing if you have interdependent data on different volumes in a resource.
ja: したがって、リソース内の異なるボリュームに相互依存データがある場合は、タイミングを気にする必要はありません。

note: type: Plain text
en: To deploy more than one volume in a LINSTOR-resource you have to create two volume-definitions with the same name.
ja: LINSTORリソースに複数のボリュームを配備するには、同じ名前の volume-definitions を2つ作成する必要があります。

note: type: Title ===
en: Volumes of one resource to different Storage-Pools
ja: 1つのリソースから異なるストレージプールへのボリューム

note: type: Plain text
en: This can be achieved by setting the `StorPoolName` property to the volume definitions before the resource is deployed to the nodes:
ja: リソースをノードに配備する前のボリューム定義で `StorPoolName` プロパティを使うことで、1つのリソースから異なるストレージプールへのボリュームを作成できます。

note: type: Plain text
en: Since the `volume-definition create` command is used without the `--vlmnr` option LINSTOR assigned the volume numbers starting at 0. In the following two lines the 0 and 1 refer to these automatically assigned volume numbers.
ja: `volume-definition create` コマンドが `--vlmnr` なしで使用されたので、LINSTORはボリューム番号を0から割り当てました。続く２行で指定されている、0, 1 の数値はこれら自動的に割り当てられたボリューム番号を示します。

note: type: Plain text
en: Here the 'resource create' commands do not need a `--storage-pool` option.  In this case LINSTOR uses a 'fallback' storage pool. Finding that storage pool, LINSTOR queries the properties of the following objects in the following order:
ja: ここでの 'resource create' は `--storage-pool` オプションを必要としません。この場合LINSTORはストレージプールのフォールバックを使用します。LINSTORは以下のオブジェクトに対してこの順番で問い合わせを行います。

note: type: Plain text
en: Volume definition
ja: ボリューム定義

note: type: Plain text
en: Resource definition
ja: リソース定義

note: type: Plain text
en: If none of those objects contain a `StorPoolName` property, the controller falls back to a hard-coded 'DfltStorPool' string as a storage pool.
ja: どのオブジェクトも `StorPoolName` プロパティを含んでいない場合、コントローラはストレージプールとして 'DfltStorPool' という文字列にフォールバックします。

note: type: Plain text
en: This also means that if you forgot to define a storage pool prior deploying a resource, you will get an error message that LINSTOR could not find the storage pool named 'DfltStorPool'.
ja: これはまた、ストレージプール名を忘れてしまって、LINSTORが 'DfltStorPool' というストレージプールを見つけられなかった場合は、エラーが表示されるということを意味します。

note: type: Title ===
en: LINSTOR without DRBD
ja: DRBDを使わないLINSTOR

note: type: Plain text
en: LINSTOR can be used without DRBD as well. Without DRBD, LINSTOR is able to provision volumes from LVM and ZFS backed storage pools, and create those volumes on individual nodes in your LINSTOR cluster.
ja: LINSTORはDRBDを使わずとも使用できます。 DRBDがなくても、LINSTORはLVMおよびZFS 下位ストレージプールからボリュームをプロビジョニングし、LINSTORクラスタ内の個々のノードにそれらのボリュームを作成できます。

note: type: Plain text
en: Currently LINSTOR supports the creation of LVM and ZFS volumes with the option of layering some combinations of LUKS, DRBD, and/or NVMe-oF/NVMe-TCP on top of those volumes.
ja: 現在LINSTORはLVMとZFSボリュームの作成をサポートしており、LUKS、DRBD、または NVMe-oF/NVMe-TCP の組み合わせをそれらのボリュームの上に重ねることもできます。

note: type: Plain text
en: For example, assume we have a Thin LVM backed storage pool defined in our LINSTOR cluster named, `thin-lvm`:
ja: たとえば、Thin LVM 下位ストレージプールがクラスタ内で `thin-lvm` という名前で定義されているとします。

note: type: Plain text
en: We could use LINSTOR to create a Thin LVM on `linstor-d` that's 100GiB in size using the following commands:
ja: 以下のコマンドで LINSTOR を使用してサイズが100Gバイトの Thin LVM を `linstor-d` 上に作成できます。

note: type: Plain text
en: You should then see you have a new Thin LVM on `linstor-d`. You can extract the device path from LINSTOR by listing your linstor resources with the `--machine-readable` flag set:
ja: 以下で `linstor-d` に新しい Thin LVM ボリュームを確認できます。linstorのリソースを `--machine-reader` フラグを付けてリストすることでLINSTORからデバイスパスを抽出することができます。

note: type: Plain text
en: If you wanted to layer DRBD on top of this volume, which is the default `--layer-list` option in LINSTOR for ZFS or LVM backed volumes, you would use the following resource creation pattern instead:
ja: ZFSまたはLVM下位ボリューム用のデフォルトの `--layer-list` オプションである DRBD をこのボリューム上に階層化したい場合は、代わりに以下のリソース作成パターンを使用します。

note: type: Plain text
en: You would then see that you have a new Thin LVM backing a DRBD volume on `linstor-d`:
ja: `linstor-d` に Thin LVM を下位デバイスとするDRBDボリュームがあることがわかります。

note: type: Plain text
en: The following table shows which layer can be followed by which child-layer:
ja: 次の表は、どのレイヤーの後にどの子レイヤーが続くかを示しています。

note: type: Plain text
en: One layer can only occur once in the layer-list
ja: 1つのレイヤーは、layer-list で1回しか使用できません。

note: type: Plain text
en: For information about the prerequisites for the `LUKS` layer, refer to the Encrypted Volumes section of this User's Guide.
ja: `luks` レイヤの必要条件についての情報はこのユーザガイドの暗号化ボリュームの節を参照ください。

note: type: Title ====
en: NVMe-oF/NVMe-TCP LINSTOR Layer
ja: NVMe-oF/NVMe-TCP LINSTOR レイヤ

note: type: Plain text
en: NVMe-oF/NVMe-TCP allows LINSTOR to connect diskless resources to a node with the same resource where the data is stored over NVMe fabrics. This leads to the advantage that resources can be mounted without using local storage by accessing the data over the network.  LINSTOR is not using DRBD in this case, and therefore NVMe resources provisioned by LINSTOR are not replicated, the data is stored on one node.
ja: NVMe-oF/NVMe-TCP により、LINSTOR はデータが NVMe ファブリックを介して格納されているリソースを持つノードにディスクレスリソースとして接続することができます。これにより、ネットワークを介してデータにアクセスすることで、ローカルストレージを使用せずにリソースをマウントできるという利点が得られます。この場合、LINSTORはDRBDを使用していないため、LINSTORによってプロビジョニングされたNVMeリソースは複製されず、データは1つのノードに格納されます。

note: type: Plain text
en: NVMe-oF only works on RDMA-capable networks and NVMe-TCP on every network that can carry IP traffic. If you want to know more about NVMe-oF/NVMe-TCP visit https://www.linbit.com/en/nvme-linstor-swordfish/ for more information.
ja: NVMe-oF はRDMA対応ネットワークでのみ動作し、NVMe-TCP はIPトラフィックを伝送できるすべてのネットワークで動作します。 NVMe-oF/NVMe-TCP の詳細については、https://www.linbit.com/en/nvme-linstor-swordfish/ を参照ください。

note: type: Plain text
en: To use NVMe-oF/NVMe-TCP with LINSTOR the package `nvme-cli` needs to be installed on every Node which acts as a Satellite and will use NVMe-oF/NVMe-TCP for a resource:
ja: LINSTORで NVMe-oF/NVMe-TCP を使用するには、サテライトとして機能し、リソースとして NVMe-oF/NVMe-TCP を使用するすべてのノードで `nvme-cli` パッケージをインストールする必要があります。

note: type: Plain text
en: If you are not using Ubuntu use the suitable command for installing packages on your OS - SLES: zypper - CentOS: yum
ja: Ubuntu を使用していない場合は、OS にパッケージをインストールするための適切なコマンドを使用してください -  SLES：zypper - CentOS：yum

note: type: Plain text
en: To make a resource which uses NVMe-oF/NVMe-TCP an additional parameter has to be given as you create the resource-definition:
ja: NVMe-oF/NVMe-TCP を使用するリソースを作成するには、resource-definition を作成するときに追加のパラメータを指定する必要があります。

note: type: Plain text
en: As default the -l (layer-stack) parameter is set to `drbd, storage` when DRBD is used. If you want to create LINSTOR resources with neither NVMe nor DRBD you have to set the `-l` parameter to only `storage`.
ja: DRBDが使用されている場合、デフォルトでは -l(layer-stack) パラメータは `drbd,storage` に設定されています。 NVMeもDRBDも使用せずにLINSTORリソースを作成したい場合は、 `-l` パラメータを `storage` だけに設定する必要があります。

note: type: Plain text
en: In order to use NVMe-TCP instead of the default NVMe-oF the following property needs to be set:
ja: デフォルトの NVMe-oF の代わりに NVMe-TCP を使用するには、次のプロパティを設定する必要があります。

note: type: Plain text
en: The property `NVMe/TRType` can alternatively be set on resource-group or controller level.
ja: プロパティ `NVMe/TRType` は、リソースグループまたはコントローラーレベルで設定することもできます。

note: type: Plain text
en: Next, create the volume-definition for our resource:
ja: 次に、リソース用の volume-definition を作成します。

note: type: Plain text
en: Before you create the resource on your nodes you have to know where the data will be stored locally and which node accesses it over the network.
ja: ノード上にリソースを作成する前に、データがローカルに格納される場所と、どのノードがネットワーク経由でそれにアクセスするかを確認します。

note: type: Plain text
en: First we create the resource on the node where our data will be stored:
ja: まず、データを保存するノードにリソースを作成します。

note: type: Plain text
en: On the nodes where the resource-data will be accessed over the network, the resource has to be defined as diskless:
ja: ネットワーク上でリソースデータにアクセスするノードでは、リソースをディスクレスとして定義する必要があります。

note: type: Plain text
en: Now you can mount the resource `nvmedata` on one of your nodes.
ja: これでリソース `nvmedata` をノードの1つにマウントできます。

note: type: Plain text
en: If your nodes have more than one NIC you should force the route between them for NVMe-of/NVME-TCP, otherwise multiple NICs could cause troubles.
ja: ノードに複数のNICがある場合は、NVMe-of/NVME-TCP に対してそれらの間の経路を強制する必要があります。そうしないと、複数のNICで問題が発生する可能性があります。

note: type: Plain text
en: Since version 1.5.0 the additional Layer `openflex` can be used in LINSTOR.  From LINSTOR's perspective, the https://www.westerndigital.com/products/storage-platforms/openflex-composable-infrastructure[OpenFlex Composable Infrastructure] takes the role of a combined layer acting as a storage layer (like LVM) and also providing the allocated space as an NVMe target.  OpenFlex has a REST API which is also used by LINSTOR to operate with.
ja: バージョン1.5.0 以降、LINSTOR で追加のレイヤー `openflex` を使用できます。LINSTOR の観点から見ると、 https://www.westerndigital.com/products/storage-platforms/openflex-composable-infrastructure[OpenFlex Composable Infrastructure] は、LVM のようなストレージレイヤーとして機能する結合レイヤーの役割を果たします。また、割り当てられたスペースを NVMe ターゲットとして提供します。OpenFlex には REST API があり、LINSTOR で操作できます。

note: type: Plain text
en: As OpenFlex combines concepts of LINSTOR's storage as well as NVMe-layer, LINSTOR was added both, a new storage driver for the storage pools as well as a dedicated `openflex` layer which uses the mentioned REST API.
ja: OpenFlex は LINSTOR ストレージと NVMeレイヤー の概念を組み合わせているため、LINSTOR は、ストレージプール用の新しいストレージドライバーと、前述の REST API を使用する専用の `openflex` レイヤーの両方に追加されました。

note: type: Plain text
en: In order for LINSTOR to communicate with the OpenFlex-API, LINSTOR needs some additional properties, which can be set once on `controller` level to take LINSTOR-cluster wide effect:
ja: LINSTOR が OpenFlex-API と通信するためには、LINSTOR はいくつかの追加のプロパティを必要とします。これらのプロパティを `controller` レベルで一度設定することで、LINSTOR クラスター全体に反映できます。

note: type: Plain text
en: `StorDriver/Openflex/ApiHost` specifies the host or IP of the API entry-point
ja: `StorDriver/Openflex/ApiHost` : API エントリポイントのホストまたは IP を指定する

note: type: Plain text
en: `StorDriver/Openflex/ApiPort` this property is glued with a colon to the previous to form the basic `http://ip:port` part used by the REST calls
ja: `StorDriver/Openflex/ApiPort` : REST 呼び出しで使用される基本的な `http://ip:port` の port の部分を指定する

note: type: Plain text
en: `StorDriver/Openflex/UserName` the REST username
ja: `StorDriver/Openflex/UserName` : REST ユーザ名を指定する

note: type: Plain text
en: `StorDriver/Openflex/UserPassword` the password for the REST user
ja: `StorDriver/Openflex/UserPassword` : REST ユーザのパスワードを指定する

note: type: Plain text
en: Once that is configured, we can now create LINSTOR objects to represent the OpenFlex architecture.  The theoretical mapping of LINSTOR objects to OpenFlex objects are as follows: Obviously an OpenFlex storage pool is represented by a LINSTOR storage pool. As the next thing above a LINSTOR storage pool is already the node, a LINSTOR node represents an OpenFlex storage device.  The OpenFlex objects above storage device are not mapped by LINSTOR.
ja: これらが設定されたら、OpenFlex アーキテクチャの LINSTOR オブジェクトを作成できます。LINSTOR オブジェクトの OpenFlex オブジェクトへの理論的なマッピングは次のとおりです。OpenFlex ストレージプールは LINSTOR ストレージプールで表されます。LINSTOR ストレージプールの上の次のものはすでにノードであるため、LINSTOR ノードは OpenFlex ストレージデバイスを表します。ストレージデバイスの上の OpenFlex オブジェクトは LINSTOR によってマップされません。

note: type: Plain text
en: When using NVMe, LINSTOR was designed to run on both sides, the NVMe target as well as on the NVMe initiator side. In the case of OpenFlex, LINSTOR cannot (or even should not) run on the NVMe target side as that is completely managed by OpenFlex. As LINSTOR still needs nodes and storage pools to represent the OpenFlex counterparts, the LINSTOR client was extended with special node create commands since 1.0.14. These commands not only accept additionally needed configuration data, but also starts a "special satellite" besides the already running controller instance. This special satellites are completely LINSTOR managed, they will shutdown when the controller shuts down and will be started again when the controller starts.  The new client command for creating a "special satellite" representing an OpenFlex storage device is:
ja: NVMe を使用する場合、LINSTOR は NVMe ターゲットと NVMe イニシエーター側の両方で実行するように設計されています。 OpenFlex の場合、LINSTOR は OpenFlex によって完全に管理されるため、NVMeターゲット側で実行しません（実行する必要はありません）。LINSTOR は OpenFlex 対応物を表すためのノードとストレージプールを必要とするため、1.0.14 以降、特別なノードを作成するコマンドが LINSTOR クライアントに拡張されました。このコマンドは、追加で必要な構成データを受け入れるだけでなく、すでに実行中のコントローラインスタンスの他に "特別なサテライト" も起動します。この特別なサテライトは完全に LINSTOR で管理され、コントローラがシャットダウンするとシャットダウンされ、コントローラが起動すると再び起動されます。 OpenFlexストレージデバイスを表す "特別なサテライト" を作成するための新しいクライアントコマンドは次のとおりです。

note: type: Plain text
en: The arguments are as follows:
ja: 引数は次のとおりです。

note: type: Plain text
en: `ofNode1` is the node name which is also used by the standard `linstor node create` command
ja: `ofNode1` は標準の `linstor node create` コマンドでも使用されるノード名です。

note: type: Plain text
en: `192.168.166.7` is the address on which the provided NVMe devices can be accessed.  As the NVMe devices are accessed by a dedicated network interface, this address differs from the address specified with the property `StorDriver/Openflex/ApiHost`. The latter is used for the management / REST API.
ja: `192.168.166.7` は提供された NVMe デバイスにアクセスされるアドレスです。NVMe デバイスは専用のネットワークインターフェースによってアクセスされるため、このアドレスは、 `StorDriver/Openflex/ApiHost` プロパティで指定されたアドレスとは異なります。後者は管理 / REST API に使用されます。

note: type: Plain text
en: `000af795789d` is the identifier for the OpenFlex storage device.
ja: `000af795789d` はOpenFlexストレージデバイスの識別子です。

note: type: Plain text
en: The last step of the configuration is the creation of LINSTOR storage pools:
ja: 構成の最後のステップは、LINSTOR ストレージプールの作成です。

note: type: Plain text
en: `ofNode1` and `sp0` are the node name and storage pool name, respectively, just as usual for the LINSTOR's create storage pool command
ja: `ofNode1` と `sp0` は、LINSTORs create storage pool コマンドの場合と同様に、それぞれノード名とストレージプール名です。

note: type: Plain text
en: The last `0` is the identifier of the OpenFlex storage pool within the previously defined storage device
ja: 最後の `0` は以前に定義されたストレージデバイス内の OpenFlex ストレージプールの識別子です。

note: type: Plain text
en: Once all necessary storage pools are created in LINSTOR, the next steps are similar to the usage of using an NVMe resource with LINSTOR. Here is a complete example:
ja: LINSTOR で必要なストレージプールをすべて作成したら、次の手順は、LINSTOR で NVMe リソースを使用する場合と同様です。以下は完全な例です。

note: type: Plain text
en: In case a node should access the OpenFlex REST API through a different host than specified with + `linstor controller set-property StorDriver/Openflex/ApiHost 10.43.7.185` you can always use LINSTOR's inheritance mechanism for properties. That means simply define the same property on the node-level you need it, i.e. + `linstor node set-property ofNode1 StorDriver/Openflex/ApiHost 10.43.8.185`
ja: ノードが `linstor controller set-property StorDriver/Openflex/ApiHost 10.43.7.185` で指定されたものとは異なるホストの OpenFlex REST API にアクセスする場合、プロパティに対して常に LINSTOR の継承メカニズムを使用できます。つまり、必要なノードレベルで同じプロパティ `linstor node set-property ofNode1 StorDriver/Openflex/ApiHost 10.43.8.185` を定義するだけです。

note: type: Title ====
en: Writecache Layer
ja: 書き込みキャッシュレイヤー

note: type: Plain text
en: A https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/writecache.html[DM-Writecache] device is composed by two devices, one storage device and one cache device.  LINSTOR can setup such a writecache device, but needs some additional information, like the storage pool and the size of the cache device.
ja: https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/writecache.html[DM-Writecache] デバイスは、ストレージデバイスとキャッシュデバイスの2つのデバイスで構成されます。 LINSTORはそのような書き込みキャッシュデバイスをセットアップできますが、ストレージプールやキャッシュデバイスのサイズなどの追加情報が必要です。

note: type: Plain text
en: The two properties set in the examples are mandatory, but can also be set on controller level which would act as a default for all resources with `WRITECACHE` in their `--layer-list`. However, please note that the `Writecache/PoolName` refers to the corresponding node. If the node does not have a storage-pool named `pmempool` you will get an error message.
ja: 例で設定されている2つのプロパティは必須ですが、コントローラレベルで設定することもできます。これは、 `--layer-list` に `WRITECACHE` が含まれるすべてのリソースのデフォルトとして機能します。ただし、 `Writecache/PoolName` は対応するノードに依存することに注意してください。ノードに `pmempool` という名前のストレージプールがない場合は、エラーメッセージが表示されます。

note: type: Plain text
en: The 4 mandatory parameters required by https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/writecache.html[DM-Writecache] are either configured via property or figured out by LINSTOR.  The optional properties listed in the mentioned link can also be set via property.  Please see `linstor controller set-property --help` for a list of `Writecache/*` property-keys.
ja: https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/writecache.html[DM-Writecache] に必要な4つの必須 パラメーターは、プロパティを介して設定されるか、LINSTORによって計算されます。上記のリンクにリストされているオプションのプロパティは、プロパティを介して設定することもできます。 `Writecache/*` プロパティキーのリストについては、 `linstor controller set-property --help` を参照ください。

note: type: Plain text
en: Using `--layer-list DRBD,WRITECACHE,STORAGE` while having DRBD configured to use external metadata, only the backing device will use a writecache, not the device holding the external metadata.
ja: 外部メタデータを使用するようにDRBDを設定しているときに `--layer-list DRBD、WRITECACHE、STORAGE` を使用すると、外部メタデータを保持するデバイスではなく、下位デバイスのみが書き込みキャッシュを使用します。

note: type: Title ====
en: Cache Layer
ja: キャッシュレイヤー

note: type: Plain text
en: LINSTOR can also setup a https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/cache.html[DM-Cache] device, which is very similar to the DM-Writecache from the previous section. The major difference is that a cache device is composed by three devices: one storage device, one cache device and one meta device. The LINSTOR properties are quite similar to those of the writecache but are located in the `Cache` namespace:
ja: LINSTOR は https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/cache.html[DM-Cache] デバイスをセットアップすることもできます。これは前のセクションの DM-Writecache によく似ています。主な違いは、キャッシュデバイスが 3 つのデバイスで構成されていることです。1 つのストレージデバイス、1 つのキャッシュデバイス、1 つのメタデバイスです。LINSTOR プロパティは書き込みキャッシュのプロパティと非常に似ていますが、`Cache` 名前空間にあります。

note: type: Plain text
en: Instead of `Writecache/PoolName` (as when configuring the Writecache layer) the Cache layer's only required property is called `Cache/CachePool`. The reason for this is that the Cache layer also has a `Cache/MetaPool` which can be configured separately or it defaults to the value of `Cache/CachePool`.
ja: Writecache レイヤーを構成する `Writecache/PoolName` と異なり、Cache レイヤーの唯一の必須プロパティは `Cache/CachePool` です。これは、Cache レイヤーの `Cache/MetaPool` は個別に設定するか、またはデフォルトで `Cache/CachePool` の値を設定するからです。

note: type: Plain text
en: Please see `linstor controller set-property --help` for a list of `Cache/*` property-keys and default values for omitted properties.
ja: `Cache/*` プロパティと省略されたプロパティのデフォルト値のリストについては `linstor controller set-property --help` を参照ください。

note: type: Plain text
en: Using `--layer-list DRBD,CACHE,STORAGE` while having DRBD configured to use external metadata, only the backing device will use a cache, not the device holding the external metadata.
ja: 外部メタデータを使用するようにDRBDを設定しているときに `--layer-list DRBD,CACHE,STORAGE` を使用すると、外部メタデータを保持するデバイスではなく、下位デバイスのみがキャッシュを使用します。

note: type: Title ====
en: Storage Layer
ja: ストレージレイヤー

note: type: Plain text
en: The storage layer will provide new devices from well known volume managers like LVM, ZFS or others. Every layer combination needs to be based on a storage layer, even if the resource should be diskless - for that type there is a dedicated `diskless` provider type.
ja: ストレージレイヤーは、LVM、ZFS などのよく知られたボリュームマネージャーからの新しいデバイスを提供します。リソースがディスクレスである必要がある場合（そのタイプは専用の「ディスクレス」プロバイダータイプ）でも、すべてのレイヤーの組み合わせはストレージレイヤーに基づく必要があります。

note: type: Plain text
en: For a list of providers with their properties please see <<s-storage-proviers, Storage Providers>>.
ja: プロバイダーのプロパティについては <<s-storage-proviers, Storage Providers>> を参照ください。

note: type: Plain text
en: For some storage providers LINSTOR has special properties:
ja: 一部のストレージプロバイダー用に、LINSTOR には特別なプロパティがあります。

note: type: Plain text
en: `StorDriver/WaitTimeoutAfterCreate`: If LINSTOR expects a device to appear after creation (for example after calls of `lvcreate`, `zfs create`,...), LINSTOR waits per default 500ms for the device to appear. These 500ms can be overridden by this property.
ja: `StorDriver/WaitTimeoutAfterCreate`: LINSTOR が作成後にデバイスが表示されることを期待している場合（たとえば `lvcreate`, `zfs create`,... の呼び出し後）、LINSTOR はデフォルトで 500ms ごとにデバイスが表示されるのを待ちます。これらの 500ms は、このプロパティによってオーバーライドできます。

note: type: Plain text
en: `StorDriver/dm_stats`: If set to `true` LINSTOR calls `dmstats create $device` after creation and `dmstats delete $device --allregions` after deletion of a volume.  Currently only enabled for LVM and LVM_THIN storage providers.
ja: `StorDriver/dm_stats`: `true` に設定すると、LINSTOR は作成後に `dmstats create $device` を呼び出し、ボリュームの削除後に `dmstats delete $device --allregions` を呼び出します。現在、LVM および LVM_THIN ストレージプロバイダーに対してのみ有効になっています。

note: type: Title ===
en: Storage Providers
ja: ストレージプロバイダー

note: type: Plain text
en: LINSTOR has a few storage providers. The most used ones are LVM and ZFS. But also for those two providers there are already sub-types for their thinly provisioned variants.
ja: LINSTOR にはいくつかのストレージプロバイダーがあります。最も使用されているのは LVM と ZFS です。しかし、これら 2 つのプロバイダーについても、シンプロビジョニングされた異なるサブタイプがすでに存在します。

note: type: Plain text
en: Diskless: This provider type is mostly required to have a storage pool that can be configured with LINSTOR properties like `PrefNic` as described in <<s-managing_network_interface_cards, Managing Network Interface Cards>>.
ja: Diskless: このプロバイダータイプには、<<s-managing_network_interface_cards, Managing Network Interface Cards>> で説明されているように `PrefNic` などの LINSTOR プロパティで構成できるストレージプールがほとんどの場合必要です。

note: type: Plain text
en: LVM / LVM-Thin: The adminstrator is expected to specify the LVM volume group or the thin-pool (in form of "LV/thinpool") in order to use the corresponding storage type. These drivers support following properties for fine-tuning:
ja: LVM / LVM-Thin: 管理者は、対応するストレージタイプを使用するために、LVM ボリュームグループまたはシンプール（"LV/thinpool" の形式）を指定する必要があります。これらのドライバーは、チューニング用に次のプロパティをサポートします。

note: type: Plain text
en: `StorDriver/LvcreateOptions`: The value of this property is appended to every
ja: `StorDriver/LvcreateOptions`: このプロパティの値は、LINSTOR が実行するすべての

note: type: Plain text
en: `lvcreate ...` call LINSTOR executes.
ja: `lvcreate ...` 呼び出しの LINSTOR 実行に追加されます。

note: type: Plain text
en: ZFS / ZFS-Thin: The administrator is expected to specify the ZPool that LINSTOR should use.  These drivers support following properties for fine-tuning:
ja: ZFS / ZFS-Thin: 管理者は、LINSTOR が使用する ZPool を指定する必要があります。これらのドライバーは、チューニング用に次のプロパティをサポートします。

note: type: Plain text
en: `StorDriver/ZfscreateOptions`: The value of this property is appended to every
ja: `StorDriver/ZfscreateOptions`: このプロパティの値は、LINSTOR が実行するすべての

note: type: Plain text
en: `zfs create ...` call LINSTOR executes.
ja: `zfs create ...` 呼び出しの LINSTOR 実行に追加されます。

note: type: Plain text
en: File / FileThin: Mostly used for demonstration / experiments. LINSTOR will basically reserve a file in a given directory and will configure a https://man7.org/linux/man-pages/man4/loop.4.html[loop device] on top of that file.
ja: File / FileThin: 主にデモンストレーション/実験に使用されます。LINSTOR は基本的に、指定されたディレクトリにファイルをリザーブし、そのファイルの上に https://man7.org/linux/man-pages/man4/loop.4.html[ループデバイス] を構成します。

note: type: Plain text
en: OpenFlex: This special storage provider currently requires to be run on a "special satellite".  Please see <<s-openflex, OpenFlex(TM) Layer>> for more details.
ja: OpenFlex: この特別なストレージプロバイダーは現在、特別なサテライトで実行する必要があります。詳細は <<s-openflex, OpenFlex(TM) Layer>> を参照ください。

note: type: Plain text
en: EXOS: This special storage provider currently requires to be run on a "special satellite".  Please see the <<ch-exos, EXOS Integration>> chapter
ja: EXOS: この特別なストレージプロバイダーは現在、特別なサテライトで実行する必要があります。詳細は <<ch-exos, EXOS Integration>> を参照ください。

note: type: Plain text
en: SPDK: The administrator is expected to speicify the logical volume store which LINSTOR should use.  The usage of this storage provider implies the usage of the <<s-nvme-layer,NVME Layer>>.
ja: SPDK: 管理者は、LINSTOR が使用する論理ボリュームストアを指定する必要があります。このストレージプロバイダーの使用法は <<s-nvme-layer,NVME Layer>> 使用を意味します。

note: type: Plain text
en: Remote-SPDK: This special storage provider currently requires to be run on a "special satellite".  Please see <<s-remote-spdk, Remote SPDK Provider>> for more details.
ja: Remote-SPDK: この特別なストレージプロバイダーは現在、特別なサテライトで実行する必要があります。詳細は <<s-remote-spdk, Remote SPDK Provider>> を参照ください。

note: type: Title ====
en: Remote SPDK Provider
ja: リモート SPDK プロバイダー

note: type: Plain text
en: A storage pool with the type remote SPDK can only be created on a "special satellite". For this you first need to start a new satellite using the command:
ja: リモート SPDK のストレージプールは、特別なサテライトでのみ作成できます。最初に次のコマンドを使用して新しいサテライトを開始する必要があります。

note: type: Plain text
en: This will start a new satellite instance running on the same machine as the controller. This special satellite will do all the REST based RPC communication towards the remote SPDK proxy. As the help message of the LINSTOR command shows, the administrator might want to use additional settings when creating this special satellite:
ja: これにより、コントローラーと同じマシンで実行されている新しいサテライトインスタンスが開始されます。この特別なサテライトは、リモート SPDK プロキシに対してすべての REST ベースの RPC 通信を実行します。LINSTOR コマンドのヘルプメッセージが示すように、管理者はこの特別なサテライトを作成するときに設定を追加したい場合があります。

note: type: Plain text
en: The difference between the `--api-\*` and their corresponding `--api-\*-env` versions is that the version with the `-env` ending will look for an environment variable containing the actual value to use whereas the `--api-\*` version directly take the value which is stored in the LINSTOR property.  Administrators might not want to save the `--api-pw` in plaintext, which would be clearly visible using commands like `linstor node list-property <nodeName>`.
ja: `--api-\*` とそれに対応する `--api-\*-env` バージョンの違いは、 `-env` で終わるバージョンは、値を含む環境変数を検索することです。一方、 `--api-\*` バージョンは、LINSTOR プロパティに格納されている値を直接取得します。管理者は `--api-pw` をプレーンテキストで保存したくない場合があります。これは `linstor node list-property <nodeName>` などのコマンドで表示されてしまいます。

note: type: Plain text
en: Once that special satellite is up and running the actual storage pool can be created:
ja: 特別なサテライトが稼働し始めたら、実際のストレージプールを作成できます。

note: type: Plain text
en: Whereas `node_name` is self-explanatory, `name` is the name of the LINSTOR storage pool and `driver_pool_name` refers to the SPDK logical volume store.
ja: `node_name` は自明ですが、`name` は LINSTOR ストレージプールの名前であり、 `driver_pool_name` は SPDK 論理ボリュームストアを指定します。

note: type: Plain text
en: Once this _remotespdk_ storage pool is created the remaining procedure is quite similar as using NVMe: First the target has to be created by creating a simple "diskful" resource followed by a second resource having the `--nvme-initiator` option enabled.
ja: この _remotespdk_ ストレージプールが作成されると、残りの手順は NVMe を使用する場合と非常に似ています。最初に、単に "diskful" リソースでターゲットを作成し、2 番目のリソースは `-nvme-initiator` オプションを有効にして作成します。

note: type: Title ===
en: Managing Network Interface Cards
ja: ネットワークインターフェイスカードの管理

note: type: Plain text
en: LINSTOR can deal with multiple network interface cards (NICs) in a machine, they are called `netif` in LINSTOR speak.
ja: LINSTORはマシンの複数のネットワークインターフェイスカード(NIC)を扱えます。LINSTORでこれらは `netif` と呼びます。

note: type: Plain text
en: When a satellite node is created a first `netif` gets created implicitly with the name `default`. Using the `--interface-name` option of the `node create` command you can give it a different name.
ja: サテライトノードが作成されると最初の `netif` が `default` という名前で暗黙に作られます。`node create` コマンドで `--interface-name` オプションを指定することにより、別の名前を与えることができます。

note: type: Plain text
en: Additional NICs are created like this:
ja: 追加のNICは以下のようにして作られます。

note: type: Plain text
en: NICs are identified by the IP address only, the name is arbitrary and is *not* related to the interface name used by Linux. The NICs can be assigned to storage pools so that whenever a resource is created in such a storage pool, the DRBD traffic will be routed through the specified NIC.
ja: NICはIPアドレスのみのよって識別され、名前は任意でありLinuxによって使用されるインターフェイス名には関連しません。NICはストレージプールに割り当てられますので、リソースがそのストレージプールに作成されるときは常にDRBDトラフィックはそのNICを介して行われます。

note: type: Title ===
en: Encrypted volumes
ja: 暗号化ボリューム

note: type: Plain text
en: LINSTOR can handle transparent encryption of drbd volumes. dm-crypt is used to encrypt the provided storage from the storage device.
ja: LINSTORはDRBDボリュームの暗号化を透過的に扱うことができます。dm-cryptがストレージデバイスから提供されるストレージを暗号化するのに使われます。

note: type: Plain text
en: In order to use dm-crypt please make sure to have `cryptsetup` installed before you start the satellite
ja: dm-crypt を使用するには、サテライトを開始する前に `cryptsetup` がインストールされていることを確認してください。

note: type: Plain text
en: Basic steps to use encryption:
ja: 暗号化の基本的な手順は以下になります。

note: type: Plain text
en: Disable user security on the controller (this will be obsolete once authentication works)
ja: コントローラでユーザセキュリティを無効にする（これは認証が実装されたあとに廃止になる予定です）

note: type: Plain text
en: Create a master passphrase
ja: マスターパスフレーズを作成する

note: type: Plain text
en: Add `luks` to the layer-list. Note that all plugins (e.g., Proxmox) require a DRBD layer as the top most layer if they do not explicitly state otherwise.
ja: layer-list に `luks` を追加します。すべてのプラグイン（Proxmoxなど）は、特に明記しない限り、最上位のレイヤーとして DRBD レイヤーを必要とすることに注意してください。

note: type: Plain text
en: Don't forget to re-enter the master passphrase after a controller restart.
ja: コントローラが再起動した後はマスターパスフレーズを再入力する

note: type: Title ====
en: Disable user security
ja: ユーザセキュリティを無効にする

note: type: Plain text
en: Disabling the user security on the `Linstor` controller is a one time operation and is afterwards persisted.
ja: Linstorコントローラのユーザセキュリティを無効にする操作は、一度行えばその後はこれが継続します。手順は以下のとおりです。

note: type: Plain text
en: Stop the running linstor-controller via systemd: `systemctl stop linstor-controller`
ja: `systemctl stop linstor-controller` でLinstorコントローラを止める

note: type: Plain text
en: Start a linstor-controller in debug mode: `/usr/share/linstor-server/bin/Controller -c /etc/linstor -d`
ja: `/usr/share/linstor-server/bin/Controller -c /etc/linstor -d` でLinstorコントローラをデバッグモードで立ち上げる

note: type: Plain text
en: In the debug console enter: `setSecLvl secLvl(NO_SECURITY)`
ja: デバックコンソールで `setSecLvl secLvl(NO_SECURITY)` を入力する

note: type: Plain text
en: Stop linstor-controller with the debug shutdown command: `shutdown`
ja: デバックシャットダウンコマンドの `shutdown` でlinstor-controllerを止める

note: type: Plain text
en: Start the controller again with systemd: `systemctl start linstor-controller`
ja: `systemctl start linstor-controller` でコントローラを再び起動する

note: type: Title ====
en: Encrypt commands
ja: 暗号化のコマンド

note: type: Plain text
en: Below are details about the commands.
ja: 以下にコマンドの詳細を示します。

note: type: Plain text
en: Before LINSTOR can encrypt any volume a master passphrase needs to be created.  This can be done with the linstor-client.
ja: LINSTORがボリュームを暗号化する前に、マスターパスフレーズを作ることが必要です。これには以下のlinstorコマンドを使用します。

note: type: Plain text
en: `crypt-create-passphrase` will wait for the user to input the initial master passphrase (as all other crypt commands will with no arguments).
ja: `crypt-create-passphrase` はマスターパスフレーズを初期化するためにユーザの入力を待ちます。

note: type: Plain text
en: If you ever want to change the master passphrase this can be done with:
ja: マスターパスフレーズを変更したい場合は以下のコマンドで行います。

note: type: Plain text
en: The `luks` layer can be added when creating the resource-definition or the resource itself, whereas the former method is recommended since it will be automatically applied to all resource created from that resource-definition.
ja: resource-definition またはリソース自体を作成するときに `luks` レイヤーを追加できますが、前者の方法は、resource-definition から作成されたすべてのリソースに自動的に適用されるため、推奨されます。

note: type: Plain text
en: To enter the master passphrase (after controller restart) use the following command:
ja: マスターパスフェーズを入力する（コントローラを再起動した後）には以下を使用します。

note: type: Plain text
en: Whenever the linstor-controller is restarted, the user has to send the master passphrase to the controller, otherwise LINSTOR is unable to reopen or create encrypted volumes.
ja: linstor-controllerが再起動したときは、コントローラにマスターパスフェーズを常に入力する必要があります。そうしないとLINSTORは暗号化されたボリュームをオープンしたり作成したりできません。

note: type: Title ====
en: Automatic Passphrase
ja: 自動パスフレーズ

note: type: Plain text
en: It is possible to automate the process of creating and re-entering the master passphrase.
ja: マスターパスフレーズの作成と再入力のプロセスを自動化することは可能です。

note: type: Plain text
en: To use this, either an environment variable called `MASTER_PASSPHRASE` or an entry in `/etc/linstor/linstor.toml` containing the master passphrase has to be created.
ja: これを使用するには、 `MASTER_PASSPHRASE` という名前の環境変数、またはマスターパスフレーズを含む `/etc/linstor/linstor.toml` のエントリを作成する必要があります。

note: type: Plain text
en: The required `linstor.toml` looks like this:
ja: `linstor.toml` は以下のようになります。

note: type: Plain text
en: If either one of these is set, then every time the controller starts it will check whether a master passphrase already exists. If there is none, it will create a new master passphrase as specified.  Otherwise, the controller enters the passphrase.
ja: これらのいずれかが設定されている場合、コントローラが起動されるたびに、マスターパスフレーズがすでに存在するかどうかがチェックされます。ない場合は、指定されたとおりに新しいマスターパスフレーズが作成されます。ある場合、コントローラはパスフレーズを入力します。

note: type: Plain text
en: If a master passphrase is already configured, and it is not the same one as specified in the environment variable or `linstor.toml`, the controller will be unable to re-enter the master passphrase and react as if the user had entered a wrong passphrase.  This can only be resolved through manual input from the user, using the same commands as if the controller was started without the automatic passphrase.
ja: マスターパスフレーズがすでに設定されていて、環境変数または `linstor.toml` で指定されたものと同じでない場合、コントローラはマスターパスフレーズを再入力できず、ユーザーがパスフレーズ間違って入力したかのように動作します。これは、自動パスフレーズなしでコントローラを起動した場合と同じで、コマンドを使用して、ユーザーからの手動入力によってのみ解決できます。

note: type: Plain text
en: In case the master passphrase is set in both an environment variable and the `linstor.toml`, only the master passphrase from the `linstor.toml` will be used.
ja: マスターパスフレーズが環境変数と `linstor.toml` の両方に設定されている場合、`linstor.toml` からのマスターパスフレーズのみが使用されます。

note: type: Title ===
en: Checking the state of your cluster
ja: クラスタの状態をチェック

note: type: Plain text
en: LINSTOR provides various commands to check the state of your cluster.  These commands start with a 'list-' prefix and provide various filtering and sorting options. The '--groupby' option can be used to group and sort the output in multiple dimensions.
ja: LINSTORにはクラスタの状態をチェックするいろいろなコマンドがあります。これらには 'list' サブコマンドを使用し、フィルターしたりソートしたりするいろいろなオプションを提供します。'--groupby' オプションは出力のグルーピングとソートに使います。

note: type: Title ===
en: Managing snapshots
ja: スナップショットの管理

note: type: Plain text
en: Snapshots are supported with thin LVM and ZFS storage pools.
ja: スナップショットはthin LVMとZFSストレージプールでサポートされています。

note: type: Title ====
en: Creating a snapshot
ja: スナップショットの作成

note: type: Plain text
en: Assuming a resource definition named 'resource1' which has been placed on some nodes, a snapshot can be created as follows:
ja: リソース定義 'resource1' がすでにどこかのノードにあると仮定すると、スナップショットは以下のコマンドで作成できます。

note: type: Plain text
en: This will create snapshots on all nodes where the resource is present.  LINSTOR will ensure that consistent snapshots are taken even when the resource is in active use.
ja: これはリソースが存在するすべてのノードでスナップショットを作成します。LINSTORはリソースが使用中でも一貫性のあるスナップショットが取れることを保証します。

note: type: Plain text
en: Setting the resource-definition property `AutoSnapshot/RunEvery` LINSTOR will automatically create snapshots every X minute.  The optional property `AutoSnapshot/Keep` can be used to clean-up old snapshots which were created automatically. No manually created snapshot will be cleaned-up / deleted.  If `AutoSnapshot/Keep` is omitted (or <= 0), LINSTOR will keep the last 10 snapshots by default.
ja: resource-definition プロパティ `AutoSnapshot/RunEvery` を設定すると LINSTOR は X 分ごとに自動的にスナップショットを作成します。オプションのプロパティ `AutoSnapshot/Keep` を使用して、自動的に作成された古いスナップショットをクリーンアップできます。手動で作成されたスナップショットはクリーンアップ/削除されません。 `AutoSnapshot/Keep` が省略されている（または 0 以下）の場合、LINSTOR はデフォルトで最新の10個のスナップショットを保持します。

note: type: Title ====
en: Restoring a snapshot
ja: スナップショットの復元

note: type: Plain text
en: The following steps restore a snapshot to a new resource.  This is possible even when the original resource has been removed from the nodes where the snapshots were taken.
ja: 以下の手順では新しいリソースにスナップショットを復元します。オリジナルのリソースがそれが取られたノードからすでに削除されていても復元可能です。

note: type: Plain text
en: First define the new resource with volumes matching those from the snapshot:
ja: 最初にスナップショットに一致するボリュームをもつリソースを定義します。

note: type: Plain text
en: At this point, additional configuration can be applied if necessary.  Then, when ready, create resources based on the snapshots:
ja: この時点で必要に応じて追加の設定を適用します。それで準備ができたら、スナップショットを使ってリソースを作成します。

note: type: Plain text
en: This will place the new resource on all nodes where the snapshot is present.  The nodes on which to place the resource can also be selected explicitly; see the help (`linstor snapshot resource restore -h`).
ja: これにより、スナップショットが存在するすべてのノードに新しいリソースが作られます。リソースを作るノードも明示的に指定できます。詳細はヘルプ (`linstor snapshot resource restore -h`) を参照ください。

note: type: Title ====
en: Rolling back to a snapshot
ja: スナップショットへのロールバック

note: type: Plain text
en: LINSTOR can roll a resource back to a snapshot state.  The resource must not be in use.  That is, it may not be mounted on any nodes.  If the resource is in use, consider whether you can achieve your goal by <<s-restoring_a_snapshot-linstor,restoring the snapshot>> instead.
ja: LINSTOR はリソースをスナップショット状態にロールバックできます。リソースが使用中のものはできません。つまり、どのノードにもマウントされていないものです。リソースが使用中の場合は、 <<s-restoring_a_snapshot-linstor,こちら>> を検討してください。

note: type: Plain text
en: Rollback is performed as follows:
ja: ロールバックは次のようにして実行します。

note: type: Plain text
en: A resource can only be rolled back to the most recent snapshot.  To roll back to an older snapshot, first delete the intermediate snapshots.
ja: リソースは最新のスナップショットにのみロールバックできます。古いスナップショットにロールバックするには、最初に途中のスナップショットを削除します。

note: type: Title ====
en: Removing a snapshot
ja: スナップショットの削除

note: type: Plain text
en: An existing snapshot can be removed as follows:
ja: スナップショットの削除は以下のコマンドで行います。

note: type: Title ====
en: Shipping a snapshot
ja: スナップショットの転送

note: type: Plain text
en: Snapshots can be shipped between LINSTOR nodes or between different LINSTOR clusters, as well as to an S3 storage such as https://aws.amazon.com/s3/[Amazon S3] or https://min.io/[min.io].
ja: スナップショットは、LINSTOR ノード間または異なる LINSTOR クラスター間、および https://aws.amazon.com/s3/[Amazon S3], https://min.io/[min.io] などの S3 ストレージに送信できます。

note: type: Title =====
en: Remotes
ja: リモート

note: type: Plain text
en: In a LINSTOR cluster, the definition of a shipping target is called a remote.  Currently, there are two different types of remotes: LINSTOR remotes and S3 remotes.  LINSTOR remotes are used to ship snapshots to a different LINSTOR cluster, while S3 remotes are needed to ship snapshots to AWS S3, min.io or any other service using S3 compatible object storage.
ja: LINSTOR クラスターでは、転送ターゲットの定義をリモートと呼びます。現在、リモートには LINSTOR リモートと S3 リモートの2種類があります。 LINSTOR リモートは、スナップショットを別の LINSTOR クラスターに送信するために使用されますが、S3 リモートは、スナップショットを AWS S3, min.io または S3 互換オブジェクトストレージを使用するその他のサービスに送信するために使用されます。

note: type: Plain text
en: Since a remote needs to store sensitive data, such as passwords, it is neccessary to have encryption enabled whenever you wish to use a remote in any way.  How to set up LINSTOR's encryption is described <<s-encrypt_commands,here>>.
ja: リモートはパスワードなどの機密データを保存する必要があるため、何らかの方法で常に暗号化を有効にする必要があります。LINSTOR の暗号化設定は <<s-encrypt_commands,こちら>> を参照ください。

note: type: Plain text
en: To create an S3 remote, LINSTOR will need to know the endpoint (that is, the URL of the target S3 server), the name of the target bucket, the region the S3 server is in, as well as the access-key and secret-key used to access the bucket. If the command is sent without adding the secret-key, a prompt will pop up to enter it in. The command should look like this:
ja: S3 リモートを作成するには、LINSTOR はエンドポイント（つまり、ターゲット S3 サーバーのURL）、ターゲットバケットの名前、S3 サーバーが存在するリージョン、およびアクセスキーとシークレットが必要です。アクセスキーを使用せずにコマンドを送信すると、プロンプトが表示されます。コマンドは次のようになります。

note: type: Plain text
en: Usually, LINSTOR uses the endpoint and bucket to create an url using the virtual-hosted-style for its access to the given bucket (e.g. my-bucket.s3.us-west-2.amazonaws.com). Should your setup not allow access this way, change the remote to path-style access (e.g. s3.us-west-2.amazonaws.com/my-bucket)  by adding the `--use-path-style` argument to make LINSTOR combine the parameters accordingly.
ja: 通常、LINSTOR は指定されたバケット（my-bucket.s3.us-west-2.amazonaws.com など）にアクセスするために、エンドポイントとバケットを使用して、仮想ホストスタイルの URL を作成します。この方法でのアクセスが許可されていない場合は `--use-path-style`引数を追加して、パススタイルのアクセス（例: s3.us-west-2.amazonaws.com/my-bucket）に変更できます。

note: type: Plain text
en: To create a LINSTOR remote, only the URL or IP address of the controller of the target cluster is needed. The command goes as follows:
ja: LINSTOR リモートを作成するには、ターゲットクラスターのコントローラーの URL または IP アドレスのみが必要です。コマンドは次のようになります。

note: type: Plain text
en: Additionally, to ship LUKS-based (encrypted) backups, it is necessary to add the `--passphrase` and `--cluster-id` arguments to the command. This is used to save the passphrase and cluster-id of the target cluster to the remote respectively. For more details on shipping LUKS-based backups between two LINSTOR clusters, see <<s-shipping_snapshots-l2l,this chapter>>.
ja: さらに、LUKSベースの（暗号化された）バックアップを転送するには、コマンドに `--passphrase`, `--cluster-id` を追加する必要があります。これは、ターゲットクラスターのパスフレーズとクラスター ID を保存するために使用されます。2 つの LINSTOR クラスター間での LUKS ベースのバックアップの転送に関する詳細は <<s-shipping_snapshots-l2l,こちら>> を参照ください。

note: type: Plain text
en: To see all the remotes known to the local cluster, use `linstor remote list`. To delete a remote, use `linstor remote delete myRemoteName`. Should an existing remote need altering, use `linstor remote modify` to change it.
ja: ローカルクラスタに認識されているすべてのリモートを表示するには `linstor remote list` を、削除するには `linstor remote delete myRemoteName` を、変更する場合は `linstor remote modify` を使用します。

note: type: Title =====
en: Shipping snapshots to S3
ja: スナップショットの S3 への転送

note: type: Plain text
en: All that is needed to ship a snapshot to S3 is to create an S3-remote that the current cluster can reach as well as the resource that should be shipped. Then, simply use the following command to ship it there:
ja: スナップショットを S3 に送信するには、現在のクラスターが到達できる S3 リモートに、送信する必要のあるリソースを転送するだけです。次に、次のコマンドを使用して転送します。

note: type: Plain text
en: This command will create a snapshot of your resource and ship it to the given remote. If this isn't the first time you shipped a backup of this resource (to that remote) and the snapshot of the previous backup hasn't been deleted yet, an incremental backup will be shipped.  To force the creation of a full backup, add the `--full` argument to the command. Getting a specific node to ship the backup is also possible by using `--node myNode`, but if the specified node is not available or only has the resource diskless, a different node will be chosen.
ja: このコマンドは、リソースのスナップショットを作成し、指定されたリモートに転送します。このリソースのバックアップを（そのリモートに）転送するのが初めてではなく、前のバックアップのスナップショットがまだ削除されていない場合は、増分バックアップが転送されます。フルバックアップの作成を強制するには、コマンドに `--full` 引数を追加します。 `--node myNode` を使用して特定のノードにバックアップを転送することもできますが、指定したノードが使用できない場合、またはリソースがディスクレスしかない場合は、別のノードが選択されます。

note: type: Plain text
en: To see which backups exist in a specific remote, use `linstor backup list myRemote`. A resource-name can be added to the command as a filter to only show backups of that specific resource by using the argument `--resource myRsc`. If you use the `--other` argument, only entries in the bucket that LINSTOR does not recognize as a backup will be shown. LINSTOR always names backups in a certain way, and as long as an item in the remote is named according to this schema, it is assumed that it is a backup created by LINSTOR - so this list will show everything else.
ja: 特定のリモートのバックアップを確認するには `linstor backup list myRemote` を使用します。引数 `--resource myRsc` を使用して、特定のリソースのバックアップのみを表示するフィルターとして resource-name をコマンドに追加できます。 `--other` 引数を使用すると、LINSTOR がバックアップとして認識しないバケット内のエントリのみが表示されます。LINSTOR は常に特定の方法でバックアップに名前を付けます。リモート内のアイテムにこのスキーマに従って名前が付けられている限り、それは LINSTOR によって作成されたバックアップであると見なされます。したがって、このリストには他のすべてが表示されます。

note: type: Plain text
en: There are several options when it comes to deleting backups:
ja: バックアップの削除に関しては、いくつかのオプションがあります。

note: type: Plain text
en: `linstor backup delete all myRemote`: This command deletes ALL S3-objects on the given remote, as long as they are recognized to be backups, that is, fit the expected naming schema.  There is the option `--cluster` to only delete backups that were created by the current cluster.
ja: `linstor backup delete all myRemote` : このコマンドは、バックアップであると認識されている、つまり期待されるネーミングスキーマに適合している限り、指定されたリモート上のすべての S3 オブジェクトを削除します。現在のクラスターによって作成されたバックアップのみを削除するオプション `--cluster` があります。

note: type: Plain text
en: `linstor backup delete id myRemote my-rsc_back_20210824_072543`: This command deletes a single backup from the given remote - namely the one with the given id, which consists of the resource-name, the automatically generated snapshot-name (back_timestamp) and, if set, the backup-suffix. The option `--prefix` lets you delete all backups starting with the given id. The option `--cascade` deletes not only the specified backup, but all other incremental backups depending on it.
ja: `linstor backup delete id myRemote my-rsc_back_20210824_072543` : このコマンドは、指定されたリモートから単一のバックアップを削除します。つまり、ID はリソース名、自動生成されたスナップショット名（back_timestamp）、設定されていた場合はバックアップサフィックスで構成されます。オプション `--prefix` を使用すると、指定された ID で始まるすべてのバックアップを削除できます。オプション `--cascade` を使用すると、指定されたバックアップだけでなく、それに依存する他のすべての増分バックアップを削除します。

note: type: Plain text
en: `linstor backup delete filter myRemote ...`: This command has a few different arguments to specify a selection of backups to delete. `-t 20210914_120000` will delete all backups made before 12 o'clock on the 14th of September, 2021. `-n myNode` will delete all backups uploaded by the given node. `-r myRsc` will delete all backups with the given resource name.  These filters can be combined as needed. Finally, `--cascade` deletes not only the selected backup(s), but all other incremental backups depending on any of the selected backups.
ja: `linstor backup delete filter myRemote ...` : このコマンドは、削除するバックアップの選択を指定するためのいくつかの異なる引数があります。 `-t 20210914_120000` は 2021年9月14日の 12 時より前に作成されたすべてのバックアップを削除します。 `-n myNode` は指定されたノードによってアップロードされたすべてのバックアップを削除します。 `-r myRsc` は指定されたリソース名のすべてのバックアップを削除します。これらのフィルターは必要に応じて組み合わせることができます。最後に `--cascade` は選択したバックアップだけでなく、選択したバックアップのすべての増分バックアップを削除します。

note: type: Plain text
en: `linstor backup delete s3key myRemote randomPictureInWrongBucket`: This command will find the object with the given S3-key and delete it - without considering anything else. This should only be used to either delete non-backup items from the remote, or to clean up a broken backup that is no longer deleteable by other means. Using this command to delete a regular, working backup will break that backup, so beware!
ja: `linstor backup delete s3key myRemote randomPictureInWrongBucket` : このコマンドは、指定された S3 キーを持つオブジェクトを検索し、何も考慮せずにそれを削除します。これは、リモートから非バックアップアイテムを削除するか、他の方法で削除できなくなった壊れたバックアップをクリーンアップするためにのみ使用します。このコマンドを使用して通常の動作中のバックアップを削除すると、そのバックアップが破損するため、注意してください。

note: type: Plain text
en: All commands that have the `--cascade` option will NOT delete a backup that has incremental backups depending on it unless you explicitly add that option.
ja: `--cascade` オプションを持つすべてのコマンドは、明示的に指定しない限り、それに依存する増分バックアップを削除しません。

note: type: Plain text
en: All `linstor backup delete ...` commands have the `--dry-run` option, which will give you a list of all the S3-objects that will be deleted. This can be used to ensure nothing that should not be deleted is accidentally deleted.
ja: すべての `linstor backup delete ...` コマンドには `--dry-run` オプションがあり、削除されるすべての S3 オブジェクトのリストが表示されます。これを使用して、削除してはならないものが誤って削除されることを防ぐことができます。

note: type: Plain text
en: Maybe the most important task after creating a backup is restoring it. To do so, only the remote is needed - but it is also possible to restore into an existing resource definition with no existing snapshots nor resources. There are two options for the command:
ja: おそらく、バックアップを作成した後の最も重要なタスクは、バックアップを復元することです。そのために必要なのはリモートのみですが、既存のスナップショットやリソースを使用せずに既存のリソース定義に復元することもできます。コマンドには 2 つのオプションがあります。

note: type: Plain text
en: Either `--resource (-r)` or `--id` must be used, but you cannot use both of them together. `-r` is used to restore the latest backup of the resource specified with this option, while `--id` restores the exact backup specified by the given id, and can therefore be used to restore backups other than the most recent.
ja: `--resource (-r)` または `--id` のいずれかを使用する必要がありますが、両方を一緒に使用することはできません。 `-r` はこのオプションで指定されたリソースの最新のバックアップを復元するために使用されますが、`--id` は id で明示的に指定されたバックアップを復元するため、最新以外のバックアップを復元するために使用されます。

note: type: Plain text
en: If the backup to be restored includes a LUKS layer, the `--passphrase` argument is required. With it, the passphrase of the original cluster of the backup needs to be set so that LINSTOR can decrypt the volumes after download and re-encrypt them with the local passphrase.
ja: 復元するバックアップに LUKS レイヤーが含まれている場合は `--passphrase` 引数が必要です。これを使用して、バックアップの元のクラスターのパスフレーズを設定し、LINSTOR がダウンロード後にボリュームを復号化し、再暗号化できるようになります。

note: type: Plain text
en: The backup restore will download all the snapshots from the last full backup up to the specified backup. Afterwards, it restores the snapshots into a new resource. If that last step should be skipped, the `--download-only` option needs to be added to the command.
ja: バックアップの復元は、最後の完全バックアップから指定されたバックアップまでのすべてのスナップショットをダウンロードします。その後、スナップショットを新しいリソースに復元します。最後のステップをスキップする場合は `--download-only` オプションを追加します。

note: type: Plain text
en: Backups can be downloaded from any cluster, not just the one that uploaded them, as long as the setup is correct. Specifically, the target resource cannot have any existing resources or snapshots, and the storage pool(s) used need to have the same storage providers. If the storage pool(s) on the target node have the exact same names as on the cluster the backup was created on, no extra action is necessary. Should they have different names, the option `--storpool-rename` needs to be used. It expects at least one `oldname=newname` pair. For every storage pool of the original backup that is not named in that list, it will be assumed that its name is exactly the same on the target node.
ja: バックアップは、設定が正しい限り、アップロードしたクラスターだけでなく、任意のクラスターからダウンロードできます。具体的には、ターゲットリソースに既存のリソースまたはスナップショットを含めることはできず、使用するストレージプールには同じストレージプロバイダーが必要です。ターゲットノードのストレージプールの名前が、バックアップが作成されたクラスターの名前とまったく同じである場合、追加のアクションは必要ありません。名前が異なる場合は、オプション `--storpool-rename` を使用します。少なくとも 1 つの `oldname=newname` ペアが必要です。そのリストで名前が付けられていない元のバックアップのすべてのストレージプールについて、その名前はターゲットノードでまったく同じであると見なされます。

note: type: Plain text
en: To find out exactly which storage pools need to be renamed, as well as how big the download and the restored resource will be, the command `linstor backup info myRemote ...` can be used. Similar to the restore command, either `-r` or `--id` need to be given, which add the same restrictions as with that command.  To see how much space will be left over in the local storage pools after a restore, the argument `-n myNode` needs to be added. Just like with a restore, it assumes the storage pool names are exactly the same on the given node as with the backup. Should that not be the case, again, just like with the restore command, `--storpool-rename` should be used.
ja: 名前を変更する必要のあるストレージプールやダウンロードと復元されたリソースのサイズを正確に確認するには、コマンド `linstor backup info myRemote ...` を使用できます。復元コマンドと同様に `-r` または `--id` のいずれかを指定する必要があり、これにより、同じ制限が追加されます。復元後にローカルストレージプールに残っているスペースを確認するには、引数 `-n myNode` を追加します。復元の場合と同様に、特定のノードのストレージプール名がバックアップの場合とまったく同じであると想定します。そうでない場合も、復元コマンドの場合と同様に `--storpool-rename` を使用します。

note: type: Title =====
en: Shipping snapshots whithin LINSTOR
ja: LINSTOR へのスナップショットの転送

note: type: Plain text
en: Shipping a snapshot directly between two LINSTOR clusters can be done with a linstor-remote as well as a resource definition with at least one diskful resource on the source side (where the command is issued). On the target side, you only need a linstor-remote with the cluster-id of the source-cluster set.  If you wish to ship a snapshot inside the same cluster just use a remote pointing to the local controller.  The command looks like this:
ja: 2 つの LINSTOR クラスター間でスナップショットを直接転送するには、linstor-remoteと、ソース側（コマンドが発行される場所）に少なくとも 1 つのディスクフルリソースを含むリソース定義を使用します。ターゲット側では、source-cluster セットの cluster-id を持つ linstor-remote のみが必要です。同じクラスター内にスナップショットを転送する場合は、ローカルコントローラーを指すリモートを使用します。コマンドは次のようになります。

note: type: Plain text
en: Additionally, you can use `--source-node` and `--target-node` to specify which node should send and receive the backup respectively. In case those nodes are not available, a different one will be chosen automatically.
ja: さらに `--source-node` と `--target-node` を使用して、バックアップを送信および受信するノードをそれぞれ指定できます。これらのノードが使用できない場合は、別のノードが自動的に選択されます。

note: type: Plain text
en: If the target resource already has resources deployed or the `--download-only` option was specified, the snapshots will only be shipped to the target cluster, but not restored.
ja: ターゲットリソースにすでにリソースがデプロイされている場合、または `--download-only` オプションが指定されている場合、スナップショットはターゲットクラスターにのみ送信され、復元されません。

note: type: Plain text
en: When the snapshot you wish to ship contains a LUKS layer, the remote on the target cluster also needs the passphrase of the source cluster set.
ja: 転送するスナップショットに LUKS レイヤーが含まれている場合、ターゲットクラスター上のリモートにもソースクラスターセットのパスフレーズが必要です。

note: type: Title =====
en: Shipping a snapshot in the same cluster
ja: 同じクラスター内へのスナップショットの転送

note: type: Plain text
en: The `snapshot ship` command is considered deprecated and any bugs found with it will not be fixed. Instead, use the `backup ship` command with a remote pointing to your local controller. For more details, see <<s-shipping_snapshots-l2l,the previous section>>.
ja: `snapshot ship` コマンドは非推奨と見なされ、それで見つかったバグは修正されません。代わりに、リモートがローカルコントローラを指している状態で `backup ship` コマンドを使用してください。詳細は <<s-shipping_snapshots-l2l,こちら>> を参照ください。

note: type: Plain text
en: Both, the source as well as the target node have to have the resource for snapshot shipping deployed. Additionally, the target resource has to be deactivated.
ja: ソースノードとターゲットノードの両方に、デプロイされたスナップショット転送のリソースをもつ必要があります。さらに、ターゲットリソースを非アクティブ化する必要があります。

note: type: Plain text
en: Deactivating a resource with DRBD in its layer-list can NOT be reactivated again. However, a successfully shipped snapshot of a DRBD resource can still be <<s-restoring_a_snapshot-linstor,restored into a new resource>>.
ja: レイヤーリストに DRBD があるリソースを非アクティブ化すると、再びアクティブ化することはできません。ただし、DRBD リソースの正常に転送されたスナップショットは <<s-restoring_a_snapshot-linstor,新しいリソースで復元>> できます。

note: type: Plain text
en: To manually start the snapshot-shipping, use:
ja: スナップショット転送を手動で開始するには、次を使用します。

note: type: Plain text
en: By default, the snapshot-shipping uses tcp ports from the range 12000-12999. To change this range, the property `SnapshotShipping/TcpPortRange`, which accepts a to-from range, can be set on the controller:
ja: デフォルトでスナップショット転送は 12000-12999 の範囲の tcp ポートを使用します。この範囲を変更するには、プロパティ `SnapshotShipping/TcpPortRange` をコントローラーに設定します。

note: type: Plain text
en: A resource can also be periodically shipped. To accomplish this, it is mandatory to set the properties `SnapshotShipping/TargetNode` as well as `SnapshotShipping/RunEvery` on the resource-definition.  `SnapshotShipping/SourceNode` can also be set, but if omitted LINSTOR will choose an active resource of the same resource-definition.
ja: リソースは定期的に転送することもできます。これにはリソース定義で必須のプロパティ `SnapshotShipping/TargetNode` および `SnapshotShipping/RunEvery` を設定する必要があります。`SnapshotShipping/SourceNode` も設定できますが、省略した場合、LINSTOR は同じリソース定義のアクティブなリソースを選択します。

note: type: Plain text
en: To allow incremental snapshot-shipping, LINSTOR has to keep at least the last shipped snapshot on the target node. The property `SnapshotShipping/Keep` can be used to specify how many snapshots LINSTOR should keep. If the property is not set (or <= 0) LINSTOR will keep the last 10 shipped snapshots by default.
ja: 増分スナップショット転送を可能にするには、LINSTOR は少なくとも最後に転送されたスナップショットをターゲットノードに保持する必要があります。プロパティ `SnapshotShipping/Keep` は、LINSTOR が保持する必要があるスナップショットの数を指定するために使用できます。プロパティが設定されていない（または 0 以下）の場合、LINSTOR はデフォルトで最新の10個のスナップショットを保持します。

note: type: Title ===
en: Setting options for resources
ja: リソースのオプション設定

note: type: Plain text
en: DRBD options are set using LINSTOR commands.  Configuration in files such as `/etc/drbd.d/global_common.conf` that are not managed by LINSTOR will be ignored.  The following commands show the usage and available options:
ja: DRBDのオプションはLINSTORコマンドで設定します。LINSTORによって管理されていない `/etc/drbd.d/global_common.conf` のような構成ファイルは無視されます。以下のコマンドで使用法と有効なオプションが表示されます。

note: type: Plain text
en: For instance, it is easy to set the DRBD protocol for a resource named `backups`:
ja: 例えばリソース名 `backups` のDRBDプロトコルを設定するには以下のようにします。

note: type: Title ===
en: Adding and removing disks
ja: ディスクの追加と削除

note: type: Plain text
en: LINSTOR can convert resources between diskless and having a disk.  This is achieved with the `resource toggle-disk` command, which has syntax similar to `resource create`.
ja: LINSTOR はディスクレスとディスクを持つことの間でリソースを変換することができます。これは `resource create` に似た構文を持つ `resource toggle-disk` コマンドを使用します。

note: type: Plain text
en: For instance, add a disk to the diskless resource `backups` on 'alpha':
ja: 例えば 'alpha' 上にディスクレスリソース `backups` のディスクを追加するには以下のようにします。

note: type: Plain text
en: Remove this disk again:
ja: このディスクを再び削除する:

note: type: Title ====
en: Migrating disks
ja: ディスクの移行

note: type: Plain text
en: In order to move a resource between nodes without reducing redundancy at any point, LINSTOR's disk migrate feature can be used.  First create a diskless resource on the target node, and then add a disk using the `--migrate-from` option.  This will wait until the data has been synced to the new disk and then remove the source disk.
ja: 冗長性を損なうことなくリソースをノード間で移動するには、LINSTOR のディスク移行機能を使用できます。最初にターゲットノードにディスクレスリソースを作成してから、--migrate-from オプションを使用してディスクを追加します。これは、データが新しいディスクに同期されるまで待機してから、ソースディスクを削除します。

note: type: Plain text
en: For example, to migrate a resource `backups` from 'alpha' to 'bravo':
ja: 例えば、リソースの `backup` を `alpha` から `bravo` に移行するには、次のようにします。

note: type: Title ===
en: DRBD Proxy with LINSTOR
ja: LINSTORによるDRBD Proxy

note: type: Plain text
en: LINSTOR expects DRBD Proxy to be running on the nodes which are involved in the relevant connections. It does not currently support connections via DRBD Proxy on a separate node.
ja: LINSTORは、DRBD Proxyが接続するノード上で実行されることを期待しています。別のノードのDRBD Proxy経由の接続は、今のところサポートしていません。

note: type: Plain text
en: Suppose our cluster consists of nodes 'alpha' and 'bravo' in a local network and 'charlie' at a remote site, with a resource definition named `backups` deployed to each of the nodes. Then DRBD Proxy can be enabled for the connections to 'charlie' as follows:
ja: ここでクラスタが、ローカルネットワーク内のノード 'alpha' と 'bravo' とリモートサイトの 'charlie' で構成され、各ノードに配備されるリソースは `backups` と仮定すると、DRBD Proxyを使用した 'charlie' への接続を有効にするには以下のようにします。

note: type: Plain text
en: The DRBD Proxy configuration can be tailored with commands such as:
ja: DRBD Proxyのオプションは、次のコマンドで設定できます。

note: type: Plain text
en: LINSTOR does not automatically optimize the DRBD configuration for long-distance replication, so you will probably want to set some configuration options such as the protocol:
ja: LINSTORは遠隔地へのレプリケーション用にDRBD構成を自動的には最適化しないので、プロトコルなどのいくつかの構成オプションを設定することをお勧めします。

note: type: Plain text
en: Please contact LINBIT for assistance optimizing your configuration.
ja: 設定を最適化するには、LINBITにお問い合わせください。

note: type: Title ====
en: Automatically enable DRBD Proxy
ja: DRBD プロキシを自動的に有効にする

note: type: Plain text
en: LINSTOR can also be configured to automatically enable the above mentioned Proxy connection between two nodes. For this automation, LINSTOR first needs to know on which site each node is.
ja: LINSTOR は、上記の 2 つのノード間のプロキシ接続を自動的に有効にするように構成することもできます。この自動化のために、LINSTOR は最初に各ノードがどのサイトにあるかを知る必要があります。

note: type: Plain text
en: As the `Site` property might also be used for other site-based decisions in future features, the `DrbdProxy/AutoEnable` also has to be set to `true`:
ja: `Site` プロパティは将来他のサイトベースの決定にも使用される可能性があります。また、 `DrbdProxy/AutoEnable` も `true` に設定します。

note: type: Plain text
en: This property can also be set on node, resource-definition, resource and resource-connection level (from left to right in increasing priority, whereas the controller is the left-most, i.e. least prioritized level)
ja: このプロパティは、node, resource-definition, resource, resource-connection レベルでも設定できます（左から右に優先順位が高くなります。つまり controller が優先順位が最も低いレベルです）。

note: type: Plain text
en: Once this initialization steps are completed, every newly created resource will automatically check if it has to enable DRBD proxy to any of its peer-resources.
ja: この初期化手順が完了すると、新しく作成されたすべてのリソースは、そのピアリソースへの DRBD プロキシを有効にする必要があるかどうかを自動的にチェックします。

note: type: Title ===
en: External database
ja: 外部データベース

note: type: Plain text
en: It is possible to have LINSTOR working with an external database provider like PostgreSQL, MariaDB and since version 1.1.0 even ETCD key value store is supported.
ja: LINSTORはPostgresqlやMariaDBのような外部データベースとともに動作させることもでき、バージョン 1.1.0 以降では ETCD キーバリューストアもサポートされています。

note: type: Plain text
en: To use an external database there are a few additional steps to configure.  You have to create a DB/Schema and user to use for linstor, and configure this in the `/etc/linstor/linstor.toml`.
ja: 外部データベースを使用するには、構成するいくつかの追加手順があります。linstor で使用する DB/スキーマとユーザーを作成し、これを `/etc/linstor/linstor.toml` で設定する必要があります。

note: type: Plain text
en: A sample PostgreSQL `linstor.toml` looks like this:
ja: PostgreSQL のサンプル `linstor.toml` は以下のようになります。

note: type: Plain text
en: A sample MariaDB `linstor.toml` looks like this:
ja: MariaDBのサンプル `linstor.toml` は以下のようになります。

note: type: Plain text
en: The LINSTOR schema/database is created as `LINSTOR` so make sure the MariaDB connection string refers to the `LINSTOR` schema, as in the example above.
ja: LINSTORの schema/database は `LINSTOR` として作成されます。よって、MariaDB の接続が `LINSTOR` schema を参照していることを確認してください。

note: type: Plain text
en: ETCD is a distributed key-value store that makes it easy to keep your LINSTOR database distributed in a HA-setup.  The ETCD driver is already included in the LINSTOR-controller package and only needs to be configured in the `linstor.toml`.
ja: ETCD は、HA セットアップで LINSTOR データベースを簡単に分散させておくことができる分散 key-value ストアです。ETCD ドライバーはすでに LINSTOR-controller パッケージに含まれており、 `linstor.toml` で設定する必要があります。

note: type: Plain text
en: More information on how to install and configure ETCD can be found here: https://etcd.io/docs[ETCD docs]
ja: ETCD のインストールおよび構成方法の詳細については、 https://etcd.io/docs[ETCD docs] を参照ください。

note: type: Plain text
en: And here is a sample [db] section from the `linstor.toml`:
ja: 以下は `linstor.toml` のサンプル [db] セクションです。

note: type: Plain text
en: To make LINSTOR's administrative tasks more accessible and also available for web-frontends a REST-API has been created. The REST-API is embedded in the linstor-controller and since LINSTOR 0.9.13 configured via the `linstor.toml` configuration file.
ja: LINSTORの管理タスクをよりアクセスしやすくし、Webフロントエンドでも利用できるようにするために、REST-APIが作成されています。REST-APIは linstor-controller に組み込まれており、LINSTOR 0.9.13 以降 `linstor.toml` ファイルによって設定します。

note: type: Plain text
en: If you want to use the REST-API the current documentation can be found on the following link: https://app.swaggerhub.com/apis-docs/Linstor/Linstor/
ja: REST-APIを使用する場合 https://app.swaggerhub.com/apis-docs/Linstor/Linstor/ から現在の資料を見つけることができます。

note: type: Plain text
en: The HTTP REST-API can also run secured by HTTPS and is highly recommended if you use any features that require authorization. Todo so you have to create a java keystore file with a valid certificate that will be used to encrypt all HTTPS traffic.
ja: HTTP REST-APIはHTTPSで保護されて実行されるので、認証が必要な機能を使用する場合は強くお勧めします。そのため、HTTPSトラフィックの暗号化に使用される有効な証明書を含む Java キーストアファイルを作成する必要があります。

note: type: Plain text
en: Here is a simple example on how you can create a self signed certificate with the `keytool` that is included in the java runtime:
ja: 以下は Javaランタイムに含まれている `keytool` を使って自己署名証明書を作成する方法の簡単な例です。

note: type: Plain text
en: `keytool` will ask for a password to secure the generated keystore file and is needed for the LINSTOR-controller configuration.  In your `linstor.toml` file you have to add the following section:
ja: `keytool` は生成されたキーストアファイルを安全にするためにパスワードを要求します。このファイルは LINSTOR コントローラの設定で必要になります。`linstor.toml` ファイルに次のセクションを追加します。

note: type: Plain text
en: Now (re)start the `linstor-controller` and the HTTPS REST-API should be available on port 3371.
ja: `linstor-controller` を再起動するとHTTPS REST-APIがポート3371で利用可能になります。

note: type: Plain text
en: More information on how to import other certificates can be found here: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html
ja: 他の証明書をインポートする方法の詳細は、 https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html を参照ください。

note: type: Plain text
en: When HTTPS is enabled, all requests to the HTTP /v1/ REST-API will be redirected to the HTTPS redirect.
ja: HTTPS が有効な場合、HTTP /v1/ REST-API へのすべてのリクエストは HTTPS にリダイレクトされます。

note: type: Title =====
en: LINSTOR REST-API HTTPS restricted client access
ja: LINSTOR REST-API HTTPS 制限付きクライアントアクセス

note: type: Plain text
en: Client access can be restricted by using a SSL truststore on the Controller.  Basically you create a certificate for your client and add it to your truststore and the client then uses this certificate for authentication.
ja: クライアントアクセスは、コントローラの SSL トラストストアを使用して制限できます。基本的には、クライアント用の証明書を作成し、それをトラストストアに追加します。クライアントは認証にこの証明書を使用します。

note: type: Plain text
en: First create a client certificate:
ja: 最初にクライアント証明書を作成します。

note: type: Plain text
en: Then we import this certificate to our controller truststore:
ja: 次に、この証明書をコントローラのトラストストアにインポートします。

note: type: Plain text
en: And enable the truststore in the `linstor.toml` configuration file:
ja: そして `linstor.toml` 設定ファイルのトラストストアを有効にします。

note: type: Plain text
en: Now restart the Controller and it will no longer be possible to access the controller API without a correct certificate.
ja: そしてコントローラを再起動することで、証明書なしではコントローラ API にアクセスできなくなります。

note: type: Plain text
en: The LINSTOR client needs the certificate in PEM format, so before we can use it we have to convert the java keystore certificate to the PEM format.
ja: LINSTOR クライアントは PEM 形式の証明書が必要なので、使用する前に Java キーストア証明書を PEM 形式に変換する必要があります。

note: type: Plain text
en: To avoid entering the PEM file password all the time it might be convenient to remove the password.
ja: PEM ファイルのパスワードを常に入力しないようにするには、以下のようにします。

note: type: Plain text
en: Now this PEM file can easily be used in the client:
ja: これでこの PEMファイルをクライアントで使用できるようになります。

note: type: Plain text
en: The `--certfile` parameter can also added to the client configuration file, see <<s-using_the_linstor_client>> for more details.
ja: `--certfile` パラメータをクライアント設定ファイルに追加することもできます。詳細は <<s-using_the_linstor_client>> を参照ください。

note: type: Title ===
en: Logging
ja: ロギング

note: type: Plain text
en: Linstor uses https://www.slf4j.org/[SLF4J] with https://logback.qos.ch/[Logback] as binding. This gives Linstor the possibility to distinguish between the log levels `ERROR`, `WARN`, `INFO`, `DEBUG` and `TRACE` (in order of increasing verbosity). In the current linstor version (1.1.2) the user has the following four methods to control the logging level, ordered by priority (first has highest priority):
ja: LINSTOR は https://www.slf4j.org/[SLF4J] と https://logback.qos.ch/[Logback] を使用しています。これにより、LINSTOR はログレベル `ERROR`, `WARN`, `INFO`, `DEBUG`, `TRACE` (冗長性の順) を区別することができます。現在の LINSTOR バージョン (1.1.2) では、ログレベルを制御するために、ユーザーは次の4つの方法を使用できます（上から優先度順に並んでいます）。

note: type: Plain text
en: `TRACE` mode can be `enabled` or `disabled` using the debug console:
ja: `TRACE` モードは、デバッグコンソールを使用して `enabled` または `disabled` にできます。

note: type: Plain text
en: When starting the controller or satellite a command line argument can be passed:
ja: コントローラまたはサテライトを起動するときに、コマンドライン引数を渡すことができます。

note: type: Plain text
en: The recommended place is the `logging` section in the configuration file.  The default configuration file location is `/etc/linstor/linstor.toml` for the controller and `/etc/linstor/linstor_satellite.toml` for the satellite.  Configure the logging level as follows:
ja: 推奨される場所は、構成ファイルの `logging` セクションです。デフォルトの設定ファイルの場所は、コントローラの場合は `/etc/linstor/linstor.toml` 、サテライトの場合は `/etc/linstor/linstor_satellite.toml` です。次のようにログレベルを構成します。

note: type: Plain text
en: As Linstor is using Logback as an implementation, `/usr/share/linstor-server/lib/logback.xml` can also be used. Currently only this approach supports different log levels for different components, like shown in the example below:
ja: LINSTOR は実装として Logback を使用しているため `/usr/share/linstor-server/lib/logback.xml` も使用できます。現在、このアプローチのみが、以下の例に示すように、さまざまなコンポーネントのさまざまなログレベルをサポートしています。

note: type: Plain text
en: See the https://logback.qos.ch/manual/index.html[Logback Manual] to find more details about `logback.xml`.
ja: `logback.xml` の詳細は https://logback.qos.ch/manual/index.html[Logback Manual] を参照ください。

note: type: Plain text
en: When none of the configuration methods above is used Linstor will default to `INFO` log level.
ja: 上記の設定方法のいずれも使用されない場合、LINSTOR はデフォルトで `INFO` ログレベルになります。

note: type: Title ===
en: Monitoring
ja: 監視

note: type: Plain text
en: Since LINSTOR 1.8.0, a https://prometheus.io/[Prometheus] `/metrics` HTTP path is provided with LINSTOR and JVM specific exports.
ja: LINSTOR 1.8.0 以降、 https://prometheus.io/[Prometheus] `/metrics` HTTP パス がLINSTOR および JVM 固有の方法で提供されています。

note: type: Plain text
en: The `/metrics` path also supports 3 GET arguments to reduce LINSTOR's reported data:
ja: `/metrics` パスは LINSTOR のレポートデータ量を減らすために 3 つの GET 引数もサポートします。

note: type: Plain text
en: These are all default `true`, to disabled e.g. error-report data: `http://localhost:3370/metrics?error_reports=false`
ja: これらはすべてデフォルトで `true` であり、無効にするには、例えば error-report データの場合 `http://localhost:3370/metrics?error_reports=false` とします。

note: type: Title ====
en: Health check
ja: ヘルスチェック

note: type: Plain text
en: The LINSTOR-Controller also provides a `/health` HTTP path that will simply return HTTP-Status 200 if the controller can access its database and all services are up and running. Otherwise it will return HTTP error status code 500 `Internal Server Error`.
ja: LINSTOR-Controller は、コントローラーがデータベースにアクセスでき、すべてのサービスが稼働している場合に HTTP-Status 200 を返す `/health` HTTPパスも提供します。それ以外の場合は、HTTP エラーステータスコード 500 `Internal Server Error` が返されます。

note: type: Title ===
en: Secure Satellite connections
ja: サテライトへの安全な接続

note: type: Plain text
en: It is possible to have the LINSTOR use SSL secure TCP connection between controller and satellite connections.  Without going into further details on how java's SSL engine works we will give you command line snippets using the `keytool` from java's runtime environment on how to configure a 3 node setup using secure connections.  The node setup looks like this:
ja: LINSTOR でコントローラとサテライト間の接続に SSL セキュア TCP 接続を使用することができます。Java の SSL エンジンの動作について詳しく調査しなくても、Java の実行時環境の `keytool` を使用したコマンドラインの使用例を以下に示します。ここでは、 安全な接続を使用して 3 ノードのセットアップを構成する方法を示します。

note: type: Plain text
en: Node `alpha` is the just the controller.  Node `bravo` and node `charlie` are just satellites.
ja: ここで、ノード `alpha` がコントローラ、ノード `bravo` と `charlie` がサテライトとします。

note: type: Plain text
en: Here are the commands to generate such a keystore setup, values should of course be edited for your environment.
ja: 以下にキーストア設定を生成するコマンド例を示します。環境に合わせて変更してください。

note: type: Plain text
en: Now just start controller and satellites and add the nodes with `--communication-type SSL`.
ja: controller と satellites を起動し、`--communication-type SSL` でノードを追加してください。

note: type: Title ===
en: Automatisms for DRBD-Resources
ja: DRBD リソースの自動化

note: type: Title ====
en: AutoQuorum Policies
ja: 自動クォーラムポリシー

note: type: Plain text
en: LINSTOR automatically configures quorum policies on resources *when quorum is achievable*. This means, whenever you have at least two diskful and one or more diskless resource assignments, or three or more diskful resource assignments, LINSTOR will enable quorum policies for your resources automatically.
ja: LINSTORは、リソースにクォーラムポリシーを自動的に構成します（クォーラムが利用可能な場合）。つまり、少なくとも2つのディスクフルと1つ以上のディスクレスリソースがある場合、または3つ以上のディスクフルリソースがある場合 、LINSTORはリソースのクォーラムポリシーを自動的に有効にします。

note: type: Plain text
en: Inversely, LINSTOR will automatically disable quorum policies whenever there are less than the minimum required resource assignments to achieve quorum.
ja: 逆に、LINSTORは、クォーラムを使用するのに必要な最低限のリソース割り当てを満たさない場合は、クォーラムポリシーを自動的に無効にします。

note: type: Plain text
en: This is controlled via the, `DrbdOptions/auto-quorum`, property which can be applied to the _linstor-controller_, _resource-group_, and _resource-definition_. Accepted values for the `DrbdOptions/auto-quorum` property are `disabled`, `suspend-io`, and `io-error`.
ja: これは、_linstor-controller_ 、_resource-group_、および _resource-definition_ に適用できる `DrbdOptions/auto-quorum` プロパティで制御されます。  `DrbdOptions/auto-quorum` プロパティには、 `disabled` 、  `suspend-io` 、および `io-error` を設定できます。

note: type: Plain text
en: Setting the `DrbdOptions/auto-quorum` property to `disabled` will allow you to manually, or more granularly, control the quorum policies of your resources should you so desire.
ja: `DrbdOptions/auto-quorum` プロパティを `disabled` に設定すると、リソースのクォーラムポリシーを手動で、必要に応じてより詳細に制御できます。

note: type: Plain text
en: The default policies for `DrbdOptions/auto-quorum` are `quorum majority`, and `on-no-quorum io-error`. For more information on DRBD's quorum features and their behavior, please refer to the {url-drbd-ug}#s-feature-quorum[quorum section of the DRBD user's guide].
ja: `DrbdOptions/auto-quorum` のデフォルトのポリシーは `quorum majority` および `on-no-quorum io-error` です。 DRBDのクォーラム機能とその動作の詳細については、 {url-drbd-ug}#s-feature-quorum[DRBDユーザーズガイドのクォーラム] を参照してください。

note: type: Plain text
en: The `DrbdOptions/auto-quorum` policies will override any manually configured properties if `DrbdOptions/auto-quorum` is not disabled.
ja: `Drbdoptions/auto-quorum` が有効な場合、 `Drbdoptions/auto-quorum` ポリシーは手動で設定されたプロパティを上書きします。

note: type: Plain text
en: For example, to manually set the quorum policies of a _resource-group_ named `my_ssd_group`, you would use the following commands:
ja: たとえば、 `my_ssd_group` という名前の _resource-group_ のクォーラムポリシーを手動で設定するには、次のコマンドを使用します。

note: type: Plain text
en: You may wish to disable DRBD's quorum features completely. To do that, you would need to first disable `DrbdOptions/auto-quorum` on the appropriate LINSTOR object, and then set the DRBD quorum features accordingly. For example, use the following commands to disable quorum entirely on the `my_ssd_group` _resource-group_:
ja: DRBDのクォーラム機能を完全に無効にすることもできます。これを行うには、まず適切なLINSTORオブジェクトで `DrbdOptions/auto-quorum` を無効にします。そしてここにDRBDクォーラム機能を設定します。例えば `my_ssd_group` の _resource-group_ でクォーラムを完全に無効にするコマンドは次のコマンドを使用します。

note: type: Plain text
en: Setting `DrbdOptions/Resource/on-no-quorum` to an empty value in the commands above deletes the property from the object entirely.
ja: 上記のコマンドで `DrbdOptions/Resource/on-no-quorum` を空の値に設定すると、プロパティがオブジェクトから完全に削除されます。

note: type: Title ====
en: Auto-Evict
ja: 自動取り除き

note: type: Plain text
en: If a satellite is offline for a prolonged period of time, LINSTOR can be configured to declare that node as evicted. This triggers an automated reassignment of the affected DRBD-resources to other nodes to ensure a minimum replica count is kept.
ja: サテライトが長期間オフラインになっている場合、LINSTOR は、そのノードを Evictedと宣言するように構成できます。これにより、影響を受ける DRBD リソースが他のノードに自動的に再割り当てされ、最小のレプリカ数が維持されるようになります。

note: type: Plain text
en: This feature uses the following properties to adapt the behaviour.
ja: この機能は、次のプロパティを使用して動作を調整します。

note: type: Plain text
en: `DrbdOptions/AutoEvictMinReplicaCount` sets the number of replicas that should always be present. You can set this property on the controller to change a global default, or on a specific resource-definition or resource-group to change it only for that resource-definition or resource-group. If this property is left empty, the place-count set for the auto-placer of the corresponding resource-group will be used.
ja: `DrbdOptions/AutoEvictMinReplicaCount` は、常に存在する必要があるレプリカの数を設定します。このプロパティをコントローラに設定してグローバルデフォルトを変更したり、特定の resource-definition または resource-group に設定して、その resource-definition または resource-group に対してのみ変更したりできます。このプロパティを空のままにすると、対応する resource-group の auto-place に設定された値が place-count に使用されます。

note: type: Plain text
en: `DrbdOptions/AutoEvictAfterTime` describes how long a node can be offline in minutes before the eviction is triggered. You can set this property on the controller to change a global default, or on a single node to give it a different behavior. The default value for this property is 60 minutes.
ja: `DrbdOptions/AutoEvictAfterTime` は、取り除きがトリガーされる前にノードがオフラインにできる時間を分単位で示します。このプロパティをコントローラーで設定してグローバルデフォルトを変更することも、単一ノードで設定して別の動作を与えることもできます。このプロパティのデフォルト値は 60 分です。

note: type: Plain text
en: `DrbdOptions/AutoEvictMaxDisconnectedNodes` sets the percentage of nodes that can be not reachable (for whatever reason) at the same time. If more than the given percent of nodes are offline at the same time, the auto-evict will not be triggered for any node , since in this case LINSTOR assumes connection problems from the controller. This property can only be set for the controller, and only accepts a value between 0 and 100. The default value is 34. If you wish to turn the auto-evict-feature off, simply set this property to 0. If you want to always trigger the auto-evict, regardless of how many satellites are unreachable, set it to 100.
ja: `DrbdOptions/AutoEvictMaxDisconnectedNodes` は、（何らかの理由で）同時に到達できないノードの割合を設定します。指定された割合を超えるノードが同時にオフラインになっている場合、LINSTOR はコントローラーからの接続の問題を想定し、どのノードに対しても自動取り除きをトリガーしません。このプロパティはコントローラにのみ設定でき、0〜100 の値のみを受け入れます。デフォルト値は 34 です。auto-evict-feature をオフにする場合は、このプロパティを 0 に設定します。到達不能なサテライトの数に関係なく、常に自動取り除きをトリガーしたい場合は 100 に設定します。

note: type: Plain text
en: `DrbdOptions/AutoEvictAllowEviction` is an additional property that can stop a node from being evicted. This can be useful for various cases, for example if you need to shut down a node for maintenance. You can set this property on the controller to change a global default, or on a single node to give it a different behavior. It accepts true and false as values and per default is set to true on the controller. You can use this property to turn the auto-evict feature off by setting it to false on the controller, although this might not work completely if you already set different values for individual nodes, since those values take precedence over the global default.
ja: `DrbdOptions/AutoEvictAllowEviction` は、ノードの取り除きを停止できる追加のプロパティです。これは、メンテナンスのためにノードをシャットダウンする必要がある場合など、さまざまな場合に役立ちます。このプロパティをコントローラーで設定してグローバルデフォルトを変更することも、単一ノードで設定して別の動作を与えることもできます。値として true と false を受け入れ、デフォルトではコントローラーで true に設定されます。このプロパティを使用して、コントローラーで false に設定することにより、自動取り除き機能をオフにできます。ただし、個々のノードに異なる値を既に設定している場合、これらの値はグローバルデフォルトよりも優先されるため、完全には機能しない可能性があります。

note: type: Plain text
en: After the linstor-controller loses the connection to a satellite, aside from trying to reconnect, it starts a timer for that satellite. As soon as that timer exceeds `DrbdOptions/AutoEvictAfterTime` and all of the DRBD-connections to the DRBD-resources on that satellite are broken, the controller will check whether or not `DrbdOptions/AutoEvictMaxDisconnectedNodes` has been met. If it hasn't, and `DrbdOptions/AutoEvictAllowEviction` is true for the node in question, the satellite will be marked as EVICTED. At the same time, the controller will check for every DRBD-resource whether the number of resources is still above `DrbdOptions/AutoEvictMinReplicaCount`. If it is, the resource in question will be marked as DELETED. If it isn't, an auto-place with the settings from the corresponding resource-group will be started. Should the auto-place fail, the controller will try again later when changes that might allow a different result, such as adding a new node, have happened. Resources where an auto-place is necessary will only be marked as DELETED if the corresponding auto-place was successful.
ja: linstor-controller がサテライトへの接続を失うと、再接続を試みる以外に、そのサテライトのタイマーを開始します。そのタイマーが `DrbdOptions/AutoEvictAfterTime` を超え、そのサテライトの DRBD-resources へのすべての DRBD 接続が切断されると、コントローラーはすぐに `DrbdOptions/AutoEvictMaxDisconnectedNodes` に該当するかを確認します。該当しない場合でかつ、問題のノードに対して `DrbdOptions/AutoEvictAllowEviction` が true の場合、サテライトは EVICTED としてマークされます。同時に、コントローラーはすべての DRBD リソースについて、リソースの数が `DrbdOptions/AutoEvictMinReplicaCount` を満たすかどうかを確認します。満たす場合、問題のリソースは DELETED としてマークされます。満たさない場合、対応するリソースグループからの設定による自動配置が開始されます。自動配置が失敗した場合、新しいノードの追加など、別の結果を可能にする変更が発生したときに、コントローラーは後で再試行します。自動配置が必要なリソースは、対応する自動配置が成功した場合にのみ DELETED としてマークされます。

note: type: Plain text
en: The evicted satellite itself will not be able to reestablish connection with the controller.  Even if the node is up and running, a manual reconnect will fail. It is also not possible to delete the satellite, even if it is working as it should be. The satellite can, however, be restored.  This will remove the EVICTED-flag from the satellite and allow you to use it again. Previously configured network interfaces, storage pools, properties and similar entities as well as non-DRBD-related resources and resources that could not be autoplaced somewhere else will still be on the satellite. To restore a satellite, use
ja: 取り除かれたサテライト自体は、コントローラーとの接続を再確立できません。ノードが稼働している場合でも、手動での再接続は失敗します。また、正常に動作していても、サテライトを削除することはできません。取り除かれたノードを削除したい場合は `node lost` コマンドを使用する必要があります。ただし、サテライトは復元できます。サテライトから EVICTED フラグを削除することにより、再度使用できるようになります。以前に構成されたネットワークインターフェイス、ストレージプール、プロパティ、および同様のエンティティ、および DRBD に関連しないリソースと、他の場所に自動配置できなかったリソースは、引き続きサテライト上にあります。サテライトを復元するには以下を実行します。

note: type: Plain text
en: Should you wish to instead throw everything that once was on that node, including the node itself, away, you need to use the `node lost` command instead.
ja: 代わりに、ノード自体を含め、そのノードにあったすべてのものを破棄したい場合は`node lost` コマンドを使用します。

note: type: Title ===
en: QoS Settings
ja: QoS設定

note: type: Plain text
en: LINSTOR is able to set the following Sysfs settings:
ja: LINSTORは、次のSysfsの設定ができます。

note: type: Plain text
en: If a LINSTOR volume is composed of multiple "stacked" volume (for example DRBD with external metadata will have 3 devices: backing (storage) device, metadata device and the resulting DRBD device), setting a `sys/fs/\*` property for a Volume, only the bottom-most local "data"-device will receive the corresponding `/sys/fs/cgroup/...` setting.  That means, in case of the example above only the backing device will receive the setting.  In case a resource-definition has an nvme-target as well as an nvme-initiator resource, both bottom-most devices of each node will receive the setting. In case of the target the bottom-most device will be the volume of LVM or ZFS, whereas in case of the initiator the bottom-most device will be the connected nvme-device, regardless which other layers are stacked on top of that.
ja: LINSTOR ボリュームが複数の "stacked" ボリュームで構成されている場合（たとえば、外部メタデータを持つ DRBD には、下位（ストレージ）デバイス、メタデータデバイス、およびその DRBD デバイスの 3 つのデバイスがあります）、ボリュームの `sys/fs/\*` プロパティを設定することは、最下部のローカル "data" デバイスのみが対応する `/sys/fs/cgroup/...` 設定を受け取ります。つまり、この例の場合、下位デバイスのみが設定を受け取ります。リソース定義が nvme-target および nvme-initiator リソースを持つ場合、各ノードの最下部のデバイスの両方が設定を受け取ります。ターゲットの場合、最下部のデバイスは LVM または ZFS のボリュームになりますが、イニシエーターの場合、最下部のデバイスは接続された nvme デバイスになります。その上に他のどのレイヤーがスタックされているかは関係ありません。

note: type: Title ===
en: Getting help
ja: ヘルプの利用

note: type: Title ====
en: From the command line
ja: コマンドラインから確認

note: type: Plain text
en: A quick way to list available commands on the command line is to type `linstor`.
ja: コマンドラインで利用可能なコマンドを確認するには `linstor` とタイプします。

note: type: Plain text
en: Further information on sub-commands (e.g., list-nodes) can be retrieved in two ways:
ja: サブコマンドのさらなる情報は次の２つの方法で確認できます。

note: type: Plain text
en: Using the 'help' sub-command is especially helpful when LINSTOR is executed in interactive mode (`linstor interactive`).
ja: LINSTOR がインタラクティブモード（ `linstor interactive` ）で動作しているときには 'help' サブコマンドはとても役にたちます。

note: type: Plain text
en: One of the most helpful features of LINSTOR is its rich tab-completion, which can be used to complete basically every object LINSTOR knows about (e.g., node names, IP addresses, resource names, ...).  In the following examples, we show some possible completions, and their results:
ja: LINSTORで役に立つ機能の１つに豊富なタブ補完機能があります。これはLINSTORが認識する基本的なすべてのオブジェクト（例えばノード名、IPアドレス、リソース名など）を完成させるために使用できます。以下の例では、いくつかの可能な補完とその結果を示します。

note: type: delimited block -
en: # linstor node create alpha 1<tab> # completes the IP address if hostname can be resolved
    # linstor resource create b<tab> c<tab> # linstor assign-resource backups charlie
ja: # linstor node create alpha 1<tab> # ホスト名が解決できるとIPアドレスを補完します
    # linstor resource create b<tab> c<tab> # linstorは backups, charlieリソースを補完します

note: type: Plain text
en: If tab-completion does not work out of the box, please try to source the appropriate file:
ja: タブ補完機能が動作しない場合は以下のファイルをソースしてください。

note: type: delimited block -
en: # source /etc/bash_completion.d/linstor # or
    # source /usr/share/bash_completion/completions/linstor
ja: # source /etc/bash_completion.d/linstor # または
    # source /usr/share/bash_completion/completions/linstor

note: type: Plain text
en: For zsh shell users linstor-client can generate a zsh compilation file, that has basic support for command and argument completion.
ja: zsh ユーザのためにlinstor-clientはzshタブ補完機能用のファイルを生成できます。これはコマンドと引数の基本的なサポート機能です。

note: type: Title ====
en: SOS-Report
ja: SOS レポート

note: type: Plain text
en: If something goes wrong and you need help finding the cause of the issue, you can use
ja: 何か問題が発生し、問題の原因を見つけるのに助けが必要な場合は、以下のコマンド使用します。

note: type: Plain text
en: The command above will create a new sos-report in `/var/log/linstor/controller/` on the controller node. Alternatively you can use
ja: 上記のコマンドは、コントローラーノードの `/var/log/linstor/controller/` に新しい sos-report を作成します。または、以下のコマンドも使用できます。

note: type: Plain text
en: which will create a new sos-report and additionally downloads that report to the local machine into your current working directory.
ja: これにより、新しい sos-report が作成され、さらにそのレポートがローカルマシンの現在の作業ディレクトリにダウンロードされます。

note: type: Plain text
en: This sos-report contains logs and useful debug-information from several sources (Linstor-logs, `dmesg`, versions of external tools used by Linstor, `ip a`, database dump and many more).  These information are stored for each node in plaintext in the resulting `.tar.gz` file.
ja: この sos-report には、いくつかのソース（Linstor-logs, `dmesg`, 外部ツールのバージョン, `ip a`, データベースダンプなど）からのログと有用なデバッグ情報が含まれています。これらの情報はノードごとにプレーンテキストで `.tar.gz` ファイルに保存されます。

note: type: Title ====
en: From the community
ja: コミュニティの助けを借りる

note: type: Plain text
en: For help from the community please subscribe to our mailing list located here: https://lists.linbit.com/listinfo/drbd-user
ja: コミュニティの助けを借りるには https://lists.linbit.com/listinfo/drbd-user にあるメーリングリストを購読してください。

note: type: Plain text
en: To file bug or feature request please check out our GitHub page https://github.com/linbit
ja: バグや機能要求を提出するには、GitHubページ https://github.com/linbit を確認してください。

note: type: Title ====
en: Paid support and development
ja: 有料のサポートと開発

note: type: Plain text
en: Alternatively, if you wish to purchase remote installation services, 24/7 support, access to certified repositories, or feature development please contact us: +1-877-454-6248 (1-877-4LINBIT) , International: +43-1-8178292-0 | sales@linbit.com
ja: リモートインストールサービス、24時間365日のサポート、認定リポジトリへのアクセス、または機能開発をご希望の場合は、1-877-454-6248（1-877-4LINBIT）、International：43-1-8178292 -0 | sales@linbit.com にお問い合わせください。
