|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
ベストプラクティス
以下のセットアップは、プロダクション環境に推奨されます。
最小推奨ハードウェア
-
3ノード
-
ノードあたり4 vCPU
-
ノードあたり4 GiB
-
ストレージ用にノード上にSSD/NVMeまたは同等の性能のブロックデバイスを使用することを推奨します。
-
ストレージ用にノード上にHDD/スピニングディスクまたは同等の性能のブロックデバイスを使用することが確認されています。
-
ボリュームあたり最大500/250 IOPS（1 MiB I/O）
-
ボリュームあたり最大500/250スループット（MiB/s）
-
|
SUSE StorageはHDD（スピニングディスク）をストレージとして使用できますが、*レイテンシー*がIOPSやスループットよりもボリュームの安定性においてはるかに重要な役割を果たすことを理解することが重要です。これは、HDDが機械的であり、データにアクセスするために回転するプラッタと移動する読み取りまたは書き込みヘッドに依存しているためです。この物理的な動きは固有の遅延（シーク時間と回転遅延）を引き起こし、フラッシュメモリを利用し、可動部品を持たないSSDやNVMeドライブと比較して、はるかに高いレイテンシーをもたらします。これは、特に次のような複数の入出力集中的なタスクが実行されているときに、直接的に不安定さを引き起こす可能性があります。
HDDの使用によるレイテンシーの増加は、他の入出力ワークロードと相まって、*ボリュームの不安定性*を引き起こす可能性があります。したがって、特にプロダクションワークロードに対して、より良いパフォーマンスと安定性のために*SSDまたはNVMe*ドライブを推奨します。 前述のIOPSとスループット（ボリュームあたり最大500/250 IOPSおよび最大500/250スループット）は、テストセットアップに基づく一般的な参考値として意図されていますが、厳密な要件として扱うべきではありません。レイテンシーはスループットだけでなく、システムの安定性を確保する上で最も重要な要素です。 |
オペレーティングシステム
|
CentOS Linuxは、CentOS Stream [ref] に移行されたため、以下の検証済みOSリストから削除されました。これはローリングリリースのLinux配布パッケージです。RHELベースのダウンストリームオープンソースディストリビューションのテストは、Rocky LinuxやOracle Linuxなどのエンタープライズグレードのバージョンに焦点を当てています。 |
以下のLinux OS配布パッケージとバージョンは、v1.11.2リリーステスト中に検証されました。ただし、これはSUSE Storageがこれらのディストリビューションを独占的にサポートしていることを意味するものではありません。SUSE Storageは、幅広い汎用オペレーティングシステムを実行しているLinuxノード上の認定Kubernetesクラスターでうまく機能するはずです。また、SLE Microのような検証済みのコンテナ最適化オペレーティングシステムでも動作します。
| いいえ。 | OS | バージョン |
|---|---|---|
1. |
Ubuntu |
24.04 |
2. |
SUSE Linux Enterprise Server |
16 |
3. |
SUSE Linux Enterprise Micro |
6.1 |
4. |
Red Hat Enterprise Linux |
10.1 |
SUSE Storageはカーネル機能に大きく依存しており、特定のカーネルバージョンでより良いパフォーマンスを発揮します。以下の活動は、特に特定のカーネルバージョンの使用から恩恵を受けます。
-
ファイルシステムの最適化または改善：バージョン`v5.8`以上のカーネルを使用してください。詳細については、 Issue #2507を参照してください。
-
スナップショット用のファイルシステムをフリーズする設定を有効にする：ファイルシステムのフリーズ中にボリュームクラッシュがノードをロックしないようにするために、バージョン`5.17`以上のカーネルを使用してください。
-
V2データエンジンを有効にする：バージョン`5.19`以上のカーネルを使用して、確実にしてください。
以下のリストには、ユーザーが使用を避けるべき既知の壊れたカーネルバージョンが含まれています：
| いいえ。 | バージョン | ディストリビューション | 追加のコンテキスト |
|---|---|---|---|
1. |
6.5.6 |
バニラカーネル |
このバグに関連しています https://longhorn.io/kb/troubleshooting-rwx-volume-fails-to-attached-caused-by-protocol-not-supported/ |
2. |
5.15.0-94 |
Ubuntu |
このバグに関連しています https://longhorn.io/kb/troubleshooting-rwx-volume-fails-to-attached-caused-by-protocol-not-supported/ |
3. |
6.5.0-21 |
Ubuntu |
このバグに関連しています https://longhorn.io/kb/troubleshooting-rwx-volume-fails-to-attached-caused-by-protocol-not-supported/ |
4. |
6.5.0-1014-aws |
Ubuntu |
このバグに関連しています https://longhorn.io/kb/troubleshooting-rwx-volume-fails-to-attached-caused-by-protocol-not-supported/ |
Kubernetes
Kubernetesバージョン
アップグレードする前に、クラスターがKubernetes v1.21以上で動作していることを確認してください SUSE Storage。
Kubernetesクラスターを以下のバージョンのいずれかで実行することをお勧めします。これらのバージョンは、SUSE Storageリリース前のアクティブなサポートバージョンであり、SUSE Storage v1.11.2でテストされています。
| リリース | リリース済み | End-of-life |
|---|---|---|
1.35 |
2025年12月17日 |
2027年2月28日 |
1.34 |
2025年8月27日 |
2026年10月27日 |
1.33 |
2025年4月23日 |
2026年6月28日 |
1.32 |
2024年12月11日 |
2026年2月28日 |
ノードとディスクのセットアップ
ノードとディスクのために以下のセットアップを推奨します。
最小限の利用可能ストレージとオーバープロビジョニング
ルートディスクを使用する必要がある場合は、デフォルトの`minimal available storage percentage`セットアップ（25%）を使用し、`overprovisioning percentage`を100%に設定してDiskPressureの可能性を最小限に抑えてください。
SUSE Storage用に専用ディスクを使用している場合は、設定`minimal available storage percentage`を10%に下げることができます。
オーバープロビジョニングの割合は、ボリュームが平均してどれだけのスペースを使用するかによります。例えば、ワークロードが利用可能なボリュームサイズの半分しか使用しない場合、オーバープロビジョニングの割合を`200`に設定できます。これは、SUSE Storageがディスクを予約スペースを除いたフルサイズの2倍のスケジュール可能なサイズを持つと見なすことを意味します。
ディスク容量管理
SUSE Storageは現在、異なるディスク間でのシャーディングをサポートしていないため、 LVMを使用してすべてのディスクをSUSE Storageの単一パーティションに集約し、将来的に簡単に拡張できるようにすることをお勧めします。
追加ディスクのセットアップ
追加のディスクは、マシンが再起動した後に自動的にマウントできるように、`/etc/fstab`ファイルに記述する必要があります。
追加のディスクにはシンボリックリンクを使用しないでください。`ln -s`の代わりに`mount --bind`を使用し、それが`fstab`ファイルに含まれていることを確認してください。詳細については、複数のディスクサポートに関するセクションを参照してください。
インストール前後のデフォルトディスクの設定
デフォルトの`/var/lib/longhorn`以外のディレクトリをストレージに使用するには、システムをインストールする前に`Default Data Path`設定を変更できます。インストール前の設定変更の詳細については、このセクションを参照してください。
デフォルトのノード/ディスク構成機能を使用して、インストール後にデフォルトのディスクをカスタマイズできます。ディスクとノードのデフォルト設定をカスタマイズすることは、クラスターのスケーリングに役立ちます。これは、ノードが複数のディスクを含む場合や、新しいノードのディスク設定が異なる場合に、各新しいノードのためにSUSE Storageを手動で設定する必要がなくなるためです。該当する場合は、`Create default disk only on labeled node`を有効にすることを忘れないでください。
ボリュームパフォーマンス最適化
ワークロードを構成する前に、最適なボリュームパフォーマンスのために以下の基本要件を設定していることを確認してください。
-
SATA/NVMe SSDまたは同様のパフォーマンスを持つディスクドライブ
-
ノード間の10 Gbpsネットワーク帯域幅
-
システム管理およびユーザーがデプロイしたSUSE Storageコンポーネントの専用優先クラス。デフォルトでは、SUSE Storageはデフォルトの優先クラス`longhorn-critical`をインストールします。
以下のセクションでは、プロダクション環境に対する他の推奨事項を概説します。
IOパフォーマンス
-
ストレージネットワーク:IOパフォーマンスと安定性を向上させるために、専用ストレージネットワークを使用してください。
-
SUSE Storageディスク:ルートディスクを使用する代わりに、専用ディスクをSUSE Storageストレージに使用してください。
-
レプリカ数:データの可用性を確保し、ディスクスペースの使用を改善するか、システムパフォーマンスへの影響を軽減するために、デフォルトのレプリカ数を「2」に設定してください。この実践は、特にデータ集約型アプリケーションに有益です。
-
ストレージタグ:ストレージタグを使用して、データ集約型アプリケーションのストレージ階層を定義します。例えば、高性能ディスクのみがパフォーマンスに敏感なデータの保存に使用できます。
-
データのローカリティ:`best-effort`をSUSE Storage StorageClassesのデフォルトのデータのローカリティとして使用します。
データレプリケーションをサポートするアプリケーション（例えば、分散データベース）では、`strict-local`オプションを使用して、各ボリュームに対して1つのレプリカのみが作成されることを保証できます。この手法は、ボリュームレプリケーションに関連する追加のディスクスペース使用とIOパフォーマンスのオーバーヘッドを防ぎます。
データ集約型アプリケーションでは、ノードセレクタやタイントレランスなどのポッドスケジューリング機能を使用できます。これらの機能により、ワークロードを特定のストレージタグ付きノードに1つのレプリカと共にスケジュールできます。
スペース効率
-
定期的スナップショット:定期的にシステム生成のスナップショットをクリーンアップし、実装に適した数のスナップショットのみを保持します。
レプリケーション機能を持つアプリケーションの場合、定期的にすべてのタイプのスナップショットを削除します。
-
定期的なファイルシステムのトリム:定期的にボリューム内のファイルシステムをトリムして、ディスクスペースを回収します。
-
スナップショットスペース管理:グローバルおよびボリューム特有の設定を構成して、予期しないディスクスペースの枯渇を防ぎます。
障害復旧
-
定期的なバックアップ:ミッションクリティカルなアプリケーションボリュームのために定期的なバックアップジョブを作成します。
-
システムバックアップ:定期的にシステムバックアップを作成します。
ワークロードの展開
ボリュームのファイルシステムとして`ext4`を使用している場合、ネットワークによる中断、ノードの再起動、またはDockerの再起動から自動的に回復するために、ワークロードにライブネスチェックを追加することをお勧めします。詳細についてはこのセクションを参照してください。
ボリュームのメンテナンス
SUSE Storageのビルトインバックアップ機能を使用することを強くお勧めします。バックアップをS3などのオブジェクトストアやNFSサーバーに保存できます。オブジェクトストアに保存する方が望ましいです。なぜなら、一般的により良い信頼性を提供するからです。もう一つの利点は、ターゲットをマウントおよびアンマウントする必要がないため、フェールオーバーやアップグレードが複雑になることがないことです。
各ボリュームについて、少なくとも1回の定期的なバックアップをスケジュールしてください。バックアップストアなしでSUSE Storageを本番環境で実行する必要がある場合は、各ボリュームについて少なくとも1回の定期的なスナップショットをスケジュールしてください。
SUSE Storageはレプリカを再構築する際にスナップショットを自動的に作成します。定期的なスナップショットやバックアップは、システム生成のスナップショットを自動的にクリーンアップすることもできます。
V1データエンジン
`Guaranteed Instance Manager CPU`の設定により、V1データエンジンが有効な場合、各インスタンスマネージャーポッドのために各ノードで割り当て可能なCPUリソースのパーセンテージを予約できます。デフォルト値は12です。
特定のノードのインスタンスマネージャーポッドのために特定のミリCPU値を設定するには、そのノードのインスタンスマネージャーCPUリクエストフィールドを更新してください。
|
このフィールドは、指定されたノードの上記設定を上書きします。 |
詳細については保証されたインスタンスマネージャーCPUを参照してください。
ストレージクラス
デフォルトのストレージクラス`longhorn`を変更しないでください。そのパラメータを変更すると、将来のアップグレード中に問題が発生する可能性があります。ストレージクラスに設定されたパラメータを変更するには、ストレージクラスの例を参照して新しいストレージクラスを作成できます。
スケジューリング設定
レプリカノードレベルのソフトアンチアフィニティ
推奨: false
この設定は、ボリュームの最適な可用性を確保するために、運用環境では`false`に設定する必要があります。そうしないと、1つのノードのダウンイベントがボリュームの複数のレプリカをダウンさせる可能性があります。
可用性が低下した状態でのボリューム作成を許可する
推奨: false
この設定（false）を運用環境で無効にして、作成時のボリュームの最大可用性を確保してください。有効にすると（true）、システムが1つのレプリカしかスケジュールできなくてもボリュームの作成が成功します。これにより、クラスターがユーザーに即座に通知することなくスペースが不足するリスクが生じます。
レプリカ自動バランス
推奨: least-effort
本番環境では、レプリカ自動バランスを`least-effort`に設定することをお勧めします。この設定により、各ゾーンの異なるノードに少なくとも1つのレプリカが配置され、高可用性（HA）が提供されます。
特定のエッジケースでは、`best-effort`を使用することを検討するかもしれません。これは、レプリカをノードとゾーン全体に均等に分配しようとし続けます。ただし、この設定は、クラスターが不安定な場合に頻繁な再構築を引き起こす可能性があります。
ほとんどのユーザーにとって、レプリカ自動バランス設定なしで複数のレプリカを持つことは、特に過剰な再構築やリソース使用を避けたい場合に、基本的なHAを達成するのに十分です。